[JBoss JIRA] (ISPN-3335) JMX statistics for Queries partially doesn't work
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3335?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3335:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1024914|https://bugzilla.redhat.com/show_bug.cgi?id=1024914] from NEW to ON_QA
> JMX statistics for Queries partially doesn't work
> -------------------------------------------------
>
> Key: ISPN-3335
> URL: https://issues.jboss.org/browse/ISPN-3335
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha1
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: QueryMBeanTest.java
>
>
> I was playing around with Query JMX statistics, and found out that there are several attributes like SearchQueryTotalTime are always 0 (this attr. represents the duration of query in nano-seconds), even though I'm running the infinispan query.
> The only attribute which is updated and returns proper value is StatisticsEnabled. Also the following operations work as expected:
> getNumberOfIndexedEntities(String entity)
> clear()
> I've tried also to retrieve the statistics using the following method:
> {code}
> Search.getSearchManager(cacheManager.getCache(CACHE_NAME)).getSearchFactory().getStatistics().getSearchQueryTotalTime()
> {code}
> and it returns the same results as if getting via JMX.
> You can find the whole running test attached.
> Best regards,
> Anna.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3448) Tests from org.infinispan.distribution.rehash package fail randomly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3448?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3448:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1002507|https://bugzilla.redhat.com/show_bug.cgi?id=1002507] from ASSIGNED to ON_QA
> 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 API
> Affects Versions: 6.0.0.Alpha3, 6.0.0.CR1, 6.0.0.Final
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 6.1.0.Final
>
> 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
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3354) Multiple events on the local node with Infinispan 5.3.0-final
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3354?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3354:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1024942|https://bugzilla.redhat.com/show_bug.cgi?id=1024942] from POST to ON_QA
> Multiple events on the local node with Infinispan 5.3.0-final
> -------------------------------------------------------------
>
> Key: ISPN-3354
> URL: https://issues.jboss.org/browse/ISPN-3354
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Affects Versions: 5.3.0.Final
> Reporter: Luca Zenti
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: TestInfinispanDuplicatedEvents.java
>
>
> After upgrading to Infinispan 5.3.0-final I found a strange "intermittent" problem in my application. Digging a bit deeper, I found out it is due to CacheEntry events raised twice for some keys on the local node (the node where the cache operation is invoked).
> I was able to reproduce the problem and I wrote the attached test case.
> The problem happens regardless of the cluster mode, but only with non-transactional caches. I think this is due to the fact that with transactional caches the events are raised on commit.
> Also, my application used to work with an interceptor rather than an event listener, so I actually found the problem when I saw my interceptor being occasionally executed 3 times with 2 nodes.
> I'm not sure whether the command and the chain of interceptor is really meant to be executed twice on the local node, but the consequent behaviour on the events sounds like 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
10 years, 5 months
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3316:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1024410|https://bugzilla.redhat.com/show_bug.cgi?id=1024410] from NEW to ON_QA
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final, 6.0.0.Final
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3745) Forwarded Prepare/Commit executed after transaction finished
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3745:
-----------------------------------
Thinking about that once more, the broadcast optimization may be the villain here as well, because the apex863 (sender) has just joined. It got the prepare/commit as this was broadcast but nobody waited for its response. Then, it could forward the commands to the old nodes and these executed it again.
> Forwarded Prepare/Commit executed after transaction finished
> ------------------------------------------------------------
>
> Key: ISPN-3745
> URL: https://issues.jboss.org/browse/ISPN-3745
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
>
> Replicated TX cache, nodes A, B, C
> 0. A and B have topology 2, C already got topology 3
> 1. A sends prepare with topology 2 to B and C, both apply the prepare and respond
> 2. C forwards prepare to B with topology 3
> 3. A sends commit with topology 2 to B and C, both commit and respond
> 4. again, C forwards prepare to B with topology 3
> 5. A and B get updated topology id
> 6. A executes another transaction on the same entry
> 7. prepare and commit from first transaction with topology 3 arrive at B - B overwrites (or removes) the entry again
> Result: on B we have inconsistent state
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3745) Forwarded Prepare/Commit executed after transaction finished
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3745:
-----------------------------------
You're right, as I have synchronous tx cache, the forwarding should be synchronous. Regrettably, I miss the logs from the forwarding node (it got truncated), just to let you see what happened:
{code}
04:19:29,410 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-95,default,apex862-11617) Attempting to execute command: CommitCommand {gtx=GlobalTransaction:<apex861-22006>:164595:
local, cacheName='testCache', topologyId=18} [sender=apex861-22006]
04:19:29,411 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-14) Calling perform() on CommitCommand {gtx=GlobalTransaction:<apex861-22006>:164595:remote, cacheName='testCache', topologyId=18}
04:19:29,412 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-14) About to send back response SuccessfulResponse{responseValue=null} for command CommitCommand {gtx=GlobalTransaction:<apex861-22006>:164595:remote, cacheName='testCache', topologyId=18}
04:19:31,301 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-78,default,apex862-11617) Attempting to execute command: PrepareCommand {modifications=[ ... ], onePhaseCommit=false, gtx=GlobalTransaction:<apex861-22006>:164595:local, cacheName='testCache', topologyId=19} [sender=apex863-20495]
{code}
> Forwarded Prepare/Commit executed after transaction finished
> ------------------------------------------------------------
>
> Key: ISPN-3745
> URL: https://issues.jboss.org/browse/ISPN-3745
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
>
> Replicated TX cache, nodes A, B, C
> 0. A and B have topology 2, C already got topology 3
> 1. A sends prepare with topology 2 to B and C, both apply the prepare and respond
> 2. C forwards prepare to B with topology 3
> 3. A sends commit with topology 2 to B and C, both commit and respond
> 4. again, C forwards prepare to B with topology 3
> 5. A and B get updated topology id
> 6. A executes another transaction on the same entry
> 7. prepare and commit from first transaction with topology 3 arrive at B - B overwrites (or removes) the entry again
> Result: on B we have inconsistent state
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3633:
-----------------------------------
I don't store the traces for longer period, I could try to re-run the job and reproduce it again, if it is worth. I understand that you may have problems reproducing this (as for any race), but do you have any doubts about order of interleaving operations (and therefore you need the logs)?
> InvalidateL1Command during ST should not cancel writing the entry by ST
> -----------------------------------------------------------------------
>
> Key: ISPN-3633
> URL: https://issues.jboss.org/browse/ISPN-3633
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.3.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry.
> Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3767:
--------------------------------
Assignee: Adrian Nistor (was: Mircea Markus)
> MassIndexer breaks search feature with one node cluster
> -------------------------------------------------------
>
> Key: ISPN-3767
> URL: https://issues.jboss.org/browse/ISPN-3767
> Project: Infinispan
> Issue Type: Bug
> Reporter: Romain Pelisse
> Assignee: Adrian Nistor
> Priority: Minor
>
> Hi,
> Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query.
> I've modified one of the test suite of InfiniSpan to reproduce the issue:
> https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi...
> Once this branch is checked out, just run :
> $ cd ./query
> $ mvn clean -Dtest=org.infinispan.query.distributed.DistributedMassIndexingTest test
> Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN).
> [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load...
> If run within a single node cluster, the MassIndexer
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3599:
--------------------------------
Labels: 620 nbst (was: 620)
> CommitCommand with replayed PrepareCommand executes rollback and then commit
> ----------------------------------------------------------------------------
>
> Key: ISPN-3599
> URL: https://issues.jboss.org/browse/ISPN-3599
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer, Transactions
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620, nbst
> Fix For: 6.0.0.Final
>
>
> During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed.
> In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc.
> Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held.
> Anyway, it is not correct to execute both commit and rollback on the same transaction.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3600) ignorePreviousValue should not be set on non-origin nodes
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3600:
--------------------------------
Labels: 620 nbst (was: 620)
> ignorePreviousValue should not be set on non-origin nodes
> ---------------------------------------------------------
>
> Key: ISPN-3600
> URL: https://issues.jboss.org/browse/ISPN-3600
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer, Transactions
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620, nbst
> Fix For: 6.0.0.Final
>
>
> In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution.
> Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores 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
10 years, 5 months