[JBoss JIRA] (ISPN-1439) Async store needs redesigning to support injected executors
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1439?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-1439:
-----------------------------------
Fix Version/s: (was: 8.0.0.Final)
> Async store needs redesigning to support injected executors
> -----------------------------------------------------------
>
> Key: ISPN-1439
> URL: https://issues.jboss.org/browse/ISPN-1439
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Loaders and Stores
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
>
> The CoalescedAsyncStore design is pretty complex and is designed around AsyncStore being able to control the lifecycle of the async store coordinator and processor executors.
> A re-design of the async store is needed to enable central management of these executors, in such way that the NamedExecutorFactory can start with the right parameters (take in account that multiple caches could be configured with an async store), and the shutdown procedure can be correctly executed by the cache manager.
> The async store's coalesced logic makes this a fairly complex task, particularly since the introduction of Sanne's changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-1439) Async store needs redesigning to support injected executors
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1439?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-1439:
----------------------------------------
With ISPN-3514 in place, it paths the way to having executors centralised defined and reusable by multiple compoments, so it's easier know to have the async store thread pool configuration that way, however, the complexities are still there. Pushing this out.
> Async store needs redesigning to support injected executors
> -----------------------------------------------------------
>
> Key: ISPN-1439
> URL: https://issues.jboss.org/browse/ISPN-1439
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Loaders and Stores
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.Final
>
>
> The CoalescedAsyncStore design is pretty complex and is designed around AsyncStore being able to control the lifecycle of the async store coordinator and processor executors.
> A re-design of the async store is needed to enable central management of these executors, in such way that the NamedExecutorFactory can start with the right parameters (take in account that multiple caches could be configured with an async store), and the shutdown procedure can be correctly executed by the cache manager.
> The async store's coalesced logic makes this a fairly complex task, particularly since the introduction of Sanne's changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-1441) Better and more sensible executor configuration
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1441?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-1441:
----------------------------------------
...and to be able to decide what's the best default, *all* executor services used internally need to be configurable, which is not yet the case. This is what ISPN-1396 will give us.
> Better and more sensible executor configuration
> -----------------------------------------------
>
> Key: ISPN-1441
> URL: https://issues.jboss.org/browse/ISPN-1441
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: executors
>
> Dan and I had a chat about ISPN-1396 and we both agreed that a better configuration and management approach is needed for Infinispan's executors:
> - Firstly, out of the box for SE environments, Infinispan should have executors configured with newCachedThreadPool because they provide better queuing performance than a fixed thread pool.
> - Sure, in an managed env (i.e. AS), this won't fly, which is why all executors need to be injectable. This should be in place once ISPN-1396 is in place.
> - So, if we go for cached thread pools for SE environments, we don't need any of the properties of executors any more. Besides, these can be more confusing for the user (there is knowledged of at least one case where things went wrong due to bad config here). So, the configuration would be limited to injecting executors. If you need any specific executor settings, pass us the right executors. To aid these cases, we could have some executor builders available with some common executor configuration for managed envs (i.e. we could borrow settings from AS?)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-1439) Async store needs redesigning to support injected executors
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1439?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-1439:
-----------------------------------
Fix Version/s: 8.0.0.Final
> Async store needs redesigning to support injected executors
> -----------------------------------------------------------
>
> Key: ISPN-1439
> URL: https://issues.jboss.org/browse/ISPN-1439
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Loaders and Stores
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.Final
>
>
> The CoalescedAsyncStore design is pretty complex and is designed around AsyncStore being able to control the lifecycle of the async store coordinator and processor executors.
> A re-design of the async store is needed to enable central management of these executors, in such way that the NamedExecutorFactory can start with the right parameters (take in account that multiple caches could be configured with an async store), and the shutdown procedure can be correctly executed by the cache manager.
> The async store's coalesced logic makes this a fairly complex task, particularly since the introduction of Sanne's changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-1441) Better and more sensible executor configuration
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1441?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-1441:
----------------------------------------
ISPN-3514 brings in new XML and embedded configuration in the executor area, so part of this JIRA is completed there. What's left is deciding better default thread pool configuration out of the box for embedded. Maybe a cached thread pool for all? Maybe a fork/join pool?...etc.
> Better and more sensible executor configuration
> -----------------------------------------------
>
> Key: ISPN-1441
> URL: https://issues.jboss.org/browse/ISPN-1441
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: executors
>
> Dan and I had a chat about ISPN-1396 and we both agreed that a better configuration and management approach is needed for Infinispan's executors:
> - Firstly, out of the box for SE environments, Infinispan should have executors configured with newCachedThreadPool because they provide better queuing performance than a fixed thread pool.
> - Sure, in an managed env (i.e. AS), this won't fly, which is why all executors need to be injectable. This should be in place once ISPN-1396 is in place.
> - So, if we go for cached thread pools for SE environments, we don't need any of the properties of executors any more. Besides, these can be more confusing for the user (there is knowledged of at least one case where things went wrong due to bad config here). So, the configuration would be limited to injecting executors. If you need any specific executor settings, pass us the right executors. To aid these cases, we could have some executor builders available with some common executor configuration for managed envs (i.e. we could borrow settings from AS?)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-3948) Missing logic to add the store to the configuration for custom stores
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3948?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3948:
----------------------------------------
I've closed the PR but I'm happy to inspect changes to new Parser70 once the PR for ISPN-3514 has been integrated.
> Missing logic to add the store to the configuration for custom stores
> ---------------------------------------------------------------------
>
> Key: ISPN-3948
> URL: https://issues.jboss.org/browse/ISPN-3948
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Loaders and Stores
> Affects Versions: 6.0.0.Final
> Reporter: Kurt Lehrke
> Assignee: Dan Berindei
> Priority: Critical
>
> Looking at the Parser60 class, if you specify a custom store that isn't a singleFileStore or a clusterLoader, the store doesn't get added to the configuration. I found this when I specified my own CacheLoader and it wasn't instantiated like expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-3514) Revamp embedded Infinispan configuration
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3514?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3514:
----------------------------------------
The aim of this JIRA is to unify Infinispan configuration between embedded and server mode, particularly when it comes to XML parsing. The JIRA adopts the XML configuration of server mode and embedded ignores those elements that are not relevant.
> Revamp embedded Infinispan configuration
> -----------------------------------------
>
> Key: ISPN-3514
> URL: https://issues.jboss.org/browse/ISPN-3514
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration, Server
> Reporter: Mircea Markus
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Final
>
>
> Umbrella JIRA for all the configurations-related Infinispan enhancements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-4025) Cross-Site State Transfer: failure scenarios
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-4025:
---------------------------------
Summary: Cross-Site State Transfer: failure scenarios
Key: ISPN-4025
URL: https://issues.jboss.org/browse/ISPN-4025
Project: Infinispan
Issue Type: Sub-task
Components: Cross-Site Replication
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 7.0.0.Final
Needs to handle the following scenarios (at least):
* join/leave in the consumer site (i.e. site that receives the the state)
I think NBST will handle most of join scenario. However, the leave scenario needs to be handle carefully or we can loose some key chunks. (easy solution: resend all the chunk?)
* join/leave in the producer site (i.e. site that sends the state)
trick scenario. we have to be sure that all keys are really sent! (naive solution: restart the state transfer)
* state transfer coordinator dies
the coordinator node is the one that receives the acks when all members has finished sending the keys. Or we replicate its state or we restart the state transfer...
* site master dies in consumer site
No idea which keys was already applied or not. need to resend the chunks...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month