Reccyle JMS connections and sessions after a period of inactivity

Idea / RFE Review. Apologies for the length of time this idea has been in the status of Uncommitted Candidate / Future Consideration. Unfortunately on this occasion we have decided not to take this suggestion further forward. Given that this requirement goes beyond the JMS specification itself, and has only gathered 6 votes (and none since 2016), there appears to be limited wider appeal for this requirement … Given that there is also already an easy to implement workaround of flow retry, unfortunately on this occasion we are closing the suggestion.

Hi Bill, thanks for the clarification and PMR number. For the benefit of wider readership, I'm going to add some of the relevant information here about IIB capabilities which were discussed on the PMR in question. IIB does not currently provide any way to forcibly refresh JMS connections or sessions after a pre-determined period. Since the JMS interface does not provide a way to check the health of a connection or session we rely on an exception being thrown in order to indicate that the current session should be cleaned up. We do provide an option on the configurable service that will register an asychronous exception listener on the connection that will cause a connection refresh if an exception is thrown, however in our experience not all JMS providers implement this part of the JMS specification. The current expected behaviour is that when an exception is detected in an output node this is thrown back to the message flow to allow the flow developer to handle the exception. This means that one current solution for the use case would be for the flow itself to attempt a retry.

On the wider topic of an automatic reconnection from IIB to the JMS provider after a period of inactivity, given the inconsistent behaviour of different providers in this area, it seems a sensible possible enhancement for the product to allow a user to specify a time period after which IIB automatically recycles all connections. Given that this goes beyond the specification and relates to the connection rather than a single node, it may be more sensible to implement on the configurable service rather than exposed directly on the node properties. Status of this RFE is updated to Uncommitted Candidate.

We would like a inactivity timeout parameter on the JMS nodes that recycles all the connections after a period of inactivity. In other words close all the connections and re-establish new connections when required.

The PMR reference is 05123,999,616

Thank you for raising this RFE. To clarify, is the request to add a "keep alive" property/behaviour to the JMS nodes (a concept not covered by the JMS specification) to in some way avoid the session being closed after a period of inactivity? Or is the preference for a more specific elegant TibCo EMS behaviour whereby a connection is more easily re-established automatically after the inactive period? Apologies if this information is already provided in the PMR - would you be able to provide the PMR number so we might correlate with any prior discussions which were made through that mechanism?