March 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5300) CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5300?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5300: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1202409|https://bugzilla.redhat.com/show_bug.cgi?id=1202409] from POST to MODIFIED > CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5300 > URL: https://issues.jboss.org/browse/ISPN-5300 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Beta1, 7.2.0.Final, 7.1.2.Final > > > Current implementetion passes the value as old value to the wrapped filter. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5174) Transaction cannot be recommitted after ownership changes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5174?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5174: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1202341|https://bugzilla.redhat.com/show_bug.cgi?id=1202341] from POST to MODIFIED > Transaction cannot be recommitted after ownership changes > --------------------------------------------------------- > > Key: ISPN-5174 > URL: https://issues.jboss.org/browse/ISPN-5174 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.CR2 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > > Once transaction is completed, it cannot commit again. If it should commit more keys since it has become an owner of some new keys modified in this transaction, it just ignores the further commit. > There is a race with state transfer which can bring an old value (with StateResponseCommand sent before it is commited) but the value is not set by the ongoing transaction either. > This results with stale value stored on one node. > In my case, The problematic part is transaction <edg-perf01-62141>:15066 (consisting of 10 modifications) which got prepared and committed on edg-perf04 in topology 25. Before the originator finishes, topology changes and 04 requests ongoing transactions: > {code} > 11:06:11,369 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (transport-thread-17) Replication task sending StateRequestCommand{cache=testCache, origin=edg-perf04-35097, type=GET_TRANSACTIONS, topologyId=28, segments=[275, 1, 278, 9, 282, 286, 17, 259, 25, 267, 171, 169, 33, 306, 175, 173, 310, 172, 314, 41, 167, 165, 318, 187, 290, 49, 185, 191, 294, 189, 179, 298, 57, 177, 183, 302, 181, 343, 205, 201, 338, 203, 336, 351, 197, 349, 199, 347, 193, 345, 195, 326, 85, 87, 322, 93, 332, 95, 330, 89, 91, 103, 101, 99, 506, 97, 105, 357, 359, 353, 355, 361]} to single recipient edg-perf01-62141 with response mode GET_ALL > 11:06:11,495 DEBUG [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread-17) Applying 6 transactions for cache testCache transferred from node edg-perf01-62141 > {code} > However I don't see how these are applied, since PrepareCommand is not created again - from the code I see only that backup locks are added. Not sure if the transaction is registered at all, since it was already completed on this node (but at that time it did not own key_00000000000002EB). > After originator stores the entry, it sends one more CommitCommand with topology 28: > {code} > 11:06:11,619 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-2) Replication task sending CommitCommand {gtx=GlobalTransaction:<edg-perf01-62141>:15066:local, cacheName='testCache', topologyId=28} to addresses [edg-perf03-20530, edg-perf04-35097] with response mode GET_ALL > {code} > 04 receives several CommitCommands (both from originator and forwards), but all of them are ignored as the transaction is completed. > I don't see the logs where state transfer is assembled, but it's probably before the entry is stored on originator as the state transfer contains the old entry: > {code} > 11:06:13,449 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (remote-thread-91) Received chunk with keys [key_000000000000065B, key_00000000000006BE, key_FFFFFFFFFFFFE62F, key_0000000000001F42, key_000000000000027B, key_000000000000159D, key_00000000000002EB, key_00000000000002BB] for segment 343 of cache testCache from node edg-perf01-62141 > 11:06:13,454 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-91) Store ImmortalCacheEntry{key=key_00000000000002EB, value=[2 #7: 366, 544, 576, 804, 1061, 1181, 1290, ]} in container > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5174) Transaction cannot be recommitted after ownership changes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5174?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5174: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1185779|https://bugzilla.redhat.com/show_bug.cgi?id=1185779] from POST to MODIFIED > Transaction cannot be recommitted after ownership changes > --------------------------------------------------------- > > Key: ISPN-5174 > URL: https://issues.jboss.org/browse/ISPN-5174 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.CR2 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > > Once transaction is completed, it cannot commit again. If it should commit more keys since it has become an owner of some new keys modified in this transaction, it just ignores the further commit. > There is a race with state transfer which can bring an old value (with StateResponseCommand sent before it is commited) but the value is not set by the ongoing transaction either. > This results with stale value stored on one node. > In my case, The problematic part is transaction <edg-perf01-62141>:15066 (consisting of 10 modifications) which got prepared and committed on edg-perf04 in topology 25. Before the originator finishes, topology changes and 04 requests ongoing transactions: > {code} > 11:06:11,369 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (transport-thread-17) Replication task sending StateRequestCommand{cache=testCache, origin=edg-perf04-35097, type=GET_TRANSACTIONS, topologyId=28, segments=[275, 1, 278, 9, 282, 286, 17, 259, 25, 267, 171, 169, 33, 306, 175, 173, 310, 172, 314, 41, 167, 165, 318, 187, 290, 49, 185, 191, 294, 189, 179, 298, 57, 177, 183, 302, 181, 343, 205, 201, 338, 203, 336, 351, 197, 349, 199, 347, 193, 345, 195, 326, 85, 87, 322, 93, 332, 95, 330, 89, 91, 103, 101, 99, 506, 97, 105, 357, 359, 353, 355, 361]} to single recipient edg-perf01-62141 with response mode GET_ALL > 11:06:11,495 DEBUG [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread-17) Applying 6 transactions for cache testCache transferred from node edg-perf01-62141 > {code} > However I don't see how these are applied, since PrepareCommand is not created again - from the code I see only that backup locks are added. Not sure if the transaction is registered at all, since it was already completed on this node (but at that time it did not own key_00000000000002EB). > After originator stores the entry, it sends one more CommitCommand with topology 28: > {code} > 11:06:11,619 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-2) Replication task sending CommitCommand {gtx=GlobalTransaction:<edg-perf01-62141>:15066:local, cacheName='testCache', topologyId=28} to addresses [edg-perf03-20530, edg-perf04-35097] with response mode GET_ALL > {code} > 04 receives several CommitCommands (both from originator and forwards), but all of them are ignored as the transaction is completed. > I don't see the logs where state transfer is assembled, but it's probably before the entry is stored on originator as the state transfer contains the old entry: > {code} > 11:06:13,449 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (remote-thread-91) Received chunk with keys [key_000000000000065B, key_00000000000006BE, key_FFFFFFFFFFFFE62F, key_0000000000001F42, key_000000000000027B, key_000000000000159D, key_00000000000002EB, key_00000000000002BB] for segment 343 of cache testCache from node edg-perf01-62141 > 11:06:13,454 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-91) Store ImmortalCacheEntry{key=key_00000000000002EB, value=[2 #7: 366, 544, 576, 804, 1061, 1181, 1290, ]} in container > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-2183) Add the ability to fetch a set of keys at once (getAll)

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2183?page=com.atlassian.jira.plugin.... ] Work on ISPN-2183 started by William Burns. ------------------------------------------- > Add the ability to fetch a set of keys at once (getAll) > ------------------------------------------------------- > > Key: ISPN-2183 > URL: https://issues.jboss.org/browse/ISPN-2183 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Mircea Markus > Assignee: William Burns > Priority: Minor > Labels: 64QueryBlockers > > When a transaction knows in advance about the set of keys it needs to read, this cache.getAll(k1,k2,..kn) method can bring a some performance improvement: > 1. all the keys can be fetched from remote nodes in parallel > 2. keys that map to the same node can be grouped and fetched in the same RPC request > > Note that 1. can be be achieved even at this time by using Cache.getAsync(K) method - that's not as elegant though as it requires the user to write the code the code that waits on the Future objects that are returned. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-2183) Add the ability to fetch a set of keys at once (getAll)

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2183?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-2183: ----------------------------------- Assignee: William Burns > Add the ability to fetch a set of keys at once (getAll) > ------------------------------------------------------- > > Key: ISPN-2183 > URL: https://issues.jboss.org/browse/ISPN-2183 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Mircea Markus > Assignee: William Burns > Priority: Minor > Labels: 64QueryBlockers > > When a transaction knows in advance about the set of keys it needs to read, this cache.getAll(k1,k2,..kn) method can bring a some performance improvement: > 1. all the keys can be fetched from remote nodes in parallel > 2. keys that map to the same node can be grouped and fetched in the same RPC request > > Note that 1. can be be achieved even at this time by using Cache.getAsync(K) method - that's not as elegant though as it requires the user to write the code the code that waits on the Future objects that are returned. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4126) Memory is pre-allocated when enable eviction, and it may cause OOM even if there is no entry stored in cache.

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4126?page=com.atlassian.jira.plugin.... ] William Burns resolved ISPN-4126. --------------------------------- Resolution: Duplicate Issue This has been resolved in ISPN-3023. > Memory is pre-allocated when enable eviction, and it may cause OOM even if there is no entry stored in cache. > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-4126 > URL: https://issues.jboss.org/browse/ISPN-4126 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: tina tian > Assignee: William Burns > Priority: Critical > > I am considering to use Infinispan as a single cache in my project, and I met a memory problem when I enabled eviction. Memory is pre-allocated according to the maxEntries you set even if no entry is stored in that cache! > This is really a critical issue, since most time you are not sure how many entries you are going to store in the cache, you set a maxEntries to avoid OOME, but now, when you set maxEntries, memory will be pre-allocated no matter you are going to use it or not! > Ehcache used to have this kind of problem too, but they solved it DEV-9437. > Step to reproduce: > 1) Enable eviction on config > 2) Set maxEntries to a big number, like 100000 > 3) Create 100 caches using the default config > You will see OOM or big usage of memory. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3023) Re-implement BoundedConcurrentHashMap using CHMv8 designs

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3023?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3023: -------------------------------- Fix Version/s: 7.2.0.Beta2 > Re-implement BoundedConcurrentHashMap using CHMv8 designs > --------------------------------------------------------- > > Key: ISPN-3023 > URL: https://issues.jboss.org/browse/ISPN-3023 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Eviction > Affects Versions: 5.2.5.Final > Reporter: Manik Surtani > Assignee: William Burns > Priority: Minor > Labels: performance > Fix For: 7.2.0.Beta2, 7.2.0.Final, 5.2.11.Final > > > This is better than the current segment-based approach, in terms of memory footprint as well as performance under high concurrency. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4924) CacheEntryEvent isOriginLocal is not correct in many circumstances

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4924?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4924: -------------------------------- Fix Version/s: (was: 7.2.0.Beta2) > CacheEntryEvent isOriginLocal is not correct in many circumstances > ------------------------------------------------------------------ > > Key: ISPN-4924 > URL: https://issues.jboss.org/browse/ISPN-4924 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.CR2 > Reporter: William Burns > Assignee: William Burns > > Origin local flag was messed up when nontx DIST was rewritten to have the primary owner send updates to the backup nodes. This in turn affected REPL when it was changed to be implemented on top of DIST. I believe that tx is unaffected. Also new cluster listeners don't put the flag properly for DIST caches if the originator is not also the primary owner. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5127) LocalEntryRetrieverWithStoreAsBinaryTest.testFilterWithStoreAsBinaryPartialKeys random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5127?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5127: -------------------------------- Fix Version/s: (was: 7.2.0.Beta2) > LocalEntryRetrieverWithStoreAsBinaryTest.testFilterWithStoreAsBinaryPartialKeys random failures > ----------------------------------------------------------------------------------------------- > > Key: ISPN-5127 > URL: https://issues.jboss.org/browse/ISPN-5127 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.Alpha1, 7.0.3.Final > Reporter: Dan Berindei > Assignee: William Burns > Priority: Blocker > Labels: testsuite_stability > > Sometimes the filtered retriever doesn't return any entries: > {noformat} > 15:16:26,328 ERROR (testng-LocalEntryRetrieverWithStoreAsBinaryTest:) [UnitTestTestNGListener] Test testFilterWithStoreAsBinaryPartialKeys(org.infinispan.iteration.LocalEntryRetrieverWithStoreAsBinaryTest) failed.java.util.NoSuchElementException > at org.infinispan.iteration.impl.LocalEntryRetriever$Itr.next(LocalEntryRetriever.java:486) > at org.infinispan.iteration.impl.LocalEntryRetriever$Itr.next(LocalEntryRetriever.java:428) > at org.infinispan.iteration.LocalEntryRetrieverWithStoreAsBinaryTest.testFilterWithStoreAsBinaryPartialKeys(LocalEntryRetrieverWithStoreAsBinaryTest.java:93) > {noformat} > http://ci.infinispan.org/viewLog.html?buildId=14964 > The test should also use custom key/value types, as {{String}} keys/values are not marshalled when {{storeAsBinary}} is enabled (see {{MarshalledValue.isTypeExcluded()}}). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3023) Re-implement BoundedConcurrentHashMap using CHMv8 designs

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3023?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3023: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/3265, https://github.com/infinispan/infinispan/pull/3282 (was: https://github.com/infinispan/infinispan/pull/3265) > Re-implement BoundedConcurrentHashMap using CHMv8 designs > --------------------------------------------------------- > > Key: ISPN-3023 > URL: https://issues.jboss.org/browse/ISPN-3023 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Eviction > Affects Versions: 5.2.5.Final > Reporter: Manik Surtani > Assignee: William Burns > Priority: Minor > Labels: performance > Fix For: 7.2.0.Final, 5.2.11.Final > > > This is better than the current segment-based approach, in terms of memory footprint as well as performance under high concurrency. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2015