a question about tomcat thread

[ophusky]

Server version: Apache Tomcat/8.0.35
Server built:   May 11 2016 21:57:08 UTC
Server number:  8.0.35.0
OS Name:Linux
OS Version: 3.2.35
Architecture:   amd64
JVM Version:1.8.0_45-b14
JVM Vendor: Oracle Corporation
_
1.
[root@app41 manager]# curl -s http://127.0.0.1/manager/status |grep -P -o 'Max 
threads:.*? '
Max threads: 700 Current thread count: 478 Current thread busy: 17 Keeped alive 
sockets count: 5
2.
[root@app41 manager]# pgrep jsvc
25446
25447
[root@app41 manager]# ps -Lf 25447 | wc -l
541

I want to figure out the meaning of "Current thread count"  "Current thread 
busy" "Keeped alive sockets count"   and  relationship between 1 and 2.
I have read the document 
http://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Server_Status  
if "Current thread busy" mean  "Parse and Prepare Request"  and  "Service" , 
"Keeped alive sockets count" mean  "Keep-Alive"?


please help me  thx~

TomcatCon London - registration open

[Mark Thomas]

All,

The Apache Tomcat PMC is delighted to announce that registration for
TomcatCon London is now open.

This one day conference will be held on Tuesday 26th September in
central London and features talks from:
- Mark Thomas (markt)
- Rémy Maucherat (remm)
- Jean-Frederic Clere (jfclere)

Full details, including the schedule is available on the website:
http://tomcat.apache.org/conference.html

Registration is via EventBrite:
https://www.eventbrite.com/e/tomcatcon-london-2017-tickets-36683639754

We hope to see you there!

Mark
on behalf of the Apache Tomcat PMC


This event is sponsored by Liferay, the robust java-based open source
platform (5 million downloads) used to build sophisticated transactional
websites and deliver them to web browsers and native mobile clients.
Liferay, Inc provides enterprise support for the commercial release
which is used by organisations such as Allianz, Volkswagen Group and the
NHS.

https://web.liferay.com/community/liferay-projects/liferay-portal/overview

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

Re: Change of status code for ClientAbortExceptions - bug?

[Mark Thomas]

On 21/08/17 18:22, icyerasor wrote:
> markt wrote
>> On 06/06/17 15:08, Thomas Eliassen wrote:
>> ...
>>
>> I think we are going to have to choose a "least bad" option here. Given
>> that Tomcat has used 200 in the past and that there is the option to add
>> %{javax.servlet.error.exception}r to the access log I think reverting
>> the change to the status code is the best (well, least bad) option here.
>>
>> I'll get that done shortly.
>>
>> Mark
> 
> I saw that the change was kind of reverted with Revision 1797829 in
> http://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk/java/org/apache/coyote/AbstractProcessor.java
> - but it does not work for me.

Steps to reproduce please.

Mark



> When I stop a request from within the client the method is called with an
> ErrorState.CLOSE_NOW and t=null. Thus !(t instanceof IOException) is true
> and the status will be set to 500 again.
> 
> Maybe it would make more sense to check for
> if (response.getStatus() < 400 && errorState.isIoAllowed()) 
> // then set to 500, otherwise it was probably a client disconnect
> 
> I also saw that with 8.5.20 the %X accessLog format was added, which I might
> be able to use to differentiate between "real" 500 server-errors and client
> disconnects.
> 
> Best Regards
> Andreas
> 
> 
> 
> 
> --
> View this message in context: 
> http://tomcat.10.x6.nabble.com/Change-of-status-code-for-ClientAbortExceptions-bug-tp5063738p5066604.html
> Sent from the Tomcat - User mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Upgrading to 8.5.20 - issue when certificateKeyAlias is not set

[Mark Thomas]

On 21/08/17 22:54, Jesse Schulman wrote:
> I'm pretty sure this is a bug/regression related to a recent change by
> markt: http://svn.apache.org/viewvc?view=revision=1800868
> 
> I think the issue was there before but we weren't hitting it, because the
> logic of taking the first alias from the keystore (even if it does not
> alias a key) was already there, but only after this change did we start to
> hit that code.
> 
> We have worked around the issue with a "getFirstKeyAlias" method that we
> use to set the certificateKeyAlias in our SSLHostConfigCertificate:
> 
>private String getFirstKeyAlias(KeyStore keyStore) {
>   try {
>  Enumeration aliases = keyStore.aliases();
>  while(aliases.hasMoreElements()) {
> String alias = aliases.nextElement();
> if (keyStore.isKeyEntry(alias))
>return alias;
> }
>   } catch (KeyStoreException e) {
>   LOGGER.error("Failed to find first key alias in keystore", e);
>   }
> 
>   return null;
>}
> 
> I think that something like this should around line 219 of JSSEUtil, where
> currently it looks like this:
> 
> Enumeration aliases = ks.aliases();
> if (!aliases.hasMoreElements()) {
> throw new IOException(sm.getString("jsse.noKeys"));
> }
> keyAlias = aliases.nextElement();
> 
> 
> Should I send this to the dev list instead?

If you could create a Bugzilla issue for it, that would be great.

Thanks,

Mark


> 
> Thanks!
> Jesse
> 
> On Wed, Aug 16, 2017 at 3:02 PM Jesse Schulman  wrote:
> 
>> We use tomcat-embed and we have a test that is breaking with an upgrade
>> from 8.5.12 to 8.5.20, it seems due to the fact that we do not set the
>> certificateKeyAlias when we configure an SSLHostConfigCertificate.
>>
>> The documentation for certificateKeyAlias states "If not specified, the
>> first *key* read from the keystore will be used."
>>
>> It seems that the first alias is being used and there is no check that it
>> references a key.
>>
>> The result is that in JSSEUtil.getKeyManagers there is a call to
>> KeyStore.getKey(keyAlias, keyPassArray) where keyAlias is actually an alias
>> for a certificate, which leads to inMemoryKeyStore.setKeyEntry being passed
>> null for the Key argument and eventually a KeyStoreException("Cannot store
>> non-PrivateKeys").
>>
>> This worked previously with certificatekeyAlias being null.  I can confirm
>> that this works just fine if I set that with the alias used when creating
>> the KeyStore but I would rather not pass that alias around our code when I
>> did not previously need to.
>>
>> Thanks!
>> Jesse
>>
>>
>>
> 


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

setting packetSize for ajp connector in embedded tomcat via commandline system property

[Johnson, Jim]

Hello,

I'm trying to set packetSize for an embedded Tomcat 8.5.4 AJP connector using a 
command line property and I am failing. Does anyone know what the correct 
property might be? These are some settings that I know which work that I've 
found in the Spring Boot Reference guide but that's not a complete reference. 
I'm thinking it should be something like

-Dserver.tomcat.connector.packet-size=65536

Or something close to that - but there's no consistency that I've been able to 
find in naming conventions at the server or server.tomcat or 
server.tomcat.connector level. And after many hours of guessing I'm turning to 
you all in hopes that someone may know the correct setting.

Can anyone provide the correct syntax? Or is packetSize for the AJP connector 
not even supported through command line for embedded Tomcat?

Thanks!

- Jim

Re: Upgrading to 8.5.20 - issue when certificateKeyAlias is not set

[Jesse Schulman]

Will do, thanks Mark!

On Tue, Aug 22, 2017 at 8:42 AM Mark Thomas  wrote:

> On 21/08/17 22:54, Jesse Schulman wrote:
> > I'm pretty sure this is a bug/regression related to a recent change by
> > markt: http://svn.apache.org/viewvc?view=revision=1800868
> >
> > I think the issue was there before but we weren't hitting it, because the
> > logic of taking the first alias from the keystore (even if it does not
> > alias a key) was already there, but only after this change did we start
> to
> > hit that code.
> >
> > We have worked around the issue with a "getFirstKeyAlias" method that we
> > use to set the certificateKeyAlias in our SSLHostConfigCertificate:
> >
> >private String getFirstKeyAlias(KeyStore keyStore) {
> >   try {
> >  Enumeration aliases = keyStore.aliases();
> >  while(aliases.hasMoreElements()) {
> > String alias = aliases.nextElement();
> > if (keyStore.isKeyEntry(alias))
> >return alias;
> > }
> >   } catch (KeyStoreException e) {
> >   LOGGER.error("Failed to find first key alias in keystore", e);
> >   }
> >
> >   return null;
> >}
> >
> > I think that something like this should around line 219 of JSSEUtil,
> where
> > currently it looks like this:
> >
> > Enumeration aliases = ks.aliases();
> > if (!aliases.hasMoreElements()) {
> > throw new IOException(sm.getString("jsse.noKeys"));
> > }
> > keyAlias = aliases.nextElement();
> >
> >
> > Should I send this to the dev list instead?
>
> If you could create a Bugzilla issue for it, that would be great.
>
> Thanks,
>
> Mark
>
>
> >
> > Thanks!
> > Jesse
> >
> > On Wed, Aug 16, 2017 at 3:02 PM Jesse Schulman 
> wrote:
> >
> >> We use tomcat-embed and we have a test that is breaking with an upgrade
> >> from 8.5.12 to 8.5.20, it seems due to the fact that we do not set the
> >> certificateKeyAlias when we configure an SSLHostConfigCertificate.
> >>
> >> The documentation for certificateKeyAlias states "If not specified, the
> >> first *key* read from the keystore will be used."
> >>
> >> It seems that the first alias is being used and there is no check that
> it
> >> references a key.
> >>
> >> The result is that in JSSEUtil.getKeyManagers there is a call to
> >> KeyStore.getKey(keyAlias, keyPassArray) where keyAlias is actually an
> alias
> >> for a certificate, which leads to inMemoryKeyStore.setKeyEntry being
> passed
> >> null for the Key argument and eventually a KeyStoreException("Cannot
> store
> >> non-PrivateKeys").
> >>
> >> This worked previously with certificatekeyAlias being null.  I can
> confirm
> >> that this works just fine if I set that with the alias used when
> creating
> >> the KeyStore but I would rather not pass that alias around our code
> when I
> >> did not previously need to.
> >>
> >> Thanks!
> >> Jesse
> >>
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: setting packetSize for ajp connector in embedded tomcat via commandline system property

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Him,

On 8/22/17 11:57 AM, Johnson, Jim wrote:
> I'm trying to set packetSize for an embedded Tomcat 8.5.4 AJP 
> connector using a command line property and I am failing. Does
> anyone know what the correct property might be?

What led you to believe that there was a particular system property
that had any effect?

> These are some settings that I know which work that I've found in
> the Spring Boot Reference guide but that's not a complete
> reference.

It's also specific to Spring Boot.

> I'm thinking it should be something like
> 
> -Dserver.tomcat.connector.packet-size=65536
> 
> Or something close to that - but there's no consistency that I've 
> been able to find in naming conventions at the server or 
> server.tomcat or server.tomcat.connector level. And after many
> hours of guessing I'm turning to you all in hopes that someone may
> know the correct setting.

If you are using Spring Boot, then you might want to ask the Spring
Boot community. Perhaps someone here can answer your question, but
most of us (myself included) can't.

If you are using Tomcat embedded directly (i.e. you have written your
own Java code to launch Tomcat) then you can use whatever system
property you want... you just have to write your code to use it.

> Can anyone provide the correct syntax? Or is packetSize for the
> AJP connector not even supported through command line for embedded 
> Tomcat?

Embedded Tomcat does whatever you tell it to do. But it cannot read
your mind.

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

iQIcBAEBCAAGBQJZnGSMAAoJEBzwKT+lPKRYPcUQAJ5poBQj19xiz5utBKQ3RL90
klMHNmAzZ45/afwTwj/G6JnSZCjRO30r33tKvTvzbf7WvDP1SL32f1Jl0b/LDXW8
o/8huECuKVhCjMsZWCM3HIxqlnR4bfhXXVOdbs3anWnO60/jrH58Km6xDLZnEVHG
C6tTqOEMqYqLS/WKUC+x9P9zHqQX1I9WpZ9yr17KEvS6xIDTXzipnCbN8J3ujrzE
o35BY7lj/ukCl2ZhqDszV21CuamdL2AW21FytIqBto7+CfnA/ftHllxPl6nUnpvg
/wyKJ6mM8/gS4fcUKO+crj5QgTkor4LYi6vbog1U1gigRhZSx3d+l8mrNX2Sdn7D
MhuM59jfzL6Q8IfkHHPrZVtQZVuKzASL79rupI025pSn7bqPFiqRv91/SrF6RT+v
tF6CsrTOrp6HM/anTyESUjnHvsyTJBhLDGOHfTptNekGIOMtk4uEfN3gAM6wLU6G
kK9Dd/7DOrtCN/6gNNp6/vVLwaJLqqJWPvfUdvYI6l2wwvBPfgKvNh/h0PVWmRu1
7JZQ89LgXZZYaUn4VqhsAEL60+RIjejK5d8ri3ZnM7OJOGOKb+VRSF6lA2pzHfM8
GuuDRxO1gVA9RhBEenObGO6445VrODW08uoe19mmw+NIqNuegnvoB6ZECP6TfPNv
kJuLdC1rUZCEieFJUGBC
=Zxsd
-END PGP SIGNATURE-

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

RE: setting packetSize for ajp connector in embedded tomcat via commandline system property

[Johnson, Jim]

Hi Chris,

> What led you to believe that there was a particular system property that had 
> any effect?

Because I've seen other properties such as:

server.tomcat.connector.max-post-size=
server.max-http-header-size=XX
server.use-forward-headers=true
server.ajp.port=

And I guess honestly, I was hoping that perhaps there was some standard that if 
it's a configurable option in an AJP Connector stanza, then there's a 
corresponding command line system property that can be used instead. This line 
of thinking of course would require that Spring Boot was using some "official" 
embedded Tomcat code that had a zillion options all ready to be used but as I 
read through your response, it's dawning on me that my line of thinking is 
completely off. That it's really up to the developer of the spring boot app I'm 
using to put into their code whatever options or settings that they need tomcat 
to use. If their code doesn’t use AJP or do anything with server.ajp.port, then 
no matter how hard I try, I'll never get an AJP connector to work. I think I 
get it now. My apologies, this is my first stint doing sysadmin work with embed 
and I've been treating it like a full blown Tomcat instance that comes with 
everything turned off, but still included, thinking I need to supply all these 
different arguments to turn stuff on. It's more like it's available but not 
included - the developer needs to supply the code to turn on the tomcat feature.

Have I got it right now?

Thanks!

- Jim

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, August 22, 2017 1:06 PM
To: users@tomcat.apache.org
Subject: Re: setting packetSize for ajp connector in embedded tomcat via 
commandline system property

This message originated outside of Unum. Use caution when opening attachments, 
clicking links or responding to requests for information.


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Him,

On 8/22/17 11:57 AM, Johnson, Jim wrote:
> I'm trying to set packetSize for an embedded Tomcat 8.5.4 AJP 
> connector using a command line property and I am failing. Does anyone 
> know what the correct property might be?

What led you to believe that there was a particular system property that had 
any effect?

> These are some settings that I know which work that I've found in the 
> Spring Boot Reference guide but that's not a complete reference.

It's also specific to Spring Boot.

> I'm thinking it should be something like
>
> -Dserver.tomcat.connector.packet-size=65536
>
> Or something close to that - but there's no consistency that I've been 
> able to find in naming conventions at the server or server.tomcat or 
> server.tomcat.connector level. And after many hours of guessing I'm 
> turning to you all in hopes that someone may know the correct setting.

If you are using Spring Boot, then you might want to ask the Spring Boot 
community. Perhaps someone here can answer your question, but most of us 
(myself included) can't.

If you are using Tomcat embedded directly (i.e. you have written your own Java 
code to launch Tomcat) then you can use whatever system property you want... 
you just have to write your code to use it.

> Can anyone provide the correct syntax? Or is packetSize for the AJP 
> connector not even supported through command line for embedded Tomcat?

Embedded Tomcat does whatever you tell it to do. But it cannot read your mind.

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

iQIcBAEBCAAGBQJZnGSMAAoJEBzwKT+lPKRYPcUQAJ5poBQj19xiz5utBKQ3RL90
klMHNmAzZ45/afwTwj/G6JnSZCjRO30r33tKvTvzbf7WvDP1SL32f1Jl0b/LDXW8
o/8huECuKVhCjMsZWCM3HIxqlnR4bfhXXVOdbs3anWnO60/jrH58Km6xDLZnEVHG
C6tTqOEMqYqLS/WKUC+x9P9zHqQX1I9WpZ9yr17KEvS6xIDTXzipnCbN8J3ujrzE
o35BY7lj/ukCl2ZhqDszV21CuamdL2AW21FytIqBto7+CfnA/ftHllxPl6nUnpvg
/wyKJ6mM8/gS4fcUKO+crj5QgTkor4LYi6vbog1U1gigRhZSx3d+l8mrNX2Sdn7D
MhuM59jfzL6Q8IfkHHPrZVtQZVuKzASL79rupI025pSn7bqPFiqRv91/SrF6RT+v
tF6CsrTOrp6HM/anTyESUjnHvsyTJBhLDGOHfTptNekGIOMtk4uEfN3gAM6wLU6G
kK9Dd/7DOrtCN/6gNNp6/vVLwaJLqqJWPvfUdvYI6l2wwvBPfgKvNh/h0PVWmRu1
7JZQ89LgXZZYaUn4VqhsAEL60+RIjejK5d8ri3ZnM7OJOGOKb+VRSF6lA2pzHfM8
GuuDRxO1gVA9RhBEenObGO6445VrODW08uoe19mmw+NIqNuegnvoB6ZECP6TfPNv
kJuLdC1rUZCEieFJUGBC
=Zxsd
-END PGP SIGNATURE-

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

Re: TomcatCon London - registration open

[Suvendu Sekhar Mondal]

Just wondering when we will have TomcatCon in India... :)

On Aug 22, 2017 10:21 PM, "Mark Thomas"  wrote:

> All,
>
> The Apache Tomcat PMC is delighted to announce that registration for
> TomcatCon London is now open.
>
> This one day conference will be held on Tuesday 26th September in
> central London and features talks from:
> - Mark Thomas (markt)
> - Rémy Maucherat (remm)
> - Jean-Frederic Clere (jfclere)
>
> Full details, including the schedule is available on the website:
> http://tomcat.apache.org/conference.html
>
> Registration is via EventBrite:
> https://www.eventbrite.com/e/tomcatcon-london-2017-tickets-36683639754
>
> We hope to see you there!
>
> Mark
> on behalf of the Apache Tomcat PMC
>
>
> This event is sponsored by Liferay, the robust java-based open source
> platform (5 million downloads) used to build sophisticated transactional
> websites and deliver them to web browsers and native mobile clients.
> Liferay, Inc provides enterprise support for the commercial release
> which is used by organisations such as Allianz, Volkswagen Group and the
> NHS.
>
> https://web.liferay.com/community/liferay-projects/liferay-portal/overview
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: TomcatCon London - registration open

[Igal @ Lucee.org]

On 8/22/2017 1:08 PM, Mark Thomas wrote:


On 22/08/17 19:23, Suvendu Sekhar Mondal wrote:

Just wondering when we will have TomcatCon in India... :)

Just as soon as we get a committer based in India :)


How does one become a committer? (asking from Los Angeles but willing to 
relocate to India if that would improve my chances :])


Igal Sapir
Lucee Core Developer
Lucee.org 

Re: TomcatCon London - registration open

[Mark Thomas]

On 22/08/17 19:23, Suvendu Sekhar Mondal wrote:
> Just wondering when we will have TomcatCon in India... :)

Just as soon as we get a committer based in India :)

Seriously, these events are intended to break even financially while not
placing the ASF or any individual committers in a position where they
might lose money. Any funds remaining after this event will be used to
fund the venue for the next one. Funds remaining from that one will be
used for the following one and so on.

In the interests of openness and transparency, I plan to publish
'accounts' for these events so everyone can see where the money goes.

We are fortunate that Liferay offered to sponsor this event and are
providing the venue. That means if the event is well attended we should
have a reasonable balance with which to plan the next event. Suggestions
of where that should be are welcome.

Generally, the expectation is that events will be held near(ish) to
where the committers are to keep travel costs for the speakers low.
However, if someone is willing to sponsor an event in terms of providing
the venue and covering speaker costs, we can have an event pretty much
anywhere committers are willing to travel to.

Based on a very quick search on monsterindia.com, Bengaluru is the most
popular location for Tomcat job postings. If we were to put on an event
in Bengaluru then, as a rough guess, we'd be looking at needing
sponsorship of around £1,000 for the venue and £750 for each Europe
based committer for a 2-day event. I can't speak for any other
committers but, other commitments permitting, I'd be willing to travel
to speak at such an event.

Mark


> 
> On Aug 22, 2017 10:21 PM, "Mark Thomas"  wrote:
> 
>> All,
>>
>> The Apache Tomcat PMC is delighted to announce that registration for
>> TomcatCon London is now open.
>>
>> This one day conference will be held on Tuesday 26th September in
>> central London and features talks from:
>> - Mark Thomas (markt)
>> - Rémy Maucherat (remm)
>> - Jean-Frederic Clere (jfclere)
>>
>> Full details, including the schedule is available on the website:
>> http://tomcat.apache.org/conference.html
>>
>> Registration is via EventBrite:
>> https://www.eventbrite.com/e/tomcatcon-london-2017-tickets-36683639754
>>
>> We hope to see you there!
>>
>> Mark
>> on behalf of the Apache Tomcat PMC
>>
>>
>> This event is sponsored by Liferay, the robust java-based open source
>> platform (5 million downloads) used to build sophisticated transactional
>> websites and deliver them to web browsers and native mobile clients.
>> Liferay, Inc provides enterprise support for the commercial release
>> which is used by organisations such as Allianz, Volkswagen Group and the
>> NHS.
>>
>> https://web.liferay.com/community/liferay-projects/liferay-portal/overview
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 


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

Re: setting packetSize for ajp connector in embedded tomcat via commandline system property

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jim,

On 8/22/17 2:03 PM, Johnson, Jim wrote:
>> What led you to believe that there was a particular system 
>> property that had any effect?
> 
> Because I've seen other properties such as:
> 
> server.tomcat.connector.max-post-size= 
> server.max-http-header-size=XX server.use-forward-headers=true 
> server.ajp.port=

Those aren't anything that Tomcat itself understands. Those must be
Spring Boot configuration settings.

> And I guess honestly, I was hoping that perhaps there was some 
> standard that if it's a configurable option in an AJP Connector 
> stanza, then there's a corresponding command line system property 
> that can be used instead. This line of thinking of course would 
> require that Spring Boot was using some "official" embedded Tomcat 
> code that had a zillion options all ready to be used but as I read 
> through your response, it's dawning on me that my line of thinking
> is completely off.

It was a reasonable assumption... it just happens to be incorrect :)

> That it's really up to the developer of the spring boot app I'm
> using to put into their code whatever options or settings that they
> need tomcat to use.
Correct.

One of the problems with properties like those you describe is that
they suppose that there is only *one* configuration for e.g. a
connector. Tomcat can support an arbitrary number of connectors, each
with separate port numbers, AJP header sizes, etc. so to
properly-support Tomcat's full capabilities, you'd need to have
properties like:

server.tomcat.connector.1.max-post-size=XXX
server.tomcat.connector.1.max-http-header-size=x
etc.

> If their code doesn’t use AJP or do anything with server.ajp.port,
> then no matter how hard I try, I'll never get an AJP connector to
> work.

Exactly.

> I think I get it now. My apologies, this is my first stint doing
> sysadmin work with embed and I've been treating it like a full
> blown Tomcat instance that comes with everything turned off, but
> still included, thinking I need to supply all these different
> arguments to turn stuff on. It's more like it's available but not
> included - the developer needs to supply the code to turn on the
> tomcat feature.

Correct. If Spring Boot is being used, then SB needs to supply the
configuration details to Tomcat, and their documentation should tell
you how to specify them. It's possible a particular setting isn't
supported (yet) and needs to be added to Spring Boot.

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

iQIcBAEBCAAGBQJZnIcjAAoJEBzwKT+lPKRYGeIQAKLnJnlwZGzXNVuNIGLuUaL7
JL6tgRJ99yX2yClERWTzPPjhLNkNRORFbwQuAOTXOhpeOnAOnqPdcYLVKNi3bx51
zxH/DwK/vnIj4MfkKRD+h6SeaApeb0mZUuqn7Ds1cE0Gspkj3935X7yQwLWUQgM6
bTw/DpAXOzL/COjQK6wAxxYHqNKVGGOliJcLpi7URjjUE8nqLt7/Sx33xs/X8rt5
nL/o+LhVcJM3DjUpF9Y/VbwglltUgZCvoOKyDAdB2uKP24qniipNwt3XHA7jtTSg
n8biWkod3ksPbWJvt/gRUkIbgQioW7xU3xTr47U48eOFtEKrgUm1o2KWwJrfIwVT
zoyqWfyFxuPJPVK+JcmCxwxCwyII/psG7LK2ui82SVy8Hn1wuC53HQI0bGuHvi0B
Si2hRaSXWzqueS8Ji8SFgrhz6i9J6Yac1Twj4tuhaTmdKfu8XYeRmCHS/JUWM/T7
pzavMTlekV3nvGJ/Gtp0DDuW8K1xCm0yZIbxBpzYXj79SSawzMy8cmlQDyPfzGCI
RIxn7ePhB7EpDlIbvhqos1Ajv7suy3lV4RXeVIrdvUgmvJpITJ/HUJIDwaDEG1P6
fEWm6pe8AdnSmyK/wng2Psvabj5tDUHV/faVGeC1uSaw7/oWpMdX+DwufhSDfGhY
GdPuTP4dCBaiIfb0KnLU
=cux+
-END PGP SIGNATURE-

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

Re: TomcatCon London - registration open

[Mark Thomas]

On 22/08/17 21:19, Igal @ Lucee.org wrote:
> On 8/22/2017 1:08 PM, Mark Thomas wrote:
> 
>> On 22/08/17 19:23, Suvendu Sekhar Mondal wrote:
>>> Just wondering when we will have TomcatCon in India... :)
>> Just as soon as we get a committer based in India :)
> 
> How does one become a committer? (asking from Los Angeles but willing to
> relocate to India if that would improve my chances :])

Several routes.

The most obvious is by providing patches / pull requests for issues. Do
that often enough that your name is recognised as someone who knows what
they are doing and provides decent patches and you'll get you commit bit
pretty quickly.

The less obvious routes are supporting the community in other areas. For
example, a number of folks were made committers based on their
contributions to this list. It hasn't happened yet but other possible
routes could include improving the wiki, documentation, providing
content for the YouTube channel etc.

In short, any sustained contribution to the community should result in
committership being offered.

Mark

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

Re: Where Tomcat webapp contexts live on Debian

[Emmanuel Bourg]

On 08/16/2017 09:24 AM, Leon Rosenberg wrote:
> Debian has a long tradition of doing things in a very special way when it
> comes to java. Long enough they shipped GnuJ as standard JVM with a debian
> distribution, a piece of garbage that wasn't able to start simplest of java
> programs.

GCJ has been superseded by OpenJDK a lng time ago as the default
Java runtime on Debian.

> But there has been an as long tradition to reply to every question about
> tomcat behaviour on a specific distribution by suggesting to throw the crap
> away and download the vanilla tomcat form the one and only legal source ;-)
> (at least in the past, to which debian belongs).

FWIW, there is now a Tomcat committer maintaining the Tomcat package in
Debian and controlling its quality. If you think there is something
crappy about the packaging feel free to send a mail to me or to the
debian-j...@lists.debian.org and I'll be happy to help.

Emmanuel Bourg

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

Re: Where Tomcat webapp contexts live on Debian

[Leon Rosenberg]

On Tue, Aug 22, 2017 at 10:55 PM, Emmanuel Bourg  wrote:

> On 08/16/2017 09:24 AM, Leon Rosenberg wrote:
> > Debian has a long tradition of doing things in a very special way when it
> > comes to java. Long enough they shipped GnuJ as standard JVM with a
> debian
> > distribution, a piece of garbage that wasn't able to start simplest of
> java
> > programs.
>
> GCJ has been superseded by OpenJDK a lng time ago as the default
> Java runtime on Debian.
>
> > But there has been an as long tradition to reply to every question about
> > tomcat behaviour on a specific distribution by suggesting to throw the
> crap
> > away and download the vanilla tomcat form the one and only legal source
> ;-)
> > (at least in the past, to which debian belongs).
>
> FWIW, there is now a Tomcat committer maintaining the Tomcat package in
> Debian and controlling its quality. If you think there is something
> crappy about the packaging feel free to send a mail to me or to the
> debian-j...@lists.debian.org and I'll be happy to help.
>

Thank you. Mea culpa. My information seems outdated.
Leon


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

Re: TomcatCon London - registration open

[Igal @ Lucee.org]

On 8/22/2017 1:29 PM, Mark Thomas wrote:

On 22/08/17 21:19, Igal @ Lucee.org wrote:

How does one become a committer? (asking from Los Angeles but willing to
relocate to India if that would improve my chances :])

The most obvious is by providing patches / pull requests for issues. Do
that often enough that your name is recognised as someone who knows what
they are doing and provides decent patches and you'll get you commit bit
pretty quickly.



In short, any sustained contribution to the community should result in
committership being offered.


Fair enough.

I personally prefer the "most obvious" way, but I must point out that it 
requires some guidance/cooperation from current committers and that is 
-- understandably so -- not always available.


Igal Sapir
Lucee Core Developer
Lucee.org 

Detect client disconnect in Tomcat

[Grigor Aleksanyan]

Hi,

I have a web application (.war file) running under *apache-tomcat-7.0.52*.
It is a proxy application between my c++ client and server apps. Once HTTP
request (from the client) is received by web application, it propagates
request to the server and sends response back to the client once it is
ready. Server may need long time before it produces some data to send to
the client (also it can send data by chunks with really long delays etc.).

My question is.

*Is there a way to detect client disconnect before the time server has
something ready to be written to the output stream?* In case if server
writes something after client's disconnect, obviously I will get an
exception and can handle it properly. But my goal is to avoid waiting for
the server to produce some data to write, to detect this. I saw a couple of
forums and mailing lists where people say that only way to do this, is by
writing to outputstream. But in case of websockets I know that I can get
notifications that connection was closed by the client.

I believe this is a very common issue people face and there should be a
graceful solution for this for HTTP as well.

Can you please advice ?

Thank you,

-Grigor

-- 

--

*CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY CONTAIN 
CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, LLC.  IT IS FOR 
THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED REVIEW, USE, 
COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, 
PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY E-MAIL OR BY TELEPHONE AT +1 
201 710 5977, AND DESTROY ALL COPIES OF THIS MESSAGE FROM YOUR SYSTEM.

E-SIGNATURE NOTICE: Unless specifically set forth herein, the transmission 
of this communication is not intended to be a legally binding electronic 
signature, and no offer, commitment or assent on behalf of OneMarketData, 
LLC is expressed or implied by the sending of this email, or any 
attachments hereto.

Re: Detect client disconnect in Tomcat

[tomcat]

On 22.08.2017 10:50, Grigor Aleksanyan wrote:

Hi,

I have a web application (.war file) running under *apache-tomcat-7.0.52*.
It is a proxy application between my c++ client and server apps. Once HTTP
request (from the client) is received by web application, it propagates
request to the server and sends response back to the client once it is
ready. Server may need long time before it produces some data to send to
the client (also it can send data by chunks with really long delays etc.).

My question is.

*Is there a way to detect client disconnect before the time server has
something ready to be written to the output stream?* In case if server
writes something after client's disconnect, obviously I will get an
exception and can handle it properly. But my goal is to avoid waiting for
the server to produce some data to write, to detect this. I saw a couple of
forums and mailing lists where people say that only way to do this, is by
writing to outputstream. But in case of websockets I know that I can get
notifications that connection was closed by the client.

I believe this is a very common issue people face and there should be a
graceful solution for this for HTTP as well.

Can you please advice ?



Hi.
You describe the problem well, and even the solution.

The problem is not at the Tomcat level, nor at the HTTP level. The problem is at the lower 
TCP/IP level, and there is not much that Tomcat or HTTP can do about it.
When a client establishes a TCP connection to a server, this is a "virtual" connection. 
There is no hardware or physical line that is dedicated to this connection. In other 
words, it exists only as long as the server and the client agree that it exists.
(And if there are any firewalls or proxies in-between, it is not even one connection, it 
is multiple chained connections).


If the client just decides to "go away", without explicitly telling the server so, the 
server side is totally unaware that the client has gone, until the server tries to send a 
packet on the connection, and (some time after that) expects to receive an "ACK" and does 
not get one.
In the case of websocket, you have a well-behaved client, that (supposedly) tells the 
server when it is closing the connection. So the application could test this, by sending 
some kind of "probe" from time to time, to check that the client is still there.
And the client would expect such a probe, and know that it is a probe, and that it is not 
data. So it could just respond with some kind of "ack", that the server also would 
interpret correctly.
But even then, if the client host were to just crash (or anything in-between, like a 
firewall or a router e.g.) you would have the same issue : nothing is sent to the server 
saying that the connection no longer exists, so the server thinks it is still there, as 
long as it does not send anything.


And you are also right to say that it affects a lot of people and their 
applications.
It is frustrating to e.g. start some long and heavy search in a database, and then when 
the result appears, find out that there is nobody listening anymore (*).

There may be some good universal solutions to this, but so far I don't know of 
any.
Fame awaits you, if you find one that can be universally applicable.


(*) and even if you knew that the client has gone, some tasks which you started in the 
background, may not be so easy to stop in the middle either.



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

Re: Detect client disconnect in Tomcat

[Simon De Uvarow]

"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Tue, Aug 22, 2017 at 11:36 AM, André Warnier (tomcat) 
wrote:

> On 22.08.2017 10:50, Grigor Aleksanyan wrote:
>
>> Hi,
>>
>> I have a web application (.war file) running under *apache-tomcat-7.0.52*.
>> It is a proxy application between my c++ client and server apps. Once HTTP
>> request (from the client) is received by web application, it propagates
>> request to the server and sends response back to the client once it is
>> ready. Server may need long time before it produces some data to send to
>> the client (also it can send data by chunks with really long delays etc.).
>>
>> My question is.
>>
>> *Is there a way to detect client disconnect before the time server has
>> something ready to be written to the output stream?* In case if server
>> writes something after client's disconnect, obviously I will get an
>> exception and can handle it properly. But my goal is to avoid waiting for
>> the server to produce some data to write, to detect this. I saw a couple
>> of
>> forums and mailing lists where people say that only way to do this, is by
>> writing to outputstream. But in case of websockets I know that I can get
>> notifications that connection was closed by the client.
>>
>> I believe this is a very common issue people face and there should be a
>> graceful solution for this for HTTP as well.
>>
>> Can you please advice ?
>>
>>
> Hi.
> You describe the problem well, and even the solution.
>
> The problem is not at the Tomcat level, nor at the HTTP level. The problem
> is at the lower TCP/IP level, and there is not much that Tomcat or HTTP can
> do about it.
> When a client establishes a TCP connection to a server, this is a
> "virtual" connection. There is no hardware or physical line that is
> dedicated to this connection. In other words, it exists only as long as the
> server and the client agree that it exists.
> (And if there are any firewalls or proxies in-between, it is not even one
> connection, it is multiple chained connections).
>
> If the client just decides to "go away", without explicitly telling the
> server so, the server side is totally unaware that the client has gone,
> until the server tries to send a packet on the connection, and (some time
> after that) expects to receive an "ACK" and does not get one.
> In the case of websocket, you have a well-behaved client, that
> (supposedly) tells the server when it is closing the connection. So the
> application could test this, by sending some kind of "probe" from time to
> time, to check that the client is still there.
> And the client would expect such a probe, and know that it is a probe, and
> that it is not data. So it could just respond with some kind of "ack", that
> the server also would interpret correctly.
> But even then, if the client host were to just crash (or anything
> in-between, like a firewall or a router e.g.) you would have the same issue
> : nothing is sent to the server saying that the connection no longer
> exists, so the server thinks it is still there, as long as it does not send
> anything.
>
> And you are also right to say that it affects a lot of people and their
> applications.
> It is frustrating to e.g. start some long and heavy search in a database,
> and then when the result appears, find out that there is nobody listening
> anymore (*).
> There may be some good universal solutions to this, but so far I don't
> know of any.
> Fame awaits you, if you find one that can be universally applicable.
>
>
> (*) and even if you knew that the client has gone, some tasks which you
> started in the background, may not be so easy to stop in the middle either.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
For cases that could have the described issue (HTTP request that may take
too long), I decided to create the "Interactive Task Manager".
The HTTP request starts a task to process something at server side, and
gets a quick response with the UUID of the task. Then the client can pool
asking if the task has finished.
When the task finishes, it stores the result as JSON in a temporal file.
When the client gets the result, the Interactive Task Manager deletes the
temporal file.
The Interactive Task Manager has it own thread pool to process the tasks.

It adds some overhead: HTTP requests asking for news + storing the result
to file + and reading it back. But it doesn't depend on configuration
changes, or hardware speed. It's robust.

I have the idea that HTTP requests should be resolved quikly (always less
than some seconds). If not, it's a bug, so we need to reimplement the
backend to fix it.

It's one possible solution. Maybe not the best.
Hope it helps.