January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1052) When running stress tests wrong log4j.xml is picked up

by Tim Fox (JIRA)

When running stress tests wrong log4j.xml is picked up ------------------------------------------------------ Key: JBMESSAGING-1052 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1052 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.CR2 When running stress tests, the log4j.xml from tests/etc, but the log4j.xml from tests/etc/stress isn't being used. This means stress tests are being run on trace logging, which is incorrect (makes them take ages) -- 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

15 years, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1126) ClusterViewUpdateTest::testGarbageCollectionOnClusteredCF fails on Hudson

by Tim Fox (JIRA)

ClusterViewUpdateTest::testGarbageCollectionOnClusteredCF fails on Hudson ------------------------------------------------------------------------- Key: JBMESSAGING-1126 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1126 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Clebert Suconic Fix For: AS 5.0 Integration, EAP 4.3 Integration This test fails on Hudson. The test makes assumptions about when Garbage collection is going to occur so IMHO is not a valid test. We cannot ever be sure GC is going to occur - this is up the JVM implementation to decide. The test has been commented out until this is resolved. -- 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

15 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-448) Provide schema for protocol stack configuration

by Bela Ban (JIRA)

Provide schema for protocol stack configuration ----------------------------------------------- Key: JGRP-448 URL: http://jira.jboss.com/jira/browse/JGRP-448 Project: JGroups Issue Type: Feature Request Affects Versions: 2.5 Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.6 This would allow for: - list of options for each protocol - description of that option - option completion in most IDEs -- 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

15 years, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-955) Port EJBTHREE-954 to trunk

by Brian Stansberry (JIRA)

Port EJBTHREE-954 to trunk -------------------------- Key: EJBTHREE-955 URL: http://jira.jboss.com/jira/browse/EJBTHREE-955 Project: EJB 3.0 Issue Type: Sub-task Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: EJB 3.0 RC11 - FD -- 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

15 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (HIBERNATE-50) Embedded Objects get set to null if all its members are null

by milan w?lke (JIRA)

Embedded Objects get set to null if all its members are null ------------------------------------------------------------ Key: HIBERNATE-50 URL: http://jira.jboss.com/jira/browse/HIBERNATE-50 Project: Hibernate Issue Type: Bug Environment: WinXP SP2, JBoss 4.0.4 GA as well as JBoss 4.0.5 GA, installation profile ejb3 Reporter: milan w?lke Assigned To: Steve Ebersole When having an embedded object only containing members of non-simple-types (e.g. String) and fetching it with the entity manager the following happens: If all columns, the embedded objects values are based on, are null the embedded object itself is set to null even if a non-arg-constructor set it to a non-null value before. A valid workaround is to include a member of a simple-type (e.g. int) in the embedded object. Doing this not all the values can be set to null, which results in not setting the embedded object itself to null, too. -- 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

15 years, 11 months

13
16
0 / 0

[JBoss JIRA] Created: (JBJMX-105) Reassess response to JBJMX-101

by David Wade (JIRA)

Reassess response to JBJMX-101 ------------------------------ Key: JBJMX-105 URL: http://jira.jboss.com/jira/browse/JBJMX-105 Project: JBoss JMX Issue Type: Sub-task Affects Versions: JBossAS-4.0.0 Reporter: David Wade The suggested work around for the NullPointerException reported in JBJMX-101 is a bit of a cop-out and disregards the often quite complex deployment environments in which we often find ourselves where communicating such a around is neither trivial or professional looking. Can we reassess the original response with a view to perhaps fixing the issue? -- 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

15 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-133) Multiplexer documentation

by Brian Stansberry (JIRA)

Multiplexer documentation ------------------------- Key: JBCLUSTER-133 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-133 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q4Y6 -- 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

15 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-134) Buddy replication documentation for http sessions

by Brian Stansberry (JIRA)

Buddy replication documentation for http sessions ------------------------------------------------- Key: JBCLUSTER-134 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-134 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q4Y6 -- 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

15 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-3647) Backport SingleRetryInterceptor to 3.2

by Scott M Stark (JIRA)

Backport SingleRetryInterceptor to 3.2 -------------------------------------- Key: JBAS-3647 URL: http://jira.jboss.com/jira/browse/JBAS-3647 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering, EJB2 Affects Versions: JBossAS-3.2.8.SP1 Reporter: Scott M Stark Assigned To: Brian Stansberry A 3.2.8.SP1 client attempting to connect to a 4.0.4 clustered bean fails with the following error due to the SingleRetryInterceptor not being available in 3.2.8.SP1: 2006-09-12 16:44:30,178 [Thread-0::] - javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException: org.jboss.proxy.ejb.SingleRetryInterceptor (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:318) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:132) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:143) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) We should backport this. -- 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

15 years, 11 months

4
4
0 / 0

[JBoss JIRA] Created: (JBAS-4505) Inter-jar dependencies between clustered EJBs leads to bean not accepting requests

by Brian Stansberry (JIRA)

Inter-jar dependencies between clustered EJBs leads to bean not accepting requests ---------------------------------------------------------------------------------- Key: JBAS-4505 URL: http://jira.jboss.com/jira/browse/JBAS-4505 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, EJB2 Affects Versions: JBossAS-4.2.0.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Scenario: 2 clustered EJB2 beans, A and B, deployed in A.jar and B.jar. A declares a dependency on B via a <depends> in jboss.xml. A.jar gets deployed before B.jar. Problem: The latch in bean A's HATarget that allows invocations to reach the bean never gets released. The bean is available in JNDI, but any thread that attempts to invoke on it will block (forever) on the latch. The bean becomes a black hole for threads. Cause: ProxyFactoryHA registers a JMX NotificationListener to listen for a service started event. Receipt of that event triggers release of the latch. Problem is it listeners for the start of the EJB module (A.jar) rather than the target bean. Reason for this is described in the ProxyFactoryHA.create() method: // ************************************************************************ // NOTE: We could also subscribe for the container service events instead of the // ejbModule service events. This problem comes from beans using other beans // in the same ejbModule: we may receive an IllegalStateException thrown // by the Container implementation. Using ejbModule events solve this // problem. // ************************************************************************ this.container.getServer (). addNotificationListener (this.container.getEjbModule ().getServiceName (), new ProxyFactoryHA.StateChangeListener (), filter, null); My interpretation of the comment is that if you allow access to the bean before the entire module is started, and the bean calls into a 2nd bean in the same module, then a request could come it via the 1st bean that tries to prematurely access the 2nd bean. Waiting for the entire module to start is intended to prevent this. The assumption here is that all beans within the module will complete the start phase before the module itself. Problem is the depends element on a bean breaks this assumption. What happens is you get the following start order: A.jar bean B bean A B.jar Effect is the notification for A.jar start happens before the HATarget for bean A even exists. The latch that A's HATarget later creates will thus never get released. -- 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

15 years, 11 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008