January 2014 - jboss-jira - Jboss List Archives

[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

12 years, 2 months

1
0
0 / 0

[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

12 years, 2 months

1
0
0 / 0

[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

12 years, 2 months

1
0
0 / 0

[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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2723) Accessing "serverInventory" without holding lock "serverInventoryLock"

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-2723?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber resolved WFLY-2723. --------------------------------------- Fix Version/s: 8.0.0.Final Resolution: Done > Accessing "serverInventory" without holding lock "serverInventoryLock" > ---------------------------------------------------------------------- > > Key: WFLY-2723 > URL: https://issues.jboss.org/browse/WFLY-2723 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Rostislav Svoboda > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Final > > > Accessing "serverInventory" without holding lock "org.jboss.as.host.controller.DomainModelControllerService.serverInventoryLock". > Elsewhere, "serverInventory" is accessed with "DomainModelControllerService.serverInventoryLock" held 4 out of 5 times. > https://github.com/wildfly/wildfly/blob/master/host-controller/src/main/j... -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2791) Remove jboss-marshalling mvn dependency from the management protocol

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-2791?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber resolved WFLY-2791. --------------------------------------- Resolution: Done > Remove jboss-marshalling mvn dependency from the management protocol > -------------------------------------------------------------------- > > Key: WFLY-2791 > URL: https://issues.jboss.org/browse/WFLY-2791 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Final > > > The wildfly-protocol depends on jboss-marshalling although it should not be used for a while now. We need to verify that it's not used any more and remove it. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2635) HTTP Management Interface Configuration

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.... ] Andre Dietisheim commented on WFLY-2635: ---------------------------------------- I^d be glad to contribute at least the parts that are related to the management-filters. Should we create sub-tasks? > HTTP Management Interface Configuration > --------------------------------------- > > Key: WFLY-2635 > URL: https://issues.jboss.org/browse/WFLY-2635 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > > Various configuration items are required for the HTTP Management interface, this is a parent task to combine them. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2698) Transaction Aware EE Concurrency EJB Context Handle

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2698?page=com.atlassian.jira.plugin.... ] Eduardo Martins commented on WFLY-2698: --------------------------------------- the allows tasks created by CMT EJB to access UserTransaction, as mandated by JSR 236 > Transaction Aware EE Concurrency EJB Context Handle > --------------------------------------------------- > > Key: WFLY-2698 > URL: https://issues.jboss.org/browse/WFLY-2698 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EE, EJB > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > When using EE Concurrency Utilities with an EJB that does not manages transactions, there is no way to transactions, for instance with a JPA entity manager. This happens because the context handle that saves and sets up EJB state does not creates and manages a transaction, and UserTransaction usage is forbidden due to EJB being of CMT kind. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2698) Transaction Aware EE Concurrency EJB Context Handle

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2698?page=com.atlassian.jira.plugin.... ] Eduardo Martins edited comment on WFLY-2698 at 1/31/14 3:32 PM: ---------------------------------------------------------------- the new PR allows tasks created by CMT EJB to access UserTransaction, as mandated by JSR 236 was (Author: emmartins): the allows tasks created by CMT EJB to access UserTransaction, as mandated by JSR 236 > Transaction Aware EE Concurrency EJB Context Handle > --------------------------------------------------- > > Key: WFLY-2698 > URL: https://issues.jboss.org/browse/WFLY-2698 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EE, EJB > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > When using EE Concurrency Utilities with an EJB that does not manages transactions, there is no way to transactions, for instance with a JPA entity manager. This happens because the context handle that saves and sets up EJB state does not creates and manages a transaction, and UserTransaction usage is forbidden due to EJB being of CMT kind. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2853) JSFFailoverTestCase fails since latest clustring / session changes in UT

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2853?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-2853: ------------------------------ Description: Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164 JSFFailoverTestCase is failing. example of failure: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=9076&buildType... {noformat} org.junit.ComparisonFailure: expected:<...COz6P7qxwwkkxE.node-[0]> but was:<...COz6P7qxwwkkxE.node-[1]> at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase.testGracefulSimpleFailover(JSFFailoverTestCase.java:268) {noformat} was: Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164 JSFFailoverTestCase is failing. I have ignored it for time being > JSFFailoverTestCase fails since latest clustring / session changes in UT > ------------------------------------------------------------------------ > > Key: WFLY-2853 > URL: https://issues.jboss.org/browse/WFLY-2853 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.0.0.CR1 > Reporter: Tomaz Cerar > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 8.0.0.Final > > > Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164 > JSFFailoverTestCase is failing. > example of failure: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=9076&buildType... > {noformat} > org.junit.ComparisonFailure: expected:<...COz6P7qxwwkkxE.node-[0]> but was:<...COz6P7qxwwkkxE.node-[1]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase.testGracefulSimpleFailover(JSFFailoverTestCase.java:268) > {noformat} -- 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

12 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 January 2014