[
https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-2891:
----------------------------------------
From what I understand (I'll let [~mircea.markus] correct me if
I'm wrong...), the test passing with the expected counter number, or failing with a
write skew failure, are to be expected. If you wanna keep track of a count, pessimistic
locking is more suited for the job. With optimistic locking, it could happen that two
threads get to the update the value concurrently, with one of them doing it and the other
failing with a write skew.
Side note: I wonder whether in an implicit transaction, with a conditional operation such
as a replace(), no write skew exceptions should be returned, and instead the friendlier
false return indicating that the replace() didn't complete... I'll send an email
to the dev list.
What could be a bug is the ugly log, where the count ends in two and no exceptions. I need
to look at the logs and the clojure test in more detail, cos I can't really figure out
whether the count being logged as 2 (and TRACE showing 3), is a bug of the test code
itself, or Infinispan.
Calls to replace don't update cache until after tx commits
----------------------------------------------------------
Key: ISPN-2891
URL:
https://issues.jboss.org/browse/ISPN-2891
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.2.1.Final
Reporter: Jim Crossley
Assignee: Galder Zamarreño
Labels: 5.2.x
Fix For: 5.3.0.Alpha1, 5.3.0.Final
Attachments: bad.log, good.log, ugly.log
Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final),
one of our integration tests has begun failing intermittently on our CI server. We've
yet to see the failure in local runs, only on CI, so I suspect there's something
racist going on.
The two tests (one for optimistic locking, the other for pessimistic) integrate an
Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions.
A number of queue listeners respond to messages by attempting to increment a value in the
cache. The failure occurs with both locking schemes, but much more often with optimistic.
We've confirmed the failure on 5.2.2 as well.
Attached you'll find three traces of the optimistic test: the good, the bad, and the
ugly. All three correspond to this test:
https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531...
So you can correlate the log messages prefixed with "JC:" in the traces to the
code. Note in particular the last two lines in locking.clj: a logged message containing
the count, and then an assertion of the count. Note that the "bad" trace was an
actual failing test, but the "ugly" trace was a successful test, even though the
trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly
shows the value as 3, hence the ugliness of this test.
It's important to understand that the "work" function occurs within an XA
transaction. This means, as I understand it, that if three messages are published to
"/queue/done", the cached count should equal 3. Line #44 in locking.clj will
block until it receives 3 messages, after which the cached count should be 3.
These tests always pass locally. They only ever fail on CI, which runs *very* slowly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira