Ok if you dont strip the jsessionid again (like they do or trying to
do in the other thread where you also replied on) then maybe there is
now a crawler thats strips it when it sees it and sends the stripped
version back to you, if somebody does that then sessions are created
in a very fast way.
You could also try to detect the spider and set its session timeout
(if one was created) to 1 minute or so... Detecting the bots shouldn't
be too hard iiuc some of the articles on robots.txt
Martijn
On 4/12/08, Johan Compagner [EMAIL PROTECTED] wrote:
Ok if you dont strip the jsessionid again
If you hit a wall in terms of decreasing session timeout or
deferring/avoiding session creation, you might want to look at Tomcat's
PersistentManager. It passivates idle (but non-expired) sessions out of RAM
to either disk or a database. The JDBC version should give you better
performance and more
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
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
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
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
which wicket does for every url via webrequest.encodeurl or something
like that. of course if you subclass webrequest and dont forward the
encodeurl to httpservletrequest you effectively strip jsessionid from
the urls.
-igor
On Fri, Apr 11, 2008 at 6:53 PM, James Carman
[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
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 often 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
try a breakpoint in ISessionStore.bind() - that is where the wicket
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.
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
Jeremy,
A workaround is to make the session timeout way lower and add some keep
alive javascript to each page. For example as described by Eelco
(http://chillenious.wordpress.com/2007/06/19/how-to-create-a-text-area-with-a-heart-beat-with-wicket/).
Regards,
Erik.
Jeremy Thomerson wrote:
Thanks for the tip. I came up with an idea last night that I would like to
get input on. I created an HttpSessionListener that will track all created
sessions. It has a thread that will run every few minutes, and if a session
does not belong to a signed-in user, it will invalidate it after only
Hi,
On Thu, Apr 10, 2008 at 6:40 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
httpsession already has a settimeout no? so once a user logs in you
can set it to a longer period
We use that technique (not on a wicket app though) and it seems to work.
Something else to consider: Do you want
Thanks for the suggestion - I may just go that route instead of my own
listener.
As far as Google - yes! We're a public community site (for hunting and
fishing in Texas), and almost all of our non-repeat traffic comes from
search engines, so we must be highly ranked. We're #2 in Google for
I finally am able to get a good analysis of it. It dumped two memory dumps
when it died in the past couple days (it's still dying about once or twice a
day). Using this GREAT tool:
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Java/Java+Memory+AnalysisI
am able to see deep memory views that
4585 tomcat sessions?
thats quite large if may say that..
and even more 10 wicket sessions that tomcat sessions
Do you have multiply apps deployed on that server?
if a search engine doesnt send a cookie back then the urls should be encoded
with jsessionid
and we get the session from that..
Yes - quite large. I'm hoping someone has an idea to overcome this. There
were definitely not 4500+ unique users on the site at the time.
There were two copies of the same app deployed on that server at the time -
one was a staging environment, not being indexed, which is probably where
the
You can use as many anonymous inner classes as you like. I have them coming
out of my ears, personally.
It's very odd for tomcat to die with no output. There will be output
somewhere. Check logs/catalina.out and also logs/localhost*. If the JVM
dies, it will hotspot or even segfault and log that,
The oddness is what baffles me: Tomcat has no output anywhere. I have
grepped and tailed the entire Tomcat logs directory, stdout*, stderr*,
localhost*, etc. Nothing in eventvwr.
It must be memory related, though. There is a steadily increasing memory
footprint - it was increasing so fast
Nope - one page never holds on to another. I never even pass pages into
another page or link or something as a reference.
Interestingly, I DECREASED the memory the JVM could have from 1.5 GB to 1.0
GB today, and it has been stable all day (after also releasing a version
using Wicket 1.3.3).
There are commandline options for the jvm to dump on OOM.
Anyway, doesn't the log file give any insight into what is happening
in your application? Did you (or your sysadmin) disable logging for
Wicket?
You can also run external tools to see what is happening inside your
JVM without blocking the
23 matches
Mail list logo
