[JBoss JIRA] (ISPN-2319) Add ability to take a site offline into x-site implementation
by Erik Salter (JIRA)
Erik Salter created ISPN-2319:
---------------------------------
Summary: Add ability to take a site offline into x-site implementation
Key: ISPN-2319
URL: https://issues.jboss.org/browse/ISPN-2319
Project: Infinispan
Issue Type: Enhancement
Components: Core API
Affects Versions: 5.2.0.Alpha3
Reporter: Erik Salter
Assignee: Mircea Markus
There should be a configuration option which determines after how many SITE-UNREACHABLE events (combined with a timeout), a site is declared as offline. (The count should be reset when there is a successful RPC to the remote site).
Once a site is taken offline, then no RPCs would be sent to it, until it is taken online again (manually, by a sysadmin), and the state transfer has completed.
--
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-2343) Exception thrown to user from xsite ROC when failurePolicy is set to WARN
by Mircea Markus (JIRA)
Mircea Markus created ISPN-2343:
-----------------------------------
Summary: Exception thrown to user from xsite ROC when failurePolicy is set to WARN
Key: ISPN-2343
URL: https://issues.jboss.org/browse/ISPN-2343
Project: Infinispan
Issue Type: Feature Request
Components: Cross-Site Replication
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.2.0.Beta1
This doesn't exhibit on 5.2.0.Alpha4 but only after upgrading to jgroups 3.2.0.Alpha2 and is caused by the fact that now, if another site is down, jgroups throws an org.jgroups.UnreachableException is in not caught.
--
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-2349) If the coordinator leaves while rebalancing is in progress, the new coordinator doesn't finish rebalancing
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2349:
----------------------------------
Summary: If the coordinator leaves while rebalancing is in progress, the new coordinator doesn't finish rebalancing
Key: ISPN-2349
URL: https://issues.jboss.org/browse/ISPN-2349
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Alpha4
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
When the coordinator dies or otherwise leaves the cluster, the new coordinator recovers the cluster state and handles any new changes.
However, if there was already a rebalance operation in progress, the new coordinator ignores the rebalance confirmations from the other members and doesn't install a balanced CH until there is another join/leave/etc. event for that cache.
Normally this doesn't appear in our tests because the state transfer is quick and so the old coordinator is able to finish the rebalance caused by its own leave before shutting down. I did see it however in Query's MultiNodeDistributedTest.
--
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] Created: (ISPN-1313) Execution timeout should not be linked to replication timeout
by Thomas Peuss (JIRA)
Execution timeout should not be linked to replication timeout
-------------------------------------------------------------
Key: ISPN-1313
URL: https://issues.jboss.org/browse/ISPN-1313
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache
Affects Versions: 5.0.0.CR8
Reporter: Thomas Peuss
Assignee: Manik Surtani
Currently the timeout of a distributed execution is linked to the settings for the replication timeout (we have set the timeout to <sync replTimeout="120000"/> as a workaround). For long running tasks this is really annoying because you get an error back from the framework but the distributed tasks runs till the end without a problem.
There should be an extra timeout for the execution of distributed tasks.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2287) Introduce DistributedTask abstraction enhancement for distributed executors
by Vladimir Blagojevic (JIRA)
Vladimir Blagojevic created ISPN-2287:
-----------------------------------------
Summary: Introduce DistributedTask abstraction enhancement for distributed executors
Key: ISPN-2287
URL: https://issues.jboss.org/browse/ISPN-2287
Project: Infinispan
Issue Type: Enhancement
Components: Distributed Execution and Map/Reduce
Affects Versions: 5.2.0.Alpha3
Reporter: Vladimir Blagojevic
Assignee: Vladimir Blagojevic
Fix For: 5.2.0.Beta1
As we have requirements to add timeout, pluggable fail over policies, topology aware target selection policies to distributed executors we have to create a new abstraction DistributedTask that users can submit to DistributedExecutorService. We will provide builder for DistributedTask, keep the existing four submit methods in DistributedExecutorService and add four new methods with DistributedTask abstraction in place of Callable. See below:
interface DistributedExecutorService {
… existing methods …
<T> List<Future<T>> submitEverywhere(DistributedTask<T> callable);
}
class DistributedTaskBuilder<T> {
DistributedTaskBuilder<T> callable(Callable<T> callable);
DistributedTaskBuilder<T> timeout(long t, TimeUnit tu);
DistributedTaskBuilder<T> executionPolicy(DistributedExecutionPolicy p);
DistributedTask<T> build();
}
--
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