8 Replies Latest reply on Oct 23, 2006 7:21 AM by fhh

    SonicMQ and JBossMQ on one AppServer

      I have configured JBoss 4.0.4.GA to use SOnicMQ laong with the preinstalled JBossMQ. This works fine for sending beans to SonicMQ.
      However, I get an AbstractMethodError when trying to have an MDB listen to a remote Sonic Queue. The configuration of the bean is:

      @MessageDriven(activationConfig =
      {
       @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
       @ActivationConfigProperty(propertyName="destination", propertyValue="queue/incoming"),
       @ActivationConfigProperty(propertyName="providerAdapterJNDI", propertyValue="java:/SonicMQJMSProvider")
      })
      


      This throws an AbstractMethodException in JmsServerSession.setup(). Does anybody know what this means. Or in generally what an AbstractMethodException is?


      Regards

      fhh



      17:26:25,437 ERROR [JmsActivation] Unable to reconnect org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@149e5ef(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@411379 destination=queue/incoming isTopic=false tx=true durable=false reconnect=10 provider=java:/SonicMQJMSProvider 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=0)
      java.lang.AbstractMethodError: progress.message.jimpl.QueueConnection.createSession(ZI)Ljavax/jms/Session;
      at org.jboss.resource.adapter.jms.inflow.JmsServerSession.setup(JmsServerSession.java:115)
      at org.jboss.resource.adapter.jms.inflow.JmsServerSessionPool.setupSessions(JmsServerSessionPool.java:206)
      at org.jboss.resource.adapter.jms.inflow.JmsServerSessionPool.start(JmsServerSessionPool.java:102)
      at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupSessionPool(JmsActivation.java:540)
      at org.jboss.resource.adapter.jms.inflow.JmsActivation.setup(JmsActivation.java:313)
      at org.jboss.resource.adapter.jms.inflow.JmsActivation.handleFailure(JmsActivation.java:250)
      at org.jboss.resource.adapter.jms.inflow.JmsActivation$SetupActivation.run(JmsActivation.java:593)
      at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
      at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
      at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
      at java.lang.Thread.run(Thread.java:595)


        • 1. Re: SonicMQ and JBossMQ on one AppServer

          Replying to myself:

          It seems that this due to the fact that the SonicMQ-Version (5.0.1) we are using only supports JMS 1.0.x not 1.1.

          Does JBoss rely on JMS 1.1?

          Regards

          fhh

          • 2. Re: SonicMQ and JBossMQ on one AppServer
            genman

            Seems like 1.1 only.

            As a work around, you might be able to bind local JNDI instances of QueueConnection/etc. that delegate to the remote JNDI objects.

            Or simply edit the source for JmsServerSession to call either createQueueSession or createTopicSession depending on the type of connection. This might be patch-worthy if it allows JBoss to use old JMS 1.0 providers.

            • 3. Re: SonicMQ and JBossMQ on one AppServer

              Thanks for your reply.


              As a work around, you might be able to bind local JNDI instances of QueueConnection/etc. that delegate to the remote JNDI objects.


              This is a route I would rather not go as it would require to disable most of the existing security features.

              Or simply edit the source for JmsServerSession to call either createQueueSession or createTopicSession depending on the type of connection. This might be patch-worthy if it allows JBoss to use old JMS 1.0 providers.


              I could deliver such a patch. The problem I see is that there might more JMS1.1-ism lurking in the code. What would be my best option to find those?

              Is it sufficient if I can build everything under org.jboss.resource.adapter.jms.* against javax.jms.* version 1.0.2? Or are there other suspicious packages?

              Regards

              fhh


              • 4. Re: SonicMQ and JBossMQ on one AppServer

                Have you looked at SonicMQ's JMS/JCA adapter? Typically this is the route people use for integrating with the Sonice provider.

                • 5. Re: SonicMQ and JBossMQ on one AppServer

                  I'm not sure but I don't think JCA is an option. I thing the JCA support may be available on for 6.1 and later. There is very little documentation out there on the 5.0.1 version.

                  Even if there was a JCA-Adapter I'm not sure about the licensing. Currently we only have a license for the client libs. I'm not sure if the JCA would be covered by that.

                  Regards

                  fhh

                  • 6. Re: SonicMQ and JBossMQ on one AppServer

                    Have you tried using the JMSContainerInvoker for your integration, rather than the JBoss/JCA adapter. I don't have a copy of Sonic, so, I really can't try and determine the underlying cause of the problem. I just wanted to try an alternate appropach in the interim.

                    • 7. Re: SonicMQ and JBossMQ on one AppServer
                      weston.price

                      Also, what VM version are you using?

                      • 8. Re: SonicMQ and JBossMQ on one AppServer

                        Hello!

                        Thanks for the replies!

                        1.) I use the Sonic glue classes from their web site. Not sure which technique these use but in theory these work fine. The only problem is that the (rather old) SonicMQ version 5.0.1 classes are JMS 1.0.2 only and the stuff under org.jboss.resource.adapter.jms.* relies on JMS 1.1 in JBossAS 4.0.x.

                        This explains the exception very well: The adapter classes are linked against javax.jms.Connection v 1.1, but progress.message.jimpl.QueueConnection implements only 1.0.2 of the interface. Therefore the createSession method ist not implemented and hence abstract.

                        To fix the lack of the unified model is pretty trivial. There are about 30 errors in the code, almost all of which can be fixed by if-instanceofs. But there are also a few more tricky issues - namely the missing methods that do not have an equivalent in JMS 1.0.2.

                        Maybe the best approach will be to avoid calling these internally and throw a NotAvailableInJMS102 exception if these are called from outside. This would mean the offending classes would still have to be linked against 1.1.

                        I do not need any fancy stuff like XASessions because the migration to SonicMQ is planned for next year and I can do without till then. So an exception would be absolutely acceptable to me.

                        2.) I use a recent version of Sun's Java 1.5.0. Don't know which as I am not in office.

                        Regards

                        fhh