Hi , 
      I also have two web apps running in Tomcat 5.5.20.Active mq
version being used is 4.0.2.
Our application uses an embedded broker, This broker is started by a
servlet context Listener, which is specified in web.xml  of one of the
web apps.  Both the web apps connect to this broker and exchange
messages. I am using tcp mode of transport tcp://localhost:"+portNum+ ,
for the broker.
Both the web apps connect to the broker using the url 
failover:tcp://localhost:"+this.portNum 

Make sure that the broker is started by a servlet context listener ,
which is part of the web app , which is  started  first in order. For
example , in my case I have two webapps servlets and users,
Servlets is started before users, so there by the broker is a part of
servlets web app.




Hope this helps.
Thanks,
Suchitha.




-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 26, 2007 8:31 PM
To: users@activemq.apache.org
Subject: Re: Problems with VM transport


To follow up on my last mail: I can perhaps avoid the problem by using
distinct brokernames for each webapp; but that would create distinct
embedded brokers perhaps? I need both the webapps to share the same
broker so they receive messages published by each other.

Regards,

/U

 -------------- Original message ----------------------
From: [EMAIL PROTECTED]
> 
> Hi -
> 
>    I am using the embedded broker in a servlet container. Each webapp 
> in the servlet container instantiates a connection factory that refers

> to broker URL of
> 
>             vm://localhost?broker.persistent=false
> 
> as follows:
> 
>         (Servlet Container
>                  (WebApp1
>                        ConnectionFactory -> 
> vm://localhost?broker.persistent=false
>                  )
>         )
> 
> and this works fine. But as soon as I instantiate another webapp 
> (WebApp2) that also uses embedded broker as follows:
> 
>         (Servlet Container
>                  (WebApp1
>                        ConnectionFactory -> 
> vm://localhost?broker.persistent=false
>                  )
>                  (WebApp2
>                        ConnectionFactory -> 
> vm://localhost?broker.persistent=false
>                  )
>         )
> 
> the second webapp fails with the JMSException given below:
> 
>    javax.jms.JMSException: Could not create Transport. Reason: 
> javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:BrokerName=localhost,Type=Broker
>         at
>
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.
java:33)
>         at
> org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQ
> Connection
> Factory.java:229)
>         at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection
> (ActiveMQC
> onnectionFactory.java:242)
>         at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection
> (ActiveMQC
> onnectionFactory.java:211)
>         at
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveM
> QConnectio
> nFactory.java:158)
>         at
> org.springframework.jms.listener.AbstractMessageListenerContainer.crea
> teConnecti
> on(AbstractMessageListenerContainer.java:989)
>         at
> org.springframework.jms.listener.AbstractMessageListenerContainer.refr
> eshSharedC
> onnection(AbstractMessageListenerContainer.java:455)
>         //...
> 
> 
> I thought I could (tentatively) work around this problem by disabling 
> Jmx, so I switched the broker URL (for both webapps) to
> 
>           vm://localhost?broker.persistent=false&useJmx=false
> 
> This did not help.  Is there fundamentally a problem with multiple 
> instances of ActiveMQConnectionFactory referring to the same broker 
> URL (which is likely to to be the case when using embedded broker)?
> 
> Thanks,
> 
> /U
> 
> 
>  -------------- Original message ----------------------
> From: Adrian Co <[EMAIL PROTECTED]>
> > [EMAIL PROTECTED] wrote:
> > > Adrian,
> > >
> > > Thanks for the note. 
> > >
> > >       > >    Startup:   vm://localhost
> > >       > >    During runtime (after an event): 
> > >       > >            failover(vm://localhost,tcp://remote:61616)
> > >       > >
> > >       > >   Would modifying the broker URL of the connection
factory cause 
> > problems?
> > >        > >   
> > >         > Personally, I'm not sure if you can I haven't tried it, 
> > > but I
> don't
> > >         > think it makes sense to make a vm transport failover. 
> > > The
> assumption
> > is
> > >         > that you have a broker running in the same vm as your
jms client. 
> If
> > the
> > >         > broker crashes, it means your client *should* have 
> > > crashed also
> and
> > it
> > >         > can't failover over to a remote broker anymore.
> > >
> > > Makes sense - now I see why someone else referred to me as
'retard' :-).
> > >  I need to have the client listen to two different brokers (the 
> > > embedded and the external) at the same time (so that the client 
> > > receives messages
> > published
> > > by both the brokers and the messages published by the client are 
> > > sent to
> both
> > the
> > > brokers).  Is this the correct URI to network the embedded broker 
> > > with an
> > external broker?
> > >
> > >             static:(vm://localhost,tcp://remotehost:61616)
> > >   
> > Hum. AFAIK,  static just tells the client to choose one url to 
> > connect to. I don't think you can listen to two or more brokers 
> > using a single connection. You might want to network the brokers 
> > together if thats possible. If someone can let me know if its 
> > possible to listen to more than two brokers using a single jms 
> > connection, I'd appreciate it also. :-)
> > >
> > > Could you also clarify an additional question? If I instantiate 
> > > multiple connection factories in the same VM pointing to the 
> > > embedded broker would all the cconnection factories in the VM 
> > > share the same broker (as opposed to attempting to "instantiating 
> > > a new embedded broker" if such a thing were possible)?
> > >   
> > If they are in the same jvm, and there's already an embedded broker,

> > it will be reused.
> > > Thanks again,
> > >
> > > /U
> > >
> > >  
> > 
> 

Reply via email to