tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: [OT] Tomcat listener not coming up - no stuck threads
Date Thu, 15 Dec 2016 21:06:15 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 12/15/16 2:44 PM, Mark Thomas wrote:
> On 15/12/2016 19:35, Christopher Schultz wrote:
>> John,
>> 
>> On 12/14/16 10:01 PM, John D. Ament wrote:
>>> I was feeling ambitious so I gave this a shot.  Here's what I 
>>> changed: 
>>> https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d
3c
>>
>>> 
d1e750b48498ff2
> 
> That was pretty much what I was thinking.
> 
>> My
>> 
>> tack was going to be to create an ExecutorService that didn't 
>> dispatch. That way, less code has to change.
> 
> Seems like more work. And doesn't solve the original problem of the
> main thread holding a lock.

No, it won't hold a lock. The (Abstract)ExecutorService just
dispatches to the execute(Runnable job) method which can simply be:

   job.run()

In that case, only one thread is ever involved: the thread that
submitted the job.

>> The problem with that approach is that, technically, the thread
>> count can change for a variety of reasons and it should behave
>> correctly at the time the contexts are started/stopped.
>> 
>> I'd be interested in some comments on changing the behavior of
>> Tomcat based upon the documentation of startStopThreads. For a
>> value of "1", it explicitly says that 1 thread will be used. I'd
>> be surprised if Tomcat were not to use a single (separate) thread
>> rather than the main thread.
>> 
>> Thing about this use-case: you have an embedded scenario where
>> you want to launch Tomcat and you expect the start() call to
>> return fairly soon so you can continue doing whatever you wanted
>> to do. But instead of using the "1 thread" to start all the
>> contexts, it's using the current thread and blocking you.
> 
> That isn't what happens. The main thread always blocks until all
> the container start threads have completed.

Oh, well, then my use-case seems moot. Or, at least, no
currently-running code will expect that behavior.

>> I'm wondering if we need to invent a new magic number for this. 
>> Unfortunately, 0 is already taken. Perhaps we could use a
>> non-numeric value for this special case.
> 
> I don't see a need for that.

I could imagine a need for that behavior, but there's an easier way
for client code to handle it: launch Tomcat.start() from a separate
thread.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYUwXHAAoJEBzwKT+lPKRYYNwP/36ZY+6XsIU2GgsihjHxCIPe
kixjLj6GZXtc8mhoBWRVg3D16dhG62PhCSt813JIKFZMQQMd/zjuYFV6qqkZlv4D
4k0+wxVGLC9oWZA0awuAfWOiAYeHDUEe6Rwr67oUrmpxNcanvv9uk0URxYWEZjzj
YS5ogX/lxJ/EuYIxz2aOptQ8q6W/fARQTsAdiIL3KWy2kjrDvWH/8V46oQxUwdXJ
ilqnMPvCkTwAyKqeCug4bsDr4V/Xk7gjdqttb0qlntfLYay1WmWx1mAnTCD77V/H
6iCSviICy7dFrif4dfTHJ8SS2a8WxXMPR+ng8daCCaZE4GcNqs7bp1z254626xSw
f/Ob2JPlD8aAsjM6WwAhtdlsE/0DzwkKm0Ski3ejt/A2Uh8V5KfaECyNgg1dRoak
czJxxegVyUotkUjx7nL8nqW3dwb2wFJjhUVb/KKiZrl6TC8ME0Ix8UvcCx+Ldaoe
KDVyJjqDSvEECwHLkCUTMbdX0wCJ2qMoH3ULDXMIEHpot9tkDQEa8iUAC9oS7dP0
zUmPY9syYwTBueRT0taSnpumrZ+iZkQIGPGEfX52kf90O9e8uGTFFSBMCoPpwI0M
OfoH6A7g0I69tHiO05fFicj16Rf5BqoNQvKfn8CCzEJA41Uek9yTETGdlHUcbIZy
NwWg49KyTN9G3o851TmW
=QY5c
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message