What are weblocks Failure-modes, and recommendation for a production website

[ashar]

I ran weblocks clsql demo. Runs OK.

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).

The web-server (hunchentoot) running the weblocks demo becomes unresponsive, until restarted.

Is this normal? Should'nt it just show empty field, or give a record not found runtime error to the user, instead

of throwing an error condtion and halting  the webserver.

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.

[Scott L. Burson]

Hmm, I'm not sure why the server is becoming unresponsive.

You can run Weblocks in either normal mode or debug mode.  In normal mode, errors are trapped and cause an (uninformative) "internal error" popup to be displayed by the browser.  In debug mode, at least if you're using SLIME, you should be able to poke around in the debugger to figure out what happened and then use the appropriate SLDB option to kill the thread that got the error.

In either case, new server threads should be started automatically to serve subsequent requests.  I haven't seen the behavior you're describing.  What platform are you using?  I'm running on SBCL, on Linux.

-- Scott

 

[Nandan Bagchee]

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

 

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.

 

Is this normal? Should'nt it just show empty field, or give a record not found runtime error to the user, instead

of throwing an error condtion and halting  the webserver.

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. 

Unless you are running a single-threaded lisp, which I would wager you are doing.

 

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).

 

[ashar]

On Monday, April 9, 2012 9:07:58 AM UTC-7, Scott L. Burson wrote:

In either case, new server threads should be started automatically to serve subsequent requests.  I haven't seen the behavior you're describing.  What platform are you using?  I'm running on SBCL, on Linux.

Thank you for the information.

Problem was due to cookies set by weblocks, which rewrites (or redirects) the home page to the last employees (or other data) view.

I browse with weblocks-clsql-demo at localhost:8080/   and it gives a static page with links. Clicking on the "Next" Link takes to employees etc navigation. Employee page gets stuck due to NIL class (due to the induced error for testing).

Then I try localhost:8080/ again (on a new browser tab or window), and that page also stucks (no new error at SLIME). That's why I thought that the whole webserver got stuck. Clearing a weblocks session cookie, gives back the static page at localhost:8080/

 

[Nandan Bagchee]

What lisp are you using?
What OS?

--
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/-/atwMxi8L16kJ.
To post to this group, send email to webl...@googlegroups.com.
To unsubscribe from this group, send email to weblocks+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.

[ashar]

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.

2) It took me many iterations of running into all sorts of runtime errors and even javascript internal-errors, trying to make weblocks-clsql-demo work on Linux or MacOS (based on changes suggested in various threads). I am using quicklisp's March 30th dependency libraries on SBCL 1.53/MacOS. Hence an impression of fragile weblocks environment was formed (mainly due to incompatible libraries versions, not the weblocks code itself). It was not until I got a private patch of clsql-fluid from Scott (in this forum last week), that clsql-demo worked.

 

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. :-)