You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by um...@comcast.net on 2007/06/18 04:03:01 UTC

Sharing embedded broker across webapp contexts

I am using activemq 4.1.1 on JDK6 with Tomcat 5.5.x.

I have a couple of webapp contexts in a servlet container that use activemq broker.
I have been using an external broker but would like to embed the broker in the
servlet container. I have the following questions.

1) Assume I have webapps A and B. Is it necessary that only one of the two webapps
   assume the responsibility of starting the broker? I mean, I would like to embed the
  starting of the broker in a jarfile that is shared by both the webapps. Its hence easy for me
  to keep the jarfile agnostic to which webapp its operating in and execute the broker start code
  at context startup.

  Stated simply, would this sequence cause two different brokers to attempt to start?
Should I build mechanisms to make sure the broker.start() is executed only once?

     Webapp A:
            context load { // Time t
                 Broker broker = new broker("tcp://localhost:61616"); //pseudocode
                 broker.start();
            }

        Webapp B:
            context load { // Time t + 5
                 Broker broker = new broker("tcp://localhost:61616"); //pseudocode
                 broker.start();
            }
                 
2) Assume webapp A starts the broker. Also, let's say Class X is defined in a jarfile
  common to both the webapps.

   Would this cause class cast exception if webapp B received an instance of class X
   from the broker? (since I assume the broker would use the webapp A classloader
   to load class X)?

   If so how do I avoid this class loading issue? Do I need to place the activemq jarfiles
   as well as the application jarfiles which contains classes of the messages dispatched
   over activemq to be in a shared system classpath common to both the webapp contexts?

3) In a setup such as this where multiple webapps share the same embedded broker,
   is it mandatory that they use an external broker?
    
    What are the other gotchas in using the embedded broker in this fashion?

Regards

/U

Re: Sharing embedded broker across webapp contexts

Posted by Mario Siegenthaler <ma...@gmail.com>.
I think the easiest way would be to use a broker that is started by
tomcat. This can be done using JNDI-configurations in the tomcats
server.xml (see http://activemq.apache.org/tomcat.html).
To connect to the broker you can either get the connection-factory via
JNDI (standard way) or just make a new ActiveMQ connection factory
pointing to vm://localhost (or whatever you named your broker).
You'll need to put the active-mq jar into the common/lib (or into the
server/lib if you only use jms-api functions and have the jms api with
common/lib) of your tomcat. Also you have to make sure that you don't
include a jms-api or activemq-jar in your war as that would cause the
feared ClassCastException.

If you don't like the way I described above then you can also just put
the AMQ-jar in the common/lib (and not in any of the webapps) and
create the connection factory in each webapp for vm://localhost. This
will bring up a broker if there isn't already one running, so I
doesn't matter which webapp starts first. You'll not need any special
setup code. However I'm not sure where I'd put the activemq.xml
configuration file in that case.

However I'd strongly recommend the first proposal, since it seems more
controllable and easier to configure.

To your point 2: The class is serialized when it's passed around by
the broker (except you turn it off, of course only possible in the
vm-protocol). So you'll just have to make sure the thing is compatible
and you can put the jar X's in into both webapps and you don't need it
to put into common/lib.

3) No, I don't see any (technical) reason. However I'd recommend to
'inject' the connection factory into the webapp, so the webapp is
completely agnostic to whether the broker is embedded or not. Else
you'll have more trouble moving them around.

Mario

On 6/18/07, uma_rk@comcast.net <um...@comcast.net> wrote:
>
> I am using activemq 4.1.1 on JDK6 with Tomcat 5.5.x.
>
> I have a couple of webapp contexts in a servlet container that use activemq broker.
> I have been using an external broker but would like to embed the broker in the
> servlet container. I have the following questions.
>
> 1) Assume I have webapps A and B. Is it necessary that only one of the two webapps
>    assume the responsibility of starting the broker? I mean, I would like to embed the
>   starting of the broker in a jarfile that is shared by both the webapps. Its hence easy for me
>   to keep the jarfile agnostic to which webapp its operating in and execute the broker start code
>   at context startup.
>
>   Stated simply, would this sequence cause two different brokers to attempt to start?
> Should I build mechanisms to make sure the broker.start() is executed only once?
>
>      Webapp A:
>             context load { // Time t
>                  Broker broker = new broker("tcp://localhost:61616"); //pseudocode
>                  broker.start();
>             }
>
>         Webapp B:
>             context load { // Time t + 5
>                  Broker broker = new broker("tcp://localhost:61616"); //pseudocode
>                  broker.start();
>             }
>
> 2) Assume webapp A starts the broker. Also, let's say Class X is defined in a jarfile
>   common to both the webapps.
>
>    Would this cause class cast exception if webapp B received an instance of class X
>    from the broker? (since I assume the broker would use the webapp A classloader
>    to load class X)?
>
>    If so how do I avoid this class loading issue? Do I need to place the activemq jarfiles
>    as well as the application jarfiles which contains classes of the messages dispatched
>    over activemq to be in a shared system classpath common to both the webapp contexts?
>
> 3) In a setup such as this where multiple webapps share the same embedded broker,
>    is it mandatory that they use an external broker?
>
>     What are the other gotchas in using the embedded broker in this fashion?
>
> Regards
>
> /U
>