February 2009 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by bstansberry＠jboss.com

OK. Note that Bela was using some JDK 6 release; you can tell from the "java.lang.Thread.State: RUNNABLE" in the thread dumps. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206706#4206706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206706

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by adrian＠jboss.org

I've uploaded a second snapshot which includes a fix for the reassignment problem. http://snapshots.jboss.org/maven2/org/jboss/cl/jboss-classloader/2.0.3-SN... i.e. this part of the code should now be back to what it was in JBoss-4.x But Ales says he is going to do the 2.0.3.GA release tonight anway. I'm going to close JBCL-81 since the reassignment problem has all the symptoms of the original problem and it is consistent with the stacktraces posted before. An extra check would be to get a TRACE log (if you reproduce the problem) that has the ClassCircularityError or LinkageError. We only log it as an error if it fails after 10 attempts. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206705#4206705 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206705

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : The reason I think it will be difficult to reproduce the problem is because I think this only occurs when you hit the ClassCircularity bug. | | Perhaps the mod_cluster objects being deserialized trigger the ClassCircularity bug? That may explain why Bela is seeing this with mod_cluster while we haven't gotten a ton of reports on it for AS 5. | It also depends which version of the JDK you use. e.g. Sun claim it is fixed from 1.5.0-b08 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2139628 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206703#4206703 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206703

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by bstansberry＠jboss.com

"adrian(a)jboss.org" wrote : The reason I think it will be difficult to reproduce the problem is because I think this only occurs when you hit the ClassCircularity bug. Perhaps the mod_cluster objects being deserialized trigger the ClassCircularity bug? That may explain why Bela is seeing this with mod_cluster while we haven't gotten a ton of reports on it for AS 5. Still trying to reproduce... Bela said it wasn't that hard for him to reproduce by stumbling into it, so if I can't there's a reasonable chance he'll be able to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206702#4206702 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206702

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : I think I know what the problem is, but if I'm correct it will be very difficult to reproduce the problem. | The reason I think it will be difficult to reproduce the problem is because I think this only occurs when you hit the ClassCircularity bug. The releaseInNextTask == true means that it got a temporary lock on the classloader. Its not the original classloader used to initiate the classloading attempt. This can only occur if the thread owns the classloader so it should in normal circumstances be able to complete the task, release the classloader and reschedule back the other requests. If however, it hits the ClassCircularity problem (see the catch block just above the unlock), it will reschedule that task. So when it does the unlock, it will loop on the reassignment of the task back to the same thread. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206700#4206700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206700

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by adrian＠jboss.org

I think I know what the problem is, but if I'm correct it will be very difficult to reproduce the problem. If you look at the old code in JBoss4, LoadMgr3 in nextTask() when releaseInNextTask == true just removes the lock on the classloader and unassigns the current thread as the owner of the classloader. The important part is that it doesn't try to reschedule any outstanding tasks back to their original threads. That only occurs in endLoadTask(). | if( threadTask.releaseInNextTask == true ) | { | if( trace ) | log.trace("Releasing loadLock and ownership of UCL: "+threadTask.ucl); | synchronized( registrationLock ) | { | loadClassThreads.remove(threadTask.ucl); | } | synchronized( threadTask.ucl ) | { | ucl3.release(); | ucl3.notifyAll(); | } | } | While in JBoss5, it does: | if (threadTask.isReleaseInNextTask()) | threadTask.getClassLoader().unlock(); | The classloader unlock() will always try to reassign the outstanding tasks when it invokes ClassLoaderManager.unregisterLoaderThread() so it is reassigning tasks in both places. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206697#4206697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206697

16 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jboss identity and removal of enterprise

by heiko.braun＠jboss.com

I am currently working on the enterprise module test coverage. Keep it excluded until I fixed it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206655#4206655 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206655

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | My concern was that you had one class for all deployments defined against the | "first" classloader, which could later get redeployed and thus cause that | classloader to leak. | That was the case before https://jira.jboss.org/jira/browse/JBAS-5505 "adrian(a)jboss.org" wrote : | But it does sound like you are generating instrumented classes for things like | java.util.ArrayList in every deployment which could be minimized if they were shared | in the AOP classloader. I get your point about introductions, but isn't that an edge case? Yes, that is an optimization that can be done View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206647#4206647 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206647

16 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - jboss identity and removal of enterprise

by tom.baeyens＠jboss.com

i've just committed a first version of the jboss identity integration. can you guys verify. i tried locally by removing my local versions of the identity component.. but you never know. let me know if this gives any problems for you. the enterprise module didn't work in my case after doing the update. so i excluded it from the main list of modules. does anyone know why enterprise could be giving problems ? if not i'll look at it tomorrow View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206646#4206646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206646

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Chasing illegal URL

by alesj

With the latest VFS (2.2.0-SNAPSHOT) I'm getting this exception when hitting Seam Booking app (although it deployes and eventually renders fine): | 17:36:00,921 ERROR [compiler] Error Loading Library: vfszip:/C:/projects/branches/jbossas/Branch_5_0/build/output/jboss-5.0.1.GA/server/default/deploy/jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/richfaces-ui.jar/META-INFa4j.taglib.xml | java.io.IOException: Cannot find child, root=DelegatingHandler@29869763[path= context=file:/C:/projects/branches/jbossas/Branch_5_0/build/output/jboss-5.0.1.GA/server/default/tmp/ax61p-eoep9z-fqqskbc4-1-fqqskoem-o/jboss-seam-booking.ear real=vfszip:/ | C:/projects/branches/jbossas/Branch_5_0/build/output/jboss-5.0.1.GA/server/default/tmp/ax61p-eoep9z-fqqskbc4-1-fqqskoem-o/jboss-seam-booking.ear], relativePath=/jboss-seam-booking.war/WEB-INF/lib/richfaces-ui.jar/META-INFa4j.taglib.xml/, uri=vfszip:/ | C:/projects/branches/jbossas/Branch_5_0/build/output/jboss-5.0.1.GA/server/default/deploy/jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/richfaces-ui.jar/META-INFa4j.taglib.xml | at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:83) | at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:106) | at org.jboss.virtual.protocol.AbstractVFSHandler.openConnection(AbstractVFSHandler.java:71) | at java.net.URL.openConnection(URL.java:943) | at java.net.URL.openStream(URL.java:1007) | at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.java:404) | at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryConfig.java:431) | at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87) | at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104) | at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:218) | at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:149) | at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:100) | at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:517) | at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:567) | at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) | at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:196) | at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110) | at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) | at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) | at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) | at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) | at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:51) See META-INFa4j.taglib.xml, missing '/'. Any other means of chasing down where this illegal URL comes from, apart from looking at all the related sources? As I've been pushing log into VFS for the last couple of hours w/o success ... ;-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206640#4206640 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206640

16 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009