Ah, yeah, looks like it may not have been fixed for XBeanBrokerService (which is what we're doing). Thanks for those links!
-----Original Message----- From: Stevo Slavić [mailto:[email protected]] Sent: Wednesday, January 12, 2011 5:50 PM To: [email protected] Subject: Re: Multiple webapps using VM brokers If I understood well, embedded broker startup (brokers waiting to get a lock on file system) should already be async, not blocking web app startup: http://activemq.2283324.n4.nabble.com/Non-blocking-embedded-broker-startup-when-using-jdbc-master-slave-setup-td2364841.html https://issues.apache.org/jira/browse/AMQ-1519 Regards, Stevo. 2011/1/13 Stevo Slavić <[email protected]>: > 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 >>> >> >
