Re: Re: Questions about the HTTP connector config
Chris, Thanks for your patience! Your explanation is quite clearly. Now I know what i'm going to do. Thanks again! jingych From: Christopher Schultz Date: 2015-07-09 03:50 To: Tomcat Users List Subject: Re: Questions about the HTTP connector config -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 jingych, On 7/8/15 4:09 AM, jingych wrote: > I desire for using tomcat as the websocket server. But I'm now > wondering about the tomcat performance. Does anyone know the max > connections that tomcat could held? the concurrent number > requests? You'll definitely want to use the NIO or NIO2 connectors. For both of those, the default maximum number of total (and thus concurrent) connections is 1. You may want to raise that if you expect lots of long-running Websocket conversations. The number of concurrent threads you think you can handle is more related to your hardware and your application than anything else. > And I don't quite understand the configurations: acceptCount & > maxConnections & maxThreads acceptCount = TCP backlog (c.f. Google) maxConnections = maximum number of connections Tomcat will maintain at once maxThreads = maximum number of threads Tomcat will use to process incoming data I wouldn't change acceptCount unless you have a very good reason. The only thing you are likely to accomplish by increasing the acceptCount is causing more connections to time out and masking any underlying problems -- like that you are trying to accept more traffic than you can reasonably service. Tomcat can handle 10k connections with many fewer threads (the default is 200) as long as those 10k connections aren't trying to all talk at once. If they are all trying to communicate at once, the 200 threads are unlikely to be able to keep up with them, and your users will experience slow performance or possibly read/write timeouts. > There must be some relationship between the three params. > > if I set [ accpetCount=200, maxConnections=1, maxThreads=100] > dose it means: 1, the max connections that tomcat maintain with the > client is 1. and if the 10001 client's connect request is > coming, the client will timeout. No, the 10001 client's request will go into the TCP backlog queue. When it comes out depends upon when one of the other 1 connections disconnects and so Tomcat will call accept() on the socket for another connection. > 2, the max request is 200, and the 201 request will be refused. There is no maximum number of requests. > 3, the max concurrent request is 100. This is pretty much correct. If your transactions are short, then 100 threads can probably comfortably service 10k connections. The best thing for you to do is work-up a realistic load test and run it against Tomcat in various configurations with your actual application doing actual work. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnX8iAAoJEBzwKT+lPKRYqSgQAMhVHWGi4QdBi6aw/5Wy826+ LTqolp9UGAbyzWKaJBaMlFS11arw8nFjy2Q9m6OWFGxKqmEXbc0qUVVrlHTf9mQd /KIb2WEfy5eUT2TbNhiuq3VM7yDYT8m9xI9KCPWsnKXr31tvYLLttyzKm9p930a6 UR1gAx8kKwrbE00KuNNklGj1OsRW8cTwGnSGnQP5Yq0fmhwJrt2bCp44FvwicILk 2JyCL3Oq4EK0hB+pB6c9WG+CYNjrXywmmHIzdI0kKzzCEu5NmHlt1zmOF7ZcPYm7 GYZcm3QtRNWK/rqMmjaSHn8YUo6pUOicabJr7fkgR9AcqxF2R9u8gkI1G1dUbTK4 Dzp1EPLDsnADvIQdOuWf+FUABT12oHHwPOMId2QMfHiM4LA9V99CNMz9R7VzsD4f T72fPy2d3jSQ+ZsWOudqAWBGC/l1S+tRI9dePJehy3wIiHSaB4SPz1MWWhYbAAQt PnjWQAhK4BOTDpsyfUE1jIkYMeTWqRQfvnTnvwAPDCo7WgUUzrh7OJMuIGSacbux vOrIACUKt1YA0QfMdQ53oUc1UrAFWefV3OyZdqC2IQ5d+xPRogMJ+GWzsDDEPI5K Kggt8D7V25vMW5PXTH/s862WmUeY+WE/ytsRGBSlBRSdz8Gri1MLYl4lyXMNZqwe CtxyYXJ7nfbGLfZIAF+7 =LEfa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---
Re: Apache HTTPD (with SSL) + mod_jk + TomEE (Tomcat) nullify the ssl session id
Alex Soto wrote: no they are always the same, I simply go to browser do https://localhost/hello/hello and I only push refresh button several times, until the id appears. Then after some pushes it disappears again and appears after some time again. So I think I am not changing the protocol from https to http. In fact the browser complains about that the certificate is homemade. So yes I think so. In first mail I sent the Docker project https://github.com/lordofthejars/apache-tomee-ssl just in case you didn't know it. Also one thing I done was to inspect the debugging file of mod_jk and I can see the session id is not sent by mod_jk. But if it is because mod_jk misses or not, I just don't know. Alex, what I think that your tests show, is that sometimes *Apache httpd* is not setting the SSL_SESSION_ID variable *as an Apache httpd environment variable*. Therefor, it is (also) not passed by mod_jk to Tomcat. That is also what Christopher was wondering, and that is why he asked you if you were really sure that all your requests were HTTPS. At this point, we also don't know why Apache httpd would in some cases not set this, but the first thing is to find out if it is so, or not. And if it is so, then why ? I believe that you can prove (or disprove) this by modifying the format of the Apache access log. You can change it so that Apache httpd logs the content of this variable for each request. Then you can again make a series of requests, and look at the Apache access log to verify what happens. Have a look here : http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats and in particular at %{FOOBAR}e The contents of the environment variable FOOBAR You can also log the request protocol : %H The request protocol In summary : if you can show that Apache httpd is always setting what it should set, and that sometimes mod_jk or Tomcat does not react to it, then the problem is with mod_jk or Tomcat. But if Apache is sometimes not setting this, then the problem is with Apache, or with something else in your setup. We are just trying to locate the issue correctly, and to avoid spending time looking in the wrong places. (For us and for you). El dc., 8 jul. 2015 a les 17:46, Christopher Schultz (< ch...@christopherschultz.net>) va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alex, On 7/8/15 10:18 AM, Alex Soto wrote: I have tried what you mention. When SSL_Id is there both request.getAttribute("javax.servlet, ."); and request.getAttribute("SSL_SESSION_ID"); returns valid sslId and in the same way if one is null them the other one is null too so it behaviour is consistent. About header approach always it is null, probably something in rewrite is not set in header. That sounds like httpd isn't providing the session id. Are you absolutely sure that all of these requests are actually HTTPS from the client? Do you ever switch between HTTPS and HTTP? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnUWVAAoJEBzwKT+lPKRYEuYQAKdxOcVmVjJI3ul57zCWys43 KOO0cQddZUnuerb3zpBKSZn8ab6KCvVCs+usULV498OAjEUOaNl2PscgNCTbT7+G YjxvXsz3TsgDvf5tIDexEFnuteb1/zxwmxl/yREjITTl4XnSx3MHPDH7n9vBiYlO 4iHFdmSF5K3CIAKweCjBYpsQdKAaVtmrfJzdpfOnop2tIlC+vAL2w5pgHOshm18Z dR3oOcSztev9Vws4iOYQlwc47Cg3M0bxyZ/KyIOd2IAUp0vpc8KTa2Hym388VnP+ UfnCUeAOfF2eKfk4c0aXJ3VNAkfIMJ44gG9oSI2lAChk8dbK4PE41sZ+ykHPwJgR gXXxXbAfrdbFuav2DtWAAoEUiGQGA4YuKqJxJMQa6LOI6sJ2+TXE/CIUkRwmijRs NkKRDGy9KW9eVsF6N7gtCsDAoL/qbu8yr01d1A6hLiofiUj3EkweNBVs2dzMmt+N WsY2Rbr9MdmYtaEcXI+uGsM5bLWatBDMxErnMCWve0QgrGiRjREns39ixuiuWpQI qbBMGhLajjDxtLpd2mMiqXvLLXVIHKem3bJ/lxACiSmYlw/5/gDayoHt9KYYbxEu adJ9wGjDRlaowokEKdGFd4GVndqoiK0NPfd2lgvSpZLuUL/qwoklTdiGr6zhkvT7 T+GAJuwkYY7GSgMplLrS =vEii -END PGP SIGNATURE- - 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: HTML 508 error with container authentication and virtual host
Here is information on how we have Apache configured. Apache is the virtual host and it redirects to the (war) app deployed in Tomcat. Note it has the app name in the ProxyPass/ProxyPassReverse URL. Regarding your question on how we deploy the app, I use Tomcat's Manager app to upload a war file. Note this same Tomcat instance has several other war apps as well. Note at first we thought this was working as it does redirect to the right app and the correct login page, the problem is when they click the Login button that's when the 408 error occurs. The 408 error does not occur if we launch the app via http://localhost:8080/myapp/. The error only occurs when users use sub1.mydomain.com which is the only URL that will have access to. What are we doing wrong? We are probably missing something simple...just don't see it. Also I'd be happy to upgrade Tomcat to a later version if that would help. ##Apache: Just a ReverseProxy to the Tomcat app: ServerName sub1.mydomain.com ServerAlias sub1.mydomain.com ## ReverseProxy's ProxyRequests Off ProxyPreserveHost Off # Have tried both on and off Order deny,allow Allow from all ProxyPass / http://localhost:8080/myapp/ ProxyPassReverse / http://localhost:8080/myapp/ On Wed, Jul 8, 2015 at 7:53 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > David, > > On 7/7/15 11:14 AM, David Hoffer wrote: > > Here is the relevant parts of the web.xml. I didn't do the Apache > > configuration so I'll have to get more details there but I was told > > that is no different than how we configure virtual hosts for other > > apps that don't use Tomcat's authentication. E.g. it seems Tomcat > > is requiring to have the app's name in the URL...not a subdomain. > > Well, /of course/ Tomcat requires the app's name in the URL. That's > how Tomcat figures out which application should take the request. > > Where is your application deployed? What WAR file (or exploded-WAR > directory)? Any other details that might help explain what's going on? > > As André said, none of us has a crystal ball (well... one of us does, > but he's been MIA for quite a long time). > > FORM authentication works in Tomcat, whether through an httpd-based > proxy or not. Most of us use it /all the time/. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJVnStSAAoJEBzwKT+lPKRYrjUP/2DO0eK+Ee1r2SqqVBRZjvtK > KsDWGY1lq/n2OELZYCRYCoiVCSwYJZ5qbe9x34GFSSLR9Ictrpo5zS4f3UhxdK5N > INeWzvQy6WlDcu962bGopNqLedrpFJBGPbrbY3mP13bm2KByjbbrD7z8LqQrnlUM > GyHLPpgWfwbaPdG+2sVG4Xi0oa/uqCGGW7XkcUCq+0IXCDKnxHmwgxERrb1T4b3y > Yq0uG644pZ3ZhDQaWhtC9ENXz6+Nw0WW82k6OfyyR7bs7m/axqfDa8G45s33hJXV > KK0GPR2Ke19xvILJ9xM6K4Bvss4y61O7TGhrfpUujniKDrmArDoJ7gALHDyCpguE > CJ2P743d4KL2bDt3Kpvc3Pct615dtIECn7+0fiJP/wZP9r7PhV0jm0srxmVF/29W > rgfJhNEMGsAmHKHjY7f7LIbJPO9t2sY7khwR5TmL8rjvD1ryAadkrxTTNngeV8/L > +h063CkbVX4+jQ9S5/QLdcD/CtL8iYE/p29FS60o+b5JwiBeOGjxnuJl0ahu9EIa > 4Q3tuMn8jtFc8mxvvSIL2I2ErRx+4mQECJwZsCnMPmD+k+dgSuGndt7avG8Jrfk/ > XqS36lNth9O916Xkgp9bKPpxOD5o5EXfXLFInr+nuew7V3Tbm0zjfsDiLx4YuQgM > NkOj5Rfv9gikgn9nq3Au > =7b2b > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat 8 AprEndpoint Poller thread consuming high CPU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rich, On 6/30/15 2:06 PM, Rich Mayfield wrote: > Moved from Tomcat 7.0.55 to Tomcat 8.0.23 and now see the AJP > Poller thread churning through a lot of CPU in a pretty much quiet > system. > > This seems like a bug. > > * Restarting does not resolve the issue * I've seen some mention of > bumping up the memory. Doubling the max heap (-Xmx from 506m to > 1012m) does not help. This is a relatively small service that is > essentially idle - or at least it would be with the exception of > this Poller thread. > > The connector configuration is unchanged. > > scheme="https" connectionTimeout="2" packetSize="2" > maxThreads="1024" URIEncoding="UTF-8" redirectPort="443" > useSendfile="false" compression="force" > compressableMimeTypes="text/html,text/xml,text/plain,text/javascript,t ext/css,application/json,application/xml" > > /> > > The thread consuming all the CPU > > "ajp-apr-28080-Poller" #62 daemon prio=5 os_prio=0 > tid=0x2ba40293e000 nid=0x407d waiting on condition > [0x2ba3fc20] java.lang.Thread.State: WAITING (parking) at > sun.misc.Unsafe.park(Native Method) - parking to wait for > <0xeaf94570> (a > java.util.concurrent.locks.ReentrantLock$NonfairSync) at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInte rrupt(AbstractQueuedSynchronizer.java:836) > > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Abst ractQueuedSynchronizer.java:870) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstract QueuedSynchronizer.java:1199) > > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock. java:209) > at > java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > > at java.util.concurrent.LinkedBlockingQueue.signalNotEmpty(LinkedBlockingQu eue.java:172) > at > java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.jav a:430) > > at org.apache.tomcat.util.threads.TaskQueue.offer(TaskQueue.java:74) > at > org.apache.tomcat.util.threads.TaskQueue.offer(TaskQueue.java:31) > at > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.jav a:1361) > > at org.apache.tomcat.util.threads.ThreadPoolExecutor.execute(ThreadPoolExec utor.java:161) > at > org.apache.tomcat.util.threads.ThreadPoolExecutor.execute(ThreadPoolEx ecutor.java:141) > > at org.apache.tomcat.util.net.AprEndpoint.processSocket(AprEndpoint.java:89 6) > at > org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:188 3) > > at java.lang.Thread.run(Thread.java:745) > > > # rpm -qa | grep apr apr-1.5.1-1 apr-util-1.5.3-1 > > # rpm -qa | grep http httpd-2.2.27-1 > > Server version: Apache Tomcat/8.0.23 Server built: May 19 2015 > 14:58:38 UTC Server number: 8.0.23.0 OS Name:Linux OS > Version: 2.6.18-371.el5 Architecture: amd64 JVM Version: > 1.8.0_40-b25 JVM Vendor: Oracle Corporation Do you have more than one "Poller" thread for the APR connector? That thread is currently blocked on a monitor. Are you saying that it looks like it wakes up all the time and then goes back to sleep? The poller thread is responsible for routing I/O requests between the sockets and the request processors. Basically, it figures out which thread's data is available and then hands it off. So, the poller thread is often busy, but it doesn't do a great deal of actual work itself. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnYIKAAoJEBzwKT+lPKRYg0kP/1dlwElcKwLCVwHzZ6S8gG/n hIX3Xj0Z0K4+odIVSpjHYGfCObNOtZFmUohXxCqRhrtvOf6VIkmy3FYmR+Uth4Et iMdAI+w1g4XhkkdPo8vThJngHrK4wzXlJSWmoMX9Tq7fGKBu0nWkT6c9PgNFWK3E glTUIOoQqKt6qJnMZU8Z3wCLjQFcPoLB7/VfAugK/BfA6YpZ6UuUx3hNT0qQ2LoV T0QX0qESJjvmhkUgKUUS4VyRd7J8NfXsbk5w/NFX1AgCfOpEOduhsd0K2SxZI5/Z sydBduMXdubSN59ckcRFFeOjxCwQ1r07nYl3KH2H2SwiK02V8dCXyObW/ZIDPbyN HAnfE9K9wTzZUeJpyDYew8BRcPKgZS6WXYgcovHAZZtMCyTJTDMjmMQai0rlh+M5 ++MhLqUmsvUL4JhdhMzfb/CFbKBDBRPM0oVSWIfAh/eALIj7Og1iM0wl7oPrOHHL n+ww9+fix7Ik1hRD1DBjlk2eB6NQUQ2p6UZIa9fGgYp9rTHpkDaayFOzEc0iheoS twwlP3a+GJ2TfCsjR1KPfsNIuCpXRiYVDpxm1PJY5/9UssiqiNRS/8yVVZX9E7fU TAlgNMBZu81eswGWB6bhlmifFtOhMTmqwm/AViqUkMB4IcVoLDtWwKyXU3eSzdmu MmsSGJ2O1r2aQhO1Er9Y =s0s6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: application frequently down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yon, On 7/3/15 2:04 AM, Yon, wrote: > > className="org.apache.catalina.core.AprLifecycleListener" > SSLEngine="on" /> This is not enough to use APR. > connectionTimeout="2" redirectPort="8443" /> > > [...] > > Neither of these elements specifies the protocol, so Tomcat will auto-choose between the APR connection and one of the Java connectors (I can't tell you which, because you didn't say which version of Tomcat you are using). Tomcat can only use the APR connector if the tcnative library is available. If you have no idea what's in use, the easiest thing to do is take a thread dump[1] of the running JVM process and look at the thread names for the request processors. - -chris [1] http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_ running_webapp_.3F -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnYDwAAoJEBzwKT+lPKRYPdgQAJT020JmurXDqkqM9G6bjpZF zpTQLwoYPBn3Dc7aDd+2WHuxC9BKf0AV3/el3no8DdN9IOUYfeUJKbEbCMfa39p5 nM0POZ+f697wA8J8ifQVgaT4/1JvWY+MOpBBI0yHcyf9NzOFLxDh7rCVioBHwH6c 4xT2gUeXY5q+DOFJL6ZuL6Md6Ir2fHghP5EcHCJTB/Ag5cwxCZpKGLoya9AcoMb0 7hzQM45IYUfZHI6gx4cmpvKHu0GyL5o3sM1EujiCtYAzIHweHLuq9T9DJHYnA/D3 osaOa2aIqR4w8Vkw7u8rf9adgqKfHShbsytGoUpXrvCKuySUgt9bFEvOm9Zp3xSz bsfmETPZb2cDVDttEWiuZWi9KXxNhSU5sZATsWeFgT7hA7r2kuthQKqNi5oBH2NT quM56ttScl75xEMSF0J+3tTuzUbn+yzz2cHg+qB4+G4wPqhHYXpV1Ln5rqZxrOE7 SJlu1pHYT3VOb/1UYxVjNj0L9MbidcoFgJgMOhMIv8xSMPOoeYSYatvGYewVsD4N dprUazghGlwSnRNjKAM9Lt1ND/7COfMzT4GHdncRbpyZU2nxOCd3Uua7YciYs+JD Fpz0T2srZHqXvzavaZW/yU2YxU9IN1PcLLLd3rXe4s5EsjDqx8HQQacd5oSMTqg+ +1matwYjhtaUPzGia75z =P8Hl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Questions about the HTTP connector config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 jingych, On 7/8/15 4:09 AM, jingych wrote: > I desire for using tomcat as the websocket server. But I'm now > wondering about the tomcat performance. Does anyone know the max > connections that tomcat could held? the concurrent number > requests? You'll definitely want to use the NIO or NIO2 connectors. For both of those, the default maximum number of total (and thus concurrent) connections is 1. You may want to raise that if you expect lots of long-running Websocket conversations. The number of concurrent threads you think you can handle is more related to your hardware and your application than anything else. > And I don't quite understand the configurations: acceptCount & > maxConnections & maxThreads acceptCount = TCP backlog (c.f. Google) maxConnections = maximum number of connections Tomcat will maintain at once maxThreads = maximum number of threads Tomcat will use to process incoming data I wouldn't change acceptCount unless you have a very good reason. The only thing you are likely to accomplish by increasing the acceptCount is causing more connections to time out and masking any underlying problems -- like that you are trying to accept more traffic than you can reasonably service. Tomcat can handle 10k connections with many fewer threads (the default is 200) as long as those 10k connections aren't trying to all talk at once. If they are all trying to communicate at once, the 200 threads are unlikely to be able to keep up with them, and your users will experience slow performance or possibly read/write timeouts. > There must be some relationship between the three params. > > if I set [ accpetCount=200, maxConnections=1, maxThreads=100] > dose it means: 1, the max connections that tomcat maintain with the > client is 1. and if the 10001 client's connect request is > coming, the client will timeout. No, the 10001 client's request will go into the TCP backlog queue. When it comes out depends upon when one of the other 1 connections disconnects and so Tomcat will call accept() on the socket for another connection. > 2, the max request is 200, and the 201 request will be refused. There is no maximum number of requests. > 3, the max concurrent request is 100. This is pretty much correct. If your transactions are short, then 100 threads can probably comfortably service 10k connections. The best thing for you to do is work-up a realistic load test and run it against Tomcat in various configurations with your actual application doing actual work. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnX8iAAoJEBzwKT+lPKRYqSgQAMhVHWGi4QdBi6aw/5Wy826+ LTqolp9UGAbyzWKaJBaMlFS11arw8nFjy2Q9m6OWFGxKqmEXbc0qUVVrlHTf9mQd /KIb2WEfy5eUT2TbNhiuq3VM7yDYT8m9xI9KCPWsnKXr31tvYLLttyzKm9p930a6 UR1gAx8kKwrbE00KuNNklGj1OsRW8cTwGnSGnQP5Yq0fmhwJrt2bCp44FvwicILk 2JyCL3Oq4EK0hB+pB6c9WG+CYNjrXywmmHIzdI0kKzzCEu5NmHlt1zmOF7ZcPYm7 GYZcm3QtRNWK/rqMmjaSHn8YUo6pUOicabJr7fkgR9AcqxF2R9u8gkI1G1dUbTK4 Dzp1EPLDsnADvIQdOuWf+FUABT12oHHwPOMId2QMfHiM4LA9V99CNMz9R7VzsD4f T72fPy2d3jSQ+ZsWOudqAWBGC/l1S+tRI9dePJehy3wIiHSaB4SPz1MWWhYbAAQt PnjWQAhK4BOTDpsyfUE1jIkYMeTWqRQfvnTnvwAPDCo7WgUUzrh7OJMuIGSacbux vOrIACUKt1YA0QfMdQ53oUc1UrAFWefV3OyZdqC2IQ5d+xPRogMJ+GWzsDDEPI5K Kggt8D7V25vMW5PXTH/s862WmUeY+WE/ytsRGBSlBRSdz8Gri1MLYl4lyXMNZqwe CtxyYXJ7nfbGLfZIAF+7 =LEfa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AIX OS Patch Breaks Apache/Tomcat
>>Hello. >> >>I am running Apache 2.2.29 and Tomcat 7.0.59 with tomcat connector(mod_jk) >>version 1.2.40 on AIX version 7.1 server. Started having problems this >>morning after AIX OS was patched to AIX 7.1 TL 03 SP 04 and openssh to 6.0.0.6108. WebAdvisor runs fine immediately after apache is started or >>restarted. However its response slowing down. AIX server CPU steadily >>increases and approaches 100% after running for 5 or 10 minutes under heavy load.. Seeing http process accumulate. Not seeing much traffic at all in >>Tomcat server status. Recompiled apache, tomcat connector, and Tomcat >>native. Still no luck. Later determined there is a bug with openssh 6.0.0.6.108 >and tried 6.0.0.6109. Recompiled again. Still no >>improvement. Just booted from Clone backup taken before the AIX patch and >>everything runs fine, no problems. Anyone else have this experience with >>AIX >>patches/updates? Not really much to see in error logs. Tomcat is >>configured to run with java6 32 bit: >> >>IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc-32 >>jvmap3260sr16-20141216_227499 (JIT enabled, AOT enabled) >>J9VM - 20141216_227499 >>JIT - r9_20140523_64469ifx3 >>GC - GA24_Java6_SR16_20141216_1020_B227499) >>JCL - 20141216_01 >> >> >>Thank you. >>David > >Just an update on this problem. Now this appears to be an issue meant for the >Apache list, which I just sent this to. > >We have determined that that this problem is triggered by Apache >server-status. I have always used server-status to monitor our production >system, no problem. I rarely use server-status to monitor our test system >because >there is nothing to see there due to extremely light traffic. But >after the AIX patch, server-status gradually causes the sever CPU to be maxed >out. This problem was just duplicated on our test server. The CPU drops back >to >normal for that server when server-status is stopped. Example of >server-status URL I use in my IE 11 browser: >https://website.com/server-status?refresh=5 > >Has anyone else had this experience? I guess for now, I will just have to >stop using server-status to monitor Apache so that we can patch our AIX system. RESOLVED: Solved this problem by downloading and compiling the latest openssl, currently 1.0.2c, from openssl.org. Recompiled Apache with openssl 1.0.2c. Recompiled Tomcat Connector and Tomcat Native too just to make sure all bases are covered. I'm guessing that the problem was caused by the AIX 7.1 TL 03 SP 04 update patching the server openssl. This triggered the Apache server-status/mod_status high CPU usage issue when used to monitor our https site. David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Content length, timeouts
Hello, we have a GWT 2.7 application that's deployed on tomcat7 (r57-63) that uses RestyGwt to make REST calls to another server (which uses RestEasy 3.11). We're seeing several issues that seem to be clustered into two categories (transferring binary data, exceptions with xml data) - with one overriding theme (content length isn't correct - this is the application server exception we see, and fiddler shows the same thing). I'm trying to sort out all the pieces and was hoping I could get some pointers in the right direction. Locally when running super dev mode in IntelliJ, we cannot reproduce many of the issues (the remaining ones seem to involve very low level debugging of Response objects, etc). With the binary data, it seems to revolve around compression/gzipping, png's, and file sizes somehow. But let me give you the more straightforward example/category... - the GWT app on any current Windows7 browser makes a REST call to get some xml data SerializableClass getData() - partway through the generating of the data, the server throws an exception - somewhere around 10-20 seconds later... (tomcat / the request times out? and)... the client gets a failure result on the asynchronous call We have a simple proxy that passes the call from the app server to the secondary server so this may involve some issue there (and so I will try to eliminate that part from the equation) - but the strange thing is that in DEV mode, all parts are still in use but when the exception happens, the client/browser gets notified immediately of the failure (this would be using the jetty embedded server for GWT super dev mode instead of being deployed on tomcat). It seems that *someone* is setting the response header to expect 8000 bytes, but the server only generates 300 (maybe the length of the exception message?) - and tomcat [or something related] (but not jetty) waits for the rest to show up before failing. Is there good info out there on content length handling in general, and how that might vary by container, such as tomcat specifically? Thank you.
Re: Apache HTTPD (with SSL) + mod_jk + TomEE (Tomcat) nullify the ssl session id
no they are always the same, I simply go to browser do https://localhost/hello/hello and I only push refresh button several times, until the id appears. Then after some pushes it disappears again and appears after some time again. So I think I am not changing the protocol from https to http. In fact the browser complains about that the certificate is homemade. So yes I think so. In first mail I sent the Docker project https://github.com/lordofthejars/apache-tomee-ssl just in case you didn't know it. Also one thing I done was to inspect the debugging file of mod_jk and I can see the session id is not sent by mod_jk. But if it is because mod_jk misses or not, I just don't know. Alex. El dc., 8 jul. 2015 a les 17:46, Christopher Schultz (< ch...@christopherschultz.net>) va escriure: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Alex, > > On 7/8/15 10:18 AM, Alex Soto wrote: > > I have tried what you mention. When SSL_Id is there both > > request.getAttribute("javax.servlet, ."); and > > request.getAttribute("SSL_SESSION_ID"); returns valid sslId and in > > the same way if one is null them the other one is null too so it > > behaviour is consistent. About header approach always it is null, > > probably something in rewrite is not set in header. > > That sounds like httpd isn't providing the session id. > > Are you absolutely sure that all of these requests are actually HTTPS > from the client? Do you ever switch between HTTPS and HTTP? > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJVnUWVAAoJEBzwKT+lPKRYEuYQAKdxOcVmVjJI3ul57zCWys43 > KOO0cQddZUnuerb3zpBKSZn8ab6KCvVCs+usULV498OAjEUOaNl2PscgNCTbT7+G > YjxvXsz3TsgDvf5tIDexEFnuteb1/zxwmxl/yREjITTl4XnSx3MHPDH7n9vBiYlO > 4iHFdmSF5K3CIAKweCjBYpsQdKAaVtmrfJzdpfOnop2tIlC+vAL2w5pgHOshm18Z > dR3oOcSztev9Vws4iOYQlwc47Cg3M0bxyZ/KyIOd2IAUp0vpc8KTa2Hym388VnP+ > UfnCUeAOfF2eKfk4c0aXJ3VNAkfIMJ44gG9oSI2lAChk8dbK4PE41sZ+ykHPwJgR > gXXxXbAfrdbFuav2DtWAAoEUiGQGA4YuKqJxJMQa6LOI6sJ2+TXE/CIUkRwmijRs > NkKRDGy9KW9eVsF6N7gtCsDAoL/qbu8yr01d1A6hLiofiUj3EkweNBVs2dzMmt+N > WsY2Rbr9MdmYtaEcXI+uGsM5bLWatBDMxErnMCWve0QgrGiRjREns39ixuiuWpQI > qbBMGhLajjDxtLpd2mMiqXvLLXVIHKem3bJ/lxACiSmYlw/5/gDayoHt9KYYbxEu > adJ9wGjDRlaowokEKdGFd4GVndqoiK0NPfd2lgvSpZLuUL/qwoklTdiGr6zhkvT7 > T+GAJuwkYY7GSgMplLrS > =vEii > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Apache HTTPD (with SSL) + mod_jk + TomEE (Tomcat) nullify the ssl session id
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alex, On 7/8/15 10:18 AM, Alex Soto wrote: > I have tried what you mention. When SSL_Id is there both > request.getAttribute("javax.servlet, ."); and > request.getAttribute("SSL_SESSION_ID"); returns valid sslId and in > the same way if one is null them the other one is null too so it > behaviour is consistent. About header approach always it is null, > probably something in rewrite is not set in header. That sounds like httpd isn't providing the session id. Are you absolutely sure that all of these requests are actually HTTPS from the client? Do you ever switch between HTTPS and HTTP? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnUWVAAoJEBzwKT+lPKRYEuYQAKdxOcVmVjJI3ul57zCWys43 KOO0cQddZUnuerb3zpBKSZn8ab6KCvVCs+usULV498OAjEUOaNl2PscgNCTbT7+G YjxvXsz3TsgDvf5tIDexEFnuteb1/zxwmxl/yREjITTl4XnSx3MHPDH7n9vBiYlO 4iHFdmSF5K3CIAKweCjBYpsQdKAaVtmrfJzdpfOnop2tIlC+vAL2w5pgHOshm18Z dR3oOcSztev9Vws4iOYQlwc47Cg3M0bxyZ/KyIOd2IAUp0vpc8KTa2Hym388VnP+ UfnCUeAOfF2eKfk4c0aXJ3VNAkfIMJ44gG9oSI2lAChk8dbK4PE41sZ+ykHPwJgR gXXxXbAfrdbFuav2DtWAAoEUiGQGA4YuKqJxJMQa6LOI6sJ2+TXE/CIUkRwmijRs NkKRDGy9KW9eVsF6N7gtCsDAoL/qbu8yr01d1A6hLiofiUj3EkweNBVs2dzMmt+N WsY2Rbr9MdmYtaEcXI+uGsM5bLWatBDMxErnMCWve0QgrGiRjREns39ixuiuWpQI qbBMGhLajjDxtLpd2mMiqXvLLXVIHKem3bJ/lxACiSmYlw/5/gDayoHt9KYYbxEu adJ9wGjDRlaowokEKdGFd4GVndqoiK0NPfd2lgvSpZLuUL/qwoklTdiGr6zhkvT7 T+GAJuwkYY7GSgMplLrS =vEii -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 7/7/15 9:39 AM, Mark Thomas wrote: On 30/06/2015 21:16, Mark Thomas wrote: This is probably off-topic now so marking as such. On 29/06/2015 14:29, André Warnier wrote: Mark Thomas wrote: On 26/06/2015 19:37, Mark Thomas wrote: On 22/06/2015 11:56, Mark Thomas wrote: On 22/06/2015 09:39, Mark Thomas wrote: Prompting for authentication in response to an untrusted certificate is bizarre to say the least. Progress, if you can call it that, has not been good. They have now asked for additional network traces since: ... to be able to understand what packets are sent by client and what response did Server generate for the specific packet, I would like to check a simultaneous trace on both communication endpoints I have just sent a very long, fairly stropy reply pointing out the complete pointlessness of this request - not least because the information they claim they don't have is right in front of them in the form of the sequence and acknowledgement numbers in the network trace. This continues to drag on. The stropy e-mail got the issue re-assigned to someone with marginally more clue. They put together a test environment (with IIS instead of Tomcat) and then attempted to demonstrate that the issue did not occur and hence it must be a Tomcat problem. "Our non-standard client works perfectly well with our non-standard server. The fact that our non-standard client doesn't work with your standards-compliant server obviously points to your software as the problem." Nice tautology you got there. It would be a shame if something were to happen to it. *sigh* Well, if you're willing to continue to tilt at this particular windmill, it would be a great service to the world. I'm not hopeful, though, as WebDAV support in Microsoft Windows has degraded consistently over the past 10 years and never improved. I don't know why they even bother to /claim/ support for it anymore. Evidently, nobody in the Microsoft world gives a rats posterior about WebDAV... they all use SMB anyway. However, once they had configured their environment to match my original bug report (server using cert issued by CA client doesn't trust, server configured not to require authentication) imagine my lack of surprise when the problem was repeated with IIS. Needless to say the other end of the conference call went very, very quiet at that point. The issue has now been passed to yet another support employee (I refuse to call these people engineers) who apparently wants to discuss the issue further. What they can possibly need to discuss at this point I have no idea but having told them (again) how to contact me I am waiting to hear from them. I also discovered that - despite the conference call - the latest support ticket update from Microsoft claimed the issue could not be repeated with IIS. It appears that the issue has been passed to the IIS team which makes no sense at all since all the evidence points to this being a WebDAV client bug and I have been making that point since this whole sorry episode started. The good news is that the IIS team is likely to refuse to accept responsibility for the bug (because, by definition, IIS contains zero bugs) and likely to pass the buck back to the WebDAV client team. If you catch them at just the right time, you may be able to show MS how to do their own jobs. While I continue to appreciate the free MSDN license Microsoft kindly provide to Apache committers, I must confess to being completely unimpressed by Microsoft's support structures and count myself fortunate that I don't have to run an IT infrastructure that relies on them. +1 With respect, you both don't get it. MS support is deliberately pitiful, to emphasize the fact that MS software is by definition bug-free and does not really need support. And to really bring the point home, MS seems to have plans to not name the next version "Windows" anymore, but invent some other name. Now /that/ should allow them to definitely start with a clean slate in their support database. There might be an idea for Tomcat there.. "Bulldog" ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache HTTPD (with SSL) + mod_jk + TomEE (Tomcat) nullify the ssl session id
I have tried what you mention. When SSL_Id is there both request.getAttribute("javax.servlet, ."); and request.getAttribute("SSL_SESSION_ID"); returns valid sslId and in the same way if one is null them the other one is null too so it behaviour is consistent. About header approach always it is null, probably something in rewrite is not set in header. Well everything is consistent, the question is if this consistency is ok or not. Alex. El dc., 8 jul. 2015 a les 14:27, André Warnier () va escriure: > Alex Soto wrote: > > Hi I have tried this approach custom JkEnvVar are pass correctly, what I > > don't know how to do is how to set an already JkEnvVar to a new JkEnvVar > > (what you mention about "force)) I have tried with %{SSL_SESSION_ID} and > $ > > but no luck (Don't know if it is because originally it was null or not). > > I think it is just > > JkEnvVar SSL_SESSION_ID "none" > > (where "none" is the default value, used if the Apache "environment > variable" > SSL_SESSION_ID was not set before you pass the request to Tomcat.) > (The default value insures that Tomcat always gets something, no matter > what) > > Then in Tomcat you do request.getAttribute("SSL_SESSION_ID") , and if you > find the value > "none", it means that SSL_SESSION_ID was not set at the httpd level. > > Note: if that does not work, there is still another method that can be > tried : setting a > HTTP request header, before proxying to Tomcat. It would work like this : > > RewriteEngine On > RewriteRule .* - [E=MY_SESSION_ID:%{SSL_SESSION_ID},NE] > RequestHeader set JK-SSL-SESSION "%{MY_SESSION_ID}e" > > and then in Tomcat you would retrieve the HTTP header "JK-SSL-SESSION". > > > > > > > Alex. > > > > El dt., 7 jul. 2015 a les 23:05, André Warnier () va > > escriure: > > > >> Alex Soto wrote: > >>> yes it is set at httpd-ssl.config > >>> > >> > https://github.com/lordofthejars/apache-tomee-ssl/blob/master/httpd-ssl.conf#L229 > >>> which I think that is where it should be set. > >>> Everything too strange, but thanks anyway. > >> Then, and until Rainer himself jumps in, let me ask you if it would be > >> possible to make > >> one more test. As far as I understand, this is not the way it /should/ > >> work, but it may be > >> a way to find out what doesn't work, inasmuch as there is really a > problem > >> : > >> > >> Somewhere in that same page, there is a way by which you can "force" a > >> value to be passed > >> on to Tomcat as a request attribute (via JkEnvVar "name" > "default-value").. > >> Can you try to pass the SSL session-id in that way, and obtain it in > >> Tomcat via > >> request.getAttribute("name"), instead of the standard > request.ssl_session ? > >> And check if /then/, you get it all the time ? > >> > >> Again, this is probably not the way in which this should work. But > Tomcat > >> is open-source > >> and free software, and its development and debugging benefit from the > help > >> of any > >> benevolent user, particularly if that user is interested in solving a > >> particular problem > >> that he is having. > >> > >>> El dt., 7 jul. 2015 a les 19:17, André Warnier () va > >>> escriure: > >>> > Alex Soto wrote: > > Thank you so much but it is already set. > > > >> > https://github.com/lordofthejars/apache-tomee-ssl/blob/master/httpd.conf#L171 > > This is so strange. > But there is also this phrase : "In order to make SSL data available > for > mod_jk in Apache, > you need to set SSLOptions +StdEnvVars." > > Honestly, I have never tried this, and I am not an SSL specialist at > >> all, > and the phrase > above is a bit ambiguous. But it seems worth a try, and I do not see > it > in your > configuration. > > > El dt., 7 jul. 2015 a les 12:25, André Warnier () va > > escriure: > > > >> Mark Thomas wrote: > >>> On 07/07/2015 09:28, Alex Soto wrote: > Hi Mark, SSL Session ID is not passed to Tomcat. You can see the > >> logs > >> here > https://gist.github.com/lordofthejars/226d8ed605f2a58b52f3 (I > have > >> created > a gist to not add here a lot of lines). > > Now the question is is it happens because of mod_jk or because of > >> Apache? > Alex. > >>> OK. You've reached the limits of my conform zone. You need someone > >> more > >>> familiar with the httpd side of things at this point. Rainer? > >>> > >>> Mark > >> Not Rainer, but maybe this helps : > >> http://tomcat.apache.org/connectors-doc/reference/apache.html > >> Look for "JkExtractSSL". > >> > >> > El dl., 6 jul. 2015 a les 12:48, Mark Thomas () > >> va > escriure: > > > On 06/07/2015 10:48, Alex Soto wrote: > >> Hello I have seen a strange behaviour in Apache HTTPD (2.4) and > TomEE > > (in > >> fact it is a Tomcat (7.0.61) so it is exactly the same for > Tomcat) > >> when I > >> configure
Re: HTML 508 error with container authentication and virtual host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 7/7/15 11:14 AM, David Hoffer wrote: > Here is the relevant parts of the web.xml. I didn't do the Apache > configuration so I'll have to get more details there but I was told > that is no different than how we configure virtual hosts for other > apps that don't use Tomcat's authentication. E.g. it seems Tomcat > is requiring to have the app's name in the URL...not a subdomain. Well, /of course/ Tomcat requires the app's name in the URL. That's how Tomcat figures out which application should take the request. Where is your application deployed? What WAR file (or exploded-WAR directory)? Any other details that might help explain what's going on? As André said, none of us has a crystal ball (well... one of us does, but he's been MIA for quite a long time). FORM authentication works in Tomcat, whether through an httpd-based proxy or not. Most of us use it /all the time/. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnStSAAoJEBzwKT+lPKRYrjUP/2DO0eK+Ee1r2SqqVBRZjvtK KsDWGY1lq/n2OELZYCRYCoiVCSwYJZ5qbe9x34GFSSLR9Ictrpo5zS4f3UhxdK5N INeWzvQy6WlDcu962bGopNqLedrpFJBGPbrbY3mP13bm2KByjbbrD7z8LqQrnlUM GyHLPpgWfwbaPdG+2sVG4Xi0oa/uqCGGW7XkcUCq+0IXCDKnxHmwgxERrb1T4b3y Yq0uG644pZ3ZhDQaWhtC9ENXz6+Nw0WW82k6OfyyR7bs7m/axqfDa8G45s33hJXV KK0GPR2Ke19xvILJ9xM6K4Bvss4y61O7TGhrfpUujniKDrmArDoJ7gALHDyCpguE CJ2P743d4KL2bDt3Kpvc3Pct615dtIECn7+0fiJP/wZP9r7PhV0jm0srxmVF/29W rgfJhNEMGsAmHKHjY7f7LIbJPO9t2sY7khwR5TmL8rjvD1ryAadkrxTTNngeV8/L +h063CkbVX4+jQ9S5/QLdcD/CtL8iYE/p29FS60o+b5JwiBeOGjxnuJl0ahu9EIa 4Q3tuMn8jtFc8mxvvSIL2I2ErRx+4mQECJwZsCnMPmD+k+dgSuGndt7avG8Jrfk/ XqS36lNth9O916Xkgp9bKPpxOD5o5EXfXLFInr+nuew7V3Tbm0zjfsDiLx4YuQgM NkOj5Rfv9gikgn9nq3Au =7b2b -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 7/7/15 9:39 AM, Mark Thomas wrote: > On 30/06/2015 21:16, Mark Thomas wrote: >> This is probably off-topic now so marking as such. >> >> On 29/06/2015 14:29, André Warnier wrote: >>> Mark Thomas wrote: On 26/06/2015 19:37, Mark Thomas wrote: > On 22/06/2015 11:56, Mark Thomas wrote: >> On 22/06/2015 09:39, Mark Thomas wrote: > > >> Prompting for authentication in response to an untrusted >> certificate is bizarre to say the least. > > > >> Progress, if you can call it that, has not been good. They have >> now asked for additional network traces since: >> >> ... to be able to understand what packets are sent by >> client and what response did Server generate for the specific >> packet, I would like to check a simultaneous trace on both >> communication endpoints >> >> I have just sent a very long, fairly stropy reply pointing out >> the complete pointlessness of this request - not least because >> the information they claim they don't have is right in front of >> them in the form of the sequence and acknowledgement numbers in >> the network trace. > > This continues to drag on. The stropy e-mail got the issue > re-assigned to someone with marginally more clue. They put together > a test environment (with IIS instead of Tomcat) and then attempted > to demonstrate that the issue did not occur and hence it must be a > Tomcat problem. "Our non-standard client works perfectly well with our non-standard server. The fact that our non-standard client doesn't work with your standards-compliant server obviously points to your software as the problem." Nice tautology you got there. It would be a shame if something were to happen to it. *sigh* Well, if you're willing to continue to tilt at this particular windmill, it would be a great service to the world. I'm not hopeful, though, as WebDAV support in Microsoft Windows has degraded consistently over the past 10 years and never improved. I don't know why they even bother to /claim/ support for it anymore. Evidently, nobody in the Microsoft world gives a rats posterior about WebDAV... they all use SMB anyway. > However, once they had configured their environment to match my > original bug report (server using cert issued by CA client doesn't > trust, server configured not to require authentication) imagine my > lack of surprise when the problem was repeated with IIS. Needless > to say the other end of the conference call went very, very quiet > at that point. > > The issue has now been passed to yet another support employee (I > refuse to call these people engineers) who apparently wants to > discuss the issue further. What they can possibly need to discuss > at this point I have no idea but having told them (again) how to > contact me I am waiting to hear from them. > > I also discovered that - despite the conference call - the latest > support ticket update from Microsoft claimed the issue could not > be repeated with IIS. > > It appears that the issue has been passed to the IIS team which > makes no sense at all since all the evidence points to this being a > WebDAV client bug and I have been making that point since this > whole sorry episode started. The good news is that the IIS team is likely to refuse to accept responsibility for the bug (because, by definition, IIS contains zero bugs) and likely to pass the buck back to the WebDAV client team. If you catch them at just the right time, you may be able to show MS how to do their own jobs. > While I continue to appreciate the free MSDN license Microsoft > kindly provide to Apache committers, I must confess to being > completely unimpressed by Microsoft's support structures and count > myself fortunate that I don't have to run an IT infrastructure that > relies on them. +1 - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnSpYAAoJEBzwKT+lPKRYCDkP/2KJK6mjA0rCQ8m/cT+3iPTe bDyXDNTs4g2aycCdKReW9MtcGwy0Qf2M5YEv6+f5EzKjDeMuR5KZU2kieqFf0nh2 DOft4iCLFdbynqyXHPq0fEpbg0dGJjAr9sB+ifA/0t+2v7iXB2bxvfu/2MZrhHYl I9L2zGrrq3JcuXrEMINm5PZJDkHwHf1lWrXTk/P/2hCw7mHFVj9qraPE3bfQULVZ XviuW4l7TfbIfqu5B8w42/VYayOC3l9rh4eW59Eea44bikj44c9q2OuB94JNXYy8 mvSS2oyOX0pe2JtjrAt0XFHL7fuz4C4bbZeEremdYrLclbVlC20PuKvxeuvuEfXn jE71qIuP+4vPD5+VlUuyIkW04r73CqeaEYGQPatrBCA+J702B05IsND3JF7ZHrdq /Ms7PugZurLJD99/UJMCvFCDnPiuL4jWMDo1NLDq5BOCXHtdN2KeDYG0zTJhh2Dk nH1y/sdJ8B3Uaya8heK7b+oxR2LS77vfmTyYRD9KMIgFDeMay1hPOvy9nAot2PEw CJkfd1YVVl+0Ym9mqKq4wybTguSXfA4DrC98H3BskuWhtB3Ev79bUCPsHxa8je1k FcN3+KaslxAk3UcxvgsXTagRIGo3S7Wnk8X2LOqrAmB0m9A8kMZuT3lHiCyhyPxG GhatQDMYanSiOd3NJNTc =+Gqo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange JSP compilation issues in tomcat 7 and 8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 7/7/15 5:21 AM, p...@kuruma.co.uk wrote: > Hi Christopher, > > I can confirm that in tomcat 8.0.23 the application does not work > with or without ##'s in the file name, however in tomcat 8.0.15 it > works without the hashes. > > I compiled a list of my tests and the exceptions that occurred, > they are different in tomcat 7 and tomcat 8: > > I have them in an excel spreadsheet if they are of any use to you > but I dont know if attachments are allowed on these emails? > > I have managed to get this working now though thankfully and it > was actually down to something quite simple... > > I deployed a standard JSP file and this compiled ok so I narrowed > it down to just being a Tiles issue. > > My pom used to have version 3.0.3 defined and when I upgraded this > to 3.0.5 the issues have gone away in both tomcat 7 and tomcat 8 > using java 7 or java 8 and it also work without issue in tomcat > 8.0.23. > > If only I had tried that first! > > Thanks to everyone who replied offering help. I'm glad to see that (a) Tomcat doesn't have a bug and (b) there is an update to Tiles that works correctly with Tomcat. I suspect the underlying problem was an edge-case conflict with Tomcat's new "resources" implementation, which is based upon URLs instead of the old-style "DirContext" which looked more like a standard filesystem API. This change can make weird things happen if the library isn't consistent about the way it loads resources. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnSgHAAoJEBzwKT+lPKRYtFsP/0RCzuSYiyeML3E+foDjkVkF 9pnCfG8NSxX20lf9bxyhFE/OOAYiB3M33CnL5XS5unprBeYOiBdRPlqdgsPucf59 SjDlvFwmePKsJlI7BgW3qLNXQYyVss1MA8mxrSDMbsqKUAcFN2F5mwc84n0em9D7 t2X4eHL01empG8DTHB1xFYrq2PHzHtTL9sU5beajE0araF158gMC6LKqusYGzKcf 9e7iLY1mqfJiFIefp0nPIvfNKeddKaoowr2QoXzkQaxxIX1dsusVux665QeSoIWt MR62GRKSa8/Avk3TyVkZ6ydCcfK0jY9emi9ZJaN7E5WvIVfGmu2IH7vYbYig0k/a m4pVM0Ush8VclMWD+GXOgjseHZm0nKC+mGTb8PHGuBABt850TB7M2btm2OOBVq42 H0IKQtaaMLhmUZKHukjiRZl8KVtDT3p63aPTcmMUhHfT7ZB9EDAredXJxp/jCLZ7 fNoPn9hlBLbfndHFNUq3xyuiaZF7CytJ7iJOWEQKyTVr+mTqlDcDMvp87Qp+0Fau 3ToOsv/7GYoySrwbpPyJShiRlJMZJd/frSB7BHVDIXbtheBXRzJgQGk+X53S9Wrq FS6KL6bPAqujX98wcWCxkQggf9BnLaH2jRgGr62yf0bYeH/E3QLQSehKR2e/cvQZ JLTwfbSsnpyqLiOQSiFX =SDPy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 8.0.24 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.24. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language and Java WebSocket technologies. Apache Tomcat 8.0.24 includes numerous fixes for issues identified in 8.0.23 as well as a number of other enhancements and changes. The notable changes since 8.0.23 include: - Provide path parameters to POJO via per session javax.websocket.server.ServerEndpointConfig as they vary between different requests. - Various fixes to the SlowQueryReport in jdbc-pool - Various improvements to how Tomcat implements the requirements of SRV.10.7.2 (not loading Java SE and implemented specification classes from web applications) Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache HTTPD (with SSL) + mod_jk + TomEE (Tomcat) nullify the ssl session id
Alex Soto wrote: Hi I have tried this approach custom JkEnvVar are pass correctly, what I don't know how to do is how to set an already JkEnvVar to a new JkEnvVar (what you mention about "force)) I have tried with %{SSL_SESSION_ID} and $ but no luck (Don't know if it is because originally it was null or not). I think it is just JkEnvVar SSL_SESSION_ID "none" (where "none" is the default value, used if the Apache "environment variable" SSL_SESSION_ID was not set before you pass the request to Tomcat.) (The default value insures that Tomcat always gets something, no matter what) Then in Tomcat you do request.getAttribute("SSL_SESSION_ID") , and if you find the value "none", it means that SSL_SESSION_ID was not set at the httpd level. Note: if that does not work, there is still another method that can be tried : setting a HTTP request header, before proxying to Tomcat. It would work like this : RewriteEngine On RewriteRule .* - [E=MY_SESSION_ID:%{SSL_SESSION_ID},NE] RequestHeader set JK-SSL-SESSION "%{MY_SESSION_ID}e" and then in Tomcat you would retrieve the HTTP header "JK-SSL-SESSION". Alex. El dt., 7 jul. 2015 a les 23:05, André Warnier () va escriure: Alex Soto wrote: yes it is set at httpd-ssl.config https://github.com/lordofthejars/apache-tomee-ssl/blob/master/httpd-ssl.conf#L229 which I think that is where it should be set. Everything too strange, but thanks anyway. Then, and until Rainer himself jumps in, let me ask you if it would be possible to make one more test. As far as I understand, this is not the way it /should/ work, but it may be a way to find out what doesn't work, inasmuch as there is really a problem : Somewhere in that same page, there is a way by which you can "force" a value to be passed on to Tomcat as a request attribute (via JkEnvVar "name" "default-value").. Can you try to pass the SSL session-id in that way, and obtain it in Tomcat via request.getAttribute("name"), instead of the standard request.ssl_session ? And check if /then/, you get it all the time ? Again, this is probably not the way in which this should work. But Tomcat is open-source and free software, and its development and debugging benefit from the help of any benevolent user, particularly if that user is interested in solving a particular problem that he is having. El dt., 7 jul. 2015 a les 19:17, André Warnier () va escriure: Alex Soto wrote: Thank you so much but it is already set. https://github.com/lordofthejars/apache-tomee-ssl/blob/master/httpd.conf#L171 This is so strange. But there is also this phrase : "In order to make SSL data available for mod_jk in Apache, you need to set SSLOptions +StdEnvVars." Honestly, I have never tried this, and I am not an SSL specialist at all, and the phrase above is a bit ambiguous. But it seems worth a try, and I do not see it in your configuration. El dt., 7 jul. 2015 a les 12:25, André Warnier () va escriure: Mark Thomas wrote: On 07/07/2015 09:28, Alex Soto wrote: Hi Mark, SSL Session ID is not passed to Tomcat. You can see the logs here https://gist.github.com/lordofthejars/226d8ed605f2a58b52f3 (I have created a gist to not add here a lot of lines). Now the question is is it happens because of mod_jk or because of Apache? Alex. OK. You've reached the limits of my conform zone. You need someone more familiar with the httpd side of things at this point. Rainer? Mark Not Rainer, but maybe this helps : http://tomcat.apache.org/connectors-doc/reference/apache.html Look for "JkExtractSSL". El dl., 6 jul. 2015 a les 12:48, Mark Thomas () va escriure: On 06/07/2015 10:48, Alex Soto wrote: Hello I have seen a strange behaviour in Apache HTTPD (2.4) and TomEE (in fact it is a Tomcat (7.0.61) so it is exactly the same for Tomcat) when I configure Apache server with SSL and mod_jk. In fact I am not sure where it is the problem if in mod_jk, in Apache Server or in Tomcat, but I suspect that maybe the problem is on mod_jk configuration. I am configuring the typical Apache as frontend and TomEE(Tomcat) as backend solution. Currently Apache is configured with SSL and with mod_jk it connects to TomEE using AJP. This works perfectly. The problem is that inside my code I need to get the ssl session id: String ssl = (String)servletRequest.getAttribute("javax.servlet.request.ssl_session_id"); I don't know why but sometimes this attribute is null and sometimes not. It may return a null at first then stay like 10 requests working and then stop working again during some requests and the get attribute returns null. It seems that everything is configured correctly since sometimes works. Have you ever found something similar or knows what it can be happening? Do you think that maybe the problem is on client (browser) side? Everything is dockerized here: https://github.com/lordofthejars/apache-tomee-ssl so you can review configuration files of tomcat and apache or even run it. Thank you s
Re: Apache HTTPD (with SSL) + mod_jk + TomEE (Tomcat) nullify the ssl session id
Hi I have tried this approach custom JkEnvVar are pass correctly, what I don't know how to do is how to set an already JkEnvVar to a new JkEnvVar (what you mention about "force)) I have tried with %{SSL_SESSION_ID} and $ but no luck (Don't know if it is because originally it was null or not). Alex. El dt., 7 jul. 2015 a les 23:05, André Warnier () va escriure: > Alex Soto wrote: > > yes it is set at httpd-ssl.config > > > https://github.com/lordofthejars/apache-tomee-ssl/blob/master/httpd-ssl.conf#L229 > > which I think that is where it should be set. > > Everything too strange, but thanks anyway. > > Then, and until Rainer himself jumps in, let me ask you if it would be > possible to make > one more test. As far as I understand, this is not the way it /should/ > work, but it may be > a way to find out what doesn't work, inasmuch as there is really a problem > : > > Somewhere in that same page, there is a way by which you can "force" a > value to be passed > on to Tomcat as a request attribute (via JkEnvVar "name" "default-value"). > Can you try to pass the SSL session-id in that way, and obtain it in > Tomcat via > request.getAttribute("name"), instead of the standard request.ssl_session ? > And check if /then/, you get it all the time ? > > Again, this is probably not the way in which this should work. But Tomcat > is open-source > and free software, and its development and debugging benefit from the help > of any > benevolent user, particularly if that user is interested in solving a > particular problem > that he is having. > > > > > El dt., 7 jul. 2015 a les 19:17, André Warnier () va > > escriure: > > > >> Alex Soto wrote: > >>> Thank you so much but it is already set. > >>> > >> > https://github.com/lordofthejars/apache-tomee-ssl/blob/master/httpd.conf#L171 > >>> This is so strange. > >> But there is also this phrase : "In order to make SSL data available for > >> mod_jk in Apache, > >> you need to set SSLOptions +StdEnvVars." > >> > >> Honestly, I have never tried this, and I am not an SSL specialist at > all, > >> and the phrase > >> above is a bit ambiguous. But it seems worth a try, and I do not see it > >> in your > >> configuration. > >> > >>> El dt., 7 jul. 2015 a les 12:25, André Warnier () va > >>> escriure: > >>> > Mark Thomas wrote: > > On 07/07/2015 09:28, Alex Soto wrote: > >> Hi Mark, SSL Session ID is not passed to Tomcat. You can see the > logs > here > >> https://gist.github.com/lordofthejars/226d8ed605f2a58b52f3 (I have > created > >> a gist to not add here a lot of lines). > >> > >> Now the question is is it happens because of mod_jk or because of > Apache? > >> Alex. > > OK. You've reached the limits of my conform zone. You need someone > more > > familiar with the httpd side of things at this point. Rainer? > > > > Mark > Not Rainer, but maybe this helps : > http://tomcat.apache.org/connectors-doc/reference/apache.html > Look for "JkExtractSSL". > > > >> El dl., 6 jul. 2015 a les 12:48, Mark Thomas () > va > >> escriure: > >> > >>> On 06/07/2015 10:48, Alex Soto wrote: > Hello I have seen a strange behaviour in Apache HTTPD (2.4) and > >> TomEE > >>> (in > fact it is a Tomcat (7.0.61) so it is exactly the same for Tomcat) > when I > configure Apache server with SSL and mod_jk. > In fact I am not sure where it is the problem if in mod_jk, in > >> Apache > Server or in Tomcat, but I suspect that maybe the problem is on > >> mod_jk > configuration. > > I am configuring the typical Apache as frontend and TomEE(Tomcat) > as > backend solution. Currently Apache is configured with SSL and with > mod_jk > it connects to TomEE using AJP. This works perfectly. The problem > is > that > inside my code I need to get the ssl session id: > > String ssl = > > >> > (String)servletRequest.getAttribute("javax.servlet.request.ssl_session_id"); > I don't know why but sometimes this attribute is null and > sometimes > not. > >>> It > may return a null at first then stay like 10 requests working and > >> then > >>> stop > working again during some requests and the get attribute returns > >> null. > It seems that everything is configured correctly since sometimes > works. > Have you ever found something similar or knows what it can be > happening? > >>> Do > you think that maybe the problem is on client (browser) side? > > Everything is dockerized here: > https://github.com/lordofthejars/apache-tomee-ssl so you can > review > configuration files of tomcat and apache or even run it. > > Thank you so much for your support. > >>> Try turning on debug logging for mod_jk. It will generate lots of > >> data > >>> so
Questions about the HTTP connector config
Hi ALL! I desire for using tomcat as the websocket server. But I'm now wondering about the tomcat performance. Does anyone know the max connections that tomcat could held? the concurrent number requests? And I don't quite understand the configurations: acceptCount & maxConnections & maxThreads There must be some relationship between the three params. if I set [ accpetCount=200, maxConnections=1, maxThreads=100] dose it means: 1, the max connections that tomcat maintain with the client is 1. and if the 10001 client's connect request is coming, the client will timeout. 2, the max request is 200, and the 201 request will be refused. 3, the max concurrent request is 100. Best regards! jingych --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---