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

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 10.0.0.Final, 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); }

      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.

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

                Created:
                Updated:
                Resolved: