-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Hans!
I have confirmed the problem both when running on localhost and with seperate machines for client and server. Siege does not act the same way that nmap -sT does. The problem is noticable with nmap because it performs a connect without sending any additional data from the nmap man page I extracted this not so flattery nugget:
Many services on your average Unix system will add a note to syslog, and sometimes a cryptic error message, when Nmap connects and then closes the connection without sending data. Truly pathetic services crash when this happens, though that is uncommon.
I noticed myself that I was unable to provoke the uncaught exception when using a lower number of iterations but it always does this for an iteration count of 20 on my machines. I'm expecting this could vary a little so maybe you could raise the number of iterations slightly to provoke one?
I also did as you suggested and set *break-on-signals*. The trace looks like this:
Socket error in "getpeername": ENOTCONN (Transport endpoint is not connected) BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL). [Condition of type SIMPLE-CONDITION]
Restarts: 0: [CONTINUE] Return from BREAK. 1: [REASSIGN] Return from BREAK and assign a new value to *BREAK-ON-SIGNALS*. 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot listener (*:8000)" RUNNING {AAA8B51}>)
Backtrace: 0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n (now rebound to NIL)." #<SB-BSD-SOCKETS:NOT-CONNECTED-ERROR {AE7FCA9}>) 1: (SIGNAL #<SB-BSD-SOCKETS:NOT-CONNECTED-ERROR {AE7FCA9}>)[:EXTERNAL] 2: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL] 3: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername") 4: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername")[:EXTERNAL] 5: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME (SB-BSD-SOCKETS:SOCKET)) #<unavailable argument> #<unavailable argument> #<SB-BSD-SOCKETS:INET-SOCKET descriptor 6 {AE7F971}>) 6: ((SB-PCL::FAST-METHOD USOCKET:GET-PEER-ADDRESS (USOCKET:STREAM-USOCKET)) #<unavailable argument> #<unavailable argument> #<USOCKET:STREAM-USOCKET {AE7FBD1}>) 7: (HUNCHENTOOT::CLIENT-AS-STRING #<USOCKET:STREAM-USOCKET {AE7FBD1}>) 8: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..) 9: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>) 10: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 11: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477)) 12: (SB-THREAD::CALL-WITH-MUTEX ..) 13: ((LAMBDA ())) 14: ("foreign function: #x806480C") 15: ("foreign function: #x8052C21") 16: ("foreign function: #x805BD9D") 17: ("foreign function: #xB7FB84C0")
I had a quick peek at client-as-string and it does indeed not handle the sb-bsd-sockets:not-connected-error and if I put a handler-case around body of client-as-string returning nil when the exception appears I can not reproduce my problem anymore.
This wouldn't provide a portable solution though :-P
/Peter
Hans Hübner wrote:
Peter,
I am not able to reproduce the problem using the nmap command line that you provided. I also ran siege against Hunchentoot:
Transactions: 1205 hits Availability: 100.00 % Elapsed time: 14.40 secs Data transferred: 3.03 MB Response time: 0.11 secs Transaction rate: 83.69 trans/sec Throughput: 0.21 MB/sec Concurrency: 9.30 Successful transactions: 1205 Failed transactions: 0 Longest transaction: 6.29 Shortest transaction: 0.01
Can you reproduce the problem with siege? What platform are you running on? Can you reproduce the problem when the client is on the same machine as the server?
It'd be interested to learn where the SB-BSD-SOCKETS:NOT-CONNECTED-ERROR is actually signalled from. To debug, you might set *BREAK-ON-SIGNALS* to 'SB-BSD-SOCKETS:NOT-CONNECTED-ERROR and post the backtrace.
-Hans
2009/7/3 Peter Stiernström peter.stiernstrom@blixtvik.se: I don't know if this have come up earlier or if it is a known problem. If so I am sorry for bringing it up again. A quick look through the archives turned up a non-caught sbcl socket timeout error with the obvious fix of adding an error translation to the usocket sbcl backend error map. I expect this to be somewhat similar.
When stressing hunchentoot with a number of connection like so:
for i in $(seq 1 20); do nmap -sT -p 80 <hostname> ;done
Hunchentoot (last 1.0 release) stops responding after not having caught a SB-BSD-SOCKETS:NOT-CONNECTED-ERROR thus being easily DOSed.
I was hoping that there would be an obvious similar mapping missing but I don't know my way around hunchentoot to figure out what to map SB-BSD-SOCKETS:NOT-CONNECTED-ERROR to.
I am seeing this problem on a regular basis and for now it always prompts a full restart.
I am using usocket 0.4.1 with hunchentoot 1.0.0.
/Peter
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
- -- Med vänlig hälsning,
Peter Stiernström 0708-810932 Blixtvik AB