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... Jason 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: http://www.nabble.com/Transport-failed%2C-attempting-to-automatically-reconnect-due-to...-tp15159638s2354p15393840.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
