|How to handle exceptions the right way||Adrien Kohlbecker||3/24/13 8:59 AM|
I'm working with ludovic_ on the ruote-resque implementation, and I was wondering what's the best way to handle errors raised inside remote processes
There seems to be different implementations in ruote-amqp and ruote-nats/ruote-beanstalk
At the moment, I'm sending back a workitem with an 'error' key and the receiver calls @context.error_handler.action_handle('error', fei, error)
But in ruote-amqp, you use the flunk method, which does not seem to work in my tests (it does not display an error in ruote-kit)
How would you go about implementing this ?
The work in progress is hosted at https://github.com/adrienkohlbecker/ruote-resque
|Re: [ruote:4033] How to handle exceptions the right way||John Mettraux||3/24/13 2:31 PM|
welcome to ruote's mailing list.
Ruote-amqp should be followed (it's the most recent of the three iirc).
I added an assertion to the error propagation specs in ruote-amqp:
The error makes it in. Ruote-kit should display it. Maybe it's something
else. If you can provide a way to reproduce the issue, that'd be great.
Very nice :-) Looking forward to see it completed.
John Mettraux - http://lambda.io/jmettraux
|Re: [ruote:4033] How to handle exceptions the right way||Adrien Kohlbecker||3/29/13 9:09 AM|
Just a follow up regarding this issue with errors not bubbling up Ruote when using flunk :
It seems that when I switch to FsStorage, it works. (I was using ruote-postgres which would be our backend of choice when we deploy ruote)
I put this specific issue aside for the time being, but now I'm running into another issue with storage, this time with HashStorage.
When I run the specs of ruote-resque using FsStorage, they pass. When I change the storage to HashStorage, they fail.
I don't know if the two issues share the same root cause, but they seem related.
What do you think ?
If you would like to reproduce the issue, the spec is at /spec/lib/ruote/resque/receiver_spec.rb
|Re: [ruote:4038] How to handle exceptions the right way||John Mettraux||3/29/13 6:20 PM|
ruote-postgres is very young, looking at the commit messages, it doesn't seem
ready for now. Maybe you'd better use ruote-sequel until the ruote-postgres
team announces their library as ready.
FsStorage "naturally" makes deep copy of the documents it stores. Maybe the
HashStorage issue is related to mutability (storing something that's modified
OK, I'll try it with the HashStorage. Give me a few days though.
|Re: [ruote:4038] How to handle exceptions the right way||John Mettraux||4/1/13 11:44 PM|
> > I put this specific issue aside for the time being, but now I'm running> > (...)
> >Salut Adrien,
I gave it a try and and it broke for me too, but it's nothing serious.
The first thing I noticed: in line 52 of the spec,
system('rm -rf spec/tmp/ruote_work')
is FsStorage specific. The better way to do it (works with all well-behaved
The second thing: the receiver in the spec is instantiated and bound to
Resque but it's never shut down. When running the specs one by one they are
successful, when running them all, previous receivers fetch the work of the
current spec receiver... With FsStorage it looks alright, since the storage
is filesystem backed whatever ruote worker + fs storage pair picks up, it
ends up in the fs... With the HashStorage, the old receiver feeds the flunk
message to its old HashStorage whose Worker was carefully shut down by your
after(:each) block. The flunk msg just disappears...
You have to shut down the old receiver before the new spec interprets.
I hope it helps, meilleures salutations,
|Re: [ruote:4038] How to handle exceptions the right way||Adrien Kohlbecker||4/2/13 1:14 AM|
Thanks John, it does work indeed if I kill the listener thread :)