I am working on a project where we have some ejbs and mdbs.
Following the regular thinking, the expensive items were put into an PostConstruct annotated method. Upon continued invocation of the ejb or mdb, connection pool errors are continuely sent to server.log.
Scenario: MDB
The mdb receives a message on a jms queue, translates some information and then publishes to another queue. The JMS connection, session and producer 'code' is in the PostConstruct annotated method. in The onMessage method there is the translate code and sent to other queue. in the PreDestroy annotated method there is the session and connection close.
After running the bean for 30 minutes under constant load, the server.log file there is a bunch of messages identifying that 'unable to allocate connection pool: max size is equal to time out' (can't remember exact error).
Resolution: Moving the JMS Connection, Session and producer code inside the onMessage method resolved this issue. But this does not seem right.
Scenario: Remote EJB
The EJB (Client) uses EJB3 Annotation for injection of another EJB (Cart). The Cart EJB pushes messages onto JMS. In the construction of the Cart EJB it connects to a connection factory and establishs a connection. Again, after a period of time glassfish throws errors about unable to allocate more resources from the pool, max size reached. The Issue here is that another connection request to the EJB takes forever to process, one request > 5 minutes.
My current thoughts are this:
Glassfish maintains a thread pool across the jvm of size (and i am pulling numbers out of thin air) 500. Of these 500 hundred, they all try to create a 'Remote EJB'. If the connection factory used by the Cart is say 101, the 102nd thread will start throwing errors.
The root question:
When resources are injected through annotation or in an annotated PostConstruct method, why do we continually hit the max thread pool size, no matter the number is.
[Message sent by forum member 'cafletch' (cafletch)]
http://forums.java.net/jive/thread.jspa?messageID=320847