Re: SwiftMQ 7.4.1 + spring 2.5 + transactions + ReplyTo == trouble

Bryan Talbot wrote:

Yes, this is what seems to cause the object leak in the SwiftMQ router itself.  Note that these leaked objects do not go away when the client disconnects or quits -- the router must be restarted.  This seems like a pretty serious leak that any JMS client might cause.

It only happens with Spring in this scenario but we were not able to figure our why. I'm not sure if this is a bug in SwiftMQ. But anyway, we will dive into it.

Bryan Talbot wrote:

The connection and session creation issues can also be avoided by using springs SingleConnectionFactory or CachingConnectionFactory which is what I'm using in the sample app above.  The CachingConnectionFactory is configured in the sample to not cache any producers but will still cache connections, sessions, and consumers.

Might be but that's simply not tested from us. We have tested our springsupport but we are not able to test any new Spring features etc.

Bryan Talbot wrote:

I've not seen that happen before.  Did that occur during startup or shutdown or while the listener was expected to be running?  I've not tried the properties yet, but it doesn't look like those settings are meant to be used with a transaction manager.  From the API docs for setReceiveTimeout:

It happend if I use samples/P2PRequestor with 2 messages. First one wents through, the second hangs because of this reason.

Bryan Talbot wrote:

 From the API docs for setReceiveTimeout:

Set the timeout to use for receive calls, in milliseconds. The default is 1000 ms, that is, 1 second.
NOTE: This value needs to be smaller than the transaction timeout used by the transaction manager (in the appropriate unit, of course). -1 indicates no timeout at all; however, this is only feasible if not running within a transaction manager.  

Since I'm using a JmsTransactionManager, that seems like asking for trouble.

The question is why there is a transaction timeout at all. JMS local transactions never timeout and it is not spec compliant to call rollback/commit from another thread to terminate a receive. You can only call session.close from another thread. However, setting receiveTimeout=-1 will avoid this strange behavior to commit empty transactions every second. So you should use -1.

Bryan Talbot wrote:

AFAIK, spring is handling the reply like most JMS applications would.  It calls Session.createQueue() using the name from the ReplyTo header.  A producer is then created from that Destination, then a Message which is finally sent.

That is not how request/reply is handled from a JMS application. Message.getJMSReplyTo() returns already a javax.jms.Destination object. In your case it's a javax.jms.TemporaryQueue, not a javax.jms.Queue. If Spring really acts like you describe above, this could be one cause for the problems.

Bryan Talbot wrote:

It seems that for the caching of connection related objects to be effective at all, the object lifetime must be at least a few seconds or connections or sessions won't be reused.  Is that correct?  If it is, then a large number of messages can be processed during that time with each of them producing a response.  I'd have to make the max-temp-producers-per-connection value very large to accommodate this.

Why don't you just use an unidentified producer? You can create it with session.createProducer(null) and pass the destination during send. That's how request/reply should be done. You can create it from our springsupport like any other producer and it will be cached (checkout on create, checkin on close).