Uploaded image for project: 'Teiid'
  1. Teiid
  2. TEIID-3707

Wrong Data returned when a procedure is executed in the SELECT clause

      I've found the following problem when executing a stored procedure in the SELECT clause. It calculates wrong data in a seemingly random fashion.

      This is a stored procedure which was created to determine whether a given coordinate lies within a specific rectangle. If this procedure is tested in a simple manner (SELECT .. FROM (EXEC ..)) the results are correctly retuned (0 = outside the rectangle and 1 otherwise).

          CREATE virtual procedure point_inside_store (
                                      pos_x float
                                     ,pos_y float
                ) RETURNS (
                       "insideFence" integer
                ) AS
                BEGIN
                   DECLARE integer insideFence = 0 ;
                   DECLARE float lowerLimit = 0.0 ;
                   DECLARE float upperLimit = 17.0 ;
                   DECLARE float leftLimit = 0.0 ;
                   DECLARE float rightLimit = 53.0 ;
                   IF (
                        pos_x >= leftLimit
                        AND pos_x <= rightLimit
                        AND pos_y >= lowerLimit
                        AND pos_y <= upperLimit
                   )
                   BEGIN
                        insideFence = 1 ;
                   END
                   SELECT
                          insideFence ;
               END
      

      If now the same procedure is included in a SELECT clause of a query:

          SELECT
              "citmp.KoordX"
              ,"citmp.KoordY"
              ,(
                  SELECT
                          "store.insideFence"
                      FROM
                          (
                              EXEC procs.point_inside_store (
                                  CAST (
                                      "citmp.KoordX" AS float
                                  )
                                  ,CAST (
                                      "citmp.KoordY" AS float
                                  )
                              )
                          ) as "store"
              ) as "insideStore"
              ,(
                  SELECT
                          "firstsection.insideFence"
                      FROM
                          (
                              EXEC procs.point_inside_store (
                                  CAST (
                                      "citmp.KoordX" AS float
                                  )
                                  ,CAST (
                                      "citmp.KoordY" AS float
                                  )
                              )
                          ) as "firstsection"
              ) as "insideFirstsection"
          FROM
              "test.sample_coords" as "citmp"
          ORDER BY
              insideStore ASC
              ,insideFirstsection DESC;;
      

      it calculates different results. The same coordinates that yielded 0 before now yield 1.

      Note that the main query has 2 columns executing the exact same procedure but there are result sets, that have different values in the last two columns. This should not be possible.
      In attachment you will find sample_coords table with a sample of coordinates.

        1. highcpu-threads.png
          highcpu-threads.png
          20 kB
        2. out.1
          5 kB
        3. out.2
          6 kB
        4. out.3
          8 kB
        5. sample_coords.sql
          1.39 MB
        6. wrong_data.jpg
          wrong_data.jpg
          117 kB

            [TEIID-3707] Wrong Data returned when a procedure is executed in the SELECT clause

            With the 1.7 JDK I was able to reproduce this. It's a unit test issue corrected by https://github.com/teiid/teiid/commit/5df19a2c1cea6f23912b9c1262ada5dc7524e196

            A mock logger was being left on for the test which was storing the invocations, which led to gc issues.

            Steven Hawkins added a comment - With the 1.7 JDK I was able to reproduce this. It's a unit test issue corrected by https://github.com/teiid/teiid/commit/5df19a2c1cea6f23912b9c1262ada5dc7524e196 A mock logger was being left on for the test which was storing the invocations, which led to gc issues.

            Can you confirm if this behaves differently with the commit https://github.com/teiid/teiid/commit/b3bdab3299fc6174bb38b2f1e5d508a463f1c5e3

            What I see running this test on latest in a tight loop is that threads, cpu, and memory usage, are all stable. That's with oracle 1.8 or openjdk 1.7/1.8.

            Steven Hawkins added a comment - Can you confirm if this behaves differently with the commit https://github.com/teiid/teiid/commit/b3bdab3299fc6174bb38b2f1e5d508a463f1c5e3 What I see running this test on latest in a tight loop is that threads, cpu, and memory usage, are all stable. That's with oracle 1.8 or openjdk 1.7/1.8.

            Which JRE is this?

            Steven Hawkins added a comment - Which JRE is this?

            From highcpu-threads.png GC threads as below consume high cpu

            "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fa44001d800 nid=0x12b5 runnable
            
            "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fa44001f800 nid=0x12b6 runnable
            
            "GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007fa440021000 nid=0x12b7 runnable
            
            "GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007fa440023000 nid=0x12b8 runnable
            

            Kylin Soong (Inactive) added a comment - From highcpu-threads.png GC threads as below consume high cpu "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fa44001d800 nid=0x12b5 runnable "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fa44001f800 nid=0x12b6 runnable "GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007fa440021000 nid=0x12b7 runnable "GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007fa440023000 nid=0x12b8 runnable

            > cause gc thread consume high cpu, seems create a lot of threads, some time will failed test.

            I'm not sure what you are seeing. There is only a single client thread. What is your platform and can you provide a thread dump and the failure you are seeing?

            Steven Hawkins added a comment - > cause gc thread consume high cpu, seems create a lot of threads, some time will failed test. I'm not sure what you are seeing. There is only a single client thread. What is your platform and can you provide a thread dump and the failure you are seeing?

            Kylin Soong (Inactive) added a comment - - edited

            I have met a build error that new added

            public void testSubqueryCache() throws Exception {
            

            cause gc thread consume high cpu, seems create a lot of threads, some time will failed test.

            Kylin Soong (Inactive) added a comment - - edited I have met a build error that new added public void testSubqueryCache() throws Exception { cause gc thread consume high cpu, seems create a lot of threads, some time will failed test.

            Thanks for bringing it to our attention.

            Steven Hawkins added a comment - Thanks for bringing it to our attention.

            Thank you, Steven, for the quick fix.

            Dmitrii Pogorelov added a comment - Thank you, Steven, for the quick fix.

            This was a regression in TEIID-1518. It requires a fairly specific set of circumstances to reproduce, so it does not occur in all situations involving deterministic subqueries.

            Steven Hawkins added a comment - This was a regression in TEIID-1518 . It requires a fairly specific set of circumstances to reproduce, so it does not occur in all situations involving deterministic subqueries.

            Yes, I can reproduce it as well. The small cache that is kept to lessen repeated subquery invocation has a bug that causes the purging of items from the first to second level to have the wrong cache key. This is why reproducing this is dependent upon the procedure being expressed as a subquery and the amount of data from the parent query.

            Steven Hawkins added a comment - Yes, I can reproduce it as well. The small cache that is kept to lessen repeated subquery invocation has a bug that causes the purging of items from the first to second level to have the wrong cache key. This is why reproducing this is dependent upon the procedure being expressed as a subquery and the amount of data from the parent query.

              rhn-engineering-shawkins Steven Hawkins
              dalex005 Dmitrii Pogorelov
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: