November 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1002) Merge: make the coordinator remain the same if possible after a merge

by Bela Ban (JIRA)

Merge: make the coordinator remain the same if possible after a merge --------------------------------------------------------------------- Key: JGRP-1002 URL: https://jira.jboss.org/jira/browse/JGRP-1002 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 When we have {C, A, B} and split into {C,A} and {B}, then a merge will produce {A,B,C}. Therefore the coord is moved from C to A. For certain apps, e.g. JBoss singletons, this is not good, as we're moving the singleton services from a perfectly healthy node to a different node. GOAL: come up with a deterministic policy of picking a coord such that we minimize coord switching if the existing coord is still member of the cluster. This depends on or is related to the flexible coord pick policy JIRA issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-7965) jta resource recovery problem

by Nicolae Petridean (JIRA)

jta resource recovery problem ----------------------------- Key: JBAS-7965 URL: https://jira.jboss.org/jira/browse/JBAS-7965 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager (Arjuna) Reporter: Nicolae Petridean Assignee: Jonathan Halliday Priority: Critical Hi all, i noticed that there is some problems with the transaction recovery in JBOSS. When a number of warnings like this : "WARN oggerI18N om.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa om.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa Could not find new XAResource to use for recovering non-serializable XAResource" appear , at some time the exceptions mechanism is affected (the exceptions are not thrown anymore). If the application uses timers those are also blocked (the timeouts dont appear anymore), it seems that the transcations that are not finished are blocking the timers. Why aren't those transactions just ended after some specific time ? Or is there another way to deal with the situation ? Thanks in advance, Nicu -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-7930) Set the port_range on JGroups stacks to 1

by Brian Stansberry (JIRA)

Set the port_range on JGroups stacks to 1 ----------------------------------------- Key: JBAS-7930 URL: https://jira.jboss.org/jira/browse/JBAS-7930 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M4 Lock down the ports. Do this for M4 as it may lead to testsuite troubles on slaves until we identify ports where there aren't conflicts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

7
12
0 / 0

[JBoss JIRA] Created: (JBAS-8632) Domain interface should include versions

by Heiko Rupp (JIRA)

Domain interface should include versions ---------------------------------------- Key: JBAS-8632 URL: https://jira.jboss.org/browse/JBAS-8632 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Alpha1 Reporter: Heiko Rupp The domain interface should for all servers provide the exact version of the server. This should contain also CP and FP tags. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

14
23
0 / 0

[JBoss JIRA] Created: (JBAS-6532) TCLFilter doesn't work in jboss 5 with war's in any documented way

by robert lazarski (JIRA)

TCLFilter doesn't work in jboss 5 with war's in any documented way ------------------------------------------------------------------ Key: JBAS-6532 URL: https://jira.jboss.org/jira/browse/JBAS-6532 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-5.0.0.GA Environment: jdk 6, linux Reporter: robert lazarski Assignee: Scott M Stark Reading this doc: http://www.jboss.org/community/docs/DOC-12203 Indicates a *-exp.war syntax is needed for TCLFilter war use, but there are no files of that type on my system running jboss 5. I've tried all the possible combinations I can think of, posted the problem to the forum, and the result is always that the file sizes and contents of the log files generated are exactly the same for the different war's, ie, no separated content. Here's my current config: <appender name="penguinLog" class="org.apache.log4j.FileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler> <param name="Append" value="false"/> <param name="File" value="${jboss.server.home.dir}/log/penguinLog.log"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="true"/> <param name="DeployURL" value="penguin"/> </filter> </appender> <appender name="wtfLog" class="org.apache.log4j.FileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler> <param name="Append" value="false"/> <param name="File" value="${jboss.server.home.dir}/log/wtfLog.log"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="true"/> <param name="DeployURL" value="wtf-exp.war"/> </filter> </appender> <root> <appender-ref ref="CONSOLE"/> <appender-ref ref="FILE"/> <appender-ref ref="penguinLog"/> <appender-ref ref="wtfLog"/> </root> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

7
13
0 / 0

[JBoss JIRA] Created: (JBWEB-160) XNIO Connector

by Remy Maucherat (JIRA)

XNIO Connector -------------- Key: JBWEB-160 URL: https://jira.jboss.org/jira/browse/JBWEB-160 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Remy Maucherat Assignee: Remy Maucherat Experiment with XNIO connector to determine if it makes sense to include one in JBW. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-6657) managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects

by Ian Springer (JIRA)

managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects ------------------------------------------------------------------------------------------------------------ Key: JBAS-6657 URL: https://jira.jboss.org/jira/browse/JBAS-6657 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Ian Springer Assignee: Scott M Stark Fix For: JBossAS-5.1.0.CR1 These are all MOs that are needed by the Embedded Console. Here's the log output: 10:47:18,464 DEBUG [ProfileServiceFactory] About to load profile via Management View... 10:47:23,964 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null 10:47:23,980 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null 10:47:57,870 WARN [ManagementViewImpl] Failed to merged the following runtime ManagedObjects: {jboss.system:type=ServerInfo/jboss.system:type=ServerInfo=ManagedObject{jboss.system:type=ServerInfo}, jboss.web:name=http-127.0.0.1-8080,type=ThreadPool/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=ThreadPool}, jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor}, jboss.web:host=127.0.0.1,type=Host/=ManagedObject{jboss.web:host=127.0.0.1,type=Host}} 10:48:00,917 DEBUG [ProfileServiceFactory] Loaded profile via Management View in 42453 milliseconds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

4
3
0 / 0

[JBoss JIRA] Created: (JBAS-8679) Add xml comment support to the domain model

by Jason Greene (JIRA)

Add xml comment support to the domain model ------------------------------------------- Key: JBAS-8679 URL: https://jira.jboss.org/browse/JBAS-8679 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jason Greene Fix For: 7.0.0.Beta1 For usability reasons, we should attach an xml comment to the nearest AbstractModelElement, so that they can be recreated when the model is altered. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

4
5
0 / 0

[JBoss JIRA] Created: (JBAS-8140) Standard JTS-based configuration

by Brian Stansberry (JIRA)

Standard JTS-based configuration -------------------------------- Key: JBAS-8140 URL: https://jira.jboss.org/browse/JBAS-8140 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: Unscheduled This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: >> Would like to have a configuration with JBossTM JTS implementation >> already installed and optimized for servers that need distributed >> transactions. Proper transaction management is an advanced topic for >> JBoss admins and having Redhat's expertise already configured on a >> server is very reassuring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
8
0 / 0

[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException

by John Mazzitelli (JIRA)

cannot init cause of ClassCastException --------------------------------------- Key: JBREM-552 URL: http://jira.jboss.com/jira/browse/JBREM-552 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.Beta2 (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod Priority: Minor Fix For: 2.0.0.CR1 (Boon) I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown: java.lang.IllegalStateException: Can't overwrite cause at java.lang.Throwable.initCause(Throwable.java:320) at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447) at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324) at org.jboss.remoting.Client.connect(Client.java:385) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430) at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167) at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820) at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102) Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written). The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor. e.g.: new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e); (notice the ", e" parameter). There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2010