ruote 2.1.10 released
It takes as input process definitions and interprets them. It routes work among participants according to the flow described in those process definitions.
Version 2.1.10 is out and contains lots of small improvements and features requested and developed with the help of various people.
I have also updated/upgraded the various storage libraries around ruote and added to their ranks two new gems.
The changelog has all the details, but let’s look at the LocalParticipant module which saw the most improvements. Following suggestions by Oleg and Avishai, I added the on_reply, re_dispatch, reject and put/get methods
A participant has a consume(workitem) which is called as the participant gets handed a workitem. When dealing with a remote participant, it’s sometimes necessary to have logic alongside the consume method to deal with the workitem when it comes back. That’s the role of the on_reply(workitem) method.
re_dispatch(workitem) forces a re-delivery from the participant expression to the ‘real’ participant.
The reject(workitem) method is about participants that reject a workitem, forcing the worker to let another worker deal with the dispatching to the participant.
LocalParticipant now has a pair put(k, v) / get(k) for stashing data between consume / on_reply. The data is stashed directly in the ParticipantExpression.
Since CouchDB 0.11 is out and it allows ?feed=continuous&include_doc=true, I could drop the polling work from ruote-couch and simply keep connected and “react” on incoming changes in messages and schedules. It makes for a robust ruote-couch. I also made sure ruote-couch 2.1.10 can be shared by multiple workers.
This ruote-couch isn’t very fast, but I’ve come to appreciate CouchDB and use it in 2 or 3 projects. I like the comfort of having Couch as a storage for ruote.
I have upgraded ruote-dm as well. It’s a DataMapper backed ruote storage gem. I made sure ruote-dm could be shared by multiple workers (though I still have an issue with one of those special tests, I hope to fix that in the coming weeks).
It seems to work well with the latest DataMapper (1.0).
For the fun, I wrote a ruote-redis gem. As the name implies, it uses Redis as a persistence mechanism for ruote. It’s fast, multi-worker ready and was fun to develop. Not sure if I will use in production, but it can sit as an example at least.
There have been very interesting developments in Redis, this ruote-redis only uses a very limited set of those features. There is probably a better way.
I got interested in Beanstalk, its simplicity and minimal size are seducing. I started working with it as a kind of transient storage, but ended up writing a server/client thing. You can start a ruote-beanstalk storage linked to a beanstalk queue, a server and then start an engine and some workers that will communicate with the real storage via the beanstalk queue. Queue in the middle.
My initial purpose when investigating Beanstalk was to use it to pass workitems between the engine and the ‘real’ participants. I didn’t forget this and ruote-beanstalk comes with participant and receiver implementations.
It could become an alternative to ruote-amqp, it is at least a good example of a participant / queue / receiver set.
I still have to improve the documentation, there are lots of weak / missing points in it.
Lots more things.
Many thanks to Torsten, Ian, Oleg, Avishai, Patrice and Matt. And also many thanks to Wes Gamble (and Sergio) for organizing a ruote BOF at the latest Railsconf.
This release is dedicated to my friend Sawada Tomoaki, who left us last friday.