Derby
  1. Derby
  2. DERBY-5445

Enhance existing concurrency test to stress sequence generators to also stress identity columns

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.8.2.2, 10.9.1.0
    • Fix Version/s: 10.8.2.2, 10.9.1.0
    • Component/s: Test
    • Labels:
      None

      Description

      DERBY-4565 added a concurrency test for sequence generators to test the possible race condition for allocating a new range of pre-allocated numbers for the sequence. I have been looking at enhancing that test to provide similar test for identity columns. I plan to add another command line parameter to the test which will run the concurrency test to stress identity column generator.

      1. fix-init-msg.diff
        1 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Mamta A. Satoor added a comment -

          For some reason, my commit 1179374 for this jira has not yet been assoicated here. The commit had added means to stress test identity columns under concurrent thread. The commit comments are as follows

          DERBY--5445 (Enhance existing concurrency test to stress sequence generators to also stress identity columns)

          DERBY-4565 added a concurrency test to stress sequence generation. I am making simple modifications to that test to add identity column stress testing. Based on a command line parameter, the test will either do sequence generation testing or identity column testing. If no parameter is specified, it will default to doing sequene generation testing.

          The test already takes number of parameters. One of those parameters is load options parameter. Load option parameter is indicated by -load_opts on command line and it is followed by a comma separated list of sub-parameters. An eg of load option parameter is as follows
          -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100
          I am adding another pair to the comma separated sub-parameters,namely identityTest=aNumber. If identityTest is 1, then the test will do identity column stress testing. For any other value for identityTest, the test will do sequence generation testing. If the user doesn't specify identityTest in load options, the test will perform sequence generation testing.

          eg of asking the test to do identity column testing
          java org.apache.derbyTesting.perf.clients.Runner -driver org.apache.derby.jdbc.EmbeddedDriver -init -load seq_gen -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100,identityTest=1 -gen b2b -threads 10

          Two possible way of asking the test to do sequence generation testing(identityTest set to a value other than 1 or identityTest is not specified)
          java org.apache.derbyTesting.perf.clients.Runner -driver org.apache.derby.jdbc.EmbeddedDriver -init -load seq_gen -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100,identityTest=2 -gen b2b -threads 10
          OR
          java org.apache.derbyTesting.perf.clients.Runner -driver org.apache.derby.jdbc.EmbeddedDriver -init -load seq_gen -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100 -gen b2b -threads 10

          When I run the test for identity columns, I can consistently see it running into derby lock time out with nested sequencec contention error while trying to get current identity value and advancing(this is what we want to achieve from the test ie that it is able to stress the functionality enough to run into contention while trying to get next range for identity columns.) Additionally, there are some lock time out errors raised by store while trying to update system catalog(this is expected too because of multiple threads simulataneously trying to do inserts into a table with identity column). I also in my codeline reverted to changes before DERBY-5426 (DERBY-4526 is Improve the error raised by too much contention on a sequence/identity.) was fixed and saw sequence contention errors (without the lock time out error encapsulation).

          Show
          Mamta A. Satoor added a comment - For some reason, my commit 1179374 for this jira has not yet been assoicated here. The commit had added means to stress test identity columns under concurrent thread. The commit comments are as follows DERBY--5445 (Enhance existing concurrency test to stress sequence generators to also stress identity columns) DERBY-4565 added a concurrency test to stress sequence generation. I am making simple modifications to that test to add identity column stress testing. Based on a command line parameter, the test will either do sequence generation testing or identity column testing. If no parameter is specified, it will default to doing sequene generation testing. The test already takes number of parameters. One of those parameters is load options parameter. Load option parameter is indicated by -load_opts on command line and it is followed by a comma separated list of sub-parameters. An eg of load option parameter is as follows -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100 I am adding another pair to the comma separated sub-parameters,namely identityTest=aNumber. If identityTest is 1, then the test will do identity column stress testing. For any other value for identityTest, the test will do sequence generation testing. If the user doesn't specify identityTest in load options, the test will perform sequence generation testing. eg of asking the test to do identity column testing java org.apache.derbyTesting.perf.clients.Runner -driver org.apache.derby.jdbc.EmbeddedDriver -init -load seq_gen -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100,identityTest=1 -gen b2b -threads 10 Two possible way of asking the test to do sequence generation testing(identityTest set to a value other than 1 or identityTest is not specified) java org.apache.derbyTesting.perf.clients.Runner -driver org.apache.derby.jdbc.EmbeddedDriver -init -load seq_gen -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100,identityTest=2 -gen b2b -threads 10 OR java org.apache.derbyTesting.perf.clients.Runner -driver org.apache.derby.jdbc.EmbeddedDriver -init -load seq_gen -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100 -gen b2b -threads 10 When I run the test for identity columns, I can consistently see it running into derby lock time out with nested sequencec contention error while trying to get current identity value and advancing(this is what we want to achieve from the test ie that it is able to stress the functionality enough to run into contention while trying to get next range for identity columns.) Additionally, there are some lock time out errors raised by store while trying to update system catalog(this is expected too because of multiple threads simulataneously trying to do inserts into a table with identity column). I also in my codeline reverted to changes before DERBY-5426 ( DERBY-4526 is Improve the error raised by too much contention on a sequence/identity.) was fixed and saw sequence contention errors (without the lock time out error encapsulation).
          Hide
          Mamta A. Satoor added a comment -

          I was wondering how often does java org.apache.derbyTesting.perf.clients.Runner get run? Don't think it is part of junit suite. Does it get run as part of a new release process?

          Show
          Mamta A. Satoor added a comment - I was wondering how often does java org.apache.derbyTesting.perf.clients.Runner get run? Don't think it is part of junit suite. Does it get run as part of a new release process?
          Hide
          Kristian Waagan added a comment -

          Every day?
          See http://home.online.no/~olmsan/derby/perf/ , accessible from http://dbtg.foundry.sun.com/derby/test/ .

          Since the results don't make sense without comparing them over time (on the same hardware, os, JVM, etc), I don't think they're well suited for running as part of suite.All. Note also that the results can be rather unstable, so to draw conclusions one has to look at the numbers for a longer period of time.
          I don't know if there are any other performance test comparing performance over time for Derby.

          Show
          Kristian Waagan added a comment - Every day? See http://home.online.no/~olmsan/derby/perf/ , accessible from http://dbtg.foundry.sun.com/derby/test/ . Since the results don't make sense without comparing them over time (on the same hardware, os, JVM, etc), I don't think they're well suited for running as part of suite.All. Note also that the results can be rather unstable, so to draw conclusions one has to look at the numbers for a longer period of time. I don't know if there are any other performance test comparing performance over time for Derby.
          Hide
          Knut Anders Hatlen added a comment -

          > For some reason, my commit 1179374 for this jira has not yet been
          > assoicated here. The commit had added means to stress test identity
          > columns under concurrent thread. The commit comments are as follows
          >
          > DERBY--5445 (...)

          Probably the extra hyphen is why it didn't get associated with the issue.

          Show
          Knut Anders Hatlen added a comment - > For some reason, my commit 1179374 for this jira has not yet been > assoicated here. The commit had added means to stress test identity > columns under concurrent thread. The commit comments are as follows > > DERBY--5445 (...) Probably the extra hyphen is why it didn't get associated with the issue.
          Hide
          Mamta A. Satoor added a comment -

          Knut, thanks for noticing that extra hyphen. I have editted the svn comment to fix it.

          Show
          Mamta A. Satoor added a comment - Knut, thanks for noticing that extra hyphen. I have editted the svn comment to fix it.
          Hide
          Knut Anders Hatlen added a comment -

          The original "initializing database..." message was changed by this issue to "initializing database for identity column testing..." or "initializing database for sequence generator testing..."

          Although the new messages are more accurate when testing identity columns or sequence generators, they are wrong when running the other tests that don't use identity columns or sequence generators.

          The attached patch changes the message back to the original.

          Committed revision 1185056.

          Show
          Knut Anders Hatlen added a comment - The original "initializing database..." message was changed by this issue to "initializing database for identity column testing..." or "initializing database for sequence generator testing..." Although the new messages are more accurate when testing identity columns or sequence generators, they are wrong when running the other tests that don't use identity columns or sequence generators. The attached patch changes the message back to the original. Committed revision 1185056.
          Hide
          Myrna van Lunteren added a comment -

          Is there more expected on this issue?

          Show
          Myrna van Lunteren added a comment - Is there more expected on this issue?
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update: close all resolved issues that haven't had any activity the last year]

          Show
          Knut Anders Hatlen added a comment - [bulk update: close all resolved issues that haven't had any activity the last year]

            People

            • Assignee:
              Mamta A. Satoor
              Reporter:
              Mamta A. Satoor
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development