Hi all,
I'm working on reddit.com, which uses TBNL as its web framework. For the most part, all is well, but I've been running into an error lately that is causing me to worry. Basically, the symptom of the problem is that our website appears to pause, and all requests just hang (eventually they'll timeout on the browser side).
I work against our server using remote SLIME. The SLIME session does not hang, but in order to bring the website back to life I log into our web server, use attachtty to view the running lisp process, and hit ctrl + c a few times, after which a debugger will pop open in Emacs that I can abort.
I'm running CMUCL 19a on a FreeBSD box. I use apache and mod_lisp in front of TBNL.
I haven't been able to find out what causes this lockup, nor do I understand why I must open the process on the web server (when I'm already cruising in SLIME) to wake it up.
Has anyone seen any issues like this before? Or perhaps know if this is even a TBNL issue?
I've pasted the output I see from the lisp process (via attachtty) and in my emacs session (after I send an interrupt).
Any help would be greatly appreciated,
Steve Huffman
In attachtty I'll see something like this:
Interrupted at #x2811F14E. [Condition of type SIMPLE-CONDITION]
Restarts: 0: [CONTINUE] Return from BREAK. 1: [DESTROY ] Destroy the process
Debug (type H for help)
(UNIX::SIGINT-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FD789C)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/signal.lisp. 0]
and in emacs I'll see something like this:
Interrupted at #x2811F14E. [Condition of type SIMPLE-CONDITION]
Restarts: 0: [CONTINUE] Return from BREAK. 1: [DESTROY] Destroy the process
Backtrace: 0: (UNIX::SIGINT-HANDLER #<#1=unused-arg> #<#1#> #.(SYSTEM:INT-SAP #x47FD789C)) 1: (UNIX::SIGINT-HANDLER 3 #<#1=unused-arg> #<#1#> #.(SYSTEM:INT- SAP #x47FD789C))[:EXTERNAL] 2: ("Foreign function call land") 3: ("Foreign function call land") 4: ("Foreign function call land") 5: ("Foreign function call land") 6: ("Foreign function call land") 7: (LISP::FD-STREAM-READ-N-BYTES #<Stream for descriptor 8> "" 0 14 ...) 8: (LISP::FD-STREAM-READ-N-BYTES 5 #<Stream for descriptor 8> "" 0 ...)[:EXTERNAL] 9: (LISP::READ-INTO-SIMPLE-STRING "" #<Stream for descriptor 8> 0 14) 10: (READ-SEQUENCE "" #<Stream for descriptor 8> :START 0 ...) 11: ((METHOD INITIALIZE-INSTANCE (:AFTER) (TBNL::REQUEST)) (#(1 2 0 3 5 ...) . #()) #<#1=unused-arg> #<TBNL::REQUEST {49094BA5}> #<#1#>) 12: ((MAKE-INSTANCE TBNL::REQUEST :HEADERS-IN PCL::|.P0.|) (("content- stream" . #<Stream for descriptor 8>) ("content-length" . "14") ("content-type" . "application/x-www-form-urlencoded") ("remote-ip- addr" . "172.133.113.57") ("remote-ip-port" . "3332") ...)) 13: (TBNL::PROCESS-REQUEST (("content-stream" . #<Stream for descriptor 8>) ("content-length" . "14") ("content-type" . "application/x-www-form-urlencoded") ("remote-ip-addr" . "172.133.113.57") ("remote-ip-port" . "3332") ...)) 14: (TBNL::LISTEN-FOR-REQUEST #<Stream for descriptor 8> TBNL::PROCESS-REQUEST)
On Tue, 9 Aug 2005 00:01:33 -0400, Steve Huffman steve.huffman@gmail.com wrote:
I'm working on reddit.com, which uses TBNL as its web framework. For the most part, all is well, but I've been running into an error lately that is causing me to worry. Basically, the symptom of the problem is that our website appears to pause, and all requests just hang (eventually they'll timeout on the browser side).
I work against our server using remote SLIME. The SLIME session does not hang, but in order to bring the website back to life I log into our web server, use attachtty to view the running lisp process, and hit ctrl + c a few times, after which a debugger will pop open in Emacs that I can abort.
I'm running CMUCL 19a on a FreeBSD box. I use apache and mod_lisp in front of TBNL.
I haven't been able to find out what causes this lockup, nor do I understand why I must open the process on the web server (when I'm already cruising in SLIME) to wake it up.
Has anyone seen any issues like this before? Or perhaps know if this is even a TBNL issue?
I've pasted the output I see from the lisp process (via attachtty) and in my emacs session (after I send an interrupt).
Hi!
Unfortunately, I currently have no idea what the problem is. Just a vague idea: Could you try if the problem is still there without SLIME being in the picture? I remember I've seen a completely unrelated threading problem with a LispWorks app which went away after we stopped having SWANK loaded.
Cheers, Edi.
PS: From you headers it looks like you're using the newest mod_lisp version so that should be fine.
I'm working on reddit.com, which uses TBNL as its web framework. For the most part, all is well, but I've been running into an error lately that is causing me to worry. Basically, the symptom of the problem is that our website appears to pause, and all requests just hang (eventually they'll timeout on the browser side).
I am not sure whether it is related yet - I was having simmilar problems with tbnl/cmucl while making mod_lisp interoperate with mod_xslt. While server was getting enough traffic it was pretty responsive yet after long pauses I was getting timeouts. Though tbnl on sbcl was working fine with such configuration. The workaround i have found was - send a ping request once in a few seconds not letting cmucl "sleep". As if one of cmucl threads was hogging all the resources and not giving any to threads that were not doing anything for a while ... Ignas
P.S. it could have been related with mod_lisp + mod_xslt combination though ...
On Tue, 9 Aug 2005 13:09:56 +0300, Ignas Mikalajunas ignas.mikalajunas@gmail.com wrote:
I am not sure whether it is related yet - I was having simmilar problems with tbnl/cmucl while making mod_lisp interoperate with mod_xslt. While server was getting enough traffic it was pretty responsive yet after long pauses I was getting timeouts. Though tbnl on sbcl was working fine with such configuration. The workaround i have found was - send a ping request once in a few seconds not letting cmucl "sleep". As if one of cmucl threads was hogging all the resources and not giving any to threads that were not doing anything for a while ...
Ah, wait! You guys use
(mp::startup-idle-and-top-level-loops)
on startup, don't you? If you don't, that /could/ be the reason for the symptons you describe.
Cheers, Edi.
On 2005-08-09 16:33:00, Edi Weitz wrote:
Ah, wait! You guys use
(mp::startup-idle-and-top-level-loops)
on startup, don't you? If you don't, that /could/ be the reason for the symptons you describe.
Wasn't there a conflict with SLIME when you use this? I think I remember I've heard something regarding (mp::startup-idle-and-top-level-loops)