[zeromq-dev] [pyzmq]: Asynchronous client api design

[Kenneth Adam Miller]

Ok, well when you have some code let me know and I will review.

On Tue, Mar 10, 2015 at 10:18 AM, Yassine Lamgarchal <bouceka78 at gmail.com>
wrote:

>
> Hi,  inline :).
>
>
> 2015-03-09 19:25 GMT+01:00 Kenneth Adam Miller <
> kennethadammiller at gmail.com>:
>
>> Inline.
>>
>> On Mon, Mar 9, 2015 at 7:12 AM, Yassine Lamgarchal <bouceka78 at gmail.com>
>> wrote:
>>
>>> Hi Kenneth,
>>>
>>> Thank you for your quick response !
>>>
>>> * I use a DEALER socket because the client must be able to send multiple
>>> commands without
>>> receiving the response:
>>>
>>>     - async_result1 = client.command("data1")
>>>     - async_result2 = client.command("data2")
>>>     - .... do other stufs ....
>>>     - result1 = async_result1.get()
>>>     - result2 = async_result2.get()
>>>
>>> * Indeed, it looks like a future object :) !
>>>
>>> * Yea, in the schema it's a thread which run the event loop and listen
>>> for commands to send to the server, i
>>> think i can easily spawn a process instead of a thread. The consumer
>>> simply connect to the socket, on
>>> which the thread listen on, and send commands.
>>>
>>> * Thanks, i realize that a REQ socket is better in this case because a
>>> PAIR will restrict to only one client
>>> connected to the "framework thread".
>>>
>>> Q1. Well, for now there is a fixed number of servers known by each
>>> client. When the cluster start it elects a server as
>>> a leader, the command are only sent to that particular server. So for
>>> now, there is no need to load balance the requests.
>>>
>>
>> So, if you wrapped the connection initialization portion along with the
>> service loop in an additional endpoint selection loop in the api, you could
>> easily abstract over the use of a broker. If you haven't seen the new
>> malamute broker that's being developed, if the test in the loop you did
>> actually return or set some kind of targeted server address then you could,
>> in the connect call to the server, pass a string that's set depending on
>> the model that you select.
>>
>
> I got the idea ! Yes, i can proceed like that. I will take a look at the
> Malamute broker project :) !
>
>
>>
>>> Q2. Yea, the thing is as a user i don't like when a library create
>>> threads in the background, this could lead to bugs hard
>>> to troubleshoot. But yea with message passing this could be acceptable.
>>>
>>
>> Well, ideally libraries should not do this, but in fact even ZeroMQ does
>> this. If you didn't know it, when you create a context it is in fact a
>> runtime as well, creating threads in the background that do things such as
>> make sure that your data gets sent reliably and is received and placed into
>> the proper framing and some such. It's interesting because the only way
>> that it imposes any change on the user is it forces that, on shutdown the
>> user not have any remaining sockets that haven't been properly
>> deallocated/collected. But that's good practice anyway. So generally, if
>> you design your library so that it doesn't expose any dependency to
>> consumer code, then you should be in good shape.
>>
>
> Yea, you are right. I have to not expose this part to the user and it will
> be fine. Thanks for the explanation :) !
>
>
>>
>>> Actually, i thought if i can have the same behavior (then having a
>>> single threaded client application) and letting the user
>>> create the event loop.  If i do so, the client application must be fully
>>> event driven (the client event loop receive events
>>> and send commands) but i don't want this. In my use case i think that
>>> "framework thread" is mandatory, does my reasoning
>>> make sense ? :)
>>>
>>
>> No, I don't know exactly what you're referencing, because my questions
>> ended at your above response. This seems to be a newer, different topic.
>> Please explain what you mean more.
>>
>
> I just wanted to be sure that, in the client side, i really need to have a
> "framework thread" (which is unavoidable) in order to have a simple and
> proper implementation.
>
> --
> Yassine
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150310/bf572837/attachment.htm>