[JBoss JIRA] (ISPN-3442) Query API DSL returns bad result on calling negated between() with includeUpper/Lower(false)
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3442?page=com.atlassian.jira.plugin.... ]
Jiří Holuša updated ISPN-3442:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2030
> Query API DSL returns bad result on calling negated between() with includeUpper/Lower(false)
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-3442
> URL: https://issues.jboss.org/browse/ISPN-3442
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Jiří Holuša
> Assignee: Sanne Grinovero
>
> Assuming existing of three users with IDs 1,2 and 3.
> Then this code's result is incorrect.
> {code:border=solid}
> Query q = queryFactory.from(User.class)
> .not().having("id").between(1, 2).includeLower(false)
> .toBuilder().build();
> {code}
> It returns no user whereas it should return two users with IDs 1 and 3. I debugged the org.infinispan.query.dsl.impl.JPAQueryGeneratorVisitor and found the problem in visit(BetweenOperator operator).
> The code correctly changes the </<= and >/>= operators if between operator is negated, but forgets to change "AND" to "OR".
> Thus the generated string query ends up like "id <= 1 AND id > 2" which is of course always empty result.
> The pull request contains fix to this bug and also extended tests for Query API DSL to increase code coverage.
--
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, 7 months
[JBoss JIRA] (ISPN-3389) Forwarded transactions can remain stale after state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3389?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3389:
------------------------------------
A small correction: at step 3, the tx must be forwarded to the new owner *after* the lock was acquired and registered with the tx.
I managed to reproduce the issue with a unit test. I believe adding a check in StateProviderImpl to ignore txs started in the current topology should be enough to fix the problem as, but we should still add the new owner to the locked nodes set as it clarifies things.
Since the set of locked nodes is now complete, at some point we should try to simplify the other places where we check whether we should invoke a commit/rollback command remotely and on what nodes (e.g. {{BaseDistributionInterceptor.shouldInvokeRemoteTxCommand}}, {{TxDistributionInterceptor.getCommitNodes}}).
> Forwarded transactions can remain stale after state transfer
> ------------------------------------------------------------
>
> Key: ISPN-3389
> URL: https://issues.jboss.org/browse/ISPN-3389
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.7.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 5.2.x
> Fix For: 6.0.0.CR1, 6.0.0.Final
>
>
> There is a scenario where a tx started on one node, moved during state transfer, and committed on the originating node won't be removed from the new owner's tx table.
> The chain of events is as follows:
> 1. New topology comes in as part of a view change.
> 2. Local transaction started with the new topology ID. This transaction was started due to a LockControlCommand and has no modifications. Also important, it only has local locks.
> 3. Tx forwarded to new owner before the local lock is acquired and registered with the transaction.
> 4. Since the tx has only local locks and no modifications, it is only removed locally. No TxCompletion or Rollback are broadcast to the new owners.
> This key becomes unusable not due to stale locks, but because the waitForTransaction() code will see that the old tx can "potentially" lock the key.
> This easily happens with pessimistic caches, though I have seen it happen with optimistic caches (there is a delta between the transaction being created and the lock registration).
--
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, 7 months
[JBoss JIRA] (ISPN-3442) Query API DSL returns bad result on calling negated between() with includeUpper/Lower(false)
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-3442:
---------------------------------
Summary: Query API DSL returns bad result on calling negated between() with includeUpper/Lower(false)
Key: ISPN-3442
URL: https://issues.jboss.org/browse/ISPN-3442
Project: Infinispan
Issue Type: Bug
Components: Querying
Reporter: Jiří Holuša
Assignee: Sanne Grinovero
Assuming existing of three users with IDs 1,2 and 3.
Then this code's result is incorrect.
{code:border=solid}
Query q = queryFactory.from(User.class)
.not().having("id").between(1, 2).includeLower(false)
.toBuilder().build();
{code}
It returns no user whereas it should return two users with IDs 1 and 3. I debugged the org.infinispan.query.dsl.impl.JPAQueryGeneratorVisitor and found the problem in visit(BetweenOperator operator).
The code correctly changes the </<= and >/>= operators if between operator is negated, but forgets to change "AND" to "OR".
Thus the generated string query ends up like "id <= 1 AND id > 2" which is of course always empty result.
The pull request contains fix to this bug and also extended tests for Query API DSL to increase code coverage.
--
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, 7 months
[JBoss JIRA] (ISPN-3441) Silence OutdatedTopologyExceptions
by Michal Linhard (JIRA)
Michal Linhard created ISPN-3441:
------------------------------------
Summary: Silence OutdatedTopologyExceptions
Key: ISPN-3441
URL: https://issues.jboss.org/browse/ISPN-3441
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 6.0.0.Alpha3
Reporter: Michal Linhard
Assignee: Mircea Markus
Priority: Minor
from:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE...
when crashing one node of four in dist sync (owners=2) config resilience test I get:
{code}
06:47:16,805 ERROR [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-20) Exception executing command: org.infinispan.statetransfer.OutdatedTopologyException: Cache topology changed while the command was executing: expected 5, got 6
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:126) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:292) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:374) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:157) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:47) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:200) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:128) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:97) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:46) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:169) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
{code}
Isn't this similar candidate for silencing as SuspectException (ISPN-2577) ?
The difference here is that it doesn't bubble up to hot rod user.
--
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, 7 months
[JBoss JIRA] (ISPN-2013) Using explicit "unlock" causes TimeoutException for other Threads
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2013?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2013:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Using explicit "unlock" causes TimeoutException for other Threads
> -----------------------------------------------------------------
>
> Key: ISPN-2013
> URL: https://issues.jboss.org/browse/ISPN-2013
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.1.2.FINAL
> Environment: Windows 7 64-bit
> Reporter: Dmitry Udalov
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
> Attachments: LockTest.java
>
>
> In a test I have several tasks that run on a single cache node configured as transactional pessimistic replicated cache. If I explicitly call "unlock" then I consistently see TimeoutException reported by some tasks. Without explicit "unlock" the test works fine. Does it mean that I should never call "unlock" and rely on transaction.commit/rollback ? It's seen with infinispan-5.1.2.FINAL
>
> Here's what in a nutshell each task does:
>
> final lockKey = ...
>
> executor.submit(new Callable<Boolean>() {
> public Boolean call() throws Exception
>
> TransactionManager tx = cache.getAdvancedCache().getTransactionManager();
> tx.begin()
> try {
> if ( lockManager.lock(lockKey) ) {
>
> // ...
>
> // removing next line makes test happy. Otherwise some tasks report TimeoutException (pls. see the stack traces)
> cache.getLockManager().unlock(lockKey);
> }
> } catch(Throwable t) {
> tx.setRollbackOnly();
> } finally {
> if (ut.getStatus() == Status.STATUS_ACTIVE)
> ut.commit();
> else
> ut.rollback();
> }
>
>
> By the time I received that exception all other tasks were completed and they released the lock on the key in question.
> I also see that LockManagerImpl.lock recognized that the lock was not owned by any thread - see "Lock held by [null]", which seems to be right. But yet the lock failed to be acquired.
> Is it a matter to trying it one more time?
>
> org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [foo] for requestor [GlobalTransaction:<Sound-15075>:8:local]! Lock held by [null]
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:206)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:180)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:170)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:209)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:136)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:228)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:144)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:207)
> at org.infinispan.interceptors.StateTransferLockInterceptor.visitLockControlCommand(StateTransferLockInterceptor.java:138)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130)
> at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:94)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> at org.infinispan.CacheImpl.lock(CacheImpl.java:484)
> at org.infinispan.CacheImpl.lock(CacheImpl.java:468)
--
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, 7 months
[JBoss JIRA] (ISPN-3430) Different CacheEntryEvents fired in library mode and compatibility mode
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3430?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3430:
-----------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2021, https://github.com/infinispan/infinispan/pull/2028 (was: https://github.com/infinispan/infinispan/pull/2021)
> Different CacheEntryEvents fired in library mode and compatibility mode
> -----------------------------------------------------------------------
>
> Key: ISPN-3430
> URL: https://issues.jboss.org/browse/ISPN-3430
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote protocols
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha2
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode:
> on replace() method: CacheEntryModifiedEvent
> But I tested this feature in compatibility mode (run methods on remote cache and listener bound to embedded cache) and it fires events like this:
> on replace() method: CacheEntryModifiedEvent, CacheEntryVisitedEvent
> Also tested remote caches via Rest and Memcached. All three ways (HotRod, Rest, Memcached) contains this inconsistency on replace() method. In addition, when operating via Rest, on modifying existing entry via put method, it fires CacheEntryVisitedEvent, which is inconsistent even with the other remote caches.
> I further explored the test CustomClassLoaderListenerTest and found another bug + bug in the test
> The test comments are confusing because they are not right. Unfortunately there are two unconsidered event fires and because of the simple final assertion, it went +1 unconsidered event and -1 "over"considered event, so the test passes.
> Summary,
> In library mode, method remove() fires (correctly) only CacheEntryRemoveEvent, not also CacheEntryModifiedEvent as it say comment in that test.
> Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent.
> This is the +1/-1 thing I was talking about.
> The difference in replace() method between library and compatibility mode remains.
> I've pulled request with tests for these things.
> Also I've noticed that when calling replace() containing the same value as it was before calling it (so no change to the value), the CacheEntryModifiedEvent is still fired, but maybe this is a feature, maybe a bug.
--
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, 7 months
[JBoss JIRA] (ISPN-3430) Different CacheEntryEvents fired in library mode and compatibility mode
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3430?page=com.atlassian.jira.plugin.... ]
Jiří Holuša commented on ISPN-3430:
-----------------------------------
Sure, do as you think it's right.
The problem was I didn't know what is expected behavior so I relied on common sense and search for inconsistences. I think (later) it would be helpful to put together some documentation like "on remove() these events are fired: ..., on put() these events are fired: ..." to make things clear
> Different CacheEntryEvents fired in library mode and compatibility mode
> -----------------------------------------------------------------------
>
> Key: ISPN-3430
> URL: https://issues.jboss.org/browse/ISPN-3430
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote protocols
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha2
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode:
> on replace() method: CacheEntryModifiedEvent
> But I tested this feature in compatibility mode (run methods on remote cache and listener bound to embedded cache) and it fires events like this:
> on replace() method: CacheEntryModifiedEvent, CacheEntryVisitedEvent
> Also tested remote caches via Rest and Memcached. All three ways (HotRod, Rest, Memcached) contains this inconsistency on replace() method. In addition, when operating via Rest, on modifying existing entry via put method, it fires CacheEntryVisitedEvent, which is inconsistent even with the other remote caches.
> I further explored the test CustomClassLoaderListenerTest and found another bug + bug in the test
> The test comments are confusing because they are not right. Unfortunately there are two unconsidered event fires and because of the simple final assertion, it went +1 unconsidered event and -1 "over"considered event, so the test passes.
> Summary,
> In library mode, method remove() fires (correctly) only CacheEntryRemoveEvent, not also CacheEntryModifiedEvent as it say comment in that test.
> Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent.
> This is the +1/-1 thing I was talking about.
> The difference in replace() method between library and compatibility mode remains.
> I've pulled request with tests for these things.
> Also I've noticed that when calling replace() containing the same value as it was before calling it (so no change to the value), the CacheEntryModifiedEvent is still fired, but maybe this is a feature, maybe a bug.
--
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, 7 months
[JBoss JIRA] (ISPN-3430) Different CacheEntryEvents fired in library mode and compatibility mode
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3430?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3430:
-----------------------------------
Fix Version/s: 6.0.0.Beta1
6.0.0.Final
Affects Version/s: 5.3.0.Final
> Different CacheEntryEvents fired in library mode and compatibility mode
> -----------------------------------------------------------------------
>
> Key: ISPN-3430
> URL: https://issues.jboss.org/browse/ISPN-3430
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote protocols
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha2
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode:
> on replace() method: CacheEntryModifiedEvent
> But I tested this feature in compatibility mode (run methods on remote cache and listener bound to embedded cache) and it fires events like this:
> on replace() method: CacheEntryModifiedEvent, CacheEntryVisitedEvent
> Also tested remote caches via Rest and Memcached. All three ways (HotRod, Rest, Memcached) contains this inconsistency on replace() method. In addition, when operating via Rest, on modifying existing entry via put method, it fires CacheEntryVisitedEvent, which is inconsistent even with the other remote caches.
> I further explored the test CustomClassLoaderListenerTest and found another bug + bug in the test
> The test comments are confusing because they are not right. Unfortunately there are two unconsidered event fires and because of the simple final assertion, it went +1 unconsidered event and -1 "over"considered event, so the test passes.
> Summary,
> In library mode, method remove() fires (correctly) only CacheEntryRemoveEvent, not also CacheEntryModifiedEvent as it say comment in that test.
> Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent.
> This is the +1/-1 thing I was talking about.
> The difference in replace() method between library and compatibility mode remains.
> I've pulled request with tests for these things.
> Also I've noticed that when calling replace() containing the same value as it was before calling it (so no change to the value), the CacheEntryModifiedEvent is still fired, but maybe this is a feature, maybe a bug.
--
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, 7 months
[JBoss JIRA] (ISPN-3430) Different CacheEntryEvents fired in library mode and compatibility mode
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3430?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3430:
----------------------------------------
{quote}
Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent.
{quote}
^ TBH, cache entry modified event should only be fired when an entry is updated (not when inserted or deleted), but we won't be changing the behaviour in the near future to avoid breaking logic users have built around this. In fact, if no cache entry modified event was thrown on creation, you'd not be able to get a callback with the added entry, as highlighted in http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010272.html. Bringing an entry back to memory from a cache store could be considered as a cache entry modified event, given the loose meaning we have on this event. I don't think we should change this at this point without a full review of events. There's a fair few other inconsistencies around...
The improvements you've made to CustomClassLoaderListenerTest are good though, apart from that expectation error, which I'll switch when committing fix for this.
> Different CacheEntryEvents fired in library mode and compatibility mode
> -----------------------------------------------------------------------
>
> Key: ISPN-3430
> URL: https://issues.jboss.org/browse/ISPN-3430
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote protocols
> Affects Versions: 6.0.0.Alpha2
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
>
> According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode:
> on replace() method: CacheEntryModifiedEvent
> But I tested this feature in compatibility mode (run methods on remote cache and listener bound to embedded cache) and it fires events like this:
> on replace() method: CacheEntryModifiedEvent, CacheEntryVisitedEvent
> Also tested remote caches via Rest and Memcached. All three ways (HotRod, Rest, Memcached) contains this inconsistency on replace() method. In addition, when operating via Rest, on modifying existing entry via put method, it fires CacheEntryVisitedEvent, which is inconsistent even with the other remote caches.
> I further explored the test CustomClassLoaderListenerTest and found another bug + bug in the test
> The test comments are confusing because they are not right. Unfortunately there are two unconsidered event fires and because of the simple final assertion, it went +1 unconsidered event and -1 "over"considered event, so the test passes.
> Summary,
> In library mode, method remove() fires (correctly) only CacheEntryRemoveEvent, not also CacheEntryModifiedEvent as it say comment in that test.
> Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent.
> This is the +1/-1 thing I was talking about.
> The difference in replace() method between library and compatibility mode remains.
> I've pulled request with tests for these things.
> Also I've noticed that when calling replace() containing the same value as it was before calling it (so no change to the value), the CacheEntryModifiedEvent is still fired, but maybe this is a feature, maybe a bug.
--
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, 7 months
[JBoss JIRA] (ISPN-3436) Not working RemoteManager.getBulk() and keySet() in compatibility mode
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3436?page=com.atlassian.jira.plugin.... ]
Jiří Holuša updated ISPN-3436:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2027
> Not working RemoteManager.getBulk() and keySet() in compatibility mode
> ----------------------------------------------------------------------
>
> Key: ISPN-3436
> URL: https://issues.jboss.org/browse/ISPN-3436
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 6.0.0.Alpha3
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Final
>
>
> When using HotRod client in compatibility mode, when trying to put entries via embedded cache and afterwards call RemoteCache.getBulk() or RemoteCache.keySet(), an exception is thrown. Exception is thrown in all cache modes (LOCAL, REPL, DIST).
> {code:borderStyle=solid}
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[3] returned server error (status=0x85): java.lang.ClassCastException: java.lang.Integer cannot be cast to [B
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> ...
> {code}
> Code that did it:
> {code:title=EmbeddedHotRodBulkTest.java|borderStyle=solid}
> public void testEmbeddedPutHotRodGetBulk() {
> Cache<Integer, Integer> embedded = cacheFactory.getEmbeddedCache();
> RemoteCache<Integer, Integer> remote = cacheFactory.getHotRodCache();
> populateCacheManager(embedded);
> Map<Integer, Integer> get = remote.getBulk();
> assertEquals(100, get.size());
> for(int i = 0; i < 100; i++) {
> assertTrue(get.containsValue(i));
> assertTrue(get.containsKey(i));
> }
> }
> {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, 7 months