Re: Http/2 : Tomcat NIO2 fails on large number of POST request with payload
On Thu, Mar 7, 2019 at 5:22 PM Rémy Maucherat wrote: > On Thu, Mar 7, 2019 at 2:54 PM Rémy Maucherat wrote: > >> On Thu, Mar 7, 2019 at 1:47 PM Mark Thomas wrote: >> >>> On 07/03/2019 07:40, Santhosh Kumar wrote: >>> > From some of the test cases I can safely say that tomcat is hitting >>> some >>> > limits, I have two test cases ran with two diff size of payload and >>> without >>> > any queryParams. The servlet is a empty servlet just returns after >>> > receiving without doing any business side logic >>> >>> Can you repeat those tests with the NIO connector? It would be helpful >>> to know if we should be looking at the HTTP/2 code or the low-level >>> connector I/O code. >>> >> >> I was planning to investigate since I'm hunting NIO2 additional issues >> after the fix for BZ63182. This one looks simpler to reproduce at least >> [assuming there's an issue]. >> > > Ok, so it's a buffer size issue with vectored IO and SSL, the sizes used > are too optimized. > The "fix" will be in Tomcat 9.0.17, the read buffer used simply needs to be larger with SSL. Both the JSSE and OpenSSL engines exhibit the same behavior, so no possible workaround elsewhere. Rémy
Re: Http/2 : Tomcat NIO2 fails on large number of POST request with payload
On Thu, Mar 7, 2019 at 2:54 PM Rémy Maucherat wrote: > On Thu, Mar 7, 2019 at 1:47 PM Mark Thomas wrote: > >> On 07/03/2019 07:40, Santhosh Kumar wrote: >> > From some of the test cases I can safely say that tomcat is hitting some >> > limits, I have two test cases ran with two diff size of payload and >> without >> > any queryParams. The servlet is a empty servlet just returns after >> > receiving without doing any business side logic >> >> Can you repeat those tests with the NIO connector? It would be helpful >> to know if we should be looking at the HTTP/2 code or the low-level >> connector I/O code. >> > > I was planning to investigate since I'm hunting NIO2 additional issues > after the fix for BZ63182. This one looks simpler to reproduce at least > [assuming there's an issue]. > Ok, so it's a buffer size issue with vectored IO and SSL, the sizes used are too optimized. Rémy > > Rémy > > >> >> Thanks, >> >> Mark >> >> >> > >> > h2load -n100 -c1 -m1 --header="Content-Type:application/json" -d >> > /home/local/santhosh/A-Test/nghttp2/agentRequest.txt >> > https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet >> > starting benchmark... >> > spawning thread #0: 1 total client(s). 100 total requests >> > TLS Protocol: TLSv1.3 >> > Cipher: TLS_AES_256_GCM_SHA384 >> > Server Temp Key: X25519 253 bits >> > Application protocol: h2 >> > progress: 10% done >> > progress: 20% done >> > progress: 30% done >> > progress: 40% done >> > progress: 50% done >> > >> > finished in 5.16s, 10.48 req/s, 552B/s >> > requests: 100 total, 55 started, 54 done, 54 succeeded, 46 failed, 46 >> > errored, 0 timeout >> > status codes: 55 2xx, 0 3xx, 0 4xx, 0 5xx >> > traffic: 2.78KB (2846) total, 1.77KB (1815) headers (space savings >> 43.10%), >> > 0B (0) data >> > min max mean sd+/- >> sd >> > time for request: 1.57ms 9.43ms 2.24ms 1.17ms >> 94.44% >> > time for connect: 4.69ms 4.69ms 4.69ms 0us >> 100.00% >> > time to 1st byte:0us 0us 0us 0us >> 0.00% >> > req/s : 10.48 10.48 10.480.00 >> 100.00% >> > >> > This above configuration always returns 54 succeeded, payload size is >> 1200B >> > (1200x54=64800) >> > >> -- >> > Now reduce the payload and trying the same test, >> > >> > h2load -n100 -c1 -m1 --header="Content-Type:application/json" -d >> > /home/local/santhosh/A-Test/nghttp2/agentRequest2.txt >> > https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet >> > starting benchmark... >> > spawning thread #0: 1 total client(s). 100 total requests >> > TLS Protocol: TLSv1.3 >> > Cipher: TLS_AES_256_GCM_SHA384 >> > Server Temp Key: X25519 253 bits >> > Application protocol: h2 >> > progress: 10% done >> > progress: 20% done >> > progress: 30% done >> > progress: 40% done >> > progress: 50% done >> > progress: 60% done >> > progress: 70% done >> > progress: 80% done >> > >> > finished in 5.21s, 16.11 req/s, 839B/s >> > requests: 100 total, 85 started, 84 done, 84 succeeded, 16 failed, 16 >> > errored, 0 timeout >> > status codes: 85 2xx, 0 3xx, 0 4xx, 0 5xx >> > traffic: 4.27KB (4376) total, 2.74KB (2805) headers (space savings >> 43.10%), >> > 0B (0) data >> > min max mean sd+/- >> sd >> > time for request: 1.43ms 5.80ms 2.04ms 760us >> 89.29% >> > time for connect: 5.02ms 5.02ms 5.02ms 0us >> 100.00% >> > time to 1st byte:0us 0us 0us 0us >> 0.00% >> > req/s : 16.11 16.11 16.110.00 >> 100.00% >> > >> > This above configuration always returns 84 succeeded, payload size is >> 775B >> > (775x84=65100) >> > >> -- >> > Reducing the payload much smaller, >> > >> > h2load -n200 -c1 -m1 --header="Content-Type:application/json" -d >> > /home/local/santhosh/A-Test/nghttp2/agentRequest3.txt >> > https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet >> > starting benchmark... >> > spawning thread #0: 1 total client(s). 200 total requests >> > TLS Protocol: TLSv1.3 >> > Cipher: TLS_AES_256_GCM_SHA384 >> > Server Temp Key: X25519 253 bits >> > Application protocol: h2 >> > progress: 10% done >> > progress: 20% done >> > progress: 30% done >> > progress: 40% done >> > progress: 50% done >> > progress: 60% done >> > progress: 70% done >> > progress: 80% done >> > progress: 90% done >> > >> > finished in 5.41s, 34.40 req/s, 1.73KB/s >> > requests: 200 total, 187 started, 186 done, 186 succeeded, 14 failed, 14 >> > errored, 0 timeout >> > status codes: 187 2xx, 0 3xx, 0 4xx, 0 5xx >> > traffic: 9.35KB (9578) total, 6.03KB (6171) headers (space savings >> 43.10%), >> > 0B (0) data
Re: Get startTime of coyoteRequest object from RequestFacade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Helena, On 3/7/19 03:12, Helena Carbajo wrote: > In response to John: >> Are you building Tomcat from source? If so, you could instrument >> the code in another location (I'm not exactly sure where that >> would be, so I would have to defer to someone else who is elbow >> deep in that code at the moment). > >> Thoughts? > > I have an application that uses a tomcat server. I also use Spring > Boot so I can add a HandlerInterceptorAdapterwith a preHandle > method wich is called just before the controller that handles the > request is called. I think this is too late for you, no? > In response to Christopher, > >> ... but the startTime is set to "now" at the moment when you >> think the "end time" should be set. Please re-read Mark's most >> recent comment. > >> I don't think "startTime" is going to help you, here, because it >> does not get set when the connection is established, but instead >> when a thread is assigned. > > In that case wouldn't both times, startTime and endTime, be the > same? You haven't posted your interceptor code, so I don't know when "start time" and "end time" are being set. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyBPwsACgkQHPApP6U8 pFgG4g//XvO0RdcR6D8BhxQhsVSPhlIh+xEl5Y+pjBUjbveSKTylZZvJ8Y8tzBIw lh3Ynf3pBAZxT/QIDw121mtu1Sroe7kyIYSPzZe5wDqySxkqnfzlvaOXrDDyzdbL UOi8BtV6ylT8vLxleToYILH5vxtj1b+T3BTItaDF9n2biBXQv1eMBkXIe6UDlSGV fGaq8yPEphQ6K4VIapvFr2SyCnPEfnnHSgwFW+CknZNbKwZZDBzvbGl9zJSTAUdz 90Mde5sj/1a2c0PFATYLaTgEIcSUQ7B4AYQ23OqtlWSIT/lZZe8273hH81rdW+2i ypzvFVchIdHpkUQUuAZiUUKxm19ExaXNS2RFFKwFIQcgo9ElegU83+eORSm5HPfY lSOmty56qkbwZ0d/uDIx8YO6IpWyylK4WrOlHWGHfW+EVHyVmhty0rGTjQP9cx/0 ayx1CZ3iHnPkks85jHJESSRthoBB4uf5C7KKqhL6I3nBIWUbcZHhEjRQvLVRVEfv /utO9oBQSUlqRB7y0gwhdNRVlc4fldgkPobqgCLXkcH0jLN3DeyUGsjvD6ADKAJq FWAOZiNj4eFveHQiErTkwbNybk5TF3Q3cNWDHAvBF4RNBwrID3BajuXnN3YSsjCv JkODLieRzoB8dphFPgAi4VRMsDyXxv6PZFGes2i30xvoBkf/ArY= =LlpZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat Apache 7.0.79 upgrade to Latest version
Hello Mark, Thanks for your suggestion it's work like charm. On Thu, Mar 7, 2019, 6:13 PM Mark Thomas wrote: > On 07/03/2019 11:24, Nitin Kadam wrote: > > > > > Root Causejava.lang.TypeNotPresentException: > > Type javax.persistence.PersistenceUnit not present > > > > It looks like you are missing the JPA implementation. Check for > additional JARs that were added to your Tomcat 7 lib directory that you > didn't add in Tomcat 8. > > A better solution would be to package all the JARs the app depends on in > the WAR file. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Http/2 : Tomcat NIO2 fails on large number of POST request with payload
I have executed few test cases in both NIO and NIO2 as Mark has requested for testing NIO connector. --Below is NIO h2load -n50 -c1 -m1 --header="Content-Type:application/json" -d /home/local/santhosh/A-Test/nghttp2/agentRequest.txt https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet starting benchmark... spawning thread #0: 1 total client(s). 50 total requests TLS Protocol: TLSv1.3 Cipher: TLS_AES_256_GCM_SHA384 Server Temp Key: X25519 253 bits Application protocol: h2 progress: 10% done progress: 20% done progress: 30% done progress: 40% done progress: 50% done progress: 60% done progress: 70% done progress: 80% done progress: 90% done progress: 100% done finished in 133.78ms, 373.74 req/s, 18.91KB/s requests: 50 total, 50 started, 50 done, 50 succeeded, 0 failed, 0 errored, 0 timeout status codes: 50 2xx, 0 3xx, 0 4xx, 0 5xx traffic: 2.53KB (2591) total, 1.61KB (1650) headers (space savings 43.10%), 0B (0) data min max mean sd+/- sd time for request: 1.30ms 6.49ms 2.53ms 1.37ms80.00% time for connect: 3.86ms 3.86ms 3.86ms 0us 100.00% time to 1st byte:0us 0us 0us 0us 0.00% req/s : 375.11 375.11 375.110.00 100.00% This is for 1200B of data --Below is NIO h2load -n80 -c1 -m1 --header="Content-Type:application/json" -d /home/local/santhosh/A-Test/nghttp2/agentRequest2.txt https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet starting benchmark... spawning thread #0: 1 total client(s). 80 total requests TLS Protocol: TLSv1.3 Cipher: TLS_AES_256_GCM_SHA384 Server Temp Key: X25519 253 bits Application protocol: h2 progress: 10% done progress: 20% done progress: 30% done progress: 40% done progress: 50% done progress: 60% done progress: 70% done progress: 80% done progress: 90% done progress: 100% done finished in 153.28ms, 521.93 req/s, 26.26KB/s requests: 80 total, 80 started, 80 done, 80 succeeded, 0 failed, 0 errored, 0 timeout status codes: 80 2xx, 0 3xx, 0 4xx, 0 5xx traffic: 4.02KB (4121) total, 2.58KB (2640) headers (space savings 43.10%), 0B (0) data min max mean sd+/- sd time for request: 1.12ms 5.17ms 1.83ms 657us86.25% time for connect: 4.84ms 4.84ms 4.84ms 0us 100.00% time to 1st byte:0us 0us 0us 0us 0.00% req/s : 523.06 523.06 523.060.00 100.00% This is for 775B of data --Below is NIO h2load -n180 -c1 -m1 --header="Content-Type:application/json" -d /home/local/santhosh/A-Test/nghttp2/agentRequest3.txt https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet starting benchmark... spawning thread #0: 1 total client(s). 180 total requests TLS Protocol: TLSv1.3 Cipher: TLS_AES_256_GCM_SHA384 Server Temp Key: X25519 253 bits Application protocol: h2 progress: 10% done progress: 20% done progress: 30% done progress: 40% done progress: 50% done progress: 60% done progress: 70% done progress: 80% done progress: 90% done progress: 100% done finished in 280.89ms, 640.82 req/s, 32.06KB/s requests: 180 total, 180 started, 180 done, 180 succeeded, 0 failed, 0 errored, 0 timeout status codes: 180 2xx, 0 3xx, 0 4xx, 0 5xx traffic: 9.00KB (9221) total, 5.80KB (5940) headers (space savings 43.10%), 0B (0) data min max mean sd+/- sd time for request: 1.05ms 6.15ms 1.50ms 637us91.11% time for connect: 7.24ms 7.24ms 7.24ms 0us 100.00% time to 1st byte:0us 0us 0us 0us 0.00% req/s : 641.64 641.64 641.640.00 100.00% This is for 352B of data --Below is NIO Above are the Ideal cases it works for NIO beyond which it breaks. For ex: take the case 1 and increase the request count from 50 to 60 it hangs and its applicable for all the 3 cases , tweak the request count beyond the configured 50(1200B), 80(775B) or 180(352B) the test will hang forever h2load -n60 -c1 -m1 --header="Content-Type:application/json" -d /home/local/santhosh/A-Test/nghttp2/agentRequest.txt https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet starting benchmark... spawning thread #0: 1 total client(s). 60 total requests TLS Protocol: TLSv1.3 Cipher: TLS_AES_256_GCM_SHA384 Server Temp Key: X25519 253 bits Application protocol: h2 progress: 10% done progress: 20% done progress: 30% done progress: 40% done progress: 50% done progress: 60% done progress: 70% done progress: 80% done progress: 90% done
Re: Http/2 : Tomcat NIO2 fails on large number of POST request with payload
On Thu, Mar 7, 2019 at 1:47 PM Mark Thomas wrote: > On 07/03/2019 07:40, Santhosh Kumar wrote: > > From some of the test cases I can safely say that tomcat is hitting some > > limits, I have two test cases ran with two diff size of payload and > without > > any queryParams. The servlet is a empty servlet just returns after > > receiving without doing any business side logic > > Can you repeat those tests with the NIO connector? It would be helpful > to know if we should be looking at the HTTP/2 code or the low-level > connector I/O code. > I was planning to investigate since I'm hunting NIO2 additional issues after the fix for BZ63182. This one looks simpler to reproduce at least [assuming there's an issue]. Rémy > > Thanks, > > Mark > > > > > > h2load -n100 -c1 -m1 --header="Content-Type:application/json" -d > > /home/local/santhosh/A-Test/nghttp2/agentRequest.txt > > https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet > > starting benchmark... > > spawning thread #0: 1 total client(s). 100 total requests > > TLS Protocol: TLSv1.3 > > Cipher: TLS_AES_256_GCM_SHA384 > > Server Temp Key: X25519 253 bits > > Application protocol: h2 > > progress: 10% done > > progress: 20% done > > progress: 30% done > > progress: 40% done > > progress: 50% done > > > > finished in 5.16s, 10.48 req/s, 552B/s > > requests: 100 total, 55 started, 54 done, 54 succeeded, 46 failed, 46 > > errored, 0 timeout > > status codes: 55 2xx, 0 3xx, 0 4xx, 0 5xx > > traffic: 2.78KB (2846) total, 1.77KB (1815) headers (space savings > 43.10%), > > 0B (0) data > > min max mean sd+/- > sd > > time for request: 1.57ms 9.43ms 2.24ms 1.17ms > 94.44% > > time for connect: 4.69ms 4.69ms 4.69ms 0us > 100.00% > > time to 1st byte:0us 0us 0us 0us > 0.00% > > req/s : 10.48 10.48 10.480.00 > 100.00% > > > > This above configuration always returns 54 succeeded, payload size is > 1200B > > (1200x54=64800) > > > -- > > Now reduce the payload and trying the same test, > > > > h2load -n100 -c1 -m1 --header="Content-Type:application/json" -d > > /home/local/santhosh/A-Test/nghttp2/agentRequest2.txt > > https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet > > starting benchmark... > > spawning thread #0: 1 total client(s). 100 total requests > > TLS Protocol: TLSv1.3 > > Cipher: TLS_AES_256_GCM_SHA384 > > Server Temp Key: X25519 253 bits > > Application protocol: h2 > > progress: 10% done > > progress: 20% done > > progress: 30% done > > progress: 40% done > > progress: 50% done > > progress: 60% done > > progress: 70% done > > progress: 80% done > > > > finished in 5.21s, 16.11 req/s, 839B/s > > requests: 100 total, 85 started, 84 done, 84 succeeded, 16 failed, 16 > > errored, 0 timeout > > status codes: 85 2xx, 0 3xx, 0 4xx, 0 5xx > > traffic: 4.27KB (4376) total, 2.74KB (2805) headers (space savings > 43.10%), > > 0B (0) data > > min max mean sd+/- > sd > > time for request: 1.43ms 5.80ms 2.04ms 760us > 89.29% > > time for connect: 5.02ms 5.02ms 5.02ms 0us > 100.00% > > time to 1st byte:0us 0us 0us 0us > 0.00% > > req/s : 16.11 16.11 16.110.00 > 100.00% > > > > This above configuration always returns 84 succeeded, payload size is > 775B > > (775x84=65100) > > > -- > > Reducing the payload much smaller, > > > > h2load -n200 -c1 -m1 --header="Content-Type:application/json" -d > > /home/local/santhosh/A-Test/nghttp2/agentRequest3.txt > > https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet > > starting benchmark... > > spawning thread #0: 1 total client(s). 200 total requests > > TLS Protocol: TLSv1.3 > > Cipher: TLS_AES_256_GCM_SHA384 > > Server Temp Key: X25519 253 bits > > Application protocol: h2 > > progress: 10% done > > progress: 20% done > > progress: 30% done > > progress: 40% done > > progress: 50% done > > progress: 60% done > > progress: 70% done > > progress: 80% done > > progress: 90% done > > > > finished in 5.41s, 34.40 req/s, 1.73KB/s > > requests: 200 total, 187 started, 186 done, 186 succeeded, 14 failed, 14 > > errored, 0 timeout > > status codes: 187 2xx, 0 3xx, 0 4xx, 0 5xx > > traffic: 9.35KB (9578) total, 6.03KB (6171) headers (space savings > 43.10%), > > 0B (0) data > > min max mean sd+/- > sd > > time for request: 1.18ms 13.49ms 1.91ms 1.13ms > 95.16% > > time for connect: 5.93ms 5.93ms 5.93ms 0us > 100.00% > > time to 1st byte:0us 0us 0us
Re: Http/2 : Tomcat NIO2 fails on large number of POST request with payload
On 07/03/2019 07:40, Santhosh Kumar wrote: > From some of the test cases I can safely say that tomcat is hitting some > limits, I have two test cases ran with two diff size of payload and without > any queryParams. The servlet is a empty servlet just returns after > receiving without doing any business side logic Can you repeat those tests with the NIO connector? It would be helpful to know if we should be looking at the HTTP/2 code or the low-level connector I/O code. Thanks, Mark > > h2load -n100 -c1 -m1 --header="Content-Type:application/json" -d > /home/local/santhosh/A-Test/nghttp2/agentRequest.txt > https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet > starting benchmark... > spawning thread #0: 1 total client(s). 100 total requests > TLS Protocol: TLSv1.3 > Cipher: TLS_AES_256_GCM_SHA384 > Server Temp Key: X25519 253 bits > Application protocol: h2 > progress: 10% done > progress: 20% done > progress: 30% done > progress: 40% done > progress: 50% done > > finished in 5.16s, 10.48 req/s, 552B/s > requests: 100 total, 55 started, 54 done, 54 succeeded, 46 failed, 46 > errored, 0 timeout > status codes: 55 2xx, 0 3xx, 0 4xx, 0 5xx > traffic: 2.78KB (2846) total, 1.77KB (1815) headers (space savings 43.10%), > 0B (0) data > min max mean sd+/- sd > time for request: 1.57ms 9.43ms 2.24ms 1.17ms94.44% > time for connect: 4.69ms 4.69ms 4.69ms 0us 100.00% > time to 1st byte:0us 0us 0us 0us 0.00% > req/s : 10.48 10.48 10.480.00 100.00% > > This above configuration always returns 54 succeeded, payload size is 1200B > (1200x54=64800) > -- > Now reduce the payload and trying the same test, > > h2load -n100 -c1 -m1 --header="Content-Type:application/json" -d > /home/local/santhosh/A-Test/nghttp2/agentRequest2.txt > https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet > starting benchmark... > spawning thread #0: 1 total client(s). 100 total requests > TLS Protocol: TLSv1.3 > Cipher: TLS_AES_256_GCM_SHA384 > Server Temp Key: X25519 253 bits > Application protocol: h2 > progress: 10% done > progress: 20% done > progress: 30% done > progress: 40% done > progress: 50% done > progress: 60% done > progress: 70% done > progress: 80% done > > finished in 5.21s, 16.11 req/s, 839B/s > requests: 100 total, 85 started, 84 done, 84 succeeded, 16 failed, 16 > errored, 0 timeout > status codes: 85 2xx, 0 3xx, 0 4xx, 0 5xx > traffic: 4.27KB (4376) total, 2.74KB (2805) headers (space savings 43.10%), > 0B (0) data > min max mean sd+/- sd > time for request: 1.43ms 5.80ms 2.04ms 760us89.29% > time for connect: 5.02ms 5.02ms 5.02ms 0us 100.00% > time to 1st byte:0us 0us 0us 0us 0.00% > req/s : 16.11 16.11 16.110.00 100.00% > > This above configuration always returns 84 succeeded, payload size is 775B > (775x84=65100) > -- > Reducing the payload much smaller, > > h2load -n200 -c1 -m1 --header="Content-Type:application/json" -d > /home/local/santhosh/A-Test/nghttp2/agentRequest3.txt > https://localhost:9191/HTTP_2_TEST_APP/Http2Servlet > starting benchmark... > spawning thread #0: 1 total client(s). 200 total requests > TLS Protocol: TLSv1.3 > Cipher: TLS_AES_256_GCM_SHA384 > Server Temp Key: X25519 253 bits > Application protocol: h2 > progress: 10% done > progress: 20% done > progress: 30% done > progress: 40% done > progress: 50% done > progress: 60% done > progress: 70% done > progress: 80% done > progress: 90% done > > finished in 5.41s, 34.40 req/s, 1.73KB/s > requests: 200 total, 187 started, 186 done, 186 succeeded, 14 failed, 14 > errored, 0 timeout > status codes: 187 2xx, 0 3xx, 0 4xx, 0 5xx > traffic: 9.35KB (9578) total, 6.03KB (6171) headers (space savings 43.10%), > 0B (0) data > min max mean sd+/- sd > time for request: 1.18ms 13.49ms 1.91ms 1.13ms95.16% > time for connect: 5.93ms 5.93ms 5.93ms 0us 100.00% > time to 1st byte:0us 0us 0us 0us 0.00% > req/s : 34.41 34.41 34.410.00 100.00% > > This above configuration always returns 186 succeeded, payload size is > 356 (356x186=66216) > > On Wed, Mar 6, 2019 at 9:15 PM John Dale wrote: > >> When you run your test(s), does it fail after a certain period of >> time, or just keep on going under a certain number of requests? >> >> Also, to confirm: you're sending 1000 Byte + query strings? >> >> Are you
Re: [OT] Tomcat Apache 7.0.79 upgrade to Latest version
On 07/03/2019 11:24, Nitin Kadam wrote: > Root Causejava.lang.TypeNotPresentException: > Type javax.persistence.PersistenceUnit not present It looks like you are missing the JPA implementation. Check for additional JARs that were added to your Tomcat 7 lib directory that you didn't add in Tomcat 8. A better solution would be to package all the JARs the app depends on in the WAR file. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.13 - random issue with HTTPS (blank page) - working good with HTTP
That doesn't answer any of my questions. Which connector are you using? It could be NIO and APR/Native with that configuration. The log files will include start-up messages for the connectors. They will tell you what connector is in use. Better still, paste those log messages here. If the TLS connector is running out of threads (possible under heavy load) there should be a log message to that effect when it happens. Is there? Are there any other error messages in the logs? Upgrading to latest 8.5.x? And an additional suggestions. Next time this happens take 3 thread dumps ~30s apart, upload them somewhere public and post the link here. Mark On 05/03/2019 14:41, youness.dakk...@bnpparibasfortis.com wrote: > Hello everyone, > > Here the tomcat config file from our Application BI: > > HTTPS:443 --> NOT OK sometime ( blank page/hanging) maybe limit of session > achieved and waiting new available connections > = > < > Connector port="443" > maxHttpHeaderSize="65536" > protocol="HTTP/1.1" > maxThreads="250" > SSLEnabled="true" > minSpareThreads="25" > maxSpareThreads="75" > enableLookups="false" > disableUploadTimeout="true" > acceptCount="200" debug="0" > scheme="https" > secure="true" > clientAuth="false" > sslProtocol="TLS" > sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" > keystorePass="XX" > keystoreFile="XX" > keyAlias="XXX" > ciphers="TLS_RSA_WITH_AES_128_CBC_SHA" > URIEncoding="UTF-8" > /> > > HTTP:8080 --> OK even when HTTPS hanging > > < > Connector port="8080" > maxHttpHeaderSize="65536" > protocol="HTTP/1.1" > connectionTimeout="2" > redirectPort="443" > compression="on" > URIEncoding="UTF-8" > compressionMinSize="2048" n > oCompressionUserAgents="gozilla, traviata" > compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/javascript,application/json" > /> > > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Monday, March 04, 2019 6:57 PM > To: users@tomcat.apache.org > Subject: Re: Tomcat 8.5.13 - random issue with HTTPS (blank page) - working > good with HTTP > > On 04/03/2019 17:28, youness.dakk...@bnpparibasfortis.com wrote: >> Dear, >> >> We are facing instability on our BI platform due to Tomcat. >> >> We have our https url working but sometimes, we get a blank page and stay >> like that for several time, in the meantime if we use the url without HTTPS >> as HTTP it works. >> >> The only fix we apply know is to restart the tomcat but this is not a >> solution... >> >> So, the issue is related to HTTPS, can you help us to tackle this problem >> and find the root cause ? and better logging ? > > Which connector are you using? > > Any error messages in the logs? > > Upgrade to the latest 8.5.x release and retest. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > == > BNP Paribas Fortis disclaimer: > http://www.bnpparibasfortis.com/e-mail-disclaimer.html > > BNP Paribas Fortis privacy policy: > https://www.bnpparibasfortis.com/footer-pages/privacy-policy > > == > > > - > 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: [OT] Tomcat Apache 7.0.79 upgrade to Latest version
We upgraded to tomcat 8.5.38 but facing below issue for couple of apps
We developed REST API using Jersey and deployed a WAR file of the same on
Tomcat7 (Exact Version)
It works fine.
We upgraded the Tomcat to the version 8.5.38 and redeployed the WAR file to
this version. We are getting errors while making the REST Calls to the API
In Developer Console we are getting attached error when the API is getting
hit from the Web application.
Below are the logs we get when hitting the API using postman
HTTP Status 500 – Internal
Server Errorh1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
h2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
h3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
body
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
p
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}
a {color:black;} a.name {color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 500 – Internal Server ErrorType
Exception ReportMessage Servlet.init() for servlet
[GMService] threw exceptionDescription The server encountered
an unexpected condition that prevented it from fulfilling the
request.Exceptionjavax.servlet.ServletException:
Servlet.init() for servlet [GMService] threw exception
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800)
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Unknown Source)
Root Causejava.lang.TypeNotPresentException: Type
javax.persistence.PersistenceUnit not present
sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(Unknown
Source)
sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Unknown Source)
sun.reflect.generics.tree.ClassTypeSignature.accept(Unknown
Source)
sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Unknown Source)
sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Unknown Source)
sun.reflect.generics.tree.ClassTypeSignature.accept(Unknown
Source)
sun.reflect.generics.repository.ClassRepository.getSuperInterfaces(Unknown
Source)
java.lang.Class.getGenericInterfaces(Unknown Source)
com.sun.jersey.core.spi.factory.InjectableProviderFactory.getMetaArguments(InjectableProviderFactory.java:122)
com.sun.jersey.core.spi.factory.InjectableProviderFactory.add(InjectableProviderFactory.java:85)
com.sun.jersey.core.spi.factory.InjectableProviderFactory$1.onAdd(InjectableProviderFactory.java:101)
com.sun.jersey.core.spi.factory.InjectableProviderFactory$1.onAdd(InjectableProviderFactory.java:100)
com.sun.jersey.core.spi.component.ProviderServices.getProvidersAndServices(ProviderServices.java:135)
com.sun.jersey.core.spi.factory.InjectableProviderFactory.configure(InjectableProviderFactory.java:98)
com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:501)
com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:383)
com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:377)
com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:242)
com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:449)
com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:169)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:281)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:442)
javax.servlet.GenericServlet.init(GenericServlet.java:158)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
Re: Get startTime of coyoteRequest object from RequestFacade
In response to John: >Are you building Tomcat from source? If so, you could instrument the >code in another location (I'm not exactly sure where that would be, so >I would have to defer to someone else who is elbow deep in that code >at the moment). >Thoughts? I have an application that uses a tomcat server. I also use Spring Boot so I can add a HandlerInterceptorAdapterwith a preHandle method wich is called just before the controller that handles the request is called. In response to Christopher, >... but the startTime is set to "now" at the moment when you think the >"end time" should be set. Please re-read Mark's most recent comment. >I don't think "startTime" is going to help you, here, because it does >not get set when the connection is established, but instead when a >thread is assigned. In that case wouldn't both times, startTime and endTime, be the same? In my test case I send 11 request at a time to the server, and set it up with four threads. My reasoning is that at the beginnig, since all the threads are free the waiting time is almost 0 for the four request that can be handle. Yet, the rest of reques are put in the waiting queue. When the first four threads have finished, the next four request that were at the queue can be processed but now the waiting time is more than a second. When this happen there are just 3 request still waiting in the queue, that finally can be processed, but after more than 2 seconds. Next, I send the logs I get to check this behaviour. I think if both start_time and end_time were set at the same time, they should be the same for all request and the waiting time will always be 0. 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-3] CustomInterceptor : start_time: 1551942174531 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-3] CustomInterceptor : end_time: 1551942174594 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-3] CustomInterceptor : waiting_time: 63 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-3] CustomInterceptor : Active-threads:4 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-4] CustomInterceptor : Queue: 7 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : start_time: 1551942174531 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : end_time: 1551942174594 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : waiting_time: 63 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : Active-threads:4 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : Queue: 7 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-1] CustomInterceptor : start_time: 1551942174531 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-1] CustomInterceptor : end_time: 1551942174594 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-1] CustomInterceptor : waiting_time: 63 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-1] CustomInterceptor : Active-threads:4 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-1] CustomInterceptor : Queue: 7 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-4] CustomInterceptor : start_time: 1551942174531 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-4] CustomInterceptor : end_time: 1551942174594 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-4] CustomInterceptor : waiting_time: 63 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-3] .CustomInterceptor : Queue: 7 2019-03-07 08:02:54.609 DEBUG 113980 --- [ tomcat-exec-4] .CustomInterceptor : Active-threads:4 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-3] .CustomInterceptor : start_time: 1551942174531 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-3] CustomInterceptor : end_time: 1551942175805 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-3] CustomInterceptor : waiting_time: 1274 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-3] CustomInterceptor : Active-threads:4 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-3] CustomInterceptor : Queue: 3 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : start_time: 1551942174531 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : end_time: 1551942175805 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : waiting_time: 1274 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : Active-threads:4 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-2] CustomInterceptor : Queue: 3 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-1] CustomInterceptor : start_time: 1551942174531 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-1] CustomInterceptor : end_time: 1551942175805 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-1] CustomInterceptor : waiting_time: 1274 2019-03-07 08:02:55.805 DEBUG 113980 --- [ tomcat-exec-1] CustomInterceptor : Active-threads:4
