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
