Re: Failover failure?

["Claude Montpetit [Trilliant]" <cl...@trilliantnetworks.com>]

Back on this subject, the problem does not occur if you have, say, a 
MBeanServer running in your process. Any thread that keeps the consumer 
VM running will prevent the (lingo) consumer from exiting when the 
broker is shutdown. Since it may be common to have another active 
thread, this may be why this problem does not show in most 4.x 
deployments, which I just read, is supposed to be kind of production ready.

--
Claude
> Here are modifications to the lingo ExampleTest class. Do attachments 
> work on the mailing list? I CC'ed you james in case they get filtered 
> out. I attached these files:
>
> spring-client.xml
> spring-server.xml
> ExampleTest.java
>
> The java file is a modified version where I added a main method. Here 
> is how you can reproduce the problem. Save those 3 files in the 
> example package of the lingo 1.1 src/test folder. Setup your 
> environment to use ActiveMQ 4. The supplied XML files only work with v4.
>
> There are 2 issues I found:
> - Problem A: server terminates when broker stops
> - Problem B: client adds threads indefinitely when broker restarts
>
> Please let me know if the way I coded both version of the main (client 
> and server) are not correct.
>
> Problem A (server stops):
>
> 1- Execute
>      java org.logicblaze.lingo.example.ExampleTest server
>   The server uses failover and waits for the broker to be available.
>
> 2- Start activemq on its default port (61616). I am currently using 
> March 23rd snapshot.
>
> 3- The server connects to the broker.
>
> 4- Stop activemq
>
> 5- The server (started in #1) terminates.
>
>
> Problem B (client adds threads indefinitely):
>
> 1- Execute
>      java org.logicblaze.lingo.example.ExampleTest client
>   The client uses failover and waits for the broker to be available.
>
> 2- Start activemq.
>
> 3- The client connects to the broker, sends the message and waits for 
> response.
>
> 4- Stop activemq
>
> 5- The client disconnects from the broker but continues to wait for 
> the answer.
>
> 6- restart activemq
>
> 7- The client connects to the broker.
>
> 8- a TcpTransport thread is created at each 20 seconds or so 
> indefinitely.
>
> -- 
> Claude
>
> James Strachan a écrit :
>> I've no idea how to reproduce this in ActiveMQ; I wonder if you could
>> create a JUnit test case? I'm pretty sure the failover code is working
>> and will keep retrying forever until someone closes the
>> connection/transport.
>>
>> I wonder if your problem is actually that Lingo is timing things out
>> and failing with an exception if a request does not complete within a
>> specific amount of time?
>>
>> Can you reproduce your issue using just JMS?
>>
>>   

Re: Failover failure?

[James Strachan <ja...@gmail.com>]

On 4/12/06, Claude Montpetit [Trilliant]
<cl...@trilliantnetworks.com> wrote:
>
> >> Back on this subject, the problem does not occur if you have, say, a
> >> MBeanServer running in your process. Any thread that keeps the consumer
> >> VM running will prevent the (lingo) consumer from exiting when the
> >> broker is shutdown. Since it may be common to have another active
> >> thread, this may be why this problem does not show in most 4.x
> >> deployments, which I just read, is supposed to be kind of production ready.
> >>
> >
> > Ah! So your problem is purely not having a non-daemon thread running
> > to stop the JVM from terminating right. So its nothing to do with
> > transports terminating early etc.
> >
> Ok, so we have here a perfect example of a attempted explanation from
> someone that does not know much about something, but just enough to be
> dangerous by leading you in the wrong direction... ;)

Its kinda complex stuff all this networking & messaging malarkey, its
hard to figure out whats going on sometimes. So no worries at all -
I'm glad we got there in the end :).

--

James
-------
http://radio.weblogs.com/0112098/

Re: Failover failure?

["Claude Montpetit [Trilliant]" <cl...@trilliantnetworks.com>]

>> Back on this subject, the problem does not occur if you have, say, a
>> MBeanServer running in your process. Any thread that keeps the consumer
>> VM running will prevent the (lingo) consumer from exiting when the
>> broker is shutdown. Since it may be common to have another active
>> thread, this may be why this problem does not show in most 4.x
>> deployments, which I just read, is supposed to be kind of production ready.
>>     
>
> Ah! So your problem is purely not having a non-daemon thread running
> to stop the JVM from terminating right. So its nothing to do with
> transports terminating early etc.
>   
Ok, so we have here a perfect example of a attempted explanation from 
someone that does not know much about something, but just enough to be 
dangerous by leading you in the wrong direction... ;)

--
Claude
> It might be worth adding some simple FactoryBean to lingo to stop the
> JVM terminating in Lingo type deployments if thats what you want.
> Though an easy way to fix it is run some other software like an
> MBeanServer
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098

Re: Failover failure?

[James Strachan <ja...@gmail.com>]

On 4/12/06, Claude Montpetit [Trilliant]
<cl...@trilliantnetworks.com> wrote:
> Back on this subject, the problem does not occur if you have, say, a
> MBeanServer running in your process. Any thread that keeps the consumer
> VM running will prevent the (lingo) consumer from exiting when the
> broker is shutdown. Since it may be common to have another active
> thread, this may be why this problem does not show in most 4.x
> deployments, which I just read, is supposed to be kind of production ready.

Ah! So your problem is purely not having a non-daemon thread running
to stop the JVM from terminating right. So its nothing to do with
transports terminating early etc.

It might be worth adding some simple FactoryBean to lingo to stop the
JVM terminating in Lingo type deployments if thats what you want.
Though an easy way to fix it is run some other software like an
MBeanServer

--

James
-------
http://radio.weblogs.com/0112098/