[ataylor]

This is now fixed in trunk. It wasn't a leak as such, but there was a connection pool being created for each new connection. This was because the connection pool is based on the security subject and the connection request info and we weren't setting defaults on the connection request info we were passing to the connection pool. This meant that it always created a new pool as it thought that the connection info was different everytime.

@nbhatia You can build from trunk if you want to try this.

[nbhatia]

Well, I finally got a chance to try out the code in trunk but unfortunately something is broken. When I start JBoss AS, I now get the following exception and messaging does not work at all:

15:37:23,041 WARN [JmsActivation] Failure in jms activation
org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@3e35e156
(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@590876bf
destination=queue/order.queue
destinationType=javax.jms.Queue tx=true durable=false reconnect=10
provider=java:/DefaultJMSProvider user=null maxMessages=1 minSession=1
maxSession=15 keepAlive=60000 useDLQ=true
DLQHandler=org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler
DLQJndiName=queue/DLQ DLQUser=null DLQMaxResent=5)
javax.naming.NameNotFoundException: XAConnectionFactory not bound
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
 at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
 at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
 at javax.naming.InitialContext.lookup(InitialContext.java:392)
 at org.jboss.util.naming.Util.lookup(Util.java:222)
 at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.setupDLQConnection(AbstractDLQHandler.java:131)
 at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.setup(AbstractDLQHandler.java:83)
 at org.jboss.resource.adapter.jms.inflow.dlq.JBossMQDLQHandler.setup(JBossMQDLQHandler.java:48)
 at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupDLQ(JmsActivation.java:413)
 at org.jboss.resource.adapter.jms.inflow.JmsActivation.setup(JmsActivation.java:351)
 at org.jboss.resource.adapter.jms.inflow.JmsActivation$SetupActivation.run(JmsActivation.java:729)
 at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
 at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:619)

I switched back to BETA5 and everything works. Can you please help me identify the problem?

Thanks.

Naresh

[timfox]

Please bear in mind that we make no claims that TRUNK is stable, TRUNK is TRUNK and used at your own risk. (Actually we don't even make any claims that a beta is stable)

See http://www.jboss.org/community/wiki/HornetQSourceLocation

When someone says "it is fixed in TRUNK", that doesn't necessarily mean it's safe for you to build the whole of TRUNK and expect it to just work. In most/many cases that won't be the case

It just means the bug was fixed and will be in the next release.

If a user wants a particular bug they can look at the particular patch that was done for a certain fix and apply that directly against the code they are working from. But again, no guarantees

[timfox]

FWIW I can see from your stack trace you're not using the HornetQ Resource Adaptor - you're using the old JBoss generic RA which comes with the app server.

Andy has made changes in this area recently.

You'd need to completely re-install HornetQ. I suspect you've just copied jars over.

[nbhatia]

Oh boy, anything I said that provoked all the disclaimers? I was trying out the trunk just because Andy suggested that in his post. And when I responded with my problem, I knew it was because of my misunderstanding and was only asking for help identifying it. I really think HornetQ is a great product in the making and you guys have been giving me great support. However I do understand that there are no guarantees about trunk or even beta5 for that matter.

Getting back to the issue at hand, I performed the following steps to install HornetQ from trunk:

1) Rebuilt the trunk from scratch
2) Deleted all-with-hornetq and default-with-hornetq folders under JBOSS_HOME/server
3) Rebuilt these folders by running the ant script under HORNETQ_HOME/config/jboss-as

I do notice the new hornetq-ra.rar folder as well as the original jms-ra.rar file under JBOSS_HOME/server/default-with-hornetq. I also notice that jms-ds.xml now refers to hornetq-ra.rar in its tx-connection-factory. There are still couple of references to jms-ra.rar in ejb-deployer-jboss-beans.xml and metadata-deployer-jboss-beans.xml. Does all this sound correct? Am I missing something?

Thanks.

Naresh

[timfox]

Actually, you'd be amazed but there really are people who don't really understand what a beta is and/or expect TRUNK to work perfectly and when it doesn't demand that we fix it immediately!

I'm glad you're not one of those people ;)

[ataylor]

I do notice the new hornetq-ra.rar folder as well as the original jms-ra.rar file under JBOSS_HOME/server/default-with-hornetq. I also notice that jms-ds.xml now refers to hornetq-ra.rar in its tx-connection-factory. There are still couple of references to jms-ra.rar in ejb-deployer-jboss-beans.xml and metadata-deployer-jboss-beans.xml. Does all this sound correct? Am I missing something?

Yes, that's all correct. You will now also need the correct resource adapter set via an annotation on the MDBor via the deployment descriptor. This is explained in the docs, take a look at the docs generated via your build.

[nbhatia]

Ok, I added the @ResourceAdapter annotation to my MDB, but I am still getting javax.naming.NameNotFoundException: XAConnectionFactory not bound. Here's my code:

@MessageDriven(activationConfig={
 @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
 @ActivationConfigProperty(propertyName="destination", propertyValue="queue/myqueue")
 })
@ResourceAdapter("hornetq-ra.rar")
@Name("myListener")
public class MyListener implements MessageListener {
 ...
}

XAConnectionFactory is mentioned in hornetq-jms.xml:

<configuration xmlns="urn:hornetq"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd">

 <connection-factory name="ConnectionFactory">
 <connector-ref connector-name="netty"/>
 <entries>
 <entry name="ConnectionFactory"/>
 <entry name="XAConnectionFactory"/>
 </entries>
 </connection-factory>

 <queue name="DLQ">
 <entry name="/queue/DLQ"/>
 </queue>
 <queue name="ExpiryQueue">
 <entry name="/queue/ExpiryQueue"/>
 </queue>

 <queue name="myqueue">
 <entry name="/queue/myqueue"/>
 </queue>
</configuration>

What should I try next?

Naresh

[ataylor]

Ok, I'm not sure what you are doing here, but you shouldn't get this error from just deploying an MDB. Are you looking up a connection factory from within your MDB, if so you probably don't want to use this connection factory anyway. You will want to ue the connection factory specified in the jms-ds.xml config file so you get the benefit of pooling. This is all in the docs, btw!

[nbhatia]

Are you looking up a connection factory from within your MDB, if so you probably don't want to use this connection factory anyway.

I assume you mean a JMS connection factory. No I am not looking up a JMS connection factory. This is happening right after I deploy my EAR.

Still trying to figure out what could be different. I will post if I find something.

[nbhatia]

Ok, I did some more digging. Still getting "NameNotFoundException: XAConnectionFactory not bound" with the default configuration generated from the trunk. Looking through JBoss console, XAConnectionFactory is exposed via the Global JNDI Namespace. So I really don't know why this exception is occurring.

Anyway, as described in the docs, I renamed hornetq-ra.rar to jms-ra.rar and the NameNotFoundException went away. So I have temporarily worked around the problem.

Anyway, getting back to the original issue, the memory leak is now gone. So your fix for not creating a new connection pool for every new connection did work. Now I am trying to take the next step. If you remember, I was using the Spring MessageListenerContainer in my WAR application for receiving messages. It is this container that is creating a new connection every second and polling for JMS messages (that's what was causing the out-of-memory earlier). Now I am trying to get rid of Spring's MessageListenerContainer completely and replacing it with my own code which works directly with the JMS API. At the start of the application I create a fixed pool of JMS sessions that share a common connection. This connection is held for the life of the application. This scheme seems to work fine in a standalone client, but does not work in a WAR deployed on JBoss. I get the following exception:

Caused by: javax.jms.IllegalStateException: This method is not applicable
inside the application server. See the J2EE spec, e.g. J2EE1.4 Section 6.6
at org.hornetq.ra.HornetQRASession.checkStrict(HornetQRASession.java:1583)
at org.hornetq.ra.HornetQRAMessageConsumer.setMessageListener(HornetQRAMessageConsumer.java:315)
at org.archfirst.spring.jms.listener.MessageListenerContainer.afterPropertiesSet(MessageListenerContainer.java:55)

Reading up on the J2EE spec, it indeed does not allow the setMessageListener() call on a MessageConsumer. So I really puzzled how to use MessageListeners in a WAR application. Any thoughts? Here's my code as it stands now:

connection = connectionFactory.createConnection();

for (int i=0; i<concurrentConsumers; i++) {
 Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
 MessageConsumer messageConsumer = session.createConsumer(destination);
 messageConsumer.setMessageListener(messageListener);
}

connection.start();

Thanks.
Naresh

[timfox]

"nbhatia" wrote:
Ok, I did some more digging. Still getting "NameNotFoundException: XAConnectionFactory not bound" with the default configuration generated from the trunk. Looking through JBoss console, XAConnectionFactory is exposed via the Global JNDI Namespace. So I really don't know why this exception is occurring.

This is because you probably haven't added annotations to your MBeans telling them to use the HornetQ RA, so they'll default to using the old JMS RA and you'll get that exception.

Anyway, as described in the docs, I renamed hornetq-ra.rar to jms-ra.rar and the NameNotFoundException went away. So I have temporarily worked around the problem.

That's an alternative way of doing it, but it's a bit hacky.

Anyway, getting back to the original issue, the memory leak is now gone. So your fix for not creating a new connection pool for every new connection did work. Now I am trying to take the next step. If you remember, I was using the Spring MessageListenerContainer in my WAR application for receiving messages. It is this container that is creating a new connection every second and polling for JMS messages (that's what was causing the out-of-memory earlier). Now I am trying to get rid of Spring's MessageListenerContainer completely and replacing it with my own code which works directly with the JMS API. At the start of the application I create a fixed pool of JMS sessions that share a common connection. This connection is held for the life of the application. This scheme seems to work fine in a standalone client, but does not work in a WAR deployed on JBoss. I get the following exception:

Caused by: javax.jms.IllegalStateException: This method is not applicable
inside the application server. See the J2EE spec, e.g. J2EE1.4 Section 6.6
at org.hornetq.ra.HornetQRASession.checkStrict(HornetQRASession.java:1583)
at org.hornetq.ra.HornetQRAMessageConsumer.setMessageListener(HornetQRAMessageConsumer.java:315)
at org.archfirst.spring.jms.listener.MessageListenerContainer.afterPropertiesSet(MessageListenerContainer.java:55)

Reading up on the J2EE spec, it indeed does not allow the setMessageListener() call on a MessageConsumer. So I really puzzled how to use MessageListeners in a WAR application. Any thoughts? Here's my code as it stands now:

connection = connectionFactory.createConnection();

for (int i=0; i<concurrentConsumers; i++) {
 Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
 MessageConsumer messageConsumer = session.createConsumer(destination);
 messageConsumer.setMessageListener(messageListener);
}

connection.start();

Thanks.
Naresh

Yes indeed you can't create message listeners in a war. The mechanism the JEE provides for asynchronously consuming messages is the MDB / JCA message inflow

If you can explain what you're trying to do here in a bit more detail, would be good.

[nbhatia]

This is because you probably haven't added annotations to your MBeans telling them to use the HornetQ RA, so they'll default to using the old JMS RA and you'll get that exception.

Well, my bad. I had actually put annotations on all my MDBs but missed one somehow. Your response prompted me to check again and there it was! So problem solved. No followup needed.

Yes indeed you can't create message listeners in a war. The mechanism the JEE provides for asynchronously consuming messages is the MDB / JCA message inflow

If you can explain what you're trying to do here in a bit more detail, would be good.

Just to clarify, I have two applications, one packaged as EAR and uses MDBs (this is the one described above where I had missed an annotation.) The other application is packaged as a WAR - its a simple web application that accepts orders from multiple applications via JMS and processes them. It also has a web front-end that allows administration of orders. It is this application where I am trying to receive JMS messages asynchronously and attempted to use MessageListeners. Is there any other way to do this synchronously aside from converting the application to an EAR and using MDBs? In no, then this seems to be a major limitation of the J2EE spec.

Thanks.

Naresh

[nbhatia]

Is there any other way to do this synchronously aside from converting the application to an EAR and using MDBs

Sorry I meant asynchronously here.

[timfox]

No, I still don't get it.

You want to create a new message listener every time a web request comes in? Why? (That seems very odd) Can you be more specific about the use case?

Like I mentioned before JEE has a mechanism for asynchronous processing of messages - they're called MDBs