February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-602) CI Pipeline Support For Maistra + Kiali Deploy on OCP4

by Matt Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-602?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-602: ------------------------------- Description: The purpose of this task is to add CI Pipeline support for deploying Maistra + Kiali on OCP4 Reference Doc: https://docs.google.com/document/d/1n9JvfyW2QpaeD_m5WKDcyesEiQGto3sUJKmzf... > CI Pipeline Support For Maistra + Kiali Deploy on OCP4 > ------------------------------------------------------ > > Key: SWSQE-602 > URL: https://issues.jboss.org/browse/SWSQE-602 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Michael Foley > Priority: Major > > The purpose of this task is to add CI Pipeline support for deploying Maistra + Kiali on OCP4 > Reference Doc: https://docs.google.com/document/d/1n9JvfyW2QpaeD_m5WKDcyesEiQGto3sUJKmzf... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-601) CI Pipeline Deploy Of OCP4 on AWS

by Matt Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-601?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-601: ------------------------------- Description: This task is to create a Jenkins pineline job that will stand-up an OCP4 cluster on AWS. Reference doc: https://docs.google.com/document/d/1n9JvfyW2QpaeD_m5WKDcyesEiQGto3sUJKmzf... was:This task is to create a Jenkins pineline job that will stand-up an OCP4 cluster on AWS. > CI Pipeline Deploy Of OCP4 on AWS > --------------------------------- > > Key: SWSQE-601 > URL: https://issues.jboss.org/browse/SWSQE-601 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Michael Foley > Priority: Major > > This task is to create a Jenkins pineline job that will stand-up an OCP4 cluster on AWS. > Reference doc: https://docs.google.com/document/d/1n9JvfyW2QpaeD_m5WKDcyesEiQGto3sUJKmzf... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-601) CI Pipeline Deploy Of OCP4 on AWS

by Matt Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-601?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-601: ------------------------------- Description: This task is to create a Jenkins pineline job that will stand-up an OCP4 cluster on AWS. > CI Pipeline Deploy Of OCP4 on AWS > --------------------------------- > > Key: SWSQE-601 > URL: https://issues.jboss.org/browse/SWSQE-601 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Michael Foley > Priority: Major > > This task is to create a Jenkins pineline job that will stand-up an OCP4 cluster on AWS. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-601) CI Pipeline Deploy Of OCP4 on AWS

by Matt Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-601?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-601: ------------------------------- Summary: CI Pipeline Deploy Of OCP4 on AWS (was: Pipeline Deploy Of OCP4 on AWS) > CI Pipeline Deploy Of OCP4 on AWS > --------------------------------- > > Key: SWSQE-601 > URL: https://issues.jboss.org/browse/SWSQE-601 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Michael Foley > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-602) CI Pipeline Support For Maistra + Kiali Deploy on OCP4

by Matt Mahoney (Jira)

Matt Mahoney created SWSQE-602: ---------------------------------- Summary: CI Pipeline Support For Maistra + Kiali Deploy on OCP4 Key: SWSQE-602 URL: https://issues.jboss.org/browse/SWSQE-602 Project: Kiali QE Issue Type: Sub-task Reporter: Matt Mahoney Assignee: Michael Foley -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-601) Pipeline Deploy Of OCP4 on AWS

by Matt Mahoney (Jira)

Matt Mahoney created SWSQE-601: ---------------------------------- Summary: Pipeline Deploy Of OCP4 on AWS Key: SWSQE-601 URL: https://issues.jboss.org/browse/SWSQE-601 Project: Kiali QE Issue Type: Sub-task Reporter: Matt Mahoney Assignee: Michael Foley -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-600) CI Pipleline Support Of OCP4 on AWS

by Matt Mahoney (Jira)

Matt Mahoney created SWSQE-600: ---------------------------------- Summary: CI Pipleline Support Of OCP4 on AWS Key: SWSQE-600 URL: https://issues.jboss.org/browse/SWSQE-600 Project: Kiali QE Issue Type: Story Reporter: Matt Mahoney Assignee: Michael Foley -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11678) ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11678?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11678: ------------------------------------ Component/s: Concurrency Utilities (was: EE) > ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks > ------------------------------------------------------------------------------------------- > > Key: WFLY-11678 > URL: https://issues.jboss.org/browse/WFLY-11678 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Environment: -- EAP 7.1.4 > Reporter: Lei Yu > Assignee: James Perkins > Priority: Critical > > managed executor: > {code} > <managed-executor-services> > <managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/> > </managed-executor-services> > {code} > With each undeploy, the application classloader is leaked and not released because contextClassLoader references persisted on the executor threads: > {code} > Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread @ 0xc3677570 EE-ManagedExecutorService-default-Thread-13 Thread| 1 | 160 | 88 | 1,344 > '- contextClassLoader org.jboss.modules.ModuleClassLoader @ 0xc32b9d98 | 1 | 88 | 88 | 366,800 > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > {code} > Tracing with byteman, what's strange is that it sets the app classloader on setup: > {code} > Thread.setContextClassLoader: Thread[EE-ManagedExecutorService-default-Thread-16,5,ServerService ThreadGroup] ModuleClassLoader for Module "deployment.services-1.0.4-rc1.war" from Service Module Loader > java.lang.Thread.setContextClassLoader(Thread.java:1477) > org.wildfly.security.manager.WildFlySecurityManager.setCurrentContextClassLoaderPrivileged(WildFlySecurityManager.java:1272) > org.jboss.as.ee.concurrent.handle.ClassLoaderContextHandleFactory$ClassLoaderSetupContextHandle.setup(ClassLoaderContextHandleFactory.java:83) > org.jboss.as.ee.concurrent.ConcurrentContext$ChainedSetupContextHandle.setup(ConcurrentContext.java:166) > org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.setup(DefaultContextSetupProviderImpl.java:58) > org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.setupContext(ManagedFutureTask.java:121) > org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor.beforeExecute(ManagedThreadPoolExecutor.java:109) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > java.lang.Thread.run(Thread.java:748) > {code} > And still sets that app classloader after task execution in the reset: > {code} > Thread.setContextClassLoader: Thread[EE-ManagedExecutorService-default-Thread-16,5,ServerService ThreadGroup] ModuleClassLoader for Module "deployment.services-1.0.4-rc1.war" from Service Module Loader > java.lang.Thread.setContextClassLoader(Thread.java:1477) > org.wildfly.security.manager.WildFlySecurityManager.setCurrentContextClassLoaderPrivileged(WildFlySecurityManager.java:1272) > org.jboss.as.ee.concurrent.handle.ClassLoaderContextHandleFactory$ClassLoaderResetContextHandle.reset(ClassLoaderContextHandleFactory.java:113) > org.jboss.as.ee.concurrent.ConcurrentContext$ChainedResetContextHandle.reset(ConcurrentContext.java:284) > org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.reset(DefaultContextSetupProviderImpl.java:63) > org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.resetContext(ManagedFutureTask.java:134) > org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor.afterExecute(ManagedThreadPoolExecutor.java:90) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > java.lang.Thread.run(Thread.java:748) > {code} > So the thread is sitting in the pool with the app classloader. Is there some way we should be able to get the context loader cleared or unset from the app loader in the reset? -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11704) Support -Ddebug for clustering testsuite

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11704?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11704: ---------------------------------- Fix Version/s: Awaiting Volunteers > Support -Ddebug for clustering testsuite > ---------------------------------------- > > Key: WFLY-11704 > URL: https://issues.jboss.org/browse/WFLY-11704 > Project: WildFly > Issue Type: Task > Components: Clustering, Test Suite > Affects Versions: 15.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: Awaiting Volunteers > > > This has been broken for a while now; there are still traces of properties such as {{as.debug.port.node3}} but never set. > * What could to be done is to pick up {{-Ddebug}} and setup debug lines for *each* server with specific ports, i.e. ports. > * However, {{suspend=y}} need to be used reasonably, since this makes for an arduous debugging session. > * Probably one server could be picked up for debugging. > * Moreover, timeouts should probably be heavily increased not to timeout very quickly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11704) Support -Ddebug for clustering testsuite

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11704?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11704: ---------------------------------- Description: This has been broken for a while now; there are still traces of properties such as {{as.debug.port.node3}} but never set. * What could to be done is to pick up {{-Ddebug}} and setup debug lines for *each* server with specific ports, i.e. ports. * However, {{suspend=y}} need to be used reasonably, since this makes for an arduous debugging session. * Probably one server could be picked up for debugging. was: This has been broken for a while now; there are still traces of properties like as.debug.port.node3 but never set. * What could to be done is to pick up {{-Ddebug}} and setup debug lines for *each* server with specific ports, i.e. ports. * However, {{suspend=y}} need to be used reasonably, since this makes for an arduous debugging session. * Probably one server could be picked up for debugging. > Support -Ddebug for clustering testsuite > ---------------------------------------- > > Key: WFLY-11704 > URL: https://issues.jboss.org/browse/WFLY-11704 > Project: WildFly > Issue Type: Task > Components: Clustering, Test Suite > Affects Versions: 15.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > This has been broken for a while now; there are still traces of properties such as {{as.debug.port.node3}} but never set. > * What could to be done is to pick up {{-Ddebug}} and setup debug lines for *each* server with specific ports, i.e. ports. > * However, {{suspend=y}} need to be used reasonably, since this makes for an arduous debugging session. > * Probably one server could be picked up for debugging. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2019