Hello GF users,
running into an issue with shared durable subscriptions
have the following fairly simple situation:
2 projects: I have a simple mavenized war project that only contains 2 MDBs, 1 looks like:
@MessageDriven(name = "testMDB", mappedName = "jms/ExampleTopic", activationConfig = { @ActivationConfigProperty(propertyName = "subscriptionName", propertyValue = "examplesub"), @ActivationConfigProperty(propertyName = "clientID", propertyValue = "exampleID1"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"), @ActivationConfigProperty(propertyName = "subscriptionDurability", propertyValue = "Durable"), }) public class MDBTest implements MessageListener { @Override public void onMessage(Message message) { System.out.println("RX1: " + message.toString()); } }
the other looks like so:
@MessageDriven(name = "testMDB2", mappedName = "jms/ExampleTopic", activationConfig = { @ActivationConfigProperty(propertyName = "subscriptionName", propertyValue = "examplesub"), @ActivationConfigProperty(propertyName = "clientID", propertyValue = "exampleID2"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"), @ActivationConfigProperty(propertyName = "subscriptionDurability", propertyValue = "Durable"), }) public class MDBTest2 implements MessageListener { @Override public void onMessage(Message message) { System.out.println("RX2: " + message.toString()); } }
I have a JMS connection factory setup to point to a local broker - it is called jms/ExampleTopic.
I also have a cluster with 2 nodes setup in Glassfish for which I deploy to and target while deploying my war.
The other project is a simple command line jar that acts as a test publisher, here's a snippet of the code block (note that now I have contants for many of the properties):
TopicConnection topicConnection = null; TopicPublisher topicPublisher = null; Topic topic = null; TopicSession topicSession = null; com.sun.messaging.TopicConnectionFactory topicConnectionFactory = null;
topicConnectionFactory = new com.sun.messaging.TopicConnectionFactory(); topicConnectionFactory.setProperty(com.sun.messaging.ConnectionConfiguration.imqAddressList, ADDR); topicConnectionFactory.setProperty(com.sun.messaging.ConnectionConfiguration.imqReconnectEnabled, "true"); topicConnectionFactory.setProperty(com.sun.messaging.ConnectionConfiguration.imqAddressListBehavior, "RANDOM"); topicConnectionFactory.setProperty(com.sun.messaging.ConnectionConfiguration.imqDefaultUsername, "test_user"); topicConnectionFactory.setProperty(com.sun.messaging.ConnectionConfiguration.imqDefaultPassword, "test_user");
try { // create topic connection and pass over the client id topicConnection = topicConnectionFactory.createTopicConnection();
// not transacted, do auto acknowledge topicSession = topicConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE); topic = new com.sun.messaging.Topic(TOPIC); topicPublisher = topicSession.createPublisher(topic);
topicConnection.start();
TextMessage msg = topicSession.createTextMessage(); msg.setText(TX);
topicPublisher.send(msg);
} finally { if (topicConnection != null) { topicConnection.stop(); topicConnection.close(); } } }
Fairly straight-forward - just posting a text message to the jms/ExampleTopic topic.
When I attempt to deploy the WAR project with the 2 MDBs outlined above I get the following exception:
Exception while loading the app : EJB Container initialization error java.lang.Exception at com.sun.enterprise.connectors.inbound.ConnectorMessageBeanClient.setup(ConnectorMessageBeanClient.java:233) at com.sun.ejb.containers.MessageBeanContainer.<init>(MessageBeanContainer.java:205) at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:121) at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230) at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:305) at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:108) at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:264) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.InstanceDeployCommand.execute(InstanceDeployCommand.java:187) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1066) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:745)
Caused by: javax.resource.NotSupportedException: MQRA:EC:Error:createRemoteMessageConsumer failed:aborting due to:[C4052]: Client ID is already in use - exampleID1 user=test_user, broker=BROKER-ADDRESS(44245) at com.sun.messaging.jms.ra.EndpointConsumer.createRemoteMessageConsumer(EndpointConsumer.java:478) at com.sun.messaging.jms.ra.EndpointConsumer._init(EndpointConsumer.java:308) at com.sun.messaging.jms.ra.EndpointConsumer.<init>(EndpointConsumer.java:185) at com.sun.messaging.jms.ra.ResourceAdapter.endpointActivation(ResourceAdapter.java:478) at com.sun.enterprise.connectors.inbound.ConnectorMessageBeanClient.setup(ConnectorMessageBeanClient.java:225) ... 36 more
Caused by: com.sun.messaging.jms.InvalidClientIDException: [C4052]: Client ID is already in use - exampleID1 user=test_user, broker=BROKER-ADDRESS(44245) at com.sun.messaging.jmq.jmsclient.ProtocolHandler.setClientID(ProtocolHandler.java:2179) at com.sun.messaging.jmq.jmsclient.ConnectionImpl.setClientID(ConnectionImpl.java:1932) at com.sun.messaging.jms.ra.EndpointConsumer.createRemoteMessageConsumer(EndpointConsumer.java:462) ... 40 more
Please excuse the BROKER-ADDRESS substitution....
NOTES:> This setup DOES WORK if there is only 1 node in the cluser> I made sure to purge dur and destroy dur the broker BEFORE deploying the WAR.> The result is the same if I have just 1 MDB instead of 2> I'm experiencing this on Glassfish 3.1.2.2, GF 4.0 b89 and GF 4.1 b13:
I thought as long as useSharedSubscriptionInClusteredContainer=true (by default) that you should be able to do this. I also attempted to set that property manually on the connection factory itself - also same result.
As you can see, the publisher does not specify a client ID either - so I'm guessing the broker is having issues with the fact that there are mutliple copies of the MDB - being clustered.
Any advice on this?