Btw if you problem is how to offload some task to thread, you might want to take a look on zactor class from czmq. It makes spawning the thread and communicating with it really easy. Dne 11. 6. 2016 8:08 PM napsal uživatel "Michal Vyskocil" < [email protected]>:
> Hi, > > Did you take a look on a SERVICE pattern (mlm_client_sendfor)? The > proposal smells like that to me. In this pattern workers are not (usually) > spawned by client making request. The pool is usually created before. > > A1 yes, uuid can be used. We have used prosess id and thread id to create > unique mailbox addresses. Whatever will work for you is fine. > > A2 mlm_client_recv is blocking call, so you must use zpoller_t from czmq > (or anything which will work for zsock_t) > > Q3 malamute does maintain the state in memory, so it will always start > fresh. However I'm a bit confused by mentioning crash together with > different signals, so I might misunderstood the question. > > If this is about stopping sequences, you can run malamute as a thread, so > it will have the same lifecycle as your system. > Dne 11. 6. 2016 5:12 PM napsal uživatel "Douglas Petican" < > [email protected]>: > >> Thanks. Malamute looks really cool. Nice doggy. And I don't have to >> keep trying to reinvent the wheel ;) I also like the idea of persistent >> storage. Could be useful for storing logfiles and data coming from a >> datalogger attached to the system. >> >> So, I've read the whitepaper and it seems like direct messaging is what I >> want to do. This is how I think I should proceed. Note that all my >> "servers/workers" process only one request and respond with one reply. >> Either success and data, or error and error message, then terminate >> normally. >> >> 1) Client spawns a worker and passes the worker its identity as a >> parameter >> >> 2) Client sends a direct message to the broker using its own identity >> addressed to the worker identity >> >> 3) When worker spins up it checks its mailbox and receives the message >> (request) >> >> 4) Worker does its work, sends a message (response) addressed to the >> client and terminates >> >> 5) Client receives the message (response) and does what it has to do >> >> Q1) Should I be using something like uuids so that mailboxes have unique >> names? >> >> Q2) Unlike req-rep which blocks will I have to keep polling the broker to >> see if there is a message? >> >> Q3) If malamute dies can I request that when it starts up again say using >> a watchdog like monit that it starts fresh. This is because the INT and >> TERM signals are processed by all my clients and workers as well. So if >> one process dies. They all die. >> >> >> <-Douglas Petican-> >> >> On 2016-06-10 8:32 AM, Kevin Sapper wrote: >> >> Sorry messed up the link: https://github.com/zeromq/malamute >> >> 2016-06-10 14:32 GMT+02:00 Kevin Sapper <[email protected]>: >> >>> Hi Douglas, >>> >>> have a look a malamute (https://github.com/zeromq/malamulte) which >>> should work for your use case. >>> >>> //Kevin >>> >>> 2016-06-08 16:07 GMT+02:00 Douglas Petican <[email protected]>: >>> >>>> I want to enforce a one to one relationship between client and >>>> dynamically spawned worker. I asked before on the list and was told to use >>>> a router router broker. However, I can't get my code to work in anyway >>>> with a router on both the frontend and backend of the broker. Nothing >>>> happens. It only works (almost) with a dealer backend. >>>> >>>> The first client connects okay and the worker is spawned dynamically. >>>> When the second client connects a new worker is spawned and the second >>>> client and worker talk to each other exclusively, but the first client >>>> talks to both workers which is not what I want. >>>> >>>> My broker code is here: http://pastebin.com/eKVQ7VwR >>>> >>>> The client/worker code is here: http://pastebin.com/5tU9BZRn >>>> >>>> -- >>>> <-Douglas Petican-> >>>> >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >>> >> >> >> _______________________________________________ >> zeromq-dev mailing >> [email protected]http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
