[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 edited comment on JGRP-2080 at 9/22/16 2:27 AM:
---------------------------------------------------------
I'm starting to have second thoughts on {{IpAddressUUID}}... :-(
Looking at the size of an instance (using JOL), we have
* 32 bytes for {{IpAddressUUID}}
* 24 bytes for {{Inet4Address}}
* 32 bytes for {{InetAddressHolder}} and {{InetAddress6Holder}} each
* 32 bytes for {{Inet6Address}}
This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses.
I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 24 bytes (16 address, 4 port and 4 scope-id) for IPv6 addresses...
That would use *40 bytes for an IPv4 address* and *56 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}.
The downside is that we have to create a new instance of {{Inet4Address}} or {{Inet6Address}} every time we need to send a unicast message, by extracting the address and port from the UUID.
was (Author: belaban):
I'm starting to have second thoughts on {{IpAddressUUID}}... :-(
Looking at the size of an instance (using JOL), we have
* 32 bytes for {{IpAddressUUID}}
* 24 bytes for {{Inet4Address}}
* 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each
* 32 bytes for {{Inet6Address}}
This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses.
I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses...
That would use *40 bytes for an IPv4 address* and *48 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}.
The downside is that we have to create a new instance of {{Inet4Address}} or {{Inet6Address}} every time we need to send a unicast message, by extracting the address and port from the UUID.
> 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)
9 years, 7 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2098 at 9/22/16 2:08 AM:
---------------------------------------------------------
To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}.
(Perhaps the discovery protocol could query attribute {{TP.use_ip_addrs}} and use it instead, so we don't have to introduce another attribute).
In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to.
was (Author: belaban):
To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}.
In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to.
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2098:
--------------------------------
To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}.
In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to.
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2098 at 9/22/16 2:02 AM:
---------------------------------------------------------
We could place {{NAMING}} over {{NAKACK2}} / {{UNICAST3}}, so we don't have to implement our own reliability. To make things simple, the name cache would be populated as follows:
* The joiner sends its address-name mapping to everyone after having joined successfully
* The joiner gets the full name cache from the coordintor, or - alternatively - everyone sends its name to the joiner after the new view has been installed
At the time the coordinator receives the JOIN(P) request, P's logical name would not be known yet, but we could (for example) simply print the IP address:port of IpAddressUUID if the logical name is not known.
After the protocol skteched out above has run, logical names would be available and used to print IpAddressUUIDs.
was (Author: belaban):
We could place {{NAMING}} over {{NAKACK2}} / {{UNICAST3}}, so we don't have to implement our own reliability. To make things simple, the name cache would be populated as follows:
* The joiner sends its address-name mapping to everyone after having joined successfully
* The joiner gets the full name cache from the coordintor, or - alternatively - everyone sends its name to the joiner after the new view has been installed
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2098:
--------------------------------
We could place {{NAMING}} over {{NAKACK2}} / {{UNICAST3}}, so we don't have to implement our own reliability. To make things simple, the name cache would be populated as follows:
* The joiner sends its address-name mapping to everyone after having joined successfully
* The joiner gets the full name cache from the coordintor, or - alternatively - everyone sends its name to the joiner after the new view has been installed
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2098 at 9/22/16 1:47 AM:
---------------------------------------------------------
Hmm, a separate {{NAMING}} protocol might be difficult to write... When a member P joins, it runs the discovery protocol to (1) find the coordinator and (2) populate its (name and address mapping) caches. Coordinator Q can log the logical name of P when receiving a JOIN(P) request, as the previous discovery phase made the logical name of P known to Q.
However, with a separate {{NAMING}} protocol, the logical name of P would somehow have to be shipped to Q separately. Piggy-backing on the discovery protocol entails {{NAMING}} having to intercept all messages and piggybacking on {{GET_MBRS_REQ}} and {{GET_MBRS_RSP}}. However, this slows things down as these message make up only a small part of the overall messages, but we have to inspect *every single message*!
The naming cache would have to be populated via each member sending its name to a joiner, or the joiner fetching the 'state' from the coordinator. Since {{NAMING}} would sit below the discovery protocol, it is not reliable, so this would have to be done multiple times, or we'd have to use some homegrown reliability by e.g. resending the name until it has been acked yada yada yada... Not nice...
was (Author: belaban):
Hmm, a separate {{NAMING}} protocol might be difficult to write... When a member P joins, it runs the discovery protocol to (1) find the coordinator and (2) populate its (name and address mapping) caches. Coordinator Q can log the logical name of P when receiving a JOIN(P) request, as the previous discovery phase made the logical name of P known to Q.
However, with a separate {{NAMING}} protocol, the logical name of P would somehow have to be shipped to Q separately. Piggy-backing on the discovery protocol entails {{NAMING}} having to intercept all messages and piggybacking on {{GET_MBRS_REQ}} and {{GET_MBRS_RSP}}. However, this slows things down as these message make up only a small part of the overall messages, but we have to inspect *every single message*!
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7190) Group related resources in Elytron subsystem
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7190:
----------------------------------
Summary: Group related resources in Elytron subsystem
Key: WFLY-7190
URL: https://issues.jboss.org/browse/WFLY-7190
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure.
Suggestion:
It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7190) Group related resources in Elytron subsystem
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7190?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7190:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Group related resources in Elytron subsystem
> --------------------------------------------
>
> Key: WFLY-7190
> URL: https://issues.jboss.org/browse/WFLY-7190
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure.
> Suggestion:
> It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7189) UT000010: Session not found
by Alpesh B (JIRA)
[ https://issues.jboss.org/browse/WFLY-7189?page=com.atlassian.jira.plugin.... ]
Alpesh B updated WFLY-7189:
---------------------------
Labels: wildfly (was: jboss)
> UT000010: Session not found
> ---------------------------
>
> Key: WFLY-7189
> URL: https://issues.jboss.org/browse/WFLY-7189
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.0.2.Final
> Environment: Production
> Reporter: Alpesh B
> Assignee: Jason Greene
> Priority: Critical
> Labels: wildfly
>
> In my application I am using 4 different database connection with spring,
> Before upgrading to wildfly 9.0.2 Final it was working fine, but yesterday from production I came to know that one database is not able to connect. and giving following exception
> {code:java}
> Caused by: java.lang.IllegalStateException: UT000010: Session not found ONaa4NC8R3y3WuYRhMjp5kD0__MXIkMtHbginKOx
> INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:430)
> INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:123)
> INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.util.WebUtils.getSessionMutex(WebUtils.java:328)
> INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.ServletRequestAttributes.getSessionMutex(ServletRequestAttributes.java:191)
> INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.SessionScope.get(SessionScope.java:88)
> INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285)
> {code}
> While, I was able to connect to other databases through the application, only facing issues for accessing one of the database.
> After restart of wildfly server issue is resolved, Even I am not able to reproduce it
> [OpenIssue|[#https://developer.jboss.org/message/949465#949465]]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months