September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11036) Shutdown hangs if WAR is distributable and uses SSE

by Rich DiCroce (JIRA)

Rich DiCroce created WFLY-11036: ----------------------------------- Summary: 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 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.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1669) Update Travis CI Configuration to use Java 10

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1669: ------------------------------------- Summary: Update Travis CI Configuration to use Java 10 Key: ELY-1669 URL: https://issues.jboss.org/browse/ELY-1669 Project: WildFly Elytron Issue Type: Task Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.7.0.CR1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2282) Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2282?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned JGRP-2282: ------------------------------------ Assignee: Radoslav Husar (was: Bela Ban) > Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT > -------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2282 > URL: https://issues.jboss.org/browse/JGRP-2282 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.13 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 4.0.15 > > > There seems to be a regression (in 4.0?) in SYM_ENCRYPT and ASYM_ENCRYPT dropping messages around topology changes (and possibly bypassing retransmission?). QE tests using these protocols observe a lot of the following: > {code} > [JBossINF] [0m[31m04:45:10,048 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ejb,perf18) perf18: received message without encrypt header from perf21; dropping it > {code} > which is followed by numerous infinispan exceptions/timeouts, see WFLY-10464. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8329) cannot set await-initial-transfer attribute in infinispan configuration

by Jan-Willem Gmelig Meyling (JIRA)

[ https://issues.jboss.org/browse/WFLY-8329?page=com.atlassian.jira.plugin.... ] Jan-Willem Gmelig Meyling commented on WFLY-8329: ------------------------------------------------- Thanks for pointing this out! (y) > cannot set await-initial-transfer attribute in infinispan configuration > ----------------------------------------------------------------------- > > Key: WFLY-8329 > URL: https://issues.jboss.org/browse/WFLY-8329 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Daniele Pirola > Assignee: Paul Ferraro > > Inside wildfly infinispan configuration I can't set attribute {{await-initial-transfer}} even if it's present in Infinispan 8.2.4.Final (see {{org.infinispan.configuration.cache.StateTransferConfiguration}}). > This is the subsystem that doesn't work: > {{<subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container XXX > > <distributed-cache XXX > > ... > <state-transfer await-initial-transfer="true" /> > </distributed-cache>}} > There is a workaround to set this attribute at runtime? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8329) cannot set await-initial-transfer attribute in infinispan configuration

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8329?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-8329. ------------------------------ Resolution: Duplicate Issue Duplicate of WFLY-9648. I had forgotten that you already created this one. As of WF 13.0.0.Final, state-transfer timeout="0" is equivalent to disabling awaitInitialTransfer. > cannot set await-initial-transfer attribute in infinispan configuration > ----------------------------------------------------------------------- > > Key: WFLY-8329 > URL: https://issues.jboss.org/browse/WFLY-8329 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Daniele Pirola > Assignee: Paul Ferraro > > Inside wildfly infinispan configuration I can't set attribute {{await-initial-transfer}} even if it's present in Infinispan 8.2.4.Final (see {{org.infinispan.configuration.cache.StateTransferConfiguration}}). > This is the subsystem that doesn't work: > {{<subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container XXX > > <distributed-cache XXX > > ... > <state-transfer await-initial-transfer="true" /> > </distributed-cache>}} > There is a workaround to set this attribute at runtime? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8329) cannot set await-initial-transfer attribute in infinispan configuration

by Jan-Willem Gmelig Meyling (JIRA)

[ https://issues.jboss.org/browse/WFLY-8329?page=com.atlassian.jira.plugin.... ] Jan-Willem Gmelig Meyling commented on WFLY-8329: ------------------------------------------------- Has this ever been implemented? > cannot set await-initial-transfer attribute in infinispan configuration > ----------------------------------------------------------------------- > > Key: WFLY-8329 > URL: https://issues.jboss.org/browse/WFLY-8329 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Daniele Pirola > Assignee: Paul Ferraro > > Inside wildfly infinispan configuration I can't set attribute {{await-initial-transfer}} even if it's present in Infinispan 8.2.4.Final (see {{org.infinispan.configuration.cache.StateTransferConfiguration}}). > This is the subsystem that doesn't work: > {{<subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container XXX > > <distributed-cache XXX > > ... > <state-transfer await-initial-transfer="true" /> > </distributed-cache>}} > There is a workaround to set this attribute at runtime? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-419) Enhance Maistra Pipeline Support

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-419?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-419: ------------------------------------------ Description: Maistra Pipeline would need to have some additions to have better support. - Some of them include - Remove Maistra Job from Upstream Pipeline - Add Minimal CR option (this will install default versions listed on istio-operator) - Separate OPENSHIFT_ISTIO_VERSION variable - one for istio operator version and other for istio openshift ansible - Include Option to run or not run Kiali Istio Checker - Include Bookinfo - Include E2E Test Run - Include UI Test Run was: Maistra Pipeline would need to have some additions to have better support. - Some of them include - Add Minimal CR option (this will install default versions listed on istio-operator) - Separate OPENSHIFT_ISTIO_VERSION variable - one for istio operator version and other for istio openshift ansible - Include Option to run or not run Kiali Istio Checker - Include Bookinfo - Include E2E Test Run - Include UI Test Run > Enhance Maistra Pipeline Support > -------------------------------- > > Key: SWSQE-419 > URL: https://issues.jboss.org/browse/SWSQE-419 > Project: Kiali QE > Issue Type: Story > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > Maistra Pipeline would need to have some additions to have better support. > - Some of them include > - Remove Maistra Job from Upstream Pipeline > - Add Minimal CR option (this will install default versions listed on istio-operator) > - Separate OPENSHIFT_ISTIO_VERSION variable - one for istio operator version and other for istio openshift ansible > - Include Option to run or not run Kiali Istio Checker > - Include Bookinfo > - Include E2E Test Run > - Include UI Test Run -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-419) Enhance Maistra Pipeline Support

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-419?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-419: ------------------------------------------ Description: Maistra Pipeline would need to have some additions to have better support (Some of them include) - Remove Maistra Job from Upstream Pipeline - Add Minimal CR option (this will install default versions listed on istio-operator) - Separate OPENSHIFT_ISTIO_VERSION variable - one for istio operator version and other for istio openshift ansible - Include Option to run or not run Kiali Istio Checker - Include Bookinfo - Include E2E Test Run - Include UI Test Run was: Maistra Pipeline would need to have some additions to have better support. - Some of them include - Remove Maistra Job from Upstream Pipeline - Add Minimal CR option (this will install default versions listed on istio-operator) - Separate OPENSHIFT_ISTIO_VERSION variable - one for istio operator version and other for istio openshift ansible - Include Option to run or not run Kiali Istio Checker - Include Bookinfo - Include E2E Test Run - Include UI Test Run > Enhance Maistra Pipeline Support > -------------------------------- > > Key: SWSQE-419 > URL: https://issues.jboss.org/browse/SWSQE-419 > Project: Kiali QE > Issue Type: Story > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > Maistra Pipeline would need to have some additions to have better support (Some of them include) > - Remove Maistra Job from Upstream Pipeline > - Add Minimal CR option (this will install default versions listed on istio-operator) > - Separate OPENSHIFT_ISTIO_VERSION variable - one for istio operator version and other for istio openshift ansible > - Include Option to run or not run Kiali Istio Checker > - Include Bookinfo > - Include E2E Test Run > - Include UI Test Run -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-423) Remove Maistra Job from Upstream Pipeline

by Guilherme Baufaker Rêgo (JIRA)

Guilherme Baufaker Rêgo created SWSQE-423: --------------------------------------------- Summary: Remove Maistra Job from Upstream Pipeline Key: SWSQE-423 URL: https://issues.jboss.org/browse/SWSQE-423 Project: Kiali QE Issue Type: Sub-task Reporter: Guilherme Baufaker Rêgo Assignee: Michael Foley - Installing Maistra, deleting and then installing Istio Upstream might lead to problems. (Istio Upstream job doesn't delete istio-operator namespace and maistra resources) - Separating the pipelines seems to be an option, since operators numbers will increase -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-423) Remove Maistra Job from Upstream Pipeline

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-423?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reassigned SWSQE-423: --------------------------------------------- Assignee: Guilherme Baufaker Rêgo (was: Michael Foley) > Remove Maistra Job from Upstream Pipeline > ----------------------------------------- > > Key: SWSQE-423 > URL: https://issues.jboss.org/browse/SWSQE-423 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > - Installing Maistra, deleting and then installing Istio Upstream might lead to problems. (Istio Upstream job doesn't delete istio-operator namespace and maistra resources) > - Separating the pipelines seems to be an option, since operators numbers will increase -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2018