On Tuesday, April 10, 2012 12:19:06 AM UTC-7, nunb wrote:
Then I delete a row in Company table that is linked to an employee in another table.
Run the employee page (that lists them).
Got an error There is no method
#<STANDARD-GENERIC-FUNCTION WEBLOCKS-CLSQL-DEMO::COMPANY-NAME (1)>
when called with arguments (NIL).
Then simply create the GF for the value nil
Thanks. Added defmethod for NIL
The web-server (hunchentoot) running the weblocks demo becomes unresponsive, until restarted.
If you mean that page hangs, then you're probably in debug mode, and your lisp is displaying a stacktrace to help you debug the error. And you can fix it live, and then the page will render (if the browser hasn't already timed out). This is a GOOD thing.
The problem was fixed by deleting cookies (posted above). I had tried both normal and debug modes.
It hasn't halted the webserver. If you open another tab to the same site (localhost?) the webserver wll spin up another thread to service the new request.
That's the expected behavior but got confused because:
1) The same main page "url" was giving a static page or a class view depending on session cookies, so unresponsive main page (that I wrongly expected to show only a static text page) gave the impression that new listen threads are not being served.
Unless you are running a single-threaded lisp, which I would wager you are doing.
I had tested both on SBCL/Centos and SBCL/MacOS 10.6.8 (compiled sbcl with threading feature on Mac)
Does that mean that unless all parts of a web application are written very carefully, making sure that all error exceptions/conditions
are caught, a single runtime error can make the webserver stuck.
I don't even know how to respond to this. If you want help please thoroughly describe your stack (OS, lisp, libraries etc).
I did consider the possibility that the weblocks author assumed that user is responsible to catch all error conditions (at least at some catch-all level), if they want to keep the web server alive (even if it is an independent listener library). This made more sense when I compared it to a more absurd assumption on hand: that weblock author could not imagine a good lisp programmer ever writing incorrect code.
You received this message because you are subscribed to the Google Groups "weblocks" group.
To view this discussion on the web visit https://groups.google.com/d/msg/weblocks/-/jSiRfgNNXsAJ
To post to this group, send email to weblocks-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to weblocks+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.