[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2080:
------------------------------------
These changes can and probably should affect various parts of the system. We are doing what we can in our stack to minimize additional discovery traffic, but there is only so much that can be done without major overhaul (ie: 4.0). We did implement a new version of PING called LESS_PING that extends PING as we no longer need to have discovery run other than initial_discovery. It might also be good to get discovery our of MERGE[N], as that appears to be duplication (with PING/Discovery) and should not be needed for Merger.
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2080:
------------------------------------
Agree 100% about RELAY2 being critical. However, I believe it uses ExtendedUUID and so would not have the issue.
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2080:
--------------------------------
RELAY2 (used for data center replication by Infinispan) installs its own generator, and that's a big use case for us.
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2080:
------------------------------------
In our scenario there is only one address generator installed (IPv4UUID). I believe that under most circumstances the limitation of ExtendedUUID being required for subsequent generators is acceptable [although that may be because I see limited use for additional generators].
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Neal Dillman updated JGRP-2092:
-------------------------------
Attachment: jgroups.txt
I believe that the attached output from several minutes of sendInfo() provides the view from every member as well as an implied state. Unfortunately, we have not had another repeat of the exact break I was referencing, but this one is an example of what is essentially the same thing.
Note that 10.214.51.102 is a member of 10.214.51.100's subgroup. However, 10.215.33.105 (and others) thinks that 10.214.51.102 is his coordinator -- hence they are in a "stuck membership state" can cannot get unstuck.
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2092:
---------------------------
Summary: MERGE3: merge never happens (was: MERGE2: merge never happens)
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JGRP-2092) MERGE2: merge never happens
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2092:
------------------------------------
The title currently reads: "MERGE2: merge never happens". I agree that the issue is likely present in MERGE2, but we have been working with MERGE3. Suggest editing the title
> MERGE2: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez reassigned WFLY-6882:
-----------------------------------------------
Assignee: Enrique González Martínez (was: Paul Ferraro)
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months