Re: 3.2

2005-07-28 Thread Jim Gallacher

Jim Gallacher wrote:

Jim Gallacher wrote:


Gregory (Grisha) Trubetskoy wrote:



On Thu, 28 Jul 2005, Nicolas Lehuen wrote:


Note that there are 29 unscheduled issues :

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1 



Maybe some of them should be included in the 3.2 release ?





My inclanation is to just release whatever we have, and mark it as a 
beta release. The last "true" release was 3.1.3 in Feb 2004, which 
makes it 18 months (if my math is correct)


Grisha



I've either commited fixes or have fixes ready for 6 or 8 of those 
issues. Also there some that don't apply to 3.2 (eg website or mailing 
list issues). Must run right now but will make a list this evening of 
issues which can be closed.


Jim



Here is my list. I think you can close all of these JIRA issues except 
MODPYTHON-52.


That should read:
"Here is my list. I think you can close all of these JIRA issues except 
MODPYTHON-59."


Not sure how *that* typo crept in. 2 is nowhere near 9 on the keyboard.

Jim



http://issues.apache.org/jira/browse/MODPYTHON-45
Implement a file-based session manager
Resolved but waiting for documentation. Working on it now - will commit 
in the next 12 hours.


http://issues.apache.org/jira/browse/MODPYTHON-58
_apache._global_lock results in segfault when index > number of mutexes
Fix has been commited

http://issues.apache.org/jira/browse/MODPYTHON-62
local_ip and local_host in connection object returns remote_ip and 
remote_host instead

This issue only applies to 3.1.4. It's already been fixed in 3.2.

http://issues.apache.org/jira/browse/MODPYTHON-65
3.2 working version will not install on Mac OS X (10.3.7)
Fix has been commited.

http://issues.apache.org/jira/browse/MODPYTHON-66
install_dso target also tries to install Python code files
Fix has been commited.

http://issues.apache.org/jira/browse/MODPYTHON-59
Add get_session() method to request object
Let's defer this to 3.3. I've changed current implementation to raise a 
NotImplemented error.


Related to get_session, I've made a small change to Session.Session(). 
It now checks PythonOption session for the default session type before 
using the hard coded default. For reasons that escape me I put this in a 
separate function, create_session(), but it really belongs in Session(). 
This is useful outside of get_session, so I've kept the change for 3.2.


Regards,
Jim





Re: 3.2

2005-07-28 Thread Graham Dumpleton
Sorry, getting a bit overwhelmed with all these rapid changes in state
of things as bit busy today. Will probably will only know what is going
on when I look at latest code in repository. Then I'll probably pipe in
with some more pertinent comments about 3.2.

One report I would like to get some confirmation about is:

  http://issues.apache.org/jira/browse/MODPYTHON-34

This was about a potential security hole. Nicolas has indicated that
changes he had been working on which involved a different module
loader addressed it, but if various things are getting pushed to 3.3,
is then this addressed or not in what would make it to 3.2?

Since it was security related, just wanted to highlight it even if
exposure risk is low.

BTW, did anyone see an issue with my proposal for making the
req.path_info attribute writable. Ie.,

  http://issues.apache.org/jira/browse/MODPYTHON-67

I have been working on some code which would depend on such a
change and the code is of a nature that I think would be a nice
candidate for rolling back into the mod_python core. If path_info
was writable in 3.2, would allow people to experiment with the code
I am working on, or even turn it into a common project, without
needing to patch the mod_python source code.

I know Jim gave a +1 for path_info to be writable.

Graham

Jim Gallacher wrote ..
> Jim Gallacher wrote:
> > Gregory (Grisha) Trubetskoy wrote:
> > 
> >>
> >> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
> >>
> >>> Note that there are 29 unscheduled issues :
> >>>
> >>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
> >>>
> >>>
> >>> Maybe some of them should be included in the 3.2 release ?
> >>
> >>
> >>
> >> My inclanation is to just release whatever we have, and mark it as a
> >> beta release. The last "true" release was 3.1.3 in Feb 2004, which 
> >> makes it 18 months (if my math is correct)
> >>
> >> Grisha
> >>
> > 
> > I've either commited fixes or have fixes ready for 6 or 8 of those 
> > issues. Also there some that don't apply to 3.2 (eg website or mailing
> > list issues). Must run right now but will make a list this evening of
> > issues which can be closed.
> > 
> > Jim
> > 
> 
> Here is my list. I think you can close all of these JIRA issues except
> MODPYTHON-52.
> 
> http://issues.apache.org/jira/browse/MODPYTHON-45
> Implement a file-based session manager
> Resolved but waiting for documentation. Working on it now - will commit
> in the next 12 hours.
> 
> http://issues.apache.org/jira/browse/MODPYTHON-58
> _apache._global_lock results in segfault when index > number of mutexes
> Fix has been commited
> 
> http://issues.apache.org/jira/browse/MODPYTHON-62
> local_ip and local_host in connection object returns remote_ip and 
> remote_host instead
> This issue only applies to 3.1.4. It's already been fixed in 3.2.
> 
> http://issues.apache.org/jira/browse/MODPYTHON-65
> 3.2 working version will not install on Mac OS X (10.3.7)
> Fix has been commited.
> 
> http://issues.apache.org/jira/browse/MODPYTHON-66
> install_dso target also tries to install Python code files
> Fix has been commited.
> 
> http://issues.apache.org/jira/browse/MODPYTHON-59
> Add get_session() method to request object
> Let's defer this to 3.3. I've changed current implementation to raise a
> NotImplemented error.
> 
> Related to get_session, I've made a small change to Session.Session().
> It now checks PythonOption session for the default session type before
> using the hard coded default. For reasons that escape me I put this in
> a 
> separate function, create_session(), but it really belongs in Session().
> This is useful outside of get_session, so I've kept the change for 3.2.
> 
> Regards,
> Jim


Re: 3.2

2005-07-28 Thread Jim Gallacher

Gregory (Grisha) Trubetskoy wrote:


I just looked on JIRA, and there are 3 issues marked for 3.2.

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=11060 



I don't see any of them as show stopping really, IMHO we should be able 
to release 3.2 beta as it is now.


Could we have a little vote on this?

Thanks!



+1


Re: 3.2

2005-07-28 Thread Jim Gallacher

Jim Gallacher wrote:

Gregory (Grisha) Trubetskoy wrote:



On Thu, 28 Jul 2005, Nicolas Lehuen wrote:


Note that there are 29 unscheduled issues :

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1 



Maybe some of them should be included in the 3.2 release ?




My inclanation is to just release whatever we have, and mark it as a 
beta release. The last "true" release was 3.1.3 in Feb 2004, which 
makes it 18 months (if my math is correct)


Grisha



I've either commited fixes or have fixes ready for 6 or 8 of those 
issues. Also there some that don't apply to 3.2 (eg website or mailing 
list issues). Must run right now but will make a list this evening of 
issues which can be closed.


Jim



Here is my list. I think you can close all of these JIRA issues except 
MODPYTHON-52.


http://issues.apache.org/jira/browse/MODPYTHON-45
Implement a file-based session manager
Resolved but waiting for documentation. Working on it now - will commit 
in the next 12 hours.


http://issues.apache.org/jira/browse/MODPYTHON-58
_apache._global_lock results in segfault when index > number of mutexes
Fix has been commited

http://issues.apache.org/jira/browse/MODPYTHON-62
local_ip and local_host in connection object returns remote_ip and 
remote_host instead

This issue only applies to 3.1.4. It's already been fixed in 3.2.

http://issues.apache.org/jira/browse/MODPYTHON-65
3.2 working version will not install on Mac OS X (10.3.7)
Fix has been commited.

http://issues.apache.org/jira/browse/MODPYTHON-66
install_dso target also tries to install Python code files
Fix has been commited.

http://issues.apache.org/jira/browse/MODPYTHON-59
Add get_session() method to request object
Let's defer this to 3.3. I've changed current implementation to raise a 
NotImplemented error.


Related to get_session, I've made a small change to Session.Session(). 
It now checks PythonOption session for the default session type before 
using the hard coded default. For reasons that escape me I put this in a 
separate function, create_session(), but it really belongs in Session(). 
This is useful outside of get_session, so I've kept the change for 3.2.


Regards,
Jim


Re: 3.2

2005-07-28 Thread Jim Gallacher

Gregory (Grisha) Trubetskoy wrote:


On Thu, 28 Jul 2005, Jim Gallacher wrote:

I don't want to leave req_get_session in as-is since people may start 
using it which would make things difficult if the final solution ends 
up being something completely different. Rather than delete 
req_get_session() completely I'd like to change it to
raise a NotImplemented error. That way there is starting point for 3.3 
but nobody will depend on it actually being there. Does this seem 
reasonable?



+1

Grisha



I've commited this change. get_session implementation will be deferred 
to 3.3.


Jim


[jira] Updated: (MODPYTHON-59) Add get_session() method to request object

2005-07-28 Thread Jim Gallacher (JIRA)
 [ http://issues.apache.org/jira/browse/MODPYTHON-59?page=all ]

Jim Gallacher updated MODPYTHON-59:
---

Version: 3.3.0
 (was: 3.2.0)

Defering implentation to 3.3.

> Add get_session() method to request object
> --
>
>  Key: MODPYTHON-59
>  URL: http://issues.apache.org/jira/browse/MODPYTHON-59
>  Project: mod_python
> Type: New Feature
>   Components: core
> Versions: 3.3.0
>  Environment: All
> Reporter: Jim Gallacher

>
> Users will get session instances by calling req.get_session(). If a session 
> already exists it will be returned, otherwise a new session instance will be 
> created. Session configuration will be handled using apache directives rather 
> than within their code.
> Using this scheme means only one session instance will be created per 
> request, which will eliminate the deadlock problems many people experience. 
> Also, using this scheme makes it possible for sessions to be properly handled 
> within psp pages and across req.internal_redirect() calls.
> Code will be commited to svn shortly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



Re: 3.2

2005-07-28 Thread Gregory (Grisha) Trubetskoy


On Thu, 28 Jul 2005, Jim Gallacher wrote:

I don't want to leave req_get_session in as-is since people may start using 
it which would make things difficult if the final solution ends up being 
something completely different. Rather than delete req_get_session() 
completely I'd like to change it to
raise a NotImplemented error. That way there is starting point for 3.3 but 
nobody will depend on it actually being there. Does this seem reasonable?


+1

Grisha


Re: 3.2

2005-07-28 Thread Jim Gallacher

Nicolas Lehuen wrote:

Hi,

I've marked #45 as resolved, since the FileSession class has been 
checked in for a while now. We only need a bit of documentation, but a 
few seconds of source browsing can help an adventurous user to see how 
to use FileSession. Now, what should we do about the new 
req.get_session() API ? Is it ready for release now ?


No. Graham has raised some valid concerns about the current 
implentation. See http://issues.apache.org/jira/browse/MODPYTHON-59


I haven't had time to address these issues properly, and I'd rather see 
it pushed into 3.3 rather than release a half-baked solution in 3.2.


I don't want to leave req_get_session in as-is since people may start 
using it which would make things difficult if the final solution ends up 
being something completely different. Rather than delete 
req_get_session() completely I'd like to change it to
raise a NotImplemented error. That way there is starting point for 3.3 
but nobody will depend on it actually being there. Does this seem 
reasonable?


Regards,
Jim


Re: 3.2

2005-07-28 Thread Jim Gallacher

Gregory (Grisha) Trubetskoy wrote:


On Thu, 28 Jul 2005, Jim Gallacher wrote:

I've either commited fixes or have fixes ready for 6 or 8 of those 
issues. Also there some that don't apply to 3.2 (eg website or mailing 
list issues). Must run right now but will make a list this evening of 
issues which can be closed.



Do you think you'll be able to create a tgz file? It would really be 
fantastic if someone other than me could do it.


Grisha



Yes I can do that. I've already done a couple of dry runs with good 
success.


Jim


Re: 3.2

2005-07-28 Thread Gregory (Grisha) Trubetskoy


On Thu, 28 Jul 2005, Jim Gallacher wrote:

I've either commited fixes or have fixes ready for 6 or 8 of those issues. 
Also there some that don't apply to 3.2 (eg website or mailing list issues). 
Must run right now but will make a list this evening of issues which can be 
closed.


Do you think you'll be able to create a tgz file? It would really be 
fantastic if someone other than me could do it.


Grisha


Re: 3.2

2005-07-28 Thread Jim Gallacher

Gregory (Grisha) Trubetskoy wrote:


On Thu, 28 Jul 2005, Nicolas Lehuen wrote:


Note that there are 29 unscheduled issues :

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1 



Maybe some of them should be included in the 3.2 release ?



My inclanation is to just release whatever we have, and mark it as a 
beta release. The last "true" release was 3.1.3 in Feb 2004, which makes 
it 18 months (if my math is correct)


Grisha



I've either commited fixes or have fixes ready for 6 or 8 of those 
issues. Also there some that don't apply to 3.2 (eg website or mailing 
list issues). Must run right now but will make a list this evening of 
issues which can be closed.


Jim


Re: 3.2

2005-07-28 Thread dharana

As a non-developer, just as an user:

+1

Nicolas Lehuen wrote:

OK, +1 for me.

Regards,
Nicolas

2005/7/28, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED] 
>:



On Thu, 28 Jul 2005, Nicolas Lehuen wrote:

 > Note that there are 29 unscheduled issues :
 >
 >

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1


 >
 > Maybe some of them should be included in the 3.2 release ?

My inclanation is to just release whatever we have, and mark it as a
beta
release. The last "true" release was 3.1.3 in Feb 2004, which makes
it 18
months (if my math is correct)

Grisha




--
dharana



Re: 3.2

2005-07-28 Thread Nicolas Lehuen
OK, +1 for me.

Regards,
Nicolas2005/7/28, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>:
On Thu, 28 Jul 2005, Nicolas Lehuen wrote:> Note that there are 29 unscheduled issues :>> 
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1>> Maybe some of them should be included in the 
3.2 release ?My inclanation is to just release whatever we have, and mark it as a betarelease. The last "true" release was 3.1.3 in Feb 2004, which makes it 18months (if my math is correct)
Grisha


Re: 3.2

2005-07-28 Thread Gregory (Grisha) Trubetskoy


On Thu, 28 Jul 2005, Nicolas Lehuen wrote:


Note that there are 29 unscheduled issues :

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1

Maybe some of them should be included in the 3.2 release ?


My inclanation is to just release whatever we have, and mark it as a beta 
release. The last "true" release was 3.1.3 in Feb 2004, which makes it 18 
months (if my math is correct)


Grisha


[jira] Updated: (MODPYTHON-54) Add a way to import a published page into another published page

2005-07-28 Thread Nicolas Lehuen (JIRA)
 [ http://issues.apache.org/jira/browse/MODPYTHON-54?page=all ]

Nicolas Lehuen updated MODPYTHON-54:


Fix Version: 3.3.0
 (was: 3.2.0)
Description: 
Before mod_python 3.2, standard Python modules and published modules could be 
imported the same way, using apache.import_module. This had a number of 
disadvantages, leading to MODPYTHON-8, MODPYTHON-9, MODPYTHON-10, MODPYTHON-11 
and MODPYTHON-12.

All these bugs were fixed by separating the published modules from the standard 
Python module. apache.import_module can still be used to import standard 
modules, but published modules are now fully managed  by mod_python.publisher, 
and are not inserted into sys.modules.

The problem is that there is a use case of importing a published module from 
another published module :

/index.py
def index(req):
return "Hello, world !"

def utility_function(foobar):
return foobar+1

/other.py
import os
directory = os.path.split(__file__)[0]
other_index = apache.import_module("index",path=[directory])

def index(req):
return "%s %i"%(other_index.index(req),other_index.utility_function(2004))

This was alread a bit of a hack in 3.1.4, but in 3.2 it does not really work 
the expected way since the imported module (other_index in the example) is not 
the same module as the one the publisher would use to publish /index.py. This 
could be troublesome if the developer wanted to share some data between the 
modules, e.g. a cache or a connection pool, but not if he only wanted to share 
some code.

Therefore, we need to provide a clean API in mod_python.publisher to allow 
developers to reference another published module.

  was:
Before mod_python 3.2, standard Python modules and published modules could be 
imported the same way, using apache.import_module. This had a number of 
disadvantages, leading to MODPYTHON-8, MODPYTHON-9, MODPYTHON-10, MODPYTHON-11 
and MODPYTHON-12.

All these bugs were fixed by separating the published modules from the standard 
Python module. apache.import_module can still be used to import standard 
modules, but published modules are now fully managed  by mod_python.publisher, 
and are not inserted into sys.modules.

The problem is that there is a use case of importing a published module from 
another published module :

/index.py
def index(req):
return "Hello, world !"

def utility_function(foobar):
return foobar+1

/other.py
import os
directory = os.path.split(__file__)[0]
other_index = apache.import_module("index",path=[directory])

def index(req):
return "%s %i"%(other_index.index(req),other_index.utility_function(2004))

This was alread a bit of a hack in 3.1.4, but in 3.2 it does not really work 
the expected way since the imported module (other_index in the example) is not 
the same module as the one the publisher would use to publish /index.py. This 
could be troublesome if the developer wanted to share some data between the 
modules, e.g. a cache or a connection pool, but not if he only wanted to share 
some code.

Therefore, we need to provide a clean API in mod_python.publisher to allow 
developers to reference another published module.

Environment: 

> Add a way to import a published page into another published page
> 
>
>  Key: MODPYTHON-54
>  URL: http://issues.apache.org/jira/browse/MODPYTHON-54
>  Project: mod_python
> Type: Improvement
> Versions: 3.2.0
> Reporter: Nicolas Lehuen
> Assignee: Nicolas Lehuen
>  Fix For: 3.3.0

>
> Before mod_python 3.2, standard Python modules and published modules could be 
> imported the same way, using apache.import_module. This had a number of 
> disadvantages, leading to MODPYTHON-8, MODPYTHON-9, MODPYTHON-10, 
> MODPYTHON-11 and MODPYTHON-12.
> All these bugs were fixed by separating the published modules from the 
> standard Python module. apache.import_module can still be used to import 
> standard modules, but published modules are now fully managed  by 
> mod_python.publisher, and are not inserted into sys.modules.
> The problem is that there is a use case of importing a published module from 
> another published module :
> /index.py
> def index(req):
> return "Hello, world !"
> def utility_function(foobar):
> return foobar+1
> /other.py
> import os
> directory = os.path.split(__file__)[0]
> other_index = apache.import_module("index",path=[directory])
> def index(req):
> return "%s %i"%(other_index.index(req),other_index.utility_function(2004))
> This was alread a bit of a hack in 3.1.4, but in 3.2 it does not really work 
> the expected way since the imported module (other_index in the example) is 
> not the same module as the one the publisher would use to publish /index.py. 
> This could be troublesome if the developer wanted to shar

Re: 3.2

2005-07-28 Thread Nicolas Lehuen
Note that there are 29 unscheduled issues :

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1


Maybe some of them should be included in the 3.2 release ?

Regards,
Nicolas2005/7/28, Nicolas Lehuen <[EMAIL PROTECTED]>:
Hi,

I've marked #45 as resolved, since the FileSession class has been
checked in for a while now. We only need a bit of documentation, but a
few seconds of source browsing can help an adventurous user to see how
to use FileSession. Now, what should we do about the new
req.get_session() API ? Is it ready for release now ?

This leaves use with #8 and #54, which are both related to importing
issues. Therefore I suggest we move those issues to mod_python 3.3 and
try to release 3.2 ASAP... A lot of bug fixes have been waiting 9
months or so to be fixed "officially".

Regards,
Nicolas2005/7/28, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>:

I just looked on JIRA, and there are 3 issues marked for 3.2.

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=11060I don't see any of them as show stopping really, IMHO we should be able to
release 3.2 beta as it is now.Could we have a little vote on this?Thanks!




Re: 3.2

2005-07-28 Thread Nicolas Lehuen
Hi,

I've marked #45 as resolved, since the FileSession class has been
checked in for a while now. We only need a bit of documentation, but a
few seconds of source browsing can help an adventurous user to see how
to use FileSession. Now, what should we do about the new
req.get_session() API ? Is it ready for release now ?

This leaves use with #8 and #54, which are both related to importing
issues. Therefore I suggest we move those issues to mod_python 3.3 and
try to release 3.2 ASAP... A lot of bug fixes have been waiting 9
months or so to be fixed "officially".

Regards,
Nicolas2005/7/28, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>:
I just looked on JIRA, and there are 3 issues marked for 3.2.
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=11060I don't see any of them as show stopping really, IMHO we should be able to
release 3.2 beta as it is now.Could we have a little vote on this?Thanks!


[jira] Updated: (MODPYTHON-8) Improve apache.load_module with a two-level locking scheme

2005-07-28 Thread Nicolas Lehuen (JIRA)
 [ http://issues.apache.org/jira/browse/MODPYTHON-8?page=all ]

Nicolas Lehuen updated MODPYTHON-8:
---

Fix Version: 3.3.0
 (was: 3.2.0)
Description: 
We should rewrite apache.load_python with a two level locking scheme, in order 
to reduce thread contention when using the threading MPM.

I've already implemented something similar for a custom-made publisher system 
(comparable to Graham's Vampire) ; I've used a thread-safe caching system that 
I've donated to the Python Cookbook :

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302997

Maybe this should be experimented in a separate branch, and merged back once 
we're sure that everything works perfectly ?

  was:
We should rewrite apache.load_python with a two level locking scheme, in order 
to reduce thread contention when using the threading MPM.

I've already implemented something similar for a custom-made publisher system 
(comparable to Graham's Vampire) ; I've used a thread-safe caching system that 
I've donated to the Python Cookbook :

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302997

Maybe this should be experimented in a separate branch, and merged back once 
we're sure that everything works perfectly ?

Environment: 

> Improve apache.load_module with a two-level locking scheme
> --
>
>  Key: MODPYTHON-8
>  URL: http://issues.apache.org/jira/browse/MODPYTHON-8
>  Project: mod_python
> Type: Improvement
> Versions: 3.1.3
> Reporter: Nicolas Lehuen
> Assignee: Nicolas Lehuen
>  Fix For: 3.3.0

>
> We should rewrite apache.load_python with a two level locking scheme, in 
> order to reduce thread contention when using the threading MPM.
> I've already implemented something similar for a custom-made publisher system 
> (comparable to Graham's Vampire) ; I've used a thread-safe caching system 
> that I've donated to the Python Cookbook :
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302997
> Maybe this should be experimented in a separate branch, and merged back once 
> we're sure that everything works perfectly ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



[jira] Resolved: (MODPYTHON-45) Implement a file-based session manager

2005-07-28 Thread Nicolas Lehuen (JIRA)
 [ http://issues.apache.org/jira/browse/MODPYTHON-45?page=all ]
 
Nicolas Lehuen resolved MODPYTHON-45:
-

Resolution: Fixed

This has been resolved a while ago. We now need some documentation.

> Implement a file-based session manager
> --
>
>  Key: MODPYTHON-45
>  URL: http://issues.apache.org/jira/browse/MODPYTHON-45
>  Project: mod_python
> Type: New Feature
> Versions: 3.1.4
> Reporter: Nicolas Lehuen
> Assignee: Nicolas Lehuen
> Priority: Minor
>  Fix For: 3.2.0

>
> Right now mod_python comes with DbmSession and MemorySession. DbmSession 
> performance can be pretty crappy if for any reason the anydbm module reverts 
> to the dumbdbm implementation. With the current filesystems, implementing a 
> file-based session manager should be easy and should perform well.
> See the following thread : 
> http://www.modpython.org/pipermail/mod_python/2005-April/017825.html
> I've checked in a preliminary implementation based on dharana's work. We'll 
> have to cope with a few issues (namely locking) before it is final.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



Re: [jira] Commented: (MODPYTHON-59) Add get_session() method torequestobject

2005-07-28 Thread Jim Gallacher

Graham Dumpleton wrote:

Jim Gallacher wrote ..


I think the automatic session unlock needs to stay. It's just too easy
for the user to forget a manual unlock, deadlock the session and hose 
their server in very short order.




In your following comments I'm assuming you are talking about the case 
where the code called by internal_redirect is *not* creating a session.



What though is the consequence of the session lock not being reacquired.
Ie., what happens if someone wants to modify the session object and save
it after internal redirect returns.


They can still do that. Nothing will break, but we have introduced a 
possible race condition if another request has come in for the same 
session in the interim. Note that this race condition currently exists 
where the code explicitly unlocks the session.


It may be tricky for the user to track down what is going on but I think 
this is better than potentially exhausting all the mutexes through 
deadlocks and needing to restart apache. A programming error in one app 
should not be allowed to bring down the whole server. To me restarting 
the server is the bigger sin.



You might save a deadlock by unlocking the session object, but does it
screw up the case of existing code where session is modified and saved
after internal redirect returns.


Current code will not break. Assuming that another request for the same 
session has not arrived in the interim and changed the underlying 
session data, all is well.


One possible solution would be to add an optional parameter to 
req_internal_redirect:


internal_redirect(url, unlock_session=True)

Current code which messes with the session object after 
internal_redirect returns would still need to be modified, but at least 
the programmer has that control and we avoid deadlocks by default.



Am still for leaving things how they are in this respect, we know the
issues involved and probably just need to beef up the documentation with
big warnings so that people are aware of the internal redirect caveat.


People actually read the documention? Cool. ;)

I still advocate for automatic session unlocking for an internal 
redirect. The messages on the mailing list where people have suggested 
not locking sessions at all to the avoid deadlock problems suggests to 
me that session locking needs to handled much more transparently. Also, 
at some point someone (Grisha?) suggested that the likes of php sessions 
may not do any session locking, so we are still ahead of the game.


Any other opinions?

Regards,
Jim