January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4795) Warning message about forcing to return previous does not apply to Get operations

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4795?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4795: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Warning message about forcing to return previous does not apply to Get operations > --------------------------------------------------------------------------------- > > Key: ISPN-4795 > URL: https://issues.jboss.org/browse/ISPN-4795 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.CR1 > > > {code} > 'ISPN006010: Operation 'GetRequest' forced to return previous value should be used on transactional caches' in the log > {code} > That message should not appear. GetRequest does not force returning previous. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4772) APIDistTest random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4772?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4772: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > APIDistTest random failures > --------------------------- > > Key: ISPN-4772 > URL: https://issues.jboss.org/browse/ISPN-4772 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.1.0.CR1 > > > The lock acquisition timeout is too small, because the asynchronous TxCompletionNotificationCommand can easily be delayed by more than 100ms. > Failure in CI here: http://ci.infinispan.org/viewLog.html?buildId=12250&buildTypeId=bt8&tab=b... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5021: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Nodes that finish the rebalance later can see outdated values > ------------------------------------------------------------- > > Key: ISPN-5021 > URL: https://issues.jboss.org/browse/ISPN-5021 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 7.1.0.CR1 > > > Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...] > If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help. > I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: start a rebalance with read_ch=old, write_ch=old+new, when the new owners have all the data install read_ch=new, write_ch=old+new, and finally read_ch=new, write_ch=new. Old cache entries are removed during the 2nd topology update, and further writes should be ignored, in order for this to work. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5019: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.CR1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5010) Improve remote listener performance

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5010?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5010: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Improve remote listener performance > ----------------------------------- > > Key: ISPN-5010 > URL: https://issues.jboss.org/browse/ISPN-5010 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 7.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.CR1, 7.1.0.Final > > > We've run some performance tests and we've noticed remote listeners have a too negative effect on get/put/remove operations, particularly as number of listeners added by clients increase. This JIRA encompasses different pieces of work to improve this: > * Make server-side clustered listener async. By doing so, the operations are detached from the actual server-side listener part when the notification is sent to clients. Async listener executor is configured with 1 thread, so order is still maintained. > * Batching at the server-side clustered listener side. Instead of sending each event as it comes, apply time/size based batching to reduce number of system calls to flush sockets to clients. > * Further improvements might come from bundling listeners added by same client, but this is more complicated to achieve, since only those listeners that have similar characteristics can be bundled, e.g. have same filter/converter settings. Also, whether to use a single connection for all listeners or maintain separate ones still would need to be decided. (see ISPN-4491) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

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

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4924?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4924: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > 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 > Fix For: 7.1.0.CR1 > > > 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4919) Configuration templates

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4919: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Configuration templates > ----------------------- > > Key: ISPN-4919 > URL: https://issues.jboss.org/browse/ISPN-4919 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.1.0.CR1 > > > Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not. > We should introduce the concept of configuration inheritance, e.g.: > {code} > <local-cache name="eviction-cache"> > <eviction strategy="LIRS" maxEntries="10000"/> > </local-cache> > <local-cache name="mycache" template="eviction-cache" /> > {code} > Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.: > {code} > <local-cache name="eviction-cache" abstract="true"> > ... > </local-cache> > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4903) ServerFailureRetrySingleOwnerTest doesn't actually test client retry

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4903?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4903: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > ServerFailureRetrySingleOwnerTest doesn't actually test client retry > -------------------------------------------------------------------- > > Key: ISPN-4903 > URL: https://issues.jboss.org/browse/ISPN-4903 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Affects Versions: 7.0.0.CR2 > Reporter: Dan Berindei > Fix For: 7.1.0.CR1 > > Attachments: ServerFailureRetrySingleOwnerTest.java > > > With {{useSynchronization = true}} (the default, before ISPN-4166 is integrated), the {{SuspectException}} thrown by the listener is swallowed by the transaction manager and the client doesn't retry. The test doesn't pick that up because the exception is thrown _after_ the entry was updated in the data container (a regular SuspectException would be thrown before). > I changed the configuration to {{useSynchronization = false}}, but it didn't work because the {{SuspectException}} is wrapped in a {{CacheListenerException}}, so the client throws an exception instead of retrying. I also changed the test to use an interceptor instead of a listener, but then I got a {{ClassCastException}}: > {noformat} > Caused by: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:424) > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:429) > at org.infinispan.server.hotrod.Decoder2x$.customReadKey(Decoder2x.scala:285) > at org.infinispan.server.hotrod.HotRodDecoder.customDecodeKey(HotRodDecoder.scala:156) > at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeKey(AbstractProtocolDecoder.scala:176) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:71) ... 14 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4899) Update user guide regarding protobuf schema definition API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4899?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4899: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Update user guide regarding protobuf schema definition API > ---------------------------------------------------------- > > Key: ISPN-4899 > URL: https://issues.jboss.org/browse/ISPN-4899 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Affects Versions: 7.0.0.CR2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.CR1 > > > Describe the usage of __protobuf_metadata cache -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4895) Rolling upgrade source migrators should use the distributed iterator to collect keys

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4895?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4895: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Rolling upgrade source migrators should use the distributed iterator to collect keys > ------------------------------------------------------------------------------------ > > Key: ISPN-4895 > URL: https://issues.jboss.org/browse/ISPN-4895 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: William Burns > Fix For: 7.1.0.CR1 > > > currently the rolling upgrade migrators iterate all entries in the cache using org.infinispan.tasks.GlobalKeySetTask<K, V> and invoking cache.keySet(). This needs to be done more efficiently using the distributed iterators -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 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 January 2015