[JBoss JIRA] (ISPN-4817) Cluster Listener replication of listener to remote dist nodes needs privilege action
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4817?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4817:
--------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.1.0.Final)
> Cluster Listener replication of listener to remote dist nodes needs privilege action
> ------------------------------------------------------------------------------------
>
> Key: ISPN-4817
> URL: https://issues.jboss.org/browse/ISPN-4817
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 7.0.0.CR1
> Reporter: William Burns
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
>
> The ClusterListenerReplicateCallable needs to add the listener in a privileged block so that it can work properly.
> I was also thinking if we need to change all of our messages to send along the current Subject so it can be properly applied to remote invocations as well. In this case we wouldn't need to wrap the listener invocation.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (ISPN-4722) CLI remove is not cluster-wide
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4722?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4722:
--------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.1.0.Final)
> CLI remove is not cluster-wide
> ------------------------------
>
> Key: ISPN-4722
> URL: https://issues.jboss.org/browse/ISPN-4722
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 6.0.2.Final, 7.0.0.Beta1
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Fix For: 7.2.0.Alpha1
>
>
> In CLI, the "remove" command does not delete entries in all nodes of a clustered environment, only the local copy. However, the "put" command does write in all nodes. Is it the expected behavior? See example below:
> {code}
> node 1
> put k1 v1
> get k1 -> v1
> node 2
> get k1 -> v1
> node 1
> remove k1
> get k1 -> null
> node 2
> get k1 -> v1
> {code}
> I know that these commands provided by CLI are not used in real world, but they are useful to demonstrate the correct configuration of a JDG cluster.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (ISPN-5010) Improve remote listener performance
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5010?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5010:
--------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.1.0.Final)
> Improve remote listener performance
> -----------------------------------
>
> Key: ISPN-5010
> URL: https://issues.jboss.org/browse/ISPN-5010
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Affects Versions: 7.0.2.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.2.0.Alpha1
>
>
> We've run some performance tests and we've noticed remote listeners have a too negative effect on get/put/remove operations, particularly as number of listeners added by clients increase. This JIRA encompasses different pieces of work to improve this:
> * Make server-side clustered listener async. By doing so, the operations are detached from the actual server-side listener part when the notification is sent to clients. Async listener executor is configured with 1 thread, so order is still maintained.
> * Batching at the server-side clustered listener side. Instead of sending each event as it comes, apply time/size based batching to reduce number of system calls to flush sockets to clients.
> * Further improvements might come from bundling listeners added by same client, but this is more complicated to achieve, since only those listeners that have similar characteristics can be bundled, e.g. have same filter/converter settings. Also, whether to use a single connection for all listeners or maintain separate ones still would need to be decided. (see ISPN-4491)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (ISPN-4924) CacheEntryEvent isOriginLocal is not correct in many circumstances
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4924?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4924:
--------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.1.0.Final)
> CacheEntryEvent isOriginLocal is not correct in many circumstances
> ------------------------------------------------------------------
>
> Key: ISPN-4924
> URL: https://issues.jboss.org/browse/ISPN-4924
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.0.CR2
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.2.0.Alpha1
>
>
> Origin local flag was messed up when nontx DIST was rewritten to have the primary owner send updates to the backup nodes. This in turn affected REPL when it was changed to be implemented on top of DIST. I believe that tx is unaffected. Also new cluster listeners don't put the flag properly for DIST caches if the originator is not also the primary owner.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months