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

HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Critical
    • 10.0.0.CR2, 9.4.17.Final
    • None
    • None
    • None
    • Hide

      You should start a server ( ./standalone.sh -c clustered.xml ) and use the following code

         private static RemoteCache<String, String> getOrCreateCache() {

      RemoteCacheManager remoteCacheManager =
            new RemoteCacheManager(new org.infinispan.client.hotrod.configuration.ConfigurationBuilder()
                  .addServer()
                  .host("localhost")
                  .port(11222)
                  .transaction()
                  .transactionMode(transactionMode)
                  .forceReturnValues(true)
                  .build());

      return remoteCacheManager.administration().getOrCreateCache("foo-tx-cache", new org.infinispan.configuration.cache.ConfigurationBuilder()
            .clustering().cacheMode(CacheMode.DIST_SYNC)
            .jmxStatistics().enable()
            .transaction()
               .cacheStopTimeout(0L)
            .transactionManagerLookup(new EmbeddedTransactionManagerLookup())
            .lockingMode(LockingMode.PESSIMISTIC)
            .locking().isolationLevel(IsolationLevel.REPEATABLE_READ)
            .build());
   }

   public static void main(String... args) throws Exception {

      RemoteCache<String, String> remoteCache = getOrCreateCache();

      final TransactionManager tm = remoteCache.getTransactionManager();

      String value = UUID.randomUUID().toString();

      //test with tx
      tm.begin();
      remoteCache.put("foo", value);
      tm.commit();

      String cacheValue = remoteCache.get("foo");

      Assert.assertEquals(cacheValue, value);
   }
      Show
      You should start a server ( ./standalone.sh -c clustered.xml ) and use the following code private static RemoteCache< String , String > getOrCreateCache() { RemoteCacheManager remoteCacheManager = new RemoteCacheManager( new org.infinispan.client.hotrod.configuration.ConfigurationBuilder() .addServer() .host( "localhost" ) .port(11222) .transaction() .transactionMode(transactionMode) .forceReturnValues( true ) .build()); return remoteCacheManager.administration().getOrCreateCache( "foo-tx-cache" , new org.infinispan.configuration.cache.ConfigurationBuilder() .clustering().cacheMode(CacheMode.DIST_SYNC) .jmxStatistics().enable() .transaction() .cacheStopTimeout(0L) .transactionManagerLookup( new EmbeddedTransactionManagerLookup()) .lockingMode(LockingMode.PESSIMISTIC) .locking().isolationLevel(IsolationLevel.REPEATABLE_READ) .build()); } public static void main( String ... args) throws Exception { RemoteCache< String , String > remoteCache = getOrCreateCache(); final TransactionManager tm = remoteCache.getTransactionManager(); String value = UUID.randomUUID().toString(); //test with tx tm.begin(); remoteCache.put( "foo" , value); tm.commit(); String cacheValue = remoteCache.get( "foo" ); Assert.assertEquals(cacheValue, value); }

    Description

      There are 3 scenarios and I believe that they are correlated. If it is not the case, a JIRA for each item should be open.

      All scenarios below are multiple clients and one server. The following steps should be executed does not matter what is the scenario.

      • Add one breakpoint at the first line of the method `acceptResponse` at the class PrepareTransactionOperation
      • Add one breakpoint at the first line of the method `executeOperation` at the class PrepareTransactionOperation

      Scenario 1

      • Execute the client code ( Program 1 )
      • Execute the client code ( Program 2 )
      • Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
      • Program 2 -> Resume, Resume. It will stop at `executeOperation`.
      • Wait 5 minutes or any time greater than 60 seconds ( I was not able to identify the right period of time but greater than 60 seconds should work), Resume and Resume the "Program 2". It will fail.
      • The issue in scenario 1 is: Why doesn't matter the amount of time since it is greater than 60 seconds the request will fail? I am expecting something like a timeout in the "Program 1" and not expire when a call in that key was called for the first time.
      • Kill all clients and servers

      Scenario 2

      • Execute the client code ( Program 1 )
      • Execute the client code ( Program 2 )
      • Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
      • Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume.
      • Program 1 -> Resume.
      • The issue in scenario 2 is: Why the test fails due: expected value 'null' different from 'random-value-generated'
      • Kill all clients and servers

      Scenario 3

      • Execute the client code ( Program 1 )
      • Execute the client code ( Program 2 )
      • Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`.
      • Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume.
      • Wait 60 seconds
      • Re-run Program 2 -> Resume, Resume, Resume, Resume. It will work.
      • Program 1 -> Resume, it will fail due to an assertion error
      • The issue in scenario 3 is: When resuming the "Program 1" I am expecting an error during the commit phase and not an assertion error.
      • Kill all clients and servers

      Program 1 means that you should run the client code. It will create a separated JVM.
      Program 2 means that you should run the client code. It will create a separated JVM.

      It will be nice if we find out an way to automate this kind of tests.

      Attachments

        Issue Links

          is caused by

          Enhancement - An enhancement to or refactoring of existing functionality that is not configurable by an end user (typically a change made by an internal team that affects users) ISPN-9261 Hot Rod Lightweight Transaction (recovery)

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              pruivo@redhat.com Pedro Ruivo
              dlovison@redhat.com Diego Lovison
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: