Today marks the official release of Apache.NMS.Stomp v1.5.2. We put a lot of work into this one fixing bugs that were found since the 1.5.1 release.
For anyone on v1.5.1 I'd definitely recommend upgrading, there were a couple of threading issues that have been resolved which should make things more stable, and interoperability with Stomp v1.1 should be much improved.
The v1.5.2 release page is here
8 comments:
Hi Tim,
The extra work paid off and is much appreciated! I'm still getting one issue though: http://activemq.2283324.n4.nabble.com/Apache-Stomp-Apollo-broker-nodejs-client-works-fine-NMS-client-disconnecting-td4564748.html#a4568737
Do you expect a version 1.5.3 coming out any time soon?
Without knowing why this is happening its hard to say what the issue is. If you can come up with a test case that reproduces the issue reliably we can look into it. There's been no changes to the Stomp code since 1.5.2 so there's no reason for a 1.5.3 at the moment.
Hi Tim, makes total sense.
The short lines would be, sending 99 messages at 100ms interval from two different MQ connections (one for sender, then a large wait (lets say 60 seconds) before sending the 100th message, and continuing sending messages at 100ms. In this precise case, I get a disconnect at the 150th message where the ACK seems to not be properly formed (maybe). On the other hand, sending a message each second does not seem to cause any disconnect. We work with different tools, but if you're curious and willing, contact me at bugvito@gmail.com and I'll ship you whatever you need to make any sense of my description ;)
The best way to help is to try and create an NUnit test case that can reproduce the issue when run against Apollo, then create a Jira issue and attach your test case, that way it will not get lost and will get worked on when time permits.
Quick note on BugVito's problem. Doing a Wireshark capture, we see a properly formed ACK messages (terminated by 00 00 0A) and when the problem occurs we are seeing the normal ACK message followed by a packet containing only (01 0A).
This seems to be confusing the Apollo broker which causes a disconnection (Unable to parser header line [ascii: ACK] ).
We can't seem to find in the code where that 01 0A message might be coming from.
I am gettting the below error when I use the "Apache.NMS.Stomp v1.5.2" version.
" Queue /queue/TEST does not exist "
same error for topic as well.
when i use the this version "Apache.NMS.Stomp v1.5.2", i am unable to connect to the queue. I am getting the below error.
Error: Queue /queue/CTM does not exist
The same is working with the earlier version.
Your best bet here is to open a jira issue and attach a test case along with more info on your environment. Not sure what broker you are using.
Post a Comment