[JBoss JIRA] (ISPN-7283) Make remote event supporting cluster listener more fine grained
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7283?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-7283:
-------------------------------------
Master is now as well
> Make remote event supporting cluster listener more fine grained
> ---------------------------------------------------------------
>
> Key: ISPN-7283
> URL: https://issues.jboss.org/browse/ISPN-7283
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote Protocols
> Affects Versions: 9.0.0.Alpha4, 8.2.5.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Beta2, 8.2.6.Final
>
>
> Make server side cluster listener used for supporting remote events more fine grained. Right now if a client registers for created events, server side all nodes push all currently supported events over to the node where the remote listener is located: created, modified, removed and expired. Having all these events being passed around the cluster creates unnecessary load which can create problems in other nodes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7283) Make remote event supporting cluster listener more fine grained
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7283?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-7283:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Make remote event supporting cluster listener more fine grained
> ---------------------------------------------------------------
>
> Key: ISPN-7283
> URL: https://issues.jboss.org/browse/ISPN-7283
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote Protocols
> Affects Versions: 9.0.0.Alpha4, 8.2.5.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Beta2, 8.2.6.Final
>
>
> Make server side cluster listener used for supporting remote events more fine grained. Right now if a client registers for created events, server side all nodes push all currently supported events over to the node where the remote listener is located: created, modified, removed and expired. Having all these events being passed around the cluster creates unnecessary load which can create problems in other nodes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7321) Upgrade to AEsh 0.66.13
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-7321:
-------------------------------------
Summary: Upgrade to AEsh 0.66.13
Key: ISPN-7321
URL: https://issues.jboss.org/browse/ISPN-7321
Project: Infinispan
Issue Type: Component Upgrade
Components: CLI, Server
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 9.0.0.Beta2
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (HRJS-30) Move testsuite server orchestration to a domain
by Galder Zamarreño (JIRA)
Galder Zamarreño created HRJS-30:
------------------------------------
Summary: Move testsuite server orchestration to a domain
Key: HRJS-30
URL: https://issues.jboss.org/browse/HRJS-30
Project: Infinispan Javascript client
Issue Type: Enhancement
Affects Versions: 0.3.0
Reporter: Galder Zamarreño
As more tests have been added to the Infinispan JS testsuite, the existing simple server orchestration script/environment are turning out to be a bit painful to deal with.
On one hand, Haskell's {{stack}} can be sometimes difficult to install in some envs, e.g. Ubuntu. I've also seen issues with Turtle library used in Haskell and copying contents inside symbolic links in Red Hat Linux.
On top of that, as security and cross-site tests were added, more configurations were added and more servers need to be added, making it track the configs a bit more confusing.
Finally, the methods used to start/stop servers in self-contained tests, e.g. xsite and cluster failover, a little bit clunky.
So, with this in mind, we thought of using more suitable orchestration techniques for Infinispan servers. We considered docker compose and kubernetes, but since the servers just simply need to run in a single machine and there's not a huge need to have clean environments, we decided to use a single Infinispan server domain to orchestrate all servers.
The advantages of domain is that is easy to start all servers with the right configuration very quickly, and start/stop servers from tests is very easy and quick compared with current approach. On top of that, having domain based orchestration will make it easy to port over the servers, their configs and script over to testsuites of other langs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months