[JBoss JIRA] (ISPN-3882) Recovery documentation is incorrect
by Donald Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-3882?page=com.atlassian.jira.plugin.... ]
Donald Naro closed ISPN-3882.
-----------------------------
Resolution: Out of Date
> Recovery documentation is incorrect
> -----------------------------------
>
> Key: ISPN-3882
> URL: https://issues.jboss.org/browse/ISPN-3882
> Project: Infinispan
> Issue Type: Feature Request
> Components: Documentation-Core
> Reporter: Mircea Markus
> Priority: Major
>
> <snip>
> 3.5. Cache Loaders and transactional caches
> When a cache is transactional and a cache loader is present, the cache loader won’t be enlisted in the transaction in which the cache is part. That means that it is possible to have inconsistencies at cache loader level: the transaction to succeed applying the in-memory state but (partially) fail applying the changes to the store. Manual recovery would not work with caches stores.
> </snip>
> The manual recovery should work with cache stores as well. A test - if missing - needs to be added to confirm this.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 3 months
[JBoss JIRA] (ISPN-2902) document exception handling in Infinispan
by Donald Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-2902?page=com.atlassian.jira.plugin.... ]
Donald Naro closed ISPN-2902.
-----------------------------
Resolution: Out of Date
> document exception handling in Infinispan
> -----------------------------------------
>
> Key: ISPN-2902
> URL: https://issues.jboss.org/browse/ISPN-2902
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 5.2.3.Final
> Reporter: Mircea Markus
> Priority: Major
>
> Map/ConcurrentMap operations, as overridden by Infinispan, might throw various runtime exception to the user. These exceptions should be:
> - documented (API)
> - the user should be informed about what happens in the case of any such exceptions being thrown (e.g. the operation hasn't succeed an all nodes, the cache might be inconsistent, etc). This again should be added in the javadoc
> (ISPN-629 did part of the job for TimeoutException)
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 3 months
[JBoss JIRA] (ISPN-820) Resolve {@link} links in configuration reference
by Donald Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-820?page=com.atlassian.jira.plugin.s... ]
Donald Naro closed ISPN-820.
----------------------------
Resolution: Out of Date
> Resolve {@link} links in configuration reference
> -------------------------------------------------
>
> Key: ISPN-820
> URL: https://issues.jboss.org/browse/ISPN-820
> Project: Infinispan
> Issue Type: Feature Request
> Components: Documentation-Core
> Reporter: Galder Zamarreño
> Priority: Major
>
> Currently configuration reference documentation does not resolve {@link} links.
> It'd be nice if it'd point to the javadoc of the corresponding class if available!
> Examples:
> - Fully qualified class name of a class that looks up a reference to a {@link javax.transaction.TransactionManager}. The default provided is capable of locating the default TransactionManager in most popular Java EE systems, using a JNDI lookup. (Javadoc)
> - Fully qualified name of the class that the configured {@link org.infinispan.marshall.Externalizer} can marshall/unmarshall. Establishing the link between type marshalled and {@link org.infinispan.marshall.Externalizer} implementations enables users to provide their own marshalling mechanisms even for classes which they cannot modify or extend. (Javadoc)
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 3 months
[JBoss JIRA] (ISPN-2156) Benchmark and blog about a fast method of loading data into Infinispan
by Donald Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-2156?page=com.atlassian.jira.plugin.... ]
Donald Naro closed ISPN-2156.
-----------------------------
Resolution: Out of Date
> Benchmark and blog about a fast method of loading data into Infinispan
> ------------------------------------------------------------------------
>
> Key: ISPN-2156
> URL: https://issues.jboss.org/browse/ISPN-2156
> Project: Infinispan
> Issue Type: Task
> Components: Core, Documentation-Core
> Reporter: Mircea Markus
> Priority: Major
> Labels: docs
>
> To summarise:
> When using distributed caches, when we need to batch-load a set of data into the cluster inserting batches of keys that map to the same node should significantly increase the performance.
> Why?
> during the prepare phase each node receives the
> complete list of modifications in that transaction and not only the
> modification pertaining to it.
> E.g. say we have the following key->node mapping:
> {code}
> k1 -> A
> k2 -> B
> k3 -> C
> {code}
> Where k1, k2 and k3 are keys; A, B and C are nodes.
> If Tx1 writes (k1,k2,k3) then during the prepare A,B and C will receive
> the the same package containing all the modification - namely (k1,
> k2,k3). There are several reasons for doing this (apparently)
> unoptimized approach: serialize the prepare only once, better handling
> of recovery information.
> Now if you group transactions/batches base on key distribution the amount of redundant traffic is significantly reduced - and that translates in better performance especially when the datasets
> you're inserting is quite high.
> This JIRA is basically about benchmarking and blogging about this approach.
> A entry in the FAQ would be helpful as well.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 3 months