3 Replies Latest reply on Sep 11, 2012 9:37 PM by shawkins

    ReusableExecution Lifecycle during Continuous execution

    rokhmanov

      Hi,

       

      I think I am not completely sure about how ReusableExecution react on DataNotAvailableException.

       

      My translator periodically returns one row of data with a small delay between executions. This is the regular flow of translator method calls during continuous execution which I see in logs:

      1. execute()

      2. next() // I throw DataNotAvailableException(10000) here because my "row" is not ready, so execution goes to sleep.

      3. next() // after 10 seconds execution continue, method next() returns the row which was not ready 10 seconds ago, then returns null;

      4. close();

      5. reset();

      6. execute(); // the next round of continuous execution, repeat after step 1  ( next() throw another exception to wait for 10 seconds, etc.).

       

      Everything good.

      Now I want to try a different approach. I want to throw DataNotAvailableException.NO_POLLING, and then use executionContext.dataAvailable() to "wake up" translator at some point. My goal - do not wait full 10 seconds if row is availlable earlier.

       

      Here is what I see:

      1. execute()

      2. next() // I throw DataNotAvailableException.NO_POLLING;

      3. onMessage() // this is my custom method, which has the executionContext.dataAvailable() and gets called when the row is ready (can be 1 second delay, can be 100, does not matter);

      4. next() // translator wakes up, method returns the row, then returns null;

      5. close()

      6. reset()

      7. execute() // now the most interesting. After this step we repeat from step 1 - another DataNotAvailableException.NO_POLLING thrown in the next() method. This time the execution locks completely, and dataAvailable() from step 3 has no effect.

      I tried NO_POLLING with and without "strict" option, or as variant a DataNotAvailableException(new Date(from far-far future)) - the same lethargic behavior, I can not wake up translator - the next() method is not executed this time.

       

      Does it mean I can use DataNotAvailableException.NO_POLLING only once per execution, or I overlooked something in my approach?

       

      Thanks,

      Andriy

        • 1. Re: ReusableExecution Lifecycle during Continuous execution
          shawkins

          > This time the execution locks completely, and dataAvailable() from step 3 has no effect.

           

          You'd have to produce a test case.  Each execution gets a different representation in the engine, so what you did the first time should have no effect with regards to delay, the strict setting etc.

          • 2. Re: ReusableExecution Lifecycle during Continuous execution
            rokhmanov

            Steven,

             

            Please see attached MessageReceiveExecution.java and MessageReceiveTest.java. Here is what I am getting as unit test output:

            =======================

            Set wake up call

            !!!! Execute

            !!!! Next

            Exception: org.teiid.translator.DataNotAvailableException

            Send wake call

            !!!! Next

            Exception: null

            msgRow: [MSG_WAKE]

            !!!! Next

            Exception: null

            msgRow: null

            !!! Close

            !!! Reset

            !!!! Execute

            !!!! Next

            Exception: org.teiid.translator.DataNotAvailableException

            Send wake call

            Send wake call

            Send wake call

            Send wake call

            1

            ================

             

            I guess the my problem is in different context between executions, so WakeCaller is runnign out of correct context?

             

            Thanks,

            Andriy

            • 3. Re: ReusableExecution Lifecycle during Continuous execution
              shawkins

              Andriy,

               

              Yes the WakeCaller is using an old ExecutionContext.  We remove the reference to the engine request from the old context so that it's properly eligible for cleanup. You'll want to obtain the current ExectuionContext from the reset method and then call dataAvailable on it.

               

              Steve