[JBoss JIRA] (WFLY-11121) CI - Master linux JDK 11 job - compilation fails - forked embedded process has failed
by Alexey Loubyansky (Jira)
[ https://issues.jboss.org/browse/WFLY-11121?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFLY-11121:
------------------------------------------
This option is added only if the JVM identifies itself as 11 or later.
> CI - Master linux JDK 11 job - compilation fails - forked embedded process has failed
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11121
> URL: https://issues.jboss.org/browse/WFLY-11121
> Project: WildFly
> Issue Type: Bug
> Reporter: Rostislav Svoboda
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Labels: Java11
>
> Compilation of Master linux JDK 11 job fails - forked embedded process has failed.
> https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk11
> {code}
> [Step 2/3] [ERROR] Failed to execute goal org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin:
> 2.0.0.Final:generate-feature-specs (feature-spec-build) on project wildfly-servlet-galleon-pack:
> Feature spec generator failed: Forked embedded process has failed -> [Help 1]
> {code}
> My local machine runs are passing for me, using {{java version "11" 2018-09-25 (build 11+28)}}
> This fail can be related to VMs setup on TeamCity, another option can be galleon related issue.
> CCing also [~aloubyansky]
> We need to have valid Java 11 runs on upstream to guard proper functionality of WildFly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-2788) UX to support selection of multiple data/domain object instances
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-2788?page=com.atlassian.jira.plugi... ]
Liz Clayton reassigned DROOLS-2788:
-----------------------------------
Assignee: Daniele Zonca (was: Liz Clayton)
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-2788
> URL: https://issues.jboss.org/browse/DROOLS-2788
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Daniele Zonca
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-07-24 at 2.22.20 PM.png, Screen Shot 2018-09-18 at 1.35.43 PM.png, Screen Shot 2018-09-19 at 11.44.07 AM.png, now-headers.png, one.png, two.png, zero.png
>
>
> As a user I want to define multiple data/domain object instances per scenario (i.e. possible to have a scenario with more than one instance of “Person”), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-2788) UX to support selection of multiple data/domain object instances
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-2788?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2788:
-------------------------------------
[~danielezonca] I was consulting with [~manstis] about various topics, and he helped me to better understand your proposal. Given the timeframe, and the constraints that [~gabriolo] outlined, it seems like a viable way to move forward. In the future, it would be great if we could plan ahead to revisit this interaction to refine it.
If you could connect with gadey(a)redhat.com or [~stetson.robinson] to figure out the best terms to use for the menu, that would be great. Here's a document for reference: https://docs.google.com/document/d/1lHQ1mvmzQcgWbxwkBobIXb9mV6uM3RLbEll8-...
I'm going to reassign this back to you so that you can keep moving forward with it.
[~tirelli] for awareness ^^
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-2788
> URL: https://issues.jboss.org/browse/DROOLS-2788
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-07-24 at 2.22.20 PM.png, Screen Shot 2018-09-18 at 1.35.43 PM.png, Screen Shot 2018-09-19 at 11.44.07 AM.png, now-headers.png, one.png, two.png, zero.png
>
>
> As a user I want to define multiple data/domain object instances per scenario (i.e. possible to have a scenario with more than one instance of “Person”), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11125) Make org.jboss.as.security and org.picketbox modules optional dependencies of org.jboss.as.weld
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-11125:
---------------------------------------
Summary: Make org.jboss.as.security and org.picketbox modules optional dependencies of org.jboss.as.weld
Key: WFLY-11125
URL: https://issues.jboss.org/browse/WFLY-11125
Project: WildFly
Issue Type: Enhancement
Components: CDI / Weld, Security
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The more optional deps the Weld subsystem module has, the better as it helps allow slimmer runtimes.
1) org.jboss.as.security -- classes from this module (SimpleSecurityManager[Service] should only be loaded if the org.wildfly.legacy-security capability is present, so this dep can be optional.
2) org.picketbox -- AFAICT these are only used via org.jboss.weld.security.spi.SecurityServices impl methods that are never called. And it seems like they wouldn't be expected to work without the org.wildfly.legacy-security capability being present anyway. So I believe this dep can be optional.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11121) CI - Master linux JDK 11 job - compilation fails - forked embedded process has failed
by Ken Wills (Jira)
[ https://issues.jboss.org/browse/WFLY-11121?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFLY-11121:
----------------------------------
[~aloubyansky] Have we confirmed that it doesn't happen with JDK 8 / 9 / 10 in CI and we're sure its something specific to JDK 11?
> CI - Master linux JDK 11 job - compilation fails - forked embedded process has failed
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11121
> URL: https://issues.jboss.org/browse/WFLY-11121
> Project: WildFly
> Issue Type: Bug
> Reporter: Rostislav Svoboda
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Labels: Java11
>
> Compilation of Master linux JDK 11 job fails - forked embedded process has failed.
> https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk11
> {code}
> [Step 2/3] [ERROR] Failed to execute goal org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin:
> 2.0.0.Final:generate-feature-specs (feature-spec-build) on project wildfly-servlet-galleon-pack:
> Feature spec generator failed: Forked embedded process has failed -> [Help 1]
> {code}
> My local machine runs are passing for me, using {{java version "11" 2018-09-25 (build 11+28)}}
> This fail can be related to VMs setup on TeamCity, another option can be galleon related issue.
> CCing also [~aloubyansky]
> We need to have valid Java 11 runs on upstream to guard proper functionality of WildFly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11121) CI - Master linux JDK 11 job - compilation fails - forked embedded process has failed
by Alexey Loubyansky (Jira)
[ https://issues.jboss.org/browse/WFLY-11121?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFLY-11121:
------------------------------------------
Just for the record, if I change it to --add-modules=java.se I get
[11:50:32] : [Step 2/3] Unrecognized option: --add-modules=java.se
[11:50:32] : [Step 2/3] Error: Could not create the Java Virtual Machine.
[11:50:32] : [Step 2/3] Error: A fatal exception has occurred. Program will exit.
[11:50:32] : [Step 2/3] [Maven Watcher]
That's on the CI. I still can't reproduce it locally.
> CI - Master linux JDK 11 job - compilation fails - forked embedded process has failed
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11121
> URL: https://issues.jboss.org/browse/WFLY-11121
> Project: WildFly
> Issue Type: Bug
> Reporter: Rostislav Svoboda
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Labels: Java11
>
> Compilation of Master linux JDK 11 job fails - forked embedded process has failed.
> https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk11
> {code}
> [Step 2/3] [ERROR] Failed to execute goal org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin:
> 2.0.0.Final:generate-feature-specs (feature-spec-build) on project wildfly-servlet-galleon-pack:
> Feature spec generator failed: Forked embedded process has failed -> [Help 1]
> {code}
> My local machine runs are passing for me, using {{java version "11" 2018-09-25 (build 11+28)}}
> This fail can be related to VMs setup on TeamCity, another option can be galleon related issue.
> CCing also [~aloubyansky]
> We need to have valid Java 11 runs on upstream to guard proper functionality of WildFly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11124) The wildfly-testsuite-shared module brings in all WildFly dependencies
by James Perkins (Jira)
James Perkins created WFLY-11124:
------------------------------------
Summary: The wildfly-testsuite-shared module brings in all WildFly dependencies
Key: WFLY-11124
URL: https://issues.jboss.org/browse/WFLY-11124
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: James Perkins
Assignee: James Perkins
The {{org.wildfly:wildfly-testsuite-shared}} has a dependency all the main 3 Galleon feature-packs.
{code:xml}
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>wildfly-galleon-pack</artifactId>
<type>pom</type>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>wildfly-servlet-galleon-pack</artifactId>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.wildfly.core</groupId>
<artifactId>wildfly-core-galleon-pack</artifactId>
<type>pom</type>
</dependency>
{code}
This means that all tests that which use the shared module, likely all of them, end up with the entirety of WildFly on the test class path. In most cases this is not an issue. However an issue was uncovered with the IBM JDK in WFLY-10529. The tests should definitely not have a transitive dependency on things like that or for example the {{org.wildfly.core:wildfly-controller}}. If dependencies like those are needed they should be explicitly defined as those are not public API's.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10529) ParseAndMarshalModelsTestCase fails on the latest IBM8 with Failed to register MBean with MBeanServer
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10529?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-10529:
--------------------------------------
The issue seems to be with OpenJDK the {{DelegatingModelControllerClient}} is found on the flat class path where as with the IBM JDK it's found on a {{ModuleClassLoader}} and the {{ModelControllerClient}} interface is found on the flat class path. Note this seems to be a test issue only. I can launch the embedded server with the CLI client JAR and the J9 JVM from the command line. A fix for this will likely be within the test suite itself.
> ParseAndMarshalModelsTestCase fails on the latest IBM8 with Failed to register MBean with MBeanServer
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-10529
> URL: https://issues.jboss.org/browse/WFLY-10529
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Petr Kremensky
> Assignee: James Perkins
> Priority: Major
>
> org.jboss.as.test.manualmode.parse.ParseAndMarshalModelsTestCase from manualmode module of wildlfy testsuite fails with the latest IBM 8 JDK bits.
> *reproduce*
> {noformat}
> wildfly/testsuite]$ mvn test -DtestLogToFile=false -pl integration/manualmode -Dts.manualmode -Dtest=ParseAndMarshalModelsTestCase
> ...
> [ERROR] Tests run: 40, Failures: 40, Errors: 0, Skipped: 0
> {noformat}
> *Error message appearing in the logs*
> {noformat}
> Jun 07, 2018 3:57:14 PM org.jboss.msc.service.ServiceContainerImpl <init>
> ERROR: MSC000010: Failed to register MBean with MBeanServer
> javax.management.InstanceAlreadyExistsException: jboss.msc:type=container,name=host-controller
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:449)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1910)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:978)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:912)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:336)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534)
> at org.jboss.msc.service.ServiceContainerImpl.<init>(ServiceContainerImpl.java:368)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:221)
> at org.wildfly.core.embedded.EmbeddedHostControllerBootstrap$ShutdownHook.register(EmbeddedHostControllerBootstrap.java:90)
> at org.wildfly.core.embedded.EmbeddedHostControllerBootstrap$ShutdownHook.access$100(EmbeddedHostControllerBootstrap.java:80)
> at org.wildfly.core.embedded.EmbeddedHostControllerBootstrap.<init>(EmbeddedHostControllerBootstrap.java:54)
> at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.start(EmbeddedHostControllerFactory.java:270)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.invokeOnServer(EmbeddedManagedProcessImpl.java:88)
> at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.start(EmbeddedManagedProcessImpl.java:58)
> at org.jboss.as.cli.embedded.EmbedHostControllerHandler.doHandle(EmbedHostControllerHandler.java:268)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:89)
> at org.jboss.as.cli.impl.CommandExecutor$2.lambda$build$0(CommandExecutor.java:685)
> at org.jboss.as.cli.impl.CommandExecutor$2$$Lambda$79.00000000200064E0.execute(Unknown Source)
> at org.jboss.as.cli.impl.CommandExecutor.lambda$execute$0(CommandExecutor.java:708)
> at org.jboss.as.cli.impl.CommandExecutor$$Lambda$78.00000000AD3CF710.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:811)
> {noformat}
> *Failure cause*
> {noformat}
> Caused by: org.jboss.as.cli.CommandLineException: Cannot start embedded server
> at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:300)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:89)
> at org.jboss.as.cli.impl.CommandExecutor$2.lambda$build$0(CommandExecutor.java:685)
> at org.jboss.as.cli.impl.CommandExecutor$2$$Lambda$79.00000000200064E0.execute(Unknown Source)
> at org.jboss.as.cli.impl.CommandExecutor.lambda$execute$0(CommandExecutor.java:708)
> at org.jboss.as.cli.impl.CommandExecutor$$Lambda$78.00000000AD3CF710.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:811)
> Caused by: java.lang.ClassCastException: org.jboss.as.controller.client.helpers.DelegatingModelControllerClient incompatible with org.jboss.as.controller.client.ModelControllerClient
> at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.getModelControllerClient(EmbeddedManagedProcessImpl.java:72)
> at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:244)
> ... 9 more
> {noformat}
> *Environment*
> {noformat}
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z)
> Maven home: /qa/tools/opt/maven3-latest
> Java version: 1.8.0_171, vendor: IBM Corporation
> Java home: /qa/tools/opt/x86_64/ibm-java-x86_64-sdk-8.0-5.15/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-862.el7.x86_64", arch: "amd64", family: "unix"
> ---
> $ java -version
> java version "1.8.0_171"
> Java(TM) SE Runtime Environment (build 8.0.5.15 - pxa6480sr5fp15-20180502_01(SR5 FP15))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20180425_385365 (JIT enabled, AOT enabled)
> OpenJ9 - a7ffbfe
> OMR - a531219
> IBM - 59ef3dc)
> JCL - 20180425_01 based on Oracle jdk8u171-b11
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JGRP-2296) DNS_PING is dropping port values with SRV based service discovery
by Eric Thompson (Jira)
[ https://issues.jboss.org/browse/JGRP-2296?page=com.atlassian.jira.plugin.... ]
Eric Thompson commented on JGRP-2296:
-------------------------------------
[~belaban] OK. I had a chance to try it out. No dice. It has the same behaviour:
{code}
[jboss@6aad4e9ec3ec ~]$ grep "4.0.16" keycloak/standalone/log/server.log
2018-10-05 16:13:49,531 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) WFLYCLJG0001: Activating JGroups subsystem. JGroups version 4.0.16
... DNS_PING service discovery, same issue ...
2018-10-05 16:14:58,984 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (ConnectionValidator) Checking for connection within frequency
2018-10-05 16:15:06,019 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Performing initial discovery
2018-10-05 16:15:06,024 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS: [10.42.3.56:0, 10.42.3.44:0]
2018-10-05 16:15:06,025 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Discovered IP Address with port 0 (10.42.3.56:0). Replacing with default Transport port: 7600
2018-10-05 16:15:06,025 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Discovered IP Address with port 0 (10.42.3.44:0). Replacing with default Transport port: 7600
2018-10-05 16:15:06,025 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Performing discovery of the following hosts [10.42.3.44:7600, 10.42.3.56:7600, 6aad4e9ec3ec, 132db10f3fe1]
2018-10-05 16:15:06,026 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 6aad4e9ec3ec: sending discovery request to 10.42.3.44:7600
2018-10-05 16:15:06,026 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 6aad4e9ec3ec: sending discovery request to 10.42.3.56:7600
2018-10-05 16:15:06,027 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-15,ejb,6aad4e9ec3ec) Received discovery from: 6aad4e9ec3ec, IP: 10.42.3.56:7600
2018-10-05 16:15:06,027 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 6aad4e9ec3ec: sending discovery request to 6aad4e9ec3ec
2018-10-05 16:15:06,028 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Received discovery from: 6aad4e9ec3ec, IP: 10.42.3.56:7600
2018-10-05 16:15:06,028 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 6aad4e9ec3ec: sending discovery request to 132db10f3fe1
2018-10-05 16:15:28,984 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 30000
{code}
> DNS_PING is dropping port values with SRV based service discovery
> -----------------------------------------------------------------
>
> Key: JGRP-2296
> URL: https://issues.jboss.org/browse/JGRP-2296
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11
> Environment: JGroups version 4.0.11.Final
> Used in Keycloak 4.4.0
> Deployed as Jboss based Docker container from jboss/keycloak into AWS ECS
> Reporter: Eric Thompson
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.0.16
>
>
> Using DNS_PING in Jgroups 4.0.11 and SRV records the port from the SRV record is being dropped (set to zero) and the default is used instead (7600).
> I am using this Jgroups config:
> {code}
> <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
> <channels default="ee">
> <channel name="ee" stack="tcp" cluster="ejb"/>
> </channels>
> <stacks>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp">
> <property name="external_addr">${env.EXTERNAL_ADDR}</property>
> </transport>
> <protocol type="dns.DNS_PING">
> <property name="dns_query">
> jgroups.${env.DNS_NAME}.svc.cluster.local
> </property>
> <property name="dns_record_type">
> SRV
> </property>
> </protocol>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG3"/>
> </stack>
> </stacks>
> </subsystem>
> {code}
> I have these service discovery DNS entries
> {code}
> $ dig jgroups.dev.auth.example.com.svc.cluster.local SRV
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.58.amzn1 <<>> jgroups.dev.auth.example.com.svc.cluster.local SRV
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16690
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;jgroups.dev.auth.example.com.svc.cluster.local. IN SRV
> ;; ANSWER SECTION:
> jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32921 9ec82e3f-3a0e-4e30-b785-17879c63cd7d.jgroups.dev.auth.example.com.svc.cluster.local.
> jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32923 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.example.com.svc.cluster.local.
> jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32915 9d9d78d0-8919-4b91-9df8-2e4e65afedae.jgroups.dev.auth.example.com.svc.cluster.local.
> jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32917 161f3d66-f1e3-46f4-a44f-ebda925a25c6.jgroups.dev.auth.example.com.svc.cluster.local.
> ;; Query time: 2 msec
> ;; SERVER: 10.42.3.2#53(10.42.3.2)
> ;; WHEN: Fri Sep 21 01:45:44 2018
> ;; MSG SIZE rcvd: 481
> {code}
> But I get this in the logs when running Keycloak in standalone cluster:
> {code}
> 17:45:10,121 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Performing initial discovery
> 17:45:10,154 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Entries collected from DNS: [10.42.3.56:0, 10.42.3.56:0, 10.42.3.44:0, 10.42.3.44:0]
> 17:45:10,155 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Discovered IP Address with port 0 (10.42.3.56:0). Replacing with default Transport port: 7600
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Discovered IP Address with port 0 (10.42.3.56:0). Replacing with default Transport port: 7600
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Discovered IP Address with port 0 (10.42.3.44:0). Replacing with default Transport port: 7600
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Discovered IP Address with port 0 (10.42.3.44:0). Replacing with default Transport port: 7600
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) Performing discovery of the following hosts [10.42.3.56:7600, 10.42.3.44:7600, e200a617bf7a]
> 17:45:10,159 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) e200a617bf7a: sending discovery request to 10.42.3.56:7600
> 17:45:10,160 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) e200a617bf7a: sending discovery request to 10.42.3.44:7600
> 17:45:10,160 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-10,ejb,e200a617bf7a) Received discovery from: e200a617bf7a, IP: 10.42.3.44:7600
> 17:45:10,161 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-3,null,null) e200a617bf7a: sending discovery request to e200a617bf7a
> 17:45:10,162 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-11,ejb,e200a617bf7a) Received discovery from: e200a617bf7a, IP: 10.42.3.44:7600
> {code}
> As you can see it is resolving the DNS addresses, but discarding the ports.
> To be clear, in this example 32923 ids the port (eg:
> 1 1 32923 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.example.com.svc.cluster.local).
> These are dynamic ports mapped to port 7600 in order to put more Keycloak containers on each instance.
> {code}
> $ docker ps
> CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
> f67e39f8f403 datadog/agent:latest-jmx "/init" 8 hours ago Up 8 hours (healthy) 8125/udp, 8126/tcp ecs-auth-service-dev-26-datadog-agent-a2b7f783ddd0ba9cf601
> bbb12f0c43a5 233747045000.dkr.ecr.us-east-2.amazonaws.com/ops/keycloak:latest "/opt/jboss/tools/do…" 8 hours ago Up 8 hours 0.0.0.0:32923->7600/tcp, 0.0.0.0:32922->8080/tcp ecs-auth-service-dev-26-keycloak-f4bd8f8dca9fd4cd4f00
> 932cad7c4fb9 datadog/agent:latest-jmx "/init" 8 hours ago Up 8 hours (healthy) 8125/udp, 8126/tcp ecs-auth-service-dev-26-datadog-agent-baa38a98ccaddea6f501
> e200a617bf7a 233747045000.dkr.ecr.us-east-2.amazonaws.com/ops/keycloak:latest "/opt/jboss/tools/do…" 8 hours ago Up 8 hours 0.0.0.0:32921->7600/tcp, 0.0.0.0:32920->8080/tcp ecs-auth-service-dev-26-keycloak-e6f398e6cc8db5b5f101
> 73bc0b863c73 amazon/amazon-ecs-agent:latest "/agent" 2 days ago Up 2 days ecs-agent
> {code}
> This seems like it might be where ports are getting lost:
> https://github.com/belaban/JGroups/blob/07060c3ba6e52ad4aad3ac799c2bc95ff...
> I don't see the port number being extracted from the SRV entry and appended to the IP returned from resolveAEntries.
> Let me know if I am missing any details. This is a major blocker for development.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10529) ParseAndMarshalModelsTestCase fails on the latest IBM8 with Failed to register MBean with MBeanServer
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10529?page=com.atlassian.jira.plugin... ]
James Perkins reassigned WFLY-10529:
------------------------------------
Assignee: James Perkins
> ParseAndMarshalModelsTestCase fails on the latest IBM8 with Failed to register MBean with MBeanServer
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-10529
> URL: https://issues.jboss.org/browse/WFLY-10529
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Petr Kremensky
> Assignee: James Perkins
> Priority: Major
>
> org.jboss.as.test.manualmode.parse.ParseAndMarshalModelsTestCase from manualmode module of wildlfy testsuite fails with the latest IBM 8 JDK bits.
> *reproduce*
> {noformat}
> wildfly/testsuite]$ mvn test -DtestLogToFile=false -pl integration/manualmode -Dts.manualmode -Dtest=ParseAndMarshalModelsTestCase
> ...
> [ERROR] Tests run: 40, Failures: 40, Errors: 0, Skipped: 0
> {noformat}
> *Error message appearing in the logs*
> {noformat}
> Jun 07, 2018 3:57:14 PM org.jboss.msc.service.ServiceContainerImpl <init>
> ERROR: MSC000010: Failed to register MBean with MBeanServer
> javax.management.InstanceAlreadyExistsException: jboss.msc:type=container,name=host-controller
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:449)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1910)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:978)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:912)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:336)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534)
> at org.jboss.msc.service.ServiceContainerImpl.<init>(ServiceContainerImpl.java:368)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:221)
> at org.wildfly.core.embedded.EmbeddedHostControllerBootstrap$ShutdownHook.register(EmbeddedHostControllerBootstrap.java:90)
> at org.wildfly.core.embedded.EmbeddedHostControllerBootstrap$ShutdownHook.access$100(EmbeddedHostControllerBootstrap.java:80)
> at org.wildfly.core.embedded.EmbeddedHostControllerBootstrap.<init>(EmbeddedHostControllerBootstrap.java:54)
> at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.start(EmbeddedHostControllerFactory.java:270)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.invokeOnServer(EmbeddedManagedProcessImpl.java:88)
> at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.start(EmbeddedManagedProcessImpl.java:58)
> at org.jboss.as.cli.embedded.EmbedHostControllerHandler.doHandle(EmbedHostControllerHandler.java:268)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:89)
> at org.jboss.as.cli.impl.CommandExecutor$2.lambda$build$0(CommandExecutor.java:685)
> at org.jboss.as.cli.impl.CommandExecutor$2$$Lambda$79.00000000200064E0.execute(Unknown Source)
> at org.jboss.as.cli.impl.CommandExecutor.lambda$execute$0(CommandExecutor.java:708)
> at org.jboss.as.cli.impl.CommandExecutor$$Lambda$78.00000000AD3CF710.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:811)
> {noformat}
> *Failure cause*
> {noformat}
> Caused by: org.jboss.as.cli.CommandLineException: Cannot start embedded server
> at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:300)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:89)
> at org.jboss.as.cli.impl.CommandExecutor$2.lambda$build$0(CommandExecutor.java:685)
> at org.jboss.as.cli.impl.CommandExecutor$2$$Lambda$79.00000000200064E0.execute(Unknown Source)
> at org.jboss.as.cli.impl.CommandExecutor.lambda$execute$0(CommandExecutor.java:708)
> at org.jboss.as.cli.impl.CommandExecutor$$Lambda$78.00000000AD3CF710.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:811)
> Caused by: java.lang.ClassCastException: org.jboss.as.controller.client.helpers.DelegatingModelControllerClient incompatible with org.jboss.as.controller.client.ModelControllerClient
> at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.getModelControllerClient(EmbeddedManagedProcessImpl.java:72)
> at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:244)
> ... 9 more
> {noformat}
> *Environment*
> {noformat}
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z)
> Maven home: /qa/tools/opt/maven3-latest
> Java version: 1.8.0_171, vendor: IBM Corporation
> Java home: /qa/tools/opt/x86_64/ibm-java-x86_64-sdk-8.0-5.15/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-862.el7.x86_64", arch: "amd64", family: "unix"
> ---
> $ java -version
> java version "1.8.0_171"
> Java(TM) SE Runtime Environment (build 8.0.5.15 - pxa6480sr5fp15-20180502_01(SR5 FP15))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20180425_385365 (JIT enabled, AOT enabled)
> OpenJ9 - a7ffbfe
> OMR - a531219
> IBM - 59ef3dc)
> JCL - 20180425_01 based on Oracle jdk8u171-b11
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months