On Thu, Apr 1, 2010 at 9:43 PM, Jeremy Davis
wrote:
>
> You are correct, it is not a queue in the classic sense... I'm storing the
> entire "conversation" with a client in perpetuity, and then playing it back
> in the order received.
>
> Rabbitmq/activemq etc all have about the same throughput 3-6
Since twitter is everyone's favorite analogy:
It's like twitter, but faster and with bigger messages that I may need to go
back and replay in order to mine for more details at a later date.
Thus, I call it a queue, because the order of messages is important.. But
not anything like a message broker/
You are correct, it is not a queue in the classic sense... I'm storing the
entire "conversation" with a client in perpetuity, and then playing it back
in the order received.
Rabbitmq/activemq etc all have about the same throughput 3-6K persistent
messages/sec, and are not good for storing the conv
you mention never deleting from the queue, so what purpose is this
serving? (if you don't pop off the front, is it really a queue?)
seems if guaranteed order of messages is required, there are many
other projects which are focused towards that problem (rabbitmq,
kestrel, activemq, etc)
or am i mi
I'm in the process of implementing a Totally Ordered Queue in Cassandra, and
wanted to bounce my ideas off the list and also see if there are any other
suggestions.
I've come up with an external source of ID's that are always increasing (but
not monotonic), and I've also used external synchronizat
