September 2008 - jboss-dev-forums

[Design of POJO Server] - Re: JBossWebService WS4EE Deployments and JACC

by alex.loubyansky＠jboss.com

https://jira.jboss.org/jira/browse/JBXB-158 It's fixed and CR14 has been released and included in the AS. Sorry. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175729#4175729 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175729

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 Classloader Leak (EJBTHREE-1442)

by ALRubinger

Thanks for your continued help, Brian. I'd tried (unsuccessfully) to limit the alternate proxy creation before, which resulted in errors in web injection. But probably using the TCCL ain't great either; I'll give it another spin. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175726#4175726 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175726

17 years, 7 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Removing SFSB in HttpSessionListener

by tkimura＠redhat.com

There are 3 scenarios the sessionDestroyed() method is called: * Application is undeployed This is the problem. We need to keep SFSBs here. However, if the application holds local resources like FileInputStream/FileOutputStream within non-SFSB Seam component and relies on the @Destroy method for releasing those resources, it could be leak. If it's implemented within SFSBs, it would be released when SFSBs get timed out. * Sesssion timeout Typically the SFSBs timeout and conversations timeout are lower than session timeout, so it would be cleaned up before session timeout. So SFSBs are already destroyed. * Application calls session.invalidate() Need to clean up entire session, including conversations and SFSBs. So this customized SeamListener would help: | import javax.servlet.http.HttpSessionEvent; | import org.jboss.seam.servlet.SeamListener; | | public class ClusteredJBossSeamListener extends SeamListener { | public void sessionDestroyed(HttpSessionEvent event) { | String threadName = Thread.currentThread().getName(); | // Those are application threads, the application calls the session.invalidate() explicitly | if (threadName.startsWith("http-") || | threadName.startsWith("ajp-")) { | super.sessionDestroyed(event); | } else { | // Don't call ServletLifecycle.endSession(event.getSession()) method, it removes session contents and kills fail over capability | } | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175723#4175723 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175723

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 Classloader Leak (EJBTHREE-1442)

by bstansberry＠jboss.com

>From a JBoss Profiler analysis of this: !--org.jboss.classloader.spi.base.BaseClassLoader@166889468(BaseClassLoader@9f287fc{vfszip:/home/bes/dev/jboss/clean/trunk/testsuite/output/lib/classloader-leak-ejb3.jar}) | !--!--ClassLoaderReference @ java.lang.Class@161343925(interface org.jboss.test.classloader.leak.ejb3.Ejb3StatelessSession) | !--!--!--ReferenceInterface@java.lang.Class(a)370564132(class $Proxy177) | !--!--!--!--arrayRef [Ljava.lang.Object;[0] id=@1684924387 | !--!--!--!--!--FieldReference protected java.lang.Object[] java.util.Vector.elementData=java.util.Vector@1804802967([class $Proxy177, class $Proxy178]) | !--!--!--!--!--!--FieldReference private java.util.Vector java.lang.ClassLoader.classes=org.jboss.classloader.spi.base.BaseClassLoader@1648466027(BaseClassLoader@6241986b{vfsfile:/home/bes/dev/jboss/clean/trunk/build/output/jboss-5.0.0.CR2/server/all/deploy/ejb3-connectors-jboss-beans.xml}) | !--!--!--!--!--!--!--FieldReference private java.lang.ClassLoader org.jboss.classloading.spi.dependency.policy.ClassLoaderPolicyModule.classLoader=org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule@116952494(VFSDeploymentClassLoaderPolicyModule ejb3-connectors-jboss-beans.xml:0.0.0) ... carries on into the default classloading domain. Looks like a proxy class loaded by the ejb3-connectors-jboss-beans.xml classloader is holding a ref to the org.jboss.test.classloader.leak.ejb3.Ejb3StatelessSession loaded from the ejb deployment. I think this is a manifestation of the problem in SessionProxyFactoryBase discussed at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=141165. I bet if you limit the creation of an alternative proxy to cases where the caller classloader's version of the business interface is distinct from the standard one, this leak will go away. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175721#4175721 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175721

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 Classloader Leak (EJBTHREE-1442)

by ALRubinger

Yeah, I'm doing that now and trying to get a version compatible. Current;y it's building me "3.0.0.Alpha1", even from https://svn.jboss.org/repos/jbossremoting/remoting2/trunk S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175705#4175705 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175705

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: JBossWebService WS4EE Deployments and JACC

by alex.loubyansky＠jboss.com

Yes, it's a regression. I am going to work on it tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175703#4175703 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175703

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 Classloader Leak (EJBTHREE-1442)

by anil.saldhana＠jboss.com

Maybe better to just get hold of the Remoting sources, make the changes you wish and test if the leak persists. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175702#4175702 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175702

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 Classloader Leak (EJBTHREE-1442)

by ALRubinger

Some more circumstantial evidence that the leak stems from Remoting ServerThread: * When commenting out the execution of "testSimpleEjb", which fails, the next test in line, "testSimpleEar", fails where it previously passed. * Subsequent invocations of the tests all pass after the first (failed) run. My working theory is that the EJB3 CL is the TCL when the ServerThread is constructed, and therefore remains throughout the life of the ServerThread. Will be posting this to jboss-dev for some wider opinions on proper resolution. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175701#4175701 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175701

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: JBossWebService WS4EE Deployments and JACC

by alex.loubyansky＠jboss.com

Yes, it is. Looking into it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175697#4175697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175697

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 Classloader Leak (EJBTHREE-1442)

by ALRubinger

Changing directions, this seems a bit more likely: java.lang.Thread has a field "contextClassLoader". Remoting ServerThread inherits this, and the ServerThread hangs around after invocations (until timeout). So if the BaseClassLoader instance in there is the one we're leaking, that could be it. Continuing to verify. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175696#4175696 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175696

17 years, 7 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-dev-forums September 2008