Hide Forgot
Created attachment 922030 [details] DuplicateJNDI.java Description of problem: HornetQ allows duplicate JNDI entries when they're create using HornetQ's management API Version-Release number of selected component (if applicable): JBoss-EAP-6.2_CP4 aka JBoss-EAP-6.2.4 How reproducible: Steps to Reproduce: 1. Enable "jmx-management-enabled" attribute to "true" in the broker configuration : .... <jmx-management-enabled>true</jmx-management-enabled> .... 2. Please define a destination in the configuration file : queue/A : .... <jms-queue name="A"> <entry name="queue/A"/> <entry name="java:jboss/exported/jms/queue/A"/> </jms-queue> .... 3. Please start the server 4. Please try to add duplicate JNDI entries using HornetQ's management API : .... JMSQueueControl jmsQueueControl = (JMSQueueControl) MBeanServerInvocationHandler.newProxyInstance(connection, objectName, JMSQueueControl.class, false); jmsQueueControl.addJNDI("my/queue/A"); jmsQueueControl.addJNDI("my/queue/A"); jmsQueueControl.addJNDI("my/queue/A"); jmsQueueControl.addJNDI("my/queue/A"); .... Actual results: The JMS broker allows creating duplicate JNDI entries Expected results: The JMS broker needs to throw an exception at a duplicate JNDI entry creation. Additional info: This bug does not have an impact on the behaviour of the JMS broker. That said, it is causing an inconvenience when displaying the list of available JNDI entries on JConsole for a given destination, if the destination has multiple unique JNDI entries for varies JMS clients.
Clebert pointed me to this JIRA so I started investigating this behavior in HornetQ 2.3.x. The code that prevents duplicate JNDI entries on the master branch is indeed present in 2.3.x. In fact, HornetQ standalone won't allow duplicate JNDI entries for queues. I was puzzled by this so I reproduced the behavior in EAP 6.3 and I saw the problem that Ty describes. The issue appears to be with the integration between HornetQ and EAP in the messaging subsystem, specifically the fact that org.jboss.as.messaging.jms.AS7BindingRegistry#lookup always returns null. This method is used by org.hornetq.jms.server.impl.JMSServerManagerImpl#checkJNDI to ensure that no duplicates exist. Jeff, can you have a look at this?
Justin, you're right, AS7BindingRegistry#lookup always returns null and this can be fixed. Tyronne, please be reminded again that the HornetQ MBeans are *not* integrated with EAP and should not be used to manage a HornetQ server integrated. Any JNDI entries added or removed using the HornetQ MBeans will *not* be taken into account if the application server is reloaded. The correct way is to use the EAP face MBeans (under the jboss.as:subsystem=messaging namespace) to add and remove JNDI entries. With those, the subsystem will check if there are any duplicates *and* persist any configuration changes.
Tested with 6.4.0.DR9. Bug is still unfixed. User can add already existing queue via jmx-management without getting exception.
How did you manage to reproduce the issue? If I follow the steps to reproduce, at step 4, I have the expected exception when I add the "my/queue/A" a second time in jconsole: Problem invoking addJNDI: javax.naming.NamingException: my/queue/A already has an object bound.
Yes , you are right. I was doing reproducer wrongly in my automated test.