[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)
10 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)
10 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)
10 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)
10 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)
10 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)
10 years, 8 months
[JBoss JIRA] (DROOLS-890) Thread deadlock issue in class ProjectClassLoader.java
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-890?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-890.
--------------------------------
Fix Version/s: 6.3.0.Final
Resolution: Done
I can see how the InternalClassLoader can be accessed without having acquired a lock on the enclosing ProjectClassLoader first and this is indeed wrong.
I fixed it with this commit https://github.com/droolsjbpm/drools/commit/183518527
> Thread deadlock issue in class ProjectClassLoader.java
> -------------------------------------------------------
>
> Key: DROOLS-890
> URL: https://issues.jboss.org/browse/DROOLS-890
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final
> Reporter: Vivek Hingorani
> Assignee: Mario Fusco
> Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFLY-5049) AMQ Artemis does not support slash character used in activation property of MDB
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5049?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5049:
----------------------------------------
Hi Jeff,
yeap, sorry, it was typo, there are two different queues. MDB consumes from MDBTriggerQueue.
Remote server uses default configuration where connection factory {{RemoteConnectionFactory}} is defined and which I expect the MDB server connects through.
I'm adding the example of configuration files for you can check. These configuration work perfectly until you use instead of queue name {{MDBTriggerQueue}} name like {{queue/MDBTriggerQueue}}.
> AMQ Artemis does not support slash character used in activation property of MDB
> -------------------------------------------------------------------------------
>
> Key: WFLY-5049
> URL: https://issues.jboss.org/browse/WFLY-5049
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha6
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Attachments: ejb-jar.xml, mdb-deployed-standalone-full.xml, remote-activemq-broker-standalone-full.xml
>
>
> When using slash character {{/}} in configuration of artemis messaging subsystem as jms queue name then MDB fails to connect to remote messaging server.
> My settings is following - I have a remote messaging server where queue is defined like
> {code}
> <jms-queue name="queue/crashRecoveryQueue" entries="java:jboss/queue/crashRecoveryQueue"/>
> {code}
> Then there is a server where MDB is deployed. That server configures connection factory
> {code}
> <pooled-connection-factory name="messaging-broker-remote" transaction="xa" entries="java:/RemoteJmsXA" connectors="messaging-broker-http-remote"/>
> {code}
> http connector
> {code}
> <http-connector name="messaging-broker-http-remote" socket-binding="remote-messaging">
> <param name="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> {code}
> outbound socket binding
> {code}
> <outbound-socket-binding name="remote-messaging">
> <remote-destination host="127.0.0.1" port="8280"/>
> </outbound-socket-binding>
> {code}
> and resource reference for ejb subsystem
> {code}
> <mdb>
> <resource-adapter-ref resource-adapter-name="messaging-broker-remote"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> {code}
> The MDB uses ejb-jar with activation properties
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar id="EJBJar_1060639024453" version="3.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
> metadata-complete="false">
> <enterprise-beans>
> <message-driven>
> <ejb-name>JMSCrashMessageDrivenBean</ejb-name>
> <ejb-class>org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean</ejb-class>
> <activation-config>
> <activation-config-property>
> <activation-config-property-name>destination</activation-config-property-name>
> <activation-config-property-value>queue/MDBTriggerQueue</activation-config-property-value>
> </activation-config-property>
> <activation-config-property>
> <activation-config-property-name>destinationType</activation-config-property-name>
> <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
> </activation-config-property>
> </activation-config>
> </message-driven>
> </enterprise-beans>
> </ejb-jar>
> {code}
> The server does not show any warning that the connection was not found, just MDB does not receive any message from the queue.
> If I use {{MDBTriggerQueue}} instead of {{queue/MDBTriggerQueue}} the same setup starts working perfectly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-939) Embedded host controller should set launch type attribute to EMBEDDED
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-939?page=com.atlassian.jira.plugin... ]
Ken Wills updated WFCORE-939:
-----------------------------
Summary: Embedded host controller should set launch type attribute to EMBEDDED (was: Embedded host controller should set lunch type attribute to EMBEDDED)
> Embedded host controller should set launch type attribute to EMBEDDED
> ---------------------------------------------------------------------
>
> Key: WFCORE-939
> URL: https://issues.jboss.org/browse/WFCORE-939
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
> *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded.
> Looking into the LaunchType class, I believe that EMBEDDED value should be used.
> {noformat}
> /** The manner in which a server can be launched */
> public static enum LaunchType {
> /** Launched by a Host Controller in a managed domain */
> DOMAIN(ProcessType.DOMAIN_SERVER),
> /** Launched from the command line */
> STANDALONE(ProcessType.STANDALONE_SERVER),
> /** Launched by another process in which the server is embedded */
> EMBEDDED(ProcessType.EMBEDDED_SERVER),
> ...
> {noformat}
> \\
> *Additional info:*
> {noformat}./standalone.sh
> launch-type STANDALONE
> {noformat}
> {noformat}./domain.sh
> launch-type DOMAIN
> {noformat}
> {noformat}[disconnected /] embed-server
> launch-type EMBEDDED
> {noformat}
> {noformat}[disconnected /] embed-host-controller
> launch-type DOMAIN
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months