Strange behaviour

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange behaviour

FDominicus
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
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour

FDominicus
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?
Ok here some more information, it seems the error is to be searched for
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
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour

SeanTAllen
Unhandled exceptions will kill the swazoo server.

On Sat, Sep 11, 2010 at 5:05 AM, Friedrich Dominicus <[hidden email]> wrote:
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?
Ok here some more information, it seems the error is to be searched for
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

Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour

FDominicus
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
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour

SeanTAllen
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:
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

Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour

FDominicus
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
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour

SeanTAllen


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

 
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour

FDominicus
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


--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour

Dale Henrichs
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
>
>
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
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour

SeanTAllen
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:
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


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