[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-5239:
------------------------------------
Summary: XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
Key: WFLY-5239
URL: https://issues.jboss.org/browse/WFLY-5239
Project: WildFly
Issue Type: Feature Request
Components: Clustering, Test Suite
Affects Versions: 10.0.0.Beta2
Reporter: Radoslav Husar
Assignee: Richard Achmatowicz
I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
{noformat}
rhusar [0m[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
[0m[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
[0m[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
[0m[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
[0m[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
[0m[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
[0mExecuted HTTP request
[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
[0m[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5239:
---------------------------------
Issue Type: Bug (was: Feature Request)
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar [0m[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> [0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> [33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> [0mExecuted HTTP request
> [33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-406) Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-406?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-406:
------------------------------------
Fix Version/s: 3.0.0.Alpha1
(was: 2.0.0.CR1)
> Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-406
> URL: https://issues.jboss.org/browse/WFCORE-406
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: FreeBSD, OpenJDK 1.6
> Reporter: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Alpha1
>
>
> Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the description says it's not nillable.
> Specifically, PlatformMBeanDescriptions.getThreadingResource()'s THREAD_CPU_TIME_ENABLED attribute, although there may well be others.
> This leads to this unit test failure on jvms where the UOE is thrown:
> failure message="thread-cpu-time-enabled is undefined"
> type="junit.framework.AssertionFailedError">junit.fra mework.AssertionFailedError: thread-cpu-time-enabled is undefined
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.validateResource(PlatformMBeanResourceUn
> itTestCase.java:595)
> at org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.basicResourceTest(PlatformMBeanResourceUnitTestCase.java:563)
> at
> org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.testThreadingMXBean(PlatformMBeanResourceUnitTestCase.java:340)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-313) DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-313?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-313:
------------------------------------
Fix Version/s: 3.0.0.Alpha1
(was: 2.0.0.CR1)
> DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-313
> URL: https://issues.jboss.org/browse/WFCORE-313
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> When creating reply descriptions, DefaultOperationDescriptionProvider calls attributeDescriptionResolver.getOperationParameterDescription instead of attributeDescriptionResolver.getOperationReplyValueTypeDescription.
> A fix needs to not break compatibility for existing users of the incorrect behavior; i.e. call the correct method in a try block, catch any MissingResourceException, and if caught call the incorrect method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-234?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-234:
------------------------------------
Fix Version/s: 3.0.0.Alpha1
(was: 2.0.0.CR1)
> Inconsistent synchronization in ConfigurationFile
> -------------------------------------------------
>
> Key: WFCORE-234
> URL: https://issues.jboss.org/browse/WFCORE-234
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha11
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir.
> The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot.
> The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-938) Embedded host controller doesn't support --admin-mode=false option
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-938?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-938:
------------------------------------
Issue Type: Feature Request (was: Bug)
> Embedded host controller doesn't support --admin-mode=false option
> ------------------------------------------------------------------
>
> Key: WFCORE-938
> URL: https://issues.jboss.org/browse/WFCORE-938
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
> Embedded standalone instance supports two running modes depending on a value of admin-only option (true is default).
> * *true*
> ** only start services related to server administration
> ** do not start other services or accept end user requests.
> ** embedded instance will not be visible to remote management clients
> * *false*
> ** all services are started
> ** embedded instance is visible to remote management clients (e.g. EAP can be configured via admin console)
> Embedded host controller doesn't offer such a option and is started using --admin-only=true mode by default. Option to run embedded host controller instance with --admin-only=false should be available as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-155) Evaluate robustness of decisions about target versions for transformation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-155?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-155:
-----------------------------------------
What is the end result when 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?
> 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, 8 months
[JBoss JIRA] (WFLY-5238) [Migration operation] [Web to Undertow] Unable to migrate any valve to handler
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFLY-5238:
--------------------------------------
Summary: [Migration operation] [Web to Undertow] Unable to migrate any valve to handler
Key: WFLY-5238
URL: https://issues.jboss.org/browse/WFLY-5238
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Radim Hatlapatka
Assignee: Stuart Douglas
In Undertow there are Handlers which can be used similarly as Valves. Some valves have corresponding handler in Undertow. Such valves could be migrated.
E.g. as part of [EAP7-428] there is added {{io.undertow.server.handlers.RequestDumpingHandler}}.
This could be thereby migrated from
{code:xml}
<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
<valve name="request-dumper" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RequestDumperValve"/>
<virtual-server name="default-host" enable-welcome-root="false">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
...
</subsystem>
{code}
to something like:
{code:xml}
<subsystem xmlns="urn:jboss:domain:undertow:3.0">
<buffer-cache name="default"/>
<server name="default-server" default-host="default-host">
<host name="default-host" alias="localhost, example.com">
<filter-ref name="request-dumper"/>
</host>
</server>
<servlet-container name="default">
<jsp-config/>
</servlet-container>
<filter name="request-dumper" module="io.undertow.core" class-name="io.undertow.server.handlers.RequestDumpingHandler"/>
...
</subsystem>
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5238) [Migration operation] [Web to Undertow] Unable to migrate any valve to handler
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5238?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated WFLY-5238:
-----------------------------------
Affects Version/s: 10.0.0.Beta2
> [Migration operation] [Web to Undertow] Unable to migrate any valve to handler
> ------------------------------------------------------------------------------
>
> Key: WFLY-5238
> URL: https://issues.jboss.org/browse/WFLY-5238
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
>
> In Undertow there are Handlers which can be used similarly as Valves. Some valves have corresponding handler in Undertow. Such valves could be migrated.
> E.g. as part of [EAP7-428] there is added {{io.undertow.server.handlers.RequestDumpingHandler}}.
> This could be thereby migrated from
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
> <valve name="request-dumper" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RequestDumperValve"/>
> <virtual-server name="default-host" enable-welcome-root="false">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> ...
> </subsystem>
> {code}
> to something like:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:undertow:3.0">
> <buffer-cache name="default"/>
> <server name="default-server" default-host="default-host">
> <host name="default-host" alias="localhost, example.com">
> <filter-ref name="request-dumper"/>
> </host>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> </servlet-container>
> <filter name="request-dumper" module="io.undertow.core" class-name="io.undertow.server.handlers.RequestDumpingHandler"/>
> ...
> </subsystem>
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 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:
-----------------------------------------
Looks like a JVM problem then. InetAddress.getByName("fe80:0:0:0:8:20ff:fe6d:eab0%net0:2") is not behaving in accordance with javadoc. It is throwing UnknownHostException when it should not. For a literal IPv6 address string that represents a link-local or site-local it should only check the validity of the address format. The format is valid, as described at https://docs.oracle.com/javase/8/docs/api/java/net/Inet6Address.html#scoped which is linked in the InetAddress.getByName javadoc.
For an IPv6 literal address string with a scope_id appended, UnknownHostException should only be thrown if the address isn't a site-local or link-local address.
This test passes in the community CI runs: http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore&...
There have been failures in the past. I haven't examined them all, but it looks like the failures were due to incorrectly testing global IPv6 addresses, which my patch fixed.
What's happening here is for an InetAddress 'address' obtained from inspecting the addresses available on the system, InetAddress.getByName(address.getHostAddress()) is throwing an UnknownHostException. That's clearly wrong.
> 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, 8 months