[JBoss JIRA] (DROOLS-3083) [DMN Designer] Data Types - Order data types in the list view
by Guilherme Carreiro (Jira)
[ https://issues.jboss.org/browse/DROOLS-3083?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro updated DROOLS-3083:
---------------------------------------
Description:
The user must be able to re-order data types, by using the options listed in the kebab menu:
!options.png|thumbnail!
was:
The user must be able to re-order data types, by using the options listed in the kebab menu:
!options.png!
> [DMN Designer] Data Types - Order data types in the list view
> -------------------------------------------------------------
>
> Key: DROOLS-3083
> URL: https://issues.jboss.org/browse/DROOLS-3083
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Priority: Major
> Labels: drools-tools
> Attachments: options.png
>
>
> The user must be able to re-order data types, by using the options listed in the kebab menu:
> !options.png|thumbnail!
--
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:
--------------------------------------
This seems to be coming from a combination of JBoss Logging trying to find the logging provider and {{org.jboss.logmanager:log4j-jboss-logmanager}} using JBoss Modules to figure out the start time. Since the CLI {{CommandContext}} creates a logger JBM is initialized before the embedded API initializes JBM meaning the system packages property setting is ignored for the emebedded API. The best solution will be to ensure that {{org.jboss.logmanager:log4j-jboss-logmanager}} does not make it on the class path.
Anyone adding {{org.jboss.logmanager:log4j-jboss-logmanager}} to the class would really have to know that they're doing. If they add that dependency they need to be using the jboss-logmanager which would cause the {{java.util.logging.manager}} system property to be set. This would cause jboss-logging to bind to the jboss-logmanager delaying the access of JBoss Modules until the embedded API initializes it.
> 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] (WFLY-11125) Make org.jboss.as.security and org.picketbox modules optional dependencies of org.jboss.as.weld
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11125?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11125:
------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/11717
> 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
> Priority: Major
>
> 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 Alexey Loubyansky (Jira)
[ https://issues.jboss.org/browse/WFLY-11121?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFLY-11121:
------------------------------------------
The forked process is running Java 1.8.
> 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] (WFCORE-4153) Capability 'org.wildfly.nosql.mongo.driver-service' is unknown error thrown on WildFly 14 + current master branch
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFCORE-4153?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFCORE-4153:
--------------------------------------
The wildfly-nosql built app server dependencies seem to be the same as WF 14, at least diffing the output of "tree -i -f", showed that the only different module files was the nosql modules and the WF 14 org/jboss/as/product/wildfly-full/ module which only contains a MANIFEST.MF.
I'll tried copying the NoSQL modules and merging (nosql) standalone.xml over to my WF 14 build and see the same failure:
{quote}
2018-10-05 16:19:28,708 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool – 4) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "mongodb"),
("mongo" => "default"),
("host" => "default")
]): java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.nosql.mongo.driver-service' is unknown.
at org.jboss.as.controller.CapabilityReferenceRecorder$DefaultCapabilityReferenceRecorder.getDependentName(CapabilityReferenceRecorder.java:139)
at org.jboss.as.controller.CapabilityReferenceRecorder$ContextDependencyRecorder.processCapabilityRequirement(CapabilityReferenceRecorder.java:196)
at org.jboss.as.controller.CapabilityReferenceRecorder$ContextDependencyRecorder.addCapabilityRequirements(CapabilityReferenceRecorder.java:182)
at org.jboss.as.controller.AttributeDefinition.addCapabilityRequirements(AttributeDefinition.java:1066)
at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:291)
at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:154)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
{quote}
> Capability 'org.wildfly.nosql.mongo.driver-service' is unknown error thrown on WildFly 14 + current master branch
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4153
> URL: https://issues.jboss.org/browse/WFCORE-4153
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 6.0.1.Final
> Reporter: Scott Marlow
> Assignee: Jeff Mesnil
> Priority: Major
>
> As reported on [https://issues.jboss.org/browse/WFNOSQL-28], the wildfly-nosql subsystems are failing on WF14. I will try to work around the failure, following Brian's advice but would still like to see this resolved for other (externally created) subsystems that might hit it.
> Example of failure:
> {quote}
> 2018-10-04 11:09:17,904 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool – 10) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "mongodb"),("mongo" => "default"),("host" => "default")
> ]): java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.nosql.mongo.driver-service' is unknown.
> at org.jboss.as.controller.CapabilityReferenceRecorder$DefaultCapabilityReferenceRecorder.getDependentName(CapabilityReferenceRecorder.java:139)
> at org.jboss.as.controller.CapabilityReferenceRecorder$ContextDependencyRecorder.processCapabilityRequirement(CapabilityReferenceRecorder.java:196)
> at org.jboss.as.controller.CapabilityReferenceRecorder$ContextDependencyRecorder.addCapabilityRequirements(CapabilityReferenceRecorder.java:182)
> at org.jboss.as.controller.AttributeDefinition.addCapabilityRequirements(AttributeDefinition.java:1066)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:291)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:154)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {quote}
--
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] I opened a PR with the fix here: https://github.com/belaban/JGroups/pull/401
> 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