Re: Webapps directory query
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please do not top post. On 6/19/2014 10:53 PM, vicky wrote: > Thanks Mark, but it doesn't have the details of scenario when we'll > carry out a redeployment along with a restart/ > > How the exploded directories will then be updated , is it only the > files are going to be updated within it ? > > Please give some directions. > > Vicky > The documentation clearly states what happens when you redeploy a web application in a stopped Tomcat (by replacing the WAR file) and then starting the Tomcat instance. The documentation also clearly states what happens when you redeploy a web application in a running Tomcat by replacing the WAR file. What are your exact steps? What exact version of Tomcat are you using? /mde/ > > > > On Friday, 20 June 2014 11:00 AM, Mark Eggers > wrote: > > > > > On 6/19/2014 10:12 PM, vicky wrote: >> Hi Guys, > >> Ideally when a redeployment happens in a tomcat , is it standard >> that the exploded war directory will again be > >> updated with the latest timestamps or is it the case that only >> files will be updated within that directory. > >> Please share if there is any online documentation available for >> this behavior > > >> Kindly suggest > > >> Thanks Vicky > > > Please read the following links, and search for the word > 'redeploy'. > > http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html > http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html > http://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html > > . . . just my two cents /mde/ > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTo85ZAAoJEEFGbsYNeTwtNV8H/jc/gbqrqgxwbELMCy8IXQt7 e0WVwsgWKWSj/pVwHX9iM6fxJSHRmQnaKEJL5CNUr3oUBasExNLlqbzNaNAA/UXK qv8IqD0DjrYO7mqZPdcY/0BVxlFc5dy33XkA0te6tG3qUj+wj36EY++QBJAQMK76 6q9j1igmV2vN9S4FYfl8Md3lUWBzp8fYupRRppNIvxAdhOvbeRdCYM2mk3J0CiOq N2mZ0XlnUhnBoYqdSa2KaepZ9Ra46AuCAUhFUke7XpMlLAv9DPUGuWBywp5aJMiC RxzWIUfok5TUd9p6Kg3DAZC6KVPjrMKbH2XFauNeMwZfOJQWQtiMJWQAAsBzVtg= =OEgB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapps directory query
Thanks Mark, but it doesn't have the details of scenario when we'll carry out a redeployment along with a restart/ How the exploded directories will then be updated , is it only the files are going to be updated within it ? Please give some directions. Vicky On Friday, 20 June 2014 11:00 AM, Mark Eggers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/19/2014 10:12 PM, vicky wrote: > Hi Guys, > > Ideally when a redeployment happens in a tomcat , is it standard > that the exploded war directory will again be > > updated with the latest timestamps or is it the case that only > files will be updated within that directory. > > Please share if there is any online documentation available for > this behavior > > > Kindly suggest > > > Thanks Vicky > Please read the following links, and search for the word 'redeploy'. http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html http://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTo8a8AAoJEEFGbsYNeTwt5kcH/1Lrmw9PeIJq6Y4P6RZCMc+K 8T4q8uCC70U/Bkesd5b7e+uaVLiv/kmutnTKB+0vSzhn12iy/fbkO8RC+6gbNjp0 sicu1y6kHaCp3t0djRk+rRqzWi0gg0yGgbJNz26FVkauXFQoPYAD6/gvApH54bp/ V1bXY0eGRgNdv2lUneMOEOk4vVaciUmIoKWSVznBISYlLNRaqg609u4ChoStAZm+ NDu6z4vrx435XZ4OygIhSzh/hBxhuNZv4VZ3gCx88a/NV4mxqiB4K4fSeGmrpF6U uffuhsfj0+INTclNk/Y0avWe+B26e2GKRDkujcWVpJS1fXb4id9uTamdRX1+N4c= =x1Ow -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapps directory query
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/19/2014 10:12 PM, vicky wrote: > Hi Guys, > > Ideally when a redeployment happens in a tomcat , is it standard > that the exploded war directory will again be > > updated with the latest timestamps or is it the case that only > files will be updated within that directory. > > Please share if there is any online documentation available for > this behavior > > > Kindly suggest > > > Thanks Vicky > Please read the following links, and search for the word 'redeploy'. http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html http://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTo8a8AAoJEEFGbsYNeTwt5kcH/1Lrmw9PeIJq6Y4P6RZCMc+K 8T4q8uCC70U/Bkesd5b7e+uaVLiv/kmutnTKB+0vSzhn12iy/fbkO8RC+6gbNjp0 sicu1y6kHaCp3t0djRk+rRqzWi0gg0yGgbJNz26FVkauXFQoPYAD6/gvApH54bp/ V1bXY0eGRgNdv2lUneMOEOk4vVaciUmIoKWSVznBISYlLNRaqg609u4ChoStAZm+ NDu6z4vrx435XZ4OygIhSzh/hBxhuNZv4VZ3gCx88a/NV4mxqiB4K4fSeGmrpF6U uffuhsfj0+INTclNk/Y0avWe+B26e2GKRDkujcWVpJS1fXb4id9uTamdRX1+N4c= =x1Ow -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Webapps directory query
Hi Guys, Ideally when a redeployment happens in a tomcat , is it standard that the exploded war directory will again be updated with the latest timestamps or is it the case that only files will be updated within that directory. Please share if there is any online documentation available for this behavior Kindly suggest Thanks Vicky
Re: Connection count explosion due to thread http-nio-80-ClientPoller-x death
"Our sites still functions normally with no cpu spikes during this build up until around 60,000 connections, but then the server refuses further connections and a manual Tomcat restart is required." yes, the connection limit is a 16 bit short count minus some reserved addresses. So your system should become unresponsive, you've run out of ports (the 16 bit value in a TCP connection). netstat -na should give you your connection state when this happens, and that is helpful debug information. Filip On Thu, Jun 19, 2014 at 2:44 PM, André Warnier wrote: > Konstantin Kolinko wrote: > >> 2014-06-19 17:10 GMT+04:00 Lars Engholm Johansen : >> >>> I will try to force a GC next time I am at the console about to restart a >>> Tomcat where one of the http-nio-80-ClientPoller-x threads have died and >>> connection count is exploding. >>> >>> But I do not see this as a solution - can you somehow deduct why this >>> thread died from the outcome from a GC? >>> >> >> Nobody said that a thread died because of GC. >> >> The GC that Andre suggested was to get rid of some of CLOSE_WAIT >> connections in netstat output, in case if those are owned by some >> abandoned and non properly closed I/O classes that are still present >> in JVM memory. >> > > Exactly, thanks Konstantin for clarifying. > > I was going per the following in the original post : > > "Our sites still functions normally with no cpu spikes during this build up > until around 60,000 connections, but then the server refuses further > connections and a manual Tomcat restart is required." > > CLOSE_WAIT is a normal state for a TCP connection, but it should not > normally last long. > It indicates basically that the other side has closed the connection, and > that this side should do the same. But it doesn't, and as long as it > doesn't the connection remains in the CLOSE_WAIT state. It's like > "half-closed", but not entirely, and as long as it isn't, the OS cannot get > rid of it. > For a more precise explanation, Google for "TCP CLOSE_WAIT state". > > I have noticed in the past, with some Linux versions, that when the number > of such CLOSE_WAIT connections goes above a certain level (several > hundred), the TCP/IP stack can become totally unresponsive and not accept > any new connections at all, on any port. > In my case, this was due to the following kind of scenario : > Some class Xconnection instantiates an object, and upon creation this > object opens a TCP connection to something. This object is now used as an > "alias" for this connection. Time passes, and finally the object goes out > of scope (e.g. the reference to it is set to "null"), and one may believe > that the underlying connection gets closed as a side-effect. But it > doesn't, not as long as this object is not actually garbage-collected, > which triggers the actual object destruction and the closing of the > underlying connection. > Forcing a GC is a way to provoke this (and restarting Tomcat another, but > more drastic). > > If a forced GC gets rid of your many CLOSE_WAIT connections and makes your > Tomcat operative again, that would be a sign that something similar to the > above is occurring; and then you would need to look in your application for > the oversight. (e.g. the class should have a "close" method (closing the > underlying connection), which should be invoked before letting the object > go out of scope). > > The insidious part is that everything may look fine for a long time (apart > from an occasional long list of CLOSE_WAIT connections). A GC will happen > from time to time (*), which will get rid of these connections. And those > CLOSE_WAIT connections do not consume a lot of resources, so you'll never > notice. > Until at some point, the number of these CLOSE_WAIT connections gets just > at the point where the OS can't swallow any more of them, and then you have > a big problem. > > That sounds a bit like your case, doesn't it ? > > (*) and this is the "insidious squared" part : the smaller the Heap, the > more often a GC will happen, so the sooner these CLOSE_WAIT connections > will disappear. Conversely, by increasing the Heap size, you leave more > time between GCs, and make the problem more likely to happen. > > > I believe that the rest below may be either a consequence, or a red > herring, and I would first eliminate the above as a cause. > > > >> And could an Exception/Error in Tomcat thread http-nio-80-ClientPoller-0 >>> or http-nio-80-ClientPoller-1 make the thread die with no Stacktrace >>> in >>> the Tomcat logs? >>> >>> >> A critical error (java.lang.ThreadDeath, >> java.lang.VirtualMachineError) will cause death of a thread. >> >> A subtype of the latter is java.lang.OutOfMemoryError. >> >> As of now, such errors are passed through and are not logged by >> Tomcat, but are logged by java.lang.ThreadGroup.uncaughtException(). >> ThreadGroup prints them to System.err (catalina.out). >> >> >> Best regards, >> Konstantin Kolinko >> >>
Re: Connection count explosion due to thread http-nio-80-ClientPoller-x death
Konstantin Kolinko wrote: 2014-06-19 17:10 GMT+04:00 Lars Engholm Johansen : I will try to force a GC next time I am at the console about to restart a Tomcat where one of the http-nio-80-ClientPoller-x threads have died and connection count is exploding. But I do not see this as a solution - can you somehow deduct why this thread died from the outcome from a GC? Nobody said that a thread died because of GC. The GC that Andre suggested was to get rid of some of CLOSE_WAIT connections in netstat output, in case if those are owned by some abandoned and non properly closed I/O classes that are still present in JVM memory. Exactly, thanks Konstantin for clarifying. I was going per the following in the original post : "Our sites still functions normally with no cpu spikes during this build up until around 60,000 connections, but then the server refuses further connections and a manual Tomcat restart is required." CLOSE_WAIT is a normal state for a TCP connection, but it should not normally last long. It indicates basically that the other side has closed the connection, and that this side should do the same. But it doesn't, and as long as it doesn't the connection remains in the CLOSE_WAIT state. It's like "half-closed", but not entirely, and as long as it isn't, the OS cannot get rid of it. For a more precise explanation, Google for "TCP CLOSE_WAIT state". I have noticed in the past, with some Linux versions, that when the number of such CLOSE_WAIT connections goes above a certain level (several hundred), the TCP/IP stack can become totally unresponsive and not accept any new connections at all, on any port. In my case, this was due to the following kind of scenario : Some class Xconnection instantiates an object, and upon creation this object opens a TCP connection to something. This object is now used as an "alias" for this connection. Time passes, and finally the object goes out of scope (e.g. the reference to it is set to "null"), and one may believe that the underlying connection gets closed as a side-effect. But it doesn't, not as long as this object is not actually garbage-collected, which triggers the actual object destruction and the closing of the underlying connection. Forcing a GC is a way to provoke this (and restarting Tomcat another, but more drastic). If a forced GC gets rid of your many CLOSE_WAIT connections and makes your Tomcat operative again, that would be a sign that something similar to the above is occurring; and then you would need to look in your application for the oversight. (e.g. the class should have a "close" method (closing the underlying connection), which should be invoked before letting the object go out of scope). The insidious part is that everything may look fine for a long time (apart from an occasional long list of CLOSE_WAIT connections). A GC will happen from time to time (*), which will get rid of these connections. And those CLOSE_WAIT connections do not consume a lot of resources, so you'll never notice. Until at some point, the number of these CLOSE_WAIT connections gets just at the point where the OS can't swallow any more of them, and then you have a big problem. That sounds a bit like your case, doesn't it ? (*) and this is the "insidious squared" part : the smaller the Heap, the more often a GC will happen, so the sooner these CLOSE_WAIT connections will disappear. Conversely, by increasing the Heap size, you leave more time between GCs, and make the problem more likely to happen. I believe that the rest below may be either a consequence, or a red herring, and I would first eliminate the above as a cause. And could an Exception/Error in Tomcat thread http-nio-80-ClientPoller-0 or http-nio-80-ClientPoller-1 make the thread die with no Stacktrace in the Tomcat logs? A critical error (java.lang.ThreadDeath, java.lang.VirtualMachineError) will cause death of a thread. A subtype of the latter is java.lang.OutOfMemoryError. As of now, such errors are passed through and are not logged by Tomcat, but are logged by java.lang.ThreadGroup.uncaughtException(). ThreadGroup prints them to System.err (catalina.out). Best regards, Konstantin Kolinko - 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
Browsers suddenly start timing out when accessing port 80 of secure site
We have a Java application running on Tomcat 7.0.52 on an Amazon Web Services EC2 Windows 2008 R2 server. Tomcat is setup so that our application is the root application and is accessible from port 80. The application and Tomcat are configured with SSL so that whenever anyone types in the url for the site (e.g. www.something.net) Tomcat will switch into HTTPS and use port 8443. This all works fine, but it seems that if for some reason a browser times out when accessing the site, it will never connect to the site again, and any attempt to connect using www.something.net will show that the connection has timed out. Yet if you put in the port number (e.g., www.something.net:8443) it comes up right away. We have seen this happen on both Chrome (Version 35.0.1916.153 m) and Firefox (Version 30.0). On Chrome I was able to get the browser to connect to the site by going to Settings > Advanced > Clear Browser Data and clearing browser history, download history, cookies, and cached images and files. Once I did that the site came up immediately with www.something.net and switch to HTTPS as it is supposed to do. On Firefox, I get the same thing. It will not connect unless I add the port. I tried clearing cached web content, setting the cache limit to zero, and clearing offline web content. None of this worked. Re-installing Firefox did work. It took me several months to encounter this problem. But other users have encountered it right away (e.g., when setting up a new machine). Using browser development tools and Tomcat logs, I was able to see the following: . When working chrome send get to url. Tomcat responds with HTTP 302 and redirects to the secure port. The Tomcat localhost_access_log reflects these transmissions. . When not working, Firefox sends get to url, but no response is returned. The Tomcat localhost_access_log is blank. Can anyone shed any light on this? Is this a Tomcat issue or something to do with the browsers? Is there anything I can look for in the logs that may help? Bruce
Re: Query string parameters not included by RequestDispatcher on Tomcat 6.0.36
On 2014/06/19 05:35 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 6/19/14, 10:54 AM, Michael van Rooyen wrote:
On 2014/06/19 04:48 PM, Michael van Rooyen wrote:
On 2014/06/19 04:20 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
Michael,
On 6/19/14, 9:43 AM, Michael van Rooyen wrote:
We've been running Tomcat 6.0.36 without issues for many
months. Our pages have many components and are constructed
using getRequestDispacher("...").include(request, response)
to pull the components in.
For the past few weeks, we've had a few instances where, in
constructing a page, the parameters in the query string
passed to getRequestDispatcher(), are not being passed
through to the components included.
For example, if a browser submits the request
/main.jsp?id=foo, then from that page, we include
/product.jsp?id=bar, the product.jsp page should see the
following parameters:
id = [ bar, foo ]
This happens almost all the time, but sporadically, we're
getting just:
id = [ foo ] instead.
If the entry page was /main.jsp?cat=foobar, for example, then
on including /product.jsp?id=bar, we should get:
id = [ bar ], cat = [ foobar ]
But instead, we sometimes get just:
cat = [ foobar ]
Here is an extract from our logs. The first is just before
the call the getRequestDispatcher().include(), and shows the
URI.
19 Jun 2014 2:58:04 PM
org.apache.catalina.core.ApplicationContext log INFO: Trace @
2014-06-19 14:58:04.808 [system: TP-Processor7]
/full/include/view/generic/smallfeature.jsp?id=25951215082928&cached=true
web.Session$Site.include(Session.java:58)
And then the smallfeature.jsp logs the contents of the
parameterMap directly thereafter:
19 Jun 2014 2:58:04 PM
org.apache.catalina.core.ApplicationContext log INFO: Trace @
2014-06-19 14:58:04.81
[993BE7ADFD65B94F2A62E85B64B3B8A2/null: TP-Processor7]
Parameters: cat = lcu; page = browse;
web.tags.Log.doStartTag(Log.java:48)
You can see the id and cached parameters are missing, and
the parameters that are available are actually those from the
main page. Has anyone experienced this before, or know what
may cause it?
I think there is a hole in the spec, here, because Servlet Spec
3.0, section 9.1.1 states:
" Parameters specified in the query string used to create the
RequestDispatcher take precedence over other parameters of the
same name passed to the included servlet. The parameters
associated with a RequestDispatcher are scoped to apply only
for the duration of the include or forward call. "
The term "take precedence" could be interpreted as "overriding
completely" (Tomcat's implementation) or "appending" (your
expectation), and I think I would agree with the current
implementation Tomcat appears to have: the "id" parameter in
your included query string completely replaces the "id"
parameter that came from the original request.
Short of a clarification of the Servlet spec, you are going to
have to do something else in order to fix this problem. Might I
recommend the use of a request /attribute/ instead of a query
string parameter to pass information from one resource to
another for inclusion?
Thanks for the info Chris. The problem is that tomcat is not
behaving consistently - from what I see, Tomcat doesn't "override
completely", rather, it "appends". But sometimes, sporadically,
it "ignores", and when it does ignore, it breaks our site.
If you compare the two logs I listed earlier (the "ignore"
scenario), to two below (normal scenario), you see the parameters
being appended. I'm not sure if there is something weird about
our code that causes the "append" behaviour, but for now I'm
assuming that this is Tomcat's normal behaviour.
Normal behaviour: just before the call to
getRequestDispatcher().include(), we log the URI:
19 Jun 2014 4:30:16 PM
org.apache.catalina.core.ApplicationContext log INFO: Trace @
2014-06-19 16:30:16.96 [system: TP-Processor24]
/full/include/view/book/detail.jsp?id=2691420082928&cached=false
web.Session$Site.include(Session.java:58)
Right thereafter, detail.jsp logs the actual parameters
received:
19 Jun 2014 4:30:16 PM
org.apache.catalina.core.ApplicationContext log INFO: Trace @
2014-06-19 16:30:16.961 [97A547EA5879F643AA717483B7165A39/null:
TP-Processor24] Parameters: id = [ 2691420082928, bdgc-269-g050
]; cached = false; page = detail;
web.tags.Log.doStartTag(Log.java:48)
Here, you see that the parameters from the include
(id=2691420082928 and cached=false) are being prepended to the
parameters on the original request (id=bdgc-269-g050 and page =
detail). Both ids are in the array, with the included one as
element 0. This is when things are working normally. In the
"ignore" scenario, the second log would be:
Parameters: id = [ bdgc-269-g050 ]; cached = false;
In other words, the parameters from the URL passed to include(),
are ignored completely...
Thanks, Michael.
Sorry, a typo in the "ignore" parameters above, the line should
re
Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 6/18/14, 12:05 PM, Konstantin Preißer wrote: >> -Original Message- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Wednesday, June 18, >> 2014 4:23 PM To: Tomcat Users List Subject: Re: Regarding >> JSESSIONIDSSO Cookie maintained by tomcat >> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Konstantin, >> >> On 6/18/14, 5:34 AM, Konstantin Kolinko wrote: >>> 2014-06-18 11:57 GMT+04:00 Konstantin Kolinko >>> : > > HTTP/1.1 302 Found Set-Cookie: > JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; > Expires=Thu, 01-Jan-1970 00:00:10 GMT Pragma: No-cache > Cache-Control: no-cache Expires: Thu, 01 Jan 1970 00:00:00 > UTC Set-Cookie: > JSESSIONID=235F4293591E5C72859317ED3294C5A5; Path=/admin; > Secure; HttpOnly Location: https://X.Y.A.B/admin/login.jsp > Content-Length: 0 Date: Tue, 17 Jun 2014 16:21:17 GMT > Server: XYZ > With that value of "Expires" the cookie is actually being cleared, not set. >>> >>> The 'Secure' flag says that the browser should never send the >>> cookie to the server over a non-secure connection. >>> >>> When the cookie is being cleared, the "Secure" flag is >>> irrelevant, as the cookie will not be sent back by the >>> browser. >> >> +1 >> >>> The "HttpOnly" flag says that the cookie should not be >>> accessible from Javascript code running in the browser. If the >>> cookie is being deleted, is there a way to access it from >>> Javascript? I think that there is no such way. >> >> +1 >> >> I think this is a spurious error being flagged by the security >> scanner. Adding "HttpOnly" and "Secure" flags to the "expire" >> Set-Cookie header is just a waste of bytes because they have no >> effect whatsoever on what the client does with the cookie (it >> always deleted it, unless the system clock is set horribly >> wrong). > > I haven't followed all of this discussion, but as for deleting a > Cookie, I think the problem is that there isn't an explicit > "Delete-Cookie" header; but instead the server has to send the > cookie name with a "Expires" flag that is in the past. Correct. > In this case, I think if the original cookie contained a "Secure" > and "HttpOnly" flag, then the Set-Cookie header which deletes the > cookie by setting an "Expire" date in the past also should set the > "Secure" and "HttpOnly" flags. The point is that the "Secure" and "HttpOnly" flags are irrelevant if the cookie is being expired. > Although it is unlikely that the client will send back a Cookie > which expires in 1970, it would be possible if the client's system > date is set wrong, so IMHO this is not an exact "delete this > cookie" instruction and therefore the "Expire" Set-Cookie header > should include the same HttpOnly and Secure flags that were > included in the original Set-Cookie header. I wonder if the spec says something about the minimum date of the Expires attribute. I'm not going to look it up, but I'll bet that Expires values prior to start-of-UNIX-epoch are invalid, so basically timestamp=0l is, by definition, an expire operation regardless of the client's current clock. > Also, when deleting a cookie, I think it might be better to send a > Set-Cookie header with an empty value, so that the value is > overwritten by the browser if for some reason the cookie is not yet > expired. > > E.g., instead of Set-Cookie: > JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Expires=Thu, > 01-Jan-1970 00:00:10 GMT the server could send: Set-Cookie: > JSESSIONIDSSO=; Expires=Thu, 01-Jan-1970 00:00:10 GMT > > (RFC6265 Section 3.1 shows an example where a cookie is deleted > this way) Seems like a reasonable request, although it should not matter one bit. Want to create a BZ request for this? Perhaps even a patch? ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTowRYAAoJEBzwKT+lPKRYUmkP/1csmbspAUI0PE8DlZukTMN6 jOKFJMJIJxTv3zOZc7jcDnUvXAwqrLvgxfylDim1MItEhhGfioi0LhCIjXuU7k9f SyWG3l+pCJmYx68qXeOcyky7QVuWsVMtFhx/gqS5s3eFpoipq5Y74XQIOvq6CQ75 18HA7R6vXB5mtTJwvd59ICwitVmoQrYPNCF8HLnFVHLCvPYeeRVBt9PgDL7nMLRo 7viE5QIFII2G/ss5sRXzFRTHkV9xrwZ9J0N4q5+ivVr47CakLwzJLh2NUbExXL+u gYfLKaVH2A6pCEacOtQgeamv6DTiKe+xdyclgyERRD04tQtjnGe1rIrH7ndwbH7z Gz28BiNPGKF5vGerWcIRngPZ0/uHRVgc5/F8TytbEHVTFVTSXZq70jl2wEzMCXRk C5iEXkyBLX7EmnnwAvCKKHc23vFMQG63Un4afHNXr7rabD8zQIeg5c9kEyDf9epx rnePt4tgSv9ajWpSpUMqcHlZhVPk4GtdmrGQ+1blr4iygvwmf0Ew2is5nZOB2SVC 0Jz3/D40VrwkMHEv7wXPsZueMhX33yCTnavGuV5zerg1VpF1ghjcz1dxsEE6KJlS VK8NPSr8zDvdBwvIeNFMT26frK11IQcwWohbQyJCkpOh8vKV9kI00yIPqQG9ccSg H7OXzMdSg9Rph+ANAsjd =wLAE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apa
Re: Query string parameters not included by RequestDispatcher on Tomcat 6.0.36
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 6/19/14, 10:54 AM, Michael van Rooyen wrote:
>
> On 2014/06/19 04:48 PM, Michael van Rooyen wrote:
>>
>> On 2014/06/19 04:20 PM, Christopher Schultz wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>
>>> Michael,
>>>
>>> On 6/19/14, 9:43 AM, Michael van Rooyen wrote:
We've been running Tomcat 6.0.36 without issues for many
months. Our pages have many components and are constructed
using getRequestDispacher("...").include(request, response)
to pull the components in.
For the past few weeks, we've had a few instances where, in
constructing a page, the parameters in the query string
passed to getRequestDispatcher(), are not being passed
through to the components included.
For example, if a browser submits the request
/main.jsp?id=foo, then from that page, we include
/product.jsp?id=bar, the product.jsp page should see the
following parameters:
id = [ bar, foo ]
This happens almost all the time, but sporadically, we're
getting just:
id = [ foo ] instead.
If the entry page was /main.jsp?cat=foobar, for example, then
on including /product.jsp?id=bar, we should get:
id = [ bar ], cat = [ foobar ]
But instead, we sometimes get just:
cat = [ foobar ]
Here is an extract from our logs. The first is just before
the call the getRequestDispatcher().include(), and shows the
URI.
19 Jun 2014 2:58:04 PM
org.apache.catalina.core.ApplicationContext log INFO: Trace @
2014-06-19 14:58:04.808 [system: TP-Processor7]
/full/include/view/generic/smallfeature.jsp?id=25951215082928&cached=true
>>>
web.Session$Site.include(Session.java:58)
And then the smallfeature.jsp logs the contents of the
parameterMap directly thereafter:
19 Jun 2014 2:58:04 PM
org.apache.catalina.core.ApplicationContext log INFO: Trace @
2014-06-19 14:58:04.81
[993BE7ADFD65B94F2A62E85B64B3B8A2/null: TP-Processor7]
Parameters: cat = lcu; page = browse;
web.tags.Log.doStartTag(Log.java:48)
You can see the id and cached parameters are missing, and
the parameters that are available are actually those from the
main page. Has anyone experienced this before, or know what
may cause it?
>>> I think there is a hole in the spec, here, because Servlet Spec
>>> 3.0, section 9.1.1 states:
>>>
>>> " Parameters specified in the query string used to create the
>>> RequestDispatcher take precedence over other parameters of the
>>> same name passed to the included servlet. The parameters
>>> associated with a RequestDispatcher are scoped to apply only
>>> for the duration of the include or forward call. "
>>>
>>> The term "take precedence" could be interpreted as "overriding
>>> completely" (Tomcat's implementation) or "appending" (your
>>> expectation), and I think I would agree with the current
>>> implementation Tomcat appears to have: the "id" parameter in
>>> your included query string completely replaces the "id"
>>> parameter that came from the original request.
>>>
>>> Short of a clarification of the Servlet spec, you are going to
>>> have to do something else in order to fix this problem. Might I
>>> recommend the use of a request /attribute/ instead of a query
>>> string parameter to pass information from one resource to
>>> another for inclusion?
>> Thanks for the info Chris. The problem is that tomcat is not
>> behaving consistently - from what I see, Tomcat doesn't "override
>> completely", rather, it "appends". But sometimes, sporadically,
>> it "ignores", and when it does ignore, it breaks our site.
>>
>> If you compare the two logs I listed earlier (the "ignore"
>> scenario), to two below (normal scenario), you see the parameters
>> being appended. I'm not sure if there is something weird about
>> our code that causes the "append" behaviour, but for now I'm
>> assuming that this is Tomcat's normal behaviour.
>>
>> Normal behaviour: just before the call to
>> getRequestDispatcher().include(), we log the URI:
>>
>> 19 Jun 2014 4:30:16 PM
>> org.apache.catalina.core.ApplicationContext log INFO: Trace @
>> 2014-06-19 16:30:16.96 [system: TP-Processor24]
>> /full/include/view/book/detail.jsp?id=2691420082928&cached=false
>> web.Session$Site.include(Session.java:58)
>>
>> Right thereafter, detail.jsp logs the actual parameters
>> received:
>>
>> 19 Jun 2014 4:30:16 PM
>> org.apache.catalina.core.ApplicationContext log INFO: Trace @
>> 2014-06-19 16:30:16.961 [97A547EA5879F643AA717483B7165A39/null:
>> TP-Processor24] Parameters: id = [ 2691420082928, bdgc-269-g050
>> ]; cached = false; page = detail;
>> web.tags.Log.doStartTag(Log.java:48)
>>
>> Here, you see that the parameters from the include
>> (id=2691420082928 and cached=false) are being prepended to the
>>
Re: Query string parameters not included by RequestDispatcher on Tomcat 6.0.36
Dne 19.6.2014 16:54, Michael van Rooyen napsal(a):
On 2014/06/19 04:48 PM, Michael van Rooyen wrote:
On 2014/06/19 04:20 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 6/19/14, 9:43 AM, Michael van Rooyen wrote:
We've been running Tomcat 6.0.36 without issues for many months.
Our pages have many components and are constructed using
getRequestDispacher("...").include(request, response) to pull the
components in.
For the past few weeks, we've had a few instances where, in
constructing a page, the parameters in the query string passed to
getRequestDispatcher(), are not being passed through to the
components included.
For example, if a browser submits the request /main.jsp?id=foo,
then from that page, we include /product.jsp?id=bar, the
product.jsp page should see the following parameters:
id = [ bar, foo ]
This happens almost all the time, but sporadically, we're getting
just:
id = [ foo ] instead.
If the entry page was /main.jsp?cat=foobar, for example, then on
including /product.jsp?id=bar, we should get:
id = [ bar ], cat = [ foobar ]
But instead, we sometimes get just:
cat = [ foobar ]
Here is an extract from our logs. The first is just before the
call the getRequestDispatcher().include(), and shows the URI.
19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext
log INFO: Trace @ 2014-06-19 14:58:04.808 [system: TP-Processor7]
/full/include/view/generic/smallfeature.jsp?id=25951215082928&cached=true
web.Session$Site.include(Session.java:58)
And then the smallfeature.jsp logs the contents of the
parameterMap directly thereafter:
19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext
log INFO: Trace @ 2014-06-19 14:58:04.81
[993BE7ADFD65B94F2A62E85B64B3B8A2/null: TP-Processor7] Parameters:
cat = lcu; page = browse; web.tags.Log.doStartTag(Log.java:48)
You can see the id and cached parameters are missing, and the
parameters that are available are actually those from the main
page. Has anyone experienced this before, or know what may cause
it?
I think there is a hole in the spec, here, because Servlet Spec 3.0,
section 9.1.1 states:
"
Parameters specified in the query string used to create the
RequestDispatcher take precedence over other parameters of the same
name passed to the included servlet. The parameters associated with a
RequestDispatcher are scoped to apply only for the duration of the
include or forward call.
"
The term "take precedence" could be interpreted as "overriding
completely" (Tomcat's implementation) or "appending" (your
expectation), and I think I would agree with the current
implementation Tomcat appears to have: the "id" parameter in your
included query string completely replaces the "id" parameter that came
from the original request.
Short of a clarification of the Servlet spec, you are going to have to
do something else in order to fix this problem. Might I recommend the
use of a request /attribute/ instead of a query string parameter to
pass information from one resource to another for inclusion?
Thanks for the info Chris. The problem is that tomcat is not
behaving consistently - from what I see, Tomcat doesn't "override
completely", rather, it "appends". But sometimes, sporadically, it
"ignores", and when it does ignore, it breaks our site.
If you compare the two logs I listed earlier (the "ignore" scenario),
to two below (normal scenario), you see the parameters being
appended. I'm not sure if there is something weird about our code
that causes the "append" behaviour, but for now I'm assuming that
this is Tomcat's normal behaviour.
Normal behaviour: just before the call to
getRequestDispatcher().include(), we log the URI:
19 Jun 2014 4:30:16 PM org.apache.catalina.core.ApplicationContext log
INFO: Trace @ 2014-06-19 16:30:16.96 [system: TP-Processor24]
/full/include/view/book/detail.jsp?id=2691420082928&cached=false
web.Session$Site.include(Session.java:58)
Right thereafter, detail.jsp logs the actual parameters received:
19 Jun 2014 4:30:16 PM org.apache.catalina.core.ApplicationContext log
INFO: Trace @ 2014-06-19 16:30:16.961
[97A547EA5879F643AA717483B7165A39/null: TP-Processor24]
Parameters: id = [ 2691420082928, bdgc-269-g050 ]; cached =
false; page = detail;
web.tags.Log.doStartTag(Log.java:48)
Here, you see that the parameters from the include (id=2691420082928
and cached=false) are being prepended to the parameters on the
original request (id=bdgc-269-g050 and page = detail). Both ids are
in the array, with the included one as element 0. This is when
things are working normally. In the "ignore" scenario, the second
log would be:
Parameters: id = [ bdgc-269-g050 ]; cached = false;
In other words, the parameters from the URL passed to include(), are
ignored completely...
Thanks,
Michael.
Sorry, a typo in the "ignore" parameters above, the line should read:
Parameters: id = [ bdgc-269-g050 ]; page = detail;
And no
Re: Query string parameters not included by RequestDispatcher on Tomcat 6.0.36
On 2014/06/19 04:48 PM, Michael van Rooyen wrote:
On 2014/06/19 04:20 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 6/19/14, 9:43 AM, Michael van Rooyen wrote:
We've been running Tomcat 6.0.36 without issues for many months.
Our pages have many components and are constructed using
getRequestDispacher("...").include(request, response) to pull the
components in.
For the past few weeks, we've had a few instances where, in
constructing a page, the parameters in the query string passed to
getRequestDispatcher(), are not being passed through to the
components included.
For example, if a browser submits the request /main.jsp?id=foo,
then from that page, we include /product.jsp?id=bar, the
product.jsp page should see the following parameters:
id = [ bar, foo ]
This happens almost all the time, but sporadically, we're getting
just:
id = [ foo ] instead.
If the entry page was /main.jsp?cat=foobar, for example, then on
including /product.jsp?id=bar, we should get:
id = [ bar ], cat = [ foobar ]
But instead, we sometimes get just:
cat = [ foobar ]
Here is an extract from our logs. The first is just before the
call the getRequestDispatcher().include(), and shows the URI.
19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext
log INFO: Trace @ 2014-06-19 14:58:04.808 [system: TP-Processor7]
/full/include/view/generic/smallfeature.jsp?id=25951215082928&cached=true
web.Session$Site.include(Session.java:58)
And then the smallfeature.jsp logs the contents of the
parameterMap directly thereafter:
19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext
log INFO: Trace @ 2014-06-19 14:58:04.81
[993BE7ADFD65B94F2A62E85B64B3B8A2/null: TP-Processor7] Parameters:
cat = lcu; page = browse; web.tags.Log.doStartTag(Log.java:48)
You can see the id and cached parameters are missing, and the
parameters that are available are actually those from the main
page. Has anyone experienced this before, or know what may cause
it?
I think there is a hole in the spec, here, because Servlet Spec 3.0,
section 9.1.1 states:
"
Parameters specified in the query string used to create the
RequestDispatcher take precedence over other parameters of the same
name passed to the included servlet. The parameters associated with a
RequestDispatcher are scoped to apply only for the duration of the
include or forward call.
"
The term "take precedence" could be interpreted as "overriding
completely" (Tomcat's implementation) or "appending" (your
expectation), and I think I would agree with the current
implementation Tomcat appears to have: the "id" parameter in your
included query string completely replaces the "id" parameter that came
from the original request.
Short of a clarification of the Servlet spec, you are going to have to
do something else in order to fix this problem. Might I recommend the
use of a request /attribute/ instead of a query string parameter to
pass information from one resource to another for inclusion?
Thanks for the info Chris. The problem is that tomcat is not behaving
consistently - from what I see, Tomcat doesn't "override completely",
rather, it "appends". But sometimes, sporadically, it "ignores", and
when it does ignore, it breaks our site.
If you compare the two logs I listed earlier (the "ignore" scenario),
to two below (normal scenario), you see the parameters being
appended. I'm not sure if there is something weird about our code
that causes the "append" behaviour, but for now I'm assuming that this
is Tomcat's normal behaviour.
Normal behaviour: just before the call to
getRequestDispatcher().include(), we log the URI:
19 Jun 2014 4:30:16 PM org.apache.catalina.core.ApplicationContext log
INFO: Trace @ 2014-06-19 16:30:16.96 [system: TP-Processor24]
/full/include/view/book/detail.jsp?id=2691420082928&cached=false
web.Session$Site.include(Session.java:58)
Right thereafter, detail.jsp logs the actual parameters received:
19 Jun 2014 4:30:16 PM org.apache.catalina.core.ApplicationContext log
INFO: Trace @ 2014-06-19 16:30:16.961
[97A547EA5879F643AA717483B7165A39/null: TP-Processor24]
Parameters: id = [ 2691420082928, bdgc-269-g050 ]; cached = false;
page = detail;
web.tags.Log.doStartTag(Log.java:48)
Here, you see that the parameters from the include (id=2691420082928
and cached=false) are being prepended to the parameters on the
original request (id=bdgc-269-g050 and page = detail). Both ids are
in the array, with the included one as element 0. This is when things
are working normally. In the "ignore" scenario, the second log would be:
Parameters: id = [ bdgc-269-g050 ]; cached = false;
In other words, the parameters from the URL passed to include(), are
ignored completely...
Thanks,
Michael.
Sorry, a typo in the "ignore" parameters above, the line should read:
Parameters: id = [ bdgc-269-g050 ]; page = detail;
And not
Parameters: id = [ bdgc-269-g050 ]; cached = false
Re: Query string parameters not included by RequestDispatcher on Tomcat 6.0.36
On 2014/06/19 04:20 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 6/19/14, 9:43 AM, Michael van Rooyen wrote:
We've been running Tomcat 6.0.36 without issues for many months.
Our pages have many components and are constructed using
getRequestDispacher("...").include(request, response) to pull the
components in.
For the past few weeks, we've had a few instances where, in
constructing a page, the parameters in the query string passed to
getRequestDispatcher(), are not being passed through to the
components included.
For example, if a browser submits the request /main.jsp?id=foo,
then from that page, we include /product.jsp?id=bar, the
product.jsp page should see the following parameters:
id = [ bar, foo ]
This happens almost all the time, but sporadically, we're getting
just:
id = [ foo ] instead.
If the entry page was /main.jsp?cat=foobar, for example, then on
including /product.jsp?id=bar, we should get:
id = [ bar ], cat = [ foobar ]
But instead, we sometimes get just:
cat = [ foobar ]
Here is an extract from our logs. The first is just before the
call the getRequestDispatcher().include(), and shows the URI.
19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext
log INFO: Trace @ 2014-06-19 14:58:04.808 [system: TP-Processor7]
/full/include/view/generic/smallfeature.jsp?id=25951215082928&cached=true
web.Session$Site.include(Session.java:58)
And then the smallfeature.jsp logs the contents of the
parameterMap directly thereafter:
19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext
log INFO: Trace @ 2014-06-19 14:58:04.81
[993BE7ADFD65B94F2A62E85B64B3B8A2/null: TP-Processor7] Parameters:
cat = lcu; page = browse; web.tags.Log.doStartTag(Log.java:48)
You can see the id and cached parameters are missing, and the
parameters that are available are actually those from the main
page. Has anyone experienced this before, or know what may cause
it?
I think there is a hole in the spec, here, because Servlet Spec 3.0,
section 9.1.1 states:
"
Parameters specified in the query string used to create the
RequestDispatcher take precedence over other parameters of the same
name passed to the included servlet. The parameters associated with a
RequestDispatcher are scoped to apply only for the duration of the
include or forward call.
"
The term "take precedence" could be interpreted as "overriding
completely" (Tomcat's implementation) or "appending" (your
expectation), and I think I would agree with the current
implementation Tomcat appears to have: the "id" parameter in your
included query string completely replaces the "id" parameter that came
from the original request.
Short of a clarification of the Servlet spec, you are going to have to
do something else in order to fix this problem. Might I recommend the
use of a request /attribute/ instead of a query string parameter to
pass information from one resource to another for inclusion?
Thanks for the info Chris. The problem is that tomcat is not behaving
consistently - from what I see, Tomcat doesn't "override completely",
rather, it "appends". But sometimes, sporadically, it "ignores", and
when it does ignore, it breaks our site.
If you compare the two logs I listed earlier (the "ignore" scenario), to
two below (normal scenario), you see the parameters being appended. I'm
not sure if there is something weird about our code that causes the
"append" behaviour, but for now I'm assuming that this is Tomcat's
normal behaviour.
Normal behaviour: just before the call to
getRequestDispatcher().include(), we log the URI:
19 Jun 2014 4:30:16 PM org.apache.catalina.core.ApplicationContext log
INFO: Trace @ 2014-06-19 16:30:16.96 [system: TP-Processor24]
/full/include/view/book/detail.jsp?id=2691420082928&cached=false
web.Session$Site.include(Session.java:58)
Right thereafter, detail.jsp logs the actual parameters received:
19 Jun 2014 4:30:16 PM org.apache.catalina.core.ApplicationContext log
INFO: Trace @ 2014-06-19 16:30:16.961
[97A547EA5879F643AA717483B7165A39/null: TP-Processor24]
Parameters: id = [ 2691420082928, bdgc-269-g050 ]; cached = false;
page = detail;
web.tags.Log.doStartTag(Log.java:48)
Here, you see that the parameters from the include (id=2691420082928 and
cached=false) are being prepended to the parameters on the original
request (id=bdgc-269-g050 and page = detail). Both ids are in the
array, with the included one as element 0. This is when things are
working normally. In the "ignore" scenario, the second log would be:
Parameters: id = [ bdgc-269-g050 ]; cached = false;
In other words, the parameters from the URL passed to include(), are
ignored completely...
Thanks,
Michael.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBC-Pool: Reconnect the connection upon failures; retry queries; etc.
Hi Chris, There are 2 cases: - When we try to execute some statement and the connection is lost, we would like to retry some times, to show Popup Window to the client with notification, etc. - We have application, which depends on another database application. If the connection to Database is lost, then all applications must be shutdown. - All this problems, retries, etc., should be logged. Miro. On Thu, Jun 19, 2014 at 5:14 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Miro, > > On 6/19/14, 9:42 AM, Miroslav Nachev wrote: > > Is it possible to configure JDBC-Pool for the following > > functionality or I need to write my own interceptors and > > Validator? > > > > - Retry N times to getConnection() for OnBorrow/OnConnect and > > WhileIdle; - Wait X ms between each Retry. > > Why would you want to throttle reconnects? > > Usually this kind of thing is supported by your JDBC driver for things > like failover, etc. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTovBHAAoJEBzwKT+lPKRYDbUQAJ77mRkG7AN38FR102n7Lddn > FTnjnsH5FHgY5uVImi71IEcsMssKqe4bAbEVqfcTz2iZBUMhbHpe2Ik4iehJ2YOi > R+xH60DLVjjHi0Mmb80VmuRLEp7E8dVj/bCiAGwmo3kFCNCsxXjdsN4V/1YR4cJA > o9HIV62uUgAlhSd4SRsthP0WbjXmTX0U5h+F2tCl29MkqwL8Fn/OXnWRqd1/FuQk > 88u7dryQU4TZXSSioLLgNGdFRRNIdV5PZeqRA2hTylCjy2GFfCqG4IIIRRgsh32z > qUY627wksT+1hC6RQ3d6h551St1a1PFr82zgCvytKuoWL30yQFX7bc0lfr+fd18i > Vny3gN/OxDNIqBFmeedGT76Yf6k3UdKgtUeJ3SLDo0zWq7CUA/BYgaTz+Lgw8J2m > eKp/QfY18rgLFZg6c+W5vRxl1w9Pd3R30J+8Y28ZuU5xgYjF98hFxuEv2Oo+VqI7 > 4mH31uA4wVppx49L/xdR5eXL9w6HZuZlqiyAbdExv/aj4KvhNtYOyWMq8z+sg9Jr > KWMApBRnjJU1rIgZpUFWqVlbtJWFs7TAB270aa+445xbbOUDSRlanzNKpoIuRtxT > R3d+h6j6Onhqmx7DpeuMWOoJzG8UMOHYfezE++ZqM6lzGTQJxbyt30mKFSHgIR1A > vBY8ZJdn8wNBL9EIK/a4 > =LXZC > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Query string parameters not included by RequestDispatcher on Tomcat 6.0.36
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 6/19/14, 9:43 AM, Michael van Rooyen wrote:
> We've been running Tomcat 6.0.36 without issues for many months.
> Our pages have many components and are constructed using
> getRequestDispacher("...").include(request, response) to pull the
> components in.
>
> For the past few weeks, we've had a few instances where, in
> constructing a page, the parameters in the query string passed to
> getRequestDispatcher(), are not being passed through to the
> components included.
>
> For example, if a browser submits the request /main.jsp?id=foo,
> then from that page, we include /product.jsp?id=bar, the
> product.jsp page should see the following parameters:
>
> id = [ bar, foo ]
>
> This happens almost all the time, but sporadically, we're getting
> just:
>
> id = [ foo ] instead.
>
> If the entry page was /main.jsp?cat=foobar, for example, then on
> including /product.jsp?id=bar, we should get:
>
> id = [ bar ], cat = [ foobar ]
>
> But instead, we sometimes get just:
>
> cat = [ foobar ]
>
> Here is an extract from our logs. The first is just before the
> call the getRequestDispatcher().include(), and shows the URI.
>
> 19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext
> log INFO: Trace @ 2014-06-19 14:58:04.808 [system: TP-Processor7]
> /full/include/view/generic/smallfeature.jsp?id=25951215082928&cached=true
>
>
web.Session$Site.include(Session.java:58)
>
>
> And then the smallfeature.jsp logs the contents of the
> parameterMap directly thereafter:
>
> 19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext
> log INFO: Trace @ 2014-06-19 14:58:04.81
> [993BE7ADFD65B94F2A62E85B64B3B8A2/null: TP-Processor7] Parameters:
> cat = lcu; page = browse; web.tags.Log.doStartTag(Log.java:48)
>
>
> You can see the id and cached parameters are missing, and the
> parameters that are available are actually those from the main
> page. Has anyone experienced this before, or know what may cause
> it?
I think there is a hole in the spec, here, because Servlet Spec 3.0,
section 9.1.1 states:
"
Parameters specified in the query string used to create the
RequestDispatcher take precedence over other parameters of the same
name passed to the included servlet. The parameters associated with a
RequestDispatcher are scoped to apply only for the duration of the
include or forward call.
"
The term "take precedence" could be interpreted as "overriding
completely" (Tomcat's implementation) or "appending" (your
expectation), and I think I would agree with the current
implementation Tomcat appears to have: the "id" parameter in your
included query string completely replaces the "id" parameter that came
from the original request.
Short of a clarification of the Servlet spec, you are going to have to
do something else in order to fix this problem. Might I recommend the
use of a request /attribute/ instead of a query string parameter to
pass information from one resource to another for inclusion?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTovHDAAoJEBzwKT+lPKRYHvcQALJB3TIcPPbJMSmB//3vhFVP
+MJw/4uNlhAYs4qOdI73Eihc2gp6ygeoDBCbMi+OMVT5TfHKVWhdZJBEhKj330au
Z9nNdTGk1dmOs+totHeMv0EhAeEL432+sab7U+ub1j7cqK9j86NfTbmsUlTifiJm
AY+afDT39Dzq3PxOaKzchLrELQB6eVLLeUNFvpkx2rPpp1HCgxIRiwN5zb1X59lH
a4VikiR2SYEAm7bwWkTZOR1u6XTao3pAUIdWTY9kdfSvOWxijBEvY3Y8E3GihYEW
w+LStaLHJ/fOZsVPKsJuxpDD9TIDck2NbReXxZJw1SYBk/6AtK3iHWYE4TAaFQm8
wxRTvrtBpfEWEnW/dvoz5PRqH4WKjnyXJoUxxkmEPDOWmlTDrCqGnqWRm/1nTkWr
TU6ySbn3eoEfGmMBXilhauKmOJW+6QPI2kFtTDiY6e/ATgm4JLDdkkfZqKJdPwaN
vYpS/wRHAR2w8d/dghxiKrKG1pm+0VXuxNJ/KknLml3sBTnK++M7tFLGApDTSO+o
Gmp41VmGlXTv46SGots6DWg5BvPIj9t43OY9gJFD0loU3dwCf1PlaNq9h4PEjjiJ
cNhzvK0jyt0uLTfXsMU9LJopk1zli17a9JZmZFGm//+pWlkYlYIgGS0+pp64fmJI
J95/PRybwNQcLAS9tnCj
=Ys8z
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Ofcourse, I am not waiting :-) -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, June 19, 2014 7:44 PM To: Tomcat Users List Subject: Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Radha, On 6/19/14, 6:32 AM, Radha Krishna Meduri -X (radmedur - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > Thanks Konstantin. This is what I am asking in my very first mail. > Why can't we empty the value in case Cookie is expired. > > Konstantin Kolinko, According to your suggestion planning to use Value > to change the Cookie. In the invoke() method of Valve, I need to get > the list of Cookies and If the Cookie name is "JSESSIONIDSSO" , we can > empty the value. Can you confirm whether above approach works? Wouldn't it be faster to try it (2 minutes) than to post to the mailing list and wait for someone to get back to you (4 hours, at this moment)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTovARAAoJEBzwKT+lPKRYhSYP/3e1QBB752UJGpbNsUaSdHvA 8A5kVD3ENUr1IOYVVqNW+tbPmeTlCeDsImralFG8ziDdzZ5fFS1Dj5XGlE6SnWTk F7ej6TmpG+N5Sc78iIVPWeOAWv8QZsWF7nvDUltkWaqem6tcL38MT8sCc7hI/K+U FLdWjVkyXk8zUBIQKdqyElZMI9CSkgCnSN/miUo4tHMC8P3BbfXQAbAe0w1PgG9V 4PZ+2iEaRbUqNvfH7T9ZoCBjWHgdseVOakz1r1HFrgyQE+rmUYhzy8bvvV9wcHsf JEP+Z4qRZcW/pmX0OLQBzuekzmoXtTafHSBRD7j5lOpTGtgBW04YZR0JWbyBXnUH Mcz+8fkUhRjtHVAa/Jjc4ZYkMAmKFuX9hzrhEBA5ryPrICKltsmW5nUNsUMMvCq9 OZN/ZudlqIe8Cyj+oduPPXSJivb35oMrTd5IWdFcEL9uVejG9Q7FxFupV63/LiQT Dn7uass4SWIxpJIp9J7Ea73UVMJQh/TfmCL4n9Oin5Ab1rEdFX2JtA345oZiuGRl fkmIVOZ0agSEMOISimV8Li5g/p0ezRpTkU3e2PktLKxIsqsrNp4Epkk2w/t41Eiq suSqUREMKA3KmxtLsJhuhynm10X7MQX9K5RIiPaJT1PdXhgkieeeT8czvUoblGm1 quN5VgZGv1wbGx8m/OKA =dWVv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBC-Pool: Reconnect the connection upon failures; retry queries; etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Miro, On 6/19/14, 9:42 AM, Miroslav Nachev wrote: > Is it possible to configure JDBC-Pool for the following > functionality or I need to write my own interceptors and > Validator? > > - Retry N times to getConnection() for OnBorrow/OnConnect and > WhileIdle; - Wait X ms between each Retry. Why would you want to throttle reconnects? Usually this kind of thing is supported by your JDBC driver for things like failover, etc. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTovBHAAoJEBzwKT+lPKRYDbUQAJ77mRkG7AN38FR102n7Lddn FTnjnsH5FHgY5uVImi71IEcsMssKqe4bAbEVqfcTz2iZBUMhbHpe2Ik4iehJ2YOi R+xH60DLVjjHi0Mmb80VmuRLEp7E8dVj/bCiAGwmo3kFCNCsxXjdsN4V/1YR4cJA o9HIV62uUgAlhSd4SRsthP0WbjXmTX0U5h+F2tCl29MkqwL8Fn/OXnWRqd1/FuQk 88u7dryQU4TZXSSioLLgNGdFRRNIdV5PZeqRA2hTylCjy2GFfCqG4IIIRRgsh32z qUY627wksT+1hC6RQ3d6h551St1a1PFr82zgCvytKuoWL30yQFX7bc0lfr+fd18i Vny3gN/OxDNIqBFmeedGT76Yf6k3UdKgtUeJ3SLDo0zWq7CUA/BYgaTz+Lgw8J2m eKp/QfY18rgLFZg6c+W5vRxl1w9Pd3R30J+8Y28ZuU5xgYjF98hFxuEv2Oo+VqI7 4mH31uA4wVppx49L/xdR5eXL9w6HZuZlqiyAbdExv/aj4KvhNtYOyWMq8z+sg9Jr KWMApBRnjJU1rIgZpUFWqVlbtJWFs7TAB270aa+445xbbOUDSRlanzNKpoIuRtxT R3d+h6j6Onhqmx7DpeuMWOoJzG8UMOHYfezE++ZqM6lzGTQJxbyt30mKFSHgIR1A vBY8ZJdn8wNBL9EIK/a4 =LXZC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Radha, On 6/19/14, 6:32 AM, Radha Krishna Meduri -X (radmedur - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > Thanks Konstantin. This is what I am asking in my very first mail. > Why can't we empty the value in case Cookie is expired. > > Konstantin Kolinko, According to your suggestion planning to use > Value to change the Cookie. In the invoke() method of Valve, I need > to get the list of Cookies and If the Cookie name is > "JSESSIONIDSSO" , we can empty the value. Can you confirm whether > above approach works? Wouldn't it be faster to try it (2 minutes) than to post to the mailing list and wait for someone to get back to you (4 hours, at this moment)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTovARAAoJEBzwKT+lPKRYhSYP/3e1QBB752UJGpbNsUaSdHvA 8A5kVD3ENUr1IOYVVqNW+tbPmeTlCeDsImralFG8ziDdzZ5fFS1Dj5XGlE6SnWTk F7ej6TmpG+N5Sc78iIVPWeOAWv8QZsWF7nvDUltkWaqem6tcL38MT8sCc7hI/K+U FLdWjVkyXk8zUBIQKdqyElZMI9CSkgCnSN/miUo4tHMC8P3BbfXQAbAe0w1PgG9V 4PZ+2iEaRbUqNvfH7T9ZoCBjWHgdseVOakz1r1HFrgyQE+rmUYhzy8bvvV9wcHsf JEP+Z4qRZcW/pmX0OLQBzuekzmoXtTafHSBRD7j5lOpTGtgBW04YZR0JWbyBXnUH Mcz+8fkUhRjtHVAa/Jjc4ZYkMAmKFuX9hzrhEBA5ryPrICKltsmW5nUNsUMMvCq9 OZN/ZudlqIe8Cyj+oduPPXSJivb35oMrTd5IWdFcEL9uVejG9Q7FxFupV63/LiQT Dn7uass4SWIxpJIp9J7Ea73UVMJQh/TfmCL4n9Oin5Ab1rEdFX2JtA345oZiuGRl fkmIVOZ0agSEMOISimV8Li5g/p0ezRpTkU3e2PktLKxIsqsrNp4Epkk2w/t41Eiq suSqUREMKA3KmxtLsJhuhynm10X7MQX9K5RIiPaJT1PdXhgkieeeT8czvUoblGm1 quN5VgZGv1wbGx8m/OKA =dWVv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Query string parameters not included by RequestDispatcher on Tomcat 6.0.36
Hello,
We've been running Tomcat 6.0.36 without issues for many months. Our
pages have many components and are constructed using
getRequestDispacher("...").include(request, response) to pull the
components in.
For the past few weeks, we've had a few instances where, in constructing
a page, the parameters in the query string passed to
getRequestDispatcher(), are not being passed through to the components
included.
For example, if a browser submits the request /main.jsp?id=foo, then
from that page, we include /product.jsp?id=bar, the product.jsp page
should see the following parameters:
id = [ bar, foo ]
This happens almost all the time, but sporadically, we're getting just:
id = [ foo ] instead.
If the entry page was /main.jsp?cat=foobar, for example, then on
including /product.jsp?id=bar, we should get:
id = [ bar ], cat = [ foobar ]
But instead, we sometimes get just:
cat = [ foobar ]
Here is an extract from our logs. The first is just before the call the
getRequestDispatcher().include(), and shows the URI.
19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext log
INFO: Trace @ 2014-06-19 14:58:04.808 [system: TP-Processor7]
/full/include/view/generic/smallfeature.jsp?id=25951215082928&cached=true
web.Session$Site.include(Session.java:58)
And then the smallfeature.jsp logs the contents of the parameterMap
directly thereafter:
19 Jun 2014 2:58:04 PM org.apache.catalina.core.ApplicationContext log
INFO: Trace @ 2014-06-19 14:58:04.81
[993BE7ADFD65B94F2A62E85B64B3B8A2/null: TP-Processor7]
Parameters: cat = lcu; page = browse;
web.tags.Log.doStartTag(Log.java:48)
You can see the id and cached parameters are missing, and the parameters
that are available are actually those from the main page. Has anyone
experienced this before, or know what may cause it?
Thanks,
Michael.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
JDBC-Pool: Reconnect the connection upon failures; retry queries; etc.
Hi All, Is it possible to configure JDBC-Pool for the following functionality or I need to write my own interceptors and Validator? - Retry N times to getConnection() for OnBorrow/OnConnect and WhileIdle; - Wait X ms between each Retry. Are there any examples? Regards, Miro.
Re: Connection count explosion due to thread http-nio-80-ClientPoller-x death
2014-06-19 17:10 GMT+04:00 Lars Engholm Johansen : > I will try to force a GC next time I am at the console about to restart a > Tomcat where one of the http-nio-80-ClientPoller-x threads have died and > connection count is exploding. > > But I do not see this as a solution - can you somehow deduct why this > thread died from the outcome from a GC? Nobody said that a thread died because of GC. The GC that Andre suggested was to get rid of some of CLOSE_WAIT connections in netstat output, in case if those are owned by some abandoned and non properly closed I/O classes that are still present in JVM memory. > And could an Exception/Error in Tomcat thread http-nio-80-ClientPoller-0 > or http-nio-80-ClientPoller-1 make the thread die with no Stacktrace in > the Tomcat logs? > A critical error (java.lang.ThreadDeath, java.lang.VirtualMachineError) will cause death of a thread. A subtype of the latter is java.lang.OutOfMemoryError. As of now, such errors are passed through and are not logged by Tomcat, but are logged by java.lang.ThreadGroup.uncaughtException(). ThreadGroup prints them to System.err (catalina.out). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection count explosion due to thread http-nio-80-ClientPoller-x death
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lars, On 6/16/14, 5:40 AM, Lars Engholm Johansen wrote: > Our sites can run for days without problems, but once in a while > the tomcat connection count suddenly starts growing abnormally > fast. See this graph: http://imgur.com/s4fOUte netstat shows these > TCP connections to be mostly in CLOSE_WAIT state. > > Our sites still functions normally with no cpu spikes during this > build up until around 60,000 connections, but then the server > refuses further connections and a manual Tomcat restart is > required. > > We have no output in tomcat or our logs at the time when this event > occurs. The only sign is when comparing full java thread dump with > a dump from a newly launched Tomcat: One of > http-nio-80-ClientPoller-0 or http-nio-80-ClientPoller-1 is > missing/has died. If the poller thread has died, you are completely SOL. Is there no indication in any log why the poller thread died? Particularly, check catalina.out for OOME or an exception that might kill such a thread. Can you configure your logger to increase the log level for the poller component? Actually, the NIO Poller only contains log.error messages except for 2 @ debug that indicate encountering JDK 1.5 bugs, so changing the log level probably won't help. The only other thing that looks like it might cause complications would be an OOME, which should definitely show up in the logs. > Our connector configuration: acceptorThreadCount="4" Have you observed a performance increase by setting acceptorThreadCount to 4 instead of a lower number? I'm just curious. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTouYeAAoJEBzwKT+lPKRYf98P/0kYjX8jH1ZCvZ/FS9hXnYBw hJtrcYHYe6ulPJLz66QU0FY0xNlu6ADISukW1njqcr7Cz/WJ8nIQI6fXnOVgcZj1 F/JLj4OhKQP8b0WA6NkN0KTtRBt/OsIZx4pp/VHBuBbkr2c/B7Ixfh3a15/XZjrl TGa+KMUIvJp/gBuLCsrvmY39SACCfKvVAL6soe6+4LozURSpv/OdGBgitbiHY8sf AqB2g4+psltMI5VGXC/wSPpmnIGfalgFyX1o1EshBeiz6sg6YejjHY5NI/eLcdW4 nfKRz+Dbm0y/uY3fs7U7tOvI2rhbXBXwu1XoscoGzlRaB4pD5nJLdIpczH4vBu2r vjKyVE2v1QitpMr/hzsZkngSkiPe7JtnrQIQGqJ+pvgdtbpWhmOmG8OcCLR3xxH5 1arfgscgxCzH0apwuWZmO2kUXqDk9z7qyHuGHOMwFcoFfHaNUF6C83tlKEnGM0ME pc+pCRwwVOIoLllVo1WizALFv/oI3MiWxs8C5FhibYqzpWAR1E6zfUz9YVarCqiV F8Cu56mVlTD9bdtunvutfVcByOuVEqxw1cMKS5nVTKueKqIi1nKh8nr9c8OAK1QP D0CeHAC6EDTTKjxUmRzApEq8LhrSCJVY6XxNdck1qeVoWp7nceQs5yrPW6t/70pE BAbG0nqUNjrPqaJP98w9 =A3kD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection count explosion due to thread http-nio-80-ClientPoller-x death
I will try to force a GC next time I am at the console about to restart a Tomcat where one of the http-nio-80-ClientPoller-x threads have died and connection count is exploding. But I do not see this as a solution - can you somehow deduct why this thread died from the outcome from a GC? And could an Exception/Error in Tomcat thread http-nio-80-ClientPoller-0 or http-nio-80-ClientPoller-1 make the thread die with no Stacktrace in the Tomcat logs? (This problem is quite critical for our production environment) On Mon, Jun 16, 2014 at 5:56 PM, André Warnier wrote: > Lars Engholm Johansen wrote: > >> Our company are running several Tomcat 7.0.52 high volume Ubuntu 12.04 >> production servers. >> We are using Tomcat WebSockets (JSR356 implementation) heavily with 100M >> text messages (100GiB) per day. >> >> We monitor webserver health by measuring several key parameters every >> minute, including tomcat connection count using: >> >> mBeanServer.getAttribute(threadPool, "connectionCount"); // >> threadPool is MBean of "type=ThreadPool" >> >> __The problem__ >> >> Our sites can run for days without problems, but once in a while the >> tomcat >> connection count suddenly starts growing abnormally fast. >> See this graph: http://imgur.com/s4fOUte >> netstat shows these TCP connections to be mostly in CLOSE_WAIT state. >> > > And if at that moment, you force the JVM that runs Tomcat to do a Garbage > Collection, do you still have these numerous connections in CLOSE_WAIT > state after the GC completed ? > > > >> Our sites still functions normally with no cpu spikes during this build up >> until around 60,000 connections, but then the server refuses further >> connections and a manual Tomcat restart is required. >> >> We have no output in tomcat or our logs at the time when this event >> occurs. >> The only sign is when comparing full java thread dump with a dump from a >> newly launched Tomcat: >> One of http-nio-80-ClientPoller-0 or http-nio-80-ClientPoller-1 is >> missing/has died. >> >> We have observed this problem at least since Tomcat 7.0.48 and can not >> find >> indications in Tomcat 7.0.x change logs that it should have been fixed in >> newer releases. >> >> Any help or advises are appreciated, >> Best regards, >> Lars Engholm Johansen >> >> >> Our connector configuration: >> > acceptCount="1500" >> acceptorThreadCount="4" >> asyncTimeout="10" >> connectionTimeout="6" >> connectionUploadTimeout="12" >> disableUploadTimeout="false" >> enableLookups="false" >> keepAliveTimeout="12" >> maxConnections="10" >> maxPostSize="300" >> maxThreads="300" >> port="80" >> protocol="org.apache.coyote.http11.Http11NioProtocol" >> socket.soKeepAlive="true" >> /> >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Thanks Konstantin. This is what I am asking in my very first mail. Why can't we empty the value in case Cookie is expired. Konstantin Kolinko, According to your suggestion planning to use Value to change the Cookie. In the invoke() method of Valve, I need to get the list of Cookies and If the Cookie name is "JSESSIONIDSSO" , we can empty the value. Can you confirm whether above approach works? -Original Message- From: Konstantin Preißer [mailto:kpreis...@apache.org] Sent: Wednesday, June 18, 2014 9:35 PM To: 'Tomcat Users List' Subject: RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat Hi, > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, June 18, 2014 4:23 PM > To: Tomcat Users List > Subject: Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Konstantin, > > On 6/18/14, 5:34 AM, Konstantin Kolinko wrote: > > 2014-06-18 11:57 GMT+04:00 Konstantin Kolinko > > : > >>> > >>> HTTP/1.1 302 Found Set-Cookie: > >>> JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Expires=Thu, > >>> 01-Jan-1970 00:00:10 GMT Pragma: No-cache Cache-Control: > >>> no-cache Expires: Thu, 01 Jan 1970 00:00:00 UTC Set-Cookie: > >>> JSESSIONID=235F4293591E5C72859317ED3294C5A5; Path=/admin; Secure; > >>> HttpOnly Location: https://X.Y.A.B/admin/login.jsp > >>> Content-Length: 0 Date: Tue, 17 Jun 2014 16:21:17 GMT Server: > >>> XYZ > >>> > >> > >> With that value of "Expires" the cookie is actually being cleared, > >> not set. > >> > > > > The 'Secure' flag says that the browser should never send the cookie > > to the server over a non-secure connection. > > > > When the cookie is being cleared, the "Secure" flag is irrelevant, > > as the cookie will not be sent back by the browser. > > +1 > > > The "HttpOnly" flag says that the cookie should not be accessible > > from Javascript code running in the browser. If the cookie is being > > deleted, is there a way to access it from Javascript? I think that > > there is no such way. > > +1 > > I think this is a spurious error being flagged by the security > scanner. Adding "HttpOnly" and "Secure" flags to the "expire" > Set-Cookie header is just a waste of bytes because they have no effect > whatsoever on what the client does with the cookie (it always deleted > it, unless the system clock is set horribly wrong). I haven't followed all of this discussion, but as for deleting a Cookie, I think the problem is that there isn't an explicit "Delete-Cookie" header; but instead the server has to send the cookie name with a "Expires" flag that is in the past. In this case, I think if the original cookie contained a "Secure" and "HttpOnly" flag, then the Set-Cookie header which deletes the cookie by setting an "Expire" date in the past also should set the "Secure" and "HttpOnly" flags. Although it is unlikely that the client will send back a Cookie which expires in 1970, it would be possible if the client's system date is set wrong, so IMHO this is not an exact "delete this cookie" instruction and therefore the "Expire" Set-Cookie header should include the same HttpOnly and Secure flags that were included in the original Set-Cookie header. Also, when deleting a cookie, I think it might be better to send a Set-Cookie header with an empty value, so that the value is overwritten by the browser if for some reason the cookie is not yet expired. E.g., instead of Set-Cookie: JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Expires=Thu, 01-Jan-1970 00:00:10 GMT the server could send: Set-Cookie: JSESSIONIDSSO=; Expires=Thu, 01-Jan-1970 00:00:10 GMT (RFC6265 Section 3.1 shows an example where a cookie is deleted this way) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 JDBCStore session keep being reset
On 19/06/2014 06:14, Johanes Soetanto wrote: > Is there some advice on how to debug our issues? or is there some obvious > configuration issue that we have? Thanks for all the advice beforehand. Check the system clocks on your production machines. Add a session listener to log the stakctrace when a session is destroyed. Add session ID to the access logs and review them for unexpectedly closed sessions. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
