Handling errors - staging/production
Locked
12
12
 
|
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 |
RE: Handling errors - staging/production
|
|
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 |
Re: Handling errors - staging/production
|
|
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:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> 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 |
|
|
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 |
Re: Handling errors - staging/production
|
|
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. On May 31, 2011, at 5:56 AM, Francois Stephany wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling errors - staging/production
|
|
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 |
Re: Handling errors - staging/production
|
|
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:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling errors - staging/production
|
|
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 |
Re: Handling errors - staging/production
|
|
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:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling errors - staging/production
|
|
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 |
Re: Handling errors - staging/production
|
|
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 |
Re: Handling errors - staging/production
|
|
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 |
Re: Handling errors - staging/production
|
|
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 |
RE: Handling errors - staging/production
|
|
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 |
Re: 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 |
RE: Handling errors - staging/production
|
|
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 |
Re: Handling errors - staging/production
|
|
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 |
Re: Handling errors - staging/production
|
|
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 |
Re: Handling errors - staging/production
|
|
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 |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |