[JBoss JIRA] (JGRP-2300) DNS_PING in AWS ECS cannot cluster with dynamic port mappings
by Sebastian Łaskawiec (Jira)
[ https://issues.jboss.org/browse/JGRP-2300?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed JGRP-2300.
-------------------------------------
Release Notes Text: Duplicate of JGRP-2316
Resolution: Duplicate Issue
> DNS_PING in AWS ECS cannot cluster with dynamic port mappings
> -------------------------------------------------------------
>
> Key: JGRP-2300
> URL: https://issues.jboss.org/browse/JGRP-2300
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.16
> Environment: AWS ECS Cluster with DNS based service discovery using jboss/keycloak:latest containers
> Reporter: Eric Thompson
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Fix For: 4.0.16
>
>
> When running an ECS cluster with jboss/keycloak:latest containers dynamic port mapping of all ports is required to allow more than one container to run per EC2 instance. Using SRV based service discovery records will allow each node to find the rest of the nodes, but when a discovery request is sent the receiving node sees the sender as IP:7600 instead of the dynamic port. It then sees this as a "new" node and tries to send discovery requests to it. And somehow it is also getting node IDs and trying to send requests to those!
> See the following log, there are only 4 actual nodes and the each have a different 5 digit port number:
> {code}
> ### Service discovery with dynamic port mapping
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) Performing discovery of the following hosts [10.42.3.44:7600, 10.42.3.56:32949, 10.42.3.56:32951, 10.42.3.44:32954, c5b479b7b6d5, 10.42.3.44:32952, 10.42.3.56:7600, 17081c624290, 63976b7fae70, 557cbd7891a2]
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:7600
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32949
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32951
> 2018-10-10 20:17:44,180 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32954
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to c5b479b7b6d5
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32952
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 17081c624290
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-238,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 63976b7fae70
> 2018-10-10 20:17:44,183 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 557cbd7891a2
> 2018-10-10 20:17:44,187 WARN [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,17081c624290) JGRP000032: 17081c624290: no physical address for c5b479b7b6d5, dropping message
> {code}
> This code seems to be part of the problem in this case: https://github.com/belaban/JGroups/blob/87d15ec848aa3d482ae792ef152f7e36e...
> See that code uses the incoming address and adds it to the discocvered_hosts, but those addresses are ALWAYS inaccurate in this case.
> Because this is what the recipient of the service discovery request sees (ie: all the ports are the default 7600):
> {code}
> 2018-10-10 20:35:15,229 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,231 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,232 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,233 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,234 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,236 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,239 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,240 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,242 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,243 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,246 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,249 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,252 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,255 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,256 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> {code}
> In this state the cluster never seems to work properly and the Keycloak interface breaks in many frustrating ways.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Sebastian Łaskawiec (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on JGRP-2316:
-------------------------------------------
[~belaban] This behavior is possible for example with AWS DNS Service. In JGRP-2300, one of the users reported such a behavior, that the DNS Service dynamically remaps the ports. Here's an example DNS SRV response:
{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}
We also have a pull request to fix this: https://github.com/belaban/JGroups/pull/409. Let me close the other issue (JGRP-2300) since this one has more information and a pull request.
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10929) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-10929?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFLY-10929:
--------------------------------------
Steps to Reproduce:
# unzip WildFly and start via ./bin/standalone.sh
# in CLI perform following operations:
{code}
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:write-attribute(name=use-server-log, value=false)
deploy helloworld.war
reload
{code}
# Now try to access WildFly server:
{code}
# First against HTTP listener:
curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
# Check result in access log
# Now try against HTTPS listener:
curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
# Check result in access log
{code}
was:
# unzip WildFly and start via ./bin/standalone.sh
# in CLI perform following operations:
{code}
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:write-attribute(name=use-server-log, value=true)
deploy helloworld.war
reload
{code}
# Now try to access WildFly server:
{code}
# First against HTTP listener:
curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
# Check result in access log
# Now try against HTTPS listener:
curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
# Check result in access log
{code}
> Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10929
> URL: https://issues.jboss.org/browse/WFLY-10929
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: helloworld.war
>
>
> Since the time of {{EAP7.1.1.CP}} there is a possibility to allow unescaped characters in URL requests from clients to server. This was allowed first by setting {{org.wildfly.undertow.ALLOW_UNESCAPED_CHARACTERS_IN_URL=true}} system property introduced by UNDERTOW-1185. Now we have a new attribute for this in Wildfly in AJP, HTTP and HTTPS listeners {{allow-unescaped-characters-in-url}}.
> However this does not seem to work correctly. There have been some fixes for AJP listener already UNDERTOW-1386, UNDERTOW-1386 and UNDERTOW-1399 (the last one not included in WildFly {{14.0.0.Beta2}} yet). However HTTP/HTTPS listener seems to be broken too.
> When HTTP request with unescaped characters is performed against server:
> {code}
> curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
> {code}
> we get 200 OK HTTP response, although the result in access log looks like:
> {code:title=HTTP actual result}
> 127.0.0.1 - - [27/Aug/2018:09:17:39 +0200] "GET /helloworld/íê¸ì´ë¦
> _test.html?param=íê¸ì´ë¦
> _ahoy HTTP/1.1" 200 950
> {code}
> but we expect following:
> {code:title=HTTP expected result}
> 127.0.0.1 - - [27/Aug/2018:08:40:47 +0200] "GET /helloworld/한글이름_test.html?param=한글이름_ahoy HTTP/1.1" 200 950
> {code}
> Slightly different problem seems to be also for HTTPS listener. When we perform HTTPS request against WildFly:
> {code}
> curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
> {code}
> we receive 404 Not Found HTTP response and following record in access.log:
> {code:HTTPS actual result}
> 127.0.0.1 - - [27/Aug/2018:09:18:37 +0200] "GET /helloworld/￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_test.html?param=￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_ahoy HTTP/2.0" 404 68
> {code}
> however expected result should be similar to what we expect for HTTP, I guess.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11432) EAR (WAR + EJB JAR) fails to be deployed with CNFE from open tracing
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11432?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-11432:
--------------------------------------
[~jstourac] PR is provided, if you feel like this should target CR1 release, please set the fix version accordingly.
> EAR (WAR + EJB JAR) fails to be deployed with CNFE from open tracing
> --------------------------------------------------------------------
>
> Key: WFLY-11432
> URL: https://issues.jboss.org/browse/WFLY-11432
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Final, 15.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Matej Novotny
> Priority: Critical
>
> Upon deployment of an example app from weld examples, there is CNFE from open tracing during the deployment of an EAR (WAR + EJB JAR) artifact. [~manovotn] has already done some investigation and sent his findings to [wildfly-dev mailing list|http://lists.jboss.org/pipermail/wildfly-dev/2018-November/006716.html].
> Problematic Weld example test is [this one|https://github.com/weld/core/blob/master/examples/jsf/translator/ftes...].
> {code}
> 2018-11-28 14:35:36,063 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."weld-translator.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."weld-translator.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> 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)
> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error while loading class org.wildfly.microprofile.opentracing.smallrye.TracerProducer$Proxy$_$$_WeldSubclass
> at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:186)
> at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:194)
> at org.jboss.weld.resources.ClassTransformer.getEnhancedAnnotatedType(ClassTransformer.java:232)
> at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:86)
> at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.<init>(SubclassedComponentInstantiator.java:79)
> at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.forInterceptedDecoratedBean(SubclassedComponentInstantiator.java:63)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:121)
> at org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
> at org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:63)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:475)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:86)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:97)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> ... 6 more
> Caused by: java.lang.NoClassDefFoundError: io/opentracing/Tracer
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.getDeclaredMethods(Class.java:1975)
> at org.jboss.weld.annotated.slim.backed.SecurityActions.getDeclaredMethods(SecurityActions.java:41)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:197)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:191)
> at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:46)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$EagerlyInitializedLazyValueHolder.<init>(BackedAnnotatedType.java:159)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:191)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:191)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.<init>(BackedAnnotatedType.java:66)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.of(BackedAnnotatedType.java:47)
> at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.apply(ClassTransformer.java:84)
> at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.apply(ClassTransformer.java:79)
> at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.lambda$null$0(ReentrantMapBackedComputingCache.java:55)
> at org.jboss.weld.util.WeakLazyValueHolder$1.computeValue(WeakLazyValueHolder.java:35)
> at org.jboss.weld.util.WeakLazyValueHolder.get(WeakLazyValueHolder.java:53)
> at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.getValue(ReentrantMapBackedComputingCache.java:72)
> at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.getCastValue(ReentrantMapBackedComputingCache.java:78)
> at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:177)
> ... 19 more
> Caused by: java.lang.ClassNotFoundException: io.opentracing.Tracer from [Module "deployment.weld-translator.ear" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> ... 39 more
> 2018-11-28 14:35:36,073 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "weld-translator.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"weld-translator.ear\".WeldStartService" => "Failed to start service
> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error while loading class org.wildfly.microprofile.opentracing.smallrye.TracerProducer$Proxy$_$$_WeldSubclass
> Caused by: java.lang.NoClassDefFoundError: io/opentracing/Tracer
> Caused by: java.lang.ClassNotFoundException: io.opentracing.Tracer from [Module \"deployment.weld-translator.ear\" from Service Module Loader]"}}
> 2018-11-28 14:35:36,076 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "weld-translator.ear" was rolled back with the following failure message:
> {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"weld-translator.ear\".WeldStartService" => "Failed to start service
> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error while loading class org.wildfly.microprofile.opentracing.smallrye.TracerProducer$Proxy$_$$_WeldSubclass
> Caused by: java.lang.NoClassDefFoundError: io/opentracing/Tracer
> Caused by: java.lang.ClassNotFoundException: io.opentracing.Tracer from [Module \"deployment.weld-translator.ear\" from Service Module Loader]"}}
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11432) EAR (WAR + EJB JAR) fails to be deployed with CNFE from open tracing
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11432?page=com.atlassian.jira.plugin... ]
Matej Novotny updated WFLY-11432:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/11902
> EAR (WAR + EJB JAR) fails to be deployed with CNFE from open tracing
> --------------------------------------------------------------------
>
> Key: WFLY-11432
> URL: https://issues.jboss.org/browse/WFLY-11432
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Final, 15.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Matej Novotny
> Priority: Critical
>
> Upon deployment of an example app from weld examples, there is CNFE from open tracing during the deployment of an EAR (WAR + EJB JAR) artifact. [~manovotn] has already done some investigation and sent his findings to [wildfly-dev mailing list|http://lists.jboss.org/pipermail/wildfly-dev/2018-November/006716.html].
> Problematic Weld example test is [this one|https://github.com/weld/core/blob/master/examples/jsf/translator/ftes...].
> {code}
> 2018-11-28 14:35:36,063 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."weld-translator.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."weld-translator.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> 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)
> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error while loading class org.wildfly.microprofile.opentracing.smallrye.TracerProducer$Proxy$_$$_WeldSubclass
> at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:186)
> at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:194)
> at org.jboss.weld.resources.ClassTransformer.getEnhancedAnnotatedType(ClassTransformer.java:232)
> at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:86)
> at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.<init>(SubclassedComponentInstantiator.java:79)
> at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.forInterceptedDecoratedBean(SubclassedComponentInstantiator.java:63)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:121)
> at org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
> at org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:63)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:475)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:86)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:97)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> ... 6 more
> Caused by: java.lang.NoClassDefFoundError: io/opentracing/Tracer
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.getDeclaredMethods(Class.java:1975)
> at org.jboss.weld.annotated.slim.backed.SecurityActions.getDeclaredMethods(SecurityActions.java:41)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:197)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:191)
> at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:46)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$EagerlyInitializedLazyValueHolder.<init>(BackedAnnotatedType.java:159)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:191)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:191)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.<init>(BackedAnnotatedType.java:66)
> at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.of(BackedAnnotatedType.java:47)
> at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.apply(ClassTransformer.java:84)
> at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.apply(ClassTransformer.java:79)
> at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.lambda$null$0(ReentrantMapBackedComputingCache.java:55)
> at org.jboss.weld.util.WeakLazyValueHolder$1.computeValue(WeakLazyValueHolder.java:35)
> at org.jboss.weld.util.WeakLazyValueHolder.get(WeakLazyValueHolder.java:53)
> at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.getValue(ReentrantMapBackedComputingCache.java:72)
> at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.getCastValue(ReentrantMapBackedComputingCache.java:78)
> at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:177)
> ... 19 more
> Caused by: java.lang.ClassNotFoundException: io.opentracing.Tracer from [Module "deployment.weld-translator.ear" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> ... 39 more
> 2018-11-28 14:35:36,073 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "weld-translator.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"weld-translator.ear\".WeldStartService" => "Failed to start service
> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error while loading class org.wildfly.microprofile.opentracing.smallrye.TracerProducer$Proxy$_$$_WeldSubclass
> Caused by: java.lang.NoClassDefFoundError: io/opentracing/Tracer
> Caused by: java.lang.ClassNotFoundException: io.opentracing.Tracer from [Module \"deployment.weld-translator.ear\" from Service Module Loader]"}}
> 2018-11-28 14:35:36,076 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "weld-translator.ear" was rolled back with the following failure message:
> {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"weld-translator.ear\".WeldStartService" => "Failed to start service
> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error while loading class org.wildfly.microprofile.opentracing.smallrye.TracerProducer$Proxy$_$$_WeldSubclass
> Caused by: java.lang.NoClassDefFoundError: io/opentracing/Tracer
> Caused by: java.lang.ClassNotFoundException: io.opentracing.Tracer from [Module \"deployment.weld-translator.ear\" from Service Module Loader]"}}
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3387) Update interaction behavior to align with DMN/Stunner.
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3387?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3387:
--------------------------------------
[~uxdlc], looks good to me. If the single click to select a cell will be different from the single click to launch a pop-over (one will be a right click and the other a left click), I think it is sufficient.
> Update interaction behavior to align with DMN/Stunner.
> -------------------------------------------------------
>
> Key: DROOLS-3387
> URL: https://issues.jboss.org/browse/DROOLS-3387
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Daniele Zonca
> Priority: Major
> Labels: UX, UXTeam
>
> Align grid interactions to be consistent with DMN updates:
> - Single-click to select a cell
> - double-click to edit a cell inline.
> - single click to launch a pop-over menu.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10929) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-10929?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFLY-10929:
--------------------------------------
Steps to Reproduce:
# unzip WildFly and start via ./bin/standalone.sh
# in CLI perform following operations:
{code}
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:write-attribute(name=use-server-log, value=true)
deploy helloworld.war
reload
{code}
# Now try to access WildFly server:
{code}
# First against HTTP listener:
curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
# Check result in access log
# Now try against HTTPS listener:
curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
# Check result in access log
{code}
was:
# unzip WildFly and start via ./bin/standalone.sh
# in CLI perform following operations:
{code}
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add(use-server-log=true)
deploy helloworld.war
reload
{code}
# Now try to access WildFly server:
{code}
# First against HTTP listener:
curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
# Check result in access log
# Now try against HTTPS listener:
curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
# Check result in access log
{code}
> Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10929
> URL: https://issues.jboss.org/browse/WFLY-10929
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: helloworld.war
>
>
> Since the time of {{EAP7.1.1.CP}} there is a possibility to allow unescaped characters in URL requests from clients to server. This was allowed first by setting {{org.wildfly.undertow.ALLOW_UNESCAPED_CHARACTERS_IN_URL=true}} system property introduced by UNDERTOW-1185. Now we have a new attribute for this in Wildfly in AJP, HTTP and HTTPS listeners {{allow-unescaped-characters-in-url}}.
> However this does not seem to work correctly. There have been some fixes for AJP listener already UNDERTOW-1386, UNDERTOW-1386 and UNDERTOW-1399 (the last one not included in WildFly {{14.0.0.Beta2}} yet). However HTTP/HTTPS listener seems to be broken too.
> When HTTP request with unescaped characters is performed against server:
> {code}
> curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
> {code}
> we get 200 OK HTTP response, although the result in access log looks like:
> {code:title=HTTP actual result}
> 127.0.0.1 - - [27/Aug/2018:09:17:39 +0200] "GET /helloworld/íê¸ì´ë¦
> _test.html?param=íê¸ì´ë¦
> _ahoy HTTP/1.1" 200 950
> {code}
> but we expect following:
> {code:title=HTTP expected result}
> 127.0.0.1 - - [27/Aug/2018:08:40:47 +0200] "GET /helloworld/한글이름_test.html?param=한글이름_ahoy HTTP/1.1" 200 950
> {code}
> Slightly different problem seems to be also for HTTPS listener. When we perform HTTPS request against WildFly:
> {code}
> curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
> {code}
> we receive 404 Not Found HTTP response and following record in access.log:
> {code:HTTPS actual result}
> 127.0.0.1 - - [27/Aug/2018:09:18:37 +0200] "GET /helloworld/￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_test.html?param=￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_ahoy HTTP/2.0" 404 68
> {code}
> however expected result should be similar to what we expect for HTTP, I guess.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3385) Stateful session is not thread safe for update operation on JDK11
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3385?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-3385:
--------------------------------
Sprint: 2018 Week 48-50
> Stateful session is not thread safe for update operation on JDK11
> -----------------------------------------------------------------
>
> Key: DROOLS-3385
> URL: https://issues.jboss.org/browse/DROOLS-3385
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.16.0.Final
> Reporter: Radovan Synek
> Assignee: Mario Fusco
> Priority: Critical
>
> We have a test failure in multithreaded solving in OptaPlanner (please see the linked issue for details). Interestingly, it happens only with JDK11.
> java.util.ConcurrentModificationException: null
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1134)
> at org.drools.core.impl.KnowledgeBaseImpl.getOrCreateExactTypeDeclaration(KnowledgeBaseImpl.java:1458)
> at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:324)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1570)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:254)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months