[JBoss JIRA] (ISPN-6279) Refactor CacheLoader API to make it thread safe
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6279?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-6279:
-------------------------------------------
After thinking about it a little bit longer, I think it would be good to have a default implementation of {{process}} method (which as you mentioned could use {{WithinThreadExecutor}}). This method could call our new simplified method (without {{Executor}} argument etc).
This way less advanced users could use simplified API (and be less exposed to concurrency issues in their own code) whereas more advanced could implement {{process}} and do whatever they like.
[~william.burns] WDYT?
> Refactor CacheLoader API to make it thread safe
> -----------------------------------------------
>
> Key: ISPN-6279
> URL: https://issues.jboss.org/browse/ISPN-6279
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Sebastian Łaskawiec
> Priority: Minor
> Fix For: 9.0.0.Final
>
>
> h3. Introduction
> Currently {{CacheLoader}} thread safety can be easily compromised by broken implementations. We should provide a better implementation to make it more convenient and less error prone.
> h3. Problem statement
> CacheLoader API looks like this:
> {code}
> public interface AdvancedCacheLoader<K, V> extends CacheLoader<K, V> {
> ...
> void process(KeyFilter<? super K> filter, CacheLoaderTask<K, V> task, Executor executor, boolean fetchValue, boolean fetchMetadata);
> ...
> }
> {code}
> The CacheLoader implementation controls {{CacheLoaderTask}} as well as the number of threads used for processing (specified by {{Executor}}). If one wants to collect all keys (similarly to [AdvancedCacheLoader|https://github.com/infinispan/infinispan/blob/master/...]) it is very easy to hit concurrently issues while adding them to the set (See previous JIRAs: ISPN-3938 and ISPN-6276).
> h3. Solution
> The solution should take away currently control (Executor) and keyset (the simplest idea is to add it to {{CacheLoaderTask}}) from from the implementation. One of the ideas is to create a Lambda expression for pulling records from Cache Store. Note that similar changes will need to be performed to {{CacheWriter}} (to make it similar).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6298) Network partition detection not working in mgmt console
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-6298?page=com.atlassian.jira.plugin.... ]
Jiří Holuša updated ISPN-6298:
------------------------------
Description:
Page: Clusters -> select server group.
When I create a network partition and go to the page above, I still see the cluster status as "started". According to https://issues.jboss.org/browse/ISPN-5768 , there should be something as "Degraded"
I checked that the cluster is really partitioned. When I go to JConsole, I see in JGroups JChannel attributes, that the "view" is only partial. I also see in the server logs that servers correctly detected the split.
When I go to homepage (or the "Status event" tab), I see in the "Latest Grid Events:" that the split happened, hence the mgmt console is able to correctly detect it elsewhere.
Note that neither the status of a cache, which has configured partition handling to true, changes.
was:
Page: Clusters -> select server group.
When I create a network partition and go to the page above, I still see the cluster status as "started". According to https://issues.jboss.org/browse/ISPN-5768 , there should be something as "Degraded"
I checked that the cluster is really partitioned. When I go to JConsole, I see in JGroups JChannel attributes, that the "view" is only partial. I also see in the server logs that servers correctly detected the split.
When I go to homepage (or the "Status event" tab), I see in the "Latest Grid Events:" that the split happened, hence the mgmt console is able to correctly detect it elsewhere.
> Network partition detection not working in mgmt console
> -------------------------------------------------------
>
> Key: ISPN-6298
> URL: https://issues.jboss.org/browse/ISPN-6298
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.1.2.Final
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
>
> Page: Clusters -> select server group.
> When I create a network partition and go to the page above, I still see the cluster status as "started". According to https://issues.jboss.org/browse/ISPN-5768 , there should be something as "Degraded"
> I checked that the cluster is really partitioned. When I go to JConsole, I see in JGroups JChannel attributes, that the "view" is only partial. I also see in the server logs that servers correctly detected the split.
> When I go to homepage (or the "Status event" tab), I see in the "Latest Grid Events:" that the split happened, hence the mgmt console is able to correctly detect it elsewhere.
> Note that neither the status of a cache, which has configured partition handling to true, changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6298) Network partition detection not working in mgmt console
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-6298:
---------------------------------
Summary: Network partition detection not working in mgmt console
Key: ISPN-6298
URL: https://issues.jboss.org/browse/ISPN-6298
Project: Infinispan
Issue Type: Bug
Components: Console
Affects Versions: 8.1.2.Final
Reporter: Jiří Holuša
Assignee: Vladimir Blagojevic
Page: Clusters -> select server group.
When I create a network partition and go to the page above, I still see the cluster status as "started". According to https://issues.jboss.org/browse/ISPN-5768 , there should be something as "Degraded"
I checked that the cluster is really partitioned. When I go to JConsole, I see in JGroups JChannel attributes, that the "view" is only partial. I also see in the server logs that servers correctly detected the split.
When I go to homepage (or the "Status event" tab), I see in the "Latest Grid Events:" that the split happened, hence the mgmt console is able to correctly detect it elsewhere.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months