Thanks for your not very helpful email, but unfortunately, you're wrong. In that other email, I did say "But, most don't (have jsessionid) because almost all of my links are bookmarkable." I don't strip out jsessionid - I don't think you even can without disabling cookieless support - your container adds the jsessionid to links in your returned HTML - it's not like you add it (or remove it) manually.
If you go to http://www.texashuntfish.com/thf/app/home, you will notice that the first time you hit the page, there are jsessionids in every link - same if you go there with cookies disabled. This won't happen if you just go to http://www.texashuntfish.com/ because it does a redirect, and you end up sending cookies back, and no jsessionid is needed. I really don't know why Google doesn't index the jsessionid in our URLs - we have 30,600 pages in Google indexes[1], and only two have jsessionid[2]. If anyone is interested, a slightly modified version of the code (just setting different expiration lengths depending on signed in / not signed in) I pasted in pastebin (linked in an earlier email) worked - we're maintaining 100-300 sessions now, and no crashes in the past 24 hours it's been running. This isn't a fix - it's a bandaid. I think this problem is caused by something making the session bind at an earlier time than it did when I was using 1.2.6 - it's probably still something that I'm doing weird, but I need to find it. Looking at the logs, we're still having one to two sessions created every second - they're just getting cleaned up better now. [1] - http://www.google.com/search?q=site%3Atexashuntfish.com&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a [2] - http://www.google.com/search?hl=en&safe=off&client=firefox-a&rls=com.ubuntu%3Aen-US%3Aofficial&hs=bFp&q=site%3Atexashuntfish.com+inurl%3Ajsessionid&btnG=Search On Fri, Apr 11, 2008 at 3:33 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > by the way it is all your own fault that you get so many session. > I just searched for your other mails and i did came across: "Removing the > jsessionid for SEO" > > where you where explaining that you remove the jsessionids from the urls.. > > johan > > > On Thu, Apr 3, 2008 at 7:23 AM, Jeremy Thomerson < > [EMAIL PROTECTED]> > wrote: > > > I upgraded my biggest production app from 1.2.6 to 1.3 last week. I > have > > had several apps running on 1.3 since it was in beta with no problems - > > running for months without restarting. > > > > This app receives more traffic than any of the rest. We have a decent > > server, and I had always allowed Tomcat 1.5GB of RAM to operate with. > It > > never had a problem doing so, and I didn't have OutOfMemory errors. > Now, > > after the upgrade to 1.3.2, I am having all sorts of trouble. It ran > for > > several days without a problem, but then started dying a couple times a > > day. Today it has died four times. Here are a couple odd things about > > this: > > > > - On 1.2.6, I never had a problem with stability - the app would run > > weeks between restarts (I restart once per deployment, anywhere from > > once a > > week to at the longest about two months between deploy / restart). > > - Tomcat DIES instead of hanging when there is a problem. Always > > before, if I had an issue, Tomcat would hang, and there would be OOM > in > > the > > logs. Now, when it crashes, and I sign in to the server, Tomcat is > not > > running at all. There is nothing in the Tomcat logs that says > anything, > > or > > in eventvwr. > > - I do not get OutOfMemory error in any logs, whereas I have always > > seen it in the logs before when I had an issue with other apps. I am > > running Tomcat as a service on Windows, but it writes stdout / stderr > to > > logs, and I write my logging out to logs, and none of these logs > include > > ANY > > errors - they all just suddenly stop at the time of the crash. > > > > My money is that it is an OOM error caused by somewhere that I am doing > > something I shouldn't be with Wicket. There's no logs that even say it > is > > an OOM, but the memory continues to increase linearly over time as the > app > > runs now (it didn't do that before). My first guess is my previous > > proliferate use of anonymous inner classes. I have seen in the email > > threads that this shouldn't be done in 1.3. > > > > Of course, the real answer is that I'm going to be digging through > > profilers > > and lines of code until I get this fixed. > > > > My question, though, is from the Wicket devs / experienced users - where > > should I look first? Is there something that changed between 1.2.6 and > > 1.3 > > that might have caused me problems where 1.2.6 was more forgiving? > > > > I'm running the app with JProbe right now so that I can get a snapshot > of > > memory when it gets really high. > > > > Thank you, > > Jeremy Thomerson > > >
