[zeromq-dev] Asynchrony in malamute clients

Kenneth Adam Miller kennethadammiller at gmail.com
Fri Apr 10 20:41:09 CEST 2015


"Replies back to an originating client are sent to the client mailbox. Thus
clients may send service requests, disconnect, and then retrieve their
replies at a later time."

Oh I just found this :) So, what if I don't associate unique identities
with clients-what are the client mailboxes then? Is this the problem, that
acknowledgements aren't being sent?

On Fri, Apr 10, 2015 at 2:36 PM, Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:

> Actually, how do workers specifically acknowledge that they have received
> a request? I don't think that's in mlm_client.c...
>
> On Fri, Apr 10, 2015 at 10:01 AM, Kenneth Adam Miller <
> kennethadammiller at gmail.com> wrote:
>
>> 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/b47de6b3/attachment.htm>


More information about the zeromq-dev mailing list