[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
[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
[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
[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