[zeromq-dev] Publish-subscribe / Time to live

[Eric Bell]

Thanks for your response. I am not new to programming but I am new to
messaging, so this is helpful. This project is perfect for me to learn
about this subject area because it will benefit from the use of
messaging, but will not be a high load system.

> Is it correct to assume the back-end workers are stateless?

Funny you should ask that. The back-end workers probably won't be
stateless ... I may in fact allocate a single back-end worker per
client-job, because the tasks generate interim results that need to be
used later in the process. My current goal is to design for scalability
to handle concurrent users, rather than reducing the time to perform a
specific user's task (not that is undesirable, just the less important).

> What you would need to make, presumably, is a broker that accepts job
> requests (as complete messages) from clients, using req/xrep sockets,
> and then distributes these to worker processes (or threads if you want
> to do it all in one process) using xreq/rep sockets.  The broker would
> have the necessary logic to do the preparatory tasks, and then the
> analysis, put the results together, and send this back to the client.

Yes. I simplified my description for the post, but this is how my
working design is structured.

> To handle disconnecting clients I can see two options.  Either ignore
> them, and discard results that cannot be sent back to a client, or add
> a Keep-Alive from the client to the broker, and purge jobs for a
> client that goes away.

This is the piece of information I really needed. The basic problem
itself only occured to me last night. I was hoping it could be solved
transparently within the messaging solution itself, but it is not a
surprise to me that I will actually have to build this into my system.

> This is a very sketchy design.  If you'd like us to make a detailed
> design, our pleasure, but that would be a few days' work and we'd
> charge for that.

Thanks for the offer. As I mentioned above, this is a learning
experience for me, so I wouldn't want to let you have the fun :-)

--eric