On Thu, Dec 29, 2011 at 11:07 AM, Pid <p...@pidster.com> wrote:
> On 29/12/2011 17:27, Matthew Tyson wrote:
> > On Wed, Dec 28, 2011 at 6:22 PM, Matthew Tyson
> > <matthewcarlty...@gmail.com>wrote:
> >
> >> On Wed, Dec 28, 2011 at 8:58 AM, Stefan Mayr <ste...@mayr-stefan.de
> >wrote:
> >>
> >>> Am 28.12.2011 10:04, schrieb ma...@apache.org:
> >>>
> >>> Matthew Tyson<matthewcarltyson@gmail.**com <
> matthewcarlty...@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.
> >>>>
> >>>
> >>> This is what I would guess. We have a loadbalancing device that
> handles n
> >>> client-lb connections with m lb-server connections in its HTTP mode.
> There
> >>> we have to switch to TCP proxy mode to keep 1:1 relations.
> >>>
> >>> Your F5 is where to do start crosschecking with tcpdump: client <-> F5
> vs
> >>> F5 <-> server
> >>>
> >>> Stefan
> >>>
> >>>
> >> You think its possible that multiplexing or some load-balancer config
> >> would cause the two observed issues:
> >>
> >> 1) When the custom valve is in use, zombie service() executions continue
> >> with no actual inbound requests
> >> 2) Inbound requests are being replied to with blank 200s, without ever
> >> executing the service method.
> >>
> >> Thanks,
> >>
> >> Matt Tyson
> >>
> >>
> > I think maybe I wasn't clear before. I am running ngrep on the server,
> > inside the f5.
> >
> > F5 <-> ngrep <-> tomcat
> >
> > So the behavior I am seeing is inbound traffic from the F5 to Tomcat,
> then
> > outbound traffic from Tomcat (empty 200s that don't execute the servlet
> > service) back to the F5. It seems very unlikely that F5 configuration is
> > the cause there.
>
> Can you post the CometdServlet code?
>
>
> p
>
>
Here is the code from the service method, it is basically from the
cometd.org project, with some added logging. There's obviously quite a bit
more involved in how cometd processes things, but in this case, the servlet
itself is very simple. How an empty 200 response could be generated
without executing the logging statement here is a mystery.
protected void service(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException
{
logger.info("REQUEST: " + request.getRemoteAddr() + " " +
request.getMethod() + " " + request.getQueryString() + " | TRACE: ", new
Throwable());
if ("OPTIONS".equals(request.getMethod()))
{
serviceOptions(request, response);
return;
}
HttpTransport transport = null;
List<String> allowedTransports = _bayeux.getAllowedTransports();
for (String transportName : allowedTransports)
{
ServerTransport serverTransport =
_bayeux.getTransport(transportName);
if (serverTransport instanceof HttpTransport)
{
HttpTransport t = (HttpTransport)serverTransport;
if (t.accept(request))
{
transport = t;
logger.info("ACCEPTED: " + request.getRemoteAddr() + "
" + t.getClass().getName());
break;
} else {
logger.info("NOT ACCEPTED: " + request.getRemoteAddr() + "
" + t.getClass().getName());
}
}
}
if (transport == null)
{
if (!response.isCommitted()) {
response.sendError(HttpServletResponse.SC_BAD_REQUEST, "Unknown
Bayeux Transport");
} else {
logger.info("NULL TRANSPORT: " + request.getRemoteAddr());
}
}
else
{
try
{
_bayeux.setCurrentTransport(transport);
transport.setCurrentRequest(request);
transport.handle(request, response);
}
finally
{
transport.setCurrentRequest(null);
BayeuxServerImpl bayeux = _bayeux;
if (bayeux != null)
bayeux.setCurrentTransport(null);
}
}
}
Best,
Matt Tyson
