[JBoss JIRA] (WFLY-11036) Shutdown hangs if WAR is distributable and uses SSE
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-11036?page=com.atlassian.jira.plugin... ]
Paul Ferraro edited comment on WFLY-11036 at 11/6/18 8:55 AM:
--------------------------------------------------------------
The fix for WFLY-7695 added a lifecycle lock to the distributed session manager that would block shutdown until all sessions are closed. However, this has adverse effect on long running async contexts.
We should drop this overeager locking and defer to Infinispan's transaction table to perform the requisite graceful shutdown behavior.
was (Author: pferraro):
The fix for WFLY-7695 added a lifecycle lock to the distributed session manager that would block shutdown until all sessions are closed. However, this has adverse effect on long running async contexts.
> Shutdown hangs if WAR is distributable and uses SSE
> ---------------------------------------------------
>
> Key: WFLY-11036
> URL: https://issues.jboss.org/browse/WFLY-11036
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 14.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: wfly-11036-0.0.1-SNAPSHOT.war, wfly-11036-src.zip
>
>
> I have an application (WAR) that uses server-sent events (as standardized in JAX-RS 2.1). The application is also marked as <distributable/> in web.xml. If anything actually opens a SSE channel, WildFly hangs during shutdown.
> The culprit appears to be DistributableSessionManager. See the below thread dump, taken during a hung shutdown. DSM is coded to wait up to getDefaultMaxInactiveInterval() seconds in its stop() method, and the default is 30 minutes unless configured otherwise. That's why shutdown hangs, although I don't know what it's waiting for.
> If I remove <distributable/> from web.xml, shutdown happens normally.
> {code}
> "ServerService Thread Pool -- 45" #154 prio=5 os_prio=0 tid=0x000000002bc1a800 nid=0x115e8 waiting on condition [0x0000000035c5e000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fb4bcc98> (a java.util.concurrent.locks.StampedLock)
> at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
> at java.util.concurrent.locks.StampedLock.tryWriteLock(StampedLock.java:394)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:98)
> - locked <0x00000000fb446c70> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:617)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:607)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:621)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:135)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:117)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Locked ownable synchronizers:
> - None
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ELY-1708) java.lang.NoSuchFieldError: state on jdk 1.8.0_191
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/ELY-1708?page=com.atlassian.jira.plugin.s... ]
Martin Choma closed ELY-1708.
-----------------------------
Resolution: Done
It was test issue. Upgrade of alpn in testsuite [1] helped in this case.
[1] https://mvnrepository.com/artifact/org.mortbay.jetty.alpn/alpn-boot/8.1.1...
> java.lang.NoSuchFieldError: state on jdk 1.8.0_191
> --------------------------------------------------
>
> Key: ELY-1708
> URL: https://issues.jboss.org/browse/ELY-1708
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.7.0.CR3
> Reporter: Martin Choma
> Priority: Blocker
>
> - on oracle/openjdk java version "1.8.0_181" it was ok on oracle/openjdk java version "1.8.0_191" it fails
> - I have checked oracle jdk 1.8.0_191 release notes and this seems relevant to this issue https://bugs.java.com/view_bug.do?bug_id=JDK-8074462
> - problem posted on openjdk mailing list security-dev http://mail.openjdk.java.net/pipermail/security-dev/2018-November/018667....
> - I have seen so far only in FIPS TS (BC and PKCS11)
> - I dont see on oracle/openjdk jdk 11
> - I have reported to oracle but get no link to issue tracker back. They just told me "We will contact you if needed" :)
> - similar problem https://youtrack.jetbrains.com/issue/JT-49978
> {noformat}
> 21:19:11 java.lang.NoSuchFieldError: state
> 21:19:11 at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:198)
> 21:19:11 at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> 21:19:11 at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> 21:19:11 at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> 21:19:11 at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> 21:19:11 at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> 21:19:11 at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> 21:19:11 at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
> 21:19:11 at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11036) Shutdown hangs if WAR is distributable and uses SSE
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-11036?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-11036:
-------------------------------------
The fix for WFLY-7695 added a lifecycle lock to the distributed session manager that would block shutdown until all sessions are closed. However, this has adverse effect on long running async contexts.
> Shutdown hangs if WAR is distributable and uses SSE
> ---------------------------------------------------
>
> Key: WFLY-11036
> URL: https://issues.jboss.org/browse/WFLY-11036
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 14.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: wfly-11036-0.0.1-SNAPSHOT.war, wfly-11036-src.zip
>
>
> I have an application (WAR) that uses server-sent events (as standardized in JAX-RS 2.1). The application is also marked as <distributable/> in web.xml. If anything actually opens a SSE channel, WildFly hangs during shutdown.
> The culprit appears to be DistributableSessionManager. See the below thread dump, taken during a hung shutdown. DSM is coded to wait up to getDefaultMaxInactiveInterval() seconds in its stop() method, and the default is 30 minutes unless configured otherwise. That's why shutdown hangs, although I don't know what it's waiting for.
> If I remove <distributable/> from web.xml, shutdown happens normally.
> {code}
> "ServerService Thread Pool -- 45" #154 prio=5 os_prio=0 tid=0x000000002bc1a800 nid=0x115e8 waiting on condition [0x0000000035c5e000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fb4bcc98> (a java.util.concurrent.locks.StampedLock)
> at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
> at java.util.concurrent.locks.StampedLock.tryWriteLock(StampedLock.java:394)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:98)
> - locked <0x00000000fb446c70> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:617)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:607)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:621)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:135)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:117)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Locked ownable synchronizers:
> - None
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFWIP-125) Logging to stdout/stderr, missing IDs for messages
by Rostislav Svoboda (Jira)
[ https://issues.jboss.org/browse/WFWIP-125?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda commented on WFWIP-125:
-----------------------------------------
Compiled finally.
{code}
14:39:31,274 INFO [org.wildfly.extension.microprofile.metrics.smallrye] (ServerService Thread Pool -- 60) WFLYMETRICS0001: Activating Eclipse MicroProfile Metrics Subsystem
...
14:39:31,295 INFO [io.smallrye.metrics] (MSC service thread 1-4) Converted [2] config entries and added [4] replacements
14:39:31,299 INFO [io.smallrye.metrics] (MSC service thread 1-4) Converted [3] config entries and added [18] replacements
{code}
IDs for io.smallrye.metrics messages are probably out of scope
> Logging to stdout/stderr, missing IDs for messages
> --------------------------------------------------
>
> Key: WFWIP-125
> URL: https://issues.jboss.org/browse/WFWIP-125
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Metrics
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> This is related to WFWIP-124 where I noticed different logging format ++ output to stdout/stderr.
> Example:
> {code}
> 15:38:10,712 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 15:38:10,712 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 15:38:10,712 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 15.0.0.Alpha1-SNAPSHOT (WildFly Core 7.0.0.Alpha2) started in 4266ms - Started 309 of 530 services (321 services are lazy, passive or on-demand)
> 15:38:26,657 INFO [stdout] (management I/O-2) metricName = /socket-binding-group/standard-sockets/socket-binding/management-http.bound-address
> 15:38:26,661 ERROR [stderr] (management I/O-2) java.lang.NumberFormatException: multiple points
> 15:38:26,662 ERROR [stderr] (management I/O-2) at java.base/jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1914)
> 15:38:26,662 ERROR [stderr] (management I/O-2) at java.base/jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> 15:38:26,662 ERROR [stderr] (management I/O-2) at java.base/java.lang.Double.parseDouble(Double.java:543)
> {code}
> Logging have to be unified and go via jboss-logging, also IDs for messages are needed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3249) [DMN Designer] Add support for optional typeRefs
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3249?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3249:
-------------------------------------
[~manstis] Hi, isn't this related to any of current epics we have?
> [DMN Designer] Add support for optional typeRefs
> ------------------------------------------------
>
> Key: DROOLS-3249
> URL: https://issues.jboss.org/browse/DROOLS-3249
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Critical
> Labels: drools-tools
>
> At the moment {{TypeRef}} is a mandatory field within the editor.
> This is a hard limitation of use of the Properties Panel bean-binding (it cannot bind to {{null}} values). However the DMN Specification states that {{TypeRef}} are optional (and we are working around by changing the _default_ to {{Any}} - see [DROOLS-3248|https://issues.jboss.org/browse/DROOLS-3248]).
> We need to change the UI and marshaller to be able to support _optional_ {{TypeRef}}. This would (probably) require adding a _magic_ value to {{BuiltInType}} representing a "null" selection. It would need to:
> - Appear at the top of the "Data Type selector" widget (with label "<None>" or similar)
> - Be the _selected_ option when the {{TypeRef}} is the new _magic_ value (this should happen automatically, but worth checking!)
> - The marshaller should set the {{TypeRef}} to the _magic_ {{BuiltInType}} if the DMN model (coming from XML->{{kie-dmn-model}}->workbench model) has a {{null}} {{TypeRef}} - the _magic_ value is only to be used _client-side_.
> - The marshaller should set the {{TypeRef}} to {{null}} when converting from the workbench model to {{kie-dmn-model}} and the workbench model {{TypeRef}} is the _magic_ value - again, the _magic_ value is only to be used _client-side_.
> - Check that creating new data-types does not show the _magic_ value (it uses a different widget, but population of the widget probably iterates all {{BuiltInType}}.
> [~tari_manga] [~karreiro] seem reasonable to you?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months