Webware for Python

On 8/4/07, sophana <sophana@...> 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

Chuck Esterbrook a écrit :
> On 8/4/07, sophana <sophana@...> 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

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

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

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