Handling errors - staging/production

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

Handling errors - staging/production

fstephany
What is the preferred way to handle errors on a production seaside
application? Is there some kind of http://www.hoptoadapp.com/ to handle
applications crashes/walkback?

How do you typically do to handle errors?

Cheers,
Francois

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Handling errors - staging/production

Boris Popov, DeepCove Labs (SNN)
We implement our own subclass of WAHtmlErrorHandler which logs the exception and sends email notification before presenting an error page to the browser,

| app |
app := WAAdmin register: self asApplicationAt: 'online'.
app filter configuration at: #exceptionHandler put: WebErrorHandler.

WebErrorHandler>>handleDefault: ex
 Manager
   notifyUnhandledException: ex
   in: self
   fatal: false.
 super handleDefault: ex.

Hope this helps,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Francois Stephany
Sent: 30 May 2011 13:42
To: [hidden email]
Subject: [Seaside] Handling errors - staging/production

What is the preferred way to handle errors on a production seaside application? Is there some kind of http://www.hoptoadapp.com/ to handle applications crashes/walkback?

How do you typically do to handle errors?

Cheers,
Francois

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

sebastianconcept@gmail.co
In reply to this post by fstephany
Hey Francois,

for airflowing we did it like this:

server side works in two stages:

first (optimist case) a custom error handler clones the walkback of the exception and redirects the app to a custom error page (a tiny little very simple seaside app.) So, this page gives the user the option to write us about what was she doing or just click on "login again." In either case, the walkback reach us printed in an email along with the user who had the problem so we can provide support or notify her about an upgrade that had fixed the issue.

second, if things goes really bad, it falls back to a simple page saying that some less gentle error happened :)

and if the exception happens in the DOM side, it works like this:

the exception is captured in the onError handler and it reacts redirecting to the error page previously described.  Obviously this time we have no useful walkback but I've made it to print the component where that happened so at least I have something about the bug 




On May 30, 2011, at 2:41 PM, Francois Stephany wrote:

What is the preferred way to handle errors on a production seaside application? Is there some kind of http://www.hoptoadapp.com/ to handle applications crashes/walkback?

How do you typically do to handle errors?

Cheers,
Francois

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside




_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

fstephany
> first (optimist case) a custom error handler clones the walkback of the
> exception and redirects the app to a custom error page (a tiny little
> very simple seaside app.) So, this page gives the user the option to
> write us about what was she doing or just click on "login again." In
> either case, the walkback reach us printed in an email along with the
> user who had the problem so we can provide support or notify her about
> an upgrade that had fixed the issue.

Interesting !
I dont need such a level of feedback from the user but the process seems
nice.

> second, if things goes really bad, it falls back to a simple page saying
> that some less gentle error happened :)

What do you mean with 'goes really bad' ? I guess it means that your
image is not responding anymore ?

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

fstephany
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Thanks !
It's exactly what I need :)

> We implement our own subclass of WAHtmlErrorHandler which logs the exception and sends email notification before presenting an error page to the browser,
>
> | app |
> app := WAAdmin register: self asApplicationAt: 'online'.
> app filter configuration at: #exceptionHandler put: WebErrorHandler.
>
> WebErrorHandler>>handleDefault: ex
>   Manager
>     notifyUnhandledException: ex
>     in: self
>     fatal: false.
>   super handleDefault: ex.
>
> Hope this helps,

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

sebastianconcept@gmail.co
In reply to this post by fstephany
We were using monit for a while but then it didn't quite fit our needs. So, we made a little seaside app we (use internally) that can be configured to monitor a cluster of worker-images (serving the real web apps) 

When a worker is unresponsive for any reason it will receive a gentle kill -15 and if it's still there, say 30sec after the signal, it will receive a kill -9 (checking if it really isn't there anymore) and then it will be restarted.

So, by 'goes really bad' I mean (inside one of this workers) an exception that your custom error handler (like the one Boris show) didn't catch (a bug in the http server used by seaside can do that for example). Actually is rare. It didn't happen to us in production but happened in development a couple of times... I think I was implementing x-sendfile or something unusual.



On May 31, 2011, at 5:56 AM, Francois Stephany wrote:

first (optimist case) a custom error handler clones the walkback of the
exception and redirects the app to a custom error page (a tiny little
very simple seaside app.) So, this page gives the user the option to
write us about what was she doing or just click on "login again." In
either case, the walkback reach us printed in an email along with the
user who had the problem so we can provide support or notify her about
an upgrade that had fixed the issue.

Interesting !
I dont need such a level of feedback from the user but the process seems nice.

second, if things goes really bad, it falls back to a simple page saying
that some less gentle error happened :)

What do you mean with 'goes really bad' ? I guess it means that your image is not responding anymore ?

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside






_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

Ramon Leon-5
On 05/31/2011 05:51 AM, Sebastian Sastre wrote:
> We were using monit <http://mmonit.com/monit/> for a while but then it
> didn't quite fit our needs.

I'm curious why not?  I love monit, what did you find wrong with it?

--
Ramon Leon
http://onsmalltalk.com
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

sebastianconcept@gmail.co
for us monit was nice for quite a while but every now and then it kind of failed to shutdown some resilient unresponsive images. It seems that it relies too much in a gentle SIGTERM. And for most cases is actually okay but zombies aren't gentle. In practice you could end up with a unresponsive image that resist to shutdown for any reason but you need it to shutdown the bastard but the bish is ignoring your SIGTERMs so... you need to SIGKILL them :)


o/

On May 31, 2011, at 12:41 PM, Ramon Leon wrote:

On 05/31/2011 05:51 AM, Sebastian Sastre wrote:
We were using monit <http://mmonit.com/monit/> for a while but then it
didn't quite fit our needs.

I'm curious why not?  I love monit, what did you find wrong with it?

--
Ramon Leon
http://onsmalltalk.com
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside






_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

Ramon Leon-5
On 05/31/2011 10:47 AM, Sebastian Sastre wrote:
> for us monit was nice for quite a while but every now and then it kind
> of failed to shutdown some resilient unresponsive images. It seems that
> it relies too much in a gentle SIGTERM. And for most cases is actually
> okay but zombies aren't gentle. In practice you could end up with a
> unresponsive image that resist to shutdown for any reason but you need
> it to shutdown the bastard but the bish is ignoring your SIGTERMs so...
> you need to SIGKILL them :)

I'm not sure I'm following; monit doesn't kill anything, it just invokes
a kill script you give it.  Your kill script can do whatever you want,
SIGTERM, wait a bit, and SIGKILL if not dead yet, that's up to your kill
script.  What does this have anything to do with monit?

--
Ramon Leon
http://onsmalltalk.com
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

sebastianconcept@gmail.co
gee... it was a long ago...

I just got pissed off by not knowing where the problem was so I've simplified everything just in case.

Unsurprisingly, once redesigned, things started to work as expected.

I also remember making something similar to Coral at the time (to make more clever that script you mention). I've tried Coral but it was missing something I needed badly so I made something a lot simpler to have that solved fast.

The combination of the two things solved our problem.

So I guess your question remains and I can't tell if monit was part of the problem or not. Maybe not. Probably was the script but I think I've tried that (I can't recall that) fortunately, there is a long time since I really don't care anymore :)

The only thing that matters is that it was a fast move to redefine the problem "moving it" to a more predictable domain and it worked wonderfully (and, not surprisingly, it was using more smalltalk and less "stuff")


On May 31, 2011, at 3:09 PM, Ramon Leon wrote:

On 05/31/2011 10:47 AM, Sebastian Sastre wrote:
for us monit was nice for quite a while but every now and then it kind
of failed to shutdown some resilient unresponsive images. It seems that
it relies too much in a gentle SIGTERM. And for most cases is actually
okay but zombies aren't gentle. In practice you could end up with a
unresponsive image that resist to shutdown for any reason but you need
it to shutdown the bastard but the bish is ignoring your SIGTERMs so...
you need to SIGKILL them :)

I'm not sure I'm following; monit doesn't kill anything, it just invokes a kill script you give it.  Your kill script can do whatever you want, SIGTERM, wait a bit, and SIGKILL if not dead yet, that's up to your kill script.  What does this have anything to do with monit?

--
Ramon Leon
http://onsmalltalk.com
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside






_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

John Toohey
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Seaside has an abstract class, WAEmailErrorHandler that will email the
stack traces. Just found it, but when I ran my app with a handler
based on that, it prompted for an SMTP server, which I gave it, but
not password/account info. The code called then failed contacting the
server, but I cannot find where in the image to change the credentials
for the SMTP server.

Has anyone ever used this handler, or knows how to re-configure the
MailSender class?

On Mon, May 30, 2011 at 13:46, Boris Popov, DeepCove Labs
<[hidden email]> wrote:

> We implement our own subclass of WAHtmlErrorHandler which logs the exception and sends email notification before presenting an error page to the browser,
>
> | app |
> app := WAAdmin register: self asApplicationAt: 'online'.
> app filter configuration at: #exceptionHandler put: WebErrorHandler.
>
> WebErrorHandler>>handleDefault: ex
>  Manager
>   notifyUnhandledException: ex
>   in: self
>   fatal: false.
>  super handleDefault: ex.
>
> Hope this helps,
>
> -Boris
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Francois Stephany
> Sent: 30 May 2011 13:42
> To: [hidden email]
> Subject: [Seaside] Handling errors - staging/production
>
> What is the preferred way to handle errors on a production seaside application? Is there some kind of http://www.hoptoadapp.com/ to handle applications crashes/walkback?
>
> How do you typically do to handle errors?
>
> Cheers,
> Francois
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>



--
~JT
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

Ramon Leon-5
On 06/01/2011 09:50 PM, John Toohey wrote:
> Seaside has an abstract class, WAEmailErrorHandler that will email the
> stack traces. Just found it, but when I ran my app with a handler
> based on that, it prompted for an SMTP server, which I gave it, but
> not password/account info. The code called then failed contacting the
> server, but I cannot find where in the image to change the credentials
> for the SMTP server.

There are none, it's expecting an open SMTP server on your local
network, not one that requires authentication on the net.

--
Ramon Leon
http://onsmalltalk.com
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

Yanni Chiu
On 02/06/11 1:00 AM, Ramon Leon wrote:

> On 06/01/2011 09:50 PM, John Toohey wrote:
>> Seaside has an abstract class, WAEmailErrorHandler that will email the
>> stack traces. Just found it, but when I ran my app with a handler
>> based on that, it prompted for an SMTP server, which I gave it, but
>> not password/account info. The code called then failed contacting the
>> server, but I cannot find where in the image to change the credentials
>> for the SMTP server.
>
> There are none, it's expecting an open SMTP server on your local
> network, not one that requires authentication on the net.

I add this method to my image:

SMTPClient class>>deliverMailFrom: fromAddress to: recipientList text:
messageText usingServer: serverName user: user password: password

   | smtpClient |
   smtpClient := self openOnHostNamed: serverName.
   smtpClient user: user.
   smtpClient password: password.
   [smtpClient login.
   smtpClient mailFrom: fromAddress to: recipientList text: messageText.
   smtpClient quit]
     ensure: [smtpClient close]

I thought I was the only one that needed it.
Should it be added to Pharo/Squeak?

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

John Toohey
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Can you show the actual code that you are using? I've setup Postfix
relaying to GMail on my laptop, and am using the WAEMailErrorHandler,
but while I can get one message sent, I then usually get a
WAIllegalStateException in the image. I'm not really sure if I am
handling the exception correctly, but what I want to do it log/email
it, and then have the app try to continue.

Thanks.


On Mon, May 30, 2011 at 13:46, Boris Popov, DeepCove Labs
<[hidden email]> wrote:

> We implement our own subclass of WAHtmlErrorHandler which logs the exception and sends email notification before presenting an error page to the browser,
>
> | app |
> app := WAAdmin register: self asApplicationAt: 'online'.
> app filter configuration at: #exceptionHandler put: WebErrorHandler.
>
> WebErrorHandler>>handleDefault: ex
>  Manager
>   notifyUnhandledException: ex
>   in: self
>   fatal: false.
>  super handleDefault: ex.
>
> Hope this helps,
>
> -Boris
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Francois Stephany
> Sent: 30 May 2011 13:42
> To: [hidden email]
> Subject: [Seaside] Handling errors - staging/production
>
> What is the preferred way to handle errors on a production seaside application? Is there some kind of http://www.hoptoadapp.com/ to handle applications crashes/walkback?
>
> How do you typically do to handle errors?
>
> Cheers,
> Francois
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>



--
~JT
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Handling errors - staging/production

Boris Popov, DeepCove Labs (SNN)
John,

We use our own mail handling system on top of clients provided by VisualWorks, so verbatim examples wouldn't be helpful to you, but here are some snippets,

client := (SMTPClient new)
                hostName: host;
                user: (NetUser username: username password: password);
                yourself.
message := (MailMessage newTextPlain)
                from: from;
                replyTo: from;
                to: to;
                cc: cc;
                bcc: bcc;
                date: Timestamp now;
                subject: subject;
                text: body;
                yourself.
mimes do: [:each | message addAttachment: each].
message prepareForTransport.
client send: message.

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of John Toohey
Sent: 02 June 2011 12:12
To: Seaside - general discussion
Subject: Re: [Seaside] Handling errors - staging/production

Can you show the actual code that you are using? I've setup Postfix relaying to GMail on my laptop, and am using the WAEMailErrorHandler, but while I can get one message sent, I then usually get a WAIllegalStateException in the image. I'm not really sure if I am handling the exception correctly, but what I want to do it log/email it, and then have the app try to continue.

Thanks.


On Mon, May 30, 2011 at 13:46, Boris Popov, DeepCove Labs <[hidden email]> wrote:

> We implement our own subclass of WAHtmlErrorHandler which logs the
> exception and sends email notification before presenting an error page
> to the browser,
>
> | app |
> app := WAAdmin register: self asApplicationAt: 'online'.
> app filter configuration at: #exceptionHandler put: WebErrorHandler.
>
> WebErrorHandler>>handleDefault: ex
>  Manager
>   notifyUnhandledException: ex
>   in: self
>   fatal: false.
>  super handleDefault: ex.
>
> Hope this helps,
>
> -Boris
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Francois Stephany
> Sent: 30 May 2011 13:42
> To: [hidden email]
> Subject: [Seaside] Handling errors - staging/production
>
> What is the preferred way to handle errors on a production seaside application? Is there some kind of http://www.hoptoadapp.com/ to handle applications crashes/walkback?
>
> How do you typically do to handle errors?
>
> Cheers,
> Francois
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>


--
~JT
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

John Toohey
I have that with the Seaside class, but am not sure what to do beyond
that (if anything). Should I send a redirect to an error page or
handle the exception some other way. On my production servers, I often
see socket timeout errors etc., and would like to just have these
emailed/logged to disk, and not have the debugger come up in the
image.

On Thu, Jun 2, 2011 at 12:19, Boris Popov, DeepCove Labs
<[hidden email]> wrote:

> John,
>
> We use our own mail handling system on top of clients provided by VisualWorks, so verbatim examples wouldn't be helpful to you, but here are some snippets,
>
> client := (SMTPClient new)
>                hostName: host;
>                user: (NetUser username: username password: password);
>                yourself.
> message := (MailMessage newTextPlain)
>                from: from;
>                replyTo: from;
>                to: to;
>                cc: cc;
>                bcc: bcc;
>                date: Timestamp now;
>                subject: subject;
>                text: body;
>                yourself.
> mimes do: [:each | message addAttachment: each].
> message prepareForTransport.
> client send: message.
>
> -Boris
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of John Toohey
> Sent: 02 June 2011 12:12
> To: Seaside - general discussion
> Subject: Re: [Seaside] Handling errors - staging/production
>
> Can you show the actual code that you are using? I've setup Postfix relaying to GMail on my laptop, and am using the WAEMailErrorHandler, but while I can get one message sent, I then usually get a WAIllegalStateException in the image. I'm not really sure if I am handling the exception correctly, but what I want to do it log/email it, and then have the app try to continue.
>
> Thanks.
>
>
> On Mon, May 30, 2011 at 13:46, Boris Popov, DeepCove Labs <[hidden email]> wrote:
>> We implement our own subclass of WAHtmlErrorHandler which logs the
>> exception and sends email notification before presenting an error page
>> to the browser,
>>
>> | app |
>> app := WAAdmin register: self asApplicationAt: 'online'.
>> app filter configuration at: #exceptionHandler put: WebErrorHandler.
>>
>> WebErrorHandler>>handleDefault: ex
>>  Manager
>>   notifyUnhandledException: ex
>>   in: self
>>   fatal: false.
>>  super handleDefault: ex.
>>
>> Hope this helps,
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Francois Stephany
>> Sent: 30 May 2011 13:42
>> To: [hidden email]
>> Subject: [Seaside] Handling errors - staging/production
>>
>> What is the preferred way to handle errors on a production seaside application? Is there some kind of http://www.hoptoadapp.com/ to handle applications crashes/walkback?
>>
>> How do you typically do to handle errors?
>>
>> Cheers,
>> Francois
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
>
>
> --
> ~JT
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>



--
~JT
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Handling errors - staging/production

Boris Popov, DeepCove Labs (SNN)
John,

You can configure the content rendered by your exception handler class using,

#titleForException:
#updateHtmlRoot:forException:
#renderContentForException:on:

Only WAWalkbackErrorHandler should be opening a debugger on the server, once you install your own handler which is subclassed from WAErrorHandler, it won't be doing it by default.

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of John Toohey
Sent: 02 June 2011 13:06
To: Seaside - general discussion
Subject: Re: [Seaside] Handling errors - staging/production

I have that with the Seaside class, but am not sure what to do beyond that (if anything). Should I send a redirect to an error page or handle the exception some other way. On my production servers, I often see socket timeout errors etc., and would like to just have these emailed/logged to disk, and not have the debugger come up in the image.

On Thu, Jun 2, 2011 at 12:19, Boris Popov, DeepCove Labs <[hidden email]> wrote:

> John,
>
> We use our own mail handling system on top of clients provided by
> VisualWorks, so verbatim examples wouldn't be helpful to you, but here
> are some snippets,
>
> client := (SMTPClient new)
>                hostName: host;
>                user: (NetUser username: username password: password);
>                yourself.
> message := (MailMessage newTextPlain)
>                from: from;
>                replyTo: from;
>                to: to;
>                cc: cc;
>                bcc: bcc;
>                date: Timestamp now;
>                subject: subject;
>                text: body;
>                yourself.
> mimes do: [:each | message addAttachment: each].
> message prepareForTransport.
> client send: message.
>
> -Boris
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of John
> Toohey
> Sent: 02 June 2011 12:12
> To: Seaside - general discussion
> Subject: Re: [Seaside] Handling errors - staging/production
>
> Can you show the actual code that you are using? I've setup Postfix relaying to GMail on my laptop, and am using the WAEMailErrorHandler, but while I can get one message sent, I then usually get a WAIllegalStateException in the image. I'm not really sure if I am handling the exception correctly, but what I want to do it log/email it, and then have the app try to continue.
>
> Thanks.
>
>
> On Mon, May 30, 2011 at 13:46, Boris Popov, DeepCove Labs <[hidden email]> wrote:
>> We implement our own subclass of WAHtmlErrorHandler which logs the
>> exception and sends email notification before presenting an error
>> page to the browser,
>>
>> | app |
>> app := WAAdmin register: self asApplicationAt: 'online'.
>> app filter configuration at: #exceptionHandler put: WebErrorHandler.
>>
>> WebErrorHandler>>handleDefault: ex
>>  Manager
>>   notifyUnhandledException: ex
>>   in: self
>>   fatal: false.
>>  super handleDefault: ex.
>>
>> Hope this helps,
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Francois Stephany
>> Sent: 30 May 2011 13:42
>> To: [hidden email]
>> Subject: [Seaside] Handling errors - staging/production
>>
>> What is the preferred way to handle errors on a production seaside application? Is there some kind of http://www.hoptoadapp.com/ to handle applications crashes/walkback?
>>
>> How do you typically do to handle errors?
>>
>> Cheers,
>> Francois
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
>
>
> --
> ~JT
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>


--
~JT
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

John Toohey
Forgot to mention, that I'm using SS 3.0. I don't have those methods
in WAExceptionHandler or its subclasses. I do have a #handleDefault,
and I override that method to send the email, and then I do a
redirect. However, I still get a WAIllegalStateException after that,
which fires the debugger in the image.

On Thu, Jun 2, 2011 at 13:10, Boris Popov, DeepCove Labs
<[hidden email]> wrote:

> John,
>
> You can configure the content rendered by your exception handler class using,
>
> #titleForException:
> #updateHtmlRoot:forException:
> #renderContentForException:on:
>
> Only WAWalkbackErrorHandler should be opening a debugger on the server, once you install your own handler which is subclassed from WAErrorHandler, it won't be doing it by default.
>
> -Boris
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of John Toohey
> Sent: 02 June 2011 13:06
> To: Seaside - general discussion
> Subject: Re: [Seaside] Handling errors - staging/production
>
> I have that with the Seaside class, but am not sure what to do beyond that (if anything). Should I send a redirect to an error page or handle the exception some other way. On my production servers, I often see socket timeout errors etc., and would like to just have these emailed/logged to disk, and not have the debugger come up in the image.
>
> On Thu, Jun 2, 2011 at 12:19, Boris Popov, DeepCove Labs <[hidden email]> wrote:
>> John,
>>
>> We use our own mail handling system on top of clients provided by
>> VisualWorks, so verbatim examples wouldn't be helpful to you, but here
>> are some snippets,
>>
>> client := (SMTPClient new)
>>                hostName: host;
>>                user: (NetUser username: username password: password);
>>                yourself.
>> message := (MailMessage newTextPlain)
>>                from: from;
>>                replyTo: from;
>>                to: to;
>>                cc: cc;
>>                bcc: bcc;
>>                date: Timestamp now;
>>                subject: subject;
>>                text: body;
>>                yourself.
>> mimes do: [:each | message addAttachment: each].
>> message prepareForTransport.
>> client send: message.
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of John
>> Toohey
>> Sent: 02 June 2011 12:12
>> To: Seaside - general discussion
>> Subject: Re: [Seaside] Handling errors - staging/production
>>
>> Can you show the actual code that you are using? I've setup Postfix relaying to GMail on my laptop, and am using the WAEMailErrorHandler, but while I can get one message sent, I then usually get a WAIllegalStateException in the image. I'm not really sure if I am handling the exception correctly, but what I want to do it log/email it, and then have the app try to continue.
>>
>> Thanks.
>>
>>
>> On Mon, May 30, 2011 at 13:46, Boris Popov, DeepCove Labs <[hidden email]> wrote:
>>> We implement our own subclass of WAHtmlErrorHandler which logs the
>>> exception and sends email notification before presenting an error
>>> page to the browser,
>>>
>>> | app |
>>> app := WAAdmin register: self asApplicationAt: 'online'.
>>> app filter configuration at: #exceptionHandler put: WebErrorHandler.
>>>
>>> WebErrorHandler>>handleDefault: ex
>>>  Manager
>>>   notifyUnhandledException: ex
>>>   in: self
>>>   fatal: false.
>>>  super handleDefault: ex.
>>>
>>> Hope this helps,
>>>
>>> -Boris
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of
>>> Francois Stephany
>>> Sent: 30 May 2011 13:42
>>> To: [hidden email]
>>> Subject: [Seaside] Handling errors - staging/production
>>>
>>> What is the preferred way to handle errors on a production seaside application? Is there some kind of http://www.hoptoadapp.com/ to handle applications crashes/walkback?
>>>
>>> How do you typically do to handle errors?
>>>
>>> Cheers,
>>> Francois
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>>
>>
>>
>>
>> --
>> ~JT
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
>
>
> --
> ~JT
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>



--
~JT
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

John Toohey
I see the last exception is thrown because I'm using a
WAStreamResponse, and its already committed. At this stage I would
just like to redirect to an error page, and have the user log back in.
Is there any way to exit the chain, and perform a redirect?


On Thu, Jun 2, 2011 at 13:39, John Toohey <[hidden email]> wrote:

> Forgot to mention, that I'm using SS 3.0. I don't have those methods
> in WAExceptionHandler or its subclasses. I do have a #handleDefault,
> and I override that method to send the email, and then I do a
> redirect. However, I still get a WAIllegalStateException after that,
> which fires the debugger in the image.
>
> On Thu, Jun 2, 2011 at 13:10, Boris Popov, DeepCove Labs
> <[hidden email]> wrote:
>> John,
>>
>> You can configure the content rendered by your exception handler class using,
>>
>> #titleForException:
>> #updateHtmlRoot:forException:
>> #renderContentForException:on:
>>
>> Only WAWalkbackErrorHandler should be opening a debugger on the server, once you install your own handler which is subclassed from WAErrorHandler, it won't be doing it by default.
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of John Toohey
>> Sent: 02 June 2011 13:06
>> To: Seaside - general discussion
>> Subject: Re: [Seaside] Handling errors - staging/production
>>
>> I have that with the Seaside class, but am not sure what to do beyond that (if anything). Should I send a redirect to an error page or handle the exception some other way. On my production servers, I often see socket timeout errors etc., and would like to just have these emailed/logged to disk, and not have the debugger come up in the image.
>>
>> On Thu, Jun 2, 2011 at 12:19, Boris Popov, DeepCove Labs <[hidden email]> wrote:
>>> John,
>>>
>>> We use our own mail handling system on top of clients provided by
>>> VisualWorks, so verbatim examples wouldn't be helpful to you, but here
>>> are some snippets,
>>>
>>> client := (SMTPClient new)
>>>                hostName: host;
>>>                user: (NetUser username: username password: password);
>>>                yourself.
>>> message := (MailMessage newTextPlain)
>>>                from: from;
>>>                replyTo: from;
>>>                to: to;
>>>                cc: cc;
>>>                bcc: bcc;
>>>                date: Timestamp now;
>>>                subject: subject;
>>>                text: body;
>>>                yourself.
>>> mimes do: [:each | message addAttachment: each].
>>> message prepareForTransport.
>>> client send: message.
>>>
>>> -Boris
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of John
>>> Toohey
>>> Sent: 02 June 2011 12:12
>>> To: Seaside - general discussion
>>> Subject: Re: [Seaside] Handling errors - staging/production
>>>
>>> Can you show the actual code that you are using? I've setup Postfix relaying to GMail on my laptop, and am using the WAEMailErrorHandler, but while I can get one message sent, I then usually get a WAIllegalStateException in the image. I'm not really sure if I am handling the exception correctly, but what I want to do it log/email it, and then have the app try to continue.
>>>
>>> Thanks.
>>>
>>>
>>> On Mon, May 30, 2011 at 13:46, Boris Popov, DeepCove Labs <[hidden email]> wrote:
>>>> We implement our own subclass of WAHtmlErrorHandler which logs the
>>>> exception and sends email notification before presenting an error
>>>> page to the browser,
>>>>
>>>> | app |
>>>> app := WAAdmin register: self asApplicationAt: 'online'.
>>>> app filter configuration at: #exceptionHandler put: WebErrorHandler.
>>>>
>>>> WebErrorHandler>>handleDefault: ex
>>>>  Manager
>>>>   notifyUnhandledException: ex
>>>>   in: self
>>>>   fatal: false.
>>>>  super handleDefault: ex.
>>>>
>>>> Hope this helps,
>>>>
>>>> -Boris
>>>>
>>>> -----Original Message-----
>>>> From: [hidden email]
>>>> [mailto:[hidden email]] On Behalf Of
>>>> Francois Stephany
>>>> Sent: 30 May 2011 13:42
>>>> To: [hidden email]
>>>> Subject: [Seaside] Handling errors - staging/production
>>>>
>>>> What is the preferred way to handle errors on a production seaside application? Is there some kind of http://www.hoptoadapp.com/ to handle applications crashes/walkback?
>>>>
>>>> How do you typically do to handle errors?
>>>>
>>>> Cheers,
>>>> Francois
>>>>
>>>> _______________________________________________
>>>> seaside mailing list
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>
>>>> _______________________________________________
>>>> seaside mailing list
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ~JT
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>>
>>
>>
>>
>> --
>> ~JT
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
>
>
> --
> ~JT
>



--
~JT
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Handling errors - staging/production

Philippe Marschall
2011/6/2 John Toohey <[hidden email]>:
> I see the last exception is thrown because I'm using a
> WAStreamResponse, and its already committed. At this stage I would
> just like to redirect to an error page, and have the user log back in.
> Is there any way to exit the chain, and perform a redirect?

You can't. Once the response it committed the bytes are on the client
(or at least on their way). You can try to send a JavaScript that does
a redirect but that may not work. If you're uncool with this behavior
don't use streaming.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
12