[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 updated JGRP-2080:
---------------------------
Description:
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.
was:
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 8 bytes for uniqueness, to have a nice padding at 24 bytes.
> 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, 11 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
Bela Ban created JGRP-2080:
------------------------------
Summary: 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 8 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6688) NPE in Http2PriorityTree$Http2PriorityNode.addDependent
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-6688?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-6688:
------------------------------------------
[~swd847], [~ctomc] Just for completeness: I manually upgraded to 1.3.21 which is used in WFLY Core 2.2.0.CR2, and the issue is gone.
> NPE in Http2PriorityTree$Http2PriorityNode.addDependent
> -------------------------------------------------------
>
> Key: WFLY-6688
> URL: https://issues.jboss.org/browse/WFLY-6688
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> I'm using Windows 8.1 with JDK 8u92, WildFly 10.0.0.Final (Undertow 1.3.15) and alpn-boot 8.1.8.v20160420. When accessing any JSF-based web page (via Chrome) I get the following stacktrace. The REST clients are not using HTTP/2 and work fine.
> {{ERROR [org.xnio.listener] XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.protocols.http2.Http2PriorityTree$Http2PriorityNode.addDependent(Http2PriorityTree.java:248)
> at io.undertow.protocols.http2.Http2PriorityTree$Http2PriorityNode.exclusive(Http2PriorityTree.java:258)
> at io.undertow.protocols.http2.Http2PriorityTree.registerStream(Http2PriorityTree.java:65)
> at io.undertow.protocols.http2.Http2Channel.createChannel(Http2Channel.java:310)
> at io.undertow.protocols.http2.Http2Channel.createChannel(Http2Channel.java:60)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:433)
> at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:103)
> at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:56)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:872)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:853)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1059)
> at io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:229)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1585) Logging handler lost due to conflict handlers in logging.properties and standalone.xml
by Takayoshi Kimura (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1585?page=com.atlassian.jira.plugi... ]
Takayoshi Kimura updated WFCORE-1585:
-------------------------------------
Steps to Reproduce: (was: [)
> Logging handler lost due to conflict handlers in logging.properties and standalone.xml
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1585
> URL: https://issues.jboss.org/browse/WFCORE-1585
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.0.10.Final
> Reporter: Takayoshi Kimura
> Assignee: James Perkins
> Attachments: logging.properties
>
>
> Console logging doesn't work after logging subsystem init with the following configuration.
> * logging.properties is configured with ASYNC with CONSOLE handlers.
> * standalone.xml is configured with stock FILE and CONSOLE handlers.
> Background of why there is a mismatch between logging.properties and standalone.xml, EAP image for OpenShift is configured with ASYNC with CONSOLE handlers by default. But users can customize standalone.xml and apply custom configuration based on the stock standalone.xml.
> Expected result is logging configuration from standalone.xml is applied once logging subsystem come up regardless the mismatch.
> Most likely related to WFCORE-159.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1585) Logging handler lost due to conflict handlers in logging.properties and standalone.xml
by Takayoshi Kimura (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1585?page=com.atlassian.jira.plugi... ]
Takayoshi Kimura edited comment on WFCORE-1585 at 6/8/16 11:46 PM:
-------------------------------------------------------------------
Attached logging.properties to reproduce this issue. Just put this file under standalone/configuration and boot, we won't see the console logging.
Workaround is to rename CONSOLE to CONSOLE2 in logging.properties.
was (Author: tkimura):
Attached logging.properties to reproduce this issue. Just put this file under standalone/configuration and boot, we won't see the console logging.
> Logging handler lost due to conflict handlers in logging.properties and standalone.xml
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1585
> URL: https://issues.jboss.org/browse/WFCORE-1585
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.0.10.Final
> Reporter: Takayoshi Kimura
> Assignee: James Perkins
> Attachments: logging.properties
>
>
> Console logging doesn't work after logging subsystem init with the following configuration.
> * logging.properties is configured with ASYNC with CONSOLE handlers.
> * standalone.xml is configured with stock FILE and CONSOLE handlers.
> Background of why there is a mismatch between logging.properties and standalone.xml, EAP image for OpenShift is configured with ASYNC with CONSOLE handlers by default. But users can customize standalone.xml and apply custom configuration based on the stock standalone.xml.
> Expected result is logging configuration from standalone.xml is applied once logging subsystem come up regardless the mismatch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1585) Logging handler lost due to conflict handlers in logging.properties and standalone.xml
by Takayoshi Kimura (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1585?page=com.atlassian.jira.plugi... ]
Takayoshi Kimura updated WFCORE-1585:
-------------------------------------
Description:
Console logging doesn't work after logging subsystem init with the following configuration.
* logging.properties is configured with ASYNC with CONSOLE handlers.
* standalone.xml is configured with stock FILE and CONSOLE handlers.
Background of why there is a mismatch between logging.properties and standalone.xml, EAP image for OpenShift is configured with ASYNC with CONSOLE handlers by default. But users can customize standalone.xml and apply custom configuration based on the stock standalone.xml.
Expected result is logging configuration from standalone.xml is applied once logging subsystem come up regardless the mismatch.
Most likely related to WFCORE-159.
was:
Console logging doesn't work after logging subsystem init with the following configuration.
* logging.properties is configured with ASYNC with CONSOLE handlers.
* standalone.xml is configured with stock FILE and CONSOLE handlers.
Background of why there is a mismatch between logging.properties and standalone.xml, EAP image for OpenShift is configured with ASYNC with CONSOLE handlers by default. But users can customize standalone.xml and apply custom configuration based on the stock standalone.xml.
Expected result is logging configuration from standalone.xml is applied once logging subsystem come up regardless the mismatch.
> Logging handler lost due to conflict handlers in logging.properties and standalone.xml
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1585
> URL: https://issues.jboss.org/browse/WFCORE-1585
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.0.10.Final
> Reporter: Takayoshi Kimura
> Assignee: James Perkins
> Attachments: logging.properties
>
>
> Console logging doesn't work after logging subsystem init with the following configuration.
> * logging.properties is configured with ASYNC with CONSOLE handlers.
> * standalone.xml is configured with stock FILE and CONSOLE handlers.
> Background of why there is a mismatch between logging.properties and standalone.xml, EAP image for OpenShift is configured with ASYNC with CONSOLE handlers by default. But users can customize standalone.xml and apply custom configuration based on the stock standalone.xml.
> Expected result is logging configuration from standalone.xml is applied once logging subsystem come up regardless the mismatch.
> Most likely related to WFCORE-159.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1585) Logging handler lost due to conflict handlers in logging.properties and standalone.xml
by Takayoshi Kimura (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1585?page=com.atlassian.jira.plugi... ]
Takayoshi Kimura updated WFCORE-1585:
-------------------------------------
Steps to Reproduce: [
Workaround Description: Rename logging handler to avoid the conflict between logging.properties and standalone.xml.
> Logging handler lost due to conflict handlers in logging.properties and standalone.xml
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1585
> URL: https://issues.jboss.org/browse/WFCORE-1585
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.0.10.Final
> Reporter: Takayoshi Kimura
> Assignee: James Perkins
> Attachments: logging.properties
>
>
> Console logging doesn't work after logging subsystem init with the following configuration.
> * logging.properties is configured with ASYNC with CONSOLE handlers.
> * standalone.xml is configured with stock FILE and CONSOLE handlers.
> Background of why there is a mismatch between logging.properties and standalone.xml, EAP image for OpenShift is configured with ASYNC with CONSOLE handlers by default. But users can customize standalone.xml and apply custom configuration based on the stock standalone.xml.
> Expected result is logging configuration from standalone.xml is applied once logging subsystem come up regardless the mismatch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1585) Logging handler lost due to conflict handlers in logging.properties and standalone.xml
by Takayoshi Kimura (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1585?page=com.atlassian.jira.plugi... ]
Takayoshi Kimura updated WFCORE-1585:
-------------------------------------
Attachment: logging.properties
Attached logging.properties to reproduce this issue. Just put this file under standalone/configuration and boot, we won't see the console logging.
> Logging handler lost due to conflict handlers in logging.properties and standalone.xml
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1585
> URL: https://issues.jboss.org/browse/WFCORE-1585
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.0.10.Final
> Reporter: Takayoshi Kimura
> Assignee: James Perkins
> Attachments: logging.properties
>
>
> Console logging doesn't work after logging subsystem init with the following configuration.
> * logging.properties is configured with ASYNC with CONSOLE handlers.
> * standalone.xml is configured with stock FILE and CONSOLE handlers.
> Background of why there is a mismatch between logging.properties and standalone.xml, EAP image for OpenShift is configured with ASYNC with CONSOLE handlers by default. But users can customize standalone.xml and apply custom configuration based on the stock standalone.xml.
> Expected result is logging configuration from standalone.xml is applied once logging subsystem come up regardless the mismatch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months