[JBoss JIRA] (ISPN-5129) Add a clustered transactional cache example for Infinispan Server
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5129?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5129:
----------------------------------
Fix Version/s: 7.1.0.CR1
(was: 7.1.0.Beta1)
> 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.CR1, 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, 3 months
[JBoss JIRA] (ISPN-5100) Failover without @ClientCacheFailover fails with NPE in Hot Rod client
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5100?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5100:
----------------------------------
Fix Version/s: 7.1.0.CR1
(was: 7.1.0.Beta1)
> Failover without @ClientCacheFailover fails with NPE in Hot Rod client
> ----------------------------------------------------------------------
>
> Key: ISPN-5100
> URL: https://issues.jboss.org/browse/ISPN-5100
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.1.0.CR1, 7.1.0.Final
>
>
> Hot Rod client raises a NullPointerException if a failover happens but the client listener has no @ClientCacheFailover callbacks defined.
> {code}
> java.lang.NullPointerException
> at org.infinispan.client.hotrod.event.ClientListenerNotifier.invokeFailoverEvent(ClientListenerNotifier.java:108)
> at org.infinispan.client.hotrod.event.ClientListenerNotifier.failoverClientListeners(ClientListenerNotifier.java:94)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.updateServers(TcpTransportFactory.java:330)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyAndHash(Codec20.java:390)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyIfPresent(Codec20.java:357)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:104)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:97)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5130) Conditional operation warning should only appear for clustered caches
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5130?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5130:
----------------------------------
Fix Version/s: 7.1.0.CR1
(was: 7.1.0.Beta1)
> Conditional operation warning should only appear for clustered caches
> ---------------------------------------------------------------------
>
> Key: ISPN-5130
> URL: https://issues.jboss.org/browse/ISPN-5130
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.1.0.Alpha1, 7.0.3.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.1.0.CR1, 7.1.0.Final, 7.0.4.Final
>
>
> Even for local caches, the following warning is shown when using conditional operations:
> {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}
> This warning should only appear in clustered situations where the real danger is present (see ISPN-2956)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5073) Improve "Number of Entries" stats
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5073?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5073:
----------------------------------
Fix Version/s: 7.1.0.CR1
(was: 7.1.0.Beta1)
> 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.CR1
>
>
> 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, 3 months
[JBoss JIRA] (ISPN-5046) PartitionHandling: split during commit can leave the cache inconsistent after merge
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5046?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5046:
----------------------------------
Fix Version/s: 7.1.0.CR1
(was: 7.1.0.Beta1)
> 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.CR1
>
>
> 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, 3 months
[JBoss JIRA] (ISPN-4359) Provide an annotation driven way of declaring protobuf metadata
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4359?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4359:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1172646|https://bugzilla.redhat.com/show_bug.cgi?id=1172646] from MODIFIED to ON_QA
> Provide an annotation driven way of declaring protobuf metadata
> ---------------------------------------------------------------
>
> Key: ISPN-4359
> URL: https://issues.jboss.org/browse/ISPN-4359
> Project: Infinispan
> Issue Type: Feature Request
> Components: Marshalling
> Affects Versions: 7.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: jdg
> Fix For: 7.1.0.Beta1
>
>
> The main goal of this is to simply marshalling of java objects to protobuf using the Protostream library.
> Instead of providing a Protostream MessageMarshaller implementation and a proto schema file it would be nice to have an alternative way of just adding minimal annotations to a Java class (and its fields) to assist on the fly generation (via reflection) of the proto schema. The Protostream library should also infer the marshaller so it would not require a manually implemented one. The annotation should require minimal info (tag number) and the rest should be inferred based on common sense defaults (protobuf type, java collection type, collection element type ...) but should be possible to override. The auto-generated schema should be available to users and they should be able then to use it as reference if they need it to implement domain model classes and marshallers for other languages.
> The user should still be able to specify a manually created schema (besides the annotated classes) and in that case the Protostream library should check the auto-inferred schema against the provided one and ensure they match.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5103:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1180693|https://bugzilla.redhat.com/show_bug.cgi?id=1180693] from NEW to MODIFIED
> Inefficient index updates cause high cost merges and increase overall latency
> -----------------------------------------------------------------------------
>
> Key: ISPN-5103
> URL: https://issues.jboss.org/browse/ISPN-5103
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.1.0.Beta1
>
>
> Currently every change to the index is done Lucene-wise combining two operations:
> * Delete by query, using a boolean query on the id plus the entity class
> * Add
>
> Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
> We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
> Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
> With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
> * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
> * Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
> {code}
> @Indexed(indexName=common)
> public class Country { ... }
> @Indexed(indexName=common)
> public class Currency { ... }
> cm.getCache("currencies").put(1, new Currency(...))
> cm.getCache("countries").put(1, new Country(...))
> {code}
> This would require a delete by query in order to persist both a Country and a Currency with id=1.
> It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
> Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-4359) Provide an annotation driven way of declaring protobuf metadata
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4359?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4359:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1172646|https://bugzilla.redhat.com/show_bug.cgi?id=1172646] from ASSIGNED to MODIFIED
> Provide an annotation driven way of declaring protobuf metadata
> ---------------------------------------------------------------
>
> Key: ISPN-4359
> URL: https://issues.jboss.org/browse/ISPN-4359
> Project: Infinispan
> Issue Type: Feature Request
> Components: Marshalling
> Affects Versions: 7.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: jdg
> Fix For: 7.1.0.Beta1
>
>
> The main goal of this is to simply marshalling of java objects to protobuf using the Protostream library.
> Instead of providing a Protostream MessageMarshaller implementation and a proto schema file it would be nice to have an alternative way of just adding minimal annotations to a Java class (and its fields) to assist on the fly generation (via reflection) of the proto schema. The Protostream library should also infer the marshaller so it would not require a manually implemented one. The annotation should require minimal info (tag number) and the rest should be inferred based on common sense defaults (protobuf type, java collection type, collection element type ...) but should be possible to override. The auto-generated schema should be available to users and they should be able then to use it as reference if they need it to implement domain model classes and marshallers for other languages.
> The user should still be able to specify a manually created schema (besides the annotated classes) and in that case the Protostream library should check the auto-inferred schema against the provided one and ensure they match.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months