hi!
seems like something was broken by one of the two patches that follow this one: 6d63d32fb7f400e93066cb37a139a43dae4721c1 "Remove useless check in MAYBE-REWIND-IOBUF."
i don't know which one, because the second newest patch doesn't work on its own due to a not of type function error.
the symptom is that in some cases the ajax answers in our web server doesn't arrive to the browser, the network stream seems to be closed. i suspect some bug around flushing?
stuff mostly work, but there's a reproducible call site (so, it's not a heisenbug) where the answer body is lost (the headers are properly sent though). the body is written using write-sequence as a byte array.
hth,
On Thu, 2010-04-01 at 13:30 +0200, Attila Lendvai wrote:
hi!
seems like something was broken by one of the two patches that follow this one: 6d63d32fb7f400e93066cb37a139a43dae4721c1 "Remove useless check in MAYBE-REWIND-IOBUF."
i don't know which one, because the second newest patch doesn't work on its own due to a not of type function error.
the symptom is that in some cases the ajax answers in our web server doesn't arrive to the browser, the network stream seems to be closed. i suspect some bug around flushing?
stuff mostly work, but there's a reproducible call site (so, it's not a heisenbug) where the answer body is lost (the headers are properly sent though). the body is written using write-sequence as a byte array.
Thanks for the notice, I'll fix this as soon as possible
i had a bit of time to gather some more info. as a first try, here's some log/trace attached, maybe it helps.
looking at the firebug output (so, not ethereal or somesuch!) it looks like the http headers got delivered, but the body is empty.
for the record, the related dojo bug report: http://trac.dojotoolkit.org/ticket/10985
conclusion: browsers behave weird and different, but simply returning an empty xml answer with a reverted iolib does not provoke the erratic behavior i see with iolib head.
i've done a bit more experimenting and i have one more data point: firebug in ff shows that the http request is running indefinitely long (several minutes later the progress indicator still spinning), even though the server log shows that handling the request have finished (with a call to close in uwp and no sign or error). maybe the browser does not receive the socket closed notification?
the console in chrome doesn't even show the xhr request being made, i guess chrome only logs it after it has finished.
hth,
On Thu, Apr 15, 2010 at 09:25:41AM +0200, Attila Lendvai wrote:
i've done a bit more experimenting and i have one more data point: firebug in ff shows that the http request is running indefinitely long (several minutes later the progress indicator still spinning), even though the server log shows that handling the request have finished (with a call to close in uwp and no sign or error). maybe the browser does not receive the socket closed notification?
I've seen that exact error. My example programs will produce it. Just start up ex6-server, connect with ex5a-client, type 'hello' at the client prompt, then 'quit'. The client hangs around forever while the server closed the connection.
-pete
I've seen that exact error. My example programs will produce it. Just start up ex6-server, connect with ex5a-client, type 'hello' at the client prompt, then 'quit'. The client hangs around forever while the server closed the connection.
anything new on this?
i've managed to reproduce the problem using the examples and iolib version 5dfec183c4d57fa315d2b29c92d2b90045ea8eed (current head)
i've added some output printing to the client code as seen below.
CL-USER> (in-package :iolib.examples) EXAMPLES> (make-thread 'run-ex6-server :name "ex6 server")
EXAMPLES> (run-ex5a-client) Connected to server 127.0.0.1:9999 from my local connection at 127.0.0.1:42670! alma Writing to socket: "alma" Flushing socket Done
Writing to socket: "" Flushing socket Done alma
Writing to socket: "" Flushing socket Done
quit Writing to socket: "quit" Flushing socket Done
happy writing?! Writing to socket: "happy writing?!" Flushing socket Done quit
and in the inferior lisp buffer i see:
Accepted a client from 127.0.0.1:42670 Creating line-echoer for 127.0.0.1:42670 Read 127.0.0.1:42670: alma Wrote 127.0.0.1:42670: alma Read 127.0.0.1:42670: Wrote 127.0.0.1:42670: Read 127.0.0.1:42670: Wrote 127.0.0.1:42670: Read 127.0.0.1:42670: quit Wrote 127.0.0.1:42670: quit Client requested quit! Closing connection to 127.0.0.1:42670
as you can see "happy writing?!" was written into a socket that has been closed by the server at the previous "quit" line.
i'm not sure it's exactly the same issue as mine, but could be related.
On Wed, May 26, 2010 at 11:08:32AM +0200, Attila Lendvai wrote:
I've seen that exact error. My example programs will produce it. Just start up ex6-server, connect with ex5a-client, type 'hello' at the client prompt, then 'quit'. The client hangs around forever while the server closed the connection.
anything new on this?
I know of no new work on fixing this bug.
as you can see "happy writing?!" was written into a socket that has been closed by the server at the previous "quit" line.
i'm not sure it's exactly the same issue as mine, but could be related.
Yup, that's the error as I produced it. The server states it closes the socket, but the client never sees it. I haven't yet done a tcpdump to see if any FIN really happens. If not, that would be a smoking gun that IOLib didn't actually close the fd associated with the socket.
Thank you.
-pete
On Wed, 2010-05-26 at 10:09 -0500, Peter Keller wrote:
On Wed, May 26, 2010 at 11:08:32AM +0200, Attila Lendvai wrote:
I've seen that exact error. My example programs will produce it. Just start up ex6-server, connect with ex5a-client, type 'hello' at the client prompt, then 'quit'. The client hangs around forever while the server closed the connection.
anything new on this?
I know of no new work on fixing this bug.
as you can see "happy writing?!" was written into a socket that has been closed by the server at the previous "quit" line.
i'm not sure it's exactly the same issue as mine, but could be related.
Yup, that's the error as I produced it. The server states it closes the socket, but the client never sees it. I haven't yet done a tcpdump to see if any FIN really happens. If not, that would be a smoking gun that IOLib didn't actually close the fd associated with the socket.
Thank you.
I think that my last commit fixed this
On Thu, May 27, 2010 at 12:51:10AM +0800, Stelian Ionescu wrote:
On Wed, 2010-05-26 at 10:09 -0500, Peter Keller wrote:
On Wed, May 26, 2010 at 11:08:32AM +0200, Attila Lendvai wrote:
I've seen that exact error. My example programs will produce it. Just start up ex6-server, connect with ex5a-client, type 'hello' at the client prompt, then 'quit'. The client hangs around forever while the server closed the connection.
anything new on this?
I know of no new work on fixing this bug.
as you can see "happy writing?!" was written into a socket that has been closed by the server at the previous "quit" line.
i'm not sure it's exactly the same issue as mine, but could be related.
Yup, that's the error as I produced it. The server states it closes the socket, but the client never sees it. I haven't yet done a tcpdump to see if any FIN really happens. If not, that would be a smoking gun that IOLib didn't actually close the fd associated with the socket.
Thank you.
I think that my last commit fixed this
I just checked, and yes, I believe his last commit does fix the bug shown by my example programs.
Thank you!
-pete
-
Attila Lendvai -
Peter Keller -
Stelian Ionescu