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
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,
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
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
Maybe a cache issue (work, conf/Catalina...)
Le 5 oct. 2013 11:48, zmirc m_chi...@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:
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*
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:
...@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
was deployed.
Thank you for such a nice and fast support!
From: Romain Manni-Bucau [via OpenEJB]
ml-node+s979440n4665387...@n4.nabble.com
To: zmirc m_chi...@yahoo.com
Sent: Wednesday, October 2, 2013 10:31 AM
Subject: 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
.nabble.com
To: zmirc m_chi...@yahoo.com
Sent: Monday, September 30, 2013 7:03 AM
Subject: Re: Memory leak by openejb.pool.scheduler
just pushed some hacks about it
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http
: Romain Manni-Bucau [via OpenEJB]
ml-node+s979440n4665357...@n4.nabble.com
To: zmirc m_chi...@yahoo.com
Sent: Monday, September 30, 2013 7:03 AM
Subject: Re: Memory leak by openejb.pool.scheduler
just pushed some hacks about it
*Romain Manni-Bucau*
*Twitter: @rmannibucau https
just pushed some hacks about it
*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/9/29
Hi!
I can confirm that @Schedule is not stopped anymore after redeploying.
That's great.
Now, regarding the leak problem, I've managed to semi-reproduce the error
with a sample project.
https://github.com/zmirc/tomee-memory-bug
https://github.com/zmirc/tomee-memory-bug
Steps for reproducing:
Moreover, with the original project, the one where I discovered this Tomee's
bug, by repeating this cycle more times (run,undeploy,deploy,redeploy
etc...), Tomee can't be stopped anymore. The only solution is to kill the
process.
I didn't get this behavior with this small sample, but I just wanted
Can you test starting/stopping tomee normally (without using manager app =
not using netbeans)
I think i idenyify the issue.
Fyi manager app is not the default in tomee and this usage can get some
cases not tested.
I'll check your sample next week.
Le 28 sept. 2013 11:32, zmirc
catalina.sh to operate Tomee, so no NetBeans or any other tools.
From: Romain Manni-Bucau [via OpenEJB]
ml-node+s979440n4665338...@n4.nabble.com
To: zmirc m_chi...@yahoo.com
Sent: Saturday, September 28, 2013 1:07 PM
Subject: Re: Memory leak by openejb.pool.scheduler
A few more logs related to that, but this ones are taken from production
server.
They appear at stop / restart / undeploy. I think most of them happened when
I was undeploying the app.
I hope they will help.
Sep 20, 2013 7:59:03 AM org.apache.catalina.loader.WebappClassLoader
i know i'm a late-comer, but I have been using NetBeans start/stop tomee+
ever since NetBeans 7.2 or 7.1.2, and using NetBeans 7.3, today, and
start/stop tomee+ works fine. when testing on my development server, i
always stop tomee+, drop WAR (manually) in tomee/webapps, and start. never
have any
i avoid restart and undeploy (in NetBeans); i forgot the reason why, but
many months ago, i just learned that the stuff/stack works great when i
stop - delete unpacked WAR folder - drop new WAR file in tomee/webapps -
start (via NetBeans on development server, and tomcat7w.exe on production
I've just seen the LEAK error logs of Tomme now on another production server,
which runs 1.6.0 from 29.07.13.
I'll try now with the latest Snapshot and come with feedback ASAP.
Thanks.
--
View this message in context:
Greetings,
On Wed, Sep 25, 2013 at 12:39 PM, Romain Manni-Bucau
rmannibu...@gmail.com wrote:
I was not able to reproduce the leak on trunk but only the other issue. I
opened https://issues.apache.org/jira/browse/TOMEE-1048
Thanks for that fix, I see it has dramatically improved 1.6.0-SNAPSHOT
Hi
Thats related to hsql. Define your datasource in
src/main/tomee/conf/tomee.xml and it should be gone
Side note: you can type quit to shutdown the container instead of ctl+c
with mvn plugin
Le 27 sept. 2013 21:12, jieryn jie...@gmail.com a écrit :
Greetings,
On Wed, Sep 25, 2013 at 12:39
redeploy the
app once.
From: Romain Manni-Bucau [via OpenEJB]
ml-node+s979440n4665267...@n4.nabble.com
To: zmirc m_chi...@yahoo.com
Sent: Wednesday, September 25, 2013 6:43 AM
Subject: Re: Memory leak by openejb.pool.scheduler
Hi
Do you configure quartz?
Le
to the discussion
below:
http://openejb.979440.n4.nabble.com/Memory-leak-by-openejb-pool-scheduler-tp4665263p4665267.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
m_chi...@yahoo.com
Sent: Wednesday, September 25, 2013 10:46 AM
Subject: Re: Memory leak by openejb.pool.scheduler
Hi
can you push us a sample reproducing it please?
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com
not necessary.
From: Romain Manni-Bucau [via OpenEJB]
ml-node+s979440n4665276...@n4.nabble.com
To: zmirc m_chi...@yahoo.com
Sent: Wednesday, September 25, 2013 10:46 AM
Subject: Re: Memory leak by openejb.pool.scheduler
Hi
can you push us a sample reproducing
.
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-tp4665263p4665267.html
To unsubscribe from Memory leak by openejb.pool.scheduler, click here
Where is that ~/.openejb/system.properties?
I have @Singleton EJB with @Schedule methods.
I'm trying right now to reproduce the bug with a new small project. While
working on it, I found 2 more bugs:
1. Supposing that we have an app deployed. I add one more @Schedule method
inside one if its
The only solution for no.2 is to stop Tomee and start it again. Redeploying x
times won't help to get those @Schedule methods start automatically inside
the @Singleton @Startup EJB.
That's actually quite a big problem.
--
View this message in context:
Hi
I was not able to reproduce the leak on trunk but only the other issue. I
opened https://issues.apache.org/jira/browse/TOMEE-1048
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
I'm happy that you fixed that bug. Thank you!
I'm under huge pressure because of a very random and not reproducible bug,
therefore I have to post-pone a little bit isolating the leaking error into
a sample project.
I would really appreciate if someone could help. I'm desperate because of
it. The
I didnt mention it but even if I was not sure of the issue (think it was
fixed already) I forced even more Thread loaders (directly when threads
were created). If you still have it now, a sample will be really mandatory
Le 26 sept. 2013 00:02, zmirc m_chi...@yahoo.com a écrit :
I'm happy that
Hi!
Using Tomee 1.6.0 2013.09.20, I get this when I try to stop Tomee, which has
a ROOT application that uses EJB @Schedule:
25-Sep-2013 00:06:09.745 WARNING [localhost-startStop-2]
org.apache.openejb.assembler.classic.Assembler.destroyApplication
Application id 'ROOT' not found in: [openejb]
Hi
Do you configure quartz?
Le 25 sept. 2013 00:17, zmirc m_chi...@yahoo.com a écrit :
Hi!
Using Tomee 1.6.0 2013.09.20, I get this when I try to stop Tomee, which
has
a ROOT application that uses EJB @Schedule:
25-Sep-2013 00:06:09.745 WARNING [localhost-startStop-2]
35 matches
Mail list logo
