Re: [OT] Tomcat listener not coming up - no stuck threads

[John D. Ament]

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 <
ch...@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 <
> > ch...@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
> >  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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] Tomcat listener not coming up - no stuck threads

[Christopher Schultz]

-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 < 
> ch...@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
> 
>
>>
>
> 
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Tomcat listener not coming up - no stuck threads

[John D. Ament]

On Thu, Dec 15, 2016 at 4:06 PM Christopher Schultz <
ch...@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
> 
> >>
> >>>
> 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] Tomcat listener not coming up - no stuck threads

[Christopher Schultz]

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Tomcat listener not coming up - no stuck threads

[Mark Thomas]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Tomcat listener not coming up - no stuck threads

[Christopher Schultz]

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Tomcat listener not coming up - no stuck threads

[John D. Ament]

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  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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] Tomcat listener not coming up - no stuck threads

[Mark Thomas]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Tomcat listener not coming up - no stuck threads

[John D. Ament]

On Wed, Dec 14, 2016 at 11:23 AM Christopher Schultz <
ch...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] Tomcat listener not coming up - no stuck threads

[Christopher Schultz]

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat listener not coming up - no stuck threads

[John D. Ament]

On Thu, Dec 8, 2016 at 4:20 AM Mark Thomas  wrote:

> On 07/12/2016 15:21, Christopher Schultz wrote:
> > John,
> >
> > On 12/7/16 7:19 AM, John D. Ament wrote:
> >> On Wed, Dec 7, 2016 at 3:58 AM Mark Thomas 
> >> wrote:
> >
> >>> On 06/12/2016 02:59, John D. Ament wrote:
> >>>
> >>> 
> >>>
>  So I was able to identify my issue.  It's not specifically a
>  tomcat problem, but tomcat's bootstrapping makes it unique.
> 
>  one of the issues I've observed is that Tomcat's use of
>  multithreading causes some thread deadlocking with some
>  synchronized blocks.  I was wondering if there's a way to turn
>  that off?  Make tomcat's bootstrap happen in the same thread as
>  the original invocation?
> >>>
> >>> What exactly do you mean by Tomcat's bootstrapping? Can you give
> >>> an example of concurrent execution that is causing issues?
> >>>
> >
> >> I instantiate the Tomcat object and invoke start() on the "main"
> >> thread. The invocation of ServletContextListeners happens on a
> >> "localhost-startStop-1" thread.  I would like to have that
> >> invocation happen on the main thread instead.
> >
> > 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. However...
>
> >> Its nothing within tomcat that is deadlocking, but under the covers
> >> weld has a synchronized block, its inside that synchronized block
> >> where Tomcat is instantiated.  There's a later point where Weld
> >> tries getting a lock again.  In that case, when its single threaded
> >> (in other containers) it passes since it has a lock, but in this
> >> case it can't get that lock.
>
> The Weld documentation suggests that it is initialized per web
> application with a ServletContainerInitializer. This would be fine with
> Tomcat's current use of an Executor for container start/stop.
>
> I don't, therefore, understand how Weld is instantiating Tomcat. Can you
> expand on this?
>
>
There's two ways to make this work.  The documentation you're reading is
referring to standard servlet containers.  E.g. someone's installed tomcat
somewhere and has a WAR with weld-servlet in it.

In my case, I'm using weld-se to bootstrap a JVM, wrote a CDI extension
that bootstraps Tomcat embedded, pointing to the embedded weld instance.
Its not designed for multiple apps, but a single service in that JVM.
Since I'm using an extension, weld isn't 100% started yet.  Since it hasn't
started yet, some of the bootstrap logic is trying to fire an event.  That
event shouldn't be fired quite yet, and its not able to coordinate that
between the threads, hence where I got this problem.

I ended up working around the issue by delaying Tomcat's bootstrap even
further, ensuring that the container is 100% up before trying to launch
tomcat.



> Mark
>
> > Is there any way for you to remove the required monitor on your own
> > code? Or is Weld so intricately-involved in the whole process that
> > unwinding it isn't possible?
> >
> > -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat listener not coming up - no stuck threads

[Mark Thomas]

On 07/12/2016 15:21, Christopher Schultz wrote:
> John,
> 
> On 12/7/16 7:19 AM, John D. Ament wrote:
>> On Wed, Dec 7, 2016 at 3:58 AM Mark Thomas 
>> wrote:
> 
>>> On 06/12/2016 02:59, John D. Ament wrote:
>>>
>>> 
>>>
 So I was able to identify my issue.  It's not specifically a
 tomcat problem, but tomcat's bootstrapping makes it unique.

 one of the issues I've observed is that Tomcat's use of
 multithreading causes some thread deadlocking with some
 synchronized blocks.  I was wondering if there's a way to turn
 that off?  Make tomcat's bootstrap happen in the same thread as
 the original invocation?
>>>
>>> What exactly do you mean by Tomcat's bootstrapping? Can you give
>>> an example of concurrent execution that is causing issues?
>>>
> 
>> I instantiate the Tomcat object and invoke start() on the "main"
>> thread. The invocation of ServletContextListeners happens on a 
>> "localhost-startStop-1" thread.  I would like to have that
>> invocation happen on the main thread instead.
> 
> 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. However...

>> Its nothing within tomcat that is deadlocking, but under the covers
>> weld has a synchronized block, its inside that synchronized block
>> where Tomcat is instantiated.  There's a later point where Weld
>> tries getting a lock again.  In that case, when its single threaded
>> (in other containers) it passes since it has a lock, but in this
>> case it can't get that lock.

The Weld documentation suggests that it is initialized per web
application with a ServletContainerInitializer. This would be fine with
Tomcat's current use of an Executor for container start/stop.

I don't, therefore, understand how Weld is instantiating Tomcat. Can you
expand on this?

Mark

> Is there any way for you to remove the required monitor on your own
> code? Or is Weld so intricately-involved in the whole process that
> unwinding it isn't possible?
> 
> -chris

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

Re: Tomcat listener not coming up - no stuck threads

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 12/7/16 7:19 AM, John D. Ament wrote:
> On Wed, Dec 7, 2016 at 3:58 AM Mark Thomas 
> wrote:
> 
>> On 06/12/2016 02:59, John D. Ament wrote:
>> 
>> 
>> 
>>> So I was able to identify my issue.  It's not specifically a
>>> tomcat problem, but tomcat's bootstrapping makes it unique.
>>> 
>>> one of the issues I've observed is that Tomcat's use of
>>> multithreading causes some thread deadlocking with some
>>> synchronized blocks.  I was wondering if there's a way to turn
>>> that off?  Make tomcat's bootstrap happen in the same thread as
>>> the original invocation?
>> 
>> What exactly do you mean by Tomcat's bootstrapping? Can you give
>> an example of concurrent execution that is causing issues?
>> 
> 
> I instantiate the Tomcat object and invoke start() on the "main"
> thread. The invocation of ServletContextListeners happens on a 
> "localhost-startStop-1" thread.  I would like to have that
> invocation happen on the main thread instead.

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).

> Its nothing within tomcat that is deadlocking, but under the covers
> weld has a synchronized block, its inside that synchronized block
> where Tomcat is instantiated.  There's a later point where Weld
> tries getting a lock again.  In that case, when its single threaded
> (in other containers) it passes since it has a lock, but in this
> case it can't get that lock.

Is there any way for you to remove the required monitor on your own
code? Or is Weld so intricately-involved in the whole process that
unwinding it isn't possible?

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

iQIcBAEBCAAGBQJYSCkWAAoJEBzwKT+lPKRYIUcP/2lSnNrqoW4XXUKuFVLJXijl
w/+TiQz58pjo7KCpXzRC6ubBPIQNO5Hj5HbukXuglNJfaWbEnoIdf9zlSOElg13a
t+Pc4OFvdFYc0uzMf5E824AvXeLR5A4SAuMxzzg86DEdJZiAW4MwEoY/UduPN1b6
PQM74JS5iXNTGQjaNZQfonS26Gsrwi69fnC+evcJ/RDGZxUIq/NAZVU1zD0wjAAh
p0dzvRqkO5XjirCF8xyUgoUIHn1LdygZrOMkDby3XY23/nQVN+JxmlPDc/Lwl+nt
a2Ywkw0D5ATkHBzqZC8ksmkFVWIiGKMZacOBKci5sv+APdTzohpAUicleZ+bQB6l
tYkTwhmqkAn27B1Zj+ev7efAz+LbjyKzBGHLztD3r+lhkfBRJrotprEIA5MWXLiD
SLrBwXcJqSLkipoKDpCwrkBHrMnHTUi1M7NyLDXSgRw/ynJfoUnN/FjssNft7K09
RtxMktXqD3FBX74tIbEUmdU5OmEGAuSIiOrjKyYgH8vXmyqo44kIw9c8EapY1mVS
FQurOjEOXO+rk5TnWWOvT22pcH3sgfH486YaaiUJ0tW7DraQFOIqVq2jlb/tSwW7
Yai218JiEQJRR1ps+ZZyXqhsSVfTJ8CSnGDsWROJuMSO7roBJQXbutftAJjxHC0M
V7Mfo/Q2YhRhrL1fPcuW
=jiLD
-END PGP SIGNATURE-

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

Re: Tomcat listener not coming up - no stuck threads

[John D. Ament]

On Wed, Dec 7, 2016 at 3:58 AM Mark Thomas  wrote:

> On 06/12/2016 02:59, John D. Ament wrote:
>
> 
>
> > So I was able to identify my issue.  It's not specifically a tomcat
> > problem, but tomcat's bootstrapping makes it unique.
> >
> > one of the issues I've observed is that Tomcat's use of multithreading
> > causes some thread deadlocking with some synchronized blocks.  I was
> > wondering if there's a way to turn that off?  Make tomcat's bootstrap
> > happen in the same thread as the original invocation?
>
> What exactly do you mean by Tomcat's bootstrapping? Can you give an
> example of concurrent execution that is causing issues?
>

I instantiate the Tomcat object and invoke start() on the "main" thread.
The invocation of ServletContextListeners happens on a
"localhost-startStop-1" thread.  I would like to have that invocation
happen on the main thread instead.

Its nothing within tomcat that is deadlocking, but under the covers weld
has a synchronized block, its inside that synchronized block where Tomcat
is instantiated.  There's a later point where Weld tries getting a lock
again.  In that case, when its single threaded (in other containers) it
passes since it has a lock, but in this case it can't get that lock.


>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat listener not coming up - no stuck threads

[Mark Thomas]

On 06/12/2016 02:59, John D. Ament wrote:



> So I was able to identify my issue.  It's not specifically a tomcat
> problem, but tomcat's bootstrapping makes it unique.
> 
> one of the issues I've observed is that Tomcat's use of multithreading
> causes some thread deadlocking with some synchronized blocks.  I was
> wondering if there's a way to turn that off?  Make tomcat's bootstrap
> happen in the same thread as the original invocation?

What exactly do you mean by Tomcat's bootstrapping? Can you give an
example of concurrent execution that is causing issues?

Mark


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

Re: Tomcat listener not coming up - no stuck threads

[John D. Ament]

On Sat, Dec 3, 2016 at 2:28 PM Mark Thomas  wrote:

> On 03/12/2016 17:39, John D. Ament wrote:
> > Sorry missed a response..
> >
> > On Sat, Dec 3, 2016 at 12:36 PM John D. Ament 
> > wrote:
> >
> >> On Wed, Nov 30, 2016 at 8:50 PM Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>
> > John,
> >
> > On 11/26/16 7:29 PM, John D. Ament wrote:
>  Hi,
> 
>  Looking for some external input.  I've put together a simple
>  tomcat embedded instance designed to deploy an arbitrary set of
>  servlets, filters, etc.
> 
>  For some reason, when I run tests with Tomcat the server never
>  fully launches.  I can see the port in use, but connections to the
>  server are not answered by the instance.  When I debug the start
>  up, I see what appears to be a loop attempting to start services
>  that never returns, in LifecycleBase.
> >
> > So you see a busy-loop? What's the stack trace?
> >
> >
> >> I am probably seeing a busy-loop, however I  see no stack traces.
>
> Take a thread dump.
>
> Better, take 3 ~10s apart and compare.
>
> > Tomcat version?
> >
> >
> > 8.5.8 and a few older ones, so 8.0.30 and 8.5.3 as well (that I can
> recall
> > recently)
> >
> >
> >
>  Easiest way to reproduce it with this project is to clone
>  https://github.com/hammock-project/hammock/ and run a local build
>  (to get snapshots) and then run 'mvn clean install -Ptomcat-test'
>  from rest-resteasy (or spark or jersey).
> >
> > Er... sorry, I'm not going to do that, and it doesn't look like anyone
> > else is going to do that, either.
> >
> >
> > Its always worth a shot.
> >
> >
> >
>  I'm sure there's something simple I'm over looking.
> >
> > I browsed your github repo for about 15 seconds until I realized that
> > there are like 10k files and I'd never find the embedded driver
> > without asking. So, where is it?
> >
> > Can you compare your driver with any of the many Tomcat test cases
> > that launch an embedded server instance? Those test classes do exactly
> > what it sounds like you are trying to do.
> >
> >
> > Happily, can you point me to some of these test cases?
>
> Most of them under trunk/test
>
> This one has several variations:
>
> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java?view=annotate
>
>
> > On a related note, documentation for tomcat embedded is scarce.  I
> usually
> > have to find it on non-apache channels.  What would be the best way to
> get
> > a document page started, maybe linked off of
> > http://tomcat.apache.org/tomcat-8.5-doc/index.html ?  What repo contains
> > your site?  I'd be happy to provide some patches from my own learnings.
>
> The docs are taken from the releases so you need to start here:
>
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/
>
>
So I was able to identify my issue.  It's not specifically a tomcat
problem, but tomcat's bootstrapping makes it unique.

one of the issues I've observed is that Tomcat's use of multithreading
causes some thread deadlocking with some synchronized blocks.  I was
wondering if there's a way to turn that off?  Make tomcat's bootstrap
happen in the same thread as the original invocation?


>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat listener not coming up - no stuck threads

[Mark Thomas]

On 03/12/2016 17:39, John D. Ament wrote:
> Sorry missed a response..
> 
> On Sat, Dec 3, 2016 at 12:36 PM John D. Ament 
> wrote:
> 
>> On Wed, Nov 30, 2016 at 8:50 PM Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
> John,
> 
> On 11/26/16 7:29 PM, John D. Ament wrote:
 Hi,

 Looking for some external input.  I've put together a simple
 tomcat embedded instance designed to deploy an arbitrary set of
 servlets, filters, etc.

 For some reason, when I run tests with Tomcat the server never
 fully launches.  I can see the port in use, but connections to the
 server are not answered by the instance.  When I debug the start
 up, I see what appears to be a loop attempting to start services
 that never returns, in LifecycleBase.
> 
> So you see a busy-loop? What's the stack trace?
> 
> 
>> I am probably seeing a busy-loop, however I  see no stack traces.

Take a thread dump.

Better, take 3 ~10s apart and compare.

> Tomcat version?
> 
> 
> 8.5.8 and a few older ones, so 8.0.30 and 8.5.3 as well (that I can recall
> recently)
> 
> 
> 
 Easiest way to reproduce it with this project is to clone
 https://github.com/hammock-project/hammock/ and run a local build
 (to get snapshots) and then run 'mvn clean install -Ptomcat-test'
 from rest-resteasy (or spark or jersey).
> 
> Er... sorry, I'm not going to do that, and it doesn't look like anyone
> else is going to do that, either.
> 
> 
> Its always worth a shot.
> 
> 
> 
 I'm sure there's something simple I'm over looking.
> 
> I browsed your github repo for about 15 seconds until I realized that
> there are like 10k files and I'd never find the embedded driver
> without asking. So, where is it?
> 
> Can you compare your driver with any of the many Tomcat test cases
> that launch an embedded server instance? Those test classes do exactly
> what it sounds like you are trying to do.
> 
> 
> Happily, can you point me to some of these test cases?

Most of them under trunk/test

This one has several variations:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java?view=annotate


> On a related note, documentation for tomcat embedded is scarce.  I usually
> have to find it on non-apache channels.  What would be the best way to get
> a document page started, maybe linked off of
> http://tomcat.apache.org/tomcat-8.5-doc/index.html ?  What repo contains
> your site?  I'd be happy to provide some patches from my own learnings.

The docs are taken from the releases so you need to start here:

http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/


Mark

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

Re: Tomcat listener not coming up - no stuck threads

[John D. Ament]

Sorry missed a response..

On Sat, Dec 3, 2016 at 12:36 PM John D. Ament 
wrote:

> On Wed, Nov 30, 2016 at 8:50 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 11/26/16 7:29 PM, John D. Ament wrote:
> > Hi,
> >
> > Looking for some external input.  I've put together a simple
> > tomcat embedded instance designed to deploy an arbitrary set of
> > servlets, filters, etc.
> >
> > For some reason, when I run tests with Tomcat the server never
> > fully launches.  I can see the port in use, but connections to the
> > server are not answered by the instance.  When I debug the start
> > up, I see what appears to be a loop attempting to start services
> > that never returns, in LifecycleBase.
>
> So you see a busy-loop? What's the stack trace?
>
>
I am probably seeing a busy-loop, however I  see no stack traces.


>
> Tomcat version?
>
>
> 8.5.8 and a few older ones, so 8.0.30 and 8.5.3 as well (that I can recall
> recently)
>
>
>
> > Easiest way to reproduce it with this project is to clone
> > https://github.com/hammock-project/hammock/ and run a local build
> > (to get snapshots) and then run 'mvn clean install -Ptomcat-test'
> > from rest-resteasy (or spark or jersey).
>
> Er... sorry, I'm not going to do that, and it doesn't look like anyone
> else is going to do that, either.
>
>
> Its always worth a shot.
>
>
>
> > I'm sure there's something simple I'm over looking.
>
> I browsed your github repo for about 15 seconds until I realized that
> there are like 10k files and I'd never find the embedded driver
> without asking. So, where is it?
>
> Can you compare your driver with any of the many Tomcat test cases
> that launch an embedded server instance? Those test classes do exactly
> what it sounds like you are trying to do.
>
>
> Happily, can you point me to some of these test cases?
>
> On a related note, documentation for tomcat embedded is scarce.  I usually
> have to find it on non-apache channels.  What would be the best way to get
> a document page started, maybe linked off of
> http://tomcat.apache.org/tomcat-8.5-doc/index.html ?  What repo contains
> your site?  I'd be happy to provide some patches from my own learnings.
>
> John
>
>
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYP4HoAAoJEBzwKT+lPKRYOL8P/A5MQFuVMK0kbgsAzbYVWx81
> yLsIN5BgjMBwPCxr2S2KIg40/P8dq256+VFYkwLI/Y3kKi206IK0KQdRJCTQFEO9
> avTOSFTgY3IXCCEEijSh5HeM8ofO7AgFrjcUGYZ6PI5PmnkCx/bN+sCAmbIL4SuE
> hpOdA+A6zaV7TFFqjk2b71dVeijCTO3B/nUjkwOY7lP56jOX4bM2YDZoZj1o0SsV
> bLsR3hjIlyZX1q83XNGPNYicueMZv9EsoUuZkwN3N/9CwTIbn27ck9xWfs3zOsOr
> DLppYHdcKQNByd630cL0xhgYEHShJJcUcRddXWCeuEJOQ0urFYvfiOW2H5Py86lE
> jwlA8XqIhvK5nmG5fOjwInSN3v+Fhd5A9rAhZrPZpP4+J1tGK37FvVhPJa9xXFWz
> OYgtUxP2y1zwYyq+qs5jCYy628HE3Y++YSUSK+mWSN8Id/jDBqKUzZkZWuc7750B
> wRy/8rb6F9L47sAVkg4gj8XqQF/gQ3gbS3ujf+eYuIf4GS4h1pmI4xCmuoZo0LLt
> NJo2k4jAfwx2l48BpjO9Ry8MaSft2a9vE0uBQR/jwY5dvn5Y0mYX8Dr2JgdFYpeW
> Skxf9+U2U/IzB2qePvdmo5u5QUyl40fu6/ndMjoEk/AXycwfodr6/UG9fLOG7uDR
> kLSU4n1jBzwEf+9WMtFA
> =7GKl
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat listener not coming up - no stuck threads

[John D. Ament]

On Wed, Nov 30, 2016 at 8:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 11/26/16 7:29 PM, John D. Ament wrote:
> > Hi,
> >
> > Looking for some external input.  I've put together a simple
> > tomcat embedded instance designed to deploy an arbitrary set of
> > servlets, filters, etc.
> >
> > For some reason, when I run tests with Tomcat the server never
> > fully launches.  I can see the port in use, but connections to the
> > server are not answered by the instance.  When I debug the start
> > up, I see what appears to be a loop attempting to start services
> > that never returns, in LifecycleBase.
>
> So you see a busy-loop? What's the stack trace?
>
> Tomcat version?
>

8.5.8 and a few older ones, so 8.0.30 and 8.5.3 as well (that I can recall
recently)


>
> > Easiest way to reproduce it with this project is to clone
> > https://github.com/hammock-project/hammock/ and run a local build
> > (to get snapshots) and then run 'mvn clean install -Ptomcat-test'
> > from rest-resteasy (or spark or jersey).
>
> Er... sorry, I'm not going to do that, and it doesn't look like anyone
> else is going to do that, either.
>

Its always worth a shot.


>
> > I'm sure there's something simple I'm over looking.
>
> I browsed your github repo for about 15 seconds until I realized that
> there are like 10k files and I'd never find the embedded driver
> without asking. So, where is it?
>
> Can you compare your driver with any of the many Tomcat test cases
> that launch an embedded server instance? Those test classes do exactly
> what it sounds like you are trying to do.
>

Happily, can you point me to some of these test cases?

On a related note, documentation for tomcat embedded is scarce.  I usually
have to find it on non-apache channels.  What would be the best way to get
a document page started, maybe linked off of
http://tomcat.apache.org/tomcat-8.5-doc/index.html ?  What repo contains
your site?  I'd be happy to provide some patches from my own learnings.

John


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYP4HoAAoJEBzwKT+lPKRYOL8P/A5MQFuVMK0kbgsAzbYVWx81
> yLsIN5BgjMBwPCxr2S2KIg40/P8dq256+VFYkwLI/Y3kKi206IK0KQdRJCTQFEO9
> avTOSFTgY3IXCCEEijSh5HeM8ofO7AgFrjcUGYZ6PI5PmnkCx/bN+sCAmbIL4SuE
> hpOdA+A6zaV7TFFqjk2b71dVeijCTO3B/nUjkwOY7lP56jOX4bM2YDZoZj1o0SsV
> bLsR3hjIlyZX1q83XNGPNYicueMZv9EsoUuZkwN3N/9CwTIbn27ck9xWfs3zOsOr
> DLppYHdcKQNByd630cL0xhgYEHShJJcUcRddXWCeuEJOQ0urFYvfiOW2H5Py86lE
> jwlA8XqIhvK5nmG5fOjwInSN3v+Fhd5A9rAhZrPZpP4+J1tGK37FvVhPJa9xXFWz
> OYgtUxP2y1zwYyq+qs5jCYy628HE3Y++YSUSK+mWSN8Id/jDBqKUzZkZWuc7750B
> wRy/8rb6F9L47sAVkg4gj8XqQF/gQ3gbS3ujf+eYuIf4GS4h1pmI4xCmuoZo0LLt
> NJo2k4jAfwx2l48BpjO9Ry8MaSft2a9vE0uBQR/jwY5dvn5Y0mYX8Dr2JgdFYpeW
> Skxf9+U2U/IzB2qePvdmo5u5QUyl40fu6/ndMjoEk/AXycwfodr6/UG9fLOG7uDR
> kLSU4n1jBzwEf+9WMtFA
> =7GKl
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat listener not coming up - no stuck threads

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 11/26/16 7:29 PM, John D. Ament wrote:
> Hi,
> 
> Looking for some external input.  I've put together a simple
> tomcat embedded instance designed to deploy an arbitrary set of
> servlets, filters, etc.
> 
> For some reason, when I run tests with Tomcat the server never
> fully launches.  I can see the port in use, but connections to the
> server are not answered by the instance.  When I debug the start
> up, I see what appears to be a loop attempting to start services
> that never returns, in LifecycleBase.

So you see a busy-loop? What's the stack trace?

Tomcat version?

> Easiest way to reproduce it with this project is to clone 
> https://github.com/hammock-project/hammock/ and run a local build
> (to get snapshots) and then run 'mvn clean install -Ptomcat-test'
> from rest-resteasy (or spark or jersey).

Er... sorry, I'm not going to do that, and it doesn't look like anyone
else is going to do that, either.

> I'm sure there's something simple I'm over looking.

I browsed your github repo for about 15 seconds until I realized that
there are like 10k files and I'd never find the embedded driver
without asking. So, where is it?

Can you compare your driver with any of the many Tomcat test cases
that launch an embedded server instance? Those test classes do exactly
what it sounds like you are trying to do.

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

iQIcBAEBCAAGBQJYP4HoAAoJEBzwKT+lPKRYOL8P/A5MQFuVMK0kbgsAzbYVWx81
yLsIN5BgjMBwPCxr2S2KIg40/P8dq256+VFYkwLI/Y3kKi206IK0KQdRJCTQFEO9
avTOSFTgY3IXCCEEijSh5HeM8ofO7AgFrjcUGYZ6PI5PmnkCx/bN+sCAmbIL4SuE
hpOdA+A6zaV7TFFqjk2b71dVeijCTO3B/nUjkwOY7lP56jOX4bM2YDZoZj1o0SsV
bLsR3hjIlyZX1q83XNGPNYicueMZv9EsoUuZkwN3N/9CwTIbn27ck9xWfs3zOsOr
DLppYHdcKQNByd630cL0xhgYEHShJJcUcRddXWCeuEJOQ0urFYvfiOW2H5Py86lE
jwlA8XqIhvK5nmG5fOjwInSN3v+Fhd5A9rAhZrPZpP4+J1tGK37FvVhPJa9xXFWz
OYgtUxP2y1zwYyq+qs5jCYy628HE3Y++YSUSK+mWSN8Id/jDBqKUzZkZWuc7750B
wRy/8rb6F9L47sAVkg4gj8XqQF/gQ3gbS3ujf+eYuIf4GS4h1pmI4xCmuoZo0LLt
NJo2k4jAfwx2l48BpjO9Ry8MaSft2a9vE0uBQR/jwY5dvn5Y0mYX8Dr2JgdFYpeW
Skxf9+U2U/IzB2qePvdmo5u5QUyl40fu6/ndMjoEk/AXycwfodr6/UG9fLOG7uDR
kLSU4n1jBzwEf+9WMtFA
=7GKl
-END PGP SIGNATURE-

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

Tomcat listener not coming up - no stuck threads

[John D. Ament]

Hi,

Looking for some external input.  I've put together a simple tomcat
embedded instance designed to deploy an arbitrary set of servlets, filters,
etc.

For some reason, when I run tests with Tomcat the server never fully
launches.  I can see the port in use, but connections to the server are not
answered by the instance.  When I debug the start up, I see what appears to
be a loop attempting to start services that never returns, in LifecycleBase.

Easiest way to reproduce it with this project is to clone
https://github.com/hammock-project/hammock/ and run a local build (to get
snapshots) and then run 'mvn clean install -Ptomcat-test' from
rest-resteasy (or spark or jersey).

I'm sure there's something simple I'm over looking.

John