[infinispan-issues] [JBoss JIRA] (ISPN-9425) HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation

[Pedro Ruivo (Jira)]

     [ https://issues.jboss.org/browse/ISPN-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Ruivo updated ISPN-9425:
------------------------------
              Status: Pull Request Sent  (was: Coding In Progress)
    Git Pull Request: https://github.com/infinispan/infinispan/pull/7259, https://github.com/infinispan/infinispan/pull/7260


> HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-9425
>                 URL: https://issues.jboss.org/browse/ISPN-9425
>             Project: Infinispan
>          Issue Type: Bug
>            Reporter: Diego Lovison
>            Assignee: Pedro Ruivo
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> 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.



--
This message was sent by Atlassian Jira
(v7.13.5#713005)