June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3235) Repeatable Read: should skip remote get if the key was previously read

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3235?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3235: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 5.3.0.Final) > Repeatable Read: should skip remote get if the key was previously read > ---------------------------------------------------------------------- > > Key: ISPN-3235 > URL: https://issues.jboss.org/browse/ISPN-3235 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: improvement, transaction > Fix For: 6.0.0.Alpha1 > > > When Repeatable Read, if the key was previously read or write, skip the remote fetch since the value return is discarded. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1540) Refactor distribution interceptor

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-1540?page=com.atlassian.jira.plugin.... ] Work on ISPN-1540 started by William Burns. > Refactor distribution interceptor > --------------------------------- > > Key: ISPN-1540 > URL: https://issues.jboss.org/browse/ISPN-1540 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Affects Versions: 5.1.0.BETA5 > Reporter: Mircea Markus > Assignee: William Burns > Fix For: 6.0.0.Final > > > DistributionInterceptor, as it looks now is unnecessary complex. Before adding more functionality on top of it (i.e. ISPN-1539) it should be refactored: > - extract L1 logic into a different interceptor > - this would require moving the StateTransferLock logic into another interceptor as well > - now that we have separation between tx and non-tx caches, we can extract the remaining logic into TransactionalDistributionInterceptor and NonTransactional... -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3214) When non owner updates non-tx dist cache the L1 is not updated

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3214?page=com.atlassian.jira.plugin.... ] William Burns resolved ISPN-3214. --------------------------------- Resolution: Rejected There is no safe way currently to update the non owner L1 on a write command. Need to rely on only gets. > When non owner updates non-tx dist cache the L1 is not updated > -------------------------------------------------------------- > > Key: ISPN-3214 > URL: https://issues.jboss.org/browse/ISPN-3214 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: William Burns > > Non tx DIST caches only add/update the L1 on a GetKeyValueCommand. The tx DIST cache updates the L1 cache on write operations as well. This should be consistent and is a minor performance issue. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3214) When non owner updates non-tx dist cache the L1 is not updated

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3214?page=com.atlassian.jira.plugin.... ] William Burns edited comment on ISPN-3214 at 6/25/13 12:59 PM: --------------------------------------------------------------- Actually this could be verified by the remote response if the command was successful. However there is still an inconsistency window between when the response is received and the L1 value is updated, since it could get an invalidation during that period as well. was (Author: william.burns): Actually this could be verified by the remote response. However there is still an inconsistency window between when the response is received and the L1 value is updated, since it could get an invalidation during that period as well. > When non owner updates non-tx dist cache the L1 is not updated > -------------------------------------------------------------- > > Key: ISPN-3214 > URL: https://issues.jboss.org/browse/ISPN-3214 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: William Burns > > Non tx DIST caches only add/update the L1 on a GetKeyValueCommand. The tx DIST cache updates the L1 cache on write operations as well. This should be consistent and is a minor performance issue. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3214) When non owner updates non-tx dist cache the L1 is not updated

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3214?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3214: ------------------------------------- Actually this could be verified by the remote response. However there is still an inconsistency window between when the response is received and the L1 value is updated, since it could get an invalidation during that period as well. > When non owner updates non-tx dist cache the L1 is not updated > -------------------------------------------------------------- > > Key: ISPN-3214 > URL: https://issues.jboss.org/browse/ISPN-3214 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: William Burns > > Non tx DIST caches only add/update the L1 on a GetKeyValueCommand. The tx DIST cache updates the L1 cache on write operations as well. This should be consistent and is a minor performance issue. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3214) When non owner updates non-tx dist cache the L1 is not updated

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3214?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3214: ------------------------------------- Thinking about adding locking more, there is no way to guarantee consistency and still get this to work. If we add locking, then there is a time duration between when the local key would be locked that the owning node could have received an update causing a L1 invalidation. In this case the local node would not run the invalidation since they key is locked and ignore it. If the local write is conditional and has now failed it will have the old L1 value from previous. Need to confirm this though. > When non owner updates non-tx dist cache the L1 is not updated > -------------------------------------------------------------- > > Key: ISPN-3214 > URL: https://issues.jboss.org/browse/ISPN-3214 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: William Burns > > Non tx DIST caches only add/update the L1 on a GetKeyValueCommand. The tx DIST cache updates the L1 cache on write operations as well. This should be consistent and is a minor performance issue. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3271) Connection leaks in JdbcBinaryCacheStore

by Nicolas Filotto (JIRA)

[ https://issues.jboss.org/browse/ISPN-3271?page=com.atlassian.jira.plugin.... ] Nicolas Filotto updated ISPN-3271: ---------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/1932 > Connection leaks in JdbcBinaryCacheStore > ---------------------------------------- > > Key: ISPN-3271 > URL: https://issues.jboss.org/browse/ISPN-3271 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.1.7.Final, 5.2.6.Final, 5.3.0.CR2 > Reporter: Nicolas Filotto > Assignee: Mircea Markus > > It seems that there is a connection leak in the method {{purgeInternal}} of the class {{JdbcBinaryCacheStore}}. Indeed in this method, there are situations where {{connectionFactory.releaseConnection(conn)}} is not called for example in case {{emptyBuckets.isEmpty()}} or {{expiredBuckets.isEmpty()}}. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3271) Connection leaks in JdbcBinaryCacheStore

by Nicolas Filotto (JIRA)

Nicolas Filotto created ISPN-3271: ------------------------------------- Summary: Connection leaks in JdbcBinaryCacheStore Key: ISPN-3271 URL: https://issues.jboss.org/browse/ISPN-3271 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.3.0.CR2, 5.2.6.Final, 5.1.7.Final Reporter: Nicolas Filotto Assignee: Mircea Markus It seems that there is a connection leak in the method {{purgeInternal}} of the class {{JdbcBinaryCacheStore}}. Indeed in this method, there are situations where {{connectionFactory.releaseConnection(conn)}} is not called for example in case {{emptyBuckets.isEmpty()}} or {{expiredBuckets.isEmpty()}}. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3103) StateRequestCommand requests serialization of type for which no Externalizer exists

by Jaromir Hamala (JIRA)

[ https://issues.jboss.org/browse/ISPN-3103?page=com.atlassian.jira.plugin.... ] Jaromir Hamala updated ISPN-3103: --------------------------------- Attachment: ISPN-3103_cow_externalized.patch COW externalizer > StateRequestCommand requests serialization of type for which no Externalizer exists > ----------------------------------------------------------------------------------- > > Key: ISPN-3103 > URL: https://issues.jboss.org/browse/ISPN-3103 > Project: Infinispan > Issue Type: Enhancement > Components: State transfer > Reporter: Sanne Grinovero > Assignee: Mircea Markus > Priority: Critical > Attachments: ISPN-3103_cow_externalized.patch > > > RPC org.infinispan.statetransfer.StateRequestCommand sends a parameter defined as type Set (field segments) which is implemented by a java.util.concurrent.CopyOnWriteArraySet. > This implementation is Serializable but seems to be quite slow as we don't have a custom Externalizer for 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3103) StateRequestCommand requests serialization of type for which no Externalizer exists

by Jaromir Hamala (JIRA)

[ https://issues.jboss.org/browse/ISPN-3103?page=com.atlassian.jira.plugin.... ] Jaromir Hamala commented on ISPN-3103: -------------------------------------- Hi, I've tried to use external serializer for COWAS (please see the attached patch), but it really didn't make any difference for ISPN-3102. > StateRequestCommand requests serialization of type for which no Externalizer exists > ----------------------------------------------------------------------------------- > > Key: ISPN-3103 > URL: https://issues.jboss.org/browse/ISPN-3103 > Project: Infinispan > Issue Type: Enhancement > Components: State transfer > Reporter: Sanne Grinovero > Assignee: Mircea Markus > Priority: Critical > Attachments: ISPN-3103_cow_externalized.patch > > > RPC org.infinispan.statetransfer.StateRequestCommand sends a parameter defined as type Set (field segments) which is implemented by a java.util.concurrent.CopyOnWriteArraySet. > This implementation is Serializable but seems to be quite slow as we don't have a custom Externalizer for 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, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013