Re: JMX currentThreadsBusy less than connections/requests when use APR connector

[linbo liao]

Hi,

Here is the Connector configuration:



I use wrk, the currentThreadsBusy is higher than the value in ab testing,
but most of time is less than 40.

./wrk -t100 -c 100 -d 10s http://10.211.55.4:8080/

For APR connector, will it get one thread from the poll to deal with each
request?


2017-03-08 22:45 GMT+08:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Linbo,
>
> On 3/7/17 10:14 PM, linbo liao wrote:
> > I setup local environment to test Tomcat monitor.
> >
> > The Environment:
> >
> > Tomcat: 8.5.5 VM: Ubuntu 14.04.1 LTS HTTP PORT: 8080 IP:
> > 10.211.55.4
> >
> > Tomcat use APR connector, I test the tomcat via ab command, find
> > JMX currentThreadsBusy < 10 all of the time.
> >
> > ab -n 10 -c 100 10.211.55.4:8080/
> >>
> >
> > I tried to search the reason but without the result. For BIO each
> > thread to handle one connection, so currentThreadsBusy can show the
> > performance of tomcat.
> >
> > But for APR connector, what's the meaning of currentThreadsBusy?
>
> Please post your  configuration.
>
> It seems that ab isn't a very good load-generator for several reasons.
> But you should be able to get more than Java 10 threads working at a tim
> e.
>
> You are probably expecting ~100 threads busy at all times, right?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYwBkcAAoJEBzwKT+lPKRYxLQQAJsr6IWI6kRaCmEg+SMZRKco
> 8ALINQrUvkUZYvIx23wlr7cKpmZ0g02RVXKn8+usEsiZ9vBwb6ap3HV7RCM/xl33
> zaAuxYPNsJ9bMUnTTkxr5ciSvMGI1FhvTWazEHprLoiPV1RtBwKBLTbztxQTQfO4
> 0AqfRgucC0NJbEPzVwKc6FB9qUl+U3XROUCC2AKmaFIHbQDSPnCLKX3hyzaOsH7R
> cd8nr3teQxoisIT3MuhaWPMDdfdKbe0ZmPj39borGUvHwUL1kRCz3wYvoQN3kCg5
> YHxjV3B9TYqU1q0TiILuQvO1rbG8G3QLIXFz8eNdX1XwS0oIRYAJfhTqSbxBuTlm
> 1jSrS716Kd2JkmNWmoSLHFSvBUkevirh5ZL6B9SuFvV449lCgBjwV//wiE/oskbT
> 6+jKDrL0ReCw8NtfWbCaeXmltyR9ir7x4SSjT1iSpg/ZGnxmKkdiZFoR/mWDcH5G
> y4TwbmDC0RNAfC9lNCp5cBtrIZkoJM53iOtUCB22I3tco/hNB91TV8WN5RKqAHl1
> Cn7FLfSGwBQRv3UHfeWmMwxcP4Q4FxMbpqtHv2PAcjB7skcsbR6BUth9gY3FbWmF
> DvKL941SuDPLtA9IVr/nplvwlMUV/QQNi+tZXuL9Xf1GoCgcM7uVQkcuhlf+QpFm
> ELHZ5kXO3Zs7RrycRnL3
> =6bmJ
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Spring fails with Tomcat 8.0.41 and unpackWARs=false

[Thomas Meyer]

Hi,

if anybody else is hitting this:

This commit seems to have broken the Spring when running under Tomcat  
with unpackWARs=false -  
https://github.com/apache/tomcat80/commit/7e767cc6efe79cdd367213da3c1f88711a29ad7a#diff-a72fb99b0729353084d2c437f749e718


I did open a Jira Bug report against Spring  
https://jira.spring.io/browse/SPR-15332 to track the issue.


with kind regards
thomas




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

Re: Logging TLS Session Failures

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Durga,

On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
> We are using JSSE only not APR. Looking for handshake failures.
> 
> Yes, using JSSE SSL debug, we are able to get all handshake 
> (-Djavax.net.debug=ssl:handshake) logs including success cases.
> These are still quite bit expense logs and meant for debug
> purposes. As you said it might impact performance that's the
> reason, trying for any other optimal solution here.

I know of no way to be notified about handshake failures on the server
side. You may not be able to fulfill this requirement if using Java
for your crypto.

Honestly, I'm not sure why you care about failed TLS handshakes. Are
you trying to implement a NIDS in your application? This is
better-handled by a network component specifically-designed for this
kind of thing.

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

iQIcBAEBCAAGBQJYwEBVAAoJEBzwKT+lPKRYHzkP/1O2jPMu6Z9MBdnCF6LD7FQl
LMWA6jmO2YjmZFPtJykyUXHuL3beBk/+5cPV275ZApp1brJmmqnxR68P4ZuedOwY
pX+dLiBTvmLYmsFoYxxfdvpl44UICwvq6qx/4VsSS0okrz9JYQtmO9d2glYG6bDD
onLmqYoivB2N+18jXoT7PAzBZcAhHFbIFPIox4VXjs9za/WQ4Oc+BUecUKpOCc0i
yvMz1I9Bo5E+tCMkTsTpbtq/Sk5lF7JozOycda3OVmLpVTf7Xz07luOF0ZaJAY0t
VMHvNEOuph9dJxkS6mXlPnqqQwf3Prlwhx/zjWm6HT9prGBMraVb9laq44qMMUcg
rDSSgfxZDiSJKDw7bCA3+o3KQfqIqbkLH9nQ2WICS2YAd9jn5tqy5Faf/H7Dd71D
mYOdVxXPk5XJPuVOWaK9dVQOEppZ8JWjxxKaofFxFXmQpaiVbSP5FLduRrkvKgJc
e9necMTzyxs9RwvpJjQtf10blDc51bL3Y+KjbTgJoPTqAIm8kUgI9VOE5NUs5eip
1MO9ub52ojavC10B+lU3OGggwHp068ozkM491stTZialCaTCmbo7LPZtKzIz0g4j
q3JgDS4Y4LVPOoLPjUSfcbzTsxnS2V/SkLhOwQpnvw4lTLrotq5CGPJDQD5ix67j
2WbMcngOqAvk16kPb5u+
=F7yo
-END PGP SIGNATURE-

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

RE: Tomcat WebSocket does not always send asynchronous messages

[Pesonen, Harri]

Here are my versions of these test files:

/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.apache.tomcat.websocket.server;

import java.net.URI;
import java.nio.ByteBuffer;
import java.util.concurrent.CountDownLatch;

import javax.websocket.ClientEndpointConfig;
import javax.websocket.ContainerProvider;
import javax.websocket.MessageHandler;
import javax.websocket.Session;
import javax.websocket.WebSocketContainer;

import org.apache.catalina.Context;
import org.apache.catalina.servlets.DefaultServlet;
import org.apache.catalina.startup.Tomcat;
import org.apache.catalina.startup.TomcatBaseTest;
import org.apache.tomcat.websocket.TesterAsyncTiming;
import 
org.apache.tomcat.websocket.TesterMessageCountClient.TesterProgrammaticEndpoint;
import org.junit.Assert;
import org.junit.Test;

//@Ignore // Test passes but GC delays can introduce false failures.
public class TestAsyncMessages extends TomcatBaseTest {

@Test
public void testAsyncTiming() throws Exception {

Tomcat tomcat = getTomcatInstance();
// No file system docBase required
Context ctx = tomcat.addContext("", null);
ctx.addApplicationListener(TesterAsyncTiming.Config.class.getName());
DefaultServlet defaultServlet = new DefaultServlet();
WebSocketContainer wsContainer =
ContainerProvider.getWebSocketContainer();

Tomcat.addServlet(ctx, "default", defaultServlet);
ctx.addServletMappingDecoded("/", "default");

ctx.addParameter(Constants.
BINARY_BUFFER_SIZE_SERVLET_CONTEXT_INIT_PARAM, "" + 
TesterAsyncTiming.Config.LARGE_DATA_SIZE);
ctx.addParameter(org.apache.tomcat.websocket.server.Constants.
TEXT_BUFFER_SIZE_SERVLET_CONTEXT_INIT_PARAM, "" + 
TesterAsyncTiming.Config.LARGE_DATA_SIZE);

wsContainer.setDefaultMaxBinaryMessageBufferSize(TesterAsyncTiming.Config.LARGE_DATA_SIZE);

wsContainer.setDefaultMaxTextMessageBufferSize(TesterAsyncTiming.Config.LARGE_DATA_SIZE);

tomcat.start();

ClientEndpointConfig clientEndpointConfig = 
ClientEndpointConfig.Builder.create().build();
Session wsSession = wsContainer.connectToServer(
TesterProgrammaticEndpoint.class,
clientEndpointConfig,
new URI("ws://localhost:" + getPort() + 
TesterAsyncTiming.Config.PATH));

AsyncTimingClientHandler handler = new AsyncTimingClientHandler();
wsSession.addMessageHandler(ByteBuffer.class, handler);
wsSession.getBasicRemote().sendText("Hello");

System.out.println("Sent Hello message, waiting for data");
handler.waitForLatch();
Assert.assertFalse(handler.hasFailed());
}

private static class AsyncTimingClientHandler implements 
MessageHandler.Partial {

private long lastMessage = 0;
private int sequence = 0;
private int count = 0;
private CountDownLatch latch = new CountDownLatch(1);
private volatile boolean fail = false;
private long minDelayLong = TesterAsyncTiming.Config.SLEEP_MILLI - 20;
private long maxDelayLong = TesterAsyncTiming.Config.SLEEP_MILLI + 20;
private long maxDelayShort = 20;

@Override
public void onMessage(ByteBuffer message, boolean last) {
if (lastMessage == 0) {
// First message. Don't check
sequence ++;
lastMessage = System.currentTimeMillis();
} else {
long newTime = System.currentTimeMillis();
long diff = newTime - lastMessage;
lastMessage = newTime;
if (sequence == 0) {
sequence++;
if (message.capacity() != 
TesterAsyncTiming.Config.LARGE_DATA_SIZE) {
System.out.println(
"Expected size " + 
TesterAsyncTiming.Config.LARGE_DATA_SIZE + " but was [" + message
.capacity() + "], count [" + count + 
"]");
fail = true;
}
if (diff < minDelayLong) {
System.out.println(

Re: Logging TLS Session Failures

[Durga Srinivasu Karuturi]

Chris,

We are using JSSE only not APR. Looking for handshake failures.

Yes, using JSSE SSL debug, we are able to get all handshake
(-Djavax.net.debug=ssl:handshake) logs including success cases. These are
still quite bit expense logs and meant for debug purposes. As you said it
might impact performance that's the reason, trying for any other optimal
solution here.


Thanks,
Durga Srinivasu

On Wed, Mar 8, 2017 at 8:10 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Durga,
>
> On 3/8/17 9:29 AM, Durga Srinivasu Karuturi wrote:
> > We have a requirement in our application to log all TLS session
> > failures.
>
> Specifically, what kind of failures? Failed handshakes? Initial or
> re-negotiation? Are you using JSSE or APR? If JSSE, are you using the
> OpenSSL crypto-backend?
>
> > We are using Tomcat 8.5.11 using JSSE for SSL layer. Is there any
> > way to configure tomcat to log/trace any TLS Failure on tomcat
> > sessions?
>
> Not at the moment. If you are using JSSE with the Oracle crypto
> backend, you can put it into debug mode, but you don't want to do
> that; it will produce so much output it will measurably slow-down your
> server.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYwBfWAAoJEBzwKT+lPKRYPDMP/06EccSRlV9KGNtQ2167Plsw
> PNefVfp4qcSHlsT8xBe2pWDU52ybLqOugBKGtTxa/ZGHDo1aMJCR+HZJqNspujdl
> Qe/7GVFKlzu6d8ucBJ/VgjM/sU+dLQnYW7sLJpfiM7gtOD3zcRYH1BN7iTW1Ij6e
> JYFrqvP6TJpdHtJgQ9n8AXB/+iUzqF6sigJPYFe6HNM4oAiuU6M8AzhNwtNM2AUN
> fnE2OyB+0FNcnwizLqhZ9+RJZeMIbb8wsyUJiOGkqyTBFcYrsPx5VR6A29+u+3R1
> FKES8jgzDAqlztdG2kZK8EmUrJokRT9aDoDKYbuSWW/+QujDDpl76pLdSaTR/eVB
> RuJSRwkyV3VA68Wg6FBGFNNCmV/1t2Yii3dLxa1aLph6TipIyEo16nyDr7yf5HPZ
> hKyfoeyIMVvreN0ldjwNlsKvlHHDheun5l02/h7hE934UYb+9KyfY1vhWuzfNcKu
> QgG8oExdi91GfjAR9vApTuVm5fAra07oqNzlXhFrx3dbYWrJamTL6uymlvxoHhhL
> KkVz6F68sMR0AqDV2+tgcKOxV7GWl+kQueMo7csBZ54kNaNN/Qcw2tRyG4iz0mNk
> ihRG5REvbqTGfN+TQzoeYLdysdU7n1R/tfxb4dHeqP6x8FMOTwz/yRdYywUsX+9e
> 83XGxnDX3Ps0mW9xA8Ab
> =H9l5
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: JMX currentThreadsBusy less than connections/requests when use APR connector

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linbo,

On 3/7/17 10:14 PM, linbo liao wrote:
> I setup local environment to test Tomcat monitor.
> 
> The Environment:
> 
> Tomcat: 8.5.5 VM: Ubuntu 14.04.1 LTS HTTP PORT: 8080 IP:
> 10.211.55.4
> 
> Tomcat use APR connector, I test the tomcat via ab command, find
> JMX currentThreadsBusy < 10 all of the time.
> 
> ab -n 10 -c 100 10.211.55.4:8080/
>> 
> 
> I tried to search the reason but without the result. For BIO each
> thread to handle one connection, so currentThreadsBusy can show the
> performance of tomcat.
> 
> But for APR connector, what's the meaning of currentThreadsBusy?

Please post your  configuration.

It seems that ab isn't a very good load-generator for several reasons.
But you should be able to get more than Java 10 threads working at a tim
e.

You are probably expecting ~100 threads busy at all times, right?

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

iQIcBAEBCAAGBQJYwBkcAAoJEBzwKT+lPKRYxLQQAJsr6IWI6kRaCmEg+SMZRKco
8ALINQrUvkUZYvIx23wlr7cKpmZ0g02RVXKn8+usEsiZ9vBwb6ap3HV7RCM/xl33
zaAuxYPNsJ9bMUnTTkxr5ciSvMGI1FhvTWazEHprLoiPV1RtBwKBLTbztxQTQfO4
0AqfRgucC0NJbEPzVwKc6FB9qUl+U3XROUCC2AKmaFIHbQDSPnCLKX3hyzaOsH7R
cd8nr3teQxoisIT3MuhaWPMDdfdKbe0ZmPj39borGUvHwUL1kRCz3wYvoQN3kCg5
YHxjV3B9TYqU1q0TiILuQvO1rbG8G3QLIXFz8eNdX1XwS0oIRYAJfhTqSbxBuTlm
1jSrS716Kd2JkmNWmoSLHFSvBUkevirh5ZL6B9SuFvV449lCgBjwV//wiE/oskbT
6+jKDrL0ReCw8NtfWbCaeXmltyR9ir7x4SSjT1iSpg/ZGnxmKkdiZFoR/mWDcH5G
y4TwbmDC0RNAfC9lNCp5cBtrIZkoJM53iOtUCB22I3tco/hNB91TV8WN5RKqAHl1
Cn7FLfSGwBQRv3UHfeWmMwxcP4Q4FxMbpqtHv2PAcjB7skcsbR6BUth9gY3FbWmF
DvKL941SuDPLtA9IVr/nplvwlMUV/QQNi+tZXuL9Xf1GoCgcM7uVQkcuhlf+QpFm
ELHZ5kXO3Zs7RrycRnL3
=6bmJ
-END PGP SIGNATURE-

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

Re: Logging TLS Session Failures

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Durga,

On 3/8/17 9:29 AM, Durga Srinivasu Karuturi wrote:
> We have a requirement in our application to log all TLS session
> failures.

Specifically, what kind of failures? Failed handshakes? Initial or
re-negotiation? Are you using JSSE or APR? If JSSE, are you using the
OpenSSL crypto-backend?

> We are using Tomcat 8.5.11 using JSSE for SSL layer. Is there any
> way to configure tomcat to log/trace any TLS Failure on tomcat
> sessions?

Not at the moment. If you are using JSSE with the Oracle crypto
backend, you can put it into debug mode, but you don't want to do
that; it will produce so much output it will measurably slow-down your
server.

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

iQIcBAEBCAAGBQJYwBfWAAoJEBzwKT+lPKRYPDMP/06EccSRlV9KGNtQ2167Plsw
PNefVfp4qcSHlsT8xBe2pWDU52ybLqOugBKGtTxa/ZGHDo1aMJCR+HZJqNspujdl
Qe/7GVFKlzu6d8ucBJ/VgjM/sU+dLQnYW7sLJpfiM7gtOD3zcRYH1BN7iTW1Ij6e
JYFrqvP6TJpdHtJgQ9n8AXB/+iUzqF6sigJPYFe6HNM4oAiuU6M8AzhNwtNM2AUN
fnE2OyB+0FNcnwizLqhZ9+RJZeMIbb8wsyUJiOGkqyTBFcYrsPx5VR6A29+u+3R1
FKES8jgzDAqlztdG2kZK8EmUrJokRT9aDoDKYbuSWW/+QujDDpl76pLdSaTR/eVB
RuJSRwkyV3VA68Wg6FBGFNNCmV/1t2Yii3dLxa1aLph6TipIyEo16nyDr7yf5HPZ
hKyfoeyIMVvreN0ldjwNlsKvlHHDheun5l02/h7hE934UYb+9KyfY1vhWuzfNcKu
QgG8oExdi91GfjAR9vApTuVm5fAra07oqNzlXhFrx3dbYWrJamTL6uymlvxoHhhL
KkVz6F68sMR0AqDV2+tgcKOxV7GWl+kQueMo7csBZ54kNaNN/Qcw2tRyG4iz0mNk
ihRG5REvbqTGfN+TQzoeYLdysdU7n1R/tfxb4dHeqP6x8FMOTwz/yRdYywUsX+9e
83XGxnDX3Ps0mW9xA8Ab
=H9l5
-END PGP SIGNATURE-

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

RE: JMX currentThreadsBusy less than connections/requests when use APR connector

[smith]

Our production usage also has same phenomenon that my "currentThreadsBusy" 
always not high (3-5), but my "currentThreadCount" will go to 200-300 
sometimes. I know that at some busy time, more threads will be created, so the 
thread pool get high, but at the same time, the busy threads will also 
increase, but I never catch when it also went high.

-Original Message-
From: Suvendu Sekhar Mondal [mailto:suv3...@gmail.com] 
Sent: Wednesday, March 08, 2017 1:43 PM
To: Tomcat Users List
Subject: Re: JMX currentThreadsBusy less than connections/requests when use APR 
connector

Linbo,

"currentThreadsBusy" is number of busy threads. These are the threads are being 
actively use. If you are seeing this count > 0 for long time(depending on your 
application type), then most likely you have "hung thread". In that case thread 
dump analysis will show you root of the problem.

"currentThreadCount" is current threads in thread pool. To track thread pool 
usage, you can use this counter.

Thanks!
Suvendu

On Wed, Mar 8, 2017 at 8:44 AM, linbo liao  wrote:
> Hi,
>
> I setup local environment to test Tomcat monitor.
>
> The Environment:
>
> Tomcat: 8.5.5
> VM: Ubuntu 14.04.1 LTS
> HTTP PORT: 8080
> IP: 10.211.55.4
>
> Tomcat use APR connector, I test the tomcat via ab command, find JMX 
> currentThreadsBusy < 10 all of the time.
>
> ab -n 10 -c 100 10.211.55.4:8080/
>>
>
> I tried to search the reason but without the result. For BIO each 
> thread to handle one connection, so currentThreadsBusy can show the 
> performance of tomcat.
>
> But for APR connector, what's the meaning of currentThreadsBusy?
>
> Thanks in advance.
>
> Thanks,
> Linbo

-
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

Logging TLS Session Failures

[Durga Srinivasu Karuturi]

Hi,

We have a requirement in our application to log all TLS session failures.

We are using Tomcat 8.5.11 using JSSE for SSL layer. Is there any way to
configure tomcat to log/trace any TLS Failure on tomcat sessions?

Thanks,
Durga Srinivasu

RE: Tomcat WebSocket does not always send asynchronous messages

[Pesonen, Harri]

Hello, and sorry for top-posting, I don't know how to configure Outlook to do 
it differently.

I was finally able to run your test. I had a lot of trouble doing it:
* did not have SVN, downloaded TortoiseSVN
* tried to open the project in IDEA, but failed miserably, I really hope that 
there was pom.xml
* was able to build whole Tomcat and test using ant command line, but it took 
so long, had to abort
* was not able to run this single test with ant:

Testsuite: org.apache.tomcat.websocket.server.TestAsyncMessages.java
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec

Caused an ERROR
org.apache.tomcat.websocket.server.TestAsyncMessages.java
java.lang.ClassNotFoundException: 
org.apache.tomcat.websocket.server.TestAsyncMessages.java

* but was able to make the Eclipse project with "ant ide-eclipse"
* was able to run the unit test in Eclipse:

08-Mar-2017 14:14:40.538 INFO [main] 
org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case 
[testAsyncTiming]
08-Mar-2017 14:14:42.676 INFO [main] org.apache.coyote.AbstractProtocol.init 
Initializing ProtocolHandler ["http-nio-127.0.0.1-auto-1"]
08-Mar-2017 14:14:42.778 INFO [main] 
org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared 
selector for servlet write/read
08-Mar-2017 14:14:42.800 INFO [main] 
org.apache.catalina.core.StandardService.startInternal Starting service Tomcat
08-Mar-2017 14:14:42.802 INFO [main] 
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: 
Apache Tomcat/@VERSION@
08-Mar-2017 14:14:43.213 INFO [main] org.apache.coyote.AbstractProtocol.start 
Starting ProtocolHandler [http-nio-127.0.0.1-auto-1-54783]
Sent Hello message, waiting for data
Expected diff < 500,000 but was [6054390], count [2]
Expected diff < 500,000 but was [1015710], count [14]
Expected diff < 500,000 but was [642270], count [25]
Expected diff < 500,000 but was [1712852], count [26]
Expected diff < 500,000 but was [595293], count [41]
Expected diff < 500,000 but was [792673], count [61]
Expected diff < 500,000 but was [799777], count [62]
Expected diff < 500,000 but was [531738], count [68]
Expected diff < 500,000 but was [532922], count [76]
Expected diff < 500,000 but was [673851], count [98]
Expected diff < 500,000 but was [538054], count [133]
Expected diff < 500,000 but was [747276], count [158]
Expected diff < 500,000 but was [794646], count [262]
Expected diff < 500,000 but was [1290461], count [263]
Expected diff < 500,000 but was [1013341], count [296]
Expected diff < 500,000 but was [582267], count [311]
Expected diff < 500,000 but was [1377703], count [337]
Expected diff < 500,000 but was [1698245], count [338]
Expected diff < 500,000 but was [1303488], count [424]
Expected diff < 500,000 but was [965181], count [425]
Expected diff < 500,000 but was [534896], count [455]
Expected diff < 500,000 but was [847938], count [458]
Expected diff < 500,000 but was [883862], count [473]
Expected diff < 500,000 but was [1026368], count [475]
Expected diff < 500,000 but was [1096241], count [476]
Expected diff < 500,000 but was [518710], count [481]
Expected diff < 500,000 but was [1053607], count [482]
Expected diff < 500,000 but was [641481], count [500]
Expected diff < 500,000 but was [565292], count [512]
Expected diff < 500,000 but was [808857], count [556]
Expected diff < 500,000 but was [643455], count [653]
Expected diff < 500,000 but was [508447], count [670]
Expected diff < 500,000 but was [960839], count [671]
Expected diff < 500,000 but was [954918], count [683]
Expected diff < 500,000 but was [601215], count [749]
Expected diff < 500,000 but was [561345], count [752]
Expected diff < 500,000 but was [688062], count [935]
Expected diff < 500,000 but was [1405730], count [937]
Expected diff < 500,000 but was [1414415], count [938]
Expected diff < 500,000 but was [1284935], count [941]
Expected diff < 500,000 but was [516737], count [995]
Expected diff < 500,000 but was [587398], count [1067]
Expected diff < 500,000 but was [946233], count [1079]
Expected diff < 500,000 but was [5403041], count [1114]
Expected diff < 500,000 but was [1181114], count [1115]
Expected diff < 500,000 but was [554239], count [1118]
Expected diff < 500,000 but was [1437706], count [1121]
Expected diff < 500,000 but was [577925], count [1240]
Expected diff < 500,000 but was [1226115], count [1241]
Expected diff < 500,000 but was [2194850], count [1285]
Expected diff < 500,000 but was [522264], count [1292]
Expected diff < 500,000 but was [845964], count [1328]
Expected diff < 500,000 but was [3652294], count [1331]
Expected diff < 500,000 but was [727538], count [1343]
Expected diff < 500,000 but was [809252], count [1349]
Expected diff < 500,000 but was [1597188], count [1393]
Expected diff < 500,000 but was [525816], count [1394]
08-Mar-2017 14:15:09.251 INFO [main] org.apache.coyote.AbstractProtocol.pause 
Pausing ProtocolHandler ["http-nio-127.0.0.1-auto-1-54783"]
08-Mar-2017 14:15:09.266 

RE: httpOnly issue

[Pritchett, Mark S. (CONT)]

Hi All

I owe an apology, sorry.
Although I'd removed all apps I hadn't removed the instrumentation settings 
from start up. With these removed the issue has gone away.

Thanks for the support
Mark

-Original Message-
From: Pritchett, Mark S. (CONT) 
Sent: 08 March 2017 13:29
To: Tomcat Users List 
Subject: RE: httpOnly issue

Hi Mark

The problem remains if I remove all the webapps except ROOT.

Regards
Mark

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 08 March 2017 13:23
To: Tomcat Users List 
Subject: Re: httpOnly issue

On 08/03/17 12:53, Pritchett, Mark S. (CONT) wrote:
> Hi All
> 
> My first posting.
> 
> Server version: Apache Tomcat/7.0.67
> JVM Version:1.7.0_131-mockbuild_2017_02_07_02_15-b00
> 
> A vulnerability scan has shown that tomcat doesn't apply httpOnly to come 
> cookies.
> I need to determine if this can be 'corrected'.



> My understanding is that httpOnly is the default with this version of 
> tomcat: https://tomcat.apache.org/tomcat-7.0-doc/config/context.html
> Even so, I have set useHttpOnly in $CATALINA_BASE/conf/context.xml, but the 
> issue is still reported by a scan.
> 
> Any ideas please?

Read the docs more carefully. useHttpOnly applies to session cookies.

Any cookie the application creates, the application has to set the httpOnly 
attribute appropriately.

You have an application problem, not a Tomcat problem.

Mark


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



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.


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

Re: JMX currentThreadsBusy less than connections/requests when use APR connector

[Suvendu Sekhar Mondal]

Linbo,

"currentThreadsBusy" is number of busy threads. These are the threads
are being actively use. If you are seeing this count > 0 for long
time(depending on your application type), then most likely you have
"hung thread". In that case thread dump analysis will show you root of
the problem.

"currentThreadCount" is current threads in thread pool. To track
thread pool usage, you can use this counter.

Thanks!
Suvendu

On Wed, Mar 8, 2017 at 8:44 AM, linbo liao  wrote:
> Hi,
>
> I setup local environment to test Tomcat monitor.
>
> The Environment:
>
> Tomcat: 8.5.5
> VM: Ubuntu 14.04.1 LTS
> HTTP PORT: 8080
> IP: 10.211.55.4
>
> Tomcat use APR connector, I test the tomcat via ab command, find JMX
> currentThreadsBusy < 10 all of the time.
>
> ab -n 10 -c 100 10.211.55.4:8080/
>>
>
> I tried to search the reason but without the result. For BIO each thread to
> handle one connection, so currentThreadsBusy can show the performance of
> tomcat.
>
> But for APR connector, what's the meaning of currentThreadsBusy?
>
> Thanks in advance.
>
> Thanks,
> Linbo

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

RE: httpOnly issue

[Pritchett, Mark S. (CONT)]

Hi Mark

The problem remains if I remove all the webapps except ROOT.

Regards
Mark

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 08 March 2017 13:23
To: Tomcat Users List 
Subject: Re: httpOnly issue

On 08/03/17 12:53, Pritchett, Mark S. (CONT) wrote:
> Hi All
> 
> My first posting.
> 
> Server version: Apache Tomcat/7.0.67
> JVM Version:1.7.0_131-mockbuild_2017_02_07_02_15-b00
> 
> A vulnerability scan has shown that tomcat doesn't apply httpOnly to come 
> cookies.
> I need to determine if this can be 'corrected'.



> My understanding is that httpOnly is the default with this version of 
> tomcat: https://tomcat.apache.org/tomcat-7.0-doc/config/context.html
> Even so, I have set useHttpOnly in $CATALINA_BASE/conf/context.xml, but the 
> issue is still reported by a scan.
> 
> Any ideas please?

Read the docs more carefully. useHttpOnly applies to session cookies.

Any cookie the application creates, the application has to set the httpOnly 
attribute appropriately.

You have an application problem, not a Tomcat problem.

Mark


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



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.


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

Re: httpOnly issue

[Mark Thomas]

On 08/03/17 12:53, Pritchett, Mark S. (CONT) wrote:
> Hi All
> 
> My first posting.
> 
> Server version: Apache Tomcat/7.0.67
> JVM Version:1.7.0_131-mockbuild_2017_02_07_02_15-b00
> 
> A vulnerability scan has shown that tomcat doesn't apply httpOnly to come 
> cookies.
> I need to determine if this can be 'corrected'.



> My understanding is that httpOnly is the default with this version of tomcat: 
> https://tomcat.apache.org/tomcat-7.0-doc/config/context.html
> Even so, I have set useHttpOnly in $CATALINA_BASE/conf/context.xml, but the 
> issue is still reported by a scan.
> 
> Any ideas please?

Read the docs more carefully. useHttpOnly applies to session cookies.

Any cookie the application creates, the application has to set the
httpOnly attribute appropriately.

You have an application problem, not a Tomcat problem.

Mark


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

httpOnly issue

[Pritchett, Mark S. (CONT)]

Hi All

My first posting.

Server version: Apache Tomcat/7.0.67
JVM Version:1.7.0_131-mockbuild_2017_02_07_02_15-b00

A vulnerability scan has shown that tomcat doesn't apply httpOnly to come 
cookies.
I need to determine if this can be 'corrected'.

We're scanning using ZAP, 
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
It finds that the base URL, has several cookies like this example

  Cookie No HttpOnly Flag
  Cookie No HttpOnly Flag
  1
  2
  Low (Medium)
  pA cookie has been set without the HttpOnly flag, which means 
that the cookie can be accessed by JavaScript. If a malicious script can be run 
on this page then the cookie will be accessible and can be transmitted to 
another site. If this is a session cookie then session hijacking may be 
possible./p
  
  
  https://localhost:8443/
  ADRUM_BTa=R:0|g:2a2c9071-b525-4756-9f91-9dee7e72e8f0; 
Version=1; Max-Age=30; Expires=Wed, 08-Mar-2017 08:47:00 GMT; Path=/; 
Secure
  ADRUM_BTa=R:0|g:2a2c9071-b525-4756-9f91-9dee7e72e8f0; 
Version=1; Max-Age=30; Expires=Wed, 08-Mar-2017 08:47:00 GMT; Path=/; 
Secure
  


My understanding is that httpOnly is the default with this version of tomcat: 
https://tomcat.apache.org/tomcat-7.0-doc/config/context.html
Even so, I have set useHttpOnly in $CATALINA_BASE/conf/context.xml, but the 
issue is still reported by a scan.

Any ideas please?

Regards
Mark


The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.

Re: Propagation of Subject with JAAS and SecurityManager enabled

[kommersz]

Well, if there are no hints, here is my view.

I checked the code for locations where org.apache.catalina.Globals.SUBJECT_ATTR 
(or the String "javax.security.auth.subject") is used. There are seemingly two 
locations:
- org.apache.catalina.connector.Request.setUserPrincipal(...)
- org.apache.catalina.security.SecurityUtil.execute(...)
the way they are using the SUBJECT_ATTR key to put a Subject in the Session 
practically excludes the possibility of using the Subject from the JAAS login 
module.

Beyond that, org.apache.catalina.realm.JAASRealm.authenticate(String username, 
CallbackHandler callbackHandler) does effectively throw away the Subject gained 
after having extracted the user and role for creating a GenericPrincipal - so 
even a workaround with passing the subject between the JAAS LoginModule and a 
Valve in ThreadContext to smuggle it into the Session under SUBJECT_ATTR would 
not work.

I am new here, and do not know how things work, but beyond a few questions I 
would also make a proposal for a fix, and would be ready to deliver it if I get 
it approved :)
So:
- Is this intentional not to allow a Subject from a JAAS LoginModule to be used 
when switching to privileged mode using Subject.doAsPrivileged at a later point 
in the code? (I would doubt, but I may not know) 
- What is the purpose of putting the subject into the Session? As I understand 
(though haven't extensively studied), in JAAS a LoginModule has the 
responsibility to provide a Subject per request - so it could decide on its own 
if it wants to cache or not (though it does not have access to the Session)
- would it be a good idea to remove the subject field from 
org.apache.catalina.connector.Request and move it into GenericPrincipal as a 
"reference to parent"? As the principal is reliably passed around, it could be 
used.

Thanks,
Gabor

kommersz  írta:
>Hi,
>
>I am playing around with the following things:
> - X.509 authentication
>- Security Manager enabled
>- Custom JAAS login module via JAASRealm
>
>My custom JAAS login module properly propagates a javax.security.auth.Subject 
>instance at commit() back. My aim is to use this javax.security.auth.Subject 
>as a basis for authorization checks - expect 
>org.apache.catalina.security.SecurityUtil to take this over.
>Curiously, by the time it comes to 
>org.apache.catalina.security.SecurityUtil.execute(...) applying 
>Subject.doAsPrivileged, it is done with another javax.security.auth.Subject 
>instance.
>
>Having looked a bit into it what is happening, I see the followings
>- org.apache.catalina.security.SecurityUtil.execute(...) looks for a subject 
>to be present in the session object with key Globals.SUBJECT_ATTR 
>("javax.security.auth.subject").
>- if it is not present, it will create a new blank Subject containing only one 
>Principal, which is extracted from the requests 
>org.apache.catalina.connector.Request object (and store it in the session 
>afterwards under Globals.SUBJECT_ATTR)
>- org.apache.catalina.connector.Requests setUserPrincipal(Principal 
>principal) sets the session object with key Globals.SUBJECT_ATTR to a newly 
>initialized javax.security.auth.Subject with a single Principal. 
>
>Summary: to me it seems that the mechanism currently used to propagate the 
>Subject to org.apache.catalina.security.SecurityUtil.execute(...) _always_ 
>creates a new empty Subject and adds a single user principal into it.
>
>Questions:
>- do I miss something about Subject propagation?
>If not:
>- is this intentionally planned like this?
>- would it not make sense to allow Subjects to be propagated to SecurityUtil 
>1:1 from JAAS Login modules to be used as the Subject for privileged execution?
>
>Btw, I am on 7.0.68, but seems that the relevant pieces of code has not been 
>changed by 7.0.75 - most recent version checked. 
>
>Thank you for any help upfront!
>
>Regards,
>Gabor
> 
> 
>
>-
>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