Update: "Bogus Handlers" error using the WIRE package: where should error handling co

I understand this problem a bit better now, but I'm still
confused
about the exact nature of the error ("bogus
handlers").

When I posted originally, I was convinced the error had
something to
do with WIRE connections behind made from each of the client
processes
to the server process.

That's incorrect.

The past few days, we turned all the client processes off,
and the
error still occurred inside the server process, so it had
nothing to
do with WIRE.

But since the server process is doing vanilla I/O on the
local
filesystem -- using (with-open-file) -- to read and write
files it
owns (there's also plenty of disk space), I'm not sure what
the "bogus
handlers" message means exactly.

I've looked for references to explain this message, but
couldn't find
any. Could anyone point me to an explanation, or help me
understand
what is happening?

And as part of that, does anyone know whether or not the
function I
mentioned earlier -- (clear-bogus-handlers) -- would clear
that error,
assuming I put it as a condition in the right place in my
server code?

>>>>> "Denis" == Denis
Papathanasiou <denis.papathanasiougmail.com> writes:

Sorry for the long delay....

    Denis> But since the server process is doing vanilla
I/O on the local
    Denis> filesystem -- using (with-open-file) -- to
read and write files it
    Denis> owns (there's also plenty of disk space), I'm
not sure what the "bogus
    Denis> handlers" message means exactly.

I've had some problems with serve-event before.  It would
work fine,
handling lots of traffic to just one client, but on an
overnight run,
it would sometimes just stop working.  I cannot remember if
it was the
bogus handler issue or not, though.

    Denis> I've looked for references to explain this
message, but couldn't find
    Denis> any. Could anyone point me to an explanation,
or help me understand
    Denis> what is happening?

src/code/serve-event.lisp is the source.  It seems that
after doing a
select, one of the file descriptors is bad in some way.  But
the error
message you get "NIL have bad file descriptors"
doesn't make much
sense.  That would indicate that there are no bogus
handlers.

    Denis> And as part of that, does anyone know whether
or not the function I
    Denis> mentioned earlier -- (clear-bogus-handlers) --
would clear that error,
    Denis> assuming I put it as a condition in the right
place in my server code?

Are you running on x86, with multiprocessing enabled? 
Perhaps that's
getting in the way of things?  Perhaps you can modify
sub-serve-event
to print out the value and err from select before calling
handler-descriptor-error.  Or maybe there really isn't a
bogus handler
and the restart-case in handler-descriptors-error should be
skipped?

Sorry I can't be more helpful,

Ray

On 3/2/07, Suresh Madhu <madhucs.unm.edu> wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.lisp.cmucl.general as
well.
>
>
>  [Not sure if I'm subscribed, please CC the list if it
doesn't make it
>   there]
>
> * "Denis Papathanasiou"
<e4044eb40703010751r5becd90amcb991a8b57df6bcdXXX>
:
> | The past few days, we turned all the client processes
off, and the
> | error still occurred inside the server process, so it
had nothing to
> | do with WIRE.
> |
> | But since the server process is doing vanilla I/O on
the local
> | filesystem -- using (with-open-file) -- to read and
write files it
> | owns (there's also plenty of disk space), I'm not
sure what the "bogus
> | handlers" message means exactly.
>
> Bogus handlers IIRC are handlers attached to closed
FDs.
>
> I have not used the WIRE package (but do use TCP/IP on
top of the MP
> package -- i.e. having a CMUCL MP:PROCESS doing a
listen, and another
> to handle each connection.)
>
> The WIRE package does not use MP but uses fd-handlers. 
I noticed you

Ah, thanks for that clarification; we'd not been able to
connect the
dots between bogus handlers and WIRE.

> used an MP function in your code.  I'd guess your bogus
handler
> messages are from some little tested interaction
between MP and the
> FD-HANDLERS packages.  Perhaps you can eliminate the
MP:PROCESS and
> see if you still get the messages?

It's plausible to try it in the interim, to find out whether
or not
that is indeed causing the error, but not using MP in the
server
creates more problems than it solves.

I.e., in a single-threaded mode, when (reload) is busy, none
of the
public methods in the server process will be responsive
enough when
they're invoked by any of the client processes.

Perhaps we should dump WIRE and switch to a model like what
you use
("use TCP/IP on top of the MP package -- i.e. having a
CMUCL
MP:PROCESS doing a listen, and another to handle each
connection.").

Do you have any examples/code snippets of that that you
could share?

> | I've looked for references to explain this message,
but couldn't find
> | any. Could anyone point me to an explanation, or help
me understand
> | what is happening?
> |
> | And as part of that, does anyone know whether or not
the function I
> | mentioned earlier -- (clear-bogus-handlers) -- would
clear that error,
> | assuming I put it as a condition in the right place
in my server code?
>
> [CLEAR-BOGUS-HANDLERS looks like trebuchet (my taste),
and not
> appropriate in this case, perhaps you can consider
wrapping your code
> inside a HANDLER-BIND that uses INVOKE-RESTART.]

This may sound like a dumb question -- I really need to go
back and
study conditions again -- but if CMUCL is offering a restart
that
solves the problem ("REMOVE-THEM"), then if I were
to wrap a
handler-bind/invoke-restart (where the restart is
"REMOVE-THEM") in
the right place in the server code, then I can go on using
WIRE and
MP, correct?

I.e. I know this condition will occur infrequently, but I
also know
how to recover from it, right?