Jim Morris
2006-Jul-09 05:59 UTC
[Backgroundrb-devel] where do uncaught exceptions printouts go?
Hi, I have a worker, which should have thrown an uncaught exception and dumped the stack in the do_work method, however I saw no dump or indication of any error in any of the logs. This makes it very hard to debug, where does stdout and or stderr go? How canb I know if it gets some kind of error? (in this case not being able to find a class). Thanks -- Jim Morris, http://blog.wolfman.com
hemant
2006-Jul-09 06:57 UTC
[Backgroundrb-devel] where do uncaught exceptions printouts go?
That is one problem with Backgroundrb with, unhandled exceptions are getting lost in wilderland. But ofcourse, whatever Erza would say will be more authorative. On 7/9/06, Jim Morris <ml at e4net.com> wrote:> > Hi, > > I have a worker, which should have thrown an uncaught exception and dumped > the stack in the do_work > method, however I saw no dump or indication of any error in any of the > logs. > > This makes it very hard to debug, where does stdout and or stderr go? How > canb I know if it gets > some kind of error? (in this case not being able to find a class). > > Thanks > > -- > Jim Morris, http://blog.wolfman.com > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060709/1acc7704/attachment.html
Klein, Michael
2006-Jul-09 16:41 UTC
[Backgroundrb-devel] where do uncaught exceptions printouts go?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version
6.5.7650.28">
<TITLE>RE: [Backgroundrb-devel] where do uncaught exceptions printouts
go?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>All my workers look like this:<BR>
<BR>
def do_work(args)<BR>
begin<BR>
# your code here ...<BR>
rescue MyHandledException => msg<BR>
# if you want to handle any errors<BR>
# before they fall through to the<BR>
# default handler<BR>
rescue Exception => boom<BR>
Thread.current.exclusive {<BR>
@logger.error(boom)<BR>
}<BR>
raise<BR>
end<BR>
end<BR>
<BR>
Works great. All unhandled exceptions go to log/backgroundrb.log<BR>
<BR>
Maybe Ezra could add the outer begin/rescue/end block to start_process, inside
the thread block, and call do_work from in there. That would do the same thing
without the worker redundancy.<BR>
<BR>
Michael<BR>
<BR>
-----Original Message-----<BR>
From: backgroundrb-devel-bounces@rubyforge.org on behalf of Jim Morris<BR>
Sent: Sun 7/9/2006 1:59 AM<BR>
To: Backgroundrb-devel@rubyforge.org<BR>
Subject: [Backgroundrb-devel] where do uncaught exceptions printouts
go?<BR>
<BR>
Hi,<BR>
<BR>
I have a worker, which should have thrown an uncaught exception and dumped the
stack in the do_work<BR>
method, however I saw no dump or indication of any error in any of the
logs.<BR>
<BR>
This makes it very hard to debug, where does stdout and or stderr go? How canb I
know if it gets<BR>
some kind of error? (in this case not being able to find a class).<BR>
<BR>
Thanks<BR>
<BR>
--<BR>
Jim Morris, <A
HREF="http://blog.wolfman.com">http://blog.wolfman.com</A><BR>
_______________________________________________<BR>
Backgroundrb-devel mailing list<BR>
Backgroundrb-devel@rubyforge.org<BR>
<A
HREF="http://rubyforge.org/mailman/listinfo/backgroundrb-devel">http://rubyforge.org/mailman/listinfo/backgroundrb-devel</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
Ezra Zygmuntowicz
2006-Jul-10 01:44 UTC
[Backgroundrb-devel] where do uncaught exceptions printouts go?
Ok, I just committed an update to the plugin. I fixed exception
handling so if your workers throw an error the full error message,
class of error and complete backtrace will get printed to the log
file. Sorry about the hassle finding this bug. It happened when I
added the job canceling and handling code. I forgot to put the begin
rescue end block inside of the Thread.new block. Its all fixed now.
I also added Michael Klien''s accessed based timestamps patch. It
doesn''t change the external interface to how you use things but it
changes the way timestamps are stored. Now timestamps are stored as a
hash of attributes instead of an array. This allows workers expiry to
act like sessions in that the time to live will be updated evey time
a worker is accessed. So it will update the timestamp when it gets
accessed and push the time to live forward again. This allows the
worker to expire based on time to live since the worker was last
accessed. So this worker will expire 300 seconds after the last time
it was accessed.
session[:job_key] = MiddleMan.new_worker(:class => :foo_worker,
:args => "Bar",
:ttl => 300,
:expire_type => :accessed )
I also added a CONTRIBUTORS file to the plugin. Please have a look
and remind me if I missed anyone who had a patch or enhancement applied.
I am in the process of adding breakpoint support to the plugin so
you can set breakpoints and inspect your workers and other state.
Along with this will be a small stats system so you can get stats
about all your running workers and timestamps and what the drb server
is working on. Should have this stuff done this week some time.
Cheers-
-Ezra
PS. Thanks everyone for using and abusing this to help ferret out any
bugs and missing features. This is a fun plugin to work on and with
and I think it will only get better.
Jim Morris
2006-Jul-12 22:36 UTC
[Backgroundrb-devel] where do uncaught exceptions printouts go?
Was this update checked into rubyforge, because script/plugin update says the plugin doesn''t exist? Ezra Zygmuntowicz wrote:> Ok, I just committed an update to the plugin. I fixed exception > handling so if your workers throw an error the full error message, > class of error and complete backtrace will get printed to the log > file. Sorry about the hassle finding this bug. It happened when I > added the job canceling and handling code. I forgot to put the begin > rescue end block inside of the Thread.new block. Its all fixed now. > > I also added Michael Klien''s accessed based timestamps patch. It > doesn''t change the external interface to how you use things but it > changes the way timestamps are stored. Now timestamps are stored as a > hash of attributes instead of an array. This allows workers expiry to > act like sessions in that the time to live will be updated evey time > a worker is accessed. So it will update the timestamp when it gets > accessed and push the time to live forward again. This allows the > worker to expire based on time to live since the worker was last > accessed. So this worker will expire 300 seconds after the last time > it was accessed. > > session[:job_key] = MiddleMan.new_worker(:class => :foo_worker, > > :args => "Bar", > > :ttl => 300, > > :expire_type => :accessed ) > > > I also added a CONTRIBUTORS file to the plugin. Please have a look > and remind me if I missed anyone who had a patch or enhancement applied. > > I am in the process of adding breakpoint support to the plugin so > you can set breakpoints and inspect your workers and other state. > Along with this will be a small stats system so you can get stats > about all your running workers and timestamps and what the drb server > is working on. Should have this stuff done this week some time. > > > Cheers- > -Ezra > > PS. Thanks everyone for using and abusing this to help ferret out any > bugs and missing features. This is a fun plugin to work on and with > and I think it will only get better. > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-- Jim Morris, http://blog.wolfman.com
Jim Morris
2006-Jul-12 22:50 UTC
[Backgroundrb-devel] where do uncaught exceptions printouts go?
Ok, actually another way which works is... > script/plugin install --force svn://rubyforge.org//var/svn/backgroundrb This re-installed and I now get the exception dump in the log, thanks. Ezra Zygmuntowicz wrote:> Jim- > > I don''t think the script/plugin will find this plugin because of the > way it works. You will have to either cd into > vendor/plugins/backgroundrb and do an svn up or do a fresh svn co of the > plugin and put it in vendor/plugins. > > Cheers- > -Ezra > > > On Jul 12, 2006, at 3:36 PM, Jim Morris wrote: > >> Was this update checked into rubyforge, because script/plugin update >> says the plugin doesn''t exist? >> >> Ezra Zygmuntowicz wrote: >>> Ok, I just committed an update to the plugin. I fixed exception >>> handling so if your workers throw an error the full error message, >>> class of error and complete backtrace will get printed to the log >>> file. Sorry about the hassle finding this bug. It happened when I >>> added the job canceling and handling code. I forgot to put the begin >>> rescue end block inside of the Thread.new block. Its all fixed now. >>> >>> I also added Michael Klien''s accessed based timestamps patch. It >>> doesn''t change the external interface to how you use things but it >>> changes the way timestamps are stored. Now timestamps are stored as a >>> hash of attributes instead of an array. This allows workers expiry to >>> act like sessions in that the time to live will be updated evey time >>> a worker is accessed. So it will update the timestamp when it gets >>> accessed and push the time to live forward again. This allows the >>> worker to expire based on time to live since the worker was last >>> accessed. So this worker will expire 300 seconds after the last time >>> it was accessed. >>> >>> session[:job_key] = MiddleMan.new_worker(:class => :foo_worker, >>> >>> :args => "Bar", >>> >>> :ttl => 300, >>> >>> :expire_type => :accessed ) >>> >>> >>> I also added a CONTRIBUTORS file to the plugin. Please have a look >>> and remind me if I missed anyone who had a patch or enhancement applied. >>> >>> I am in the process of adding breakpoint support to the plugin so >>> you can set breakpoints and inspect your workers and other state. >>> Along with this will be a small stats system so you can get stats >>> about all your running workers and timestamps and what the drb server >>> is working on. Should have this stuff done this week some time. >>> >>> >>> Cheers- >>> -Ezra >>> >>> PS. Thanks everyone for using and abusing this to help ferret out any >>> bugs and missing features. This is a fun plugin to work on and with >>> and I think it will only get better. >>> _______________________________________________ >>> Backgroundrb-devel mailing list >>> Backgroundrb-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel >>> >> >> --Jim Morris, http://blog.wolfman.com >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel >> > >-- Jim Morris, http://blog.wolfman.com