Just make sure you are not receiving more than 90 requests from search engines an hour. If you are you may want to set up a robots.txt (http://www.robotstxt.org/) and a sitemap (http://www.sitemaps.org/).
On Sat, Apr 12, 2008 at 1:20 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > try a breakpoint in ISessionStore.bind() - that is where the wicke > session is pushed into httpsession > > -igor > > > On Fri, Apr 11, 2008 at 9:26 PM, Jeremy Thomerson > > > <[EMAIL PROTECTED]> wrote: > > Thanks for the insight - didn't know that the webapp had to make a call to > > force the cookie-less support. Someone asked for how if your Google is > > crawling us. It seems like at any given point of almost any day, we have > > one crawler or another going through the site. I included some numbers > > below to give an idea. > > > > Igor - thanks - it could easily be the search form, which is the only > thing > > that would be stateful on about 95% of the pages that will be crawled. I > > made myself a note yestereday that I need to look at making that a > stateless > > form to see if that fixes the unnecessary session creation. I'll post the > > results. > > > > The one thing I have determined from all this (which answers a question > from > > the other thread) is that Google (and the other crawlers) is definitely > > going to pages with a jsessionid in the URL, and the jsessionid is not > > appearing in the search results (with 2 exceptions out of 30,000+ pages > > indexed). But I know that maybe only a month ago, there were hundreds of > > pages from our site that had jsessionids in the URLs that Google had > > indexed. Could it be possible that they are stripping the jsessionid from > > URLs they visit now? I haven't found anywhere that they volunteer much > > information on this matter. > > > > Bottom line - thanks for everyone's help - I have a bandaid on this now > > which will buy me the time to see what's creating the early unnecessary > > sessions. Is there a particular place in the code I should put a > breakpoint > > to see where the session is being created / where it says "oh, you have a > > stateful page - here's the component that makes it stateful"? That's > where > > I'm headed next, so if anyone knows where that piece of code is, the tip > > would be greatly appreciated. > > > > Thanks again, > > Jeremy > > > > Here's a few numbers for the curious. I took a four minute segment of our > > logs from a very slow traffic period - middle of the night. In that time, > > 67 sessions were created. Then did reverse DNS lookups on the IPs. The > > traffic was from: > > > > cuill.com crawler 4 (interesting - new search engine - didn't know > > about it before) > > googlebot 4 > > live.com bot 1 > > unknown 13 > > user 28 > > yahoo crawler 26 > > > > > > > > > > On Fri, Apr 11, 2008 at 9:20 PM, Igor Vaynberg <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > 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] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ryan Gravener http://ryangravener.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
