[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by Emond Papegaaij (Jira)
[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ]
Emond Papegaaij updated LOGMGR-263:
-----------------------------------
Attachment: ClassInEar.java
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.redhat.com/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, responsetimes.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by Emond Papegaaij (Jira)
[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ]
Emond Papegaaij updated LOGMGR-263:
-----------------------------------
Attachment: LogContextCacher.java
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.redhat.com/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, responsetimes.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by Emond Papegaaij (Jira)
[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ]
Emond Papegaaij commented on LOGMGR-263:
----------------------------------------
We are hitting this problem as well. In our application we see a lot of threads in {{getLogger}} (see attached stackdump). Many of these come from OpenSAML, where they use instance fields for loggers (or in some cases even create a new logger per log statement). See this link for more information on OpenSAML and the reason why they do logging like this: [SIDP-425|https://issues.shibboleth.net/jira/browse/SIDP-425?focusedCommen...] . The effect is that on a single SAML request, hundreds, if not thousands of loggers are instantiated.
To make things worse, the {{StackWalker}} seems to accumulate state on every call, making it slower over time. We see a steady increase in response times over time (see attached graph). This increase continues until a full GC runs, after which the response times return to normal. The entire delta (from less than 100ms to over 1s) is caused by logger lookups.
For now, we've developed a workaround for this issue by setting the {{LogContext}} at the beginning of the request and clearing it at the end (classes attached). This reduces the number of stack walks to one. This workaround also shows a severe weakness in the stack walking approach. When {{LogContextCacher}} is deployed in a war inside an ear, the call stack only contains stack frames in WildFly and Undertow and 1 frame in {{LogContextCacher}}. The {{LogContext}} that it should resolve is registered for the ear classloader. However, because none of the stack frames touch code in the ear classloader, it doesn't find this {{LogContext}} and returns the {{SYSTEM_CONTEXT}}. The parent classloader of a war deployment inside an ear is the {{jdk.internal.loader.ClassLoaders$AppClassLoader}}, not the ear classloader.
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.redhat.com/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, responsetimes.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by Emond Papegaaij (Jira)
[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ]
Emond Papegaaij updated LOGMGR-263:
-----------------------------------
Attachment: responsetimes.png
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.redhat.com/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, responsetimes.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by Emond Papegaaij (Jira)
[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ]
Emond Papegaaij updated LOGMGR-263:
-----------------------------------
Attachment: getlogger-stack.txt
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.redhat.com/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13128) Add a Galleon layer for batch-jberet
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13128:
---------------------------------------
Summary: Add a Galleon layer for batch-jberet
Key: WFLY-13128
URL: https://issues.redhat.com/browse/WFLY-13128
Project: WildFly
Issue Type: Feature Request
Components: Batch
Reporter: Brian Stansberry
Assignee: Brian Stansberry
I saw a community request for a Galleon layer for batch-jberet so let's make it first in the set we add to complete coverage of the various subsystems.
Besides the usual layer smoke tests, we can provision a cloud-server+batch-jberet server in testsuite/integration/basic and run most of the batch tests there against it. There are 4 that won't run because they use EJB, Agroal or the org.jboss.remoting3 module, none of which would be provisioned.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13127) NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13127?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13127:
-----------------------------------------
[~pferraro] [~maeste] [~kenfinni] [~jmesnil] [~lthon] [~michael.edgar]
Upgrading to smallrye openapi 1.2.0 fixes this problem, but I don't know if that is safe. In particular the changelog for 1.2.0 has this minor version bump in the smallrye config version (1.4.1 to 1.5.0):
https://github.com/smallrye/smallrye-open-api/pull/229
WildFly is still on 1.4.1, and the code diff from 1.4.1 to 1.5.0 seems fairly significant.
Any thoughts on this? Sorry to spam the world. :)
I tossed up https://github.com/wildfly/wildfly/pull/13014 just to see what WildFly CI thinks but it may not uncover important issues.
> NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
> --------------------------------------------------------------------
>
> Key: WFLY-13127
> URL: https://issues.redhat.com/browse/WFLY-13127
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI, MP OpenTracing
> Affects Versions: 19.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Critical
>
> I tried running the microprofile-tck/opentracing tests against a config that included the OpenAPI subsystem. It failed with an NPE:
> {code}
> 2020-02-18 16:36:53,302 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly/testsuite/integration/microprofile-tck/opentracing/target/wildfly/standalone/data/content/85/48e223eb8bfcd73f66458e14a0bbc425998a70/content
> 2020-02-18 16:36:53,313 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "opentracing.war" (runtime-name: "opentracing.war")
> 2020-02-18 16:36:54,020 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment opentracing.war
> 2020-02-18 16:36:54,114 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-7) HV000001: Hibernate Validator 6.0.18.Final
> 2020-02-18 16:36:54,330 INFO [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 3.1.3 (Final)
> 2020-02-18 16:36:54,576 INFO [io.smallrye.metrics] (MSC service thread 1-5) MicroProfile: Metrics activated (SmallRye Metrics version: 2.4.0)
> 2020-02-18 16:36:54,992 WARN [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0101: Duplicate servlet mapping /rest/* found
> 2020-02-18 16:36:55,173 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.undertow.host.default-server.default-host./openapi: org.jboss.msc.service.StartException in service org.wildfly.undertow.host.default-server.default-host./openapi: java.lang.NullPointerException
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:934)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.scan(OpenApiAnnotationScanner.java:221)
> at io.smallrye.openapi.runtime.OpenApiProcessor.modelFromAnnotations(OpenApiProcessor.java:72)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:173)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:94)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
> ... 8 more
> {code}
> I hit this when working on WFLY-13099. I was using a standalone.xml variant equivalent to what Galleon would generate using the cloud-server, h2-default-datasource, microprofile-fault-tolerance, microprofile-jwt and microprofile-openapi layers. It wasn't a slimmed server though.
> OpenApiAnnotationScanner L934 seems to assume 'schema' will not be null. But the 'SchemaFactory.typeToSchema' method seems like it's written such that returning null is a possibility; e.g. L362 in the final 'else' block is doing a null check on the 'schema' var whose value is ultimately returned. (I don't see how else the NPE would happen other than SchemaFactory.typeToSchema returning null.)
>
> I put Critical severity on this because I don't know anything about opentracing.war; i.e. whether it's written in a way that would be a real corner case for OpenAPI. I'm being conservative and assigning a high priority.
> [~ehugonnet] FYI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13127) NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13127?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13127:
-----------------------------------------
This is https://github.com/smallrye/smallrye-open-api/issues/248 fixed in smallrye openapi 1.2.0.
> NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
> --------------------------------------------------------------------
>
> Key: WFLY-13127
> URL: https://issues.redhat.com/browse/WFLY-13127
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI, MP OpenTracing
> Affects Versions: 19.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Critical
>
> I tried running the microprofile-tck/opentracing tests against a config that included the OpenAPI subsystem. It failed with an NPE:
> {code}
> 2020-02-18 16:36:53,302 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly/testsuite/integration/microprofile-tck/opentracing/target/wildfly/standalone/data/content/85/48e223eb8bfcd73f66458e14a0bbc425998a70/content
> 2020-02-18 16:36:53,313 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "opentracing.war" (runtime-name: "opentracing.war")
> 2020-02-18 16:36:54,020 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment opentracing.war
> 2020-02-18 16:36:54,114 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-7) HV000001: Hibernate Validator 6.0.18.Final
> 2020-02-18 16:36:54,330 INFO [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 3.1.3 (Final)
> 2020-02-18 16:36:54,576 INFO [io.smallrye.metrics] (MSC service thread 1-5) MicroProfile: Metrics activated (SmallRye Metrics version: 2.4.0)
> 2020-02-18 16:36:54,992 WARN [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0101: Duplicate servlet mapping /rest/* found
> 2020-02-18 16:36:55,173 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.undertow.host.default-server.default-host./openapi: org.jboss.msc.service.StartException in service org.wildfly.undertow.host.default-server.default-host./openapi: java.lang.NullPointerException
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:934)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.scan(OpenApiAnnotationScanner.java:221)
> at io.smallrye.openapi.runtime.OpenApiProcessor.modelFromAnnotations(OpenApiProcessor.java:72)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:173)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:94)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
> ... 8 more
> {code}
> I hit this when working on WFLY-13099. I was using a standalone.xml variant equivalent to what Galleon would generate using the cloud-server, h2-default-datasource, microprofile-fault-tolerance, microprofile-jwt and microprofile-openapi layers. It wasn't a slimmed server though.
> OpenApiAnnotationScanner L934 seems to assume 'schema' will not be null. But the 'SchemaFactory.typeToSchema' method seems like it's written such that returning null is a possibility; e.g. L362 in the final 'else' block is doing a null check on the 'schema' var whose value is ultimately returned. (I don't see how else the NPE would happen other than SchemaFactory.typeToSchema returning null.)
>
> I put Critical severity on this because I don't know anything about opentracing.war; i.e. whether it's written in a way that would be a real corner case for OpenAPI. I'm being conservative and assigning a high priority.
> [~ehugonnet] FYI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13127) NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13127?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13127:
-----------------------------------------
Same problem when OpenAPI is in the config when running the JWT TCK:
{code}
2020-02-18 18:46:21,104 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0003: Processing weld deployment IssValidationTest.war
2020-02-18 18:46:21,185 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-5) HV000001: Hibernate Validator 6.0.18.Final
2020-02-18 18:46:21,390 INFO [io.jaegertracing.internal.JaegerTracer] (MSC service thread 1-5) No shutdown hook registered: Please call close() manually on application shutdown.
2020-02-18 18:46:21,442 INFO [org.jboss.weld.Version] (MSC service thread 1-3) WELD-000900: 3.1.3 (Final)
2020-02-18 18:46:21,713 INFO [io.smallrye.metrics] (MSC service thread 1-5) MicroProfile: Metrics activated (SmallRye Metrics version: 2.4.0)
2020-02-18 18:46:22,257 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 58) Initializing Soteria 1.0.1-jbossorg-1 for context ''
2020-02-18 18:46:22,405 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service org.wildfly.undertow.host.default-server.default-host./openapi: org.jboss.msc.service.StartException in service org.wildfly.undertow.host.default-server.default-host./openapi: java.lang.NullPointerException
at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:934)
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.scan(OpenApiAnnotationScanner.java:221)
at io.smallrye.openapi.runtime.OpenApiProcessor.modelFromAnnotations(OpenApiProcessor.java:72)
at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:173)
at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:94)
at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
... 8 more
{code}
> NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
> --------------------------------------------------------------------
>
> Key: WFLY-13127
> URL: https://issues.redhat.com/browse/WFLY-13127
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI, MP OpenTracing
> Affects Versions: 19.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Critical
>
> I tried running the microprofile-tck/opentracing tests against a config that included the OpenAPI subsystem. It failed with an NPE:
> {code}
> 2020-02-18 16:36:53,302 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly/testsuite/integration/microprofile-tck/opentracing/target/wildfly/standalone/data/content/85/48e223eb8bfcd73f66458e14a0bbc425998a70/content
> 2020-02-18 16:36:53,313 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "opentracing.war" (runtime-name: "opentracing.war")
> 2020-02-18 16:36:54,020 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment opentracing.war
> 2020-02-18 16:36:54,114 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-7) HV000001: Hibernate Validator 6.0.18.Final
> 2020-02-18 16:36:54,330 INFO [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 3.1.3 (Final)
> 2020-02-18 16:36:54,576 INFO [io.smallrye.metrics] (MSC service thread 1-5) MicroProfile: Metrics activated (SmallRye Metrics version: 2.4.0)
> 2020-02-18 16:36:54,992 WARN [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0101: Duplicate servlet mapping /rest/* found
> 2020-02-18 16:36:55,173 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.undertow.host.default-server.default-host./openapi: org.jboss.msc.service.StartException in service org.wildfly.undertow.host.default-server.default-host./openapi: java.lang.NullPointerException
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:934)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.scan(OpenApiAnnotationScanner.java:221)
> at io.smallrye.openapi.runtime.OpenApiProcessor.modelFromAnnotations(OpenApiProcessor.java:72)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:173)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:94)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
> ... 8 more
> {code}
> I hit this when working on WFLY-13099. I was using a standalone.xml variant equivalent to what Galleon would generate using the cloud-server, h2-default-datasource, microprofile-fault-tolerance, microprofile-jwt and microprofile-openapi layers. It wasn't a slimmed server though.
> OpenApiAnnotationScanner L934 seems to assume 'schema' will not be null. But the 'SchemaFactory.typeToSchema' method seems like it's written such that returning null is a possibility; e.g. L362 in the final 'else' block is doing a null check on the 'schema' var whose value is ultimately returned. (I don't see how else the NPE would happen other than SchemaFactory.typeToSchema returning null.)
>
> I put Critical severity on this because I don't know anything about opentracing.war; i.e. whether it's written in a way that would be a real corner case for OpenAPI. I'm being conservative and assigning a high priority.
> [~ehugonnet] FYI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13127) NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13127:
---------------------------------------
Summary: NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
Key: WFLY-13127
URL: https://issues.redhat.com/browse/WFLY-13127
Project: WildFly
Issue Type: Bug
Components: MP OpenAPI, MP OpenTracing
Affects Versions: 19.0.0.Beta2
Reporter: Brian Stansberry
Assignee: Paul Ferraro
I tried running the microprofile-tck/opentracing tests against a config that included the OpenAPI subsystem. It failed with an NPE:
{code}
2020-02-18 16:36:53,302 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly/testsuite/integration/microprofile-tck/opentracing/target/wildfly/standalone/data/content/85/48e223eb8bfcd73f66458e14a0bbc425998a70/content
2020-02-18 16:36:53,313 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "opentracing.war" (runtime-name: "opentracing.war")
2020-02-18 16:36:54,020 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment opentracing.war
2020-02-18 16:36:54,114 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-7) HV000001: Hibernate Validator 6.0.18.Final
2020-02-18 16:36:54,330 INFO [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 3.1.3 (Final)
2020-02-18 16:36:54,576 INFO [io.smallrye.metrics] (MSC service thread 1-5) MicroProfile: Metrics activated (SmallRye Metrics version: 2.4.0)
2020-02-18 16:36:54,992 WARN [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0101: Duplicate servlet mapping /rest/* found
2020-02-18 16:36:55,173 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.undertow.host.default-server.default-host./openapi: org.jboss.msc.service.StartException in service org.wildfly.undertow.host.default-server.default-host./openapi: java.lang.NullPointerException
at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:934)
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.scan(OpenApiAnnotationScanner.java:221)
at io.smallrye.openapi.runtime.OpenApiProcessor.modelFromAnnotations(OpenApiProcessor.java:72)
at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:173)
at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:94)
at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
... 8 more
{code}
I hit this when working on WFLY-13099. I was using a standalone.xml variant equivalent to what Galleon would generate using the cloud-server, h2-default-datasource, microprofile-fault-tolerance, microprofile-jwt and microprofile-openapi layers. It wasn't a slimmed server though.
OpenApiAnnotationScanner L934 seems to assume 'schema' will not be null. But the 'SchemaFactory.typeToSchema' method seems like it's written such that returning null is a possibility; e.g. L362 in the final 'else' block is doing a null check on the 'schema' var whose value is ultimately returned. (I don't see how else the NPE would happen other than SchemaFactory.typeToSchema returning null.)
I put Critical severity on this because I don't know anything about opentracing.war; i.e. whether it's written in a way that would be a real corner case for OpenAPI. I'm being conservative and assigning a high priority.
[~ehugonnet] FYI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months