Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-2651

Default useSynchronization and recovery value changes make tests fail

    XMLWordPrintable

Details

    Description

      While investigating ISPN-2054 I've found an important issue wrt default transaction configuration options.

      First of all, InvocationContextTest.testMishavingListenerResumesContext() is incorrectly coded. It misses the following line after the cache put call to make sure that only exceptional path makes the test pass:

      fail("Should have failed with an exception");

      With that in mind, and taking in account that this test uses old programmatic configuration:

      Configuration cfg = TestCacheManagerFactory.getDefaultConfiguration(true);
      cfg.setSyncCommitPhase(true);
      cfg.setSyncRollbackPhase(true);
      cfg.fluent().transaction().lockingMode(LockingMode.PESSIMISTIC);
      createClusteredCaches(1, "timestamps", cfg);
      

      We should be able to switch it to equivalent new configuration and testMishavingListenerResumesContext should pass:

      ConfigurationBuilder builder = TestCacheManagerFactory.getDefaultCacheConfiguration(true);
      builder.transaction()
         .syncCommitPhase(true).syncRollbackPhase(true)
         .lockingMode(LockingMode.PESSIMISTIC);
      createClusteredCaches(1, "timestamps", builder);
      

      The problem is that the test does not pass once you switch to equivalent new configuration. It fails with "Should have failed with an exception" message.

      After debugging, the reason is cos default values in old configuration have been changed for new configuration. To be more precise, in old configuration, defaults are:

      useSynchronization = false
      recovery enabled = false

      In new configuration, equivalent defaults are:

      useSynchronization = true
      recovery enabled = true

      In fact, once you change defaults in new configuration to be both false, the test passes.

      So, this JIRA must address the following:

      1. Why have default values have changed? This is very risky since what should be equivalent configurations externally don't behave the same way.

      2. When has these defaults changed and since when has the behaivour changed?

      3a. If these new default values are reasonable, documentation must be provided in our upgrade guide section bearing in mind the major version in which the default values changed (see https://docs.jboss.org/author/display/ISPN/Upgrade+Guide). The code should also be documented to note down that some tests might fail which would not otherwise because of change of those default values

      3b. If default values should not have changed, they must be reverted and it needs to be checked whether any major release has been out with the default values changed and document it.

      Attachments

        Issue Links

          Activity

            People

              mircea.markus Mircea Markus (Inactive)
              rh-ee-galder Galder ZamarreƱo
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: