If you checkout the trunk code of NMS.Stomp you can now connect up to a Stomp v1.1 broker and it will take advantage of the new features in the Stomp v1.1 spec. I started working on this on Friday and think I've got everything working now. So what do you get, well for now the main thing is that Stomp v1.1 supports heart beats between client and broker so the NMS.Stomp client is much more resilient when it comes to detecting that its connection to the broker has dropped. The Failover Transport that I added to NMS.Stomp in v1.4 should get informed by the inactivity monitor now much quicker that it needs to reconnect.
You can try it out using the Apollo broker which you can download from here.
2 comments:
Hi!
Hopefully you are a NMS expert and can explain to me why NMSTemplate seems to create a new socket for sending messages to AMQ every so often. Checking what's going on with netstat reveals this:
C:\>netstat -an|find "61616"
TCP 0.0.0.0:61616 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1593 127.0.0.1:61616 TIME_WAIT
TCP 127.0.0.1:1594 127.0.0.1:61616 TIME_WAIT
TCP 127.0.0.1:1596 127.0.0.1:61616 TIME_WAIT
TCP 127.0.0.1:1597 127.0.0.1:61616 TIME_WAIT
TCP 127.0.0.1:1598 127.0.0.1:61616 TIME_WAIT
TCP 127.0.0.1:1599 127.0.0.1:61616 TIME_WAIT
TCP 127.0.0.1:1600 127.0.0.1:61616 TIME_WAIT
TCP 127.0.0.1:1601 127.0.0.1:61616 TIME_WAIT
TCP 127.0.0.1:1602 127.0.0.1:61616 TIME_WAIT
... hundreds of similar socket binds...
Anyway, after some time the server will not respond. Is this a bug in the nms implementation shipped with Spring.Net 1.3 or is there something one should do to release these sockets when using NMSTemplate's ConvertAndSend method?
I've just followed the examples that you can find on the AMQ and Spring.Net sites. I haven't read anywhere that I should handle socket releases when using this template from NMS.
Thanks,
Steinard.
Sounds like an NMSTemplate bug, I'd report an issue to them about it, maybe provide them with a sample that reproduces the issue.
Post a Comment