November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3531) LifecycleManager of query module keeps references to per cache manager resources (jmx related)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3531?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3531: ------------------------------------- Bumping the priority as this is a bug after all. > LifecycleManager of query module keeps references to per cache manager resources (jmx related) > ---------------------------------------------------------------------------------------------- > > Key: ISPN-3531 > URL: https://issues.jboss.org/browse/ISPN-3531 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 620 > > The resources in question are gathered when a cache manager is started and are used again when it is stopped. This does not work well if there are multiple cache managers that have different jmx domains. > Cache stop event also does not seem to be processed correctly. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3518) 1PC can cause a window of inconsistency with L1 invalidation

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3518?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3518: -------------------------------- Priority: Critical (was: Major) > 1PC can cause a window of inconsistency with L1 invalidation > ------------------------------------------------------------ > > Key: ISPN-3518 > URL: https://issues.jboss.org/browse/ISPN-3518 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: William Burns > Assignee: William Burns > Priority: Critical > Labels: 620 > > The L1TxInterceptor currently doesn't block on L1 invalidations during a 1PC. This can cause an inconsistent view of data across non owner nodes. > Example: > {quote} > Node A owns k with value of v1 > Node B has k in L1 with value of v1 > tx1 started > Node A put k -> v2 > Node A sends invalidation > Node A commits > tx1 completed > tx2 started > Node B get k returns v1 from L1 > tx2 completed > Node B gets invalidation for k > tx3 started > Node B get k remotely retrieves v2 from Node A > tx3 completed > {quote} > We need to make sure that all L1 invalidations in Tx mode are completed before completing the 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3518) 1PC can cause a window of inconsistency with L1 invalidation

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3518?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3518: -------------------------------- Fix Version/s: 6.0.0.Final > 1PC can cause a window of inconsistency with L1 invalidation > ------------------------------------------------------------ > > Key: ISPN-3518 > URL: https://issues.jboss.org/browse/ISPN-3518 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: William Burns > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > The L1TxInterceptor currently doesn't block on L1 invalidations during a 1PC. This can cause an inconsistent view of data across non owner nodes. > Example: > {quote} > Node A owns k with value of v1 > Node B has k in L1 with value of v1 > tx1 started > Node A put k -> v2 > Node A sends invalidation > Node A commits > tx1 completed > tx2 started > Node B get k returns v1 from L1 > tx2 completed > Node B gets invalidation for k > tx3 started > Node B get k remotely retrieves v2 from Node A > tx3 completed > {quote} > We need to make sure that all L1 invalidations in Tx mode are completed before completing the 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3531) LifecycleManager of query module keeps references to per cache manager resources (jmx related)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3531?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3531: -------------------------------- Priority: Major (was: Minor) > LifecycleManager of query module keeps references to per cache manager resources (jmx related) > ---------------------------------------------------------------------------------------------- > > Key: ISPN-3531 > URL: https://issues.jboss.org/browse/ISPN-3531 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 620 > > The resources in question are gathered when a cache manager is started and are used again when it is stopped. This does not work well if there are multiple cache managers that have different jmx domains. > Cache stop event also does not seem to be processed correctly. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3556) When LockControlCommand fails on an owner, the rollback command is not sent

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3556: -------------------------------- Fix Version/s: 6.0.0.Final > When LockControlCommand fails on an owner, the rollback command is not sent > --------------------------------------------------------------------------- > > Key: ISPN-3556 > URL: https://issues.jboss.org/browse/ISPN-3556 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > If a transaction starts with a {{lock()}} operation and the lock fails on one of the owners (e.g. because of a {{SuspectException}}), the rollback command should still be sent to all the live owners. > However, because a locked key is only registered in the {{affectedKeys}} collection after a successful lock operation (in {{PessimisticLockingInterceptor.acquireRemoteIfNeeded()}}, the rollback command is not sent to any owners. > This is in a pessimistic cache. However, looking at the {{OptimisticLockingInterceptor.acquireAllLocks()}} code I think I see a similar problem: it's possible that a key is locked, but the write skew check fails and the key is not added to the {{affectedKeys}} collection. We should always register the key first and attempt to lock it after. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3608) HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3608?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3608: -------------------------------- Priority: Critical (was: Major) > HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-3608 > URL: https://issues.jboss.org/browse/ISPN-3608 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > HotRod client's RemoteCacheManager still has a constructor that internally reads hotrod-client.properties (public RemoteCacheManager(boolean start)) and this constructor is not deprecated. > This call leads to parsing "server_list" property by ConfigurationBuilder.addServers(String servers)). > However, IPv6 addresses usually contain colons and so this parsing fails (enable to differentiate the host and port as these are separated by colon too) -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3612) JON server plugin, unreachable NaN cache statistics values, even after Get Live Value

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3612?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3612: -------------------------------- Priority: Critical (was: Major) > JON server plugin, unreachable NaN cache statistics values, even after Get Live Value > ------------------------------------------------------------------------------------- > > Key: ISPN-3612 > URL: https://issues.jboss.org/browse/ISPN-3612 > Project: Infinispan > Issue Type: Bug > Reporter: Mircea Markus > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.CR2 > > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3608) HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3608?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3608: -------------------------------- Assignee: Galder Zamarreño (was: Mircea Markus) > HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-3608 > URL: https://issues.jboss.org/browse/ISPN-3608 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Labels: 620 > Fix For: 6.0.0.Final > > > HotRod client's RemoteCacheManager still has a constructor that internally reads hotrod-client.properties (public RemoteCacheManager(boolean start)) and this constructor is not deprecated. > This call leads to parsing "server_list" property by ConfigurationBuilder.addServers(String servers)). > However, IPv6 addresses usually contain colons and so this parsing fails (enable to differentiate the host and port as these are separated by colon too) -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3659) Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3659?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3659: -------------------------------- Assignee: Pedro Ruivo (was: Dan Berindei) > Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches > ------------------------------------------------------------------------------------- > > Key: ISPN-3659 > URL: https://issues.jboss.org/browse/ISPN-3659 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.3.0.Final, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Labels: 620 > Fix For: 6.1.0.Final > > > The fix for ISPN-2372 was incomplete. We now clear the references from the thread-local marshallers to the cache itself, so it can be garbage-collected, but we don't clear the marshallers or their instance caches. If the cache values' object graph is very large, the cached marshallers will use up a lot of memory that could be garbage-collected (assuming the cache was indeed restarted and only one cache instance is running now). -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3659) Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3659?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3659: -------------------------------- Priority: Critical (was: Major) > Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches > ------------------------------------------------------------------------------------- > > Key: ISPN-3659 > URL: https://issues.jboss.org/browse/ISPN-3659 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.3.0.Final, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.1.0.Final > > > The fix for ISPN-2372 was incomplete. We now clear the references from the thread-local marshallers to the cache itself, so it can be garbage-collected, but we don't clear the marshallers or their instance caches. If the cache values' object graph is very large, the cached marshallers will use up a lot of memory that could be garbage-collected (assuming the cache was indeed restarted and only one cache instance is running now). -- 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, 5 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 November 2013