Re: Odd NIO connector behavior

[Matthew Tyson <ma...@gmail.com>]

Just a heads up to the Tomcat team - I switched all our comet handling to
Jetty, and these issues are resolved.  Something is definitely amiss in the
NIO connector.

Regards,

Matt Tyson


On Sat, Dec 31, 2011 at 10:23 AM, Mark Thomas <ma...@apache.org> wrote:

> On 31/12/2011 16:35, Matthew Tyson wrote:
> > On Wed, Dec 28, 2011 at 1:04 AM, <ma...@apache.org> wrote:
> >
> >> Matthew Tyson <ma...@gmail.com> wrote:
> >>
> >>> That's right, there is an f5 load balancer.  The valve is used to keep
> >>> track of whether the request was via HTTPS or not.
> >>
> >> What happens if you go direct to Tomcat and bypass the F5?
> >>
> >>> tcpdump seems to confirm the same.  What are you thinking?
> >>
> >> Probably, like me, that the F5 isn't handling the Comet requests
> correctly.
> >>
> >> Mark
> >>
> >>
> > I am trying to understand how the load balancer could cause Tomcat to
> > respond with an empty 200 response to a request, without ever executing
> the
> > service method on the servlet mapped to the url.
>
> I've seen all sorts of odd behaviors when something is expecting HTTP
> but doesn't get it.
>
> > The inbound request to tomcat is correct, and it is sometimes
> > handled correctly.   However, much of the time it is sending the empty
> 200.
>
> Given that there appears to be multiple issues here, I'd suggest
> concentrating on the one that is likely easiest to debug. Fix that and
> then see what the other problems then look like. We might be seeing two
> sides of the same issue.
>
> My recommendation is:
> - if possible, test without the F5 just to be sure this is purely a
> Tomcat issue
> - investigate the repeated calls to service() with no incoming request
> as that is likely to be easier to debug. As per my previous suggestion,
> get Tomcat into this state and then use remote debugging to see what is
> calling NioEndpoint.processSocket()
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>