[Design of JBoss Profiler] - Re: Class Leakage Tool
by clebert.suconic＠jboss.com
anonymous wrote : which classloader was used to load the class?
I don't know if this is what you meant.. but I never cared about the classLoader holding the class.
Every time I had a class leakage was one of these three scenarios:
- static field holding reference to class/classLoader/reflection
- Class instance/ClassLoader instance being held in a Map
- Class instance being held in a WeakHashMap value. (Values are not weak. Any circular reference between the key and a value will keep a leak)
- Instance of an object referenced.
- Stack Reference to object/class/classLoaders
I never had any case where a classLoader instance is holding a reference to its child classLoaders.
I never cared about this, because if all references are inside the same classLoader, the reference would be gone before getting to the duplicates.
ah... and about EJB3 I guess Bill Burke fixed some of those references, but there might be still some leakage he needs to work on.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967578#3967578
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967578
18 years, 1 month
[Deployers on JBoss (Deployers/JBoss)] - Unable to acess web application
by brp
Hi,
I developed a web application and deployed it in Suse linux9.0 which is inbuilt with thejboss3.2.3. I put my developed war folder into the deploy folder of jboss. When I am trying to access the Web application the first page qhich is login.jsp is displayed from there I am unable to navigate.The server log generated is as follows
2006-08-24 15:30:00,538 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel) [3.2.3 (build: CVSTag=JBoss_3_2_3 date=200407011559)] Started in 11s:848ms
2006-08-24 15:30:15,272 DEBUG [org.apache.tomcat.util.threads.ThreadPool] Getting new thread data
2006-08-24 15:30:17,022 DEBUG [org.apache.tomcat.util.threads.ThreadPool] Getting new thread data
2006-08-24 15:30:17,061 ERROR [org.jboss.web.localhost.Engine] StandardWrapperValve[default]: Servlet.service() for servlet default threw exception ClientAbortException: java.net.SocketException: Broken pipe
at org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java:404)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:428)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:348)
at org.apache.coyote.tomcat4.OutputBuffer.writeBytes(OutputBuffer.java:432)
at org.apache.coyote.tomcat4.OutputBuffer.write(OutputBuffer.java:419)
at org.apache.coyote.tomcat4.CoyoteOutputStream.write(CoyoteOutputStream.java:108)
at org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:1996)
at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:1745)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1073)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:506)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:220)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.jboss.web.tomcat.tc4.statistics.ContainerStatsValve.invoke(ContainerStatsValve.java:76)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:65)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:197)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:781)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:549)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:605)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:677)
at java.lang.Thread.run(Thread.java:534)
2006-08-24 15:30:17,065 INFO [org.jboss.web.localhost.Engine] ErrorDispatcherValve[localhost]: Remote Client Aborted Request, IOException: Broken pipe
Can anybody suggest me in this issue.Its very urgent.
Thank you in advance.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967572#3967572
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967572
18 years, 1 month
[Design of JBoss jBPM] - Re: plan to convert web console to commands
by tom.baeyens＠jboss.com
coming back from a visit to brussels together with jeff delong, i realized the problem is the different transaction strategies is the problem:
* in a ee environment, i want jbpm to be configured for JTA. i don't want the web console to require EJB's. so we need some kind of abstraction between the web console and the ejb's that manage the transactions. that is the command service pattern.
* the problem is that in a POJO environment we can easily manage the transactions ourselves: one transaction for the updates, and after that one transaction for preparing all the data for the new view.
I don't yet see how we can get a good transaction strategy that works on both platforms... unless we can manage JTA transactions from inside the JSF backed beans. i'll investigate a bit further and report if i find something that could mean a solution. i just wanted to keep you up to date on where i just found that the command service based interface between web console and jbpm has problems.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967568#3967568
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967568
18 years, 1 month
[Design of POJO Server] - Re: Behavior with AbstractKernelController
by scott.stark＠jboss.org
The test runs multiple times now in head, but fails at each point because of:
| junit.framework.ComparisonFailure: state is Destroyed expected:<DESTROY...> but was:<FAIL...>
| at junit.framework.Assert.assertEquals(Assert.java:81)
| at org.jboss.test.security.test.DynamicLoginConfigServiceUnitTestCase.testAuthConf(DynamicLoginConfigServiceUnitTestCase.java:165)
|
There is a change in the ServiceController to ignore requests to destroy a service that is in a FAILED state. Previouly only requests for services in ServiceContext.DESTROYED or ServiceContext.NOTYETINSTALLED were ignored.
| 2006-08-25 12:01:26,641 DEBUG [org.jboss.system.ServiceController] destroying se
| rvice: jboss:service=TestDynamicLoginConfig
| 2006-08-25 12:01:26,641 DEBUG [org.jboss.system.ServiceController] Ignoring dest
| roy request for service: jboss:service=TestDynamicLoginConfig at state FAILED
|
If we want backward compatibility we need to define the service state machine diagram with all transitions and require the same under the mc. I'm doubtful that this would be useful as we really should not allow a service to go from an error state liked FAILED to DESTROYED. At this point the service state diagram needs to be defined along with the expected semantics and code updated to conform to it in my view.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967562#3967562
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967562
18 years, 1 month