activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janylj <>
Subject Re: ActiveMQ and JNDI provider
Date Tue, 10 Feb 2009 18:14:11 GMT

I don't quite understand the solution described by Jonnie. I just asked a
similar post about JNDI. I thought JNDI support provided by ActiveMQ is not
suitable for production or failover case. First, because the JMS
Administered Objects are defined in the in the client side
instead of ActiveMQ server side. For example, 

java.naming.factory.initial =

# use the following property to configure the default connector
java.naming.provider.url = tcp://someIP:61616

# use the following property to specify the JNDI name the connection factory
# should appear as. 
connectionFactoryNames = connectionFactory, queueConnectionFactory,

# register some queues in JNDI using the form
# queue.[jndiName] = [physicalName]
queue.MyQueue = example.MyQueue

# register some topics in JNDI using the form
# topic.[jndiName] = [physicalName]
topic.MyTopic = example.MyTopic

The other client who wants to access JNDI name [MyQueue] needs to have the
same settings in its own When the ActiveMQ
(tcp://someIP:61616) fails, the ActiveMQ JNDI fails also. The ActiveMQ
server could fail over to the slave, does the JNDI provider fails over to
the slave ActiveMQ as well?

If just use an external LDAP server, LDAP server itself could be HA so that
the naming service is always available. I don't know whether there is any
impact of the JMS Administered Objects stored at LDAP. I image the
ConnectionFactory would be fine as long as it uses failover URI. The
destination doesn't depend on any broker, does it?

My 2 cents.


sweetjonnie wrote:
> gregory.guibert wrote:
>> Thank you for the link on OpenDS, it looks great and seems to solve half
>> my
>> problem (alignment of data) :-)
>> ...
>> When using a file to create an initial context, the file
>> looks like this:
>> java.naming.factory.initial = com.sun.jndi.ldap.LdapCtxFactory
>> java.naming.provider.url=ldap://host1:10389/ou=adminobjects,o=amq,dc=example,dc=com
>> The same way ActiveMQ manages the failover mechanism, do you know if it
>> is
>> possible to define the OpenDS servers addresses in a single
>> file ? I did not find anything about this on the Sun Website.
> I think it solved the problem of mutable persistence state accessible by
> The alignment of data seems to be more difficult, however. it appears that
> you have one LDAP server per Message Queue. At each node, your LDAP server
> knows only the JMS Administered Objects associated with that Message
> Queue. This is indeed alignment.
> The problem with this arrangement is that it appears to require that the
> client have understanding of the correct LDAP server to direct requests
> against (the same one that is associated with the "current" ActiveMQ
> server). If the client can know this, then it doesn't appear to be a
> problem. But, I don't believe that the client can know this. If this is
> correct, then this is where we lose alignment.
> Provided that your code can know of the current ActiveMQ server
> (preferably in an event based fashion), then this piece of code can always
> request the JMS Administered Objects from the LDAP server (or ActiveMQ
> JNDI server) associated with the current ActiveMQ server and rebind these
> objects in yet another LDAP server (one that is situated "in front" of the
> others and to which all client requests are directed). Unfortunately, you
> still have a window between the the time when the "switch" from the last
> current MQ to the new current MQ occurs and the repopulation of the client
> facing LDAP server occurs. It is within this window that bad things can
> happen.
> I wanted to discuss this with you as much as possible because it is
> interesting, but I am afraid that I don't know nearly enough about
> fail-over to really add anything. Certainly, I welcome additional notes
> concerning this experiment.
> Sincerely,
> jonnie savell

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message