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. ---
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 (a...@ice-sa.com) 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 (a...@ice-sa.com) 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 (a...@ice-sa.com) 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 (ma...@apache.org)
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
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 (a...@ice-sa.com) 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 (a...@ice-sa.com) 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 (a...@ice-sa.com) 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 (ma...@apache.org)
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 just do it long enough to see the problem. When you look at the
logs
you should be able to see if the SSL Session ID is being passed to
Tomcat or not.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:
[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: [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: snip/ Prompting for authentication in response to an untrusted certificate is bizarre to say the least. snip/ Progress, if you can call it that, has not been good. They have now asked for additional network traces since: quote ... 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 /quote 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
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: 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 (a...@ice-sa.com) 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 (a...@ice-sa.com) 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 (a...@ice-sa.com) 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 (a...@ice-sa.com) 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 (ma...@apache.org)
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
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: snip/ Prompting for authentication in response to an untrusted certificate is bizarre to say the least. snip/ Progress, if you can call it that, has not been good. They have now asked for additional network traces since: quote ... 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 /quote 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
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
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: 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
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: application frequently down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yon, On 7/3/15 2:04 AM, Yon, wrote: !--APR library loader. Documentation at /docs/apr.html -- Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / This is not enough to use APR. Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / [...] Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Neither of these Connector 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: 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: VirtualHost *:80 ServerName sub1.mydomain.com ServerAlias sub1.mydomain.com ## ReverseProxy's ProxyRequests Off ProxyPreserveHost Off # Have tried both on and off Proxy * Order deny,allow Allow from all /Proxy 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. Connector port=28080 protocol=AJP/1.3 secure=true 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: 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: 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. ---
