ruote tmp/log_2011-06-22.html

2011-06-22 06:52:08 utc biv hey jmettraux - you there?
2011-06-22 06:52:16 utc jmettraux biv: hello, yes
2011-06-22 06:52:32 utc biv I'm thinking of trying to upgrade our ruote code to the latest ver
2011-06-22 06:52:50 utc jmettraux last time you had a json issue, iirc
2011-06-22 06:52:51 utc biv I remember that the old DSL kept breaking though. Do you think now is a good time to try?
2011-06-22 06:53:06 utc biv hrm, I can't remember exactly what it was. I was quite rushed
2011-06-22 06:53:19 utc biv is it the case the old process definitions should work?
2011-06-22 06:53:24 utc jmettraux ok, let's try
2011-06-22 06:53:54 utc biv well, it might not be that hard for me to rewrite the process defs I already have
2011-06-22 06:54:07 utc biv just trying to get a feel from you on what you think is the easiest route
2011-06-22 06:54:48 utc jmettraux they shouldn't break, I kept the newer versions compatible
2011-06-22 06:55:02 utc biv ok, sounds pretty easy, I'll just pull down ruote master then
2011-06-22 06:55:12 utc jmettraux great
2011-06-22 06:58:50 utc biv yup, have hit a syntax like error:
2011-06-22 06:59:23 utc biv https://gist.github.com/1039617
2011-06-22 07:00:42 utc jmettraux ok, this is not a syntax error, it's the security check telling that your participant implementation is touching the File constant
2011-06-22 07:01:07 utc jmettraux let me dig up the "security unlocking" thing I passed you the other day
2011-06-22 07:01:15 utc biv k
2011-06-22 07:01:20 utc biv I might have it here already
2011-06-22 07:01:21 utc biv ACTION looks
2011-06-22 07:02:05 utc jmettraux when instantiating the storage, you have to pass 'user_ruby_treechecker' => false
2011-06-22 07:02:33 utc jmettraux (or you port your participants from blocks to classes)
2011-06-22 07:02:43 utc biv k
2011-06-22 07:03:04 utc biv Ill start with the first option, but I'd like to move to the second
2011-06-22 07:03:46 utc biv @storage = Ruote::FsStorage.new("/tmp/nesstar/ruote/", 'user_ruby_treechecker' => false) didn't seem to do it
2011-06-22 07:03:54 utc biv sorry, i remember we went through this last tme
2011-06-22 07:04:01 utc jmettraux ouch, sorry
2011-06-22 07:04:10 utc jmettraux 'use_ruby_treechecker' => false
2011-06-22 07:04:48 utc biv hrm, how do I communicate that to the storage?
2011-06-22 07:05:44 utc jmettraux @storage = Ruote::FsStorage.new("/tmp/nesstar/ruote/", 'use_ruby_treechecker' => false)
2011-06-22 07:05:56 utc jmettraux user --> user
2011-06-22 07:06:01 utc jmettraux user --> use
2011-06-22 07:06:03 utc jmettraux sorry my fault
2011-06-22 07:06:04 utc biv gotcha
2011-06-22 07:06:42 utc biv hrm, still the same error
2011-06-22 07:07:32 utc jmettraux ok, let me try something
2011-06-22 07:09:44 utc jmettraux ah, yes, you're right
2011-06-22 07:10:26 utc jmettraux https://gist.github.com/1039626
2011-06-22 07:10:58 utc biv k
2011-06-22 07:12:06 utc jmettraux my bad
2011-06-22 07:12:28 utc jmettraux we went through the same scenario back then
2011-06-22 07:12:37 utc biv ACTION nods
2011-06-22 07:12:45 utc biv no worries - just let me play with this a bt
2011-06-22 07:12:46 utc biv bit
2011-06-22 07:12:48 utc jmettraux give me 5 minutes to fix that in the medium term
2011-06-22 07:16:39 utc biv cool that appears to hvae worked
2011-06-22 07:16:46 utc biv no, that's fine, I can live with that
2011-06-22 07:17:15 utc biv ok, so now I can work with the latest ruote, I wonder if the multithreading requires first problem still exists
2011-06-22 07:17:22 utc biv ACTION adds more threads to his threadpool
2011-06-22 07:19:06 utc jmettraux I don't remember enough to answer :)
2011-06-22 07:19:31 utc jmettraux ok, got the fix, now running the tests
2011-06-22 07:21:19 utc biv :)
2011-06-22 07:21:26 utc biv hrm, the server Im supposed to integrate with is timing out
2011-06-22 07:21:30 utc biv haha
2011-06-22 07:21:33 utc biv that helps
2011-06-22 07:23:01 utc jmettraux an immediate workaround for you would be to nuke the configurations/ne/engine.json file and retry
2011-06-22 07:23:34 utc biv right
2011-06-22 07:23:38 utc biv well, at least I have it upgraded
2011-06-22 07:23:41 utc biv so that's a good start
2011-06-22 07:24:03 utc jmettraux groumpf, my fix broke something somewhere else, looking into it
2011-06-22 07:39:04 utc jmettraux tosch_le: hello, I added the Gemfile.lock to ruote-kit
2011-06-22 07:39:30 utc tosch_le hello!
2011-06-22 07:39:40 utc tosch_le jmettraux: great! many thanks.
2011-06-22 07:40:11 utc jmettraux :)
2011-06-22 08:10:54 utc jmettraux biv: I just pushed a fix for fs_storage to ruote master, I will port the fix to other storage implementations later in the evening
2011-06-22 08:16:59 utc biv cheers dude
2011-06-22 08:17:01 utc biv ok, Im out
2011-06-22 08:17:05 utc biv have to switch off :)
2011-06-22 08:17:09 utc jmettraux ciao !
2011-06-22 08:17:10 utc biv thanks for your help
2011-06-22 09:20:54 utc MCamou hi everyone
2011-06-22 09:21:23 utc MCamou could someone give me a hand with ruote-amqp?
2011-06-22 09:23:18 utc jmettraux MCamou: hello
2011-06-22 09:23:26 utc MCamou Hi John
2011-06-22 09:23:37 utc jmettraux next time you have no answer, please try the mailing list
2011-06-22 09:24:06 utc MCamou yeah, I got bogged in stuff :)
2011-06-22 09:24:07 utc jmettraux I will try my best, but my amqp experience is limited to maintaining ruote-amqp
2011-06-22 09:24:23 utc MCamou thanks
2011-06-22 09:24:33 utc jmettraux you might have more chance on the mailing list
2011-06-22 09:25:00 utc MCamou hmm…good point
2011-06-22 09:25:06 utc MCamou I'll try the list
2011-06-22 09:26:00 utc jmettraux no worries, ask first here
2011-06-22 09:26:08 utc MCamou thanks!
2011-06-22 10:10:36 utc MCamou OK…sent to the list
2011-06-22 10:11:33 utc jmettraux if I can reply, I will, else I will have to let it pass, let's hope the amqp crowd is listening
2011-06-22 10:33:38 utc jmettraux MCamou: your gut feeling is that we should handle gracefully "nil" messages ?
2011-06-22 10:41:08 utc MCamou as far as nil's are concerned, we should probably filter them out before doing a q.publish
2011-06-22 10:41:38 utc MCamou but I am also concerned that there are cases when AMQP stops responding without warning
2011-06-22 10:42:15 utc MCamou I wonder if this is a ruby-amqp bug
2011-06-22 10:42:34 utc jmettraux so far the people using ruote-amqp in production haven't complained
2011-06-22 10:42:58 utc MCamou But I assume that if we send in a bug report the first response would be to upgrade to 0.8
2011-06-22 10:43:16 utc MCamou hmmmm….so perhaps this is the only case
2011-06-22 10:43:27 utc MCamou or perhaps what we're doing is so weird that we hit on a corner case :)
2011-06-22 10:49:31 utc jmettraux ouch
2011-06-22 10:52:30 utc jmettraux now I remember the amqp 0.8.0 pain http://groups.google.com/group/openwferu-users/browse_thread/thread/f7a8138e987867a3
2011-06-22 11:06:08 utc MCamou ah yes… I remember that exchange
2011-06-22 11:08:15 utc jmettraux I've pinged Kenneth about your email, if no one answers by tomorrow, I will try myself
2011-06-22 11:09:11 utc MCamou thanks!
2011-06-22 15:57:04 utc MCamou hi again
2011-06-22 15:57:08 utc MCamou quick question
2011-06-22 15:58:42 utc MCamou I have a participant/receiver combination. The Participant doesn't call reply_to_engine in consume(), it just registers the workitem in an in-memory Hash and returns. The Receiver looks up the workitem in the Hash when it gets a message and does the Reply
2011-06-22 15:58:55 utc MCamou (these actually extend the RuoteAMQP ParticipantProxy/Receiver)
2011-06-22 15:59:23 utc kitplummer what's the question? :)
2011-06-22 15:59:31 utc MCamou my question is, what happens if Ruote goes down after the execution of the Participant but before the Receiver gets the message?
2011-06-22 16:00:00 utc MCamou will the workitem be persisted (so I should probably persist the Hash too) or not?
2011-06-22 16:00:16 utc MCamou in my use case I think it makes more sense for it NOT to be persisted
2011-06-22 16:01:39 utc MCamou (before when I was talking of the Receiver, I should have said it does a RECEIVE instead of a reply)