[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-5239 at 10/4/16 9:14 AM:
---------------------------------------------------------------
[~pkremens] thanks for the update, but this issue is unrelated to the intermittent failures.
Nevertheless, there are 4 nodes in this test case, so specifying binding node0 and node1 to different interfaces (depending on the setup) the LON site will not cluster (or the tcp-bridge) and the test will fail as per your paste.
Specifying all 4 addresses does work, e.g.
{quote}
[rhusar@syrah wildfly]$ ./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Dtest=org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase -Dnode0=192.168.0.7 -Dnode1=192.168.0.7 -Dnode2=192.168.0.7 -Dnode3=192.168.0.7
{quote}
was (Author: rhusar):
[~pkremens] thanks for the update, but this issue is unrelated to the intermittent failures.
Nevertheless, there are 4 nodes in this test case, so specifying binding node0 and node1 to different interfaces (depending on the setup) the LON site will not cluster and the test will fail as per your paste.
Specifying all 4 addresses does work, e.g.
{quote}
[rhusar@syrah wildfly]$ ./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Dtest=org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase -Dnode0=192.168.0.7 -Dnode1=192.168.0.7 -Dnode2=192.168.0.7 -Dnode3=192.168.0.7
{quote}
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar [0m[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> [0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> [33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> [0mExecuted HTTP request
> [33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5239:
--------------------------------------
[~pkremens] thanks for the update, but this issue is unrelated to the intermittent failures.
Nevertheless, there are 4 nodes in this test case, so specifying binding node0 and node1 to different interfaces (depending on the setup) the LON site will not cluster and the test will fail as per your paste.
Specifying all 4 addresses does work, e.g.
{quote}
[rhusar@syrah wildfly]$ ./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Dtest=org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase -Dnode0=192.168.0.7 -Dnode1=192.168.0.7 -Dnode2=192.168.0.7 -Dnode3=192.168.0.7
{quote}
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar [0m[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> [0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> [33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> [0mExecuted HTTP request
> [33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1052) Add server-config parameter to :reload op
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1052:
------------------------------------------
Note that this behavior is problematic for the domain config in the context of an HA DC feature (WFCORE-338). It adds another path via which the domain-wide config can be changed underneath the cluster of HCs that are attempting to ensure that the domain is using the correct config.
> Add server-config parameter to :reload op
> -----------------------------------------
>
> Key: WFCORE-1052
> URL: https://issues.jboss.org/browse/WFCORE-1052
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 3.0.0.Alpha1
>
>
> {code}
> [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml
looks for that file in the snapshots directory
> [13:48] Kabir Khan:
> [standalone@localhost:9990 /] :list-snapshots
> {
> "outcome" => "success",
> "result" => {
> "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot",
> "names" => [
> "20151013-134523280standalone.xml",
> "20151013-134726769standalone.xml"
> ]
> }
> }
> Show less
> [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation
> {code}
> Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail.
> For a domain server, we should not have the server-config parameter.
> We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1851) Inconsistent behaviour with browse-content(depth=1) operation between archived and exploded deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1851?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-6294 to WFCORE-1851:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1851 (was: JBEAP-6294)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: 3.0.0.Alpha9
(was: 7.1.0.DR5)
(was: 7.1.0.DR6)
> Inconsistent behaviour with browse-content(depth=1) operation between archived and exploded deployments
> -------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1851
> URL: https://issues.jboss.org/browse/WFCORE-1851
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha9
> Reporter: Michal Jurc
> Assignee: ehsavoie Hugonnet
> Attachments: jboss-kitchensink-ear.ear
>
>
> {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} operation returns inconsistent result depending on whether the deployment is exploded or not. Deployment attached.
> Archived:
> {code}{
> "outcome" => "success",
> "result" => [
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> },
> {
> "path" => "META-INF/",
> "directory" => true
> }
> ]
> }
> {code}
> Exploded:
> {code}{
> "outcome" => "success",
> "result" => [
> {
> "path" => "META-INF/",
> "directory" => true
> },
> {
> "path" => "META-INF/MANIFEST.MF",
> "directory" => false,
> "file-size" => 130L
> },
> {
> "path" => "jboss-kitchensink-ear-web.war",
> "directory" => false,
> "file-size" => 63190L
> },
> {
> "path" => "jboss-kitchensink-ear-ejb.jar",
> "directory" => false,
> "file-size" => 12256L
> },
> {
> "path" => "META-INF/application.xml",
> "directory" => false,
> "file-size" => 802L
> },
> {
> "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
> "directory" => false,
> "file-size" => 1955L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
> "directory" => false,
> "file-size" => 5582L
> },
> {
> "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
> "directory" => false,
> "file-size" => 143L
> }
> ]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7260:
-----------------------------------
Assignee: Ilia Vassilev
> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
> Key: WFLY-7260
> URL: https://issues.jboss.org/browse/WFLY-7260
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1668) org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1668?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1668:
-------------------------------------------------
Ivo Hradek <ihradek(a)redhat.com> changed the Status of [bug 1358556|https://bugzilla.redhat.com/show_bug.cgi?id=1358556] from ON_QA to VERIFIED
> org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1668
> URL: https://issues.jboss.org/browse/WFCORE-1668
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
> Fix For: 3.0.0.Alpha4
>
> Attachments: reproducer.zip
>
>
> {code}
> helloWorld.ear
> - helloWorld-ejb.jar
> - HelloBean - @Stateless EJB extends AbstractBean
> - lib
> - helloWorld-api.jar
> - META-INF
> - jandex.idx
> - Hello - EJB interface
> - AbstractBean - abstract class which has @PostConstruct and implements Hello
> helloWorld2.ear
> - helloWorld2-ejb.jar
> - HelloBean2 - @Startup @Singleton extends AbstractBean
> - META-INF
> - jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
> {code}
> To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
> When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
> It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
> {code}
> 19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFBUILD-21) Use Woodstox as the StAX engine
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFBUILD-21:
----------------------------------
Summary: Use Woodstox as the StAX engine
Key: WFBUILD-21
URL: https://issues.jboss.org/browse/WFBUILD-21
Project: WildFly Build Tools
Issue Type: Enhancement
Affects Versions: 1.1.3.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
WildFly's XML persister uses Woodstox as its StAX engine.
By using the same engine for the build tools (especially its maven plug-in), we ensure that the XML generated by the build tools is identical to the XML generated by WildFly's XML persister.
Otherwise, there are differences in the XML declaration (WildFly persisted file have the encoding attribute while the XML generated by the build tools does not).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6895) TimerService problem(duplicated resource)
by M G (JIRA)
[ https://issues.jboss.org/browse/WFLY-6895?page=com.atlassian.jira.plugin.... ]
M G commented on WFLY-6895:
---------------------------
What is the status of this issue? Was the fix reviewed? Will it be included in the nearest release?
> TimerService problem(duplicated resource)
> -----------------------------------------
>
> Key: WFLY-6895
> URL: https://issues.jboss.org/browse/WFLY-6895
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Two standalone instances connected into a cluster.
> *Master WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master
> {code}
> *Slave WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100
> {code}
> Both instances has the same singleton policy defined in singleton-full-ha.xml:
> {code}
> <singleton-policy name="scada-singleton" cache-container="server">
> <simple-election-policy>
> <name-preferences>master</name-preferences>
> </simple-election-policy>
> </singleton-policy>
> {code}
> Reporter: Artur Kowalczyk
> Assignee: Tomasz Adamski
>
> I found a problem with TimerService that occurs when your application is configured as a singleton deployment.
> *Test Case*
> # Start master node, the app is also started - OK
> # Start slave node, the app is deployed but bot stared - OK
> # Stop master node, the app is started on slave - OK
> # Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK
> # Stop master node, the app should be started again on slave but an exception occur. - ERROR
> {code}
> 09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-5239:
--------------------------------------
The test fails if -Dnode0 (MYTESTIP_1 != localhost) is used:
{noformat}
./integration-tests.sh -Dts.noSmoke -Dts.clustering -Dtest=XSiteSimpleTestCase -Dnode0=$MYTESTIP_1
{noformat}
{noformat}
Running org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 64.527 sec <<< FAILURE! - in org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
testPutRelayedToBackups(org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase) Time elapsed: 48.265 sec <<< FAILURE!
java.lang.AssertionError: expected:<200> but was:<500>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutRelayedToBackups(XSiteSimpleTestCase.java:144)
Results :
Failed tests:
XSiteSimpleTestCase.testPutRelayedToBackups:144 expected:<200> but was:<500>
{noformat}
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar &#27;[0m&#27;[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &#27;[0mExecuted HTTP request
> &#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months