From: sophana <so...@zi...> - 2007-08-04 23:21:42
|
Hi While trying to debug my webware application, I tried to stress it with a simple wget loop. I saw that memory was increasing. After searching a little, I found out that it was webware sessions that were growing up to the max dynamic session limit. Using cookie option of wget made no more session creation... My application set a session variable at each visit.. So I though it is a normal behaviour. But I have a page which is dedicated to monitoring. I thought that by making the monitoring servlet a subclass of Page, webware would no more allocate a new session at each wget access. But it does allocate a session at each wget access! Is it normal that a session is created even if I don't use it? How can I prevent webware from creating a session? Thanks for your help |
From: Chuck E. <chu...@gm...> - 2007-08-04 23:35:19
|
On 8/4/07, sophana <so...@zi...> wrote: > Hi > > While trying to debug my webware application, I tried to stress it with > a simple wget loop. > I saw that memory was increasing. > After searching a little, I found out that it was webware sessions that > were growing up to the max dynamic session limit. > Using cookie option of wget made no more session creation... > > My application set a session variable at each visit.. So I though it is > a normal behaviour. > But I have a page which is dedicated to monitoring. I thought that by > making the monitoring servlet a subclass of Page, webware would no more > allocate a new session at each wget access. > But it does allocate a session at each wget access! > Is it normal that a session is created even if I don't use it? > How can I prevent webware from creating a session? > > Thanks for your help If you never access self.session() then it should not be created. But as soon as you do, I don't see how WebKit has any other choice but to create it. You can safely check for a session without creating one with self.transaction().hasSession() and then only update the session if there is one. Several of my apps have done so to avoid the problem you describe. -Chuck |
From: sophana <so...@zi...> - 2007-08-04 23:42:18
|
Chuck Esterbrook a écrit : > On 8/4/07, sophana <so...@zi...> wrote: > >> Hi >> >> While trying to debug my webware application, I tried to stress it with >> a simple wget loop. >> I saw that memory was increasing. >> After searching a little, I found out that it was webware sessions that >> were growing up to the max dynamic session limit. >> Using cookie option of wget made no more session creation... >> >> My application set a session variable at each visit.. So I though it is >> a normal behaviour. >> But I have a page which is dedicated to monitoring. I thought that by >> making the monitoring servlet a subclass of Page, webware would no more >> allocate a new session at each wget access. >> But it does allocate a session at each wget access! >> Is it normal that a session is created even if I don't use it? >> How can I prevent webware from creating a session? >> >> Thanks for your help >> > > If you never access self.session() then it should not be created. But > as soon as you do, I don't see how WebKit has any other choice but to > create it. > > You can safely check for a session without creating one with > self.transaction().hasSession() and then only update the session if > there is one. Several of my apps have done so to avoid the problem you > describe. > > The monitoring servlet is a subclass of WebKit.Page All it does it make an sql ping, and write 'success' to the output. It does not use any session. But my simple test is as follow. - I shut down the appserver. - erase all session files - restart AppServer - make a wget loop on the monitoring servlet. - shutdown again - then I see a LOT session created. note that the test is made on 0.9.2 webware... They are not created if I use the cookie session option of wget. Could someone please check? Thanks |
From: Christoph Z. <ci...@on...> - 2007-08-30 08:45:47
|
sophana wrote: > The monitoring servlet is a subclass of WebKit.Page > All it does it make an sql ping, and write 'success' to the output. > It does not use any session. > But my simple test is as follow. > - I shut down the appserver. > - erase all session files > - restart AppServer > - make a wget loop on the monitoring servlet. > - shutdown again > - then I see a LOT session created. note that the test is made on 0.9.2 > webware... > They are not created if I use the cookie session option of wget. Is this still an open issue? If yes, can you check with 0.9.4 or send me your monitoring servlet and the wget commands/script you are using? I'll try to reproduce it here. -- Christoph |
From: Ben P. <be...@pa...> - 2007-10-09 06:25:50
|
Christoph Zwerschke wrote on 8/30/07 1:45 AM: > sophana wrote: > >> The monitoring servlet is a subclass of WebKit.Page >> All it does it make an sql ping, and write 'success' to the output. >> It does not use any session. >> But my simple test is as follow. >> - I shut down the appserver. >> - erase all session files >> - restart AppServer >> - make a wget loop on the monitoring servlet. >> - shutdown again >> - then I see a LOT session created. note that the test is made on 0.9.2 >> webware... >> They are not created if I use the cookie session option of wget. >> > > Is this still an open issue? If yes, can you check with 0.9.4 or send me > your monitoring servlet and the wget commands/script you are using? I'll > try to reproduce it here. > > > If nobody else has figured this one out, I just did. We use a database backed session store and I came across this after noticing extra db hits for pages which did not use the session. The problem is that HTTPResponse.recordSession() is referencing transaction.session() instead of transaction._session when checking for the existence of (and therefore need to save/send cookie for) the Session. The session() method creates the session if it did not exist, which defeats the purposes of what recordSession() is trying to do, and ends up creating a Session object for every request. The bugfix patch against Webware 0.9.4 or 0.9.3 is very simple. I'll submit this to sourceforge shortly: $ diff HTTPResponse.original.py HTTPResponse.py 348c348 < sess = trans.session() --- > sess = trans._session |
From: Christoph Z. <ci...@on...> - 2007-10-13 11:13:42
|
Ben Parker wrote: > If nobody else has figured this one out, I just did. We use a database > backed session store and I came across this after noticing extra db hits > for pages which did not use the session. > > The problem is that HTTPResponse.recordSession() is referencing > transaction.session() instead of transaction._session when checking for > the existence of (and therefore need to save/send cookie for) the > Session. The session() method creates the session if it did not exist, > which defeats the purposes of what recordSession() is trying to do, and > ends up creating a Session object for every request. Thanks a lot for the patch, I have applied this in r7032. Strange that nobody had noticed this so far. Actually, there is also a hasSession() method, but checking the _session attribute is the right thing here. The cookie needs only be sent when the session really has been used. -- Chris |