[zeromq-dev] Asynchrony in malamute clients
Kenneth Adam Miller
kennethadammiller at gmail.com
Fri Apr 10 16:01:54 CEST 2015
So, I have the following regarding how to make sure that clients that are
asynchronous manage to use the Service Request api correctly:
void syncOppClient(const char *broker_endpoint, const char
*subscribe_stream, const char *subscribe_pattern,
const char *publish_stream, const char *publish_message) {
mlm_client_t *_init_client = mlm_client_new();
int rc=mlm_client_connect (_init_client, broker_endpoint, 1000, "");
assert(rc==0);
mlm_client_set_consumer (_init_client, subscribe_stream,
subscribe_pattern);
mlm_client_set_producer (_init_client, publish_stream);
mlm_client_sendx (_init_client, publish_message, NULL);
mlm_client_recv(_init_client);
mlm_client_destroy(&_init_client);
}
I notice that often the clients freeze; it's as though the messages aren't
routed. Some of the time, they freeze at the
mlm_client_recv(_init_client);, so I'm wondering if I should be using some
other malamute client api to make sure that clients are on each side at the
same time by making them wait. They are indeed concurrent, meaning that the
clients should be running simultaneously regardless, but if the
syncOppClient call isn't made, they race to the broker in the sense that
calls to sendforx don't seem to make it through. The broker documentation
about api semantics specifically says:
"When a client sends a service request, the broker creates a service queue
if needed. Service queues are persisted in the same way as mailboxes. "
but just doing sendforx; recvx as in the change that I merged into the
mlm_client test with *multiple* concurrent clients on each side results in
lockups for the clients. syncOppClient reduces these races some, but
doesn't eliminate them. How do I facilitate having more than one client on
each side of the broker, managers and workers? What I want is exactly what
is documented that I added to the mlm_client_test, except that the frontend
and backend are concurrent and there can be more than one of them
simultaneously.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150410/731c4464/attachment.htm>
More information about the zeromq-dev
mailing list