[zeromq-dev] Asynchrony in malamute clients

[Kenneth Adam Miller]

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/25cd2535/attachment.htm>