Re: Is unix socket limited to ~16KB?

Hi Krzysztof,

On Fri, Feb 29, 2008 at 12:23:07PM +0100, Krzysztof Oledzki wrote:
> On Thu, 28 Feb 2008, Willy Tarreau wrote:
> >I found the problem. It's not an implementation bug, it's a design bug.
> >The fact is that the session getting the "show stat" or "show info" request
> >does not hold the request, and if the response needs to reschedule, then
> >the
> >nature of the request is lost :-(
> >
> >In the HTTP case, a somewhat similar case was addressed by the
> >SN_STAT_FMTCSV
> >flag, indicating if we want to read csv or html. Here we should in theory
> >use
> >the same principle. But doing such exceptions is quickly going to get me
> >nuts.
> >
> >So I will prefer to store several "request" parameters in the session,
> >which
> >will be castable depending on the request handler.
> >
> >I was about to fix the problem reusing the SN_STAT_FMTCSV flag, but I don't
> >like that. Instead, I will not fix it immediately and focus on your changes
> >first. That way, I will reduce the risk of rejects, making it easier to fix
> >the problem just after that.
>
> Thanks.

Done!
That was not easy but I finally fixed it. It will tell me not to write such crappy things next time :-)

In the process, I added a "flags" entry into the stats member of the session, to store all info required to produce the stats. That way, I could move 4 of the SN_XXX flags there, where they are more adequate. I found that the unix stats FSM was quite tricky, because it did magics on some flag combinations. Now I've reused the server state in a cleaner manner (until we can split L4 and L7 FSMs).

I've updated 1.3.14 and 1.3.15 (on top of your recent SNMP changes).

All tests I've run on it went fine. I think I will issue 1.3.14.4 soon with this crap fixed.

Regards,
Willy Received on 2008/03/17 22:29