[zeromq-dev] Reliability question

Ben Kloosterman bklooste at gmail.com
Fri Jul 30 07:08:54 CEST 2010


Not sure about the sleeps.

 

There is no way pub sub system which allows the pub message to be received
if it was sent before subscription unless it has persistence which will kill
performance 

 

Ben. 

 

From: zeromq-dev-bounces at lists.zeromq.org
[mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Hannes Schmidt
Sent: Friday, July 30, 2010 12:39 PM
To: zeromq-dev at lists.zeromq.org
Subject: [zeromq-dev] Reliability question

 

I am currently evaluating 0MQ as an alternative to ActiveMQ mainly because
of frustration with its complexity. I don't need 100% durability and I just
need something that works without 200 lines of XML configuration. 

 

I do need pub/sub and I can't afford losing messages while all subscribers
are connected. I have written a Java unit test to validate that requirement
against ActiveMQ and I don't seem to be able to get it working reliably:

 

http://pastie.org/1066636

 

This is with one producer and one subscriber. The code is pretty much the
one from the cookbook with the difference that the subscriber is asserting
that the message arrive in order without dropped messages. Without the
Thread.sleep() in line 64 the test fails 50% of the cases. Without the
latches it fails everytime. The latches ensure that the receiver connects
after the sender has bound and that the sender starts sending after the
receiver has connected.

 

This is on Mac OS X 10.6.4 against HEAD of zeromq2 and jzmq.

 

Am I doing something wrong or is this a bug? When exactly is it safe to
start sending without risking message loss? I also think that ideally there
should not be the need for these latches I introduced. In production these
threads will ultimately run on different machines and latches won't be an
option, of course.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100730/d20f6f7c/attachment.htm>


More information about the zeromq-dev mailing list