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

IIT Software wrote:

You should always use our springsupport.jar. There are issues with Spring, especially with a TransactionManager. For example, if you use the default values on the DefaultMessageListenerContainer, it will use receive(1000) and runs a commit every second. If you don't use pooling, it will create/destroy sessions etc on every go.

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.

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.

IIT Software wrote:

I got a strange exception from DefaultMessageListenerContainer stating that a message was received while the listener was stopped. Don't know what that means but I was able to get over it by adding a property. See attached Spring context. swiftmq-context.xml

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:

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.

IIT Software wrote:

The problem with many producers for temp queues can be solved a) by using an unidentified producer or b) by reducing the poolExpiration. Both are supported by our springsupport. The usual way is a) in request/reply. I don't know how you can use an unidentified producer in Spring's request/reply.

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.

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.

Does the springsupport SingleSharedConnectionFactory perform any other magic besides caching the connection related objects that the CachingConnectionFactory does not?