incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject new queue capability
Date Thu, 27 Feb 2014 15:07:48 GMT
I've been playing around with the new QueueReader stuff and I'm
starting to believe it's at the wrong level of abstraction - in the
shard context - for a user.

Between having to know about the BlurPartioner and handling all the
failure nuances, I'm thinking a much friendlier approach would be to
have the client implement a single message pump that Blur take's from
and handles.

Maybe on startup the Controllers compete for the lead QueueReader
position, create it from the TableContext and run with it?  The user
would still need to deal with  Controller failures but that seems
easier to reason about then shard failures.

The way it's crafted right now, the user seems burdened with a lot of
the hard problems that Blur otherwise solves.  Obviously, it trades
off a high burden for one of the controllers.


View raw message