September 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1821) Update to web console 2.0.0.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1821: ----------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1003533|https://bugzilla.redhat.com/show_bug.cgi?id=1003533] from ON_QA to VERIFIED > Update to web console 2.0.0.Final > --------------------------------- > > Key: WFLY-1821 > URL: https://issues.jboss.org/browse/WFLY-1821 > Project: WildFly > Issue Type: Sub-task > Components: Web Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Priority: Blocker > Fix For: 8.0.0.Beta1 > > -- 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-1821) Update to web console 2.0.0.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1821: ----------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> made a comment on [bug 1003533|https://bugzilla.redhat.com/show_bug.cgi?id=1003533] O.K. EAP 6.2.0 ER3 > Update to web console 2.0.0.Final > --------------------------------- > > Key: WFLY-1821 > URL: https://issues.jboss.org/browse/WFLY-1821 > Project: WildFly > Issue Type: Sub-task > Components: Web Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Priority: Blocker > Fix For: 8.0.0.Beta1 > > -- 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 resolved JGRP-1707. ---------------------------- Resolution: Done > 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-1916) Deployer role within domain

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.... ] Heiko Braun updated WFLY-1916: ------------------------------ Parent: (was: WFLY-490) Issue Type: Bug (was: Sub-task) > Deployer role within domain > --------------------------- > > Key: WFLY-1916 > URL: https://issues.jboss.org/browse/WFLY-1916 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > Fix For: 8.0.0.Beta1 > > > There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to: > a) /server-group=* > b) /deployment=* > But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups. -- 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: -------------------------------- The second exception: {noformat} version = 6400 (3.4.0) flags: OOB java.lang.RuntimeException: class for magic number 9625 not found at org.jgroups.util.Util.readOtherAddress(Util.java:967) at org.jgroups.util.Util.readAddress(Util.java:911) at org.jgroups.util.Util.readAddresses(Util.java:1038) at org.jgroups.View.readFrom(View.java:190) at org.jgroups.MergeView.readFrom(MergeView.java:108) 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.tests.ParseMessages.parse(ParseMessages.java:56) at org.jgroups.ParserPcap.main(ParserPcap.java:37) {noformat} is caused by a view of a subgroup not being read correctly. The code is here: {code} public void readFrom(DataInput in) throws Exception { super.readFrom(in); short len=in.readShort(); if(len > 0) { subgroups=new View[len]; for(int i=0; i < len; i++) { int index=in.readShort(); long id=in.readLong(); Address creator=get(index); Address[] mbrs=new Address[in.readShort()]; for(int j=0; j < mbrs.length; j++) mbrs[j]=get(in.readShort()); View view=View.create(creator, id, mbrs); subgroups[i]=view; } } } {code} When {{View.create()}} throws an exception, and there are more views in the subgroups, then we have unread data left, and parsing of the next header will fail. SOLUTION: wrap {{View.create()}} in a try-catch clause and simply skip the view if an exception is thrown > 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-1569) Not possible to reload server when JTS transactions are activated

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1569: ----------------------------------------------- tom.jenkinson(a)redhat.com made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] For information: this has the same severity as 1009931, both are fixed in 4.17.11. > Not possible to reload server when JTS transactions are activated > ----------------------------------------------------------------- > > Key: WFLY-1569 > URL: https://issues.jboss.org/browse/WFLY-1569 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.0.0.Alpha1 > Reporter: Ondřej Chaloupka > Assignee: Stefano Maestri > > When transactions are set for JTS being used > - <jts/> tag under transactions subsystem > - transactions="on" under jacorb subsystem > then it is not possible to reload the server. > The reload causes the following exception being shown. > {code} > 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed > at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409) > at org.jacorb.poa.POA.set_servant(POA.java:1979) > at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > 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] > 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > 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] > Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67) > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) > ... 5 more > {code} -- 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-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

12 years, 9 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

12 years, 9 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

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: -------------------------------- 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

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