[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2956:
--------------------------------
Fix Version/s: 7.0.0.Alpha4
(was: 7.0.0.Alpha3)
> putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
> -------------------------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Minor
> Labels: hotrod-java-client, remote-clients
> Fix For: 7.0.0.Alpha4
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it.
--
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
12 years
[JBoss JIRA] (ISPN-2958) Lucene Directory Read past EOF
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2958?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2958:
--------------------------------
Fix Version/s: 7.0.0.Alpha4
(was: 7.0.0.Alpha3)
> Lucene Directory Read past EOF
> ------------------------------
>
> Key: ISPN-2958
> URL: https://issues.jboss.org/browse/ISPN-2958
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.1.Final
> Reporter: Clement Pang
> Assignee: Pedro Ruivo
> Labels: retest, stable_embedded_query
> Fix For: 7.0.0.Alpha4
>
>
> This seems to be happening rather deterministically.
> Infinispan configuration (in JBoss EAP 6.1.0.Alpha):
> {code}
> <cache-container name="lucene">
> <local-cache name="dshell-index-data" start="EAGER">
> <eviction strategy="LIRS" max-entries="50000"/>
> <file-store path="lucene" passivation="true" purge="false"/>
> </local-cache>
> <local-cache name="dshell-index-metadata" start="EAGER">
> <file-store path="lucene" passivation="true" purge="false"/>
> </local-cache>
> <local-cache name="dshell-index-lock" start="EAGER">
> <file-store path="lucene" passivation="true" purge="false"/>
> </local-cache>
> </cache-container>
> {code}
> Upon shutting down the server and confirming that passivation did indeed write the data to disk, the subsequent start-up would fail right away with:
> {code}
> Caused by: org.hibernate.search.SearchException: Could not initialize index
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:162)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 64 more
> Caused by: java.io.IOException: Read past EOF
> at org.infinispan.lucene.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:77)
> at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:86)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272)
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1168)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157)
> ... 67 more
> {code}
--
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
12 years
[JBoss JIRA] (ISPN-3448) Tests from org.infinispan.distribution.rehash package fail randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3448?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3448:
--------------------------------
Fix Version/s: 7.0.0.Alpha4
(was: 7.0.0.Alpha3)
> Tests from org.infinispan.distribution.rehash package fail randomly
> -------------------------------------------------------------------
>
> Key: ISPN-3448
> URL: https://issues.jboss.org/browse/ISPN-3448
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Alpha3, 6.0.0.CR1, 6.0.0.Final
> Reporter: Jiří Holuša
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 6.0.1.Final, 7.0.0.Alpha4
>
> Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent.log.zip, NonTxStateTransferOverwritingValue2Test.log.zip, NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringPutOverwrite.log.zip, NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringRemove.log.zip, NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuring{Remove, Replace}WithPreviousValue.log.zip
>
>
> These tests are randomly failing on various platforms (RHEL, Solaris) with various JDKs.
> org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxJoinerBecomingBackupOwnerTest.testBackupOwnerJoiningDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringJoinStressTest.testNodeJoiningDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxJoinerBecomingBackupOwnerTest.testBackupOwnerJoiningDuringPut
> org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringRemove
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringPutOverwrite
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringRemoveWithPreviousValue
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringReplaceWithPreviousValue
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringReplace
> New randomly failing test
> org.infinispan.distribution.rehash.ConcurrentOverlappingLeaveTest.testNonTransactional
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
12 years