[JBoss JIRA] (ISPN-5073) Improve "Number of Entries" stats
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-5073?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-5073:
--------------------------------------
Fix Version/s: 7.1.0.Final
(was: 7.1.0.CR2)
> Improve "Number of Entries" stats
> ---------------------------------
>
> Key: ISPN-5073
> URL: https://issues.jboss.org/browse/ISPN-5073
> Project: Infinispan
> Issue Type: Task
> Components: Core, JMX, reporting and management
> Affects Versions: 7.1.0.Alpha1
> Reporter: Tristan Tarrant
> Assignee: Vladimir Blagojevic
> Fix For: 7.1.0.Final
>
>
> Currently the getNumberOfEntries in CacheMgmtInterceptor returns the size of the datacontainer which doesn't take into account expired entries and cache stores.
> To avoid compatibility issues, modify the description to reflect its behaviour and add proper statistics, possibly with different flag combinations (SKIP_REMOTE, SKIP_CACHE_LOAD)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5046) PartitionHandling: split during commit can leave the cache inconsistent after merge
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-5046?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-5046:
--------------------------------------
Fix Version/s: 7.1.0.Final
(was: 7.1.0.CR2)
> PartitionHandling: split during commit can leave the cache inconsistent after merge
> -----------------------------------------------------------------------------------
>
> Key: ISPN-5046
> URL: https://issues.jboss.org/browse/ISPN-5046
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.1.0.Final
>
>
> Say we have a cluster ABCD; a transaction T was started on A, with B as the primary owner and C the backup owner. B and C both acknowledge the prepare, and the network splits into AB and CD right before A sends the commit command. Eventually A suspects C and D, but the commit still succeeds on B before C and D are suspected. And SuspectExceptions are ignored for commit commands, so the user won't see any error.
> However, C will eventually suspect A and B. When the CD cache topology is installed, it will roll back transaction T. After the merge, both partitions are in degraded mode, so we assume that they both have the latest data and the key is never updated on C.
> From C's point of view, this is very similar to ISPN-3421. The fix should also be similar, we could delay the transaction rollback on C until we get a confirmation from B that T was not committed there. Since B is inaccessible, it will eventually get a SuspectException and the CD cache topology, at which point the cache is in degraded mode and it can wait for a merge. On merge, it should check the status of the transaction on B again, and either commit or rollback based on what B did.
> We also need to suspend the cleanup of completed transactions while the cache is in degraded mode, otherwise C might not find T on B after the merge.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-5021:
--------------------------------------
Fix Version/s: 7.1.0.Final
(was: 7.1.0.CR2)
> 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.Final
>
>
> 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, 2 months
[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-5019:
--------------------------------------
Fix Version/s: 7.1.0.Final
(was: 7.1.0.CR2)
> 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.Final
>
>
> 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, 2 months
[JBoss JIRA] (ISPN-5010) Improve remote listener performance
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-5010?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-5010:
--------------------------------------
Fix Version/s: (was: 7.1.0.CR2)
> 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.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, 2 months
[JBoss JIRA] (ISPN-5149) Nested field is reported as non-indexed
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-5149?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-5149:
--------------------------------------
Fix Version/s: 7.1.0.Final
(was: 7.1.0.CR2)
> Nested field is reported as non-indexed
> ---------------------------------------
>
> Key: ISPN-5149
> URL: https://issues.jboss.org/browse/ISPN-5149
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 7.1.0.Beta1
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.1.0.Final
>
>
> Steps to reproduce:
> 1. use the remote-query quickstart app (https://github.com/jboss-developer/jboss-jdg-quickstarts/tree/master/remo...) with an indexed cache config to add a Person and then a Memo object that has the Person as author.
> 2. try to query memos by author -> you get this exception
> {code}
> Jan 14, 2015 4:13:52 PM org.infinispan.client.hotrod.impl.protocol.Codec20 checkForErrorsInResponseStatus
> WARN: ISPN004005: Error received from the server: java.lang.IllegalArgumentException: Field author.name from type quickstart.Memo is not indexed
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[14] returned server error (status=0x85): java.lang.IllegalArgumentException: Field author.name from type quickstart.Memo is not indexed
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:321)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:111)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:97)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:57)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:24)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.executeQuery(RemoteQuery.java:72)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.list(RemoteQuery.java:62)
> at org.jboss.as.quickstarts.datagrid.hotrod.query.AddressBookManager.queryMemoByAuthor(AddressBookManager.java:285)
> at org.jboss.as.quickstarts.datagrid.hotrod.query.AddressBookManager.main(AddressBookManager.java:328)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> >
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5129) Add a clustered transactional cache example for Infinispan Server
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-5129?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-5129:
--------------------------------------
Fix Version/s: (was: 7.1.0.CR2)
> Add a clustered transactional cache example for Infinispan Server
> -----------------------------------------------------------------
>
> Key: ISPN-5129
> URL: https://issues.jboss.org/browse/ISPN-5129
> Project: Infinispan
> Issue Type: Task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.1.0.Final
>
>
> We should add a transactional cache example as a separate configuration in docs/examples folder.
> There's no such example at the moment, and this is really needed in order to avoid WARN messages when conditional versioned operations are used, e.g.
> {code}
> 08:38:08,920 WARN [org.infinispan.server.hotrod.Decoder2x$] (HotRodServerWorker-6-8) ISPN006010:
> Conditional operation 'ReplaceIfUnmodifiedRequest' should be used with transactional caches, otherwise data inconsistency issues could arise under failure situations
> {code}
> Also, this WARN message should only appear when the cache is clustered and there's > 1 node in the cluster, but currently it also appears in local caches, but this is a different issue...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months