On Thu, Mar 28, 2013 at 12:05:09PM -0700, Steve Sexton wrote: > > We are in production with our 2nd customer using ruote to > automate/customize customer-specific workflows. > > Today I ended up with a process in a bizarre state. In ruote-kit it looks > like this: > > (...) > > Hopefully email didn't mangle this. If it did, the odd thing is that the > leaf nodes of my expression tree are a cursor and a subprocess. I wouldn't > expect to see a tree like this except temporarily after a participant > expression was completed (aside: we use 'complete' to mean what ruote-kit > calls 'proceed' what ruote calls 'reply'/ 'receive') and the replies are > still propagating up the tree. I suspect what happened is that the ruote > process was killed/restarted while the replies were being processed, and > that something got lost. > > Two questions: > 1. Is there a way to get ruote to pick up where it left off, and continue > processing replies?
Hello Steve, if I understand correctly, your process is stuck in an intermediate state and doesn't move off of it, right? If that is the case then maybe, Dashboard#respark might help. https://github.com/jmettraux/ruote/blob/6aacbbb08e2b13650cee1313b21ce67e467bd995/lib/ruote/dashboard.rb#L411-L425 Respark was made for those "something got lost" cases, generally a reply msg dropping out of the truck. If your version of ruote doesn't have respark, the manual way of doing it is by re-applying the process at the stuck leaf (where the message didn't come back), the participant will receive the workitem one more time, but hopefully it's not such a big cost. The alternative would be to cancel that participant, the flow would go on too, but the participant implementation would thus not have its take on the workitem payload. > 2. Does ruote use transactions? Our current backend is MySQL with MyISAM > tables, we are migrating to postgres for other reasons but it would be nice > to able to tell management that switching to a transactional database will > prevent this problem from occuring in the future. > > Using ruote-sequel for the storage. ruote version is 2.2.0. I know that > is old, but that was the official release when we went into production and > I haven't had an opportunity to upgrade. No, ruote-sequel doesn't use transactions. I don't think it would help in that case, processes (unless there is a timeout set) are very patient, if the order to stand up doesn't come, the dog will just stay sitting. Using transactions to wrap "msgs" so that they don't get lost might be a bit expensive, there are lots of msgs, that might slow down. Maybe someone will come up with a storage that leverages transactions at some point. Here are the respark tests, if you want to understand it better: https://github.com/jmettraux/ruote/blob/6aacbbb08e2b13650cee1313b21ce67e467bd995/test/functional/ft_74_respark.rb Maybe I should split respark in two, the part that asserts that a leave is "stuck" might be interesting (hey, this process has 2 errors, and that other process is stuck there). Although, iirc, respark only re-applies leaves and contains no smart routine. We probably need a way to highlight stuck processes to admins. I hope this will help, keep me posted, best regards, -- John Mettraux - http://lambda.io/jmettraux -- -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en --- You received this message because you are subscribed to the Google Groups "ruote" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
