We'll give that a shot, but I think our biggest problem is the unique broker 
names between instances.  We were also able to get Tomcat to start a broker as 
a JNDI resource before the webapps start, so each web app doesn't need to 
create a local broker, they just get a JNDI resource.

The core issue is that we have a shared caching module.  This module relies on 
activemq so we can make a call to say "remove this key from your cache" and all 
servers on the activemq network get notified.  Since that common module is 
shared, all services that use it get the same Spring context files that 
configure activemq.  If we have two webapps in one Tomcat that both use the 
caching module, they both have the same configuration (even if we use external 
property files), and then they clash.  I'm trying to figure out how to use the 
common module, but get it to use a consistently unique broker name for each web 
application.  I'm following up with Spring to see if there's a way to get the 
web application name as an environment variable that we could use in the 
"brokerName" property of the Spring config.

-Ryan

-----Original Message-----
From: Stevo Slavić [mailto:[email protected]] 
Sent: Wednesday, January 12, 2011 5:39 PM
To: [email protected]
Subject: Re: Multiple webapps using VM brokers

I think I understand better your use case now, and it is different
from mine - I believe you're looking for this:
http://activemq.apache.org/shared-file-system-master-slave.html - each
app starts an embedded broker, they all use same data directory,
whichever has a lock on data directory is master, and clients (e.g.
one app producer, the other consumer of the same topic) connect to
whichever is active.

Regards,
Stevo.

2011/1/13 Shelley, Ryan <[email protected]>:
> Hey Stevo, that's so much for your quick reply... I truly appreciate it!
>
> So, our two webapps need to be sharing messaging, obviously.  One webapp puts 
> a message in queue and says "hey, clear the cache" and the other webapp has 
> to get the message and clear the cache.  If we have different broker names 
> for VM brokers, will we have issues where the messages are not in the same 
> broker and not shared, or are the broker names pretty much just for data 
> isolation but share the queues?
>
> -Ryan
>
> -----Original Message-----
> From: Stevo Slavić [mailto:[email protected]]
> Sent: Wednesday, January 12, 2011 4:53 PM
> To: [email protected]
> Subject: Re: Multiple webapps using VM brokers
>
> Hello Ryan,
>
> Beginner ActiveMQ user here as well. Had same dilemmas myself today,
> at least for the first question of yours. Came to conclusion that each
> instance has to have it's own data directory, and that we actually
> configure base data directory, so both instances can use the same one,
> but have to be given different broker name - it gets appended to the
> base data directory path so they'll both have different data directory
> within same data.
>
> Regards,
> Stevo.
>
> On Thu, Jan 13, 2011 at 1:41 AM, Shelley, Ryan <[email protected]> 
> wrote:
>> I'm pretty green to ActiveMQ, but we're diving in and trying to get it to 
>> work within our environment (ActiveMQ 5.2, Java 1.6, RHEL5).  One issue we 
>> had, and probably due to my incomplete comprehension of ActiveMQ, came about 
>> when we tried running two webapps that both used local VM brokers.  We'd get 
>> errors where one broker would hang waiting for a lock that we assume the 
>> other webapp had, or we'd get errors about a VM broker already being 
>> created.  We also tried running ActiveMQ as a WAR in Tomcat with our other 
>> webapps, but since we couldn't configure the startup order of the webapps, 
>> we had our webapps failing because the ActiveMQ webapp wasn't up yet.
>>
>>
>>
>> So, I suppose my question is multipart.  First, must the data directory for 
>> two VM brokers be different (our config file for ActiveMQ was being shared 
>> between webapps, so each VM broker shared the same URI, brokerName, data 
>> directory, etc)?
>>
>>
>>
>> Second, is there a way to make the connectivity to a broker delayed (say, 
>> until first request, like Spring's RMI config), or retry gracefully?
>>
>> Currently, if it fails connecting to a broker at startup, the entire webapp 
>> fails.  If we configure reconnect retry attempts, the webapp will block 
>> during startup, which will block loading other webapps, which may include 
>> the ActiveMQ webapp, so it eventually fails.
>>
>>
>>
>> Third, what is industry standard (or recommended) approach for setting up 
>> ActiveMQ services?  In a separate, dedicated Tomcat instance?  As the 
>> executable (through Jetty)?  As an embedded VM broker per webapp (or shared 
>> VM broker for multiple webapps)?  Some other approach?
>>
>>
>>
>> Thanks!
>>
>> Ryan Shelley
>>
>

Reply via email to