3 Replies Latest reply on Dec 15, 2006 2:49 AM by mclu

    JmsXA vs XAConnectionfactory and durable topic subscription

    mclu

      Hi out there!

      I have problems using jmsxa on a durable topic subscription.

      I am using:
      JBoss 4.0.5
      JBoss Messaging 1.0.1 GA
      JBoss EJB3 RC9

      What I need:
      Inside the Container I have a Topic where messages comes in.
      Via a EJB3 Service Pojo I instantiate Objects with its own thread which register themselves as listener via createDurableSubscriber.
      These Handlers get a message, process them somehow and put the result in an outgoing queue on the same server.
      In other words. I want to dynamically register topic listeners. There is one Listener for each remote attached server which reads its data from that outgoing queue.
      The attached Servers are stored in a database so I can read the DB and create as many subscribers as I need.

      All works fine with

      ic.lookup("java:/XAConnectionFactory");


      But I what to use the Container Transaction to be sure everything is rolled back if something went wrong from the topic to the queue. I mean, the storing to the queue must be rolled back and the receiving from the queue should be retried.
      So I changed it to
      ic.lookup("java:/JmsXA");


      But with JmsXA I receive an error when I try to set the client ID like:
      ERROR [NodeBasedRemoteSynchronizer] Failed to create connection and session
      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.jboss.resource.adapter.jms.JmsSessionFactoryImpl.setClientID(JmsSessionFactoryImpl.java:201)
       at com.XXXXX.NodeBasedRemoteSynchronizer.run(NodeBasedRemoteSynchronizer.java:130)


      removing the set clientID method results in an other error:

      Failed to create connection and session
      javax.jms.JMSException: Cannot create durable subscriber without a valid client ID
       at org.jboss.jms.server.endpoint.ServerSessionEndpoint.createConsumerDelegate(ServerSessionEndpoint.java:179)
       at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$createConsumerDelegate$aop(SessionAdvised.java:90)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
       at org.jboss.jms.server.container.SecurityAspect.handleCreateConsumerDelegate(SecurityAspect.java:116)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:130)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
       at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
       at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:127)
       at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:1008)
       at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
       at org.jboss.remoting.Client.invoke(Client.java:589)
       at org.jboss.remoting.Client.invoke(Client.java:581)
       at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:111)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_6311124154581125663.invokeNext(ClientSessionDelegate$createConsumerDelegate_6311124154581125663.java)
       at org.jboss.jms.client.container.StateCreationAspect.handleCreateConsumerDelegate(StateCreationAspect.java:122)
       at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect20.invoke(StateCreationAspect20.java)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_6311124154581125663.invokeNext(ClientSessionDelegate$createConsumerDelegate_6311124154581125663.java)
       at org.jboss.jms.client.container.ConsumerAspect.handleCreateConsumerDelegate(ConsumerAspect.java:69)
       at org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect19.invoke(ConsumerAspect19.java)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_6311124154581125663.invokeNext(ClientSessionDelegate$createConsumerDelegate_6311124154581125663.java)
       at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:182)
       at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_6311124154581125663.invokeNext(ClientSessionDelegate$createConsumerDelegate_6311124154581125663.java)
       at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_6311124154581125663.invokeNext(ClientSessionDelegate$createConsumerDelegate_6311124154581125663.java)
       at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_6311124154581125663.invokeNext(ClientSessionDelegate$createConsumerDelegate_6311124154581125663.java)
       at org.jboss.jms.client.delegate.ClientSessionDelegate.createConsumerDelegate(ClientSessionDelegate.java)
       at org.jboss.jms.client.JBossSession.createDurableSubscriber(JBossSession.java:307)
       at org.jboss.resource.adapter.jms.JmsSession.createDurableSubscriber(JmsSession.java:314)
       at com.XXXXX.NodeBasedRemoteSynchronizer.run(NodeBasedRemoteSynchronizer.java:134)



      What is the right way to handle this?
      It this a Bug?

      THX

        • 1. Re: JmsXA vs XAConnectionfactory and durable topic subscript
          timfox

          Like it says on the tin, sounds like what you're trying to do is an illegal use of the JMS JCA cf - Weston will probably be able to add more here.

          BTW, any reason why you're not just using MDBs?

          • 2. Re: JmsXA vs XAConnectionfactory and durable topic subscript
            weston.price

            Correct, the method you are invoking is reserved only for application clients and generally should not be used by other application components. However, this can be relaxed by setting the following in your *-ds.xml file for your JMS connection factory

            <config-property name="Strict">False</config-property>

            this will turn off the strict spec compliant behavior. Be forwarned however that if portablity is something you care about don't do this.

            • 3. Re: JmsXA vs XAConnectionfactory and durable topic subscript
              mclu

               

              "timfox" wrote:
              BTW, any reason why you're not just using MDBs?


              Hmm Yes!

              As I said I have a Topic where messages comes in. These must be processed and send to a queue for each connected system.
              I don't want so hardcode his so it must be self maintaining.
              My Idea: Have a service which starts or stops durable subscribers on a topic based on registered servers...
              The Order is relevant so I can only have one instance per connected Server.
              Any small hints how I can handle this with MDB? I would prefer this way because of DLQ handling and transactions...

              In the end I need a scaleable system which consumes messages from a topic and send the processed data (different for each server) to connected servers/outgoing queue (which register themself).

              One Idea is to have an MDB which handles the message for all servers, but this is not that scaleable, because the order is relevant so I only can have one MDB instance...



              "weston.price@jboss.com" wrote:
              <config-property name="Strict">False</config-property>

              Thx for this hint but I try be be spec compliant...



              /MDB consuming messages