activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Rosenberg <>
Subject Re: Transport failed, attempting to automatically reconnect due to...
Date Sun, 10 Feb 2008 06:51:24 GMT

It's more than cosmetic, since it keeps the connection alive, preventing the
connection pool's default idle timeout from triggering after 30seconds and
breaking the connection primaturely.  The TcpTransport uses an
InactivityMonitor which keeps connections alive, and so you don't want the
connection pool swooping in and breaking the connections that the
InactivityMonitor is working to keep alive...It's still working correctly
for you without it, it just has to do more connection tear-down and creation
than should be necessary, I'd think...

I had many problems with amq 5.0.0, I've had better luck so far on with
5.1-SNAPSHOT, but alas, I still have some troublesome issues (I think indeed
they might be due to transactions)....Still investigating those.

But 5.0.0 turned out to be unusable completely, for me.

Would have to know more about your specific account application to have any
ideas about what's going there...


RHeil wrote:
> Jason Rosenberg wrote:
>> Don't know if you are using connection pooling....I've solved this issue
>> by setting the idle timeout to 0 (infinite timeout), for pooled
>> connections.....Unfortunately, the PooledConnectionFactory doesn't expose
>> the idleTimeout property, so I sub-classed it as a work-around.  I've
>> filed an issue which outlines the work-around: AMQ-1578
> Interesting reference to this ticket, thank you, Jason
> I am wondering if this prevents only the warning, so it is more a
> cosmetical thing.
> Currently we have instable transactions (cannot save the creation of user
> account) and we are wondering if activemq could cause that. 
> What is your opinion about that?
> Ragnar

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message