Archived
This forum has been archived. Please start a new discussion on GitHub.
Leaning about bidirectional communications - deadlocks and implicit contexts
in Help Center
I am trying to learn how to properly use bidirectional communications, and I have some questions. Let me use the bidir example as a reference to pose my questions.
* In bidir demo example, the invocation of the callback is roughly as follows:
1- The client invokes CallbackSenderI.addClient in the server, passing as an argument the ID of the object in the client side that is to receive the callback.
2- The method CallbackSenderI (in the server) simply stores the client's callback ID in a list that contains callbacks from different clients.
3- The invocation of the clients' callbacks is done in a separate thread in the server side using a synchronous invocation.
Now I try to modify the example in different ways:
1- I change CallbackSenderI.addClient so that it invokes the client's callback directly (using a synchronous invocation) instead of relying on a separate thread. This blocks the client and server.
2- If instead of using a synchronous invocation I use a oneway or an asynchronous, it works.
Obviously there are threading issues that I am missing.
- Can somebody please explain what is the problem of the modification 1? Can you explain the deadlock that is occurring?
- And if wanted to make it work, can I do something? (e.g. add more threads and where?)
* Another question. Instead of passing the client's object ID as an argument to the CallbackSenderI.addClient, I am considering to pass the name of the object (that is, identity.name) in an implicit request context (https://doc.zeroc.com/display/Ice36/Implicit+Request+Contexts). This requires to re-create the identity in the server side.
- Is this for any reason not recommended or discouraged?
- Should also identity.category be passed in the context? In my simple tests I don't use it, so it is not necessary. But I wonder if this might affect later e.g. if we ever use Glacier or if ICE ever modifies the ID automatically.
Thanks in advance, and regards.
José.
* In bidir demo example, the invocation of the callback is roughly as follows:
1- The client invokes CallbackSenderI.addClient in the server, passing as an argument the ID of the object in the client side that is to receive the callback.
2- The method CallbackSenderI (in the server) simply stores the client's callback ID in a list that contains callbacks from different clients.
3- The invocation of the clients' callbacks is done in a separate thread in the server side using a synchronous invocation.
Now I try to modify the example in different ways:
1- I change CallbackSenderI.addClient so that it invokes the client's callback directly (using a synchronous invocation) instead of relying on a separate thread. This blocks the client and server.
2- If instead of using a synchronous invocation I use a oneway or an asynchronous, it works.
Obviously there are threading issues that I am missing.
- Can somebody please explain what is the problem of the modification 1? Can you explain the deadlock that is occurring?
- And if wanted to make it work, can I do something? (e.g. add more threads and where?)
* Another question. Instead of passing the client's object ID as an argument to the CallbackSenderI.addClient, I am considering to pass the name of the object (that is, identity.name) in an implicit request context (https://doc.zeroc.com/display/Ice36/Implicit+Request+Contexts). This requires to re-create the identity in the server side.
- Is this for any reason not recommended or discouraged?
- Should also identity.category be passed in the context? In my simple tests I don't use it, so it is not necessary. But I wonder if this might affect later e.g. if we ever use Glacier or if ICE ever modifies the ID automatically.
Thanks in advance, and regards.
José.
0
Comments
-
- To understand why the server blocks see thread considerations for bidirectional connections.
- If you want pass the Identity as string better use Ice::identityToString and Ice::stringToIdentity to convert between Ice::Identity and std::string.
0 -
0
-
0