Thank you for the response, All servers are unix,
Changing that variable is the debate and it's impact, But I own the arserver so will set it, to be safe. Additional 2hour timer on top port for 2hour, And reduce the mt session timeout to 60 mins along with mt user preferences. We are increasing the Jvms to >= 1.5 gb, due to perform once testing by webadmin. Will see if all hell breaks loose Monday when people start hitting change/service/reporting on the mt. Conny Martin wrote: > > Dee, > > IHMO the easiest way to avoid flushing connections on the firewall is to > set the tcp keepalive timeout to a value shorter than 60 minutes. > > If your arserver is running on a linux box just do > > echo 3500 >/proc/sys/net/ipv4/tcp_keepalive_time > > as root and restart your arserver. > > HTH > > KR Conny > > -----Ursprüngliche Nachricht----- > Von: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] Im Auftrag von Dee > Gesendet: Donnerstag, 12. April 2012 17:13 > An: arslist@ARSLIST.ORG > Betreff: Re: Java API connection pool question.. > > Axton, > > From our network admins, these points where made, in response to your > post. > > The connections from the midtier (Websphere) server to the ARserver are > persistent TCP connections. These connections are not stateless. > Our firewall is doing stateful inspection on these connections. > The firewall security policy allows all of these connections to be > started. > Connections are flushed from the firewall state tables after 1 hour of > INACTIVITY. Not active connections are ever flushed. > After an inactive connection has been flushed, any further packets (in > either direction) are dropped by the firewall. No RST packets are sent to > the session endpoints at the time of the flush or at the time of the > packet drops. A firewall log entry is created for each of these > "out-of-state" > packet drops. > After attempting to re-use one of the inactive/flushed connections, the > application's session endpoint make take several minutes doing TCP retries > of their dropped packets before they give up and start a new connection. > > We want to know how we can configure the AR product to either: > 1) keep these connections active by implementing the keepalive protocol or > 2) close the connections when the immediate unit of work is finished. > > > > > -- > View this message in context: > http://ars-action-request-system.1093659.n2.nabble.com/Java-API-connection-pool-question-tp7454090p7459721.html > Sent from the ARS (Action Request System) mailing list archive at > Nabble.com. > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > -- View this message in context: http://old.nabble.com/Java-API-connection-pool-question..-tp33663782p33687857.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
