[activemq-dev] Reconnect - 3.0 versus 3.1-M5

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[activemq-dev] Reconnect - 3.0 versus 3.1-M5

Don Branson-3
All,

It's mostly working okay under 3.0; the only difference is that the
commons-beanutils-1.6.1.jar is in the classpath now.  Not sure I know
activemq well enough to say why this would fix the problem.  Even now,
it occasionally will reconnect into a state where the queued items
from A don't get to B, though.

Under 3.1-M5 with the same config, reconnect doesn't seem to work at
all.  The channel will connect to a broker that starts after it, but
once the broker goes away, the channel won't reconnect.

I've attached the sample configs that work under 3.0.  Use the
'activemq' command to run the examples.  B1 connects to A whether A
starts first or B1.  But if A stops and restarts, B1 will never
re-connect.

Thoughts?

Don

-----Original Message-----
From: Don Branson [mailto:[hidden email]]
Sent: Thursday, July 21, 2005 9:01 AM
To: [hidden email]
Subject: RE: [activemq-dev] Linux and Windows


Perhaps I've misinterpreted how to use this.  If I configure broker A in
this way:

                <connector>
                        <tcpServerTransport uri="tcp://localhost:1090" />
                </connector>

And configure broker B with a channel like this:

                <connector>
                        <tcpServerTransport uri="tcp://localhost:1091" />
                </connector>

                <networkConnector>
                        <networkChannel uri="reliable:tcp://localhost:1090"
/>
                </networkConnector>

B definitely doesn't reconnect when A bounces, using ActiveMQ 3.0 or
ActiveMQ 3.1-M5.  Under 3.1 B's channel to A stops, and it complains that it
'Caught exception dispatching message and no ExceptionListener registered:'.
(It's an EOFException.)  When A restarts, B never reconnects.

What needs to be changed in the above configuration to make this work?

Don

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Tuesday, July 19, 2005 7:35 AM
To: [hidden email]
Subject: Re: [activemq-dev] Linux and Windows

BTW if for whatever reason the socket connection fails, you can get  
ActiveMQ to auto-reconnect for you using the reliable transport. Just  
connect using

     reliable:tcp://host:port

and it'll just work without you having to hack the JMS client.

We could add some kind of flag to indicate whether or not the  
connection is currently connected. Just out of interest; what do you  
do differently knowing something is connected or not?


On 19 Jul 2005, at 13:58, Frik Strecker wrote:

> Hi,
>
> Sorry for not clarifying the logs better from the start.
>
> The JMS connection is persistent and only closed when there is an  
> error
> condition.  There is something suspicious that I will need to  
> investigate.
>
> I have found that sometimes a client will lose it's connection with  
> the
> broker and not be notified through the ExceptionListener... I  
> looked for an
> isConnected() function call, but could not find any.  So I created  
> a hack
> workaround that I do not like...
>
>     synchronized public boolean isConnected() {
>         if (connection==null) return false;
>         try {
>             return connection.getClientID()!=null;
>         } catch (JMSException e) {
>             return false;
>         }
>     }
>
> And if this returns false, the connection will be closed and  
> reopened.  This
> works great on Windows, but I can see how this may behave  
> differently on
> Linux.  Let me do some testing and let you know.  If this is not  
> the cause,
> I will send some sources.
>
> Do you have any plans to add an isConnected()?  I guess I should  
> file an RFE
> :)
>
> Kind regards,
> Frik Strecker
>
>
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Tuesday, July 19, 2005 7:22 AM
>> To: [hidden email]
>> Subject: Re: [activemq-dev] Linux and Windows
>>
>> Just out of interest, what does the Java code look like thats doing
>> the JMS publishing?
>>
>> BTW the log you posted on the issue...
>> http://jira.logicblaze.com/jira/browse/AMQ-311
>>
>> seems to suggest these warnings appear in the log while your broker
>> is being shut down, yet the publisher is still publishing. I wonder
>> how the broker is being closed? Are you closing connections
>> somewhere? How are you running the broker?
>>
>>
>> On 19 Jul 2005, at 13:12, Frik Strecker wrote:
>>
>>> Hi,
>>>
>>> The problem is that I am not closing the connection.  This is the
>>> problem:
>>>
>>>
>>>
>>>> INFO: ActiveMQ Message Broker
>>>>
>>>>
>>> (ID:os4.gatherplace.com-32773-1121729492019-0:0) is shutting down
>>>
>>>
>>>> Jul 19, 2005 7:41:34 AM
>>>>
>> org.activemq.broker.impl.BrokerContainerImpl
>>
>>>>
>>>>
>>> deregisterConnection
>>>
>>>
>>>> INFO: Removing client: gwjmsproducer on transport:
>>>> TcpTransportChannel:
>>>>
>>>>
>>> Socket[addr=/127.0.0.1,port=60733,localport=61616]
>>>
>>>
>>>> Jul 19, 2005 7:41:35 AM
>>>> org.activemq.transport.tcp.TcpTransportChannel
>>>>
>>>>
>>> doClose
>>>
>>> Because ActiveMQ decides to shut down the broker for some unknown
>>> reason,
>>> all subsequent sends fail.
>>>
>>> From the time stamps this connection is not closed until the first
>>> message
>>> is ready to be sent.  So this connection has been open for a few
>>> minutes
>>> without a problem.  Then mysteriously just before the first
>>>
>> message
>>
>>> is to be
>>> sent, ActiveMQ decides it is time to shut down the broker
>>>
>> and close
>>
>>> the
>>> connnection.
>>>
>>> I am not saying that there is not a bug in my code :) but I am not
>>> closing
>>> the JMS connections - they are opened and kept open.  The
>>>
>> code is also
>>
>>> pretty simple and works fine on Windows.
>>>
>>> It is interesting that the logs shows an IP address of 127.0.0.1
>>> for the
>>> connection to be closed.  Could that be a problem?
>>>
>>> Kind regards,
>>> Frik Strecker
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: [hidden email] [mailto:[hidden email]]
>>>> Sent: Tuesday, July 19, 2005 6:58 AM
>>>> To: [hidden email]
>>>> Subject: Re: [activemq-dev] Linux and Windows
>>>>
>>>> Thanks Frik
>>>>
>>>>  From looking at the stack traces, I don't think this is actually a
>>>> problem with ActiveMQ - its more an effect of a different
>>>>
>> threading/
>>
>>>> scheduler implementation on Linux versus Windows.
>>>>
>>>> i.e. you have a thread which is attempting to send a message on a
>>>> connection that another thread has closed. It doesn't look like any
>>>> kind of bug in ActiveMQ.
>>>>
>>>> Just out of interest, who is closing the connections down that your
>>>> background publisher thread is using to publish? Maybe its worth
>>>> stopping the publisher threads first (and waiting for them to
>>>> complete) before closing the JMS connection they are using?
>>>>
>>>>
>>>>
>>>> On 19 Jul 2005, at 12:43, Frik Strecker wrote:
>>>>
>>>>
>>>>
>>>>> Done.  Thanks and let me know what other data I can
>>>>>
>> gather to help.
>>
>>>>>
>>>>> Kind regards,
>>>>> Frik Strecker
>>>>>
>>>>> Voice: +1-603-672-3296
>>>>> http://www.GatherPlace.NET
>>>>> Effective On-line Presentations
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>> Sent: Tuesday, July 19, 2005 4:34 AM
>>>>>> To: [hidden email]
>>>>>> Subject: Re: [activemq-dev] Linux and Windows
>>>>>>
>>>>>>
>>>>>> On 19 Jul 2005, at 02:09, Frik Strecker wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> When I run the broker on Windows and the JMS clients on
>>>>>>>
>> Windows, I
>>
>>>>>>> have no
>>>>>>> problems.  But if I run the same broker on Linux
>>>>>>>
>> Fedora, I have a
>>
>>>>>>> problem.
>>>>>>> I use the same clients... The only change is to run the
>>>>>>>
>> broker on
>>
>>>>>>> Linux (the
>>>>>>> exact same java code).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> This sounds like a new one to us.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Should I open a trouble ticket under the broker?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Sure, please do. If you include the exception / exact problem
>>>>>> you get
>>>>>> it'll help us figure out whats going on.
>>>>>>
>>>>>> James
>>>>>> -------
>>>>>> http://radio.weblogs.com/0112098/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> James
>>>> -------
>>>> http://radio.weblogs.com/0112098/
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
>>
>>
>
>

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

a.xml (500 bytes) Download Attachment
b1.xml (738 bytes) Download Attachment