September 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2172) Resurrect the mixed domain testing and fix any problems

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-2172: ----------------------------- Description: THis has not been run for quite some time, and needs to be included in the general testing. > Resurrect the mixed domain testing and fix any problems > ------------------------------------------------------- > > Key: WFLY-2172 > URL: https://issues.jboss.org/browse/WFLY-2172 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 8.0.0.CR1 > > > THis has not been run for quite some time, and needs to be included in the general testing. -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2172) Resurrect the mixed domain testing and fix any problems

by Kabir Khan (JIRA)

Kabir Khan created WFLY-2172: -------------------------------- Summary: Resurrect the mixed domain testing and fix any problems Key: WFLY-2172 URL: https://issues.jboss.org/browse/WFLY-2172 Project: WildFly Issue Type: Feature Request Components: Domain Management Reporter: Kabir Khan Assignee: Brian Stansberry Fix For: 8.0.0.CR1 -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2172) Resurrect the mixed domain testing and fix any problems

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-2172: ----------------------------- Priority: Blocker (was: Major) > Resurrect the mixed domain testing and fix any problems > ------------------------------------------------------- > > Key: WFLY-2172 > URL: https://issues.jboss.org/browse/WFLY-2172 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 8.0.0.CR1 > > -- 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

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: -------------------------------- We don't even need to implement the second suggestion (remove all members from subgroups which are not in {{members}}). > 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

10 years, 7 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: -------------------------------- 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

10 years, 7 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

10 years, 7 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

10 years, 7 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

10 years, 7 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

10 years, 7 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

10 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2013