[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:comment-tabpanel&focusedCommentId=13637369#comment-13637369 ] 

Pedro Ruivo commented on ISPN-9425:
-----------------------------------

Scenario 1:
I need to do some digging about the failures in program 2. I'm not sure if there are any timeouts check for the operation execution time.
Program 1 is expected to fail. After 1 min, the server will rollback the transaction from program 1 and, when it tries to commit, the transaction no longer exists.

Scenario 2:
The scenario 2 is expected. When the program 2 completed, the transaction in program 1 isn't committed yet. So, the key's value is null.

Scenario 3:
The transaction in program 1 is expected to fail. I'm not sure where the assertion error comes from.

> 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
>
> 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.5.0#75005)