Home Help Center

Leaning about bidirectional communications - deadlocks and implicit contexts

jmygtjmygt Member Jose ValletOrganization: Finnish Geospatial Research InstituteProject: Localization framework that respects users privacy
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é.

Comments

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
  • jmygtjmygt Member Jose ValletOrganization: Finnish Geospatial Research InstituteProject: Localization framework that respects users privacy
    OK, thanks. The key name seems to be nested invocations.

    Regards.
    José
  • jmygtjmygt Member Jose ValletOrganization: Finnish Geospatial Research InstituteProject: Localization framework that respects users privacy
    OK, the key name seems to be nested invocations

    Thanks!
    José
Sign In or Register to comment.