September 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1707) MergeView: marshalling fails when subgroups are not a subset of members

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1707?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1707: -------------------------------- The marshalling of MergeViews was changed: when a member of a subgroup is not found in the 'members' array, we send index -1 and then the actual address of that member. On reading a -1 as index, we read the actual address and use it. > MergeView: marshalling fails when subgroups are not a subset of members > ----------------------------------------------------------------------- > > Key: JGRP-1707 > URL: https://issues.jboss.org/browse/JGRP-1707 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView: > {noformat} > MergeView: > view={A,B,C,X,Y} > subgroups={A,B,C} {X,Y,Z} > {noformat} > Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace: > {noformat} > 00631037-49819: failed handling incoming message > java.lang.IllegalArgumentException: creator cannot be null > at org.jgroups.ViewId.<init>(ViewId.java:32) > at org.jgroups.ViewId.<init>(ViewId.java:42) > at org.jgroups.View.create(View.java:90) > at org.jgroups.MergeView.readFrom(MergeView.java:119) > at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285) > at org.jgroups.Message.readHeader(Message.java:889) > at org.jgroups.Message.readFrom(Message.java:803) > at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796) > at org.jgroups.protocols.TP.receive(TP.java:1463) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683) > at java.lang.Thread.run(Unknown Source) > {noformat} > SOLUTION: > * When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index > * OR: remove all members from subgroups which are not in {{members}} -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1707) MergeView: marshalling fails when subgroups are not a subset of members

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1707?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1707: -------------------------------- This bug was introduced by JGRP-1391 > MergeView: marshalling fails when subgroups are not a subset of members > ----------------------------------------------------------------------- > > Key: JGRP-1707 > URL: https://issues.jboss.org/browse/JGRP-1707 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView: > {noformat} > MergeView: > view={A,B,C,X,Y} > subgroups={A,B,C} {X,Y,Z} > {noformat} > Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace: > {noformat} > 00631037-49819: failed handling incoming message > java.lang.IllegalArgumentException: creator cannot be null > at org.jgroups.ViewId.<init>(ViewId.java:32) > at org.jgroups.ViewId.<init>(ViewId.java:42) > at org.jgroups.View.create(View.java:90) > at org.jgroups.MergeView.readFrom(MergeView.java:119) > at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285) > at org.jgroups.Message.readHeader(Message.java:889) > at org.jgroups.Message.readFrom(Message.java:803) > at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796) > at org.jgroups.protocols.TP.receive(TP.java:1463) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683) > at java.lang.Thread.run(Unknown Source) > {noformat} > SOLUTION: > * When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index > * OR: remove all members from subgroups which are not in {{members}} -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2171) Use deployment unit processors to register mod_cluster metrics

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-2171: ------------------------------------ Summary: Use deployment unit processors to register mod_cluster metrics Key: WFLY-2171 URL: https://issues.jboss.org/browse/WFLY-2171 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 8.0.0.Beta1 Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Critical Fix For: 8.0.0.Beta1 Remove static dependency and make it runtime using DUPs. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2090) CXF fails with IllegalStateException: UT000005: getRequestChannel() has already been called

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2090?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-2090: -------------------------------------- https://github.com/wildfly/wildfly/commit/b20b8087080f656a021fc9a2ccf5db8... temporary to disable the static linking. proper fix PR coming shortly > CXF fails with IllegalStateException: UT000005: getRequestChannel() has already been called > ------------------------------------------------------------------------------------------- > > Key: WFLY-2090 > URL: https://issues.jboss.org/browse/WFLY-2090 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 8.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 8.0.0.Beta1 > > > asoldano is seeing CXF problems with the latest modcluster undertow integration: > 18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called > at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13] > at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13] > at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13] > at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13] > at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13] > at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13] > at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17] -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1511) RemoteDomainConnection.close() will block forever if the master HC is not running

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1511: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850] Description of problem: RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality. Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/ That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown. A backport of WFLY-1511 to EAP 6.2. > RemoteDomainConnection.close() will block forever if the master HC is not running > ---------------------------------------------------------------------------------- > > Key: WFLY-1511 > URL: https://issues.jboss.org/browse/WFLY-1511 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Beta1 > > > RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality. > Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/ > That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1511) RemoteDomainConnection.close() will block forever if the master HC is not running

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1511: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850] from NEW to ASSIGNED > RemoteDomainConnection.close() will block forever if the master HC is not running > ---------------------------------------------------------------------------------- > > Key: WFLY-1511 > URL: https://issues.jboss.org/browse/WFLY-1511 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Beta1 > > > RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality. > Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/ > That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1511) RemoteDomainConnection.close() will block forever if the master HC is not running

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1511: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012850 > RemoteDomainConnection.close() will block forever if the master HC is not running > ---------------------------------------------------------------------------------- > > Key: WFLY-1511 > URL: https://issues.jboss.org/browse/WFLY-1511 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Beta1 > > > RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality. > Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/ > That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-78) Intermittent failures in RespawnTestCase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-78: --------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809] from ASSIGNED to POST > Intermittent failures in RespawnTestCase > ---------------------------------------- > > Key: WFLY-78 > URL: https://issues.jboss.org/browse/WFLY-78 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Alpha1 > > > Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail. > Failed tests: testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase) > testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase) testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase) > [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/... -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-78) Intermittent failures in RespawnTestCase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-78: --------------------------------------------- Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809] Relevant PR: https://github.com/jbossas/jboss-eap/pull/474 > Intermittent failures in RespawnTestCase > ---------------------------------------- > > Key: WFLY-78 > URL: https://issues.jboss.org/browse/WFLY-78 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Alpha1 > > > Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail. > Failed tests: testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase) > testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase) testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase) > [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/... -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2113) NamingBindingResourceDefinition attribute validation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2113?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2113: ----------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1006206|https://bugzilla.redhat.com/show_bug.cgi?id=1006206] from ON_QA to VERIFIED > NamingBindingResourceDefinition attribute validation > ---------------------------------------------------- > > Key: WFLY-2113 > URL: https://issues.jboss.org/browse/WFLY-2113 > Project: WildFly > Issue Type: Feature Request > Components: Naming > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Fix For: 8.0.0.Beta1 > > > Missing attribute validation may end up on an invalid naming subsystem config, which then prevents server start. For instance it is possible to use the CLI to add a simple binding without value defined, or change an existing resource value attribute to null. -- 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, 9 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 September 2013