Saturday, November 19, 2011

Apache.NMS.Stomp v1.5.2 Released

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:

BugVito said...

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?

Tim said...

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.

BugVito said...

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 ;)

Tim said...

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.

Danny D'Amours said...

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.

Madhukar said...

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.

Madhukar said...

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.

Tim said...

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.