On Fri, Apr 11, 2008 at 6:37 PM, Jeremy Thomerson <[EMAIL PROTECTED]> wrote: > 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.
as far as i know jsessionid is only appended once an http session is created and needs to be tracked. so the fact you see it right after you go to /app/home should tell you that right away the session is created and bound. not good. something in your page is stateful. > 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. i think this is unlikely. if i remember correctly delayed session creation was introduced in 1.3.0. 1.2.6 _always created a session on first request_ regardless of whether or not the page you requested was stateless or stateful. -igor > > 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 > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
