JBossDeveloper

MonteiroSP wrote:

 

That leads to the beginning of the conversation.

 

Pure JMS specification objects are hard to pool, because once the server crash or goes offline due to some network problem, the cached sessions, producers and consumers become "broken" and there's no way to check their consistency and purge the bad ones out of the pool.

 

That's not correct, the JCA adaptor, handles dead connections, and it just uses the standard JMS API.

In JMS you can set an ExceptionListener on a connection and it will be called in event of connection failure.

Quoting JMS 1.1 specification, chapter 4.3.5 Closing a Connection: "Once a connection has been closed, an attempt to use it or its sessions or their
message consumers and producers must throw an IllegalStateException (calls to the close method of these objects must be ignored)."

HornetQ was not compliant with this part of the JMS spec in some older beta releases, but it does comply in the current GA release. In my framework (no JCA, no JEE container) I shutdown and recreate the application thread which gets such exception, and I recreate the Connection when its ExceptionListener gets called. Threads use the shared Connection when they start to create their Sessions and following JMS objects. It seems to work fine so far.

Please note that you cannot actually pool JMS Sessions and objects created from them (producers, consumers) between the threads - the JMS spec mandates that they must not be shared between threads! So making each thread create its own JMS Session(s) etc. is a reasonable approach, I think.

LeosBitto wrote:

 

Quoting JMS 1.1 specification, chapter 4.3.5 Closing a Connection: "Once a connection has been closed, an attempt to use it or its sessions or their
message consumers and producers must throw an IllegalStateException (calls to the close method of these objects must be ignored)."

 

HornetQ was not compliant with this part of the JMS spec in some older beta releases, but it does comply in the current GA release. In my framework (no JCA, no JEE container) I shutdown and recreate the application thread which gets such exception, and I recreate the Connection when its ExceptionListener gets called. Threads use the shared Connection when they start to create their Sessions and following JMS objects. It seems to work fine so far.

 

Please note that you cannot actually pool JMS Sessions and objects created from them (producers, consumers) between the threads - the JMS spec mandates that they must not be shared between threads! So making each thread create its own JMS Session(s) etc. is a reasonable approach, I think.

Well, almost To clarify, a JMS session can be shared between different threads, it just mustn't be accessed by more than one thread *concurrently*.

From the spec:

"There are no restrictions on the number of threads that can use a Session object or those it creates. The restric-
tion is that the resources of a Session should not be used concurrently by multiple threads. It is up to the user
to insure that this concurrency restriction is met. The simplest way to do this is to use one thread. In the case
of asynchronous delivery, use one thread for setup in stopped mode and then start asynchronous delivery.
In more complex cases the user must provide explicit synchronization."

Although I do think some people pool JMS resources out of habit, and where unnecessary, perhaps due to bad habits caused by e.g. usage of the Spring JMS Template, there are valid reasons for pooling, outside the app server environment, e.g. standalone servlet engine.

Perhaps we should consider writing a pool for these use cases?

If so, someone could create a JIRA....

Basically Tim was asking you to open the JIRA. You would put your name on the history of HornetQ :-)

https://jira.jboss.org/jira/browse/HORNETQ

but If you don't want to.. I can do it myself :-)

Leos Bitto wrote:

 

Tim, I think that the users would appreciate having an easy and efficient JMS access outside of JEE container. I believe that providing implementations of ConnectionFactory, Connection and Sesion which would do proper caching of the created objects should not be too difficult. I could contribute such code if you would like.

Leos, sure take a stab at the JIRA if you like.

I'd suggest first making a proposal about how you intend to do it on the dev forum.

Tim Fox wrote:

 

 

Leos, sure take a stab at the JIRA if you like.

 

I'd suggest first making a proposal about how you intend to do it on the dev forum.

My proposal with the initial implementation is on the dev forum.