George, This is a non-SSL secure connector that is fronted by an SSL hardware. This means that Tomcat is seeing the traffic as plain HTTP. The packet data we traced was to the Tomcat server itself, so the SSL hardware seems to have been eliminated from the equation. The connector is set to "https" and "secure" so that Tomcat servlets know they are served in a secure context.
Randy Watler Finali Corporation "Sexton, George" wrote: > If you don't use SSL do you have the same problem? > > -----Original Message----- > From: Randy Watler [mailto:rwatler@;finali.com] > Sent: 08 November, 2002 4:41 PM > To: Tomcat Users List > Subject: Re: Rare request delay of 100 seconds > > George, > > Thanks for the query. Here is the connector configuration: > > <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" > port="8543" minProcessors="8" maxProcessors="128" > enableLookups="false" > acceptCount="64" debug="0" connectionTimeout="300000" > scheme="https" secure="true" > useURIValidationHack="false"/> > > So, I think we have it setup right, no? > > Randy Watler > Finali Corporation > > "Sexton, George" wrote: > > > Do you have the connector doing reverse DNS resolution of hosts? > > > > -----Original Message----- > > From: Randy Watler [mailto:rwatler@;finali.com] > > Sent: 08 November, 2002 4:22 PM > > To: [EMAIL PROTECTED] > > Subject: Rare request delay of 100 seconds > > > > We are using 4.1.12 standalone on RedHat Linux 7.3 servers and having > > rare HTTP requests delayed on their way into the Coyote HTTP/1.1 > > connectors. We have packet traces that indicate the request is delayed > > by exactly 100 seconds, but otherwise is received and responded to as > > one would expect. Other requests immediately before and after the > > problematic ones are handled without any significant delay. We are > > wondering if others have noticed this problem or similar ones that sound > > like it? > > > > In the coyote connector code, it appears that the request sockets are > > set by default to have 100 second SO_LINGER timeouts for socket close() > > calls. Of course, this looks suspicious given our problem, but we have > > not been able to identify any way the blocked close() operation could > > affect incoming accept() requests. It is clear that running out of > > processor threads in the thread pool could cause such a delay, but we > > are not running under loads where this would happen, especially for 100 > > seconds. > > > > Any ideas out there? > > > > Randy Watler > > Finali Corporation > > > > -- > > To unsubscribe, e-mail: > <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > > For additional commands, e-mail: > <mailto:tomcat-user-help@;jakarta.apache.org> > > -- > To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
