RPC after adapter create but just before adding object. client finish silently without server action

raycrayraycray Member Ray ChengProject: Electronic Trading

Hi,

I found a weird behavior when doing RPC call when starting server and client at the same time. In some case we found client perform RPC successfully (with no exception) but server actually didn't receive any call. Please find the time sequence as below:

  1. Server created adapter A
  2. Server added object O1
  3. Client perform RPC_O1, server recieved the call and client return with no exception
  4. Client perform RPC_O2, server NOT receive any call but client return with no exception

FYI the RPC call is void ABC(...) with no return code.

ICE version: 3.6.1
Setup: ICEgridregistry, ICEStorm, server, client (both in c++)

Tagged:

Best Answer

  • bernardbernard Jupiter, FLBernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Accepted Answer

    Hi Ray,

    The typical sequence on the server-side is:
    - initialize communicator
    - create object adapter
    - add servants to object adapter
    - activate object adapter

    Before you activate your object adapter, it's in a holding state, and requests are not dispatched to the servants: see https://doc.zeroc.com/display/Ice36/Object+Adapter+States for more details.

    For your issue:

    Client perform RPC_O2, server NOT receive any call but client return with no exception

    You could find more information about what's happening "under the hood" with tracing; I would set Ice.Trace.Protocol=1 on both the client and server to see which messages are sent/received.

    If this RPC is a two-way synchronous request, your client thread will block until it gets a response (which can be void) or an exception. The exception could be for example ObjectNotExistException, if there is no servant registered for the target object's identity.

    If this RPC is a oneway request, it is possible for the client to send the request successfully and not get any exception. This would be the case in this scenario:
    - the client successfully establishes a connection to the server and sends a oneway request
    - the client is done since it's a oneway request
    - the server can't find the desired object, but can't notify the client since it's a oneway request

    The easiest is to add some tracing; please post these traces if the behavior you're seeing isn't clear.

    Best regards,
    Bernard

Answers

  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Accepted Answer

    Hi Ray,

    The typical sequence on the server-side is:
    - initialize communicator
    - create object adapter
    - add servants to object adapter
    - activate object adapter

    Before you activate your object adapter, it's in a holding state, and requests are not dispatched to the servants: see https://doc.zeroc.com/display/Ice36/Object+Adapter+States for more details.

    For your issue:

    Client perform RPC_O2, server NOT receive any call but client return with no exception

    You could find more information about what's happening "under the hood" with tracing; I would set Ice.Trace.Protocol=1 on both the client and server to see which messages are sent/received.

    If this RPC is a two-way synchronous request, your client thread will block until it gets a response (which can be void) or an exception. The exception could be for example ObjectNotExistException, if there is no servant registered for the target object's identity.

    If this RPC is a oneway request, it is possible for the client to send the request successfully and not get any exception. This would be the case in this scenario:
    - the client successfully establishes a connection to the server and sends a oneway request
    - the client is done since it's a oneway request
    - the server can't find the desired object, but can't notify the client since it's a oneway request

    The easiest is to add some tracing; please post these traces if the behavior you're seeing isn't clear.

    Best regards,
    Bernard

  • raycrayraycray Member Ray ChengProject: Electronic Trading

    I think the root cause is the adapter is activated before adding the second servants. It looks good now after changing the code to activate after added all servants.
    Thanks for quick response.

Sign In or Register to comment.