https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #30 from Rainer Jung ---
I agree.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #29 from Remy Maucherat ---
(In reply to Rainer Jung from comment #28)
> > (In reply to Rainer Jung from comment #25)
> > > Wouldn't it be better to limit the queue and log any exception resulting
> > > from the queue being full?
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #28 from Rainer Jung ---
> (In reply to Rainer Jung from comment #25)
> > Wouldn't it be better to limit the queue and log any exception resulting
> > from the queue being full?
>
> Sure, try it ;)
> (read the scheduled executor
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
Remy Maucherat changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #26 from Remy Maucherat ---
(In reply to Mark Thomas from comment #24)
> First of all I forgot to say thank you to Peter for the thread dump. It was
> extremely helpful.
>
> I'd lean towards increasing the default and minimum
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #25 from Rainer Jung ---
Small addition: I think Rémy mentioned that we are currently using an unlimited
queue for the executor. It is one of the patterns I typically do not like much,
because then problems will go unnoticed for a
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #24 from Mark Thomas ---
First of all I forgot to say thank you to Peter for the thread dump. It was
extremely helpful.
I'd lean towards increasing the default and minimum utility thread count from
one to two. That should fix this
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #23 from Remy Maucherat ---
Ok, I understand it too now, the background processor uses the first thread and
then the deployment task waits in the queue forever. I'll try to add code that
makes parallel deployment use a minimum of
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
Mark Thomas changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #22 from Mark Thomas
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #21 from Remy Maucherat ---
Ok, Mark got it right: only one utility thread (thanks to my bad new default
... now fixed), blocked during deployment. No idea why this happens at this
point.
The log entry here also gave away the
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #20 from Peter ---
Hi,
for the test I used a vanilla tomcat, added startStopThreads="0" startet it
only with the manager webapp and one smnall war-file (Echo.war)
1) after startup I took the first threadump
2) undeployed the the
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #19 from Mark Thomas ---
We still haven't got to the bottom of what is going on here.
Could you reproduce then and then take a thread dump? I am wondering if the
utility thread pool ends up with a single thread and that thread
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #18 from Peter ---
We operate more than 30 of tomcat server with many different webapps. All
server run in a big blade environments in virtual maschines.
New versions of these webapps from many developer gets automatically deployed
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #17 from Remy Maucherat ---
Negative or zero values will now again use
(Runtime.getRuntime().availableProcessors() + value) in Tomcat 9.0.15.
It's not really related to the mysterious behavior, but it shouldn't have been
changed
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #16 from Coty Sutherland ---
Are you able to reproduce the problem 100% of the time? How large are your
webapps and how long does it take to deploy/undeploy? Does the same webapp fail
repeatedly, or are you able to reproduce with
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #15 from Remy Maucherat ---
(In reply to Konstantin Kolinko from comment #14)
> 1. Have you looked into Tomcat log files?
>
> 2. A comment says:
>
>
> This means that the actual number depends on your hardware.
> I wonder what
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #14 from Konstantin Kolinko ---
1. Have you looked into Tomcat log files?
2. A comment says:
This means that the actual number depends on your hardware.
I wonder what is the actual number of cores that Java reports for you.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #13 from Peter ---
We are getting closer.
I testet with startStopThreads="2", startStopThreads="4" and
startStopThreads="8"
In these cases autodeploy is working fine. Only startStopThreads="0" has the
problem.
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #12 from Remy Maucherat ---
Ok, so this turns out rather mysterious. The executor used has an unlimited
queue and any execution rejection or error is supposed to be logged anyway, so
there shouldn't be a problem.
Can you try
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #11 from Peter ---
If I copy a new war in the appBase directory,nothing happens. No message in the
log file. The war does not get unpacked and started until I restart the tomcat.
If I upload a new war-file with the Tomcat Manager
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #10 from Remy Maucherat ---
Except the use of startStopThreads="0" which uses parallel deployment, this
looks like a default configuration.
There is nothing which radically changes in the deployer with parallel
deployment here.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #9 from Peter ---
Hi,
her is my server.xml file. Like mentioned before, I do use exactly the same
with Tomcat 9.0.13 and 9.0.14.
If I remove the attribute startStopThreads="0" from the host element,
autodeployment is working on
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #8 from Mark Thomas ---
Just a thought. I can't reproduce it either. Neither did a code inspection
suggest any potential configuration that would cause it.
Peter - can you provide the server.xml file for the 9.0.14 install that
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #7 from Remy Maucherat ---
(In reply to Mark Thomas from comment #5)
> Related to the server executor refactoring?
That sounds like it, but I cannot reproduce the issue using the steps and
configuration given.
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #5 from Mark Thomas ---
Related to the server executor refactoring?
--- Comment #6 from Mark Thomas ---
Related to the server executor refactoring?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #5 from Mark Thomas ---
Related to the server executor refactoring?
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe,
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #4 from Peter ---
There are no entries in the logfile when I try to redeploy a warfile.
However, I found, that if I turn parallel deployment off, autodeploy is working
with Tomcat 9.0.14 again. (but my tomcat needs significantly
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #3 from Remy Maucherat ---
(In reply to Peter from comment #2)
> I know that startStopThreads="0" uses parallel deployment (as many as cores
> are available).
> I testet on Debian Linux (64 bit, 4 cores, ext4 filesystem) with
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
--- Comment #2 from Peter ---
Hi Remy,
I know that startStopThreads="0" uses parallel deployment (as many as cores are
available).
I testet on Debian Linux (64 bit, 4 cores, ext4 filesystem) with openjdk11,
openjdk8 and oracle jdk8.
Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=63078
Remy Maucherat changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Remy
30 matches
Mail list logo
