Uploaded image for project: 'ACS'
  1. ACS
  2. ACS-6

Python oneway methods are not working when both the caller and callee are on the same container

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Medium Medium
    • None

      During the test of a tutorial prepared by the ACS community, we ran into a weird situation that oneway method definitions on the IDL were not being skipped right away, but rather it waited for the call to finish.

      There were two components (async and caller). The caller is just a dummy component to call the oneway methods. The result is the following:

      2020-11-30T15:21:24.291 None callOneWay - [AsyncExampleCallerImpl - callOneWay] start!
      2020-11-30T15:21:24.294 None callOneWay - [AsyncExampleCallerImpl - callOneWay] before calling delayResult
      2020-11-30T15:21:24.294 None callOneWay - cb.get: INIT None
      2020-11-30T15:21:24.294 None delayResult - [AsynExampleImpl - delayResult] start!
      2020-11-30T15:21:34.305 None delayResult - [AsynExampleImpl - delayResult] almost finished, setting the callback!
      2020-11-30T15:21:35.308 None delayResult - [AsynExampleImpl - delayResult] finish!
      2020-11-30T15:21:35.309 None callOneWay - [AsyncExampleCallerImpl - callOneWay] right after calling delayResult
      2020-11-30T15:21:35.310 None callOneWay - [AsyncExampleCallerImpl - callOneWay] cb.get: DONE DATA 2
      2020-11-30T15:21:36.311 None callOneWay - [AsyncExampleCallerImpl - callOneWay] 1 sec after delayResult
      2020-11-30T15:21:36.312 None callOneWay - [AsyncExampleCallerImpl - callOneWay] cb.get: DONE DATA 2
      2020-11-30T15:21:39.316 None callOneWay - [AsyncExampleCallerImpl - callOneWay] after 3 sec sleep 
      2020-11-30T15:21:39.317 None callOneWay - [AsyncExampleCallerImpl - callOneWay] cb.get: DONE DATA 2
      

      As you can see, the "right after calling delayResult" message appears 10 seconds after the call, and after the "finish!" message.

      The problem is not seen if interacting from a client instead of the caller component:

      localhost almamgr:~ 510 > python test.py 
      2020-11-30 15:31:45.738324 Before first call (2 seconds delay)
      2020-11-30 15:31:45.738831 After fist call. Before second call (10 seconds delay)
      2020-11-30 15:31:45.738903 After second call
      2020-11-30 15:32:05.759163 After 20 seconds sleep
      2020-11-30T15:32:05.773 Python Client: initialized by almamgr@localhost disconnect - Disconnect called for client
      

      After deploying the component in two containers, the problem is not seen either:

      2020-11-30T17:05:53.797 None callOneWay - [AsyncExampleCallerImpl - callOneWay] start!
      2020-11-30T17:05:53.799 None callOneWay - [AsyncExampleCallerImpl - callOneWay] before calling delayResult
      2020-11-30T17:05:53.799 None callOneWay - cb.get: INIT None
      2020-11-30T17:05:53.800 None callOneWay - [AsyncExampleCallerImpl - callOneWay] right after calling delayResult
      2020-11-30T17:05:53.800 None callOneWay - [AsyncExampleCallerImpl - callOneWay] cb.get: INIT None
      2020-11-30T17:05:53.803 None delayResultWithOutCallback - [AsynExampleImpl - delayResultWithOutCallback] start! Sleeping for 20 seconds
      2020-11-30T17:05:54.802 None callOneWay - [AsyncExampleCallerImpl - callOneWay] 1 sec after delayResult
      2020-11-30T17:05:54.803 None callOneWay - [AsyncExampleCallerImpl - callOneWay] cb.get: INIT None
      2020-11-30T17:05:57.804 None callOneWay - [AsyncExampleCallerImpl - callOneWay] after 3 sec sleep 
      2020-11-30T17:05:57.804 None callOneWay - [AsyncExampleCallerImpl - callOneWay] cb.get: INIT None
      2020-11-30T17:06:13.824 None delayResultWithOutCallback - [AsynExampleImpl - delayResultWithOutCallback] finish!
      

      As you can see, here the "right after calling delayResult" message didn't have to wait the delay of 20 seconds given to the oneway method.

      Everything is pointing to a problem in OmniORBpy, when handling CORBA object references on the same process. Most ORB implementations use a special mechanism to avoid using the network for calls in the same process, and apparently OmniORBpy's trick has a bug with oneway methods.


              jaodev JAO Software Development (Inactive)
              Tomas.Staig Tomas Staig
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: