[JBoss JIRA] (WFLY-11) Bundle path for Embedded server still not working properly
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-11?page=com.atlassian.jira.plugin.sy... ]
Alexey Loubyansky updated WFLY-11:
----------------------------------
Fix Version/s: (was: 8.0.0.CR1)
Git Pull Request: https://github.com/wildfly/wildfly/pull/5830
> Bundle path for Embedded server still not working properly
> ----------------------------------------------------------
>
> Key: WFLY-11
> URL: https://issues.jboss.org/browse/WFLY-11
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Galder Zamarreño
> Assignee: Alexey Loubyansky
> Fix For: 8.0.0.Final
>
>
> Error is:
> {code} io.escalante.test.artifact.ArtifactInstallTest: bundlesDir not a directory{code}
> The problem is that the check is done in an 'assert' block and that only happens when assertions have been enabled by the user :(
> The problem comes cos bundlesDir is set to "null/bundles", even if I have not set any bundlesDir.
> Seems like bundlesDir is pre-computed too early in EmbeddedContainerConfiguration where it expects a system property, but that might not be set, it might come from arquillian.xml. So better delay until EmbeddedServerFactory.create.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (WFLY-11) Bundle path for Embedded server still not working properly
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-11?page=com.atlassian.jira.plugin.sy... ]
Alexey Loubyansky resolved WFLY-11.
-----------------------------------
Resolution: Done
Fixed.
> Bundle path for Embedded server still not working properly
> ----------------------------------------------------------
>
> Key: WFLY-11
> URL: https://issues.jboss.org/browse/WFLY-11
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Galder Zamarreño
> Assignee: Alexey Loubyansky
> Fix For: 8.0.0.Final
>
>
> Error is:
> {code} io.escalante.test.artifact.ArtifactInstallTest: bundlesDir not a directory{code}
> The problem is that the check is done in an 'assert' block and that only happens when assertions have been enabled by the user :(
> The problem comes cos bundlesDir is set to "null/bundles", even if I have not set any bundlesDir.
> Seems like bundlesDir is pre-computed too early in EmbeddedContainerConfiguration where it expects a system property, but that might not be set, it might come from arquillian.xml. So better delay until EmbeddedServerFactory.create.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (JGRP-1789) Fix host binding of tests involving GossipRouter
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1789:
-------------------------------------------
Both of these tests create their own stack involving TUNNEL and this stack does not explicitly set the bind address passed into the test case.
Both the GossipRouter and the TUNNEL protocol should probably use the same jgroups.bind_addr to avoid this sort of failure.
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
> Key: JGRP-1789
> URL: https://issues.jboss.org/browse/JGRP-1789
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter.
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (JGRP-1789) Fix host binding of tests involving GossipRouter
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-1789:
--------------------------------------
Description:
Tests like TUNNEL_Test and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]
------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}
TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
was:
Tests like TUNNEL_Test and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter.
{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]
------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}
TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
> Key: JGRP-1789
> URL: https://issues.jboss.org/browse/JGRP-1789
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (JGRP-1789) Fix host binding of tests involving GossipRouter
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JGRP-1789:
-----------------------------------------
Summary: Fix host binding of tests involving GossipRouter
Key: JGRP-1789
URL: https://issues.jboss.org/browse/JGRP-1789
Project: JGroups
Issue Type: Bug
Affects Versions: 3.2.13
Environment: Windows
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Fix For: 3.2.13
Tests like TUNNEL_Test and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter.
{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]
------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}
TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (WFLY-2558) Patching core Test failure
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-2558?page=com.atlassian.jira.plugin.... ]
Emanuel Muckenhuber resolved WFLY-2558.
---------------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Done
> Patching core Test failure
> --------------------------
>
> Key: WFLY-2558
> URL: https://issues.jboss.org/browse/WFLY-2558
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Patching
> Affects Versions: 8.0.0.Beta1
> Environment: JDK 8-ea-b115, Linux Ubuntu 64-bit
> Reporter: Yosi Pramajaya
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.Final
>
>
> Running org.jboss.as.patching.tests.PatchModuleInvalidationTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.135 sec <<< FAILURE! - in org.jboss.as.patching.tests.PatchModuleInvalidationTestCase
> test(org.jboss.as.patching.tests.PatchModuleInvalidationTestCase) Time elapsed: 0.13 sec <<< FAILURE!
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at org.junit.Assert.assertNotNull(Assert.java:631)
> at org.jboss.as.patching.tests.PatchModuleInvalidationTestCase.assertLoadable(PatchModuleInvalidationTestCase.java:192)
> at org.jboss.as.patching.tests.PatchModuleInvalidationTestCase.test(PatchModuleInvalidationTestCase.java:77)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months