Should validationQuery commit ?
Hi, we recently switched to tomcat-jdbc-pool as our connection pool, and have since encountered performance problems with Postgresql. The problem is due to the fact that postgres is having hard time vacuuming, due to always ongoing idle transactions. See http://permalink.gmane.org/gmane.comp.db.postgresql.performance/37893 for the details. It turns out that those idle transactions were coming from tomcat pool validation queries... here is our configuration: property name=defaultAutoCommit value=false/ property name=maxActive value=30/ property name=maxIdle value=30/ property name=initialSize value=10/ property name=minIdle value=10/ property name=testOnReturn value=true/ property name=testOnBorrow value=true/ property name=validationQuery value=select 1 from rtelre/ property name=validationInterval value=0/ rtelre is a dummy table with 1 column and one row. We use it for compatibility reasons, since we deploy in several environments, and on oracle the from clause is mandatory (so select 1 does not fit). So the problem is that the select 1 from rtelre is never commited, nor rolled back. Adding a commit in the query seems to work : select 1 from rtelre; commit; does not leave idle transactions. That said, we never encountered such config example in the docs, nor on web. So here is my question(s): - is it expected that the validationQuery transaction are not terminated ? - is adding a commit (or rollback, for that matters) in the query a valid workaround, or even the only sensible configuration ? - if so, shouldn't it be mentionned somewhere in the docs ? Thanks, Franck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should validationQuery commit ?
On Apr 18, 2014, at 5:05 AM, Franck Routier franck.rout...@axege.com wrote: Hi, we recently switched to tomcat-jdbc-pool as our connection pool, and have since encountered performance problems with Postgresql. The problem is due to the fact that postgres is having hard time vacuuming, due to always ongoing idle transactions. See http://permalink.gmane.org/gmane.comp.db.postgresql.performance/37893 for the details. It turns out that those idle transactions were coming from tomcat pool validation queries... here is our configuration: property name=defaultAutoCommit value=false/ property name=maxActive value=30/ property name=maxIdle value=30/ property name=initialSize value=10/ property name=minIdle value=10/ property name=testOnReturn value=true/ property name=testOnBorrow value=true/ property name=validationQuery value=select 1 from rtelre/ property name=validationInterval value=0/ rtelre is a dummy table with 1 column and one row. We use it for compatibility reasons, since we deploy in several environments, and on oracle the from clause is mandatory (so select 1 does not fit). So the problem is that the select 1 from rtelre is never commited, nor rolled back. Adding a commit in the query seems to work : select 1 from rtelre; commit; does not leave idle transactions. That said, we never encountered such config example in the docs, nor on web. So here is my question(s): - is it expected that the validationQuery transaction are not terminated ? I don’t know what the intended behavior is here since I didn’t write the code, but given that you have set defaultAutoCommit to false, I could see this happening. - is adding a commit (or rollback, for that matters) in the query a valid workaround, or even the only sensible configuration ? Another option you might try would be to set “rollbackOnReturn to “true”. That is supposed to instruct the pool to rollback an open transactions when the connection is returned to the pool. I haven’t tried it, but it seems like it would work here. Dan - if so, shouldn't it be mentionned somewhere in the docs ? Thanks, Franck - 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: Should validationQuery commit ?
Hi, Le 18/04/2014 13:53, Daniel Mikusa a écrit : Another option you might try would be to set “rollbackOnReturn to “true”. That is supposed to instruct the pool to rollback an open transactions when the connection is returned to the pool. I haven’t tried it, but it seems like it would work here. Dan Hummm, not sure this is really what we want. The problem in not with the application returning unclosed transactions, it's rather than when the connection is returned to the pool, the pool itself will open a transaction and not close it... But I'll try it anyway. Thanks, Franck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Heartbeat Bug Update - Installation?
https://issues.apache.org/bugzilla/show_bug.cgi?id=56363 I'm somewhat new to Tomcat. What do I need to do obtain this patch / update? I'm running Apache Tomcat 7 on Windows. Keith Davis - (214) 906-5183 - http://laurinkeithdavis.com http://laurinkeithdavis.com/
Re: Should validationQuery commit ?
On Fri, 2014-04-18 at 11:05 +0200, Franck Routier wrote: property name=validationQuery value=select 1 from rtelre/ Is is possible the select just needs to be terminated with a semi-colon? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Heartbeat Bug Update - Installation?
On Apr 18, 2014, at 9:02 AM, Keith Davis laurinkeithda...@gmail.com wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=56363 I'm somewhat new to Tomcat. What do I need to do obtain this patch / update? I'm running Apache Tomcat 7 on Windows. This is a good starting point. https://wiki.apache.org/tomcat/Security/Heartbleed Dan Keith Davis - (214) 906-5183 - http://laurinkeithdavis.com http://laurinkeithdavis.com/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should validationQuery commit ?
Le 18/04/2014 13:53, Daniel Mikusa a écrit : Another option you might try would be to set “rollbackOnReturn to “true”. That is supposed to instruct the pool to rollback an open transactions when the connection is returned to the pool. I haven’t tried it, but it seems like it would work here. Ok, I tested, and you were absolutely right: rollbackOnReturn does the trick. Moreover, notice that have 'select 1 from rtelre; commit;' as a validationQuery works on Postgresql, but is categorically refused by Oracle... So using rollbackOnReturn=true works and is more portable. Thanks. nb: adding a ; as suggest by Tim does not change anything. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8 websocket example
I have downloaded the websocket example echo in the examples section of the tomcat 8 docs. I downloaded both java classes and the xhtml file and have placed all of these in my eclipse project. I then created a basic web.xml which is: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 welcome-file-list welcome-fileecho.xhtml/welcome-file /welcome-file-list /web-app I build all of this into a war with my libraries. I've stripped out the javax.websocket libraries by hand from the jar file just to get the test working. I place this in tomcat, start it, and go to: http://localhost:8080/examples/echo.xhtml. When I choose either API and click connect, it immediately responds with: Info: WebSocket connection closed, Code: 1006. Since I'm just running an example, I can't see where I've erred. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fwd: Tomcat 8 websocket example
Also, I found several examples of this same issue on stack overflow with no solutions. Original Message Subject:Tomcat 8 websocket example Date: Fri, 18 Apr 2014 12:28:56 -0400 From: Thom Hehl th...@corrisoft.com To: users@tomcat.apache.org I have downloaded the websocket example echo in the examples section of the tomcat 8 docs. I downloaded both java classes and the xhtml file and have placed all of these in my eclipse project. I then created a basic web.xml which is: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 welcome-file-list welcome-fileecho.xhtml/welcome-file /welcome-file-list /web-app I build all of this into a war with my libraries. I've stripped out the javax.websocket libraries by hand from the jar file just to get the test working. I place this in tomcat, start it, and go to: http://localhost:8080/examples/echo.xhtml. When I choose either API and click connect, it immediately responds with: Info: WebSocket connection closed, Code: 1006. Since I'm just running an example, I can't see where I've erred.
Re: Tomcat 8 websocket example
On Apr 18, 2014, at 12:28 PM, Thom Hehl th...@corrisoft.com wrote: I have downloaded the websocket example echo in the examples section of the tomcat 8 docs. I downloaded both java classes and the xhtml file and have placed all of these in my eclipse project. I then created a basic web.xml which is: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 welcome-file-list welcome-fileecho.xhtml/welcome-file /welcome-file-list /web-app I build all of this into a war with my libraries. I've stripped out the javax.websocket libraries by hand from the jar file just to get the test working. I place this in tomcat, start it, and go to: http://localhost:8080/examples/echo.xhtml. When I choose either API and click connect, it immediately responds with: Info: WebSocket connection closed, Code: 1006. Since I'm just running an example, I can't see where I've erred. This seems like way too much effort. To run the samples you only need to do this. 1.) Download Tomcat 8: https://tomcat.apache.org/download-80.cgi 2.) Extract the files. 3.) Start the Tomcat instance. 4.) Go to http://server/examples. From there click the link for WebSocket examples. It’s not necessary to download and package them yourself. Dan - 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: Tomcat 8 websocket example
Please check if you have not included websocket related jars in your application's WEB-INF/lib. if you have ,please remove as it does not initialize the websockets correctly. THey only need to be in tomcat's lib On Fri, Apr 18, 2014 at 10:17 PM, Daniel Mikusa dmik...@gopivotal.comwrote: On Apr 18, 2014, at 12:28 PM, Thom Hehl th...@corrisoft.com wrote: I have downloaded the websocket example echo in the examples section of the tomcat 8 docs. I downloaded both java classes and the xhtml file and have placed all of these in my eclipse project. I then created a basic web.xml which is: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 welcome-file-list welcome-fileecho.xhtml/welcome-file /welcome-file-list /web-app I build all of this into a war with my libraries. I've stripped out the javax.websocket libraries by hand from the jar file just to get the test working. I place this in tomcat, start it, and go to: http://localhost:8080/examples/echo.xhtml. When I choose either API and click connect, it immediately responds with: Info: WebSocket connection closed, Code: 1006. Since I'm just running an example, I can't see where I've erred. This seems like way too much effort. To run the samples you only need to do this. 1.) Download Tomcat 8: https://tomcat.apache.org/download-80.cgi 2.) Extract the files. 3.) Start the Tomcat instance. 4.) Go to http://server/examples. From there click the link for WebSocket examples. It’s not necessary to download and package them yourself. Dan - 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
comet servlet gets connected to inadvertantly
Im using tomcat7 on 64 bit ubuntu linux and java 7. I have a client software that connects to the server. For some reason, when a user logs in, in the access log, i see 3 connections, one to the version check servlet, one to the output servlet, and one to the login servlet. the output servlet should not be accessed by the client until it gets a return value from the login servlet, and im sure it happens in this order in the code. My best guess is that the request is somehow going to two servlets somehow, but i dont know if this is even possible, but I dont know what else could happen. If you are running a comet servlet next to traditional servlets, its there any chance both will get the same request?
Re: Should validationQuery commit ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dan, On 4/18/14, 7:53 AM, Daniel Mikusa wrote: On Apr 18, 2014, at 5:05 AM, Franck Routier franck.rout...@axege.com wrote: Hi, we recently switched to tomcat-jdbc-pool as our connection pool, and have since encountered performance problems with Postgresql. The problem is due to the fact that postgres is having hard time vacuuming, due to always ongoing idle transactions. See http://permalink.gmane.org/gmane.comp.db.postgresql.performance/37893 for the details. It turns out that those idle transactions were coming from tomcat pool validation queries... here is our configuration: property name=defaultAutoCommit value=false/ property name=maxActive value=30/ property name=maxIdle value=30/ property name=initialSize value=10/ property name=minIdle value=10/ property name=testOnReturn value=true/ property name=testOnBorrow value=true/ property name=validationQuery value=select 1 from rtelre/ property name=validationInterval value=0/ rtelre is a dummy table with 1 column and one row. We use it for compatibility reasons, since we deploy in several environments, and on oracle the from clause is mandatory (so select 1 does not fit). So the problem is that the select 1 from rtelre is never commited, nor rolled back. Adding a commit in the query seems to work : select 1 from rtelre; commit; does not leave idle transactions. That said, we never encountered such config example in the docs, nor on web. So here is my question(s): - is it expected that the validationQuery transaction are not terminated ? I don’t know what the intended behavior is here since I didn’t write the code, but given that you have set defaultAutoCommit to false, I could see this happening. +1 Also note that setting defaultAutoCommit=false changes the driver to be different than the JDBC spec default. That may confuse some Java programmers. - is adding a commit (or rollback, for that matters) in the query a valid workaround, or even the only sensible configuration ? Another option you might try would be to set “rollbackOnReturn to “true”. That is supposed to instruct the pool to rollback an open transactions when the connection is returned to the pool. I haven’t tried it, but it seems like it would work here. It might not, if the connection isn't being returned to the pool, since it's just being checked. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTUXJhAAoJEBzwKT+lPKRYvNQP/Ak2BPOwiW+xdCv99KKObYs7 232psJaox7GZg08Rn28Omyoqjzp+OmAUfT0iAy5cGKfRpX2+4SAQ4uG7qYyLEOkn jMy7tTk8B/V2ezuhLpxprXGOW6PT35xfEmakrDGMm6VrRwynZTUwVHDO9wijye8P 2kBETWUUwP1ML5u5bZzJ+yvFBBcpQZsMoo40jLvC0txTo0QzaJDfglLaZKa0+Xlv DYnseBcSvsuRnmJiLRSrVo3OcToTPzSERP8Rnn4adgSTISrbuKNmLrpIdtsCF+aO vxhTlJlfcK/ndl1+Kwin+kuMMbOAezzHpLcJnlmeZ+56MXsgjSF1W1ZBVsfosPZ2 gwVwmQCpQpRP3bNZPUXNtHCvXbIVKqF2PN6ExD4x34rtn+BE7St3Cv+Hyg36mrER 8O62t1y0fkk92S9vkGREVdtCw6XzwD6gApBunDtKqlilomjbwnf4FICfm+Oe4vgl EaTHLnKMlhzVhwWcXuHHyihGQysFi42HcTDbEcmx7M4btfYlGFoKqN2PSFsr1KfI 3T6C7mi8c24REXCXe9HzRp+UZ8HHVVqxCXZyNf04Zj42pmUnlPxR8R5Orp72TuIf 2wES9mW37tEZ0LkrfRWr6X2d4unmw7anaqZkUlIt12kD5h3XmqB7PXojYgchKF2V JWsVzpDt3HPGbQhBBxtr =2stW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat logging with Log4j
Sorry,
I'm not sure why you want to log to the console (stdout), but it looks like
you've managed to do it.
I think is was put in a long time ago (in a bad way) and never changed to a
better way.
Our developers changed
statusListener class=ch.qos.logback.core.status.OnConsoleStatusListener/
appender name=STDOUT class=ch.qos.logback.core.ConsoleAppender
encoder class=ch.qos.logback.core.encoder.LayoutWrappingEncoder
layout
class=com.donlen.common.utility.logging.DefaultAlignedLayout/
/encoder
/appender
To this in our logback.xml
statusListener class=ch.qos.logback.core.status.OnConsoleStatusListener/
appender name=STDOUT class=ch.qos.logback.core.rolling.RollingFileAppender
filelogFile.log/file
rollingPolicy
class=ch.qos.logback.core.rolling.TimeBasedRollingPolicy
!-- daily rollover --
fileNamePatternlogFile.%d{-MM-dd}.%i.log/fileNamePattern
maxHistory180/maxHistory
timeBasedFileNamingAndTriggeringPolicy
class=ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP
maxFileSize100MB/maxFileSize
/timeBasedFileNamingAndTriggeringPolicy
/rollingPolicy
encoder
pattern%date [%thread] %-5level %logger{35} - %msg%n/pattern
/encoder
/appender
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, April 17, 2014 4:41 PM
To: Tomcat Users List
Subject: Re: Tomcat logging with Log4j
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Scott,
On 4/16/14, 10:15 AM, Scott Bailey wrote:
I was able to get one of our developers and it was simple for them to
add the logging for our app to the logback we are using a file and add
logging rotation. My issue is resolved. Thanks for the help though.
Glad to hear you got your issue fixed, though you didn't actually tell us how
it was fixed. It would help others if you would explain what you had to do to
fix this.
I'm not sure why you want to log to the console (stdout), but it looks like
you've managed to do it.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTUEp7AAoJEBzwKT+lPKRYh1IQALT16jdmdy0HvjEIW2NS638b
7NyAmq/VamC2bYMcSwnpc3Zb2MpyJBkpG/dpfEIq14yYf9oqw9veC55hczrTI2YB
Fov95SLzH1e0fnH5tBWTxfS7xGxImv+pI3691gMMElCeR35yrGeNuhdM9sPB22IY
+JjOuX8gDTkI3m5Jq1r2UWe4inLjOneZp3sk5C7esxG8DV4yHUe6C5MFr0+RxsbH
ofZQaaOi+x2PH79vk28YSPB+7OTHf156UhSohFF8jHT5ue1vwl6XqaABjLy79z6Q
ZtCIfudTzKU31FMRJWarD4glHNkKfs+3t6Hw/VKnl6NeS+GnVQYvLDpxhfuKG9Ar
akwQipRaoeudFJSXIu39U8YgrJBYTQFVgMjt4aH3eIdXPhpkC7/hMhuQ2kdXRfgw
pW4L9s2nwaCXN13IOcOOS4CgaXkfXr+DVi7W+zZPVPK0AYmraOCDLrpaRwBJXQvW
5TTqCAfU1SmYDsPrSIjpwFzE4sq8GododUm8lWL2zH+BfOLXFI2Pboy2ji3vpVHU
CKiPhgB+N7zezULlwhZ09gmZOLLb3zBg6q/oFzTwZC9oCX5AN0ziEzi00lLgWf5Q
6y2AN/0zvGv2MziWvWZCrOzL6yyKEscdH5S9O0M1r6FF/BKRH8V95Y7emdnX5ShT
M9cojCEJ9nl3LMzZ697s
=hPD6
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
DISCLAIMER: This electronic mail message and any attached files contain
information intended for the exclusive use of the intended addressee and may
contain information that is proprietary, privileged, confidential and/or exempt
from disclosure under applicable law. If you are not the intended recipient,
you are hereby notified that any viewing, copying, disclosure or distribution
of this information may be subject to legal restriction or sanction. Please
notify sender if you are an unintended recipient and delete the original
message without making copies. Thank you.
Re: Should validationQuery commit ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Franck, On 4/18/14, 5:05 AM, Franck Routier wrote: we recently switched to tomcat-jdbc-pool as our connection pool, and have since encountered performance problems with Postgresql. The problem is due to the fact that postgres is having hard time vacuuming, due to always ongoing idle transactions. See http://permalink.gmane.org/gmane.comp.db.postgresql.performance/37893 for the details. It turns out that those idle transactions were coming from tomcat pool validation queries... here is our configuration: property name=defaultAutoCommit value=false/ property name=maxActive value=30/ property name=maxIdle value=30/ property name=initialSize value=10/ property name=minIdle value=10/ property name=testOnReturn value=true/ property name=testOnBorrow value=true/ property name=validationQuery value=select 1 from rtelre/ property name=validationInterval value=0/ rtelre is a dummy table with 1 column and one row. We use it for compatibility reasons, since we deploy in several environments, and on oracle the from clause is mandatory (so select 1 does not fit). Every database I've ever used accepts SELECT 1 FROM DUAL because Oracle did it first. You could try that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTUXKgAAoJEBzwKT+lPKRYs7oQAIo212h6oQgQ4tlTLWnWt/AJ Oc9kD0uCSZrsDZaABHkILPOGyqcKv+2uYHJ0+tMvuZw0rsYybVCSsxn3a/Kmqaqj wlm+md0ru0MA9/lbMwIPe1w8k8ppMk/fALBBooBu6M0RXs1oGnzAGfPoQ+RNA0Iu JeSOWKKRybQvHH+dv8dlJZJLPBCUx5KzLpuPtl3btDXt7Oa3X5qt+T8ya8W/yi8j QN171iNNZMANFAv32KTPIwIwvg5gup3ptFcHsqcY8prTee1qW25dShMAad4QEKRl eQqMhaI1ETzQaXofNt4WgCP32XPKpfqY0TEBpBBB+3VMLYm9hhEgM359FYZPonAJ EXTo7oGth/8HpO7ZwL7OGV73gf4iondPjPiG8+ks9OI4aWhBN717OLQGwkn5JbaP DYFQJiQ57zcWKcWWUhk6BC4Rh1K61Z69V/D5V2iAtjClvJNGgdIBsyG1DEGD1u+z RkoR3LIQi+n6qPld+XzWqP2nNc5YckbCSR6bL0pza/sraGJXymCwXdbJtlVL3sJT YGF10pfApEt4Imoi6+WjiLX8G3bd0/FNfp02rxJtsQL+eyDXUUICz8dOoJhBkIp2 vgr/u8TM0O+vu/pt4v/aovJO1Rqggsr76Rp5xUqY0Amzrn1wg7b9f8uDr8EhZNFv d3R4rDxto3/8b9upDJUz =p05t -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: comet servlet gets connected to inadvertantly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Elias, On 4/18/14, 2:17 PM, Elias Kopsiaftis wrote: Im using tomcat7 on 64 bit ubuntu linux and java 7. I have a client software that connects to the server. For some reason, when a user logs in, in the access log, i see 3 connections, one to the version check servlet, one to the output servlet, and one to the login servlet. Do you mean you see 3 connections, or 3 requests. How do you see them? Access log? tcpdump? the output servlet should not be accessed by the client until it gets a return value from the login servlet, and im sure it happens in this order in the code. My best guess is that the request is somehow going to two servlets somehow, but i dont know if this is even possible, but I dont know what else could happen. If you are running a comet servlet next to traditional servlets, its there any chance both will get the same request? Version information? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTUXMBAAoJEBzwKT+lPKRYteoP/3B5984tExGxPfLii33gMT7C 7l9YkD7jmseCVr/hORfNqAfce8dk4Jb0VZ0/2Ft7EE+RU+S8Itu/Epf6O9rYlhdA jJ9IYltZl/TzZUDLTb3fPeuv669UM2Ccg7E+KKKkyG2omWIwptp8BzK9Q8+K1uez 8lMlz2Z8UNwF46PlmDP8ngtO0spr+QjNlorBzP5GN/ifAQ7Wqsw6qju+0CDTT+BO FM6AmWEYtdCq/IUD7gxqG8Wi8NxBZXn72F4YYO0LrUkPsSYIY+Ks3BT6MtCrF5Xk 8dqu8ALkH0A7E9bYf77d3GqtrmeByBSQeGtlzz8Wwx/KvPKy9IDBlg069njySZoH DtxOVURwwbiRuMj2PFDiHz5g4vECALsNDzWfXYi1+YYkfvU7qRs05YRzpszOfzqD zbL60IGHnlerRnPsBR1HhwoW7LcewMt5nasKC+yiEa6zfmYjwEhYAq2rTEXw3z8V sfq3R2ySqvoQfiIrgjohzVSjwECIa4DVv4L8VH5vOdWLLrTwFEOg/HpjYsSLnMSg dEhM17odRiGkvAdCxSzWhyyQsxrCeupb9AIZU48Ew0I802wIvhIlaRK9v4k0hZ0p NuOpNqUCMMZw+V/oKUgl+xfeWYdr4NLbKTbv5orJ3LuUU4s3OL7kPtOhSR7rdxev pnAnkn76mxL5EIHDiyT6 =kVaV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: comet servlet gets connected to inadvertantly
Oh, what I meant was version information is that server sends version and tells you to upgrade if you dont have the right version. i see these connections in the access log On Fri, Apr 18, 2014 at 2:46 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Elias, On 4/18/14, 2:17 PM, Elias Kopsiaftis wrote: Im using tomcat7 on 64 bit ubuntu linux and java 7. I have a client software that connects to the server. For some reason, when a user logs in, in the access log, i see 3 connections, one to the version check servlet, one to the output servlet, and one to the login servlet. Do you mean you see 3 connections, or 3 requests. How do you see them? Access log? tcpdump? the output servlet should not be accessed by the client until it gets a return value from the login servlet, and im sure it happens in this order in the code. My best guess is that the request is somehow going to two servlets somehow, but i dont know if this is even possible, but I dont know what else could happen. If you are running a comet servlet next to traditional servlets, its there any chance both will get the same request? Version information? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTUXMBAAoJEBzwKT+lPKRYteoP/3B5984tExGxPfLii33gMT7C 7l9YkD7jmseCVr/hORfNqAfce8dk4Jb0VZ0/2Ft7EE+RU+S8Itu/Epf6O9rYlhdA jJ9IYltZl/TzZUDLTb3fPeuv669UM2Ccg7E+KKKkyG2omWIwptp8BzK9Q8+K1uez 8lMlz2Z8UNwF46PlmDP8ngtO0spr+QjNlorBzP5GN/ifAQ7Wqsw6qju+0CDTT+BO FM6AmWEYtdCq/IUD7gxqG8Wi8NxBZXn72F4YYO0LrUkPsSYIY+Ks3BT6MtCrF5Xk 8dqu8ALkH0A7E9bYf77d3GqtrmeByBSQeGtlzz8Wwx/KvPKy9IDBlg069njySZoH DtxOVURwwbiRuMj2PFDiHz5g4vECALsNDzWfXYi1+YYkfvU7qRs05YRzpszOfzqD zbL60IGHnlerRnPsBR1HhwoW7LcewMt5nasKC+yiEa6zfmYjwEhYAq2rTEXw3z8V sfq3R2ySqvoQfiIrgjohzVSjwECIa4DVv4L8VH5vOdWLLrTwFEOg/HpjYsSLnMSg dEhM17odRiGkvAdCxSzWhyyQsxrCeupb9AIZU48Ew0I802wIvhIlaRK9v4k0hZ0p NuOpNqUCMMZw+V/oKUgl+xfeWYdr4NLbKTbv5orJ3LuUU4s3OL7kPtOhSR7rdxev pnAnkn76mxL5EIHDiyT6 =kVaV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: http status 400 question
On 4/17/2014 7:50 AM, Christopher Schultz wrote:
I'll take a look at the code to see if maybe we can conditionally log
something somewhere when we get a 400 error. You can probably get
information about it by enabling DEBUG logging on the component that
throws the 400 error, but you'll likely get a huge amount of output in
that log file, which you obviously don't want.
Our first remedial action was to to add URIEncoding=UTF-8 to our HTTP
and HTTPS connectors defined in server.xml, as well as added a character
encoding filter to our webapp's web.xml:
filter
filter-nameSetCharacterEncodingFilter/filter-name
filter-class
org.apache.catalina.filters.SetCharacterEncodingFilter
/filter-class
init-param
param-nameencoding/param-name
param-valueUTF-8/param-value
/init-param
/filter
filter-mapping
filter-nameSetCharacterEncodingFilter/filter-name
url-pattern*/url-pattern
/filter-mapping
We've not see any issues since. Could this have played a role somehow
in resolving this, or just coincidence for now?
Do you know if using the above setup we can remove our own JSP page
bean init code shown below that sets the character encoding like we
have now? Seems like our code below was trying to accomplish what I
believe the SetCharacterEncodingFilter is now doing for every request
(not just those that reach our JSPs).
try
{
if ( request.getCharacterEncoding() == null )
request.setCharacterEncoding(CHARSET_UTF_8);
response.setCharacterEncoding(CHARSET_UTF_8);
}
catch( UnsupportedEncodingException e )
{
app.warning(PageBean.init() - Failed to set request/response to
UTF-8 encoding.);
}
Our JSPs already specify charset=UTF-8 in the content type and/or HTML
meta tag for Content-Type.
We're keeping our fingers crossed!
It could also be possible that a browser is incorrectly-formatting
something. Do you make extensive use of cookies Do you ever store
anything in a cookie name or value that isn't in US-ASCII? If so, you
might have some edge cases where the overwhelming majority of your
users are find but some folks with Greek names or whatever step-over
into non-US-ASCII and hit some edge cases with either the browser or
Tomcat itself.
Aside from the session cookie for JSESSIONID done by Tomcat, we
generally only have one cookie that is optional for those who want to
save their login email address. For these, we are using
java.net.URLDecoder.decode/java.net.URLEncoder.encode of the email
address string specifying the UTF-8 charset param to the encoder/decoder.
Does that sound like it could be an issue for these edge cases you are
talking about since my impression is that such encoding would ensure
US-ASCII was the cookie value?
Thanks for your help and consideration, Christopher!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: comet servlet gets connected to inadvertantly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Elias, On 4/18/14, 2:55 PM, Elias Kopsiaftis wrote: Oh, what I meant was version information is that server sends version and tells you to upgrade if you dont have the right version. I was asking for you to tell us what versions of everything you are running. i see these connections in the access log What makes you think that the requests are made in a particular order? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTUXYHAAoJEBzwKT+lPKRYNckP/1q+JUup9mL5Bw/EAj7u/qY4 IFsNz6ixxMh0/6leDJWLQ5GC3xIxjjZY7alc6KoYIrMk3RCit742C4N+lgGYedaI Vof1bddpcLJiQk38D4Oi8esCf63u24ThGWwHfNBDXiQHVqUE6s7MNEwyQQ976yTa ETdKOcLJE0ivML+hfP/9UjT13LPCXMUGyJX3tTzIXcR/Olj69QtLEMtd/vryy5fk ustZKdqoKWrc/CUvJRC+Em9hLUcOMXefyvIPyoNssh7LYpvnME1RRZHWrAAeJYkC iMEhQuca+dYi/NEZV5HXxfslb0NOKwB9cwQABkFpwFbfqmwklVN90NANhg+OaUkI Ox0qCGEsFRgmuG4ons82zb5xq7JUHeTfdwVEjcwcg1qG8sz0BuKkCNONwNiUm0fJ 1MwsADkO3k2MkidOQMDEX+zIiZb6EUSRUwbRWSG8nnANEX1Lcdp7R0j3GgDL6tDQ EvWl7NzPPxQKZrfBY7OWsyAL92R3VXLZoWvIeanMgax3lsj2vFXHhbyXzRD5cFGs cgl6/uOZ390vHC51ej6RKZTB7isEO4vagOCUylJO9Co7v2cA7MXpTlIePJ7+1Q/6 jVueYJXve89FABOPk58mNdQu+vsIoO9xgpIbNVq/3vKbYR0VNer5+NXehgaUsP2D ZMYugcC+5hlz7X1NNLlv =RNe3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: http status 400 question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 4/18/14, 2:57 PM, David Wall wrote:
On 4/17/2014 7:50 AM, Christopher Schultz wrote:
I'll take a look at the code to see if maybe we can conditionally
log something somewhere when we get a 400 error. You can probably
get information about it by enabling DEBUG logging on the
component that throws the 400 error, but you'll likely get a huge
amount of output in that log file, which you obviously don't
want.
Our first remedial action was to to add URIEncoding=UTF-8 to our
HTTP and HTTPS connectors defined in server.xml, as well as added a
character encoding filter to our webapp's web.xml:
filter filter-nameSetCharacterEncodingFilter/filter-name
filter-class
org.apache.catalina.filters.SetCharacterEncodingFilter
/filter-class init-param param-nameencoding/param-name
param-valueUTF-8/param-value /init-param /filter
filter-mapping
filter-nameSetCharacterEncodingFilter/filter-name
url-pattern*/url-pattern /filter-mapping
We've not see any issues since. Could this have played a role
somehow in resolving this, or just coincidence for now?
I've never seen a request generate a 400 error due to a badly-encoded
body... you just end up with broken characters. So the
SetCharacterEncodingFilter probably didn't change anything.
But changing to UTF-8 URI encoding could have an effect: if your pages
are declared to be in UTF-8, then more and more clients these days are
automatically using UTF-8 to encode characters before putting them
into the URL. If you were expecting ISO-8859-1 (the default) and the
client was sending UTF-8, you could easily have problems like this.
I'll repeat what I said earlier: having non-US-ASCII stuff appear in
your URL is still pretty risky these days. Try to find places where
you do that and switch to HTTP POST if you can.
Do you know if using the above setup we can remove our own JSP
page bean init code shown below that sets the character encoding
like we have now? Seems like our code below was trying to
accomplish what I believe the SetCharacterEncodingFilter is now
doing for every request (not just those that reach our JSPs).
try { if ( request.getCharacterEncoding() == null )
request.setCharacterEncoding(CHARSET_UTF_8);
response.setCharacterEncoding(CHARSET_UTF_8); } catch(
UnsupportedEncodingException e ) { app.warning(PageBean.init() -
Failed to set request/response to UTF-8 encoding.); }
Yes. If you use the SetCharacterEncodingFilter (which I recommend you
do), then you will no longer need this hack in your JSPs.
Our JSPs already specify charset=UTF-8 in the content type and/or
HTML meta tag for Content-Type.
Right: that will set the /response/ encoding. I'm thinking that your
clients were probably using UTF-8-encoded URLs and that was tripping
you up. URIEncoding=UTF-8 probably did the trick.
We're keeping our fingers crossed!
I think you'll be okay from here on out. Let us know.
It could also be possible that a browser is
incorrectly-formatting something. Do you make extensive use of
cookies Do you ever store anything in a cookie name or value
that isn't in US-ASCII? If so, you might have some edge cases
where the overwhelming majority of your users are find but some
folks with Greek names or whatever step-over into non-US-ASCII
and hit some edge cases with either the browser or Tomcat
itself.
Aside from the session cookie for JSESSIONID done by Tomcat, we
generally only have one cookie that is optional for those who want
to save their login email address. For these, we are using
java.net.URLDecoder.decode/java.net.URLEncoder.encode of the email
address string specifying the UTF-8 charset param to the
encoder/decoder.
Perfect. You could also base64 encode it if you wanted to. Cookie
values can get ugly, but since you are using URLEncoder (and
specifying an encoding!), everything that actually goes into the
cookie value is US-ASCII so you should be all set.
Does that sound like it could be an issue for these edge cases you
are talking about since my impression is that such encoding would
ensure US-ASCII was the cookie value?
Nope, you are doing the right thing for your cookies.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTUXeOAAoJEBzwKT+lPKRYxPEQAKn/x8wfAiBWXpaN3hlJwa5y
oceMNPPkQx94AGcy9zGaH/5PnkkS5mRlnf02srfrG/wg/RmKKfSj0dl9OpvLzdVF
ZCCEP7Wyxr2yQDPmwGfSZD/kgIlhkUTqGO9tlUVc3lvAhVtF0mih72521j+vwWDj
ampRInly9+p98w6SwCL3TNkVFy1NIyneg7lYqZ0jDW9txSLwUP+Rad9NTJpgTGGg
XuwVRiVr+HbrWwxiBjIkgKfn6KATJcVHzjqeYzBLqfRP9EOR14O/RkWjhNm/W1uv
Yu1KwzQ6jYd2e4+WJS9Xpzk25uRWGIES7AW2WKpua14u4F0WtoiTvH+3fCqB/Grw
fiKV+dLr9MU7g1lQwRi2otUxlNWOQP+6tzPwDs/oEk3lilT+iJdUZEXwMIoymajx
ws8v4UR0j9/zcpnD3mwg0wQNwmLPDFDbJp7prbOKhX36VbzAcM4P/gANFzeE4Pq7
DpxxeSbWQmETlMpzScEXZ7PehxSUjNjXk3EhFF+VxUUDq5FRt5z58eIhWjR4NfvS
Re: http status 400 question
Thanks, Christopher. One last question has to do with the filter-mapping's url-pattern element. Are url-pattern/*/url-pattern and url-pattern*/url-pattern the same? My impression is that /* is more correct since a * pattern implies a file name suffix but there's nothing after it. Is that true, or do /* and * work the same to mean to match every request? The spec does not seem to describe * all by itself and so sounds less correct. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: http status 400 question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 4/18/14, 3:37 PM, David Wall wrote: Thanks, Christopher. One last question has to do with the filter-mapping's url-pattern element. Are url-pattern/*/url-pattern and url-pattern*/url-pattern the same? My impression is that /* is more correct since a * pattern implies a file name suffix but there's nothing after it. Is that true, or do /* and * work the same to mean to match every request? The spec does not seem to describe * all by itself and so sounds less correct. - From my quick re-reading of Section 12.1 of the 3.0 spec, it seems that * should itself only match the URI * exactly, since it does not conform to any of the match-types defined buy the spec. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTUYL/AAoJEBzwKT+lPKRY+goP/1i3AIyVak14vIDmfsN1DnqL LgmUzeWD5wuyyRPWBhcMniGmP6mp96TY4mtW0wOu0CrZathdF+M+Q6OrlVF/L295 76q4BgWr2wBBSNVtsv36i5pSNWRuG7a92E5ZLJWxkrtVdGetoWZshK4nVXi/WKJm 6F1F5Ul4+kgUr4hC3hvhYughm59QRCbSfATtlP6sL05GEt7S8B3sEeRRurugCKCW KUPp8Zczv0d18GoW25U1EoD2+Afmeb8r2oyy/FSH3PMhUko1y8l0SYsY7oQKjnT7 vslWZZ84GeOKO25nkbqwo1zdWVgCp7yUZ41XR6tsq4Fb5MRjwErIrA6+VhsoN6py yFZ1W7QXWrXzsFrKfE7DetGOrNDi2mIImz4BKkaICei+g//ecQMYhpvkAXNSO4wx fYffLevMxm3IeIoed8ts+wPPtrwASZk/jll8Q7xKYvxRRRaJpJOd56qHZ/imJjz8 TGemOIx3x89vRgaeAtL8Vr/dZzhlZKmQd0T/oGUlP0ernukGunijPgq7UxkIURf7 GeuzlZwYW4EIbsKRMq3ZRqAyg/Zl3t0jyFsRIkWprEhX/EYxdDfGYChz3VLRz+AB QpW4sjWPoUQeZHndo+ezz/YIxbhxFjqaeQ6Vb/xE+/Ec3RqOAd2froRfBvBqRc1S yXwhRIl5PmICMaN3zDPW =djnr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Heartbeat Bug Update - Installation?
Funny, stupid autocorrect...I know it's Heartbleed, not Heartbeat. :) -Original Message- From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Sent: Friday, April 18, 2014 8:24 AM To: Tomcat Users List Subject: Re: Heartbeat Bug Update - Installation? On Apr 18, 2014, at 9:02 AM, Keith Davis laurinkeithda...@gmail.com wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=56363 I'm somewhat new to Tomcat. What do I need to do obtain this patch / update? I'm running Apache Tomcat 7 on Windows. This is a good starting point. https://wiki.apache.org/tomcat/Security/Heartbleed Dan Keith Davis - (214) 906-5183 - http://laurinkeithdavis.com http://laurinkeithdavis.com/ - 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: Best practice to programmatically get the disableURLRewriting context attribute value
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lo, On 4/17/14, 10:44 AM, Sauvel Laurent wrote: 1. Before testing the code below with different Tomcat configurations, I would like to know if there is a better way to do what I want. I'm not really satisfied with this code that is closely related to Tomcat classes. You are trying to fetch a value from a Tomcat-specific configuration... why do you think you can do this in a non-Tomcat-specific way? 2. The original problem is that I would like to: a) prevent Tomcat (6.0.x, including versions older than 6.0.30) from adding the ;jsessionid=xxx string to the URL when there is no cookie named JSESSIONID in the client browser Use a Filter, just like everybody else. This will work in any container. b) prevent jsessionid hijacking via the url, i.e redirect to an error page when the jsessionid= string is detected in the URL You can do this with a Filter, too. No Tomcat-specific code necessary. AFAICT, you don't need to sniff/set the disableURLRewriting attribute value at all. Just FYI, preventing jsessionid hijacking does not prevent session hijacking at all. Forging the JSESSIONID cookie is just as easy as forging a jsessiondi URL path parameter. The difference is that you can't email a cookie-laden URL to someone. The real way to prevent session hijacking is to change the session id after a login, which is exactly what Tomcat already does for you, so you shouldn't have to worry about it at all. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTUY3dAAoJEBzwKT+lPKRYzgEP/3dXC9Eq0MGpunHdS/iWwbRF h83Zodu6Q4VMfj9ugvCdch4MtkAMMoLJCX+eFD9BsDmI+Y+Uou1A1ogL36u/5Lxh QyTt8T7BJIs6ZJK/FemCbzKbNPwAfJXZZ0BqWiG/lSE9ZvmI8Pn/DHHIylZZKEMe /dTYiNKxEChl7U2qzs/vY5Gh8xzoKnB0JXvVxozVjRgnw9UiWKUlLWy7WvN1YjJF 4ET0FcMaRIJbiEIxmPMAaHkQSs8ctApU2WMASUS+zqiNnJ9iLMEfyG+ime5PispG JkmR9EAKk2Y/epKy7BAgBIHpGLiHA0H+knEP7ITJj1kWYvZF5IPO9FwR/TMsKTyl PhpU80ZF5U8S7du2qAK5K438ms2E/oWTqVAf4yOtsZrIk4C5p5E2ZV4j4anzpwgf cTiZHTJhIM6TerYDdReEE11DjH14nPmeV/V/OHLHUEUMhblfhH1TsvDnESsZ0YK3 fq0qIsmHSgy5Nec2jCe+bUKomYruZBkMzoHL0JbqYW9UYRvoFgRWDJLzs3PVIfZi PKArFozMM7+Ggv8irzNSmnyiT/v6TIo8axmIEYrmJAKWXiIHHuQBMdyJ5ntv66+w hwm5d/zVn35QVdfGHWMeZG2Cn4z9ch7Gb4zv94M5cJQ9QaIKu5aZPDj9QuJ3RYUM R8zWdkTyDumXntA7nJdY =tWIu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
