in reply to Message transport via network

You will need to think hard about what kinds persistence you need. If you only need a message protocol for sending status updates, with a limited delivery guarantee, then something lightweight like ZeroMQ might be enough and "conveniently" testable as it is a serverless infrastructure. On the opposite end of delivery/consistency of messages, a database provides that, but has much slower throughput and creates a harder single point of failure.

Consider where messages are allowed to get lost - a missing completion message will leave the task in need to be restarted. If the only side effect of this is wasted time, that may or may not be sufficient for you. How important is a crash of the queue server? Can all messages stored in the queue server get lost, or should they be as available as possible?

Replies are listed 'Best First'.
Re^2: Message transport via network
by Sewi (Friar) on Jun 18, 2012 at 09:56 UTC
    Thank you,
    loosing the complete message store because of a hardware or software failure would be ok. Web users won't get status reports for completed jobs (but the final report is saved permanently anyway, they could look it up at any time) or "cancel this"-messages won't be processed and users would have to re-issue the cancel-request. Users might also not get search results but a error message instead - perfectly fine if something is broken (and also current procedure in case of database problems).
    Messages shouldn't get lost as a planned design feature (or problem).

    I'll take a look at both suggested solutions.

    Try out Padre - the free Perl IDE and visit my blog's Perl section.
[reply]

In Section Seekers of Perl Wisdom