users@glassfish.java.net

Re: Running out of JMS Connections

From: Sivakumar Thyagarajan <Sivakumar.Thyagarajan_at_Sun.COM>
Date: Tue, 24 Jul 2007 11:25:51 +0530

Hi

> Version info first: Sun Java System Application Server Platform Edition 9.1
> (build b19) ...
Could you try with a later build?

Could you provide us more info, like any exceptions you see in the server.log,
connection pool details of the JMS CF, any errors in broker.log [available under
domains/{domain}/imq/instances/imqbroker/log/log.txt]?

The code snippet looks fine. You might want to add a MessageProducer.close, a
try/catch on session close and finally close connection to take care of session
close errors.

You might also want to enable connection leak tracing to check if any other
component using the CF is leaking connections.
http://blogs.sun.com/kshitiz/entry/connection_leak_tracing

> So, can someone shed some light on JMS Connections or what I'm doing wrong?
> Why does it suck up so many connections when I do several messages in a
> single transaction? Why does it suck up so many connections when the message
> send itself is within its own transaction? Why does it matter how long the
> MDB takes to process a message when it comes to filling up the JMS connection
> pool?

Ideally the MDB should not affect the outbound JMS Connection factories. Could
you share the deployment descriptors of the MDB?

Thanks
--Siva.


glassfish_at_javadesktop.org wrote:
> Version info first: Sun Java System Application Server Platform Edition 9.1 (build b19) ...
>
> Mac OS X 10.4 , Java 1.5
>
> To put it simply, I'm running out of JMS connections when trying to queue up a bunch of messages.
>
> I do not understand why this is happening.
>
> Here's the gist of the error:
>
> Caused by: com.sun.enterprise.resource.PoolingException: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.
>
> The message is quite clear -- connection pool is full.
>
> The question is why.
>
> Here's the connection and message send code:
> [code]
> private void sendJMSMessageToSearchMDB(Serializable messageData) throws NamingException, JMSException {
> Connection connection = null;
> Session session = null;
> try {
> connection = searchMDBFactory.createConnection();
> session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
> MessageProducer messageProducer = session.createProducer(searchMDB);
> messageProducer.send(createJMSMessageForSearchMDB(session, messageData));
> } finally {
> if (session != null) {
> session.close();
> }
> if (connection != null) {
> connection.close();
> }
> }
> }
> [/code]
>
> Astute observers will notice that this is the generated code from NetBeans 5.5. This looks pretty straightforward to me.
>
> I was thinking that perhaps I was running in to the connection limit because I was calling this several times within a single transaction.
>
> I'm calling that routine from a simple SessionBean facade (the code itself is also within the same Session Bean).
>
> I tried adding the REQUIRES_NEW annotation to the Session Bean method.
>
> [code]
> @TransactionAttribute(value=TransactionAttributeType.REQUIRES_NEW)
> public void submitIndexRequest(IndexRequest request) {
> try {
> sendJMSMessageToSearchMDB(request);
> } catch (JMSException ex) {
> log.severe("Error during submitIndexRequest.", ex);
> } catch (NamingException ex) {
> log.severe("Error during submitIndexRequest.", ex);
> }
> }
> [/code]
>
> The hope was that the commit of the queue submit would free up the connection.
>
> Also note, when the MDB doesn't actually do anything, this seems to work fine (since the MDB returns essentially immediately). This only crops up when the MDB actually needs to do some work.
>
> Oh, important detail:
> [code]
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 EJB 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-ejb-jar_3_0-0.dtd">
> <sun-ejb-jar>
> <enterprise-beans>
> <ejb>
> <ejb-name>SearchMDB</ejb-name>
> <bean-pool>
> <steady-pool-size>1</steady-pool-size>
> <max-pool-size>1</max-pool-size>
> </bean-pool>
> </ejb>
> </enterprise-beans>
> </sun-ejb-jar>
> [/code]
>
> This intent is that I only have one MDB to service the queue. I only want one of these to be running at a time.
>
> So, can someone shed some light on JMS Connections or what I'm doing wrong? Why does it suck up so many connections when I do several messages in a single transaction? Why does it suck up so many connections when the message send itself is within its own transaction? Why does it matter how long the MDB takes to process a message when it comes to filling up the JMS connection pool?
>
> Thanx!
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=227863
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>