[rabbitmq-discuss] [Q] best way to add a sequencer to the broker

[Chuck Remes]

On Dec 29, 2008, at 6:36 PM, Ben Hood wrote:

> Chuck,
>
> 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  
>>> relay
>>> mechanism.
>>
>> This has helped immensely. Can you provide a pointer to an example  
>> custom
>> exchange?
>
> 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  
> though.

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):
global_counter++;


> 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  
one too.

I am not opposed to using a timestamp. I thought it would be *simpler*  
(and faster) to use an integer.

cr