Are you storing a lot of variables in your session? Also how often is google visiting your site?
On Fri, Apr 11, 2008 at 9:37 PM, Jeremy Thomerson <[EMAIL PROTECTED]> wrote: > 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 > > > > > > -- Ryan Gravener http://ryangravener.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
