[iolib-devel] poll error leaking from write-sequence
Stelian, i think it's not against the rules to signal other exceptions than stream-error from sequence calls, but it's causing me more and more headaches. the situation: i want to log errors happening while our web server is serving requests, but i want to keep the error log noise-free. network related errors are considered noise, so i have a function that decides whether the error is coming from the network stream connected to the client: (def function is-error-from-client-stream? (error client-stream) (bind ((client-stream-fd (iolib:fd-of client-stream))) (or (and (typep error 'stream-error) (eq (stream-error-stream error) client-stream)) ;; TODO the rest is fragile and easily breaks when iolib changes behavior (and client-stream-fd (and (typep error 'iolib:socket-error) (eql client-stream-fd (isys:handle-of error))) ;; TODO signalling non stream-error conditions might be an iolib bug (and (typep error 'iolib.multiplex:poll-error) (eql client-stream-fd (iolib.multiplex:poll-error-fd error))))))) this function keeps getting longer, but the bigger issue is that it highly depends on iolib's internal implementation. is there any chance to add it to iolib's contracts that it only signals stream-error from stream calls like write-sequence? it could chain the original condition not to lose information... or do you have some other suggestions? -- attila ps: the new error that started to show up after i temporarily made the client sockets blocking until we fully implement connection multiplexing (the error is most probably that the connection was reset, client cancelled the download): Error caught while polling file descriptor 9: Unknown error *** Backtrace: 6: (HANDLE-TOPLEVEL-ERROR #<HOME-APPLICATION \"/\" 0 {1000FD4429}> #<POLL-ERROR {100B7CB041}>) 7: ((FLET HU.DWIM.WUI::HANDLE-REQUEST-ERROR) #<POLL-ERROR {100B7CB041}>) 8: ((LABELS HU.DWIM.UTIL::HANDLE-LEVEL-1-ERROR) #<POLL-ERROR {100B7CB041}>) 9: (SIGNAL #<POLL-ERROR {100B7CB041}>) [:EXTERNAL] 10: (ERROR POLL-ERROR) [:EXTERNAL] 11: (IOLIB.MULTIPLEX::PROCESS-POLL-REVENTS 24 9) 12: (WAIT-UNTIL-FD-READY 9 :OUTPUT NIL T) 13: (IOLIB.STREAMS::%WRITE-OCTETS-FROM-FOREIGN-MEMORY IOLIB.SOCKETS::SOCKET-WRITE-FN 9 #.(SB-SYS:INT-SAP #X100B7C7010) 8192) 14: (IOLIB.STREAMS::%WRITE-SIMPLE-ARRAY-UB8 #<active IPv6 stream socket, unconnected {100B617891}> #(173 24 188 120 227 48 246 217 166 31 219 246 223 156 15: (WRITE-SEQUENCE #(173 24 188 120 227 48 246 217 166 31 219 246 223 156 67 143 56 133 143 102 199 237 58 116 214 169 16 138 87 110 26 198 192 45 54 96 16: ((LABELS HU.DWIM.WUI::WITH-CONTENT-SERVING-LOGIC-BODY) ((\"Content-Length\" . \"1957376\") (\"Content-Type\" . \"application/msword\") (\"Date\" . \" 17: (HU.DWIM.WUI::SERVE-FILE #P\"/var/opt/darcs/ebr42-hydrogen/documents/ebr42 - Felhasználói kézikönyv önkormányzatoknak.doc\") [:EXTERNAL]
On Mon, 2009-11-16 at 00:12 +0100, Attila Lendvai wrote:
Stelian, i think it's not against the rules to signal other exceptions than stream-error from sequence calls, but it's causing me more and more headaches.
the situation: i want to log errors happening while our web server is serving requests, but i want to keep the error log noise-free. network related errors are considered noise, so i have a function that decides whether the error is coming from the network stream connected to the client:
(def function is-error-from-client-stream? (error client-stream) (bind ((client-stream-fd (iolib:fd-of client-stream))) (or (and (typep error 'stream-error) (eq (stream-error-stream error) client-stream)) ;; TODO the rest is fragile and easily breaks when iolib changes behavior (and client-stream-fd (and (typep error 'iolib:socket-error) (eql client-stream-fd (isys:handle-of error))) ;; TODO signalling non stream-error conditions might be an iolib bug (and (typep error 'iolib.multiplex:poll-error) (eql client-stream-fd (iolib.multiplex:poll-error-fd error)))))))
this function keeps getting longer, but the bigger issue is that it highly depends on iolib's internal implementation.
is there any chance to add it to iolib's contracts that it only signals stream-error from stream calls like write-sequence? it could chain the original condition not to lose information...
or do you have some other suggestions?
I'd rather not do chaining because that would disallow the use of restarts. I think it would be better to make sure that only two error types can come out of a stream operation: CL:STREAM-ERRORs signaled by the Gray stream layer, and ISYS:SYSCALL-ERRORs signaled by low-level code. I've logged it as https://bugs.launchpad.net/iolib/+bug/485392 -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
participants (2)
-
Attila Lendvai
-
Stelian Ionescu