October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2174) CommandAwareRpcDispatcher swallows thread interruptions

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2174?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2174: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > CommandAwareRpcDispatcher swallows thread interruptions > ------------------------------------------------------- > > Key: ISPN-2174 > URL: https://issues.jboss.org/browse/ISPN-2174 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 5.1.5.FINAL > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Labels: jdg, jdg6 > Fix For: 6.0.0.Final > > > When interruption happens in FutureCollator.getResponseList() method > see > https://github.com/infinispan/infinispan/blob/5.1.x/core/src/main/java/or... > it is ignored and later wrongly dealt with as TimeoutException > (The original exception is not even set as cause anywhere) > This disables possibility of interrupting some cache operations. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2478) PutMapCommand not correctly removing previous types from indexes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2478?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2478: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > PutMapCommand not correctly removing previous types from indexes > ---------------------------------------------------------------- > > Key: ISPN-2478 > URL: https://issues.jboss.org/browse/ISPN-2478 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 5.1.8.Final > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Labels: stable_embedded_query > Fix For: 6.0.0.Final > > > We need to perform certain cleanup operations - potentially - on the return types of commands such as put and remove. In case of a putAll command, we're ignoring this requirement. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2465) Rollback sent twice in certain situations

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2465?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2465: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Rollback sent twice in certain situations > ----------------------------------------- > > Key: ISPN-2465 > URL: https://issues.jboss.org/browse/ISPN-2465 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.8.Final, 5.2.0.Final > Reporter: Mircea Markus > Assignee: William Burns > Priority: Minor > Fix For: 6.0.0.Final > > > If a prepare files e.g. due to a lock timeout, the initiating node sends a RollbackCommand before giving control back to the TransactionManager. The transaction manager might decide to invoke a rollback as well on the Synchrnization or XAResouce object, causing the rollback to be multicasted twice. This is not critical as the second Rollback is practically ignored, but unnecessary. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2418) CLONE - Cache restart doesn't work properly

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2418?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2418: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > CLONE - Cache restart doesn't work properly > ------------------------------------------- > > Key: ISPN-2418 > URL: https://issues.jboss.org/browse/ISPN-2418 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.1.7.Final, 5.2.0.Alpha3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: jdg6 > Fix For: 6.0.0.Final > > > Copied from ISPN-2297: > {quote} > If a cache is stopped via {{Cache.stop()}} it will still be returned by {{DefaultCacheManager.getCache()}}. Cache {{start()}} and {{stop()}} are not synchronized in any way, so a {{start()}} call may return before the cache was properly started - just because another thread is in the process of starting it. > Also, the documentation of {{EmbeddedCacheManager.getCache()}} should say that it will start the cache only if it doesn't exist yet - if the cache is stopped it will return the cache as it was. Alternatively we could change the behaviour of {{getCache()}} to always start the cache. > {quote} -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2376) KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2376?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2376: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes > ---------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2376 > URL: https://issues.jboss.org/browse/ISPN-2376 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Beta1 > Reporter: Scott Marlow > Assignee: Dan Berindei > Priority: Minor > Fix For: 6.0.0.Final > > > I instrumented KeyAffinityServiceImpl and DefaultConsistentHash to show why KeyAffinityServiceImpl is looping forever when running the AS7 clustered tests with some recent changes that aren't committed yet. We are hoping to get through this failure so we can get clustered tests running again more completely on our continuous test server (lightning). > We have two nodes running in the AS cluster, node-0/web and node-1/web. > In my recent test run, I stopped the test after it was stuck for a while. Below is some of the instrumented logging output. > {quote} > KeyAffinityServiceImpl interestedInAddress() check, for address: node-1/web, filter.contains(address) returns false, filter contents [node-0/web] > . > . > . > KeyAffinityServiceImpl.getKeyForAddress() loop # 1455775 will loop again since result is null, queue [], address node-0/web > {quote} > We are using address "node-1/web" because that is passed into the DefaultConsistentHash constructor segmentOwners parameter (element zero). > Later, address=node-1/web is the primary owner of the consistent hash (hash=DefaultConsistentHash{numSegments=1, numOwners=2, members=[node-1/web, node-0/web], segmentOwners={0: 0 1}). > I'm still collecting information and want to get a little more. > Let me know if there is anything that you would like to see. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2359) Query should not reindex cache entries on preload or activation

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2359?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2359: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Query should not reindex cache entries on preload or activation > --------------------------------------------------------------- > > Key: ISPN-2359 > URL: https://issues.jboss.org/browse/ISPN-2359 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Labels: stable_embedded_query > Fix For: 6.0.0.Final > > > If a cache entry is returning to the Infinispan datacontainer after activation or preloading it should not be re-indexed. > Check also that passivation doesn't remove the entry from the index. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2610) Use Query but disable automatic indexing

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2610?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2610: -------------------------------- Fix Version/s: (was: 6.0.0.CR1) > Use Query but disable automatic indexing > ---------------------------------------- > > Key: ISPN-2610 > URL: https://issues.jboss.org/browse/ISPN-2610 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Priority: Critical > Labels: stable_embedded_query > Fix For: 6.0.0.Final > > > The option known in Hibernate Search as > "hibernate.search.default.indexing_strategy" value="manual" > is not applied by Infinispan Query. > Workaround: use the SKIP_INDEXING flag > {code} > org.infinispan.context.Flag.SKIP_INDEXING{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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2538) Endless loop in TreeMap.remove at shutdown of query-enabled cache

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2538?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2538: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Endless loop in TreeMap.remove at shutdown of query-enabled cache > ----------------------------------------------------------------- > > Key: ISPN-2538 > URL: https://issues.jboss.org/browse/ISPN-2538 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.Beta4 > Reporter: Marko Lukša > Assignee: William Burns > Fix For: 6.0.0.Final > > > {code} > "MSC service thread 1-6" prio=6 tid=0x000000000d5b9000 nid=0x10a0 runnable [0x000000000e45e000] > java.lang.Thread.State: RUNNABLE > at java.util.TreeMap.fixAfterDeletion(TreeMap.java:2215) > at java.util.TreeMap.deleteEntry(TreeMap.java:2173) > at java.util.TreeMap.remove(TreeMap.java:600) > at org.infinispan.query.impl.LifecycleManager.cacheStopped(LifecycleManager.java:181) > at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:227) > at org.infinispan.CacheImpl.stop(CacheImpl.java:540) > at org.infinispan.CacheImpl.stop(CacheImpl.java:535) > at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:348) > at org.jboss.as.capedwarf.services.CacheLifecycleService.stop(CacheLifecycleService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > {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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2575: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > KeyTransformer registration is required on all nodes of the cluster, in case of custom keys > ------------------------------------------------------------------------------------------- > > Key: ISPN-2575 > URL: https://issues.jboss.org/browse/ISPN-2575 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Priority: Minor > Fix For: 6.0.0.Final > > Attachments: ClusteredCacheTest.java > > > The case is the following: > I have a clustered cache on which I want to perform a search. I'm doing the following: > I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception: > java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer > When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager. > The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer() -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2510) PrepareCommands should fail on nodes where the cache is not running

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2510?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2510: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > PrepareCommands should fail on nodes where the cache is not running > ------------------------------------------------------------------- > > Key: ISPN-2510 > URL: https://issues.jboss.org/browse/ISPN-2510 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, RPC > Affects Versions: 5.2.0.Beta3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 6.0.0.Final > > > When the user stops a cache without stopping the cache manager on that node, subsequent PrepareCommands sent to that node will return a {{SuccessfulResponse}}. > If that node used to the primary owner of the command's modified key, the originator will proceed with the transaction as if it had acquired a lock on that key. It is thus possible for multiple transactions to think they have acquired the key lock at the same time. > On the other hand, in replicated caches is is quite possible that a cache is not running on all the cluster node and yet PrepareCommands are broadcasted to everyone in parallel. So the solution should not involve sending exceptions (which have huge stack traces), and the originator should be able to ignore failures responses from nodes that were not targeted in the first place. -- 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, 6 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 October 2013