You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2016/12/14 16:23:56 UTC
Re: [OT] Tomcat listener not coming up - no stuck threads
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 12/8/16 4:19 AM, Mark Thomas wrote:
> On 07/12/2016 15:21, Christopher Schultz wrote:
>>
>> Hmm... there is the "startStopThreads" setting on the Engine,
>> but unfortunately there is not (currently available) setting that
>> says "don't use multiple threads at all". It looks like Tomcat is
>> always going to use at least one (separate) thread to launch the
>> various Hosts (and webapps).
>
> It wouldn't be too hard to change that to not use an executor if
> the default of startStopThreads="1" was being used.
+1 to running start on the main thread if startStopThreads="1".
Where would I look to start working on a proposed patch? The Tomcat
Lifecycle isn't my strong suit.
> However...
Even if this doesn't solve John's problem, I think it's worth doing.
Comments?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYUXIcAAoJEBzwKT+lPKRYuWsQAMhrAt3mFLGio4u16ZABWLyG
vPwlNRH24l9AnXu2yJ2FALS0ydIB8RTKW7BlwsdrlVAINQ8I0tWXFY4cn7jnMox3
GLyg0ABmSIYqO/Qxqd4YIILBWWycNmvWn8BBgfLvqJaVDO/VB8vrsGClBnVbuqh8
UetcFoCuIjXWpSQFBI7NhPouE4C145eMrmSmbz0Go7jtBPEfib5dgF26QepfX56M
+ds8CDJc9OLusGSCvNgzYu7HXo3fBAFr52LoykQn6IqJbfv0PduiX8ySbLceBXpa
VGlD9Fb9P/08wgANgBs7cbgkmxaEU/PnpXB/B5Mx8QbBV08Ajch3Rxedc2ikqMgi
GP0n8xYzk0GaeEl8VSEwIQCbkib8kz4cR8s+nsiDwcq1WkFrIUqqr0UapN3dyRAS
ySlfFyYN+Wbhe37lRjjQrMDsVcS8mX7t9ELKYRQ3difkmKeeme6D60tyNX/gEUPp
NqHFeOknpgNw/Orj3KM6v1b9BAeRstFelx+kAffrc0G9Gz9GG8+BY7ThBvdfrSZO
wp/ufXhmyVta57qVmmpwR7ua3b5npbCvgkIos6GTu2dKRMqRj2pBPBA3f9HyT82S
1IsYM72RhCTimrmskIb2/G6okRNa1aft5f3iypwsG6J1+ZLxgYROZVWfTbdA9WRS
2/n3/Gtg2yi9GhED0luy
=FbNM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Tomcat listener not coming up - no stuck threads
Posted by "John D. Ament" <jo...@apache.org>.
On Wed, Dec 14, 2016 at 11:23 AM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 12/8/16 4:19 AM, Mark Thomas wrote:
> > On 07/12/2016 15:21, Christopher Schultz wrote:
> >>
> >> Hmm... there is the "startStopThreads" setting on the Engine,
> >> but unfortunately there is not (currently available) setting that
> >> says "don't use multiple threads at all". It looks like Tomcat is
> >> always going to use at least one (separate) thread to launch the
> >> various Hosts (and webapps).
> >
> > It wouldn't be too hard to change that to not use an executor if
> > the default of startStopThreads="1" was being used.
>
> +1 to running start on the main thread if startStopThreads="1".
>
> Where would I look to start working on a proposed patch? The Tomcat
> Lifecycle isn't my strong suit.
>
> > However...
>
> Even if this doesn't solve John's problem, I think it's worth doing.
>
Having an option to startStop on the main thread would fix my issue.
However would that be when startStopThreads = 1 or some other parameter (to
not break compatibility) ?
John
>
> Comments?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYUXIcAAoJEBzwKT+lPKRYuWsQAMhrAt3mFLGio4u16ZABWLyG
> vPwlNRH24l9AnXu2yJ2FALS0ydIB8RTKW7BlwsdrlVAINQ8I0tWXFY4cn7jnMox3
> GLyg0ABmSIYqO/Qxqd4YIILBWWycNmvWn8BBgfLvqJaVDO/VB8vrsGClBnVbuqh8
> UetcFoCuIjXWpSQFBI7NhPouE4C145eMrmSmbz0Go7jtBPEfib5dgF26QepfX56M
> +ds8CDJc9OLusGSCvNgzYu7HXo3fBAFr52LoykQn6IqJbfv0PduiX8ySbLceBXpa
> VGlD9Fb9P/08wgANgBs7cbgkmxaEU/PnpXB/B5Mx8QbBV08Ajch3Rxedc2ikqMgi
> GP0n8xYzk0GaeEl8VSEwIQCbkib8kz4cR8s+nsiDwcq1WkFrIUqqr0UapN3dyRAS
> ySlfFyYN+Wbhe37lRjjQrMDsVcS8mX7t9ELKYRQ3difkmKeeme6D60tyNX/gEUPp
> NqHFeOknpgNw/Orj3KM6v1b9BAeRstFelx+kAffrc0G9Gz9GG8+BY7ThBvdfrSZO
> wp/ufXhmyVta57qVmmpwR7ua3b5npbCvgkIos6GTu2dKRMqRj2pBPBA3f9HyT82S
> 1IsYM72RhCTimrmskIb2/G6okRNa1aft5f3iypwsG6J1+ZLxgYROZVWfTbdA9WRS
> 2/n3/Gtg2yi9GhED0luy
> =FbNM
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Tomcat listener not coming up - no stuck threads
Posted by "John D. Ament" <jo...@apache.org>.
So I wanted to make sure I didn't lose track of this. Did you want me to
revise what I put out there, or were you going to bring in your changes?
On Thu, Dec 15, 2016 at 5:06 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> John,
>
> On 12/15/16 5:03 PM, John D. Ament wrote:
> > On Thu, Dec 15, 2016 at 4:06 PM Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > 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/a0281b2d4e0fea7cb0f7
> a9d <https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d>
> >
> >>>>>>
> 3c
> > <https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d3
> c>
> >>>>>
> >>>>>>
> >
> >
> d1e750b48498ff2
> >>>>
> >>>> That was pretty much what I was thinking.
> >
> >
> >> If you want it, let me know. I can provide a patch. I'm not
> >> sure what tests to add, other than verify no extra threads were
> >> created. I need to setup a bugzilla account too.
> >
> >
> >
> >>>>
> >>>>> 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 is that tomcat is expecting a ThreadPoolExecutor. It
> >> may make sense to wrap it in a delegate that just handles the
> >> calls you need, since you're only calling one method on the
> >> executor. That would simplify this logic as well.
>
> That was exactly what I was going to do: create a class that would do
> double-duty. So rather than if/else blocks behaving differently for
> the case where 1 thread is being used rather than >1, the
> ExecutorService (ThreadPoolExecutor) would handle the difference. So
> it would be a one-line change to the ContainerBase class.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYUxPwAAoJEBzwKT+lPKRYmlwP/A/3F64wo3nJ46if8Ldm72hG
> 1zCUHD+ticxSX/wnjxjjItpy24jLw74d7ub/zuEGdXbcz0FZkL7HkX7uBqsoq/5K
> SR3fS4Vukz7h4aohDrkGFqMYcI48xZOBj2qPP26PNxKgBD4JbGGA/5kP2g1ItVbC
> EWhKRhHUJbP+sPqbyw6EGgxuGFczen/nXXhiTgDY5J5heG/4UoAOzCMJSbWzmywG
> lpPsa3UPvrErf43WE5AH8TijwxSOOSMCQDgVSDWgo5obqPRUzYE69f1h4pap7j5M
> HJlJZyaR+/5H3epfgyim1D4G6+LudvbS8chLIl0Dq9cPcFfbUny118ZSd9zs1n2D
> Np0q03wL4fTSfZTe95q8OWTdmGdwpg++GIoL8hsDg6wzkkPnWOX0mC3qc4TZ5Z8P
> cr+jW5VW12INwKyJROqe3KfX0IJQHS+MfddO+VDaItumibAeDeNEY+TTRsOWSq7k
> MSFH8Uic/S7EoWCTrGILTVgiZ5swAZIgIYSThSEukE3smltdnjZoR9juqwqz8ZgC
> ivIhrHx0lyHr36kbtebCgC/G9IRmv1oO5zNSUglCOmB4fsssxX84CUZXrcx1jxA2
> rdxgImaDw1igiLyhA++RUEL33t38wFzzqk0yfuNSZIa3jX7Obs89LY+wS6Oi6lMI
> bmjL4dBBuzbKbDgnTn26
> =JFw5
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Tomcat listener not coming up - no stuck threads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
John,
On 12/15/16 5:03 PM, John D. Ament wrote:
> On Thu, Dec 15, 2016 at 4:06 PM Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> 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/a0281b2d4e0fea7cb0f7
a9d
>
>>>>>>
3c
> <https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d3
c>
>>>>>
>>>>>>
>
>
d1e750b48498ff2
>>>>
>>>> That was pretty much what I was thinking.
>
>
>> If you want it, let me know. I can provide a patch. I'm not
>> sure what tests to add, other than verify no extra threads were
>> created. I need to setup a bugzilla account too.
>
>
>
>>>>
>>>>> 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 is that tomcat is expecting a ThreadPoolExecutor. It
>> may make sense to wrap it in a delegate that just handles the
>> calls you need, since you're only calling one method on the
>> executor. That would simplify this logic as well.
That was exactly what I was going to do: create a class that would do
double-duty. So rather than if/else blocks behaving differently for
the case where 1 thread is being used rather than >1, the
ExecutorService (ThreadPoolExecutor) would handle the difference. So
it would be a one-line change to the ContainerBase class.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYUxPwAAoJEBzwKT+lPKRYmlwP/A/3F64wo3nJ46if8Ldm72hG
1zCUHD+ticxSX/wnjxjjItpy24jLw74d7ub/zuEGdXbcz0FZkL7HkX7uBqsoq/5K
SR3fS4Vukz7h4aohDrkGFqMYcI48xZOBj2qPP26PNxKgBD4JbGGA/5kP2g1ItVbC
EWhKRhHUJbP+sPqbyw6EGgxuGFczen/nXXhiTgDY5J5heG/4UoAOzCMJSbWzmywG
lpPsa3UPvrErf43WE5AH8TijwxSOOSMCQDgVSDWgo5obqPRUzYE69f1h4pap7j5M
HJlJZyaR+/5H3epfgyim1D4G6+LudvbS8chLIl0Dq9cPcFfbUny118ZSd9zs1n2D
Np0q03wL4fTSfZTe95q8OWTdmGdwpg++GIoL8hsDg6wzkkPnWOX0mC3qc4TZ5Z8P
cr+jW5VW12INwKyJROqe3KfX0IJQHS+MfddO+VDaItumibAeDeNEY+TTRsOWSq7k
MSFH8Uic/S7EoWCTrGILTVgiZ5swAZIgIYSThSEukE3smltdnjZoR9juqwqz8ZgC
ivIhrHx0lyHr36kbtebCgC/G9IRmv1oO5zNSUglCOmB4fsssxX84CUZXrcx1jxA2
rdxgImaDw1igiLyhA++RUEL33t38wFzzqk0yfuNSZIa3jX7Obs89LY+wS6Oi6lMI
bmjL4dBBuzbKbDgnTn26
=JFw5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Tomcat listener not coming up - no stuck threads
Posted by "John D. Ament" <jo...@apache.org>.
On Thu, Dec 15, 2016 at 4:06 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----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
> <https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d3c>
> >>
> >>>
> d1e750b48498ff2
> >
> > That was pretty much what I was thinking.
>
If you want it, let me know. I can provide a patch. I'm not sure what
tests to add, other than verify no extra threads were created. I need to
setup a bugzilla account too.
> >
> >> 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 is that tomcat is expecting a ThreadPoolExecutor. It may make
sense to wrap it in a delegate that just handles the calls you need, since
you're only calling one method on the executor. That would simplify this
logic as well.
>
> >> 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
>
>
Re: [OT] Tomcat listener not coming up - no stuck threads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
Re: [OT] Tomcat listener not coming up - no stuck threads
Posted by Mark Thomas <ma...@apache.org>.
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/a0281b2d4e0fea7cb0f7a9d3c
> 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.
> 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.
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Tomcat listener not coming up - no stuck threads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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/a0281b2d4e0fea7cb0f7a9d3c
d1e750b48498ff2
My
>
tack was going to be to create an ExecutorService that didn't
dispatch. That way, less code has to change.
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.
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 get some failed tests, but generallys eems good (I broke it
> earlier, and lots of things failed).
>
> [concat] Testsuites with failed tests: [concat]
> TEST-org.apache.catalina.session.TestStandardSessionIntegration.NIO.tx
t
>
>
[concat]
> TEST-org.apache.catalina.session.TestStandardSessionIntegration.NIO2.t
xt
>
>
[concat]
> TEST-org.apache.catalina.startup.TestHostConfigAutomaticDeployment.NIO
.txt
>
>
[concat]
> TEST-org.apache.catalina.startup.TestHostConfigAutomaticDeployment.NIO
2.txt
>
>
[concat]
> TEST-org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NI
O.txt
>
>
[concat]
> TEST-org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NI
O2.txt
>
>
[concat]
> TEST-org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO.tx
t
>
>
[concat]
> TEST-org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO2.t
xt
>
>
[concat]
> TEST-org.apache.catalina.tribes.group.interceptors.TestOrderIntercepto
r.NIO.txt
>
>
[concat]
> TEST-org.apache.catalina.tribes.group.interceptors.TestOrderIntercepto
r.NIO2.txt
>
>
[concat]
> TEST-org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetec
tor.NIO.txt
>
>
[concat]
> TEST-org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetec
tor.NIO2.txt
>
>
[concat]
> TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO.txt
> [concat]
> TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO2.txt
>
>
[concat]
> TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfi
gurationParser.NIO.txt
>
>
[concat]
> TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfi
gurationParser.NIO2.txt
These
>
tests are very sensitive to environment. They always fail for me :)
> I'm wondering, can I publish local maven artifacts using the ant
> build?
You can always copy JARs from place to place. That's the extent of my
knowledge of Maven... really at all.
> Would be good to see if this fixes or changes my behavior.
You can take the catalina.jar from the output/build/lib directory and
overwrite the one in your test harness. That should work.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYUvCCAAoJEBzwKT+lPKRYaBsQAMYXGyxbek5K1h5cGSlH8uCh
Lqj/c0yLEbCeFaLcqqUGw9zuDMs7VyfmARFFfYz/gezfs/bHOMFFlznbH4j3iTv9
K2JxsdvNzSbng/Pc/AjhnjKZz7bXM8Abg/hh0icRs8fUY16mZFNrdC3XGT9Mdcfj
clhbTlQPT582+EEVaOwwjEdZLQEk5iKuPleR9yzJSWqW9At/R3Nu8kA6ZuDP2o/v
tf3hir9nafWfFTrmHJatHrQUfQ+R+QBpOgHjVR+yStoHkGl6NACCy5WQqwy8FQ1f
+FgKq5qVE4aeSNXJ+l0wqqnwCNHZvXrqPLMcBbfqY7DWC5uOoSVtFQI/k9S8AE7v
YRq52G1ALzActhgCPQh4xmbnSkxsvRisl6q4NHTztNGMW1OgxYBUajr8gtKSAZ57
Iu4LvxATkc/xkr/Fs/qgMkNO+maIrxtGBm+RXrxm1pNmvNMz3xZfSUcHc6Jqii4e
2Tbur27Quz0qU6ZVurNiSPRSpZwWYhJVtZNeDsC8UB17gabppMzOOtyKY3n6bYrr
fpp4oW/91FLNAPpclUTmwBe0tZVDTnTvTfMZAUXAuXIYpgzijdAYh38xC17iqIYl
7VJiSMZVe1ajCyS8SmfCvVvi2Rvky1b8gy52fZ313auq7QzTv6NMGBOYwcV6Mzxh
pluxK0iMaMeC+rn1warX
=Ov3Q
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Tomcat listener not coming up - no stuck threads
Posted by "John D. Ament" <jo...@apache.org>.
I was feeling ambitious so I gave this a shot. Here's what I changed:
https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d3cd1e750b48498ff2
.
I get some failed tests, but generallys eems good (I broke it earlier, and
lots of things failed).
[concat] Testsuites with failed tests:
[concat]
TEST-org.apache.catalina.session.TestStandardSessionIntegration.NIO.txt
[concat]
TEST-org.apache.catalina.session.TestStandardSessionIntegration.NIO2.txt
[concat]
TEST-org.apache.catalina.startup.TestHostConfigAutomaticDeployment.NIO.txt
[concat]
TEST-org.apache.catalina.startup.TestHostConfigAutomaticDeployment.NIO2.txt
[concat]
TEST-org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO.txt
[concat]
TEST-org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO2.txt
[concat]
TEST-org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO.txt
[concat]
TEST-org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO2.txt
[concat]
TEST-org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO.txt
[concat]
TEST-org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO2.txt
[concat]
TEST-org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO.txt
[concat]
TEST-org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO2.txt
[concat]
TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO.txt
[concat]
TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO2.txt
[concat]
TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO.txt
[concat]
TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO2.txt
I'm wondering, can I publish local maven artifacts using the ant build?
Would be good to see if this fixes or changes my behavior.
John
On Wed, Dec 14, 2016 at 12:22 PM Mark Thomas <ma...@apache.org> wrote:
> On 14/12/2016 16:23, Christopher Schultz wrote:
> > Mark,
> >
> > On 12/8/16 4:19 AM, Mark Thomas wrote:
> >> On 07/12/2016 15:21, Christopher Schultz wrote:
> >>>
> >>> Hmm... there is the "startStopThreads" setting on the Engine,
> >>> but unfortunately there is not (currently available) setting that
> >>> says "don't use multiple threads at all". It looks like Tomcat is
> >>> always going to use at least one (separate) thread to launch the
> >>> various Hosts (and webapps).
> >
> >> It wouldn't be too hard to change that to not use an executor if
> >> the default of startStopThreads="1" was being used.
> >
> > +1 to running start on the main thread if startStopThreads="1".
> >
> > Where would I look to start working on a proposed patch? The Tomcat
> > Lifecycle isn't my strong suit.
>
> ContainerBase. Look for uses of startStopThreads.#
>
> >> However...
> >
> > Even if this doesn't solve John's problem, I think it's worth doing.
> >
> > Comments?
>
> No objections. I'd thought about it previously but it wasn't an itch I
> felt the urge to scratch.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Tomcat listener not coming up - no stuck threads
Posted by Mark Thomas <ma...@apache.org>.
On 14/12/2016 16:23, Christopher Schultz wrote:
> Mark,
>
> On 12/8/16 4:19 AM, Mark Thomas wrote:
>> On 07/12/2016 15:21, Christopher Schultz wrote:
>>>
>>> Hmm... there is the "startStopThreads" setting on the Engine,
>>> but unfortunately there is not (currently available) setting that
>>> says "don't use multiple threads at all". It looks like Tomcat is
>>> always going to use at least one (separate) thread to launch the
>>> various Hosts (and webapps).
>
>> It wouldn't be too hard to change that to not use an executor if
>> the default of startStopThreads="1" was being used.
>
> +1 to running start on the main thread if startStopThreads="1".
>
> Where would I look to start working on a proposed patch? The Tomcat
> Lifecycle isn't my strong suit.
ContainerBase. Look for uses of startStopThreads.#
>> However...
>
> Even if this doesn't solve John's problem, I think it's worth doing.
>
> Comments?
No objections. I'd thought about it previously but it wasn't an itch I
felt the urge to scratch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org