JBossDeveloper

I followed the instructions posted by conora & pcallies, but when I tried to deploy a MDB (JBoss 3.0.0beta), I got the following error. I'm wondering if extra step is required to bind QueueConnectionFactory??

10:00:56,719 INFO [EJBDeployer] Deploying test.ejb.Queue
10:00:59,383 ERROR [HAJNDI] lookupLocally failed for QueueConnectionFactory
javax.naming.NameNotFoundException: QueueConnectionFactory not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:495)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:503)
at org.jnp.server.NamingServer.getObject(NamingServer.java:509)
at org.jnp.server.NamingServer.lookup(NamingServer.java:282)
at org.jboss.ha.jndi.HAJNDI.lookupLocally(HAJNDI.java:230)
at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:174)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:178)
at $Proxy9.lookup(Unknown Source)
...

My jboss.xml looks like this:


<enterprise-beans>
<message-driven>
<ejb-name>test.ejb.Queue</ejb-name>
<destination-jndi-name>RequestQueue</destination-jndi-name>
<resource-ref>
<res-ref-name>jms/QCF</res-ref-name>
<jndi-name>external/fs/QueueConnectionFactory</jndi-name>
</resource-ref>
</message-driven>
</enterprise-beans>
<resource-managers>
</resource-managers>

conora, thanks for posting the details on how to get around JBoss's insistence on prepending "queue/" to the queue name. I knew there had to be a better way than what I was doing.

If you defined your JNDI repository as an external context, why did you need to create a custom adapter? The default adapter should work fine.

Have you run into any memory-leak problems with MQSeries and JBoss working together? We're experiencing all kinds of problems with HP-AS and MQSeries, but HP-AS and JBoss works fine.

Not had any problems so far (althought it is mostly proof of concept stuff at the minute) - although it seemed to me that all I was doing when creating a custom JMS provider for MQSeries was redefining the initial context factory class - and that was just held as a string. Seemed wasteful to me. Anyway I must be missing something here - did I not need to create a custom loader for MQSeries?

Maybe I'll just have a look at the code before I embarass myself too much.

Conor

OK,

I've had a look and it is not necessary to create a custom MQSeries provider - however it is really a hack - mostly because of jboss insists on placing queues under a queue subcontext.

If this was not the case no work around would be necessary.

Anyway - I just created another extenral context which was bound under queue


queue
external.fs.queue.props
javax.naming.InitialContext


and the file external.fs.queue.props contained the following

java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory
java.naming.provider.url=file:///env2/eb20rel1/jndiRoot/queue

I'm sure that this would be better done with a jndi alias which I believe jboss jndi supports, however I've not looked at that yet.

(Oh, and I've changed the provider back to the JBossMQProvider in the provider loader MBean)

Conor

I've looked at the Naming alias stuff and the second external context is not necessary - here is the config for the Naming alias


external/fs/queue/RequestQueue
queue/RequestQueue



external/fs/queue/ReplyQueue
queue/ReplyQueue


Enjoy

Conor

What version of JBoss are you running? I'm getting the following exception in the 3.0 code I checked out last night. It looks like it's assuming that whatever is passed to it is of a SpyDestination type.

java.lang.ClassCastException: com.ibm.mq.jms.MQQueue
at org.jboss.mq.SpyConnectionConsumer.(SpyConnectionConsumer.java:69)
at org.jboss.mq.SpyConnection.createConnectionConsumer(SpyConnection.java:112)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerCreate(JMSContainerInvoker.java:584)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.create(JMSContainerInvoker.java:415)
at org.jboss.ejb.MessageDrivenContainer.create(MessageDrivenContainer.java:168)
at org.jboss.ejb.Container.invoke(Container.java:766)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:447)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:805)
at $Proxy1.create(Unknown Source)
at org.jboss.system.ServiceController.create(ServiceController.java:239)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:447)
at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy25.create(Unknown Source)
at org.jboss.ejb.EjbModule.createService(EjbModule.java:348)
at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:447)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:805)
at $Proxy1.create(Unknown Source)
at org.jboss.system.ServiceController.create(ServiceController.java:239)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:447)
at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.create(Unknown Source)
at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:372)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:633)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:516)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:480)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:447)
at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:329)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:439)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:202)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:191)

Sorry it took a while to reply

I'm using version JBoss 2.4.3 and MQSeries 5.1.

Also, I disabled the JBossMQ mbean - it it possible that there is some interaction going on between JbossMQ and MQSeries as JMS Providers?

If jboss (in 2.4.3) does not find a queue it creates one in the JBossMQ implementation. Have a look at your server.log - Also having a look using the JNDIView of your server might reval something - you usually get at it on http://localhost:8082 and looking for the JNDIView mbean - and then select the list button on the page that is loaded.

Let me know how you get on.

Conor

I did finally get this running with MQSeries 5.2.1 CSD04 with the latest MA88 support pack and JBoss 2.4.4. However, it seems like JBoss gets lost with a high volume of messages.

I've got a queue loaded with thousands of messages. I was getting a NullPointerException after a small, but variable number of messages. It looked like the JBoss implementations of ServerSession and ServerSessionPool are passing ServerSessions with null JMS sessions to the ConnectionConsumer.

Now, the MDB just stops processing messages after a small, but variable number of messages.

I don't have time to dig through this and fix it so I'll probably not recommend JBoss for MDBs -- bummer.

Hmm,

I'll see if I can recreate this in my environment - I'd like to get a definitive view on which component is responsible. If you do any more work on this I'd be interested.

I'll let you know what I find.

Conor

Well, it might be a bug there, but it has never showed up on other occasions. My guesss is that it is your provider that are gining out null sessions, and then can't handle what i self gave out.

Contribute improvment, then you can start yelling, otherwise just shut up.

//Peter

I was not complaining - I just want to understand what is happening.

Conor

Ditto. I don't think I was complaining. I was just making an observation.

I've tried to contribute constructively via this forum. I've checked out the code (2.4.4 and 3.0), tried some changes, and offered suggestions/feedback.

In this instance, Conor and I have been trying to contribute improvement. We're two developers who like JBoss. We're also two of many who need to accomodate MQSeries since it is the MOM system with the largest install base. We're trying to figure out how to get JBoss and MQSeries to like each other.

I clearly said that I don't have time to explore this right now. If I did have time, I'd do what I've done in the past and dig into the code. I was trying to let Conor know where I ran into problems so he could continue trying to contribute improvment. This is an open-source project that touts the advantages of being able to leverage an endless supply of developers. You need to let us communicate if you want us to contribute.

Sincerely without intending to start a flame war.

-Peter (nice name, eh?)

Shure, I also have to admit that this is possibly the best thread in the JMS forum history, in that there are actuall users trying to help each other. Thats great. I just happens to be the one that implemented (the first cut at least) the MDB container, and sort of does not want to be called bummer. Eveything else is nice and dandy ;-)

//Peter

Well, I don't know how good it really is but here is a ContainterInvoker that I did so that it would work with MQSeries..

Thanks, Hiram. I'll try to make time to check it out this weekend...if my wife doesn't come up with too many chores. ;-)