Hi, inline :).
2015-03-09 19:25 GMT+01:00 Kenneth Adam Miller <[email protected]> : > Inline. > > On Mon, Mar 9, 2015 at 7:12 AM, Yassine Lamgarchal <[email protected]> > 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 [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
