[JBoss JIRA] (WFLY-5233) Optimize marshalled size of web sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5233?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5233:
-------------------------------
Description:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into 2: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
was:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into 2: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #3 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
> Optimize marshalled size of web sessions
> ----------------------------------------
>
> Key: WFLY-5233
> URL: https://issues.jboss.org/browse/WFLY-5233
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> There are a couple of marshalling optimizations that we can make in the current web session clustering code:
> * We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
> * We currently store the metadata of a session in a single cache entry. The metadata is composed of:
> *# Creation timestamp (long)
> *# Last access timestamp (long)
> *# Max inactive interval (int)
> #1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into 2: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-5233) Optimize marshalled size of web sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5233?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5233:
-------------------------------
Description:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
was:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into 2: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
> Optimize marshalled size of web sessions
> ----------------------------------------
>
> Key: WFLY-5233
> URL: https://issues.jboss.org/browse/WFLY-5233
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> There are a couple of marshalling optimizations that we can make in the current web session clustering code:
> * We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
> * We currently store the metadata of a session in a single cache entry. The metadata is composed of:
> *# Creation timestamp (long)
> *# Last access timestamp (long)
> *# Max inactive interval (int)
> #1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol fatal error on OpenStack Kilo
by Nick Sawadsky (JIRA)
[ https://issues.jboss.org/browse/JGRP-1954?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky commented on JGRP-1954:
-------------------------------------
That would probably be doable -- but having to write it two ways, depending on the Java version, makes this approach less attractive to me. There might be a version-independent option as well, using ScriptEngine.eval() -- but that may open up security risks. Moving SWIFT_PING to a separate project, or embedding JSON.simple, both seem like more attractive options, in my mind.
> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
> Key: JGRP-1954
> URL: https://issues.jboss.org/browse/JGRP-1954
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123 FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFCORE-934) IPv6ScopeIdMatchUnitTestCase fails on some machines
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-934?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-934:
-----------------------------------------
The "WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%net0:2, so cannot match it to any InetAddress" logging indicates that passing "fe80:0:0:0:8:20ff:fe6d:eab0%net0:2" to InetAddress.getByName() resulted in an UnknownHostException.
I can see how this test could fail if the setup() method stored a global IPv6 address in the "addresses" map, as passing a global IPv6 address string with a scope id appended into InetAddress.getByName() should result in UnknownHostException.
But fe80:0:0:0:8:20ff:fe6d:eab0 is a link-local IPv6 address. If passing that plus the the result of NetworkInterface.getName() appended as a scope-id to InetAddress.getByName() fails, that sounds like a JVM bug.
> IPv6ScopeIdMatchUnitTestCase fails on some machines
> ---------------------------------------------------
>
> Key: WFCORE-934
> URL: https://issues.jboss.org/browse/WFCORE-934
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Brian Stansberry
>
> *Description of problem:*
> org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase#testNonLoopback in WildFly Core TS fails on Solaris11 SPARC.
> *How reproducible:*
> Always with this configuration on Solaris11 SPARC:
> {noformat}
> $ /usr/sbin/ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
> inet 127.0.0.1 netmask ff000000
> net0: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.91.211 netmask fffff800 broadcast 10.16.95.255
> net0:1: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.24 netmask fffff800 broadcast 10.16.183.255
> net0:2: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.25 netmask fffff800 broadcast 10.16.183.255
> net0:3: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.26 netmask fffff800 broadcast 10.16.183.255
> net0:4: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.27 netmask fffff800 broadcast 10.16.183.255
> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
> inet6 ::1/128
> net0: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab1/10
> net0:1: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab2/10
> net0:2: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab0/10
> net0:3: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:164/64
> net0:4: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:165/64
> net0:5: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:166/64
> net0:6: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:167/64
> net0:7: flags=120002080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f:8:20ff:fe6d:eab0/64
> $
> {noformat}
> *Steps to Reproduce:*
> # cd controller
> # mvn test -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dtest=IPv6ScopeIdMatchUnitTestCase
> *Actual results:*
> * StackTrace:
> {noformat}
> java.lang.AssertionError: expected:</fe80:0:0:0:8:20ff:fe6d:eab0%net0:2> but was:<null>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase.testNonLoopback(IPv6ScopeIdMatchUnitTestCase.java:129)
> {noformat}
> * Test output:
> {noformat}
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab2%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab1%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:167%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:166%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:165%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:164%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%net0:2, so cannot match it to any InetAddress
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFCORE-934) IPv6ScopeIdMatchUnitTestCase fails on some machines
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-934?page=com.atlassian.jira.plugin... ]
Marek Kopecký commented on WFCORE-934:
--------------------------------------
Yes, there should be IPv6ScopeIdMatchUnitTestCase.java:128. Sorry for misunderstanding, I probably used old version of wildfly-core.
> IPv6ScopeIdMatchUnitTestCase fails on some machines
> ---------------------------------------------------
>
> Key: WFCORE-934
> URL: https://issues.jboss.org/browse/WFCORE-934
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Brian Stansberry
>
> *Description of problem:*
> org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase#testNonLoopback in WildFly Core TS fails on Solaris11 SPARC.
> *How reproducible:*
> Always with this configuration on Solaris11 SPARC:
> {noformat}
> $ /usr/sbin/ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
> inet 127.0.0.1 netmask ff000000
> net0: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.91.211 netmask fffff800 broadcast 10.16.95.255
> net0:1: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.24 netmask fffff800 broadcast 10.16.183.255
> net0:2: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.25 netmask fffff800 broadcast 10.16.183.255
> net0:3: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.26 netmask fffff800 broadcast 10.16.183.255
> net0:4: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.27 netmask fffff800 broadcast 10.16.183.255
> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
> inet6 ::1/128
> net0: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab1/10
> net0:1: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab2/10
> net0:2: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab0/10
> net0:3: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:164/64
> net0:4: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:165/64
> net0:5: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:166/64
> net0:6: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:167/64
> net0:7: flags=120002080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f:8:20ff:fe6d:eab0/64
> $
> {noformat}
> *Steps to Reproduce:*
> # cd controller
> # mvn test -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dtest=IPv6ScopeIdMatchUnitTestCase
> *Actual results:*
> * StackTrace:
> {noformat}
> java.lang.AssertionError: expected:</fe80:0:0:0:8:20ff:fe6d:eab0%net0:2> but was:<null>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase.testNonLoopback(IPv6ScopeIdMatchUnitTestCase.java:129)
> {noformat}
> * Test output:
> {noformat}
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab2%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab1%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:167%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:166%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:165%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:164%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%net0:2, so cannot match it to any InetAddress
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFCORE-155) Evaluate robustness of decisions about target versions for transformation
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-155?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-155:
------------------------------------------
Currently we have a lot of registries (*GlobalTransformerRegistry*) which will be organized as a tree of registries the address(of the resource or of the operation) will lead to the *TransformationDescription*(s) to be applied. The 'entry' point is the *TransformerRegistry* which contains the subsystems registry and the domain registry.
When a HC connects to the DC it sends a list of all the subsystems it uses and their versions.
For each subsystem/version we will get a registry that will contains all the transformations from the current version of the DC to the HC version.
A slight difference exists when we reach a *ChainedTransformingDescription* because it then takes place of the registry to resolve the subparts.
So if the DC is running on 2.0.0 and the HC is on 1.1.0 when the HC registers : a *TransformationTarget* is created with only a 'filtered' registry containing the a registry with the transformation description for each subsystem according to its version.
So if we have a subsystem with an unregistered version we need to manage it in this processing aka
*GlobalTransformerRegistry.process(final OperationTransformerRegistry registry, final PathAddress address, final ModelVersion version, Map<PathAddress, ModelVersion> versions)* (around line 170) then we need to check that the unregistered version is not used anymore.
> Evaluate robustness of decisions about target versions for transformation
> -------------------------------------------------------------------------
>
> Key: WFCORE-155
> URL: https://issues.jboss.org/browse/WFCORE-155
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 2.0.0.CR1
>
>
> Apologies; this is a bit vague, just a general thing I want us to look into.
> Task is to evaluate how we choose whether transformation needs to occur for a given management API version from a slave, with a view toward checking that intelligent choices are made in the absence of proper transformation definitions.
> The main kind of thing I'm thinking about is the DC is on 2.0.0 and has a transformer to 1.1.0 registered, and then a slave registers that is using 1.1.1. The subsystem author likely forgot to create the transformation to 1.1.1. Odds are good though that transforming to 1.1.0 is a better choice than not transforming and treating the slave as if it were on 2.0.0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFCORE-934) IPv6ScopeIdMatchUnitTestCase fails on some machines
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-934?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-934:
-----------------------------------------
That stack trace does not match the code. Please clarify.
I believe the first line should be IPv6ScopeIdMatchUnitTestCase.java:128 but I am not certain.
> IPv6ScopeIdMatchUnitTestCase fails on some machines
> ---------------------------------------------------
>
> Key: WFCORE-934
> URL: https://issues.jboss.org/browse/WFCORE-934
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Brian Stansberry
>
> *Description of problem:*
> org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase#testNonLoopback in WildFly Core TS fails on Solaris11 SPARC.
> *How reproducible:*
> Always with this configuration on Solaris11 SPARC:
> {noformat}
> $ /usr/sbin/ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
> inet 127.0.0.1 netmask ff000000
> net0: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.91.211 netmask fffff800 broadcast 10.16.95.255
> net0:1: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.24 netmask fffff800 broadcast 10.16.183.255
> net0:2: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.25 netmask fffff800 broadcast 10.16.183.255
> net0:3: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.26 netmask fffff800 broadcast 10.16.183.255
> net0:4: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.27 netmask fffff800 broadcast 10.16.183.255
> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
> inet6 ::1/128
> net0: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab1/10
> net0:1: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab2/10
> net0:2: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab0/10
> net0:3: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:164/64
> net0:4: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:165/64
> net0:5: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:166/64
> net0:6: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:167/64
> net0:7: flags=120002080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f:8:20ff:fe6d:eab0/64
> $
> {noformat}
> *Steps to Reproduce:*
> # cd controller
> # mvn test -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dtest=IPv6ScopeIdMatchUnitTestCase
> *Actual results:*
> * StackTrace:
> {noformat}
> java.lang.AssertionError: expected:</fe80:0:0:0:8:20ff:fe6d:eab0%net0:2> but was:<null>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase.testNonLoopback(IPv6ScopeIdMatchUnitTestCase.java:129)
> {noformat}
> * Test output:
> {noformat}
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab2%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab1%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:167%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:166%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:165%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:164%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%net0:2, so cannot match it to any InetAddress
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFCORE-935) "Connection refused" on FileSystemDeploymentServiceUnitTestCase and LoggingSubsystemRollbackTestCase on pure-IPv6
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-935?page=com.atlassian.jira.plugin... ]
Marek Kopecký moved JBEAP-940 to WFCORE-935:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-935 (was: JBEAP-940)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Test Suite
(was: Test Suite)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.0.Beta4
(was: 7.0.0.DR9)
> "Connection refused" on FileSystemDeploymentServiceUnitTestCase and LoggingSubsystemRollbackTestCase on pure-IPv6
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-935
> URL: https://issues.jboss.org/browse/WFCORE-935
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: James Perkins
>
> *Description of problem:*
> FileSystemDeploymentServiceUnitTestCase and LoggingSubsystemRollbackTestCase fail with "java.net.ConnectException: Connection refused" on pure-IPv6 machines.
> *How reproducible:*
> Always on pure-IPv6 machines
> *Steps to Reproduce:*
> # mvn install -DfailIfNoTests=false -Dtest=LoggingSubsystemRollbackTestCase,FileSystemDeploymentServiceUnitTestCase -DallTests -fae
> *Actual results:*
> {noformat}
> java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.<init>(Socket.java:434)
> at java.net.Socket.<init>(Socket.java:211)
> at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:881)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:787)
> at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:603)
> at org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptText(BMUnit.java:268)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$10.evaluate(BMUnitRunner.java:369)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No errors on output
> *Affected tests:*
> * org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase#testNoUndeployment
> * org.jboss.as.logging.LoggingSubsystemRollbackTestCase#testRollbackHandler
> * org.jboss.as.logging.LoggingSubsystemRollbackTestCase#testRollbackRemoveProfile
> * org.jboss.as.logging.LoggingSubsystemRollbackTestCase#testRollbackWriteAttribute
> * org.jboss.as.logging.LoggingSubsystemRollbackTestCase#testRollbackUpdateAttribute
> * org.jboss.as.logging.LoggingSubsystemRollbackTestCase#testRollbackCompositeLoggingProfile
> * org.jboss.as.logging.LoggingSubsystemRollbackTestCase#testRollbackLogger
> * org.jboss.as.logging.LoggingSubsystemRollbackTestCase#testRollbackRemove
> * org.jboss.as.logging.LoggingSubsystemRollbackTestCase#testRollbackAdd
> * org.jboss.as.logging.LoggingSubsystemRollbackTestCase#testRollbackComposite
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol fatal error on OpenStack Kilo
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1954?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1954:
--------------------------------
Nick, do you think it would be possible to use the JSON parser of either Rhino (shipped with Java 7) or Nashorn (Java 8) ?
> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
> Key: JGRP-1954
> URL: https://issues.jboss.org/browse/JGRP-1954
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123 FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months