[JBoss JIRA] (ISPN-7119) Change cluster listener to use JGroups non OOB thread
by William Burns (JIRA)
William Burns created ISPN-7119:
-----------------------------------
Summary: Change cluster listener to use JGroups non OOB thread
Key: ISPN-7119
URL: https://issues.jboss.org/browse/ISPN-7119
Project: Infinispan
Issue Type: Feature Request
Reporter: William Burns
Assignee: William Burns
Cluster listeners could use non OOB thread from JGroups instead of distributed executor to enforce ordering. This would allow the primary owner to release the lock earlier by not having to wait for response from the cluster listener nodes.
This can lose a message though if the primary owner goes down after the originator got the response that the value was written but before the primary owner sent the message to the listeners. Also could have an issue that if state transfer occurs and the primary owner changes while in the same state you could get a new event from the new primary before the previous ones was received causing an ordering issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-7118) Change cluster listener to use JGroups non OOB thread
by William Burns (JIRA)
William Burns created ISPN-7118:
-----------------------------------
Summary: Change cluster listener to use JGroups non OOB thread
Key: ISPN-7118
URL: https://issues.jboss.org/browse/ISPN-7118
Project: Infinispan
Issue Type: Feature Request
Components: Core, Listeners
Reporter: William Burns
Assignee: William Burns
Currently listeners use dist exec to send events to clustered listeners. This is done while holding onto the lock which increases response time. We could instead send this on a JGroups non OOB thread and not wait for the response. This would allow the write operation to complete much quicker.
However this can cause a missed event if the primary crashes after replying to the originator that it completed but before it transmitted the event to the various cluster listeners.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-6241) Old version of commons-logging drags old version of servlet-api through infinispan-spring
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6241?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6241:
----------------------------------
Status: Open (was: New)
> Old version of commons-logging drags old version of servlet-api through infinispan-spring
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-6241
> URL: https://issues.jboss.org/browse/ISPN-6241
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Affects Versions: 8.1.1.Final
> Reporter: B Bozhanov
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.Beta1, 8.2.5.Final
>
>
> infinispan-spring 8.1.1. has a dependency on an old version of commons-logging (1.1) which in turn has a "compile" dependency on servlet-api 2.3, so in maven the old servlet api is dragged into the build and then conflicts arise when deployed on a servlet container.
> The dependency on commons-logging should be updated (1.2 has a "provided" dependency on the servlet-api)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-6241) Old version of commons-logging drags old version of servlet-api through infinispan-spring
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6241?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6241:
----------------------------------
Component/s: Spring Integration
> Old version of commons-logging drags old version of servlet-api through infinispan-spring
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-6241
> URL: https://issues.jboss.org/browse/ISPN-6241
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Affects Versions: 8.1.1.Final
> Reporter: B Bozhanov
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.Beta1, 8.2.5.Final
>
>
> infinispan-spring 8.1.1. has a dependency on an old version of commons-logging (1.1) which in turn has a "compile" dependency on servlet-api 2.3, so in maven the old servlet api is dragged into the build and then conflicts arise when deployed on a servlet container.
> The dependency on commons-logging should be updated (1.2 has a "provided" dependency on the servlet-api)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-6241) Old version of commons-logging drags old version of servlet-api through infinispan-spring
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6241?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6241:
----------------------------------
Fix Version/s: 9.0.0.Beta1
8.2.5.Final
> Old version of commons-logging drags old version of servlet-api through infinispan-spring
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-6241
> URL: https://issues.jboss.org/browse/ISPN-6241
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.1.1.Final
> Reporter: B Bozhanov
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.Beta1, 8.2.5.Final
>
>
> infinispan-spring 8.1.1. has a dependency on an old version of commons-logging (1.1) which in turn has a "compile" dependency on servlet-api 2.3, so in maven the old servlet api is dragged into the build and then conflicts arise when deployed on a servlet container.
> The dependency on commons-logging should be updated (1.2 has a "provided" dependency on the servlet-api)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-7114) Consistency checker
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7114?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-7114:
-------------------------------------
Assignee: Ryan Emerson
> Consistency checker
> -------------------
>
> Key: ISPN-7114
> URL: https://issues.jboss.org/browse/ISPN-7114
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Tristan Tarrant
> Assignee: Ryan Emerson
>
> We should implement a consistency checker that can either be run on demand via management (e.g. JMX) or triggered by a merge or a topology change caused by abrupt leavers. It should perform per-segment analysis of each key/value pair between primary and backup. The design should incorporate pluggable repair strategies (e.g. latest wins, primary wins, discard, degrade segment, custom)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months