Bug 1124178

Summary: jmsQueueControl.addJNDI(String jndiName) method allows duplicate JNDI entry creation
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Tyronne Wickramarathne <tywickra>
Component: JMSAssignee: Jeff Mesnil <jmesnil>
Status: CLOSED CURRENTRELEASE QA Contact: Miroslav Novak <mnovak>
Severity: high Docs Contact:
Priority: urgent    
Version: 6.2.4CC: dandread, jbertram, jmesnil, kkhan, msvehla, myarboro
Target Milestone: DR9   
Target Release: EAP 6.4.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
DuplicateJNDI.java none

Description Tyronne Wickramarathne 2014-07-29 06:16:11 UTC
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.

Comment 3 Justin Bertram 2014-09-10 15:51:23 UTC
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?

Comment 4 Jeff Mesnil 2014-09-11 07:16:37 UTC
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.

Comment 6 Ondřej Kalman 2014-11-18 07:39:15 UTC
Tested with 6.4.0.DR9. Bug is still unfixed.  User can add already existing queue via jmx-management without getting exception.

Comment 7 Jeff Mesnil 2014-11-18 09:54:01 UTC
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.

Comment 8 Ondřej Kalman 2014-11-18 11:25:13 UTC
Yes , you are right. I was doing reproducer wrongly in my automated test.