[JBoss JIRA] (AS7-3786) Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3786?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka resolved AS7-3786.
-------------------------------
Resolution: Done
I'm closing this, let's keep track of the rest in AS7-3696 .
Reopen if you find some non-Arq tests with this issue.
> Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
> ------------------------------------------------------------------
>
> Key: AS7-3786
> URL: https://issues.jboss.org/browse/AS7-3786
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.0.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Critical
> Fix For: 7.1.1.Final
>
>
> Some TestCases are hard bound to *127.0.0.1* IP address. I think, it is useless - especially testing in IPv6 environment is impossible in this case for a such TestCase(-s).
> These classes aren't in integration testsuite part, it is in other places.
> Some of them are (maybe I've overlooked some others):
> - org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase
> - org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase
> - org.jboss.as.controller.test.RemoteProxyControllerProtocolTestCase
> - org.jboss.as.controller.ModelControllerClientTestCase
> - org.jboss.as.jmx.JMXSubsystemTestCase
> - org.jboss.as.jmx.ModelControllerMBeanTestCase
> Otherwise these tests are run *before* IP address transformation (usually used node0 variable and tranforms AS7 config file standalone-*.xml), so maybe there isn't present now any mechanism how to get/propagate proper (and wanted) IP address.
> Also note - some of them are hardcoded to IP name alias *localhost* - see JBPAPP-8132 for localhost vs. localhost6.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-3786) Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3786?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka commented on AS7-3786:
-----------------------------------
Pavel, org.jboss.as.controller.* is not part of the testsuite.
I think that situation when we will need to support whole build on machine not supporting 127.0.0.1 is far far away from now.
> Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
> ------------------------------------------------------------------
>
> Key: AS7-3786
> URL: https://issues.jboss.org/browse/AS7-3786
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.0.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Critical
> Fix For: 7.1.1.Final
>
>
> Some TestCases are hard bound to *127.0.0.1* IP address. I think, it is useless - especially testing in IPv6 environment is impossible in this case for a such TestCase(-s).
> These classes aren't in integration testsuite part, it is in other places.
> Some of them are (maybe I've overlooked some others):
> - org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase
> - org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase
> - org.jboss.as.controller.test.RemoteProxyControllerProtocolTestCase
> - org.jboss.as.controller.ModelControllerClientTestCase
> - org.jboss.as.jmx.JMXSubsystemTestCase
> - org.jboss.as.jmx.ModelControllerMBeanTestCase
> Otherwise these tests are run *before* IP address transformation (usually used node0 variable and tranforms AS7 config file standalone-*.xml), so maybe there isn't present now any mechanism how to get/propagate proper (and wanted) IP address.
> Also note - some of them are hardcoded to IP name alias *localhost* - see JBPAPP-8132 for localhost vs. localhost6.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-3128) Arquillian should wait until a port is free after AS JVM process ends to prevent "port in use".
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3128?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka commented on AS7-3128:
-----------------------------------
Hi Andrew, any progress on this?
Here is the run which demonstrates the problem on slower machines:
https://hudson.qa.jboss.com/hudson/view/ESSC/job/AS7-TS-valid-all-debug/1...
Run #17 on dev09 went fine. Run #18 on dsp machine hit the issue.
> Arquillian should wait until a port is free after AS JVM process ends to prevent "port in use".
> -----------------------------------------------------------------------------------------------
>
> Key: AS7-3128
> URL: https://issues.jboss.org/browse/AS7-3128
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.0.CR1
> Reporter: Ondrej Zizka
> Assignee: Andrew Rubinger
> Priority: Blocker
> Labels: arq_qe_blocker
> Fix For: 7.1.2.Final
>
>
> (05:54:09) dmlloyd: when running with JDWP enabled on the client or server, I occasionally get bind exceptions due to address in use
> (05:54:25) dmlloyd: which means that tests are running into each other without waiting for termination of the previous one
> (05:54:35) dmlloyd: which may also be causing other issues
> (05:56:04) ozizka: dmlloyd: Yes, lbarrerio observed similar problem too,
> (05:56:47) ozizka: And that's arq's issue too - there's no way to get around this currently AFAIK. Or is there?
> (05:57:05) ozizka: Perhaps "manually" wait in @AfterClass or such
> (05:57:07) dmlloyd: yeah, it can wait for the child process to terminate
> (05:57:07) ozizka: which is ugly
> (05:57:14) dmlloyd: I mean arq should
> (05:59:17) ozizka: dmlloyd: Do you have it somewhere on hudson?
> (05:59:24) ozizka: dmlloyd: It never happened to me actually
> (05:59:49) ozizka: Send me a log if you have one handy
> (06:01:35) dmlloyd: ozizka: no, try running with this command though:
> {code}
> mvn -DallTests install -Djpda -Dsurefire.jpda.args=-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n \
> -Dmaven.surefire.debug="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
> {code}
> (06:13:56) ozizka: dmlloyd: That's on linux?
> (06:14:03) dmlloyd: yes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-3128) Arquillian should wait until a port is free after AS JVM process ends to prevent "port in use".
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3128?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka updated AS7-3128:
------------------------------
Fix Version/s: 7.1.2.Final
> Arquillian should wait until a port is free after AS JVM process ends to prevent "port in use".
> -----------------------------------------------------------------------------------------------
>
> Key: AS7-3128
> URL: https://issues.jboss.org/browse/AS7-3128
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.0.CR1
> Reporter: Ondrej Zizka
> Assignee: Andrew Rubinger
> Priority: Blocker
> Labels: arq_qe_blocker
> Fix For: 7.1.2.Final
>
>
> (05:54:09) dmlloyd: when running with JDWP enabled on the client or server, I occasionally get bind exceptions due to address in use
> (05:54:25) dmlloyd: which means that tests are running into each other without waiting for termination of the previous one
> (05:54:35) dmlloyd: which may also be causing other issues
> (05:56:04) ozizka: dmlloyd: Yes, lbarrerio observed similar problem too,
> (05:56:47) ozizka: And that's arq's issue too - there's no way to get around this currently AFAIK. Or is there?
> (05:57:05) ozizka: Perhaps "manually" wait in @AfterClass or such
> (05:57:07) dmlloyd: yeah, it can wait for the child process to terminate
> (05:57:07) ozizka: which is ugly
> (05:57:14) dmlloyd: I mean arq should
> (05:59:17) ozizka: dmlloyd: Do you have it somewhere on hudson?
> (05:59:24) ozizka: dmlloyd: It never happened to me actually
> (05:59:49) ozizka: Send me a log if you have one handy
> (06:01:35) dmlloyd: ozizka: no, try running with this command though:
> {code}
> mvn -DallTests install -Djpda -Dsurefire.jpda.args=-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n \
> -Dmaven.surefire.debug="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
> {code}
> (06:13:56) ozizka: dmlloyd: That's on linux?
> (06:14:03) dmlloyd: yes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month