[rabbitmq-discuss] [Q] best way to add a sequencer to the broker
cremes.devlist at mac.com
Tue Dec 30 15:00:39 GMT 2008
On Dec 29, 2008, at 6:36 PM, Ben Hood wrote:
> On Tue, Dec 30, 2008 at 12:13 AM, Chuck Remes
> <cremes.devlist at mac.com> wrote:
>>> As indicated above, setting this for each message would not be too
>>> difficult to do. Given a mechanism to maintain a global counter, it
>>> would be less effort to do the custom exchange that any external
>> This has helped immensely. Can you provide a pointer to an example
> There isn't one really, but if you look in the deliver/5 function in
> the rabbit_router module, all you have to do is to fold the global
> counter into each message that gets applied to the list of queue
> endpoints. This would be one way to skin the cat.
I took a look but my lack of knowledge regarding Erlang made the code
look like line noise. :)
> You still have the problem of how to maintain the global counter
I don't understand this issue. Do you say this because the deliver/5
function may be called from many Erlang threads thereby requiring the
counter to be protected by a mutex? I thought Erlang serialized all
accesses via messaging to "mailboxes" so these kinds of race
conditions did not exist.
What is the problem with doing (the Erlang equivalent of):
> Having said this, are you interested in strict ordering as if it were
> be monitored by some all-knowing being or is it just a case of needing
> to be able to replay the same order?
I am only concerned about the replay order.
> If your application could tolerate some perceived re-ordering, but
> still replays in the same order, you could request batches of ordering
> keys from your globally visible state. The effect of this would allow
> a degree of parallelization at the cost of some stuff *appearing* to
> have arrived out of the *true* global order. But you could replay in
> the same order and the things were stamped.
This sounds reasonable.
But let me make sure I am understanding you clearly. You are saying
that it is possible for messages to be stamped in a different order
than they were received by the Exchange. Is that the case? Or are you
saying they may be delivered to queues in a different order than they
were received by the Exchange?
Off-list I received a message from Alexis who highlighted this issue.
Apparently the 0-8 AMQP spec does not address any ordering constraints
except in the case of Queues, so the server has the option of
reordering messages internally while processing. I don't think this
really bothers me all that much.
> Having said that, you might find using plain jane timestamps easier,
> if you can relax this true global ordering constraint a bit.
Why is a timestamp better? Is it because it pushes the access to a
"global counter" (in this case the system clock) outside of Erlang?
Your answer to the earlier ordering questions will likely answer this
I am not opposed to using a timestamp. I thought it would be *simpler*
(and faster) to use an integer.
More information about the rabbitmq-discuss