Re: ExtendedAccessLogValve.class overloaded timezone and set it to GMT

[Farhan Tariq]

hi,

we have tomcat 7.0.68 deployed on linux.

To capture the log in local system timezone using ExtendedAccessLogValve
class we change the following line
"currentTimestampFormat.setTimeZone(TimeZone.getTimeZone("GMT"))"

into
"currentTimestampFormat.setTimeZone(TimeZone.getDefault())"

in ElementTimestampStruct class and then compile and replace the
catalina.jar in already deployed tomcat.

Now , The time is sync with the system set time which is GMT+5 but somehow
date is still operating on GMT as date get changed at 05:00 AM ( system
time). please help me in this regard to understand why the above mentioned
change have no impact of date field.

Regards
Farhan

On Thu, Dec 15, 2016 at 3:31 AM, Konstantin Kolinko 
wrote:

> 2016-12-14 18:48 GMT+03:00 Farhan Tariq :
> > Hello team,
> >
> > I am not sure why the timezone is explicitly set to GMT in
> > ExtendedAccessLogValve class?
> > To capture URL encoded parameters I looking to use this class but need
> help
> > to get time in GMT+5. I am using tomcat 7 on redhat.
> > Any suggestions?
>
>
> 1. Please read the mailing list rules:
> http://tomcat.apache.org/lists.html#tomcat-users
>
> You have not mentioned what exact version of Tomcat you are using (1.)
>
> 2. Use of GMT in ExtendedAccessLogValve is by design.
>
> That valve implements log format specified by "Extended Log File
> Format" specification by W3C, and the specification dictates that the
> time is in GMT.
>
> http://tomcat.apache.org/tomcat-8.5-doc/config/valve.
> html#Extended_Access_Log_Valve
>
> https://www.w3.org/TR/WD-logfile.html
>
>
> It may be good to implement configurable timezone in AccessLogValve
> (currently it uses TimeZone.getDefault()), but I think that
> ExtendedAccessLogValve shall remain with GMT.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: https redirect failed for POST request when behind a load balancer

[Bin Chen]

Peter:
Our Load balancer uses a VIP to do the redirect, so when a request coming in as 
http://lb-api:8080, it changes it into https://lb-api:8443 and submit to the 
api server behind. I could not see any redirect logged into the access log. 
However, if I submit a request to the api server directly using 
http://my-api:8080, I'd see a redirect return code of 302 and another entry 
after that with the request to port 8443. Almost make me thing it might be the 
load balancer that is redirecting the POST request to a GET. Is that possible?

Thank you again,

Bin

-Original Message-
From: Kreuser, Peter [mailto:pkreu...@airplus.com] 
Sent: Friday, January 20, 2017 1:43 AM
To: Tomcat Users List 
Subject: AW: https redirect failed for POST request when behind a load balancer

Hi Bin



I wonder if the redirect will use a 301 or 302 and that per default results in 
a GET. How is this implemented in the loadbalancer?


As I read a 307 should preserve the request method. From: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_questions_13628831_apache-2D301-2Dredirect-2Dand-2Dpreserving-2Dpost-2Ddata=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ=quLXN4mLB8a4NNSXBq_y8iftNygJUC3ZqeL5gYH46So=Cr-WfGYAinyNBtKqFUGgzoXRehN9Mfw-Ssq2Q24Hpvk=
  



If you want to enforce the redirect to https, you should however consider a 
different approach.



If it is necessary to protect the data, no POST should ever go to http/port 
8080, as the data will be open in the first request.

So in my opinion the calling website/application that is sending the data to 
8080 should be modified in the first place.



Best regards



Peter 



> -Original Message-

> From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 

> Sent: Wednesday, January 18, 2017 11:43 PM

> To: Tomcat Users List 

> Subject: Re: https redirect failed for POST request when behind a load 
> balancer

> 

> 1. You know that "api-lb" and "lb-api" above are two different host names?

> 

> 2. What HTTP response code is send to client to perform the redirection?

> (What is displayed by access log? Or by "network" monitoring tool in browser. 
>  What are actual responses to perform the redirection).

> 

> Some response codes used for redirects allow the browser to change POST to 
> GET, some do not. See the HTTP protocol specification for details.

> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.apache.org_tomcat_Specifications=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ=g9XvhdAG4g80Ajw7i4CvF3kysWtESxDF6NFX8j630c8=mOjl8_uOfuo3lfn8xDS6jwCZao9az7SjXLxgAh-2Twc=
>  

> 

> Is redirect performed by a single response, or there are several redirect 
> responses in a chain, A -> B -> C/ ?

> 

> 3. Actual configuration?

> 

> (For someone else to reproduce the issue or to match your tale to their 
> configs).

> 

> Best regards,

> Konstantin Kolinko

> 

> -

> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

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

> 

>

Re: FW: tomcat 8080 thread not reduced

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Smith,

On 1/19/17 9:59 PM, smith wrote:
>> "busy" is the same as "active".
> 
> When not use , our busy thread always keep under 10
> while the currentThreadCount keeps high (these are get from tomcat
> manager), So we really don't know how many threads are truly free.

Why do you care how many are free? Isn't it more important to know how
many are active? For example, I run my app servers with
maxThreads="150" for the most part. Then, I have Nagios notify me if
the "active count" goes above 135 (that's 90% of my maxThreads).

Nagios, like many monitoring systems, won't scream the first time it
sees something. Instead, it will check again a few times before
complaining. That means that as long as I don't see any significant
duration where the active thread count exceeds 135, I don't get any
alarms going off.

And I don't care how many "free" threads I have. I've decided that I
want "150 and NO MORE". Nothing else matters except the active count.
I don't happen to allow the thread pool to re-size downward (fewer
threads), but if I did, I wouldn't have to change my monitoring at
all. What? The active count is 10 and the total pool size is 20? I
don't care. Wake me up when the active thread count stays high for a
while, indicating to me that we are getting hammered.

> How many are in keepAlivedStatus

Use NIO and forget about it.

Besides, you are using *AJP*. Every thread is *always* in a keepalive
state. So keepalive == idle as far as Tomcat is concerned.

If you were using HTTP, then keepalive would be an issue (and NIO
would be the answer), but you aren't, so it's not.

- -chris

> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Thursday, January 19,
> 2017 4:38 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080
> thread not reduced
> 
> Smith,
> 
> On 1/18/17 8:25 PM, smith wrote:
>> I don't care if the threads will be reduced, I just want to know
>> why.
> 
> Okay.
> 
>> And we want to use the account to determine when the tomcat
>> capacity is not enough that we need to add max configuration or
>> add new tomcat servers.
> 
> Set your initial and max threads to the same value (pool size = 
> constant) and then monitor the "active count" with a Nagios warning
> at e.g. 80% usage.
> 
>> Since not use the , the busy thread account also cannot
>> tell us the correct active threads count.
> 
> "busy" is the same as "active".
> 
>> In another email thread, you said if use , it will tell
>> us the right active thread count not just busy count, right?
> 
> I would always use an  for at least two different
> reasons:
> 
> 1. Thread management (e.g. reducing threads if necessary) 2. Shared
> thread-pools (no need to have port 8080 and 8443 with separate
> pools)
> 
> -chris
> 
>> -Original Message- From: Christopher Schultz 
>> [mailto:ch...@christopherschultz.net] Sent: Wednesday, January
>> 18, 2017 3:28 PM To: Tomcat Users List Subject: Re: FW: tomcat
>> 8080 thread not reduced
> 
>> Smith,
> 
>> On 1/18/17 12:47 AM, smith wrote:
>>> So the tomcat default executor will not reduce the thread count
>>> until it reach to the max configuration?
> 
>> By default, you get a thread pool that isn't as smart as an
>> executor.
> 
>>> Will it reduce when it reach to max?
> 
>> Not unless you use an .
> 
>>> And why the default not reduce the thread?
> 
>> Because it didn't do so in the past, before  was
>> introduced.
> 
>> I'm curious: if you are willing to have e.g. 200 threads
>> available at any time during the life of the JVM, why does it
>> matter if those threads are reduced during times of inactivity?
> 
>> I think of threads as a resource like memory, where if you are
>> going to allocate X resources, you may as well allocate X
>> resources and be done with it. Growing and shrinking pools of
>> things just adds complexity and reduces performance.
> 
>> Idle threads are "free" other than using a little bit of memory. 
>> So why is it so important for those threads to stop when they
>> don't have any work for a while?
> 
>> -chris
> 
>>> -Original Message- From: Christopher Schultz 
>>> [mailto:ch...@christopherschultz.net] Sent: Tuesday, January
>>> 17, 2017 7:18 PM To: Tomcat Users List Subject: Re: FW: tomcat
>>> 8080 thread not reduced
> 
>>> Smith,
> 
>>> On 1/16/17 8:22 PM, smith wrote:
 Yes, I think thread count should be reduced when those
 threads are idle
> 
 Is this right? Or it will not reduced?
> 
>>> Id you want Tomcat to reduce the number of idle threads, you'll
>>> need to explicitly configure an  and use that with
>>> your  .
> 
>>> -chris
> 
 -Original Message- From: Christopher Schultz 
 [mailto:ch...@christopherschultz.net] Sent: Monday, January
 16, 2017 2:20 PM To: Tomcat Users List Subject: Re: FW:
 tomcat 8080 thread not reduced
> 
 Smith,
> 
 There are your only active s:
> 
 On 1/14/17 1:30 AM, smith wrote:
>   

Re: [ANN] New committer: Emmanuel Bourg

[Rainer Jung]

Am 20.01.2017 um 18:12 schrieb Mark Thomas:

On behalf of the Tomcat committers I am pleased to announce that
Emmanuel Bourg (ebourg) has been voted in as a new Tomcat committer.

Please join me in welcoming him.


Congratulations and welcome!

Rainer

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

Re: [ANN] New committer: Emmanuel Bourg

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Emmanuel,

On 1/20/17 12:12 PM, Mark Thomas wrote:
> On behalf of the Tomcat committers I am pleased to announce that 
> Emmanuel Bourg (ebourg) has been voted in as a new Tomcat
> committer.
> 
> Please join me in welcoming him.

Congratulations!

And yes, this was a ruse to get you to spend more time on Tomcat. ;)

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

iQIcBAEBCAAGBQJYgoCuAAoJEBzwKT+lPKRYv6wP/iHZtIjRzHBnGkJxFdX3aFEt
sUXmK/xmDlHmCFCyRiAmgH608dZFAituvJQA9X6olWgmg/TPvXyz/Jkg2mzpA/h+
gN9d4qNJBz5CjY+gAyERk7fbZsroqyuKYwkX3Yu24kvkelV48TOzW7iaIoOCdzvw
LborKgKcIxCmSHqcAO6dxW8sT9voSztD/hj7AckXR7S3rooWs3bwUEK0ZdCEHfcm
SYJbOEzweSLhHvvyb8qDPBciTe2evkH10UejaR/9Q/TLhUi7fRRg45wcNpBC3r/B
NJk2Y587wrkbtmyXCx7NtlboP7IkI3ffP1esGpMRtVpTET6NwfOvHtU/E3dTlVwz
2fjSzkRKeBrXDRbGkSeaVfXnPAvtferpP9bRinf0+V2d0cwJXGRB2VXtaKMHTO6D
gjvwBg9Ikp8rMX3qM2QWdeypCxP0btkzMJu410tCmUhIbb+yYs2/ni6eabz2vHBi
5HNCdHziPk6tRMHWcwP4T+YzzjMr6jzVckMCaScl184HPWTU6AruG+k2DwmZRQq9
7xX5Y8xAepbK0TN4jg252JIgdSMSkOaHv3milNv9PAGzFODjIaCq3GywQJ4qCCRS
IKgJQE/4TFgejduXZTPdGOY45giwy4Cw0x1kQkxhGtqvBcuDNVzvB77BDp/icMXD
0u8Q0b6x3SE6Mwez5Fzq
=xnnZ
-END PGP SIGNATURE-

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

Re: Can Tomcat act as an HTTPS proxy?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 1/19/17 12:21 PM, David P. Caldwell wrote:
> 1. The backend server serves files via HTTPS. (I control this, and
> may switch it to HTTP; see below.)

Ok.

> 2. The proxy server has an HTTPS connector like this (but under my 
> initial solution I wasn't thinking I should use it).
> 
> I can connect to this HTTPS connector with my client (as long as I 
> disable the various SSL security checks, given that this is a 
> self-signed certficate).

Let's Encrypt?

> 3. The proxy server also has an HTTP connector, the one that is
> the default when using the embedded API. It changes the port number
> on it to an open ephemeral port, changes the base directory to a
> temporary directory, adds a context and configures servlets and so
> forth (it's part of a framework, so it's generalized; in the case
> I'm working on, it's adding a single servlet that basically
> forwards requests to the backend).
> 
> 4. The purpose of all this rigamarole is mocking.

Oh. That can make a lot of my questions go away. One more before I
spend any real time droning on and on:

Is this only for unit testing, and so security, trust, etc. are all
moot points?

> I'd like to get rid of some or all of that parameterization, to 
> simplify my production code, so I decided to see whether I could 
> build an HTTPS mock of the environment.

This sounds like an excellent idea. Simpler production code is
*always* better.

> The purpose of the middle proxy server is essentially to remove
> the need to also parameterize server names and stuff. (The client
> code requests real production URLs, but because they are proxied
> through the middle tier, the middle tier can forward the requests
> to the mock server.)
> 
> So I think what I want to do is have that middle tier's HTTP
> connector pass HTTPS requests from the client through to the
> backend HTTPS server.

This is what is confusing to me. You have only two choices for
connectors: HTTP or HTTPS. You can't have the HTTPS connector use the
HTTP connector. At least not on the same server.

You either want this:

client --- HTTP --> proxy --- HTTP --> origin

or this

client --- HTTP --> proxy --- HTTPS --> origin

or this

client --- HTTPS --> proxy --- HTTP --> origin

or this

client --- HTTPS --> proxy --- HTTPS --> origin

Pick which one you want to use. Then, on the proxy, only enable the
protocol that the client needs as a Connector. For the outgoing
connection (to the origin server), there is no Connector. There is
only the proxy-as-client, which will connect to whatever protocol is
being used on the origin server.

But... if you are just trying to "mock" the backend server... doesn't
that mean that there *is no backend server* when the mocking takes place
?

> For what it's worth, with some additional research, it looks like 
> what's happening is that the various mechanisms I am attempting to
> use to "proxy" (tunnel) these requests are using a CONNECT request
> to Tomcat, which is returning a 400. I think. I haven't been able
> to catch it in the act.

Tomcat doesn't yet support the CONNECT protocol. There is a patch in a
BZ issue somewhere that I haven't yet tested (this is something I'm
actually interested in making work in Tomcat). So if your client is
intending to use HTTP CONNECT then you are out of luck.

If you want to use Tomcat as a reverse-proxy, then I believe there is
a servlet for that, but I've never used it.

> However, for my situation, explaining it to you suggests a
> different solution -- since I have my Tomcat "middle" server with
> an HTTPS connector, and that is working, I am also going to
> experiment with using HTTPS to communicate with the middle, and
> then switch the back end to HTTP. I'm not sure that'll help
> (because I'm not sure how I can implement the "direct all HTTPS
> requests to this host/port" without the Java client attempting to
> establish a tunnel) but I'll explore it.

Only you can decide what make the most sense to you, but my experience
with connecting to arbitrary backend services is that connection
information isn't that tough to "parameterize"... a URL plus an
SSLSocketFactory can get the job done in most cases.

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

iQIcBAEBCAAGBQJYgn/qAAoJEBzwKT+lPKRYx60P/ikPqpzWx2zHui7UKt+VOS/8
eeape8b+Jngamkp7f4/3avaia3AI48Vbrk2Y5EVGzgVzz6YDgSh/Q4eI+h9FwWGr
ZpqWcN8s/WOyJWCrfxQyKkZMbZaDPmC5a5XvUbgJ6GA2v2vcJ0iGhYqEoaTf3oKw
CvdWbuT8NHltccFymJCvRXLXCZTBSwBFXQFPC2PyGXzPuxhUzwapDqjWYoORGN/N
X50lRTp5byzchLkk1wWJPNX+t8zNXWi9Xt+uK20yTJgpv+yJ54+x4xqzZvpVtta1
kEV7GsPnv3PYxFmMvA9y3B1SQ0aJopY24eiURVOlSaZwJ+at6wyBS9CwzPAadHte
RTkdo2OJUO3wvw2UpGnikp+2ksiGAWGY+8VBTOWWmBB4yRUsMkvDM+5GTggXhcCf
N1qD4l1ZqkAuqkUM2gmYQgPyVubvkVR0L6ovtQ1eXsPJ5C5DOnVyMK196Qp/EP7Y
VTUYw4jZKGExojUg5Wsxh2lx2njUr5qIMwaNdfFTjfgL+UvwkiWUJrn6oOo/uC+H

Re: [ANN] New committer: Emmanuel Bourg

[Violeta Georgieva]

2017-01-20 19:12 GMT+02:00 Mark Thomas :
>
> On behalf of the Tomcat committers I am pleased to announce that
> Emmanuel Bourg (ebourg) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.

Welcome!

Regards,
Violeta

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

Re: [ANN] New committer: Emmanuel Bourg

[tomcat]

Et les miennes !

On 20.01.2017 18:14, Zala Pierre GOUPIL wrote:

Toutes mes félicitations !

Le 20 janv. 2017 18:12, "Mark Thomas"  a écrit :


On behalf of the Tomcat committers I am pleased to announce that
Emmanuel Bourg (ebourg) has been voted in as a new Tomcat committer.

Please join me in welcoming him.

Regards,

Mark

-
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: [ANN] New committer: Emmanuel Bourg

[Zala Pierre GOUPIL]

Toutes mes félicitations !

Le 20 janv. 2017 18:12, "Mark Thomas"  a écrit :

> On behalf of the Tomcat committers I am pleased to announce that
> Emmanuel Bourg (ebourg) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.
>
> Regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

[ANN] New committer: Emmanuel Bourg

[Mark Thomas]

On behalf of the Tomcat committers I am pleased to announce that
Emmanuel Bourg (ebourg) has been voted in as a new Tomcat committer.

Please join me in welcoming him.

Regards,

Mark

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

Re: TomcatCon @ ApacheCon

[tomcat]

Maybe in the "thought-provoking" category :
Compare and discuss :
https://news.netcraft.com/archives/2016/12/21/december-2016-web-server-survey.html
https://w3techs.com/technologies/overview/web_server/all
https://plumbr.eu/uncategorized/most-popular-java-ee-servers-2016-edition

or (being facetious) :
why are you guys developing in/for tomcat/java ?
should you not be developing in/for nginx/php ?

On 19.01.2017 23:45, Mark Thomas wrote:

On 17/01/2017 22:04, Mark Thomas wrote:

On 09/01/2017 11:57, Mark Thomas wrote:




I look forward to hearing your topic ideas.


Thanks for all the great ideas so far. I've tried to pull them all
together here:
https://cwiki.apache.org/confluence/display/TOMCAT/TomcatCon+NA+2017

I'm waiting to hear back from the ApacheCon folks as to how this would
work. I'll update this thread with info as I get it.


Good news. I have received the following reply:


I think this sounds great (it's wonderful to see all the ideas on the
content side flowing on the list) and in short, yes we can do this. Some
specifics:

-We can do an element of separate branding on signage/promotion/badges
-A dedicated track branded as the Tomcat Conference is great.
-100% on board with community selecting the content

The questions/points I'd want to confirm would be:
1. Could the sessions/track live on the ApacheCon schedule as the Tomcat
Conference 'track? or do you need a fully separate schedule?

2. Would you need a Tomcat Conference only registration or could we use
the ApacheCon registration form with an add-on 'Check here to sign up
for the Tomcat Conference'? I think that is what you meant, but just
confirming.

Thanks,

Angela


For those of you who don't know her, Angela is our ApacheCon contact at
the Linux Foundation who produce ApacheCon for the ASF.

My response to the questions was:
1. Shared schedule is fine.
2. A separate registration page is preferred.

I've also asked if we should go ahead and use the ApacheCon CFP.

More updates as I get them.

Mark


-
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

Separate and Redirect Tomcat Embedded 8.5.6 Log

[Costin Giorgian Papuc]

I have an app that can take a war file and deploy it with embedded tomcat .5.6. 
So, for each uploaded war file I do the following
Tomcat tomcat = new Tomcat();
tomcat.setPort(port);
File catalinaHome = new File(TOMCAT_DIR + port);
catalinaHome.mkdirs();
File webapp = new File(TOMCAT_DIR + port + "\\webapps");
webapp.mkdir();
tomcat.setBaseDir(catalinaHome.getAbsolutePath());

try {
File war = new File("myapp.war"); //the given war file
StandardContext context = (StandardContext) tomcat.addWebapp("/myapp", 
war.getAbsolutePath());
context.setAntiResourceLocking(true);
tomcat.start();
} catch (Exception e) {
e.printStackTrace();
}

I don't have any idea how can I redirect the output.
I read that tomcat embedded log to System.out, and I was able to redirect to 
file with:
PrintStream out = new PrintStream(new FileOutputStream("output.txt"));
System.setOut(out);
but redirect all output, and I want something that log to a different file for 
each tomcat instance that I run.
Any solution that I found so far don't resolve my problem.
So, how can I separate output for each tomcat instance?
Thanks


The information in this email is confidential and may be legally privileged. It 
is intended solely for the addressee. Any opinions expressed are mine and do 
not necessarily represent the opinions of the Company. Emails are susceptible 
to interference. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on 
it, is strictly prohibited and may be unlawful. If you have received this 
message in error, do not open any attachments but please notify the Endava 
Service Desk on (+44 (0)870 423 0187), and delete this message from your 
system. The sender accepts no responsibility for information, errors or 
omissions in this email, or for its use or misuse, or for any act committed or 
omitted in connection with this communication. If in doubt, please verify the 
authenticity of the contents with the sender. Please rely on your own virus 
checkers as no responsibility is taken by the sender for any damage rising out 
of any bug or virus infection.

Endava Limited is a company registered in England under company number 5722669 
whose registered office is at 125 Old Broad Street, London, EC2N 1AR, United 
Kingdom. Endava Limited is the Endava group holding company and does not 
provide any services to clients. Each of Endava Limited and its subsidiaries is 
a separate legal entity and has no liability for another such entity's acts or 
omissions.

AW: https redirect failed for POST request when behind a load balancer

[Kreuser, Peter]

Hi Bin

> Konstantin:
> Thank you very much for your reply. To answer your question
> 
> 1. The api-lb and lb-api was a typo.
> 
> 2. I was able to reproduce this problem with a single server behind the 
> load balancer.  
> Where http://lb-test-api:8080 was set to forward to https://lb-test-api:8443 
> using vip. 
> On the test server, 8080 was redirect to 8443 in server.xml and modified 
> web.xml as described in tomcat doc.
>  My war file's web.xml also included  section. With 
> these settings, my Post request to http://my-test-api:8080 was automatically 
> redirect to https://my-test-api:8443 with no problem. The Post is a REST 
> webservice call so single response was received. 
> 
> Inside the access log, when post via the load balancer 
> 10.166.27.33 - - [19/Jan/2017:11:21:27 -0800] 8443 "GET /theacturalapicallurl 
>  HTTP/1.1" 405 1045
> When post directly to the my-test-api:8080, the access log got recorded as 
> 10.20.96.62 - - [19/Jan/2017:11:28:15 -0800] 8080 "POST /theacturalapicallur 
> HTTP1.1l" 201 277
> 
> 3. Here is my setup
> 
>   (load balancer) (my-test-api) 
> 
> 
> This looks to me like Tomcat is performing the POST Redirect GET when there 
> is a proxy and the call was redirected to prevent the server from MITM 
> attack. 
> 
> Hopefully this clarifies my question,
> 
> Thank you very much,
> 
> Bin
> 

I wonder if the redirect will use a 301 or 302 and that per default results in 
a GET. How is this implemented in the loadbalancer?

As I read a 307 should preserve the request method. From: 
http://stackoverflow.com/questions/13628831/apache-301-redirect-and-preserving-post-data
 

If you want to enforce the redirect to https, you should however consider a 
different approach.

If it is necessary to protect the data, no POST should ever go to http/port 
8080, as the data will be open in the first request.
So in my opinion the calling website/application that is sending the data to 
8080 should be modified in the first place.

Best regards

Peter 

> -Original Message-
> From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
> Sent: Wednesday, January 18, 2017 11:43 PM
> To: Tomcat Users List 
> Subject: Re: https redirect failed for POST request when behind a load 
> balancer
> 
> 1. You know that "api-lb" and "lb-api" above are two different host names?
> 
> 2. What HTTP response code is send to client to perform the redirection?
> (What is displayed by access log? Or by "network" monitoring tool in browser. 
>  What are actual responses to perform the redirection).
> 
> Some response codes used for redirects allow the browser to change POST to 
> GET, some do not. See the HTTP protocol specification for details.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.apache.org_tomcat_Specifications=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ=g9XvhdAG4g80Ajw7i4CvF3kysWtESxDF6NFX8j630c8=mOjl8_uOfuo3lfn8xDS6jwCZao9az7SjXLxgAh-2Twc=
>  
> 
> Is redirect performed by a single response, or there are several redirect 
> responses in a chain, A -> B -> C/ ?
> 
> 3. Actual configuration?
> 
> (For someone else to reproduce the issue or to match your tale to their 
> configs).
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
>

Re: FW: tomcat 8080 thread not reduced

[tomcat]

On 20.01.2017 03:59, smith wrote:

Hi, chris:


"busy" is the same as "active".

When not use , our busy thread always keep under 10 while the 
currentThreadCount keeps high (these are get from tomcat manager), So we really don't 
know how many threads are truly free. How many are in keepAlivedStatus



That may be my fault, in my contributions earlier.
I believe that it is reasonable to assume that "busy" also counts the threads which are 
currently "in keepAlive" status. That is because these threads are not "free" to handle 
new requests yet from other clients than the one which "owns" the connection on which they 
are in keepAlive.

But I do not know the code, so someone else may want to confirm/correct this.

Anyway, you do have a simple way to verify this : reduce the keepAlive to 5 seconds, 
instead of 20, and see how it impacts the counts that you are seeing.

If keepAlive counts as "busy", then you should see less "busy" threads on 
average.
If keepAlive does not count as busy, then you will see no difference.

One more proviso : the above is for the case where clients connect to tomcat directly, 
without a front-end, which may itself create a pool of permanent connections to tomcat.

(Chris already mentioned that).
If there is such a front-end, and it does something like "pings" on each connection to the 
tomcat back-end connections all the time, then you would have, on the tomcat side, an 
alsmost constant number of threads in keepAlive wait status.


All in all, considering your ultimate purpose (to determine when your tomcat is getting 
close to the limit of what it can handle, and decide if you need more tomcats or not), I 
believe that your current focus on the number of tomcat threads active or not, may not be 
the best diagnostic tool.


Maybe a better tool would be to look at the number of connections which are waiting to be 
accepted. This should always be 0, or small.  If it starts growing, then that is a clear 
signal that tomcat is getting saturated. (This is related to the "acceptCount" attribute 
of the Connectors).


Another tool may be to look at how long it takes tomcat to respond to requests (or at 
least some specific types of requests).  You can probably set a baseline, when you know 
that tomcat is really not heavily loaded (maybe on your development system e.g.).  And 
then, when you see this response time increasing seriously, is when you should start 
analysing why. (*)


This kind of approach would have the advantage of focusing on what really matters in the 
end : the ability of your server (as a whole : hardware, OS, tomcat and applications 
included) to handle a given number of requests within a given time interval, with /your/ 
mix of clients and applications.



(*) because the reason may be for example that you need more memory, not more 
threads.



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, January 19, 2017 4:38 PM
To: Tomcat Users List
Subject: Re: FW: tomcat 8080 thread not reduced

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Smith,

On 1/18/17 8:25 PM, smith wrote:

I don't care if the threads will be reduced, I just want to know why.


Okay.


And we want to use the account to determine when the tomcat capacity
is not enough that we need to add max configuration or add new tomcat
servers.


Set your initial and max threads to the same value (pool size =
constant) and then monitor the "active count" with a Nagios warning at e.g. 80% 
usage.


Since not use the , the busy thread account also cannot tell
us the correct active threads count.


"busy" is the same as "active".


In another email thread, you said if use , it will tell us
the right active thread count not just busy count, right?


I would always use an  for at least two different reasons:

1. Thread management (e.g. reducing threads if necessary) 2. Shared 
thread-pools (no need to have port 8080 and 8443 with separate pools)

- -chris


-Original Message- From: Christopher Schultz
[mailto:ch...@christopherschultz.net] Sent: Wednesday, January 18,
2017 3:28 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080 thread
not reduced

Smith,

On 1/18/17 12:47 AM, smith wrote:

So the tomcat default executor will not reduce the thread count until
it reach to the max configuration?


By default, you get a thread pool that isn't as smart as an executor.


Will it reduce when it reach to max?


Not unless you use an .


And why the default not reduce the thread?


Because it didn't do so in the past, before  was introduced.

I'm curious: if you are willing to have e.g. 200 threads available at
any time during the life of the JVM, why does it matter if those
threads are reduced during times of inactivity?

I think of threads as a resource like memory, where if you are going
to allocate X resources, you may as well allocate X resources and be
done with it. Growing and shrinking pools of things just adds
complexity and reduces