Setting tcp_keeliave_time is pretty normal practice in this case. The client can only enable the SO_KEEPALIVE setting on a socket, but its not responsible for the tcp_keepalive_time as you have discovered :-).
In regards to your earlier 10 minute drops do you have any firewalls in between your clients and the STOMP connector? Some firewalls and load-balancing devices will only keep state for a short time - which may explain the 10 minutes perhaps. Checkpoint defaults to an hour for example - but I've seen F5 load-balancers dropping state after 5 minutes ... its user configurable in both cases however. ken. On Tue, Jul 12, 2011 at 2:50 AM, reachrichrulez <reachrichru...@gmail.com> wrote: > Martin, > Thanks for your response. > > I set the ?transport.keepAlive=true on the stomp TransportConnector url on > the broker, but there was no effect. jconsole still showed the connection > for a long time. It appears that this setting relies on the OS > tcp_keepalive_time which is defaulted to 2 hours > > Even after the power cable was pulled off, netstat -a still showed the > connection. Then I modifed the linux tcp settings (tcp_keepalive_time, > tcp_keepalive_intvl and tcp_keepalive_probes) and then the connections were > closed within a few minutes. Even jconsole reflected the same. > > What makes me wonder is that the default for the tcp_keepalive_time is 7200 > seconds(2 hours), but in my original test case scenario the broker > recognized that powered off consumer in ~10 min in sent all the messages to > the other connected consumer. Where is this ~10 min configured? > > Also, It appears from the source code that inactivity monitor for stomp i > disabled. > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/AMQ-does-not-drop-connection-on-stomp-client-ungraceful-shutdown-tp3639513p3661277.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- "Join us for PuppetConf, September 22nd and 23rd in Portland, OR: http://bit.ly/puppetconfsig";
