Brief follow up on CPU spike issue. In an attempt to work around the
problem via configuration changes, we have swapped out APR connectors
with NIO using an equivalent configuration. (The only meaningful
changes are SSL configuration directives.) Since swapping out
connectors over the weekend, w
> Can you confirm whether or not the issue exists with 6.0.26 and 1.1.22?
I cannot. We have tried repeatedly to reproduce this problem in a
test environment where such experimentation is tolerated, but the
problem simply does not manifest using available load testing tools.
We attempted to try 7.
We are seeing excessive CPU burn (top > 300% on multicore machine) in
multiple versions of Tomcat that use APR connectors exclusively. The
problem does not correlate with load. We initially saw it on 6.0.35
and subsequently on 7.0.23 as we attempted to upgrade around the
problem. We have determi
> /can/ the servlet (or one of the filters)
> do anything that would cause the value of "name1" to /not/ be a correct Java
> "TÜV" string in the servlet ?
Yes, absolutely. If this is a posted value and some filter fires that
coerces the encoding (e.g. request.getParameter() in the case of POST)
o
> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.)
> support an authentication mode where no password or credentials are required?
It's hard to imagine a valid use case for this -- I hope you know what
you're doing. That said, you could use JAASRealm with
http://code.google
> 3] And then from Clinet Side, from where, I execute curl, kill all curl
> process.
> So, on server all ESTABLISHED becomes, CLOSE_WAIT in netstat.
I'd imagine kill -KILL or kill -TERM is preventing proper socket
teardown. The server is expecting ACKs from the clients that
apparently not being
Crypto providers need to be installed into the JRE extension directory
(e.g. $JRE_HOME/lib/ext) and an entry must be added to
$JRE_HOME/lib/security/java.security to install the provider. For
example:
security.provider.5=org.bouncycastle.jce.provider.BouncyCastleProvider
Note the 5 above; each p
The following works as expected on my config (6.0.26) using the
default protocols and cipher suite as in your config:
$ openssl s_client -connect eiger:443 -debug -ssl3
CONNECTED(0003)
...
Something in your SSL version jumped out at me:
OpenSSL 0.9.8e-fips-rhel5
Looks like you're running Op
> In windows, How to let the tomcat write the catalina log to the log file
I was going to suggest setting the CATALINA_OUT environment variable,
but it looks like that's only supported in catalina.sh for Unix hosts.
If you're starting via startup.bat/catalina.bat, you could edit
catalina.bat to r
> You can also do it with iptables, converting any port 80 request to 8080.
> The user types in http://mywebapp but gets redirected to
> http://hostname:8080
+1
What I use:
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
M
-
> My question is, why my first aproach didn't work ?
Likely because you specified the APR connector somewhere in your
connector config, yet the SSL instructions you cited for CAS describe
the setup for the pure-java connectors. APR is a different (but
friendly) beast.
M
---
> SSLEngine="on"
There's no such attribute for this connector. The attribute you want
is SSLEnabled="true". I would also recommend the following attributes
for security-conscious deployments:
SSLProtocol="SSLv3+TLSv1"
SSLCipherSuite="!ADH:HIGH:MEDIUM:-SSLv2"
If you continue to have trouble, po
> port="8443" maxThreads="200"
> scheme="https" secure="true" SSLEnabled="true"
> SSLCertificateFile="/usr/local/tomcat/conf/my.crt"
> SSLCertificateKeyFile="/usr/local/tomcat/conf/my.pem"
> clientAuth="optional" SSLProtocol="TLSv1"/>
>
Things to
If you've got the container to request and accept a client cert, the
connector configuration is likely correct and it's an SSL trust
problem. Please post the output of the following command:
keytool -list -keystore
D:/users/apache-tomcat-7.0.11/keystore/trust.keystore -storePass
changeit
Also, p
> I can get with the Dev team and see if they are willing to re-code for the
> possibility (or even need to).
It's a valuable change that dramatically increases your deployment
options; well worth the effort IMO.
M
-
To unsubsc
> This is equivalent to the inclusion of the following element in the web
> application deployment descriptor (/WEB-INF/web.xml):
>
>
> companyName
> My Company, Incorporated
>
>
> but does not require modification of the deployment descriptor to customize
> this value.
That's correct but
> I think you mean "any attempt to WRITE The RESPONSE".
I took some time to verify the effect I described,
https://github.com/serac/charset-test. Reading data from the request
body coerces the encoding as I claimed. Simply swap the order of the
filter-mappings in web.xml and post some unicode da
> Does Tomcat APR really needs pollTime set so low by default?
Anyone care to comment on this point? I'm interested in this
discussion as a user of Linux+APR connectors. While we don't yet run
on a tickless kernel, I'm considering trying to measure the impact on
our systems as well, but some ins
> If you want to set
> the charset in the HTTP header, you'll need to set it explicitly using a
> JSP, a filter or similar.
It's wise to do both, http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8.
For the filter, it's important to put the filter at or near the top of the
filter chain sinc
> There is some "junk" ("bag attributes")n the file that I don't' understand. I
> am used to just seeing "-BEGIN CERTIFICATE- "END CERTIFICATE-
> "" ""-BEGIN RSA PRIVATE KEY- "-END RSA PRIVATE KEY- "
As far as I know, keytool can only import certificates in PKCS8
20 matches
Mail list logo
