December 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3842) Inconsistent L1 in non-tx distributed cache in certain circumstances

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3842?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3842: ------------------------------------- The trace levels you have may be sufficient. If you could attach the entire trace log when this happens I may be able to see something. I am especially interested in what the other threads are doing at the same time. Thanks. > Inconsistent L1 in non-tx distributed cache in certain circumstances > -------------------------------------------------------------------- > > Key: ISPN-3842 > URL: https://issues.jboss.org/browse/ISPN-3842 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Mikolaj Gierulski > Assignee: William Burns > > In my poc environment there are two nodes in dist non-tx sync cluster with L1 enabled and numOwners=1. > Node A, in a loop, reads one key (K), which is stored on node B (in test case it performs about 1 000 000 reads per second). > From time to time K is updated on node B. This causes an L1 invalidation message sent to A, and K is fetched from B upon next read attempt. > But whenever I run my test, I come to a situation, where updates of K no longer invalidate it on A, and A sees old value of K. > When this happens, I can see in logs of node A: > {noformat} > 18:21:33.296 [remote-thread-0] TRACE o.i.i.d.L1NonTxInterceptor - L1 invalidation found a pending update for key K - need to block until finished > 18:21:33.296 [remote-thread-0] TRACE o.i.i.d.L1NonTxInterceptor - Pending L1 update completed successfully: true - L1 invalidation can occur for key K > 18:21:33.296 [remote-thread-0] TRACE o.i.c.write.InvalidateL1Command - Preparing to invalidate keys [K] > 18:21:33.296 [remote-thread-0] TRACE o.i.c.write.InvalidateL1Command - Invalidating key K. > 18:21:33.296 [remote-thread-0] TRACE o.i.commands.write.RemoveCommand - Nothing to remove since the entry is null or we have a null entry > {noformat} > While logs of node B show: > {noformat} > 18:21:33.200 [OOB-1,AGST-2012000591-33853] TRACE o.i.distribution.L1ManagerImpl - Registering requestor AGST-2012000591-25400 for key 'K' > 18:21:33.266 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - Invalidating keys [K] on nodes [AGST-2012000591-25400]. Use multicast? false > 18:21:33.269 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Allowing entry to commit as local node is owner > 18:21:33.269 [OOB-2,AGST-2012000591-33853] TRACE o.i.distribution.L1ManagerImpl - Registering requestor AGST-2012000591-25400 for key 'K' > 18:21:33.269 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Sending additional invalidation for requestors if necessary. > 18:21:33.269 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - Invalidating keys [K] on nodes [AGST-2012000591-25400]. Use multicast? false > 18:21:33.270 [remote-thread-1] INFO p.c.a.ispn.WriteTask - Update task runtime millis 3 > 18:21:33.271 [OOB-1,AGST-2012000591-33853] TRACE o.i.distribution.L1ManagerImpl - Registering requestor AGST-2012000591-25400 for key 'K' > 18:21:33.293 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - Invalidating keys [K] on nodes [AGST-2012000591-25400]. Use multicast? false > 18:21:33.295 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Allowing entry to commit as local node is owner > 18:21:33.295 [OOB-2,AGST-2012000591-33853] TRACE o.i.distribution.L1ManagerImpl - Registering requestor AGST-2012000591-25400 for key 'K' > 18:21:33.295 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Sending additional invalidation for requestors if necessary. > 18:21:33.295 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - Invalidating keys [K] on nodes [AGST-2012000591-25400]. Use multicast? false > 18:21:33.295 [remote-thread-1] INFO p.c.a.ispn.WriteTask - Update task runtime millis 2 > 18:21:33.476 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - No L1 caches to invalidate for keys [K] > 18:21:33.476 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Allowing entry to commit as local node is owner > 18:21:33.476 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Sending additional invalidation for requestors if necessary. > 18:21:33.476 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - No L1 caches to invalidate for keys [K] > {noformat} > So it seems, that after this: > bq. 'L1 invalidation found a pending update for key K - need to block until finished' > B no longer knows A holds K in L1, and no longer sends invalidation commands after updates. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3844) Cluster Registry cache does not need to provide return value for put and remove

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3844?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3844: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2286 > Cluster Registry cache does not need to provide return value for put and remove > ------------------------------------------------------------------------------- > > Key: ISPN-3844 > URL: https://issues.jboss.org/browse/ISPN-3844 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 6.1.0.Final > > > This internal registry needs to be efficient, and the return types of put and remove operations are redundant for our purposes: I'm removing them. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3844) Cluster Registry cache does not need to provide return value for put and remove

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3844?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3844: ---------------------------------- Labels: 620 (was: ) > Cluster Registry cache does not need to provide return value for put and remove > ------------------------------------------------------------------------------- > > Key: ISPN-3844 > URL: https://issues.jboss.org/browse/ISPN-3844 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Labels: 620 > Fix For: 6.1.0.Final > > > This internal registry needs to be efficient, and the return types of put and remove operations are redundant for our purposes: I'm removing them. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3844) Cluster Registry cache does not need to provide return value for put and remove

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-3844: ------------------------------------- Summary: Cluster Registry cache does not need to provide return value for put and remove Key: ISPN-3844 URL: https://issues.jboss.org/browse/ISPN-3844 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 6.1.0.Final This internal registry needs to be efficient, and the return types of put and remove operations are redundant for our purposes: I'm removing them. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3841) L1NonTxInterceptor - Invalid format of log.tracef message

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3841?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3841: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 6.1.0.Final Resolution: Done Integrated in master. Thanks! > L1NonTxInterceptor - Invalid format of log.tracef message > --------------------------------------------------------- > > Key: ISPN-3841 > URL: https://issues.jboss.org/browse/ISPN-3841 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Mikolaj Gierulski > Assignee: Sanne Grinovero > Priority: Minor > Labels: 620 > Fix For: 6.1.0.Final > > > org.infinispan.interceptors.distribution.L1NonTxInterceptor.invalidateL1(InvocationContext, DataWriteCommand, boolean) invokes log.tracef with invalid message format - it contains '%', but should be '%s': > log.tracef("Not invalidating key '%' as local node(%s) is not owner", command.getKey(), rpcManager.getAddress()); -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3666) Fix CI failures regarding L1 issues

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3666?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3666: -------------------------------- Description: There are some L1 failures that occur intermittently as seen here -http://ci.infinispan.org/viewLog.html?buildId=3905&buildTypeId=bt9- -http://ci.infinispan.org/viewLog.html?buildId=3921&tab=buildResultsDiv&buildTypeId=bt9- http://ci.infinispan.org/viewLog.html?buildId=4932&buildTypeId=bt9 Looking into them they appear to be test failures only and not related to core code. was: There are some L1 failures that occur intermittently as seen here http://ci.infinispan.org/viewLog.html?buildId=3905&buildTypeId=bt9 http://ci.infinispan.org/viewLog.html?buildId=3921&tab=buildResultsDiv&bu... Looking into them they appear to be test failures only and not related to core code. > Fix CI failures regarding L1 issues > ----------------------------------- > > Key: ISPN-3666 > URL: https://issues.jboss.org/browse/ISPN-3666 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > > There are some L1 failures that occur intermittently as seen here > -http://ci.infinispan.org/viewLog.html?buildId=3905&buildTypeId=bt9- > -http://ci.infinispan.org/viewLog.html?buildId=3921&tab=buildResultsDiv&buildTypeId=bt9- > http://ci.infinispan.org/viewLog.html?buildId=4932&buildTypeId=bt9 > Looking into them they appear to be test failures only and not related to core 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3666) Fix CI failures regarding L1 issues

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3666?page=com.atlassian.jira.plugin.... ] Work on ISPN-3666 started by William Burns. > Fix CI failures regarding L1 issues > ----------------------------------- > > Key: ISPN-3666 > URL: https://issues.jboss.org/browse/ISPN-3666 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > > There are some L1 failures that occur intermittently as seen here > -http://ci.infinispan.org/viewLog.html?buildId=3905&buildTypeId=bt9- > -http://ci.infinispan.org/viewLog.html?buildId=3921&tab=buildResultsDiv&buildTypeId=bt9- > http://ci.infinispan.org/viewLog.html?buildId=4932&buildTypeId=bt9 > Looking into them they appear to be test failures only and not related to core 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3666) Fix CI failures regarding L1 issues

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3666?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3666: -------------------------------- Affects Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Fix CI failures regarding L1 issues > ----------------------------------- > > Key: ISPN-3666 > URL: https://issues.jboss.org/browse/ISPN-3666 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > > There are some L1 failures that occur intermittently as seen here > -http://ci.infinispan.org/viewLog.html?buildId=3905&buildTypeId=bt9- > -http://ci.infinispan.org/viewLog.html?buildId=3921&tab=buildResultsDiv&buildTypeId=bt9- > http://ci.infinispan.org/viewLog.html?buildId=4932&buildTypeId=bt9 > Looking into them they appear to be test failures only and not related to core 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3762) Test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fail on all environments

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3762?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3762: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2298 [~galder.zamarreno], I hope you don't mind :) > Test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fail on all environments > ----------------------------------------------------------------------------------------------------- > > Key: ISPN-3762 > URL: https://issues.jboss.org/browse/ISPN-3762 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 6.0.0.Final > Reporter: Jiří Holuša > Assignee: Galder Zamarreño > Attachments: log.txt > > > The test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fails every time on all environments. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3296) Total Order: timeout exceptions are not throw correctly

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3296?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3296: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2297 > Total Order: timeout exceptions are not throw correctly > ------------------------------------------------------- > > Key: ISPN-3296 > URL: https://issues.jboss.org/browse/ISPN-3296 > Project: Infinispan > Issue Type: Bug > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 6.1.0.Final > > > Issues found in Cloud-TM. Check if they happen here and create a JIRA for each of them > * IgnoreExtraResponseFilter is not needed anymore. > * missing argument log message > * TimeoutException, when happens, it is ignored and the transaction is processed normally > * TimeoutException can block the total order chain (all system is blocked!) > * port the testTimeoutCleanup from cloudtm to master -- 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, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2013