You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by zmirc <m_...@yahoo.com> on 2013/10/01 20:00:40 UTC
Re: Memory leak by openejb.pool.scheduler
Hi!
I'm back with feedback for 1.6.0 2013.10.01.
1. I don't see the leak log anymore.
2. @Schedule seems to be properly working after restart.
2.1. During redeployment, all @Schedule executions crash once, which
generates a huge amount of logs. That's something new that happens. They
shouldn't start if deployment is not done...or...whatever other protection,
because the current situation is not so desired.
/// I have attached the complete logs generated at a redeployment
redeploy-log.txt
<http://openejb.979440.n4.nabble.com/file/n4665382/redeploy-log.txt>
One more strange thing:
1. Deploy the big project, the one with many @Schedule.
2. Undeploy it.
3. Deploy the sample project used for reproducing the @Schedule leak bug.
During deployment, errors appear for @Schedule of the big project. This
shouldn't happen because that project was undeployed before.
--
View this message in context: http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665382.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Memory leak by openejb.pool.scheduler
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
please disregard. it was not a 'tomee' caching issue. it was a developer
issue (my fault). i only updated a few of the xhtml pages that I needed to
update instead of updating all xhtml pages...that needed to be udpated.
my app is working now. :)
On Sun, Oct 6, 2013 at 6:10 PM, Howard W. Smith, Jr. <smithh032772@gmail.com
> wrote:
> wow, i think I'm experiencing some caching issue. I decided to download
> 2013-Oct-05 based on this thread/discussion/topic, I made some changes to
> beans (java classes) and xhtml pages, and now it seems as though my xhtml
> pages are trying to reference the old bean, when I modified xhtml pages to
> reference the new bean that I been developing 'today'.
>
> I deleted files/folders in tomee/work, and there really were no files in
> tomee/conf/Catalina (that seemed to be deleted), but I did delete the
> 'cached' copy of my webapp in tomee/work, and I am deleting the
> unpacked-war-folder from tomee/webapps that was created when I started
> tomee.
>
> on my development server, I always:
>
> 1. stop tomee (via netbeans)
> 2. delete unpacked-war-folder in tomee/webapps
> 3. drop-and-overwrite WAR file in tomee/webapps
> 4. start tomee (via netbeans)
>
> and stuff works, but now, I cannot figure out how to get past this
> 'caching' behavior related to start/stop-tomee-via-netbeans.
>
> i hope i don't need to revert to previous version of tomee 1.6.0-snapshot
> that I downloaded some days ago.
>
>
> On Sat, Oct 5, 2013 at 5:54 AM, Romain Manni-Bucau <rm...@gmail.com>wrote:
>
>> Maybe a cache issue (work, conf/Catalina...)
>
>
>
>
Re: Memory leak by openejb.pool.scheduler
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
wow, i think I'm experiencing some caching issue. I decided to download
2013-Oct-05 based on this thread/discussion/topic, I made some changes to
beans (java classes) and xhtml pages, and now it seems as though my xhtml
pages are trying to reference the old bean, when I modified xhtml pages to
reference the new bean that I been developing 'today'.
I deleted files/folders in tomee/work, and there really were no files in
tomee/conf/Catalina (that seemed to be deleted), but I did delete the
'cached' copy of my webapp in tomee/work, and I am deleting the
unpacked-war-folder from tomee/webapps that was created when I started
tomee.
on my development server, I always:
1. stop tomee (via netbeans)
2. delete unpacked-war-folder in tomee/webapps
3. drop-and-overwrite WAR file in tomee/webapps
4. start tomee (via netbeans)
and stuff works, but now, I cannot figure out how to get past this
'caching' behavior related to start/stop-tomee-via-netbeans.
i hope i don't need to revert to previous version of tomee 1.6.0-snapshot
that I downloaded some days ago.
On Sat, Oct 5, 2013 at 5:54 AM, Romain Manni-Bucau <rm...@gmail.com>wrote:
> Maybe a cache issue (work, conf/Catalina...)
Re: Memory leak by openejb.pool.scheduler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Maybe a cache issue (work, conf/Catalina...)
Le 5 oct. 2013 11:48, "zmirc" <m_...@yahoo.com> a écrit :
> This error appeared once during deployment.
> I did a lot of tries and deployed / redeployed 15-20 times, but it didn't
> appear again.
> Maybe the stack trace will help.
>
> The interesting part is: the error complains about EJB EmailC, but the
> second log line (Retrieved 0 unsent e-mails from DB) shows how it has been
> successfully initialized.
>
> 05-Oct-2013 11:08:23.829 INFO [http-bio-8080-exec-50]
> org.apache.tomee.catalina.TomcatWebAppBuilder.deployWebApps using context
> file
>
> C:\Users\Mircea\Documents\NetBeansProjects\pingushare\target\ROOT\META-INF\context.xml
> javax.naming.NameAlreadyBoundException: ParsedName{path=EmailC,
> component=EmailC}
> at
> org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:148)
> 2013-10-05 11:08:24,576 INFO [EjbTimerPool - 2] c.p.c.EmailC
> [EmailC.java:46] Retrieved 0 unsent e-mails from DB
> at
> org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:164)
> at
> org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:164)
> at
> org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:164)
> at
> org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:164)
> at
> org.apache.openejb.core.ivm.naming.IvmContext.bind(IvmContext.java:300)
> at
> org.apache.openejb.core.ivm.naming.IvmContext.rebind(IvmContext.java:313)
> at
>
> org.apache.openejb.assembler.classic.Assembler.bindGlobals(Assembler.java:913)
> at
>
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:864)
> at
>
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:612)
> at
>
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1144)
> at
>
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1007)
> at
>
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:127)
> at
>
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> at
>
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> at
>
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
>
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
> at
>
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:656)
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:535)
> at
> org.apache.catalina.startup.HostConfig.check(HostConfig.java:1461)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
>
> org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
> at
>
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1445)
> at
> org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:860)
> at
> org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:357)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
>
> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> at
>
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
> at
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
>
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
> at
>
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> at
>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665425.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: Memory leak by openejb.pool.scheduler
Posted by zmirc <m_...@yahoo.com>.
This error appeared once during deployment.
I did a lot of tries and deployed / redeployed 15-20 times, but it didn't
appear again.
Maybe the stack trace will help.
The interesting part is: the error complains about EJB EmailC, but the
second log line (Retrieved 0 unsent e-mails from DB) shows how it has been
successfully initialized.
05-Oct-2013 11:08:23.829 INFO [http-bio-8080-exec-50]
org.apache.tomee.catalina.TomcatWebAppBuilder.deployWebApps using context
file
C:\Users\Mircea\Documents\NetBeansProjects\pingushare\target\ROOT\META-INF\context.xml
javax.naming.NameAlreadyBoundException: ParsedName{path=EmailC,
component=EmailC}
at org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:148)
2013-10-05 11:08:24,576 INFO [EjbTimerPool - 2] c.p.c.EmailC
[EmailC.java:46] Retrieved 0 unsent e-mails from DB
at org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:164)
at org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:164)
at org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:164)
at org.apache.openejb.core.ivm.naming.NameNode.bind(NameNode.java:164)
at org.apache.openejb.core.ivm.naming.IvmContext.bind(IvmContext.java:300)
at
org.apache.openejb.core.ivm.naming.IvmContext.rebind(IvmContext.java:313)
at
org.apache.openejb.assembler.classic.Assembler.bindGlobals(Assembler.java:913)
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:864)
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:612)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1144)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1007)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:127)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:656)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:535)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1461)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at
org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1445)
at
org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:860)
at
org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
--
View this message in context: http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665425.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Memory leak by openejb.pool.scheduler
Posted by zmirc <m_...@yahoo.com>.
Everything seems to work flawlessly now with 1.6.0 from 2013.10.05. I love
it!!!
Moreover,
AbstractHttp11Processor-process-Error-processing-request-td4665383.html
<http://openejb.979440.n4.nabble.com/AbstractHttp11Processor-process-Error-processing-request-td4665383.html>
doesn't appear neither.
I didn't put it in production yet, but it seems good in my local
environment.
Thank you so much!
--
View this message in context: http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665424.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Memory leak by openejb.pool.scheduler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yep somebody broke the build, should be fixed now.
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/10/3 zmirc <m_...@yahoo.com>
> Hi!
>
> I wanted to test now with the latest snapshot (2013.10.03), but it doesn't
> seem to be uploaded on
> http://tomee.apache.org/download/tomee-1.6.0-snapshot.html
> The last one is from yesterday, so it seems that something it's wrong with
> it.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665398.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: Memory leak by openejb.pool.scheduler
Posted by zmirc <m_...@yahoo.com>.
Hi!
I wanted to test now with the latest snapshot (2013.10.03), but it doesn't
seem to be uploaded on
http://tomee.apache.org/download/tomee-1.6.0-snapshot.html
The last one is from yesterday, so it seems that something it's wrong with
it.
--
View this message in context: http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665398.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Memory leak by openejb.pool.scheduler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I understood the issue but not the steps to reproduce it (where should i
download the "big project" typically).
That said if you can build tomee from sources and test again I hope my fix
helped
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/10/2 zmirc <m_...@yahoo.com>
> Hi!
>
> Sorry, but I didn't actually understand what your message was in the last
> reply.
> Did my report helped somehow and you've added a new fix or...?
>
> Regarding the second part, the following:
> > One more strange thing:
> > 1. Deploy the big project, the one with many @Schedule.
> > 2. Undeploy it.
> > 3. Deploy the sample project used for reproducing the @Schedule leak
> bug.
> > During deployment, errors appear for @Schedule of the big project. This
> > shouldn't happen because that project was undeployed before.
>
>
> I will try to say it again. Basically, I deploy a project which has some
> @Schedule methods. I undeploy it, then I deploy a completely other project.
> During deployment of the latest one, the @Schedule from the first project
> throw errors exactly how it happens in the first part of my last reply,
> when I was redeploying the same project.
> > 2.1. During redeployment, all @Schedule executions crash once, which
> > generates a huge amount of logs. That's something new that happens. They
> > shouldn't start if deployment is not done...or...whatever other
> protection,
> > because the current situation is not so desired.
> My question about the above is: why do those logs appear for @Schedule
> methods that shouldn't exist anymore in Tomee, because that project was
> undeployed before the new one was deployed.
>
> Thank you for such a nice and fast support!
>
>
> ________________________________
> From: Romain Manni-Bucau [via OpenEJB] <
> ml-node+s979440n4665387h61@n4.nabble.com>
> To: zmirc <m_...@yahoo.com>
> Sent: Wednesday, October 2, 2013 10:31 AM
> Subject: Re: Memory leak by openejb.pool.scheduler
>
>
>
> Hmm
>
> Not sure I got the "big project" side of your answer but I hacked it a bit
> (in particular the restart step which was something I never understood how
> it could work and you prooved it was not working ;).
>
>
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/10/1 zmirc <[hidden email]>
>
>
> > Hi!
> >
> > I'm back with feedback for 1.6.0 2013.10.01.
> > 1. I don't see the leak log anymore.
> > 2. @Schedule seems to be properly working after restart.
> > 2.1. During redeployment, all @Schedule executions crash once, which
> > generates a huge amount of logs. That's something new that happens. They
> > shouldn't start if deployment is not done...or...whatever other
> protection,
> > because the current situation is not so desired.
> >
> > /// I have attached the complete logs generated at a redeployment
> > redeploy-log.txt
> > <http://openejb.979440.n4.nabble.com/file/n4665382/redeploy-log.txt>
> >
> > One more strange thing:
> > 1. Deploy the big project, the one with many @Schedule.
> > 2. Undeploy it.
> > 3. Deploy the sample project used for reproducing the @Schedule leak bug.
> > During deployment, errors appear for @Schedule of the big project. This
> > shouldn't happen because that project was undeployed before.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665382.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
> >
>
>
> ________________________________
>
> If you reply to this email, your message will be added to the discussion
> below:
> http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665387.html
> To unsubscribe from Memory leak by openejb.pool.scheduler, click here.
> NAML
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665388.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: Memory leak by openejb.pool.scheduler
Posted by zmirc <m_...@yahoo.com>.
Hi!
Sorry, but I didn't actually understand what your message was in the last reply.
Did my report helped somehow and you've added a new fix or...?
Regarding the second part, the following:
> One more strange thing:
> 1. Deploy the big project, the one with many @Schedule.
> 2. Undeploy it.
> 3. Deploy the sample project used for reproducing the @Schedule leak bug.
> During deployment, errors appear for @Schedule of the big project. This
> shouldn't happen because that project was undeployed before.
I will try to say it again. Basically, I deploy a project which has some @Schedule methods. I undeploy it, then I deploy a completely other project. During deployment of the latest one, the @Schedule from the first project throw errors exactly how it happens in the first part of my last reply, when I was redeploying the same project.
> 2.1. During redeployment, all @Schedule executions crash once, which
> generates a huge amount of logs. That's something new that happens. They
> shouldn't start if deployment is not done...or...whatever other protection,
> because the current situation is not so desired.
My question about the above is: why do those logs appear for @Schedule methods that shouldn't exist anymore in Tomee, because that project was undeployed before the new one was deployed.
Thank you for such a nice and fast support!
________________________________
From: Romain Manni-Bucau [via OpenEJB] <ml...@n4.nabble.com>
To: zmirc <m_...@yahoo.com>
Sent: Wednesday, October 2, 2013 10:31 AM
Subject: Re: Memory leak by openejb.pool.scheduler
Hmm
Not sure I got the "big project" side of your answer but I hacked it a bit
(in particular the restart step which was something I never understood how
it could work and you prooved it was not working ;).
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/10/1 zmirc <[hidden email]>
> Hi!
>
> I'm back with feedback for 1.6.0 2013.10.01.
> 1. I don't see the leak log anymore.
> 2. @Schedule seems to be properly working after restart.
> 2.1. During redeployment, all @Schedule executions crash once, which
> generates a huge amount of logs. That's something new that happens. They
> shouldn't start if deployment is not done...or...whatever other protection,
> because the current situation is not so desired.
>
> /// I have attached the complete logs generated at a redeployment
> redeploy-log.txt
> <http://openejb.979440.n4.nabble.com/file/n4665382/redeploy-log.txt>
>
> One more strange thing:
> 1. Deploy the big project, the one with many @Schedule.
> 2. Undeploy it.
> 3. Deploy the sample project used for reproducing the @Schedule leak bug.
> During deployment, errors appear for @Schedule of the big project. This
> shouldn't happen because that project was undeployed before.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665382.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
________________________________
If you reply to this email, your message will be added to the discussion below:http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665387.html
To unsubscribe from Memory leak by openejb.pool.scheduler, click here.
NAML
--
View this message in context: http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665388.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Memory leak by openejb.pool.scheduler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm
Not sure I got the "big project" side of your answer but I hacked it a bit
(in particular the restart step which was something I never understood how
it could work and you prooved it was not working ;).
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/10/1 zmirc <m_...@yahoo.com>
> Hi!
>
> I'm back with feedback for 1.6.0 2013.10.01.
> 1. I don't see the leak log anymore.
> 2. @Schedule seems to be properly working after restart.
> 2.1. During redeployment, all @Schedule executions crash once, which
> generates a huge amount of logs. That's something new that happens. They
> shouldn't start if deployment is not done...or...whatever other protection,
> because the current situation is not so desired.
>
> /// I have attached the complete logs generated at a redeployment
> redeploy-log.txt
> <http://openejb.979440.n4.nabble.com/file/n4665382/redeploy-log.txt>
>
> One more strange thing:
> 1. Deploy the big project, the one with many @Schedule.
> 2. Undeploy it.
> 3. Deploy the sample project used for reproducing the @Schedule leak bug.
> During deployment, errors appear for @Schedule of the big project. This
> shouldn't happen because that project was undeployed before.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665382.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>