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 <[email protected]> wrote:
> > 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 > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
