[zeromq-dev] Asynchrony in malamute clients

[Kenneth Adam Miller]

I've found that, with similar unit tests, there no way to ensure that
before a send occur that there is a client on the other side in order to
make sure that the broker will create a queue for the message. This is a
major problem I've been trying repeatedly to solve, because if I have
clients connect asynchronously, each subscribed to what the other side
produces, in is implausible to prevent messages being lost. If messages get
lost this way, since I can't timeout on receive operations, the clients
deadlock.

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

> The following unit test fails:
>
> void test_services_are_preserved_across_connections() {
>   std::cout << "test service messages are preserved across connectiosn" <<
> std::endl;
>   startUP();
>   mlm_client_t *client=mlm_client_new();
>   char *topic, *content;
>   int rc=mlm_client_connect(client, "tcp://127.0.0.1:9999", 2000, "");
>   assert ( rc == 0);
>   mlm_client_sendforx(client, MANAGER_GIVE, "gotit", "", NULL);
>   mlm_client_destroy(&client);
>
>   client=mlm_client_new();
>   rc=mlm_client_connect(client, "tcp://127.0.0.1:9999", 2000, "");
>   assert ( rc == 0);
>   mlm_client_set_worker(client, MANAGER_GIVE, "got*");
>   mlm_client_recvx(client, &topic, &content, NULL);
>   assert(!strcmp(content, "gotit"));
>   mlm_client_destroy(&client);
>   shutDown();
> }
>
> start up and shut down just create an in process malamute actor and bind
> it to port 9999.
>
> On Fri, Apr 10, 2015 at 2:41 PM, Kenneth Adam Miller <
> kennethadammiller at gmail.com> wrote:
>
>> "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/a5db19e0/attachment.htm>