mod_jk - Failover behaviour and load
Hi all,
I have this situation, an hardware loadbalancer configured with sticky
session based
on souce IP, two httpd servers behind it doing HTTPS termination with
mod_jk doing
load balancing vs four tomcats, i'll try to do my best in ascii art,
hopping my mailer
does the right thing:
- {internet}-
|
v
[HW LB with source IP stickyness]
| |
| |
[httpd1][httpd2]
[mod_jk] [mod_jk]
| |
==
| || |
[TC1] [TC2] [TC3] [TC4]
Each apache httpd talks with every tomcat.
mod_jk is configured with load balancing by business, sticky sessions, only
one try for ajp worker (so if it's busy i dont add more stuff to the
poor worker)
and only 1 retry for all load balanced workers, in short, here's the
interesting
part of my conf:
worker.worker_lb.balance_workers = w1, w2, w3, w4
sticky session on, sticky session force = off ecc
[...]
Now, even with this settings, on peak times i have an amplification
effect, all
tomcats are busy, mod_jk reaches atimeout and retries again and again
... in a
death spiral for the poor cats.
This behaviour brings me two problems:
1) Even if apache httpd / mod_jk timeouts (read_timeout) from his side
this does
not stop the tomcat thread proccessing that request. It goes sometimes
on and on
but after all finishes the request.
This seems a resource waste, is there a way to let tomcat know that
mod_jk droped
the connection and stop proccessingthe dropped request? I tried to find
a way to
get this behaviour without success, so any suggestions are welcome.
2) I noticed that the default behaviour of load balanced workers and AJP
workers is
as follows:
a) ajp worker reaches retry_timeout, at this point retries again to
the same worker
once, thus amplifying load. This onewas easy to solve, just add a
"worker.w1.retries = 1"
and this does not happen anymore
b) Load balancer worker goes to the next ajp worker.. till the last
one, than does
another round of requests:
lb -> w1 -> timeout
[...]
lb-> w4 -> timeout
LB try 2
lb -> w1 -> timeout
[...]
request fails.
The second round to the workers IMHO is wasteful, but easy solved
with:
"worker.worker_lb.retries = 1"
So at this point for every request all the busy tomcats get only one
request. I tryed finding a way to tell
the LB worker to try just once, only another worker for request but i
didnt find an option for doing this.
Well, as i had an each to scratch i made a patch that adds an option to
a LB worker telling how much times
to retry before giving up, i'm glad to post it if somebody is
interested. Not sure it's perfect, but works
for me.
Now, my questions:
1) Am i doing something wrong?
2) Is there a way to make a tomcat thread stop proccessing when AJP
timeouts?
Thanks in advance,
Frederik
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat-native libraries
> Date: Tue, 18 Mar 2014 19:57:57 +0530 > Subject: Re: tomcat-native libraries > From: randeep...@gmail.com > To: users@tomcat.apache.org > > On Tue, Mar 18, 2014 at 7:29 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Randeep, > > > > On 3/18/14, 9:46 AM, Randeep wrote: > > > On Tue, Mar 18, 2014 at 7:13 PM, Christopher Schultz < > > > ch...@christopherschultz.net> wrote: > > > > > > John, > > > > > > On 3/17/14, 9:52 AM, John Smith wrote: > > > > > > > > > Installing the native library will make a difference. > > > Whether the difference is large enough to notice depends > > > very much on your application. If you want to improve your > > > application's performance I suspect your time would be > > > better spent with a profiler to see where the bottlenecks > > > are in your application. > > > > > > Mark > > > > > > > +1 I had the native APR installed and ended up removing it in > > favor of keeping things simple. The NIO connector often > > recommended by Chris S. and others works very well. > > > > > > It's also a big "safer" in that obscure problems rarely bring-down > > > the JVM, whereas a bug in tcnative/apr/openssl can kill the entire > > > JVM without warning. > > > > > > Using APR really only makes sense if you are using Tomcat directly > > > as a web server that uses SSL, since there is a measurable > > > difference between OpenSSL's performance and JSSE's performance. > > > > > > -chris > > > > > > > > >> Thank you Chris, In that case, I'm not going to use it. I was > > >> using httpd as front end to server ssl certificates. Now load > > >> balancer is handling it. > > > > Stick with the NIO connector. If you are using AJP to connect httpd to > > Tomcat, you will probably be better off with the BIO connector, > > actually. It's simpler and basically bug-free given its maturity. > > Since there is a 1:1 map between Tomcat and httpd connections, there's > > no really good reason to switch to another connector IMO. > > > > - -chris > > > > Chris, > I'm not sure about what kind of connector I'm using. This ismy > configuration. > > httpd-2.2.3-65.el5.centos + tomcat-connectors-1.2.28-src + > tomcat-connectors-1.2.28-src > > [root@server tomcat-connectors-1.2.28-src]# cat > /etc/httpd/conf.d/mod_jk.conf > JkWorkersFile /etc/httpd/conf.d/workers.properties > JkLogFile /var/log/httpd/mod_jk.log > JkLogLevel info > JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " > JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories > JkRequestLogFormat "%w %V %T" > JkMount /* worker1 > JkShmFile /etc/httpd/logs/jk-runtime-status > > [root@server tomcat-connectors-1.2.28-src]# cat > /etc/httpd/conf.d/workers.properties > workers.tomcat_home=/usr/share/apache-tomcat-6.0.37/ > workers.java_home=/usr/java/default > ps=/ > worker.list=worker1 > worker.default.port=8009 > worker.default.host=localhost > worker.default.type=ajp13 > > Is there anyway to check which type is this NIO or BIO? MG>check the Connector in server.xml > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1 > > Comment: GPGTools - http://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iQIcBAEBCAAGBQJTKFFMAAoJEBzwKT+lPKRYS74P/1UkDakuqDz6LyLUaBeTzcXl > > R/2eliStJMAE146C6QpE2YBV4w2dyh/xEnndRmbE3R3NE9cD3yUom+VO7x1OOgL9 > > ODM8Ry5AWXBXqhjx2k4hjRM43Hza6Z+GJYb9RutdLj71GCU4fEFrTX23sCAkUKbx > > nzCGMG4robj7l6TDSdK6uZpmisV7LGBWsUIjkJnTX5AvxFhU5QsFOISE/osFAy6I > > ukw840t57BCJ0mlIV/EBORa+0BCO+lz7ZBk+kkwHG5mSXFapTqNcySKfYGEzkVmD > > 8OHBJehmkqHfBuqgiavIwpLZ3wZnLcrJpsMzdxGUG1wuuFVtr1aRZ+h/L+/diUnE > > B37m9fOuwd3RfY7uhJXATiYo8oW5nB/EOIYuKDsfgMi7eY/NBg2r8Rw7MHYLJUuN > > lXtHJTyyBLQcgw5twnTbdA5MPbdgjZ2A2uw6sKCf5/vNyZBkGky+6Fush9cMRIL/ > > zdmNyJCCP9jzBOltFl0NNW/bpI1UKpMk8bScJZvAC3JNvMt1FCu3e4rQmqJXlzwG > > yBIQeqoIHpogLbF5CxGcOUJGV80O0o5vq+N2qt7TArqOHEifGhroVAQPEOtYmI/K > > x7u4Xv+VPg19YmRS6PJCYkYw082vFbmanXjt7BgmUWNs3WD1ooe66bmWPzKX3btA > > HcuHDQFgyaGQu0z55MYP > > =Vqt8 > > -END PGP SIGNATURE- > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > -- > Randeep > Mob: +919447831699[kerala] > Mob: +919880050349[B'lore] > I blog here: > http://www.randeeppr.me/ > Follow me Here: > http://twitter.com/Randeeppr > Poke me here! > http://www.facebook.com/Randeeppr > A little Linux Help > http://www.linuxhelp.in/ > Work profile: > http://in.linkedin.com/in/randeeppr
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Seema-
You've asked about 10 different questions on 10 different aberrancies on your
upgrade
zip up the whole project up and stick it on driveway or any other free site
That way anyone building/running the code on TC7.0.52 can at least observe
same behaviour you are experiencing
Martin --
> From: seema...@hotmail.com
> To: users@tomcat.apache.org
> Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
> Date: Tue, 18 Mar 2014 14:10:19 +
>
> Any update on this Chris Schultz or anyone else? I know the images I added to
> the email didn't show up, so if you want me to email them directly to you, I
> can.
> Could really do with help on this, as it is not something I know much about.
>
> Thanks
> Seema
>
> > From: seema...@hotmail.com
> > To: users@tomcat.apache.org
> > Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
> > Date: Fri, 14 Mar 2014 15:15:04 +
> >
> >
> >
> > > Date: Fri, 14 Mar 2014 08:36:08 -0400
> > > From: ch...@christopherschultz.net
> > > To: users@tomcat.apache.org
> > > Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > Seema,
> > >
> > > On 3/14/14, 7:53 AM, Seema Patel wrote:
> > > > I have upgraded my tomcat (5.5.29 to 7.0.52) and Java (1.5 to 1.7)
> > > > for my struts servlet jsp application. I have also removed all
> > > > JCIFS authentication from the WEB-INF/web.xml file and have tried
> > > > to do BASIC authentication through Tomcat and the AD (it
> > > > authenticates me, but not sure if I've missed anything out, as I've
> > > > never done this before).
> > >
> > > One question at a time, please ;)
> >
> > Sorry for the off-loading of multiple questions :-)
> >
> > >
> > > > I have a doFilter function in my code, which contains
> > > > httpServletRequest.getServletPath() call. In the Tomcat 5.5.29 Java
> > > > 1.5 version, this will work, as when I print
> > > > httpServletRequest.getServletPath() i get the following:
> > > >
> > > > P1_00.do P5_0_0.do P5_0_1.do
> > > >
> > > > But in Tomcat 7.0.52 Java 1.7 I get the following from
> > > > httpServletRequest.getServletPath() call:
> > > >
> > > > P1_00.do P5_0_0.do P5_0_1.do includes/tab_defaultsettings.jsp
> > > > includes/P1_00.do
> > >
> > > How are you printing this? Do you just have a Filter that wraps
> > > everything and dumps-out the ServletPath for every request? Can you
> > > post the code for that Filter as well as the and
> > > configuration you have in web.xml?
> > >
> >
> > I'm just doing a System.out.println() in the doFilter function in the
> > RequestFilter class to show which page it is. The doFilter function is:
> >
> >
> > public void doFilter(ServletRequest request, ServletResponse response,
> > FilterChain chain) throws IOException, ServletException {
> > if (request instanceof HttpServletRequest) {
> > final HttpServletRequest httpRequest = (HttpServletRequest)request;
> > final Object userBeanObject =
> > httpRequest.getSession().getAttribute(GenConstants.LOGGED_IN_USER_BEAN);
> > final String pageName = httpRequest.getServletPath().replaceAll("/","");
> > System.out.println("Request Page = " + httpRequest.getServletPath());
> > if (unsecuredPages.contains(pageName)) {
> > // don't need any protection
> > chain.doFilter(request, response);
> > } else if (!(userBeanObject instanceof UserBean)) {
> > // no user bean in session do need one, invalidate session and redirect to
> > login
> > if (httpRequest.getSession(false) != null) {
> > httpRequest.getSession().invalidate();
> > }
> > ((HttpServletResponse)response).sendRedirect(logonPage);
> > } else {
> > final UserBean user = (UserBean) userBeanObject;
> > Map permissions =
> > (Map)context.getAttribute(GenConstants.PERMISSIONS_MAP);
> > if(permissions == null) {
> > PermissionsUtil.setupPermissions(context);
> > permissions =
> > (Map)context.getAttribute(GenConstants.PERMISSIONS_MAP);
> > }
> > final LogicalOperation requiredOp =
> > permissions.get(pageName.replaceAll("\\.do",""));
> > if (user.isOperationAllowed(requiredOp)) {
> > chain.doFilter(request, response);
> > } else {
> > if (httpRequest.getSession(false) != null) {
> > httpRequest.getSession().invalidate();
> > }
> > ((HttpServletResponse)response).sendRedirect(logonPage);
> > }
> > }
> > }
> > }
> >
> > To give you a better idea of what was in the web.xml, here is what's been
> > taken out:
> >
> >
> > NtlmHttpFilter
> > jcifs.http.NtlmHttpFilter
> >
> > jcifs.smb.client.soTimeout
> > 3
> >
> >
> >
> >
> > jcifs.smb.client.domain
> > XXX.LOCAL
> >
> >
> >
> > jcifs.smb.client.username
> > username
> >
> >
> > jcifs.smb.client.password
> > password
> >
> >
> >
> > jcifs.util.loglevel
> > 2
> >
> >
> >
> > jcifs.http.insecureBasic
> > true
> >
> >
> >
> >
> > NtlmHttpFilter
> > *.do
> >
> >
> > NtlmHttpFilter
> > *.jsp
> >
> >
> > Here is what is still in the web.xml file (pre-upgrade and now):
> >
> >
> > ADG
Re: jax-ws and tomcat 7 with ssl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maria, On 3/18/14, 5:58 PM, Maria Cristina Siena wrote: > Hi, > > I developed a web service using jax-ws and configured Tomcat to > support SSL connection. Here are my steps: > > ** Step 1 - Generate a self-signed server certificate > > Use JDK 1.7 keytool: > > keytool -genkey -alias trackerdev -keypass changeit -storepass > changeit -keystore D:\Tomcat7\htdkeystore\trackerdev.ks –ext > san=ip:xx.x.x.xxx > > Is CN=xx.x.x.xxx, OU=it, O=companynamehere, L=citynamehere, > ST=provincenamehere, C=ca correct? [no]: yes > > ** Step 2 – Configure Tomcat to support SSL connection > > On the dev server: > > Modify TOMCAT_HOME\conf\server.xml by adding the following block > where keystoreFile and keystorePass are set to values from the > previous step: > > maxThreads="150" scheme="https" secure="true" clientAuth="false" > sslProtocol="TLS" keystoreFile="htdkeystore/trackerdev.ks" > keystorePass="changeit" /> > > ** Step 3 - Export the generated server certificate to a > certificate file > > On the dev server: > > keytool –export -alias trackerdev -storepass changeit –file > D:\Tomcat7\htdkeystore\serverdev.cer -keystore > D:\Tomcat7\htdkeystore\trackerdev.ks > > ** Step 4 - Import the server certificate into the truststore > file (Open an administrator cmd window and hit Shift, Ctrl, Enter) > > Copy serverdev.cer from the dev server and on the local machine: > > keytool –import –v –trustcacerts –alias trackerdev –file > C:\fromdevserver\serverdev.cer –keystore "C:\Program > Files\Java\jdk1.7.0_51\jre\lib\security\cacerts" -keypass changeit > -storepass changeit > > Trust this certificate? [no]: yes > > ** Step 5 – Modify webapps’s web.xml > > Add the following: > com.sun.xml.ws.transport.http.servlet.WSServletContextListener > > tracker > com.sun.xml.ws.transport.http.servlet.WSServlet > tracker > /tracker > > securedapp > /tracker > > CONFIDENTIAL > > > ** MY QUESTION IS THIS: > > I tested the web service using https and it worked for me. I > provided another team with my server certificate so that they could > add it to their truststore file but I have no idea if they did or > not. All I know is that they got an error loading the wsdl. The > exception they got was: > > Error loading [https://xx.x.x.xxx:8444/appname/tracker?wsdl] > org.apache.xmlbeans.XmlException: > javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: PKIX path building > failed: sun.security.provider.certpath.SunCertPathBuilderException: > unable to find valid certification path to requested target > > They claim that the certificate is not properly signed. Well, I > don't know. It is a self-signed certificate. Self-signed certificates are almost never trusted by outsiders. Why not go ahead and get a trusted cert? You can get them for free at StartSSL.com. Note that Java does not ship with a StartSSL CA root-level certificate, so you still have to import the CA's root key into the client's key store. If your client is willing to import /your/ self-signed CA's certificate (that is, your own certificate) into their trust store, then just send them your CA cert. They may not know how to configure that correctly -- it's not exactly the easiest thing in the world for a Java client. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKOUVAAoJEBzwKT+lPKRYxuQP+gOh9NnPEjB2nfXw3qe1r1v6 jzPkDxRFf7qIqhdJMEuGy40ndatK2Q2xU2IPPZi0P2ba+y/PWQ7g9egFlutZC3H5 uR+TtPOxw67njLGy2QehCgOaQ+/eBoXUFlU9bywfMYpm22OmrIxogiahvlAnP6Y4 ZKEPaJ5GxJaq+f6kiWsgWNPZMIQUYEL2eK9CKdMWz2GzIwdVXnHqRhaqHlP5u3hE SZrEOOubYCLaQN6AtGV4kyBBj97zR/u5JWh7t8jlHekZwY5jeroP/s8knOTxAXOn 6aEbmdEh85uSyLc02FixDzPA41h6BHSRyM1X1TrhgInABkIMBJtC3kecscjcWnUV CXaNW69vq/2l64z4O7CR/IrRtR8gLHcUDNpIN2PjpOFHD9oSNvBAXEMv5sM/VYFc hHIJbStUi/q/3JUGe6m2qVvCkeuxKORXzZ1KwczVK2o+J7IXO1XZ0wzKAWvig63A paGi1jNEFJTLia+vy8Xsr5g+Qw1AxnKS0unSNIvZdMaWj/zxKrYKsXn09BUJcgzg AJeRtK1zbadFVbj5Plct52/EpRjFlErLi1UlErFptYr2NRBDC8+rqRY2e73vsTar dU0n3C7W4l5mJtKvdJnVYl390RVDfF6GlYgHHVrejfj3tJXUoD620ZIQgm4tn7Um OG0P6Q9NyO7JzeVFSOcd =Q4ZE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: jax-ws and tomcat 7 with ssl
i assume they copied cacerts $JAVA_HOME\jre\lib\security? make sure validation dates are correct for Certificate a self-signed cert is designed to work on the machine where you created the cert only *CN* to implement a cert that will work on FQDN with correct dates you will need a REAL cert from verisign / thawte / DigiCert Fixing PKIX Errors: http://www.mkyong.com/webservices/jax-ws/suncertpathbuilderexception-unable-to-find-valid-certification-path-to-requested-target/ Making Self-Signed Certs http://torlanglo.wordpress.com/2008/05/03/how-to-create-a-ssl-certificate-with-custom-domain-name-for-use-in-iis7-web-sites/ Get your 'REAL CERTS' here http://safire.net/support/verisign.html Martin > Date: Tue, 18 Mar 2014 17:58:32 -0400 > From: mariacristinasi...@sourcecable.net > To: users@tomcat.apache.org > Subject: jax-ws and tomcat 7 with ssl > > Hi, > > I developed a web service using jax-ws and configured Tomcat to support > SSL connection. Here are my steps: > > ** Step 1 - Generate a self-signed server certificate > > Use JDK 1.7 keytool: > > keytool -genkey -alias trackerdev -keypass changeit -storepass changeit > -keystore D:\Tomcat7\htdkeystore\trackerdev.ks –ext san=ip:xx.x.x.xxx > > Is CN=xx.x.x.xxx, OU=it, O=companynamehere, L=citynamehere, > ST=provincenamehere, C=ca correct? > [no]: yes > > ** Step 2 – Configure Tomcat to support SSL connection > > On the dev server: > > Modify TOMCAT_HOME\conf\server.xml by adding the following block where > keystoreFile and keystorePass are set to values from the previous step: > > maxThreads="150" scheme="https" secure="true" clientAuth="false" > sslProtocol="TLS" > keystoreFile="htdkeystore/trackerdev.ks" > keystorePass="changeit" /> > > ** Step 3 - Export the generated server certificate to a > certificate file > > On the dev server: > > keytool –export -alias trackerdev -storepass changeit –file > D:\Tomcat7\htdkeystore\serverdev.cer -keystore > D:\Tomcat7\htdkeystore\trackerdev.ks > > ** Step 4 - Import the server certificate into the truststore file > (Open an administrator cmd window and hit Shift, Ctrl, Enter) > > Copy serverdev.cer from the dev server and on the local machine: > > keytool –import –v –trustcacerts –alias trackerdev –file > C:\fromdevserver\serverdev.cer –keystore "C:\Program > Files\Java\jdk1.7.0_51\jre\lib\security\cacerts" -keypass changeit > -storepass changeit > > Trust this certificate? [no]: yes > > ** Step 5 – Modify webapps’s web.xml > > Add the following: > > > com.sun.xml.ws.transport.http.servlet.WSServletContextListener > > > > tracker > > com.sun.xml.ws.transport.http.servlet.WSServlet > > > > tracker > /tracker > > > > securedapp > /tracker > > > CONFIDENTIAL > > > > ** MY QUESTION IS THIS: > > I tested the web service using https and it worked for me. I provided > another team with my server certificate so that they could add it to > their truststore file but I have no idea if they did or not. All I know > is that they got an error loading the wsdl. The exception they got was: > > Error loading [https://xx.x.x.xxx:8444/appname/tracker?wsdl] > org.apache.xmlbeans.XmlException: javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to > find valid certification path to requested target > > They claim that the certificate is not properly signed. Well, I don't > know. It is a self-signed certificate. > > Any ideas would help! > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: jax-ws and tomcat 7 with ssl
2014-03-18 22:58 GMT+01:00 Maria Cristina Siena : > Hi, > > I developed a web service using jax-ws and configured Tomcat to support SSL > connection. Here are my steps: > > ** Step 1 - Generate a self-signed server certificate > > Use JDK 1.7 keytool: > > keytool -genkey -alias trackerdev -keypass changeit -storepass changeit > -keystore D:\Tomcat7\htdkeystore\trackerdev.ks -ext san=ip:xx.x.x.xxx > > Is CN=xx.x.x.xxx, OU=it, O=companynamehere, L=citynamehere, > ST=provincenamehere, C=ca correct? > [no]: yes > > ** Step 2 - Configure Tomcat to support SSL connection > > On the dev server: > > Modify TOMCAT_HOME\conf\server.xml by adding the following block where > keystoreFile and keystorePass are set to values from the previous step: > > maxThreads="150" scheme="https" secure="true" clientAuth="false" > sslProtocol="TLS" >keystoreFile="htdkeystore/trackerdev.ks" > keystorePass="changeit" /> > > ** Step 3 - Export the generated server certificate to a certificate > file > > On the dev server: > > keytool -export -alias trackerdev -storepass changeit -file > D:\Tomcat7\htdkeystore\serverdev.cer -keystore > D:\Tomcat7\htdkeystore\trackerdev.ks > > ** Step 4 - Import the server certificate into the truststore file (Open > an administrator cmd window and hit Shift, Ctrl, Enter) > > Copy serverdev.cer from the dev server and on the local machine: > > keytool -import -v -trustcacerts -alias trackerdev -file > C:\fromdevserver\serverdev.cer -keystore "C:\Program > Files\Java\jdk1.7.0_51\jre\lib\security\cacerts" -keypass changeit > -storepass changeit > > Trust this certificate? [no]: yes > > ** Step 5 - Modify webapps's web.xml > > Add the following: > > > > com.sun.xml.ws.transport.http.servlet.WSServletContextListener > > > > tracker > > com.sun.xml.ws.transport.http.servlet.WSServlet > > > > tracker > /tracker > > > > securedapp > /tracker > > > CONFIDENTIAL > > > > ** MY QUESTION IS THIS: > > I tested the web service using https and it worked for me. I provided > another team with my server certificate so that they could add it to their > truststore file but I have no idea if they did or not. All I know is that > they got an error loading the wsdl. The exception they got was: > > Error loading [https://xx.x.x.xxx:8444/appname/tracker?wsdl] > org.apache.xmlbeans.XmlException: javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > > They claim that the certificate is not properly signed. Well, I don't know. > It is a self-signed certificate. > > Any ideas would help! > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > I guess that they must add your PK certificate to their keystore. Ask them Read the next link ( in Spanish ): http://danielriab.wordpress.com/2012/08/13/java-pkix-path-building-failed/ Regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
jax-ws and tomcat 7 with ssl
Hi, I developed a web service using jax-ws and configured Tomcat to support SSL connection. Here are my steps: ** Step 1 - Generate a self-signed server certificate Use JDK 1.7 keytool: keytool -genkey -alias trackerdev -keypass changeit -storepass changeit -keystore D:\Tomcat7\htdkeystore\trackerdev.ks –ext san=ip:xx.x.x.xxx Is CN=xx.x.x.xxx, OU=it, O=companynamehere, L=citynamehere, ST=provincenamehere, C=ca correct? [no]: yes ** Step 2 – Configure Tomcat to support SSL connection On the dev server: Modify TOMCAT_HOME\conf\server.xml by adding the following block where keystoreFile and keystorePass are set to values from the previous step: maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="htdkeystore/trackerdev.ks" keystorePass="changeit" /> ** Step 3 - Export the generated server certificate to a certificate file On the dev server: keytool –export -alias trackerdev -storepass changeit –file D:\Tomcat7\htdkeystore\serverdev.cer -keystore D:\Tomcat7\htdkeystore\trackerdev.ks ** Step 4 - Import the server certificate into the truststore file (Open an administrator cmd window and hit Shift, Ctrl, Enter) Copy serverdev.cer from the dev server and on the local machine: keytool –import –v –trustcacerts –alias trackerdev –file C:\fromdevserver\serverdev.cer –keystore "C:\Program Files\Java\jdk1.7.0_51\jre\lib\security\cacerts" -keypass changeit -storepass changeit Trust this certificate? [no]: yes ** Step 5 – Modify webapps’s web.xml Add the following: com.sun.xml.ws.transport.http.servlet.WSServletContextListener tracker com.sun.xml.ws.transport.http.servlet.WSServlet tracker /tracker securedapp /tracker CONFIDENTIAL ** MY QUESTION IS THIS: I tested the web service using https and it worked for me. I provided another team with my server certificate so that they could add it to their truststore file but I have no idea if they did or not. All I know is that they got an error loading the wsdl. The exception they got was: Error loading [https://xx.x.x.xxx:8444/appname/tracker?wsdl] org.apache.xmlbeans.XmlException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target They claim that the certificate is not properly signed. Well, I don't know. It is a self-signed certificate. Any ideas would help! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Possible Tomcat 8.0.3 issue
Yes, I started to use it when I migrated from Tomcat 6 to 7. 2014-03-17 17:21 GMT-03:00 Howard W. Smith, Jr. : > On Mon, Mar 17, 2014 at 4:14 PM, Felipe Jaekel wrote: > > > My Tomcat 7 was running fine with this script, but last friday morning I > > started Tomcat 8 setting only this: > > *-Xms2048m -Xmx2048m -XX:MaxPermSize=1024m > > -Dorg.apache.el.parser.COERCE_TO_ZERO=false* > > and the applications crashed too. > > > > So I'd say that the problem is not my JVM config, but I'm interested on > > improving it. What arguments do you recommend to tune GC? > > > > Last friday afternoon I created a new Amazon EC2 instance with Tomcat 7 > to > > check, and the problem is still there, so It was a damn coincidence that > > this problem started after I migrate to Tomcat 8. As I had a connection > > pool leak with Tomcat 8 it contributed for me to think that it could be > > > > Was the following in your Tomcat7 config before 'and' after migrating to > tomcat8? > > -Dorg.apache.el.parser.COERCE_TO_ZERO=false* >
Re: [Off Topic] Forwarding tomcat logs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dan, On 3/18/14, 10:40 AM, Daniel Mikusa wrote: > On Mar 18, 2014, at 10:13 AM, Randeep > wrote: > >> Hi, >> >> I have servers in Amazon Web Services Platform. >> >> My servers are Centos 5.4 >> >> I have httpd-2.2+mod_jk+tomcat-6.0.37 stack on them >> >> I'm using elastic load balancer with autoscaling, so, many >> instances can spawn and terminate anytime. But once the instance >> is terminated tomcat logs of that instance is no more available. >> >> I was trying to forward httpd > > ErrorLog supports sending logs to syslog. > > http://httpd.apache.org/docs/2.2/mod/core.html#errorlog +1 Syslog is pretty much the answer to the whole question. > I’m not sure about CustomLog. That might take a little more work. > Are you trying to send access logs as well? > >> and Apache tomcat logs > > First thing that comes to mind here is using Log4j and it’s syslog > appender. +1 I believe there is a syslog plug-in for JULI as well. Not supported here but I believe it works. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKJ8vAAoJEBzwKT+lPKRY088QAKwvUu4Tm3Mbf+VDMScpHdDe gvJBRmpNgBxEYUh3FC5TUyngrQGiKy24jxeMSvBbcsipZQRPb56n1/G1SoFVewYm +ty6XPngdTLtU8SylLTlB0rKOB/VaZGccmXgiY6wAwRjJwoEMBT/OYXaAfJdCRNV Jnrr2SaDidLxMpdiIC2Wh5lDdPeOtMAadLB3Q7dUGM0SY63a3MXKfHxx+f8VDy/t 57VzGc125U4f9HGyA7JFHcb1cxi6OJjJ8SwwkGtwpGKlPmk8Ut6qcn5zR5D73M+5 R6YHPcMN804n7M/8mgbVYCKVmkLnmT/eE5wPfxX9ucJDRSZ1CHLBWr828/2BkA/e JhEsh85tNqOkWbZ8G7VglA3NhHoIPiy2/Isr9Ig+kPR8HxoenQ9yrRxsEs38Y02P DVP53wx0QxuTYpraFkvPROl1riY2U18tglPZBRjaAg84lKq9RsiIhLPLKY9DM/PS GeDfa/MZZUJZLv1iBsO6COIiHdfwZ11S0aXGVB0BsH9vbUR4i1Se9CYxXCq8ph6G Ki5CU1HJ3NaF4gQU8eIP3U+BZRe4gxQkfFQISTQ5++w9qIQZ/yW9LGbwFdRaZ9tG /EyF8cLM6RD/uqLk6Dp3MZN8iyB+LZ3MRwode5ndZd8M41SIwcTuGXDw6cA0hwO0 ZajYkHWhEcjx+bIYrUfx =KVxw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Off Topic] Forwarding tomcat logs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Randeep, On 3/18/14, 10:13 AM, Randeep wrote: > I have servers in Amazon Web Services Platform. > > My servers are Centos 5.4 > > I have httpd-2.2+mod_jk+tomcat-6.0.37 stack on them > > I'm using elastic load balancer with autoscaling Each server is running httpd+tomcat? Do you actually need httpd in there for anything? If not, remove it and simplify your life. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKJ7hAAoJEBzwKT+lPKRYo2cQAIiZL+K+YbjDFgRns8+xMmLP OIm/nU7/4e5pXS7YTn9k0W4l0rpJns6/hPtbWNhD/5zrTdz5ZnfAsr6IuQCDoJen dRxx1LuWXz3GjFVjqSJ0hXP7sSzPwCWZuNvfLO4eHYf1ow8wPcavS0mFr7t9QtdO rMmssRnUPtTCBr7KGuQEf+d62guqAvweA8DOEUOfHGlBWXm3b+DuQp9qK9oGWPvF uiuF4A+w3uWmSgA3B2Cs2X2FwM4aJ/tztGAOHekmNKimc1JYDRd60gB1iDenFc4s JxOEjqqjqDG99NCDrwS0cjEQRPJA5G6uhaTZ6DLWJCfUgvXp2TjURpkPQjv6ssJV PKMau+8niuAIWO+sBn4tSekNIa3hZlm5e+uoFKyO8/vUsX5nEvYKggAlN14ja7Ja AJ/D70otmD49UoeG4QwE8cpTMRp2pOmCmggHCRnYkGxWyZWvADPs07ZD+cgF/7m0 vf89aNQzbXursX1MAM0kjTWWcb092G6JOIyUjG8j2ZIUjNOxQztJ0zkSqtyNgAd+ gVTG3USil3U6xAnod1gjJZvOW82imMc7el/d42K0dOm5fDtg6Gv4aZE5T8b8D7Du HUqX6MdjiEpXnpDtfUdZHFDnzLjLWNf2PoG/PeBfqlOLe5UmPnLnnUCMseIn0Dkh mF499Ym4cxYxBF33KrjD =wQd1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat-native libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Randeep, On 3/18/14, 10:27 AM, Randeep wrote: >> I'm not sure about what kind of connector I'm using. This is my >> configuration. > >> httpd-2.2.3-65.el5.centos + tomcat-connectors-1.2.28-src + >> tomcat-connectors-1.2.28-src > >> [root@server tomcat-connectors-1.2.28-src]# cat >> /etc/httpd/conf.d/mod_jk.conf JkWorkersFile >> /etc/httpd/conf.d/workers.properties JkLogFile >> /var/log/httpd/mod_jk.log JkLogLevel info JkLogStampFormat "[%a >> %b %d %H:%M:%S %Y] " JkOptions +ForwardKeySize +ForwardURICompat >> -ForwardDirectories JkRequestLogFormat "%w %V %T" JkMount /* >> worker1 JkShmFile /etc/httpd/logs/jk-runtime-status Assuming that this is the only configuration you have in httpd.conf, then you are using mod_jk (and not mod_proxy_ajp or mod_proxy_http). >> [root@server tomcat-connectors-1.2.28-src]# cat >> /etc/httpd/conf.d/workers.properties >> workers.tomcat_home=/usr/share/apache-tomcat-6.0.37/ >> workers.java_home=/usr/java/default You don't need "java_home". >> ps=/ You don't need "ps". >> worker.list=worker1 worker.default.port=8009 >> worker.default.host=localhost worker.default.type=ajp13 > >> Is there anyway to check which type is this NIO or BIO? The from Tomcat's server.xml will tell you that, unless you have left the default in which case it depends upon whether you have APR available or not. Since the whole thread started with you saying you didn't have APR, it's likely that it's /not/ available and therefore you likely have the default BIO connector. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKJ6dAAoJEBzwKT+lPKRYpi8QAKrcux1ROhOTnlB4zhnobLFK BjYrggkOddrzQoncePN/4vcZeKssBlzNNNu2JD6OzDmax3vhms/y6Fhn9x3dYwFm MKDySqHdNiPqe5b33n/vIPg5gqiZlHDh+AzOwW3mG83rI0S8NFt2zIq3EY5pX915 uu31kISNWR7/W4nFGqngg8lGT6VH0qLXOpjLKCe+AwMIhtgIarfoZ1UZkZbbgBXq wE0gKC7xO+nCs+nC0Rovadne9nQRLIBjxtqfl8w2+YfuSmanpZ/ar+utAh51xi7X XCeJP6gKXh+gYZLcauHEyKKVwdHPquJn/p0k8HMNoEkNTYauykwIBcU2GPxlqcPI 4rE80edoCkIth+RuccnD9xG5Db8QiYDT9Q5Fea9klbs3VwK36FXeLAHiKo3UV4Xg yZDO2yqEDTdQwNXI1IldMUh9yA7jatvYUg83vL1C11W45dCm7ZHmKeb3GBIF6ze6 mmmd0aBQ6xle9ghEU57ComPKxcJke+XST7UybIu24Ug29ig9UvgjoortMTmKJaQY 8kwwPLkfRJKsf3XZa4pMwpY3bhb2o5u6ugz7qcQz318hZUnaWi5kRsS3BJzl4H1u IXCaD1cVm8sPNWFWJexnJvwY+bLgjCI/zvyz21BwGYqkc4Z8OgQdzGkwPAzPBj9G DFQAkuNV4BK29jwuRWnl =onNP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Off Topic] Forwarding tomcat logs
On Mar 18, 2014, at 10:13 AM, Randeep wrote: > Hi, > > I have servers in Amazon Web Services Platform. > > My servers are Centos 5.4 > > I have httpd-2.2+mod_jk+tomcat-6.0.37 stack on them > > I'm using elastic load balancer with autoscaling, so, many instances can > spawn and terminate anytime. But once the instance is terminated tomcat > logs of that instance is no more available. > > I was trying to forward httpd ErrorLog supports sending logs to syslog. http://httpd.apache.org/docs/2.2/mod/core.html#errorlog I’m not sure about CustomLog. That might take a little more work. Are you trying to send access logs as well? > and Apache tomcat logs First thing that comes to mind here is using Log4j and it’s syslog appender. You can setup Tomcat to use Log4j. Instructions here. http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j Then configure an appender to use SyslogAppender. http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/SyslogAppender.html That should get you anything that would normally be written to a Tomcat log (catalina.-mm-dd.log or localhost.-mm-dd.log). It wouldn’t get you access logs or anything your apps are writing to System.out / System.err. Again, how much are you trying to send to your syslog server? Dan > to a central logging > server (splunk/graylog2). But was not able to. > > http://stackoverflow.com/questions/22293195/forwarding-logs-to-splunk-gralog-from-syslog-ng > > Has anyone done this? What is the best way to do it? > > Kindly advise. > > -- Randeep - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat-native libraries
On Tue, Mar 18, 2014 at 7:29 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Randeep, > > On 3/18/14, 9:46 AM, Randeep wrote: > > On Tue, Mar 18, 2014 at 7:13 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > John, > > > > On 3/17/14, 9:52 AM, John Smith wrote: > > > > > > Installing the native library will make a difference. > > Whether the difference is large enough to notice depends > > very much on your application. If you want to improve your > > application's performance I suspect your time would be > > better spent with a profiler to see where the bottlenecks > > are in your application. > > > > Mark > > > > +1 I had the native APR installed and ended up removing it in > favor of keeping things simple. The NIO connector often > recommended by Chris S. and others works very well. > > > > It's also a big "safer" in that obscure problems rarely bring-down > > the JVM, whereas a bug in tcnative/apr/openssl can kill the entire > > JVM without warning. > > > > Using APR really only makes sense if you are using Tomcat directly > > as a web server that uses SSL, since there is a measurable > > difference between OpenSSL's performance and JSSE's performance. > > > > -chris > > > > > >> Thank you Chris, In that case, I'm not going to use it. I was > >> using httpd as front end to server ssl certificates. Now load > >> balancer is handling it. > > Stick with the NIO connector. If you are using AJP to connect httpd to > Tomcat, you will probably be better off with the BIO connector, > actually. It's simpler and basically bug-free given its maturity. > Since there is a 1:1 map between Tomcat and httpd connections, there's > no really good reason to switch to another connector IMO. > > - -chris > Chris, I'm not sure about what kind of connector I'm using. This ismy configuration. httpd-2.2.3-65.el5.centos + tomcat-connectors-1.2.28-src + tomcat-connectors-1.2.28-src [root@server tomcat-connectors-1.2.28-src]# cat /etc/httpd/conf.d/mod_jk.conf JkWorkersFile /etc/httpd/conf.d/workers.properties JkLogFile /var/log/httpd/mod_jk.log JkLogLevel info JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkRequestLogFormat "%w %V %T" JkMount /* worker1 JkShmFile /etc/httpd/logs/jk-runtime-status [root@server tomcat-connectors-1.2.28-src]# cat /etc/httpd/conf.d/workers.properties workers.tomcat_home=/usr/share/apache-tomcat-6.0.37/ workers.java_home=/usr/java/default ps=/ worker.list=worker1 worker.default.port=8009 worker.default.host=localhost worker.default.type=ajp13 Is there anyway to check which type is this NIO or BIO? -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTKFFMAAoJEBzwKT+lPKRYS74P/1UkDakuqDz6LyLUaBeTzcXl > R/2eliStJMAE146C6QpE2YBV4w2dyh/xEnndRmbE3R3NE9cD3yUom+VO7x1OOgL9 > ODM8Ry5AWXBXqhjx2k4hjRM43Hza6Z+GJYb9RutdLj71GCU4fEFrTX23sCAkUKbx > nzCGMG4robj7l6TDSdK6uZpmisV7LGBWsUIjkJnTX5AvxFhU5QsFOISE/osFAy6I > ukw840t57BCJ0mlIV/EBORa+0BCO+lz7ZBk+kkwHG5mSXFapTqNcySKfYGEzkVmD > 8OHBJehmkqHfBuqgiavIwpLZ3wZnLcrJpsMzdxGUG1wuuFVtr1aRZ+h/L+/diUnE > B37m9fOuwd3RfY7uhJXATiYo8oW5nB/EOIYuKDsfgMi7eY/NBg2r8Rw7MHYLJUuN > lXtHJTyyBLQcgw5twnTbdA5MPbdgjZ2A2uw6sKCf5/vNyZBkGky+6Fush9cMRIL/ > zdmNyJCCP9jzBOltFl0NNW/bpI1UKpMk8bScJZvAC3JNvMt1FCu3e4rQmqJXlzwG > yBIQeqoIHpogLbF5CxGcOUJGV80O0o5vq+N2qt7TArqOHEifGhroVAQPEOtYmI/K > x7u4Xv+VPg19YmRS6PJCYkYw082vFbmanXjt7BgmUWNs3WD1ooe66bmWPzKX3btA > HcuHDQFgyaGQu0z55MYP > =Vqt8 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Randeep Mob: +919447831699[kerala] Mob: +919880050349[B'lore] I blog here: http://www.randeeppr.me/ Follow me Here: http://twitter.com/Randeeppr Poke me here! http://www.facebook.com/Randeeppr A little Linux Help http://www.linuxhelp.in/ Work profile: http://in.linkedin.com/in/randeeppr
[Off Topic] Forwarding tomcat logs
Hi, I have servers in Amazon Web Services Platform. My servers are Centos 5.4 I have httpd-2.2+mod_jk+tomcat-6.0.37 stack on them I'm using elastic load balancer with autoscaling, so, many instances can spawn and terminate anytime. But once the instance is terminated tomcat logs of that instance is no more available. I was trying to forward httpd and Apache tomcat logs to a central logging server (splunk/graylog2). But was not able to. http://stackoverflow.com/questions/22293195/forwarding-logs-to-splunk-gralog-from-syslog-ng Has anyone done this? What is the best way to do it? Kindly advise. -- Randeep
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Any update on this Chris Schultz or anyone else? I know the images I added to
the email didn't show up, so if you want me to email them directly to you, I
can.
Could really do with help on this, as it is not something I know much about.
Thanks
Seema
> From: seema...@hotmail.com
> To: users@tomcat.apache.org
> Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
> Date: Fri, 14 Mar 2014 15:15:04 +
>
>
>
> > Date: Fri, 14 Mar 2014 08:36:08 -0400
> > From: ch...@christopherschultz.net
> > To: users@tomcat.apache.org
> > Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Seema,
> >
> > On 3/14/14, 7:53 AM, Seema Patel wrote:
> > > I have upgraded my tomcat (5.5.29 to 7.0.52) and Java (1.5 to 1.7)
> > > for my struts servlet jsp application. I have also removed all
> > > JCIFS authentication from the WEB-INF/web.xml file and have tried
> > > to do BASIC authentication through Tomcat and the AD (it
> > > authenticates me, but not sure if I've missed anything out, as I've
> > > never done this before).
> >
> > One question at a time, please ;)
>
> Sorry for the off-loading of multiple questions :-)
>
> >
> > > I have a doFilter function in my code, which contains
> > > httpServletRequest.getServletPath() call. In the Tomcat 5.5.29 Java
> > > 1.5 version, this will work, as when I print
> > > httpServletRequest.getServletPath() i get the following:
> > >
> > > P1_00.do P5_0_0.do P5_0_1.do
> > >
> > > But in Tomcat 7.0.52 Java 1.7 I get the following from
> > > httpServletRequest.getServletPath() call:
> > >
> > > P1_00.do P5_0_0.do P5_0_1.do includes/tab_defaultsettings.jsp
> > > includes/P1_00.do
> >
> > How are you printing this? Do you just have a Filter that wraps
> > everything and dumps-out the ServletPath for every request? Can you
> > post the code for that Filter as well as the and
> > configuration you have in web.xml?
> >
>
> I'm just doing a System.out.println() in the doFilter function in the
> RequestFilter class to show which page it is. The doFilter function is:
>
>
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws IOException, ServletException {
> if (request instanceof HttpServletRequest) {
> final HttpServletRequest httpRequest =
> (HttpServletRequest)request;
> final Object userBeanObject =
> httpRequest.getSession().getAttribute(GenConstants.LOGGED_IN_USER_BEAN);
> final String pageName =
> httpRequest.getServletPath().replaceAll("/","");
> System.out.println("Request Page = " +
> httpRequest.getServletPath());
> if (unsecuredPages.contains(pageName)) {
> // don't need any protection
> chain.doFilter(request, response);
> } else if (!(userBeanObject instanceof UserBean)) {
> // no user bean in session do need one, invalidate session
> and redirect to login
> if (httpRequest.getSession(false) != null) {
> httpRequest.getSession().invalidate();
> }
> ((HttpServletResponse)response).sendRedirect(logonPage);
> } else {
> final UserBean user = (UserBean) userBeanObject;
> Map permissions =
> (Map)context.getAttribute(GenConstants.PERMISSIONS_MAP);
> if(permissions == null) {
> PermissionsUtil.setupPermissions(context);
> permissions =
> (Map)context.getAttribute(GenConstants.PERMISSIONS_MAP);
> }
> final LogicalOperation requiredOp =
> permissions.get(pageName.replaceAll("\\.do",""));
> if (user.isOperationAllowed(requiredOp)) {
> chain.doFilter(request, response);
> } else {
> if (httpRequest.getSession(false) != null) {
> httpRequest.getSession().invalidate();
> }
> ((HttpServletResponse)response).sendRedirect(logonPage);
> }
> }
> }
> }
>
> To give you a better idea of what was in the web.xml, here is what's been
> taken out:
>
>
> NtlmHttpFilter
> jcifs.http.NtlmHttpFilter
>
> jcifs.smb.client.soTimeout
> 3
>
>
>
>
> jcifs.smb.client.domain
> XXX.LOCAL
>
>
>
> jcifs.smb.client.username
> username
>
>
> jcifs.smb.client.password
> password
>
>
>
> jcifs.util.loglevel
> 2
>
>
>
> jcifs.http.insecureBasic
> true
>
>
>
>
> NtlmHttpFilter
> *.do
>
>
> NtlmHttpFilter
> *.jsp
>
>
Re: tomcat-native libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Randeep, On 3/18/14, 9:46 AM, Randeep wrote: > On Tue, Mar 18, 2014 at 7:13 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > John, > > On 3/17/14, 9:52 AM, John Smith wrote: > > > Installing the native library will make a difference. > Whether the difference is large enough to notice depends > very much on your application. If you want to improve your > application's performance I suspect your time would be > better spent with a profiler to see where the bottlenecks > are in your application. > > Mark > +1 I had the native APR installed and ended up removing it in favor of keeping things simple. The NIO connector often recommended by Chris S. and others works very well. > > It's also a big "safer" in that obscure problems rarely bring-down > the JVM, whereas a bug in tcnative/apr/openssl can kill the entire > JVM without warning. > > Using APR really only makes sense if you are using Tomcat directly > as a web server that uses SSL, since there is a measurable > difference between OpenSSL's performance and JSSE's performance. > > -chris > > >> Thank you Chris, In that case, I'm not going to use it. I was >> using httpd as front end to server ssl certificates. Now load >> balancer is handling it. Stick with the NIO connector. If you are using AJP to connect httpd to Tomcat, you will probably be better off with the BIO connector, actually. It's simpler and basically bug-free given its maturity. Since there is a 1:1 map between Tomcat and httpd connections, there's no really good reason to switch to another connector IMO. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKFFMAAoJEBzwKT+lPKRYS74P/1UkDakuqDz6LyLUaBeTzcXl R/2eliStJMAE146C6QpE2YBV4w2dyh/xEnndRmbE3R3NE9cD3yUom+VO7x1OOgL9 ODM8Ry5AWXBXqhjx2k4hjRM43Hza6Z+GJYb9RutdLj71GCU4fEFrTX23sCAkUKbx nzCGMG4robj7l6TDSdK6uZpmisV7LGBWsUIjkJnTX5AvxFhU5QsFOISE/osFAy6I ukw840t57BCJ0mlIV/EBORa+0BCO+lz7ZBk+kkwHG5mSXFapTqNcySKfYGEzkVmD 8OHBJehmkqHfBuqgiavIwpLZ3wZnLcrJpsMzdxGUG1wuuFVtr1aRZ+h/L+/diUnE B37m9fOuwd3RfY7uhJXATiYo8oW5nB/EOIYuKDsfgMi7eY/NBg2r8Rw7MHYLJUuN lXtHJTyyBLQcgw5twnTbdA5MPbdgjZ2A2uw6sKCf5/vNyZBkGky+6Fush9cMRIL/ zdmNyJCCP9jzBOltFl0NNW/bpI1UKpMk8bScJZvAC3JNvMt1FCu3e4rQmqJXlzwG yBIQeqoIHpogLbF5CxGcOUJGV80O0o5vq+N2qt7TArqOHEifGhroVAQPEOtYmI/K x7u4Xv+VPg19YmRS6PJCYkYw082vFbmanXjt7BgmUWNs3WD1ooe66bmWPzKX3btA HcuHDQFgyaGQu0z55MYP =Vqt8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 : Configure redirect url for session timeout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 3/18/14, 7:31 AM, chris derham wrote: >> It is not feasible to determine the difference between a >> timed-out session and a user who had no session to begin with. > > Couldn't you use the presence/absence of a session id cookie? Not really. What's the difference between a JSESSIONID being there 2 minutes after a /true/ session time-out versus one that the client is sending 30 days after the session time out? There are so many reasons that the client and server can get out of sync with (non-stored, as is the default) cookies that you really can't make any real guesses about the true state of the world. All you know is that a client-requested session id does match a currently-valid session. Remember that you can't trust anything that the client sends you, really. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKFDkAAoJEBzwKT+lPKRYLFgQAI3FNdNfzBr2THuHCZAi4dfh 7JdMEQh8QJGXyPOAYirnhJIiiS2aoGhjHMwq8h6FLj+Jfd84pFUYHQytGww0rSqS bqZxQbaEePNT58AHqzKwzl+NfNDTac6A978mtXJJ9OpPgxVzexkHjGoP1b/yDtFI CL1PRudg+yO1IbNHSKsSqADoVv+sMR2YuiXB4+0HaHIXGGORbQoAFBeiChHcsAzX JXskHUicFzs6oemlAtttc44seCuDwx8mDcKnid0Ad8P2vgtWxKvu6cvYEPWOuEYU asptvvUNipcfaMU+d3fgaWAj184EXL8jO0krmbT/gPNW1C39WNGBXfvEZiNfNrwk CeH3foQT19uNG+OGTlUZc/eR64g7vMWY4caxLJUm3fXi2Z4PZeFPE5nYoDuKHn6L tF2hyyp8pLxbeCC6vkqh3oBElz/LdgCSSyz314HIC/OO5z6T9FzMWT+HtzVLOkFA 5wCkHswh1OED083Q2ysaGVtbg3A39hYWDN3MxfIpmFZB1kFyZopStvqf5dlBwukH m/6+iuwAdj/aMvhcmk8EJ6NcC0hGw+Jp71/pe0QsBx9uV9FhaC4Nkf50qpB/bGtn mEmOSEHHKRmEaOpQswIv1IfRaUOCCmLA9rCT8osmxzfaWc7ddMKS/GS7rWTKLNZh MxERN0TUbkdnjJv1ngfL =Jzjq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat-native libraries
On Tue, Mar 18, 2014 at 7:13 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > John, > > On 3/17/14, 9:52 AM, John Smith wrote: > >> > >> > >> Installing the native library will make a difference. Whether > >> the difference is large enough to notice depends very much on > >> your application. If you want to improve your application's > >> performance I suspect your time would be better spent with a > >> profiler to see where the bottlenecks are in your application. > >> > >> Mark > >> > > > > +1 I had the native APR installed and ended up removing it in favor > > of keeping things simple. The NIO connector often recommended by > > Chris S. and others works very well. > > It's also a big "safer" in that obscure problems rarely bring-down the > JVM, whereas a bug in tcnative/apr/openssl can kill the entire JVM > without warning. > > Using APR really only makes sense if you are using Tomcat directly as > a web server that uses SSL, since there is a measurable difference > between OpenSSL's performance and JSSE's performance. > > - -chris > Thank you Chris, In that case, I'm not going to use it. I was using httpd as front end to server ssl certificates. Now load balancer is handling it. -Randeep -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTKE1nAAoJEBzwKT+lPKRYtq8P/2VBOytTaDZ7Tg7jDWXkBYl3 > nky5nQB1YqMiFnMaSEFuy7z84CEEPKOclQd1qU7GSbvdTL2pKUXhkYo5UCgUxElb > prsiaoMqx4YjCF3XY3231TKCE1v9MgkcGsdFbDu9m4eeyUP+U+R9obh02CsfeHqP > zs+/5eglbfYLeTfxKoJviE+uWOqAbkPD/j9hHJNG2TNme+ognYMshFiAjyEVI0AN > kz+8eoTMabL3mM6echZwwZhfGtMx7xM7oVL+kgdFvwE93iw/JopUyQa0O0znFJ9S > mITnnmjnuFH9J7Ktm96STcJ0VCFy+qmM3+/p0wZOFlh5EWczomcvTMtQIjh2nVzK > CWeLxQlifZoSqIO/zADg79PCJHPnpT8p3woV7Q4Dwb7PmTToKvpZLhday84U7mQG > ue6f3jWaqb93zN8K3qJJll8MT/WqTR84lEeKaVfW3hJevWB0Ym70kGLAcRGgC9fk > f3necQBAhg9B5a0OAPc/+W2b3RrPmQ9NnTTBBzDWxRBmXeBvpkZMLzTZPnZ42VvW > z2HMucc+izlv/43Iz1afeXJI0CyJ+ATtVjfwJdC4/jHYk8p7kjcD61QVjPqh0MtH > Aoa8IvsDBl6K+dOyJ3qOzDpfCMc60491TNGLTojtvNAgNwXOKijLYUTwnqzt5I2F > 8MDbrI2Mj7LYnlPGsIHA > =mCrR > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Randeep Mob: +919447831699[kerala] Mob: +919880050349[B'lore] I blog here: http://www.randeeppr.me/ Follow me Here: http://twitter.com/Randeeppr Poke me here! http://www.facebook.com/Randeeppr A little Linux Help http://www.linuxhelp.in/ Work profile: http://in.linkedin.com/in/randeeppr
Re: tomcat-native libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 3/17/14, 9:52 AM, John Smith wrote: >> >> >> Installing the native library will make a difference. Whether >> the difference is large enough to notice depends very much on >> your application. If you want to improve your application's >> performance I suspect your time would be better spent with a >> profiler to see where the bottlenecks are in your application. >> >> Mark >> > > +1 I had the native APR installed and ended up removing it in favor > of keeping things simple. The NIO connector often recommended by > Chris S. and others works very well. It's also a big "safer" in that obscure problems rarely bring-down the JVM, whereas a bug in tcnative/apr/openssl can kill the entire JVM without warning. Using APR really only makes sense if you are using Tomcat directly as a web server that uses SSL, since there is a measurable difference between OpenSSL's performance and JSSE's performance. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKE1nAAoJEBzwKT+lPKRYtq8P/2VBOytTaDZ7Tg7jDWXkBYl3 nky5nQB1YqMiFnMaSEFuy7z84CEEPKOclQd1qU7GSbvdTL2pKUXhkYo5UCgUxElb prsiaoMqx4YjCF3XY3231TKCE1v9MgkcGsdFbDu9m4eeyUP+U+R9obh02CsfeHqP zs+/5eglbfYLeTfxKoJviE+uWOqAbkPD/j9hHJNG2TNme+ognYMshFiAjyEVI0AN kz+8eoTMabL3mM6echZwwZhfGtMx7xM7oVL+kgdFvwE93iw/JopUyQa0O0znFJ9S mITnnmjnuFH9J7Ktm96STcJ0VCFy+qmM3+/p0wZOFlh5EWczomcvTMtQIjh2nVzK CWeLxQlifZoSqIO/zADg79PCJHPnpT8p3woV7Q4Dwb7PmTToKvpZLhday84U7mQG ue6f3jWaqb93zN8K3qJJll8MT/WqTR84lEeKaVfW3hJevWB0Ym70kGLAcRGgC9fk f3necQBAhg9B5a0OAPc/+W2b3RrPmQ9NnTTBBzDWxRBmXeBvpkZMLzTZPnZ42VvW z2HMucc+izlv/43Iz1afeXJI0CyJ+ATtVjfwJdC4/jHYk8p7kjcD61QVjPqh0MtH Aoa8IvsDBl6K+dOyJ3qOzDpfCMc60491TNGLTojtvNAgNwXOKijLYUTwnqzt5I2F 8MDbrI2Mj7LYnlPGsIHA =mCrR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 : Configure redirect url for session timeout
> It is not feasible to determine the difference between a timed-out > session and a user who had no session to begin with. Couldn't you use the presence/absence of a session id cookie? Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
