[Backgroundrb-devel] [ANN] BackgrounDRb 1.0 pre-release available now

hemant kumar gethemant at gmail.com
Tue Dec 11 09:58:12 EST 2007


On Tue, 2007-12-11 at 14:52 +0100, Emil Marceta wrote:
> We are actually on of the ActiveMerchant providers (E-Xact), so
> strictly we are talking what is actually behind ActiveMerchant. There
> are many protocols involved in financial networks, depending where the
> transaction is routed. We are very familiar with Reactor engines and
> patterns you are advocating, and they work great, especially in
> uniform scenarios without throttling, sequencing etc. In our case, I
> don't see a clear gain I'm afraid. While a thread pool was done in
> no-time and is dead simple maintain, test etc.

Cool. You can use existing approach provided you handle your threads
with as much care. I will get back to this in sometime. There are other
ways also, that I am looking. For example: co-routines ( on top of
fibers ) from Ruby1.9. Just watch bdrb mailing list, or submit some
patch. As i guess, you guys are already running somewhat customized
version of bdrb.

> Our Rails cluster runs bdrb on each Rails server and uses domain
> sockets. This to avoid a single point of failure and have uniform
> architecture. Would that work too? That is, does bdrb now works sort
> of like memcache where each server knows of every other instance? But
> even with that in place, in fastcgi for example, fastcgi processor may
> recycle the Rails process where callback has been registered.

Hmm, this is cool. So, how did you handle this situation earlier?
Prolly, what you can do is, have bdrb instances running on each cluster
and have cluster specific backgroundrb configuration file. So as,
requests from  mongrels running on cluster1 will be served by bdrb
running on cluster1 only, and update some db/memcache key to indicate
it, so as even if next time request goes to another worker on another
machine, you know the state.
Again, I would love any patch, ideas from you and I am myself working on
something like this, which would avoid logging to db and stuff.

Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.


More information about the Backgroundrb-devel mailing list