Re: JMX currentThreadsBusy less than connections/requests when use APR connector
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
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
-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
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
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
-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
-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
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 liaowrote: > 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
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
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
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 ListSubject: 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
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 liaowrote: > 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
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 ListSubject: 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
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
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
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