[
https://issues.jboss.org/browse/ISPN-4810?page=com.atlassian.jira.plugin....
]
William Burns commented on ISPN-4810:
-------------------------------------
[~dan.berindei] Unfortunately I can't say, but yes I assume it was a null returned
from polling the queue. However if the size is greater than max there should be something
in the queue to remove - since they should have exclusive access (fullMiss is only ever
invoked from a miss which has the lock to the segment). A hit could come in but it would
have to be over the maximum queue size in the BatchWrapper and can cause havoc if more
than 1 thread was running in a LIRS segment.
In regards to our existing LIRS implementation it doesn't use HIR_NONRESIDENT in a
meaningful way, so a value shouldn't be able to be null. The only way an entry is set
to non resident is if it is evicted in which case it removes it from the stack and queue
(non resident are supposed to stay in the stack).
Local Transactional Cache loses data when eviction is enabled and
there are multiple readers and one writer
-----------------------------------------------------------------------------------------------------------
Key: ISPN-4810
URL:
https://issues.jboss.org/browse/ISPN-4810
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.2.Final
Environment: Windows 7 x64 (NTFS)
Oracle JDK1.7.0_40
Apache Maven 3.0.5
Reporter: Horia Chiorean
Assignee: William Burns
Labels: modeshape
Attachments: ispn_concurrent.zip
Using Infinispan 6.0.2 and a local, transactional cache backed by a <singleFile>
store, with eviction enabled and a small {{max-entries}} setting, we have the following
scenario:
* the main thread (i.e. the "writer") starts a transaction, adds a batch of
strings into the cache and also appends the same strings into a List cache entry and then
commits the transaction
* after the above has finished (i.e. after tx.commit) it fires a number of reader threads
where each reader thread
** checks that the string entries were added into the cache and
** checks that the entries were correctly appended to the List entry
* the above steps are repeated a number of times
On any given run, based on timing, we're seeing that at some point (after some time)
some of the reader threads will not see the latest version of the List entry (i.e. will
not see the latest elements that were added into the list) but rather an old, stale List
(sort of a "lost update" scenario).
If we either:
* disable eviction or
* set the {{max-entries}} to a large enough value (which I suspect has the same effect -
not evicting anything) the problem doesn't show up.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)