January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5143) Upgrade jboss transactions to 4.3.0.GA (from 4.3.0.Beta2)

by Dimitris Andreadis (JIRA)

Upgrade jboss transactions to 4.3.0.GA (from 4.3.0.Beta2) --------------------------------------------------------- Key: JBAS-5143 URL: http://jira.jboss.com/jira/browse/JBAS-5143 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JB5-Transaction Manager Reporter: Dimitris Andreadis Assigned To: Jonathan Halliday Priority: Critical Fix For: JBossAS-5.0.0.CR1 Upgrade jbossts to a GA version. -- 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

18 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-836) Remoting Endpoint/Listener Deployer

by David Lloyd (JIRA)

Remoting Endpoint/Listener Deployer ----------------------------------- Key: JBREM-836 URL: http://jira.jboss.com/jira/browse/JBREM-836 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Deployer for the Microcontainer that creates and configures a Remoting Endpoint. -- 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

18 years, 5 months

1
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1089) Upgrade to JGroups 2.5

by Tim Fox (JIRA)

Upgrade to JGroups 2.5 ---------------------- Key: JBMESSAGING-1089 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1089 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: AS 5.0 Integration Update to JGroups 2.5 to take advantage of better throughput. We need to ensure the post office code is sufficiently thread safe. We may need to do another release for 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

18 years, 5 months

3
12
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1027) Timeout method gets called with an unspecified caller identity

by Carlo de Wolf (JIRA)

Timeout method gets called with an unspecified caller identity -------------------------------------------------------------- Key: EJBTHREE-1027 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1027 Project: EJB 3.0 Issue Type: Bug Components: Security Affects Versions: AS 4.2.1.GA Reporter: Carlo de Wolf Having a secured bean with a timeout method with @PermitAll, but without an unauthenticatedIdentity will lead to a 'random' identity being used to call the method or no identity at all. The last one leads to EJBAccessExceptions. Spec 18.2.2: "Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity." We must disallow all calls to a timeout method if unauthenticatedIdentity is not set. -- 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

18 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1225) PacketFilter to intercept client2server calls

by Clebert Suconic (JIRA)

PacketFilter to intercept client2server calls --------------------------------------------- Key: JBMESSAGING-1225 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1225 Project: JBoss Messaging Issue Type: Feature Request Components: Messaging Core Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 2.0.0 Alpha In co-relation to the work done at JBMESSAGING-681, I'm adding the capability of intercepting calls on server. -- 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

18 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1175) ThreadlocalPool does not remove active BeanContext instances from InfinitePool

by Galder Zamarreno (JIRA)

ThreadlocalPool does not remove active BeanContext instances from InfinitePool ------------------------------------------------------------------------------ Key: EJBTHREE-1175 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1175 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.2.GA Reporter: Galder Zamarreno Assigned To: Carlo de Wolf Priority: Critical I've done a mental walkthrough of StatelessInstanceInterceptor.invoke() and seems like there might be a leak: 1st ejb3 stateless invocation: call StatelessInstanceInterceptor.invoke() call pool.get() -> start ThreadlocalPool.get() // currentBeanContext is null so create new BeanContext and add it to InfinitePool.active return created BeanContext // currentBeanContext is still null upon return -> end ThreadlocalPool.get() call ejb.invokeNext(); call pool.release(ctx); -> start ThreadlocalPool.release() //currentBeanContext is null so call currentBeanContext.set(ctx); -> end ThreadlocalPool.release() end StatelessInstanceInterceptor.invoke() // created BeanContext is still in InfinitePool.active // currentBeanContext is not null now and contains the ctx created for this invocation 2nd ejb3 stateless invocation: call StatelessInstanceInterceptor.invoke() call pool.get() -> start ThreadlocalPool.get() // currentBeanContext is not null assign currentBeanContext.get to ctx set currentBeanContext to null return ctx // currentBeanContext is null upon return -> end ThreadlocalPool.get() call ejb.invokeNext(); call pool.release(ctx); -> start ThreadlocalPool.release() //currentBeanContext is null so call currentBeanContext.set(ctx); -> end ThreadlocalPool.release() end StatelessInstanceInterceptor.invoke() // BeanContext is still in InfinitePool.active // currentBeanContext is not null now and contains the ctx created for this invocation Looks to me like there's a leak as active contexts are never removed from InfinitePool.active List because currentBeanContext is always null when it the call lands on pool.release(ctx). Screenshots of the memory analysis can be found in the support case. -- 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

18 years, 5 months

2
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-919) deplace JBossXB descriptor processing with JAXB

by William DeCoste (JIRA)

deplace JBossXB descriptor processing with JAXB ----------------------------------------------- Key: EJBTHREE-919 URL: http://jira.jboss.com/jira/browse/EJBTHREE-919 Project: EJB 3.0 Issue Type: Task Affects Versions: AS 4.2.0 CR1 Reporter: William DeCoste Assigned To: William DeCoste -- 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

18 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4673) SARDeployer should throw an error if there is more than one loader repository

by Adrian Brock (JIRA)

SARDeployer should throw an error if there is more than one loader repository ----------------------------------------------------------------------------- Key: JBAS-4673 URL: http://jira.jboss.com/jira/browse/JBAS-4673 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-4.2.1.GA Reporter: Adrian Brock Fix For: JBossAS-4.2.2.GA, JBossAS-5.0.0.GA The SAR Deployer should be throwing an error if it finds more than one loader-repository config. Currently it just ignores the duplicates and uses the first one. The same problem exists in head in ServiceDeploymentParser::parseLoaderRepositoryConfig() which was copied from the SAR deployer. -- 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

18 years, 5 months

3
11
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1148) An ejbCreate method is only valid when an EJB 2.1 view is active

by Carlo de Wolf (JIRA)

An ejbCreate method is only valid when an EJB 2.1 view is active ---------------------------------------------------------------- Key: EJBTHREE-1148 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1148 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Assigned To: Andrew Lee Rubinger Fix For: AS 5.0.0.GA -- 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

18 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1220) When an JBM client encounters an OOM, it causes to hang the JBM server

by Tyronne Wickramarathne (JIRA)

When an JBM client encounters an OOM, it causes to hang the JBM server ---------------------------------------------------------------------- Key: JBMESSAGING-1220 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1220 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.SP3 Environment: Fedora 8, JBM-1.4.0-SP3, JDK-1.5.0_14 Reporter: Tyronne Wickramarathne Assigned To: Tim Fox 1. Connect a JMS Topic Subscriber with limited memory (e.g. -Xmx64m), that buffers an infinite number of messages. 2. Publish messages to JBM, on the same subscribed topic, until the client runs out of memory. 3. Try to connect another client, publish more messages, etc. You should see the problem at this point. 4. Kill the OOM client. The system should recover. 5. at this point, the JBM server gets hanged -- 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

18 years, 5 months

3
18
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 January 2008