I don't know what I'm doing wrong or why this happens. but assume I have
this code: renderContentOn: html "self halt." html heading level:1; with: 'Some header'. well that works fine but if I write renderContentOn: html html header1: 'Some text'. This renders something but after that the Web Server at that Port is gone. I can't imagine a web server dying because of this. Does anyone else have an explanation for this? Regards Friedrich |
Friedrich Dominicus <[hidden email]> writes:
> I don't know what I'm doing wrong or why this happens. but assume I have > this code: > > > renderContentOn: html > "self halt." > html heading > level:1; > with: 'Some header'. > > well that works fine but if I write > renderContentOn: html > html header1: 'Some text'. > This renders something but after that the Web Server at that Port is > gone. > > I can't imagine a web server dying because of this. Does anyone else > have an explanation for this? elswhere the log says: Swazoo_server-8080.log topaz 1> GemStone Smalltalk Compiler Errors: GemToGemAnnouncement uninstallStaticHandler. System beginTransaction. (ObjectLogEntry fatal: '8080: topaz exit' object: 'port: ', Swazoo printString, ' ', * ^1 ******* 'pid: ', (System gemVersionReport at: 'processId') printString) addToLog. System commitTransaction. 1: [1031] undefined symbol So that is the trouble spot. Could it be that this is related to: runSwazoo WAGemStoneRunSeasideGems default name: 'Swazoo'; adaptorClass: WAGsSwazooAdaptor; ports: #(8080 8081). I thought I got this right after a mail here in the group. And I've used it yesterday without any troubles. But I may be wrong... Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus |
Unhandled exceptions will kill the swazoo server.
On Sat, Sep 11, 2010 at 5:05 AM, Friedrich Dominicus <[hidden email]> wrote:
|
Sean Allen <[hidden email]> writes:
> Unhandled exceptions will kill the swazoo server. Well and what can I do abou it. I can't believe that a wrong send HTML should kill the server. So what am I supposed to do to restart the server or am I not ot use Swazoo but what? during development. Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus |
You can either start swazoo in an exception handler that will catch those things ( not nec. good, what if it really is a serious exception ).
Or you could have it monitored by monit, god, daemontools or something of that ilk. Or you could fix the exception causing code.
On Mon, Sep 13, 2010 at 4:04 AM, Friedrich Dominicus <[hidden email]> wrote: Well and what can I do abou it. |
Sean Allen <[hidden email]> writes:
> You can either start swazoo in an exception handler that will catch those > things ( not nec. good, what if it really is a serious exception ). > Or you could have it monitored by monit, god, daemontools or something of that > ilk. Or you could fix the exception causing code. Thanks Sean but I simply do not get it. If I have a simple typo like html header1: 'Whatever this header could be' The server bails out? Of course I should fix the code, but a Web Server that crashes because of an invalid tag? That sounds ridicoulous rigid. Regards Friedrich |
On Mon, Sep 13, 2010 at 10:22 AM, Friedrich Dominicus <[hidden email]> wrote:
It isnt because of an invalid tag. It is because of an exception. Do you really wanting it catching all exceptions? Trying to determine what exceptions are ok to recover from and which arent?
It is doing what any program is supposed to do w/ an uncaught exception- exiting. That isnt a crash- that is expected behavior. If you don't like the behavior, you can start Swazoo inside a handler that will
eat any exception. I doubt that will work out very well though. |
Sean Allen <[hidden email]> writes:
> On Mon, Sep 13, 2010 at 10:22 AM, Friedrich Dominicus < > [hidden email]> wrote: > > Sean Allen <[hidden email]> writes: > > > You can either start swazoo in an exception handler that will catch those > > things ( not nec. good, what if it really is a serious exception ). > > Or you could have it monitored by monit, god, daemontools or something of > that > > ilk. Or you could fix the exception causing code. > Thanks Sean but I simply do not get it. If I have a simple typo like > html header1: 'Whatever this header could be' > > The server bails out? Of course I should fix the code, but a Web Server > that crashes because of an invalid tag? That sounds ridicoulous rigid. > > > > It isnt because of an invalid tag. It is because of an exception. Do you really > wanting it catching > all exceptions? exception. I just proceeded after the exceptoin and the server was gone, but while I opened a debugger and fixed the code and stopped the debugger the Server still was there. So it was my "misunderstanding". Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus |
Friedrich Dominicus wrote:
> Sean Allen <[hidden email]> writes: > >> On Mon, Sep 13, 2010 at 10:22 AM, Friedrich Dominicus < >> [hidden email]> wrote: >> >> Sean Allen <[hidden email]> writes: >> >> > You can either start swazoo in an exception handler that will catch those >> > things ( not nec. good, what if it really is a serious exception ). >> > Or you could have it monitored by monit, god, daemontools or something of >> that >> > ilk. Or you could fix the exception causing code. >> Thanks Sean but I simply do not get it. If I have a simple typo like >> html header1: 'Whatever this header could be' >> >> The server bails out? Of course I should fix the code, but a Web Server >> that crashes because of an invalid tag? That sounds ridicoulous rigid. >> >> >> >> It isnt because of an invalid tag. It is because of an exception. Do you really >> wanting it catching >> all exceptions? > I checked the code again. Yes, you're right it's not the tag but the > exception. I just proceeded after the exceptoin and the server was > gone, but while I opened a debugger and fixed the code and stopped the > debugger the Server still was there. So it was my "misunderstanding". > > Regards > Friedrich > > The Swazoo server was freshly ported to GemStone in December for Seaside3.0 support and I have not had the time to work through the Swazoo implementation and address some of the "odd" exception handling patterns. I usually recommend using FastCGI because it has been beaten on pretty heavily in my testing (over the last 3-4 years). I have tried to make sure that every exception handler in the FastCGI stack logs errors to the Object Log and the server log file...A FastCGI server can still be knocked over by certain error conditions, but I am confident that when that happens, the error condition is logged to the server log (at a minimum). I can't say the same for Swazoo as just haven't had the time to pore over the code to find the exception handlers and ensure that logging in is done. There is one exception handler that I in the original swazoo silently handled the exception ... I think that Sean has had trouble with that spot off and on and possibly you are running into the same problem ... It appears that the exception handler gets triggered a whole lot under "normal conditions" which I don't think is the right thing to do, so I'm assuming that there is more work needed to straighten the error handling out ... Dale |
I did indeed run into that issue. We addressed by monitoring the swazoo adapters and restarted when needed. The monitoring was two fold:
1. monitor w/ something like daemontools. 2. use nginx to monitor the backend and not send to non responding swazoo's until the monitor check was done ( every couple minutes ).
This worked for the most part and we had minimal issues as an overall % of traffic.
On Wed, Sep 22, 2010 at 1:28 PM, Dale Henrichs <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |