While testing perlbal we ran into these messages:
already responded.
already responded [2].
They start immediately after perlbal has parsed the headers -- before a
backend connection is created.

They seem to happen occasionally on a POST that's preceded by a GET.
If I get persist_client to off, the problem goes away.

Any ideas?

Thanks!
--Justin

[ Post a follow-up to this message ]

When you say "the problem goes away", do you see a real problem, or just
the error messages?

I honestly hardly run at debug level >= 3, so it's possible the warning
messages are bogus, or a legacy of times before persistent connections.

Before I look into this more, I'm curious if things actually work for you,
despite the warnings.  If not, then I'm curious what your traffic looks
like, and the rest of your config.

- Brad


On Fri, 11 May 2007, Justin Huff wrote:

> While testing perlbal we ran into these messages:
> 	already responded.
> 	already responded [2].
> They start immediately after perlbal has parsed the headers -- before a
> backend connection is created.
>
> They seem to happen occasionally on a POST that's preceded by a GET.
> If I get persist_client to off, the problem goes away.
>
> Any ideas?
>
> Thanks!
> --Justin
>
>

[ Post a follow-up to this message ]

> When you say "the problem goes away", do you see a real problem, or just
> the error messages?
With persistence, the POST never makes it to the backend, so the image
upload fails.  When it's disabled, everything works great (i.e. the POST
makes it). Oh yeah, the messages go away too

> I honestly hardly run at debug level >= 3, so it's possible the warning
> messages are bogus, or a legacy of times before persistent connections.
Yeah, it's pretty verbose.

> Before I look into this more, I'm curious if things actually work for you,
> despite the warnings.  If not, then I'm curious what your traffic looks
> like, and the rest of your config.
I have a debug log, and some tcpdump action if you want 'em.

Our test env is running perlbal in front of apache, which is in front of
CherryPy.  In production we're just using apache in front of CherryPy.
Both use MFS, but it's use seems un-related.

I should have mentioned that I'm also not convinced that this is a
Perlbal issue.  We've seen indications that this *might* be happening in
production due to external proxies, but we're not totally sure.  This is
the first time we've been able to repro it where we have access to both
sides.  Even at that, it's not a consistant repro.

--justin

[ Post a follow-up to this message ]

Yeah, send me a pcap file privately, off-list and I can look into it.

(As long as you captured full packets and did it from the Perlbal machine
itself, so I can see all perspectives... not from your desktop/etc)


On Fri, 11 May 2007, Justin Huff wrote:
 
> With persistence, the POST never makes it to the backend, so the image
> upload fails.  When it's disabled, everything works great (i.e. the POST
> makes it). Oh yeah, the messages go away too
> 
> Yeah, it's pretty verbose.
> 
> I have a debug log, and some tcpdump action if you want 'em.
>
> Our test env is running perlbal in front of apache, which is in front of
> CherryPy.  In production we're just using apache in front of CherryPy.
> Both use MFS, but it's use seems un-related.
>
> I should have mentioned that I'm also not convinced that this is a
> Perlbal issue.  We've seen indications that this *might* be happening in
> production due to external proxies, but we're not totally sure.  This is
> the first time we've been able to repro it where we have access to both
> sides.  Even at that, it's not a consistant repro.
>
> --justin
>
>

[ Post a follow-up to this message ]