February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AG-9) Create initial test suite

by Luis Barreiro (JIRA)

Luis Barreiro created AG-9: ------------------------------ Summary: Create initial test suite Key: AG-9 URL: https://issues.jboss.org/browse/AG-9 Project: Agroal Issue Type: Task Components: test Affects Versions: 0.0 Reporter: Luis Barreiro Assignee: Luis Barreiro Fix For: 0.1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AG-8) Migrate Narayana integration module from existent POC repo

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-8?page=com.atlassian.jira.plugin.syste... ] Luis Barreiro resolved AG-8. ---------------------------- Resolution: Done > Migrate Narayana integration module from existent POC repo > ---------------------------------------------------------- > > Key: AG-8 > URL: https://issues.jboss.org/browse/AG-8 > Project: Agroal > Issue Type: Task > Components: narayana > Affects Versions: 0.0 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Fix For: 0.1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2298) RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2298?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2298: ------------------------------------------ If this isn't resolved soon, anyone should feel free to take it. > RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs > --------------------------------------------------------------------------- > > Key: WFCORE-2298 > URL: https://issues.jboss.org/browse/WFCORE-2298 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > On Windows, apparently PIDs can be recycled in such a way that they can reappear shortly after the first process with a PID is terminated. (See http://stackoverflow.com/questions/26301382/does-windows-7-recycle-proces... and links therein.) > RespawnHttpTestCase is assuming that this won't happen, since when checking for reload completion it ignores any PID that belonged to one of the servers that's expected to be restarted. I'm seeing intermittent failures that seem to be due to this expectation being incorrect, as the logging for the failed tests clearly shows that the servers are restarted. > For example: > https://ci.wildfly.org/viewLog.html?buildId=45601&tab=buildResultsDiv&bui... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2298) RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2298?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2298: ------------------------------------------ This probably can't be made perfect (at least not with effort reasonable for the problem) but 1) RunningProcess.equals/hashCode can account for both the PID and the process "type" string. 2) Use that for checking if a process should be ignored, instead of just the PID, so if server-one reloads to the PID used before by server-two, it's not counted as not having reloaded. 3) Check more frequently, with no initial delay 4) Once an excluded process isn't seen, stop excluding it, so if it resurrects its not treated as the old process. Also, RespawnTestCase and RespawnHttpTestCase should share the utility code here instead of duplicating it. > RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs > --------------------------------------------------------------------------- > > Key: WFCORE-2298 > URL: https://issues.jboss.org/browse/WFCORE-2298 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > On Windows, apparently PIDs can be recycled in such a way that they can reappear shortly after the first process with a PID is terminated. (See http://stackoverflow.com/questions/26301382/does-windows-7-recycle-proces... and links therein.) > RespawnHttpTestCase is assuming that this won't happen, since when checking for reload completion it ignores any PID that belonged to one of the servers that's expected to be restarted. I'm seeing intermittent failures that seem to be due to this expectation being incorrect, as the logging for the failed tests clearly shows that the servers are restarted. > For example: > https://ci.wildfly.org/viewLog.html?buildId=45601&tab=buildResultsDiv&bui... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2298) RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2298?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2298: ------------------------------------- Summary: RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs (was: RespawnHttpTestCase doesn't account for recycling of PIDs) > RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs > --------------------------------------------------------------------------- > > Key: WFCORE-2298 > URL: https://issues.jboss.org/browse/WFCORE-2298 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > On Windows, apparently PIDs can be recycled in such a way that they can reappear shortly after the first process with a PID is terminated. (See http://stackoverflow.com/questions/26301382/does-windows-7-recycle-proces... and links therein.) > RespawnHttpTestCase is assuming that this won't happen, since when checking for reload completion it ignores any PID that belonged to one of the servers that's expected to be restarted. I'm seeing intermittent failures that seem to be due to this expectation being incorrect, as the logging for the failed tests clearly shows that the servers are restarted. > For example: > https://ci.wildfly.org/viewLog.html?buildId=45601&tab=buildResultsDiv&bui... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8119) NPE in mod_cluster stopping

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8119?page=com.atlassian.jira.plugin.... ] Radoslav Husar moved JBEAP-8841 to WFLY-8119: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8119 (was: JBEAP-8841) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: mod_cluster (was: mod_cluster) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR10) > NPE in mod_cluster stopping > --------------------------- > > Key: WFLY-8119 > URL: https://issues.jboss.org/browse/WFLY-8119 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Don't know what causing it or how to reproduce it. > It started to show with EAP 7.1.0.DR10. > At first glance it shows quite randomly without any significant effect on server > {noformat} > 2017-01-11 08:29:19,989 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping > 2017-01-11 08:29:20,108 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) null: java.lang.NullPointerException > at org.jboss.modcluster.ModClusterService.connectionEstablished(ModClusterService.java:305) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:392) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454) > at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} > http://paste.fedoraproject.org/530763/30767148/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2298) RespawnHttpTestCase doesn't account for recycling of PIDs

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2298: ---------------------------------------- Summary: RespawnHttpTestCase doesn't account for recycling of PIDs Key: WFCORE-2298 URL: https://issues.jboss.org/browse/WFCORE-2298 Project: WildFly Core Issue Type: Bug Components: Domain Management, Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor On Windows, apparently PIDs can be recycled in such a way that they can reappear shortly after the first process with a PID is terminated. (See http://stackoverflow.com/questions/26301382/does-windows-7-recycle-proces... and links therein.) RespawnHttpTestCase is assuming that this won't happen, since when checking for reload completion it ignores any PID that belonged to one of the servers that's expected to be restarted. I'm seeing intermittent failures that seem to be due to this expectation being incorrect, as the logging for the failed tests clearly shows that the servers are restarted. For example: https://ci.wildfly.org/viewLog.html?buildId=45601&tab=buildResultsDiv&bui... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8100) Use RuntimeCapability.Builder.setAllowMultipleRegistrations(...) where appropriate

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8100?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-8100: ------------------------------- Summary: Use RuntimeCapability.Builder.setAllowMultipleRegistrations(...) where appropriate (was: Use RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate) > Use RuntimeCapability.Builder.setAllowMultipleRegistrations(...) where appropriate > ---------------------------------------------------------------------------------- > > Key: WFLY-8100 > URL: https://issues.jboss.org/browse/WFLY-8100 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: No Release > Reporter: Paul Ferraro > Assignee: Paul Ferraro > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8118) Use RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-8118: ---------------------------------- Summary: Use RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate Key: WFLY-8118 URL: https://issues.jboss.org/browse/WFLY-8118 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: No Release Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8117) Require Maven 3.3.1+ and introduce mvnw

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-8117: --------------------------------- Summary: Require Maven 3.3.1+ and introduce mvnw Key: WFLY-8117 URL: https://issues.jboss.org/browse/WFLY-8117 Project: WildFly Issue Type: Task Reporter: Tomaz Cerar Assignee: Peter Palaga * Maven 3.3.1+ is required by the Enforcer Plugin * {{mvnw}} (a.k.a. Maven Wrapper) replaces the legacy {{tools/download-maven.*}} scripts * {{build.*}} and {{integration-tests.*}} scripts were kept for backwards compatibility. These changes were discussed on wildfly-dev mailing list. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017