[zeromq-dev] Extending the Paranoid Pirate Pattern - a problem and a candidate solution

Lucas Hope lucas.r.hope at gmail.com
Mon Jun 6 09:26:00 CEST 2011


Hi there,

I have extended the paranoid pirate pattern for a slightly different use
case, and I am having some difficulties. I think perhaps that this is a
deficit to the pattern itself, and not my programming - but am willing to
accept it could be the latter. :-)

My extension is this: I changed the worker so it handles envelope stacks
correctly, and implemented a dealer client in addition to a req client. (I
also altered the code to work with normal socket ids, and also to do real
work :-) )

My dealer dispatches batches of related jobs like this - job-id, "",
message-body. The batch length is about 50 and takes about 15 seconds of
processor time total. The dealer resends all unprocessed messages if it
doesn't hear from the broker queue for a given time period. As long as it is
has received at least one message, it doesn't time out.

The pattern works perfectly under normal operation.  However, it breaks down
badly if I kill the workers mid-batch and restart them again after the
client has begun retrying. The workers reconnect and begin to receive
defunct jobs from the older client socket(s) which the client has abandoned.
The workers spend time processing these defunct jobs before getting to the
new, valid jobs, and so can never catch up to live jobs which the client is
waiting on.

One solution is to tweak the retry parameters so the above is unlikely to
happen. But I'm not sure that is really reliable.

A second solution I thought of is as follows:

1. Receive messages from the client even if there are no workers ready.
Store these in an application-side queue for dispatch.

2. If the message body is an ABORT signal (either "ABORT" or perhaps \002),
go through the dispatch queue and remove messages relating to the sender's
envelope stack. The client sends the abort message just before closing the
socket and retrying (or aborting). This doesn't help if the queue itself has
died, but shouldn't hurt either.

Any thoughts or other solutions are welcome.

Peace,

-Luke
-- 
---------------------------------------------------
Dr Lucas Hope - lucas.r.hope at skype
Machine Learning and Software Engineering Consultant
Melbourne, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110606/2107334c/attachment.htm>


More information about the zeromq-dev mailing list