[JBoss JIRA] (WFLY-10952) JDK11 IIOPSslInvocationTestCase fails
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10952?page=com.atlassian.jira.plugin... ]
Richard Opalka resolved WFLY-10952.
-----------------------------------
Release Notes Text:
I apologise for false alarm Honza. It was some maven weirdness on my side.
When I ran whole IIOP test suite it worked like a charm on all JDKs 8,9,10 & 11
Resolution: Out of Date
> JDK11 IIOPSslInvocationTestCase fails
> -------------------------------------
>
> Key: WFLY-10952
> URL: https://issues.jboss.org/browse/WFLY-10952
> Project: WildFly
> Issue Type: Sub-task
> Components: Test Suite
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> {code}
> cd testsuite/integration/iiop
> JAVA_HOME=/opt/jdk-11/ PATH=$JAVA_HOME/bin:$PATH mvn clean test -Dtest=IIOPSslInvocationTestCase#testManualCleartextLookup -Djavax.net.debug=all
> {code}
> {code}
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/statelessHome [Root exception is java.lang.RuntimeException: javax.naming.NamingException: WFLYIIOP0031: Cannot connect to ORB [Root exception is org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No]]
> at org.jboss.as.naming@14.0.0.CR1-SNAPSHOT//org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:159)
> at org.jboss.as.naming@14.0.0.CR1-SNAPSHOT//org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming@14.0.0.CR1-SNAPSHOT//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming@14.0.0.CR1-SNAPSHOT//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming@14.0.0.CR1-SNAPSHOT//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming@14.0.0.CR1-SNAPSHOT//org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:322)
> ... 213 more
> Caused by: java.lang.RuntimeException: javax.naming.NamingException: WFLYIIOP0031: Cannot connect to ORB [Root exception is org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No]
> at org.jboss.as.ejb3@14.0.0.CR1-SNAPSHOT//org.jboss.as.ejb3.deployment.processors.EjbLookupInjectionSource$1.getReference(EjbLookupInjectionSource.java:99)
> at org.jboss.as.naming@14.0.0.CR1-SNAPSHOT//org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 218 more
> Caused by: javax.naming.NamingException: WFLYIIOP0031: Cannot connect to ORB [Root exception is org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No]
> at org.wildfly.iiop-openjdk@14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.naming.jndi.CNCtx.setOrbAndRootContext(CNCtx.java:366)
> at org.wildfly.iiop-openjdk@14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingCorbanameUrl(CNCtx.java:335)
> at org.wildfly.iiop-openjdk@14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingUrl(CNCtx.java:268)
> at org.wildfly.iiop-openjdk@14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:233)
> at org.wildfly.iiop-openjdk(a)14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
> at org.wildfly.iiop-openjdk@14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
> at org.wildfly.iiop-openjdk@14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.naming.jndi.WrapperInitialContext.lookup(WrapperInitialContext.java:72)
> at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
> at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
> at org.jboss.as.ejb3@14.0.0.CR1-SNAPSHOT//org.jboss.as.ejb3.deployment.processors.EjbLookupInjectionSource$1.getReference(EjbLookupInjectionSource.java:81)
> ... 219 more
> Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No
> at javax.orb.api@8.1.2.Final//com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2200)
> at javax.orb.api@8.1.2.Final//com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2221)
> at javax.orb.api(a)8.1.2.Final//com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:223)
> at javax.orb.api(a)8.1.2.Final//com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:236)
> at javax.orb.api@8.1.2.Final//com.sun.corba.se.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:131)
> at javax.orb.api@8.1.2.Final//com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:187)
> at javax.orb.api@8.1.2.Final//com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:137)
> at javax.orb.api@8.1.2.Final//com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:229)
> at javax.orb.api@8.1.2.Final//org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:130)
> at javax.orb.api@8.1.2.Final//org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
> at org.wildfly.iiop-openjdk@14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.naming.jndi.CNCtx.setOrbAndRootContext(CNCtx.java:353)
> ... 228 more
> Caused by: java.net.ConnectException: Connection refused
> at java.base/sun.nio.ch.Net.connect0(Native Method)
> at java.base/sun.nio.ch.Net.connect(Net.java:482)
> at java.base/sun.nio.ch.Net.connect(Net.java:474)
> at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:694)
> at java.base/java.nio.channels.SocketChannel.open(SocketChannel.java:194)
> at org.wildfly.iiop-openjdk@14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.security.SocketFactoryBase.createSocket(SocketFactoryBase.java:68)
> at org.wildfly.iiop-openjdk@14.0.0.CR1-SNAPSHOT//org.wildfly.iiop.openjdk.security.NoSSLSocketFactory.createSocket(NoSSLSocketFactory.java:59)
> at javax.orb.api(a)8.1.2.Final//com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:207)
> ... 236 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-11062) Missing "Multi-Release: true" in MANIFEST for multirelease jar infinispan-commons-9.3.3.Final-redhat-00001.jar
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-11062?page=com.atlassian.jira.plugin... ]
tommaso borgato moved JBEAP-15506 to WFLY-11062:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11062 (was: JBEAP-15506)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Productization)
Affects Version/s: (was: 7.2.0.CD14)
> Missing "Multi-Release: true" in MANIFEST for multirelease jar infinispan-commons-9.3.3.Final-redhat-00001.jar
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11062
> URL: https://issues.jboss.org/browse/WFLY-11062
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: tommaso borgato
> Assignee: Petr Sakař
>
> Project {{org.infinispan:infinispan-commons:9.3.3.Final}} contains classes specific for JDK-10.
> In the {{pom.xml}} file there is a {{jdk10-compile}} profile for the multi-release compilation.
> The MANIFEST in jar {{infinispan-commons-9.3.3.Final-redhat-00001.jar}} shipped with {{jboss-eap-7.2.0.CD14.CR1.zip}} does not contain line {{Multi-Release: true}}.
> Note this may be related to JBEAP-15502.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 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 updated JGRP-2296:
--------------------------------
Description:
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.sonatype.com.svc.cluster.local SRV
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.58.amzn1 <<>> jgroups.dev.auth.sonatype.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.sonatype.com.svc.cluster.local. IN SRV
;; ANSWER SECTION:
jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32921 9ec82e3f-3a0e-4e30-b785-17879c63cd7d.jgroups.dev.auth.sonatype.com.svc.cluster.local.
jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32923 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.sonatype.com.svc.cluster.local.
jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32915 9d9d78d0-8919-4b91-9df8-2e4e65afedae.jgroups.dev.auth.sonatype.com.svc.cluster.local.
jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32917 161f3d66-f1e3-46f4-a44f-ebda925a25c6.jgroups.dev.auth.sonatype.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.sonatype.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.
was:
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.sonatype.com.svc.cluster.local SRV
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.58.amzn1 <<>> jgroups.dev.auth.sonatype.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.sonatype.com.svc.cluster.local. IN SRV
;; ANSWER SECTION:
jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32921 9ec82e3f-3a0e-4e30-b785-17879c63cd7d.jgroups.dev.auth.sonatype.com.svc.cluster.local.
jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32923 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.sonatype.com.svc.cluster.local.
jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32915 9d9d78d0-8919-4b91-9df8-2e4e65afedae.jgroups.dev.auth.sonatype.com.svc.cluster.local.
jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32917 161f3d66-f1e3-46f4-a44f-ebda925a25c6.jgroups.dev.auth.sonatype.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.sonatype.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...
Let me know if I am missing any details. This is a major blocker for development.
> 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
>
> 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.sonatype.com.svc.cluster.local SRV
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.58.amzn1 <<>> jgroups.dev.auth.sonatype.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.sonatype.com.svc.cluster.local. IN SRV
> ;; ANSWER SECTION:
> jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32921 9ec82e3f-3a0e-4e30-b785-17879c63cd7d.jgroups.dev.auth.sonatype.com.svc.cluster.local.
> jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32923 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.sonatype.com.svc.cluster.local.
> jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32915 9d9d78d0-8919-4b91-9df8-2e4e65afedae.jgroups.dev.auth.sonatype.com.svc.cluster.local.
> jgroups.dev.auth.sonatype.com.svc.cluster.local. 10 IN SRV 1 1 32917 161f3d66-f1e3-46f4-a44f-ebda925a25c6.jgroups.dev.auth.sonatype.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.sonatype.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.5.0#75005)
7 years, 9 months
[JBoss JIRA] (SWSQE-428) Maistra Deploy Failing Checker
by Matt Mahoney (JIRA)
[ https://issues.jboss.org/browse/SWSQE-428?page=com.atlassian.jira.plugin.... ]
Matt Mahoney resolved SWSQE-428.
--------------------------------
Resolution: Done
> Maistra Deploy Failing Checker
> ------------------------------
>
> Key: SWSQE-428
> URL: https://issues.jboss.org/browse/SWSQE-428
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Matt Mahoney
> Assignee: Matt Mahoney
>
> The Maistra job called the 'checker' before istio-system had been created, thus the checker failed.
> Will need to add a retry on checking for the existence of istio-system namespace.
> + sh scripts/kiali/testscript.sh
> Checking if Istio is deployed Successfully and all pods are up.
> OS_HOSTNAME: mstr.cicd.osoos.centralci.eng.rdu2.********.com
> OS_USERNAME: user1
> OS_PASSWORD: ********
> OS_PORT: 8443
> KIALI: false
> BOOKINFO:
> Login to OS CLI...
> Istio-system project does not exist..exiting
> Build step 'Execute shell' marked build as failure
> Finished: FAILURE
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2522) [DMN Designer] Palette aesthetics
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2522?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-2522:
--------------------------------
Priority: Major (was: Minor)
> [DMN Designer] Palette aesthetics
> ---------------------------------
>
> Key: DROOLS-2522
> URL: https://issues.jboss.org/browse/DROOLS-2522
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: drools-tools
> Attachments: palette.png
>
>
> The palette css styling has changed. There appeared margins between items in palette, what is probably not problem, however even when user click to this margin (to space between two item in palette) still some palette item is selected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months