Derby
  1. Derby
  2. DERBY-5671

NsTest does not run on trunk do multiple issues stemming from concurrency improvements

    Details

    • Issue & fix info:
      High Value Fix
    • Bug behavior facts:
      Regression

      Description

      As I understand it at least since September 30 of last year, the system test NsTest has been broken on trunk. In these six months the test has not been runnable, so we do not know if new issues have been introduced with sequence generators or most importantly with auto-increment columns that are now based on them, which many, many applications rely upon. Even if the known problems are fixed later in the 10.9 release cycle and new problems are exposed, we won't be able to go back to any point in time to discover when they might be released.

      In 10.8 we coped with this problem by backing out the concurrency improvements (DERBY-5448) pending fixes for DERBY-5422, DERBY-5454, DERBY-5430. Currently none of those issues have been assigned. Since this has been going on now for six months, I think we urgently need to stabiliize auto-increment columns and get this test running again on trunk. I can see three possible options.
      1) Someone with interest assign themselves to these issues and make significant progress over the next few weeks.
      2) Make the concurrency improvements optional with a property which defaults to false (I don't know if this is practical)
      3) Back the concurrency performance improvements out of trunk until these issues have been resolved and the change can be resubmitted.

      I realize that NsTest is not the easiest test to work with but it does seem to have found serious problems with generated columns that I think users are likely to hit. In the past, a similiar disregard for mailjdbc exposing a corruption issue meant that we actually released a bad corruption issue that I know hit many users of Derby before we addressed it. Autoincrement is widely, widely, used. We need to get it stabilized and the test running on trunk. Although the system tests are not particularly easy to deal with, they are all we have and they do find issues.

        Issue Links

          Activity

          Kathey Marsden created issue -
          Kathey Marsden made changes -
          Field Original Value New Value
          Link This issue is related to DERBY-5422 [ DERBY-5422 ]
          Kathey Marsden made changes -
          Link This issue is related to DERBY-5454 [ DERBY-5454 ]
          Kathey Marsden made changes -
          Link This issue is related to DERBY-5430 [ DERBY-5430 ]
          Kathey Marsden made changes -
          Link This issue is related to DERBY-5448 [ DERBY-5448 ]
          Kathey Marsden made changes -
          Description As I understand it at least since September 30 of last year, the system test NsTest has been broken on trunk. In these six months the test has not been runnable, so we do not know if new issues have been introduced with sequence generators or most importantly with auto-increment columns that are now based on them, which many, many applications rely upon. Even if the known problems are fixed later in the 10.9 release cycle and new problems are exposed, we won't be able to go back to any point in time to discover when they might be released.

          In 10.8 we coped with this problem by backing out the concurrency improvements (DERBY-4448) pending fixes for DERBY-5422, DERBY-5454, DERBY-5430. Currently none of those issues have been assigned. Since this has been going on now for six months, I think we urgently need to stabiliize auto-increment columns and get this test running again on trunk. I can see three possible options.
              1) Someone with interest assign themselves to these issues and make significant progress over the next few weeks.
              2) Make the concurrency improvements optional with a property which defaults to false (I don't know if this is practical)
              3) Back the concurrency performance improvements out of trunk until these issues have been resolved and the change can be resubmitted.

          I realize that NsTest is not the easiest test to work with but it does seem to have found serious problems with generated columns that I think users are likely to hit. In the past, a similiar disregard for mailjdbc exposing a corruption issue meant that we actually released a bad corruption issue that I know hit many users of Derby before we addressed it. Autoincrement is widely, widely, used. We need to get it stabilized and the test running on trunk. Although the system tests are not particularly easy to deal with, they are all we have and they do find issues.


          As I understand it at least since September 30 of last year, the system test NsTest has been broken on trunk. In these six months the test has not been runnable, so we do not know if new issues have been introduced with sequence generators or most importantly with auto-increment columns that are now based on them, which many, many applications rely upon. Even if the known problems are fixed later in the 10.9 release cycle and new problems are exposed, we won't be able to go back to any point in time to discover when they might be released.

          In 10.8 we coped with this problem by backing out the concurrency improvements (DERBY-5448) pending fixes for DERBY-5422, DERBY-5454, DERBY-5430. Currently none of those issues have been assigned. Since this has been going on now for six months, I think we urgently need to stabiliize auto-increment columns and get this test running again on trunk. I can see three possible options.
              1) Someone with interest assign themselves to these issues and make significant progress over the next few weeks.
              2) Make the concurrency improvements optional with a property which defaults to false (I don't know if this is practical)
              3) Back the concurrency performance improvements out of trunk until these issues have been resolved and the change can be resubmitted.

          I realize that NsTest is not the easiest test to work with but it does seem to have found serious problems with generated columns that I think users are likely to hit. In the past, a similiar disregard for mailjdbc exposing a corruption issue meant that we actually released a bad corruption issue that I know hit many users of Derby before we addressed it. Autoincrement is widely, widely, used. We need to get it stabilized and the test running on trunk. Although the system tests are not particularly easy to deal with, they are all we have and they do find issues.


          Rick Hillegas made changes -
          Link This issue relates to DERBY-5495 [ DERBY-5495 ]
          Rick Hillegas made changes -
          Link This issue is related to DERBY-5687 [ DERBY-5687 ]
          Myrna van Lunteren made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 10.9.0.0 [ 12316344 ]
          Resolution Fixed [ 1 ]
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12659541 ] Default workflow, editable Closed status [ 12802756 ]
          Kathey Marsden made changes -
          Labels derby_backport_reject_10_8

            People

            • Assignee:
              Unassigned
              Reporter:
              Kathey Marsden
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development