When we started 3.3 development we discussed some of the deficiencies of
the current unit test framework, and the general idea of a new design.
After a couple of ill-fated attempts at a rewrite I think I have
something that fits the bill. At this point it's actually usable, and
the code is
about the overall concept and design?
Jim
On 03/10/2006, at 7:01 AM, Jim Gallacher wrote:
When we started 3.3 development we discussed some of the deficiencies
of the current unit test framework, and the general idea of a new design.
After a couple of ill-fated attempts at a rewrite I think
to worry about manipulating
access on individual pages.
Graham
On 13/09/2006, at 9:31 AM, Max Bowsher wrote:
Graham Dumpleton wrote:
On 13/09/2006, at 8:45 AM, Jim Gallacher wrote:
Woot Woot Woot! We have our wiki!
http://wiki.apache.org/mod_python/
Now comes the hard part... what
amendments
to the documentation.
The MoinMoin site could be kept for general community contributions.
Ie., the FAQ, examples of handlers, links to other resources etc etc.
Graham
On 12/10/2006, at 10:29 PM, Jim Gallacher wrote:
Graham Dumpleton wrote:
Anyone had any thoughts on how we
When I compile and run svn trunk with apache 2.2.3 I get an run I get
the following:
apache2: Syntax error on line 185 of /etc/apache2/apache2.conf: Syntax
error on
line 1 of /etc/apache2/mods-enabled/mod_python.load: Cannot load
/usr/lib/apache2/modules/mod_python.so into server:
Trunk is blowing up with apache 2.2.3, with the following error_log output:
[Sat Oct 21 16:32:59 2006] [notice] Apache/2.2.3 (Debian)
mod_python/3.3.0-dev-20061021 Python/2.4.3 configured -- resuming normal
operations
Fatal Python error: Invalid thread state for this thread
Fatal Python
Ignore this. It was a messed up installation of apache and or python.
Jim
Jim Gallacher wrote:
Trunk is blowing up with apache 2.2.3, with the following error_log output:
[Sat Oct 21 16:32:59 2006] [notice] Apache/2.2.3 (Debian)
mod_python/3.3.0-dev-20061021 Python/2.4.3 configured
--
Key: MODPYTHON-190
URL: http://issues.apache.org/jira/browse/MODPYTHON-190
Project: mod_python
Issue Type: Task
Components: core
Affects Versions: 3.3
Environment: All
Reporter: Jim Gallacher
Attachments
Graham Dumpleton wrote:
=?ISO-8859-1?Q?Indrek_J=E4rve?= wrote ..
Jim Gallacher wrote:
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-190?page=all ]
Graham Dumpleton updated MODPYTHON-190:
---
Fix Version/s
Graham Dumpleton wrote:
In mod_python, the session ID consists of 32 characters coming from the ranges
0-9 and a-f. At the moment the code will if it detects invalid characters in
the SID or it is the wrong size, raise a HTTP_INTERNAL_SERVER_ERROR exception.
if self._sid:
#
Graham Dumpleton wrote:
There were no more comments on basic apache.import_module()
documentation so I have tweaked a few last things, committed it
and marked as resolved the final issue in JIRA tagged for 3.3.
Thus, unless anyone else has got any last minute issues, we should
be good to go
I stupidly tagged a branch with the wrong name (3-3-0-bc1 instead of
3-3-0b). Should I remove it or just let it slide?
Jim
[EMAIL PROTECTED] wrote:
Author: jgallacher
Date: Sat Dec 9 07:43:41 2006
New Revision: 484999
URL: http://svn.apache.org/viewvc?view=revrev=484999
Log:
copied trunk to
in this string as that information is available in
the email subject. Who knows, one day I may actually write a script to
extract this information automatically. :)
Thank you for your assistance,
Jim Gallacher
test it because I was waiting for the core vote :-)
David
Jim Gallacher wrote:
Gregory (Grisha) Trubetskoy wrote:
core +1 on releasing it into the wild
grisha
I'm not sure what we're voting on here, and I'm not sure what I meant
by the next level either. :)
Is this a vote to give 3.3.0
+1 Linux Ubuntu 6.0.6, Apache 2.0.55 (mpm-worker), Python 2.4.3
I'd like to get a core vote on 3.3.1 before Graham goes on holidays. If
we can get 2 more people to check the tarball I think we can then
proceed with the vote and an official 3.3.1 stable release.
Jim
Jim Gallacher wrote
votes, right?)
Yes, +1 across the board.
Jim
grisha
On Thu, 1 Feb 2007, Nicolas Lehuen wrote:
Following my tests on Windows, and knowing that 3.3.1 = 3.3.0b + a
version number change, I give my +1 on the release.
Regards,
Nicolas
2007/2/1, Jim Gallacher [EMAIL PROTECTED]:
I think we have
it is not binding but I'm confident he would support
mod_python becoming a TLP. In fact I believe he alludes to such in the
second email linked above.
At any rate, I'd be very happy to server on the new PMC, and if there a
lack of candidates I would stand for the chair as well.
Sincerely,
Jim Gallacher
Jim Gallacher wrote:
Roy T. Fielding wrote:
On Feb 9, 2007, at 8:30 AM, Jim Gallacher wrote:
Hi Roy,
+1 approve requesting a mod_python TLP
+2 to the alterative: approve requesting a python TLP
I think that would be fine, except you will have to come up with a
name that is not Apache
Gregory (Grisha) Trubetskoy wrote:
Sorry - for technical reasons (serious home server crash) I missed this
thread entirely, and for the same reason i'm lagging on the releasing
mod_python that's ready to go.
I am for making mod_python a TLP, and I also support Jim's suggestion of
making it
Graham Dumpleton wrote:
On 10/05/07, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED] wrote:
1. Python is not a good name for this project because Apache Python
will just be too confusing and probably infringes on a PSF trademark. So
if you have any creative suggestions, send them in, don't be
Nic Ferrier wrote:
Nicolas Lehuen [EMAIL PROTECTED] writes:
OK now this is totally weird, we've got a Nic, a Nick and a Nicolas in the
thread, watch out for mass confusion !
Bah. You got the joke first.
Well, this is python, so everyone really should be called Bruce. Maybe
that will
Nic Ferrier wrote:
All that I asked is that a module similar to mine be included in
mod_python's dist so that it can be available to programmers by
default.
Yes, I understand this. I just think if the decision was made to include
this feature it should be rock solid. I've not used the python
that change? Likewise do we fix
MODPYTHON-83 and do another beta, fix and release without another beta,
or catch it in a 3.2.3 bugfix release?
Jim
2005/10/21, Jim Gallacher [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Can we do a release of 3.2.2-final or do we need another beta to fix
Graham Dumpleton wrote:
Graham Dumpleton wrote ..
It is only recently that I realised that a nested function like that
could access stack variables of the enclosing function.
I should have added, when the execution of the enclosing function has
already finished and the nested function is
Nicolas Lehuen wrote:
I can try to integrate Graham's proposal for a fix to MODPYTHON-83 and
test it on Win32 this week-end, but after that I'll be away for a week.
If you have a chance could you test req.sendfile() on Windows as well?
See http://issues.apache.org/jira/browse/MODPYTHON-84
Nick wrote:
Jim Gallacher wrote:
I'm wondering where the PythonLogHandler directive might fit into the
scheme of things. One problem of course is that any PythonLogHandler
gets called *after* any PythonHandlers.
I believe the PythonLogHandler is used to intercept and handle logging
Graham Dumpleton wrote:
Graham Dumpleton wrote ..
It is only recently that I realised that a nested function like that
could access stack variables of the enclosing function.
I should have added, when the execution of the enclosing function has
already finished and the nested function is
on before I commit it.
Jim
Jim Gallacher wrote:
I'll give it a try, and create a unit test at the same time. Should the
unit tests cover other possibilites such as \t, \r and so on?
Jim
Gregory (Grisha) Trubetskoy wrote:
I think the fix to that may be inserting
TEXT\\n
to refactor *all* of my psp pages, so I guess we'll need to
fix psp_parser. ;)
Jim
Jim Gallacher wrote:
Ok, this is weird.
I tried Grisha's suggested fix, but instead of getting the expected '\n'
character string in the test output I got '\\n'. So I reverted
psp_parser.l and recompiled. Now, rather
Gregory (Grisha) Trubetskoy wrote:
On Wed, 9 Nov 2005, Jim Gallacher wrote:
This just get's stranger and stranger. Regenerating psp_parser.c from
the current psp_parser.l has caused my psp pages to go completely
pair-shaped. Things that rendered correctly before now puke up hairballs
John McFarlane wrote:
Sure enough /tmp/mp_sess.dbm was present, and owned by apache. I
removed the file and tested again with the same results. In doing so
/tmp/mp_sess.dbm was re-created and owned by the user running the test.
Yes, mp_sess.dbm should be owned by the test user. This is the
[EMAIL PROTECTED] wrote:
Author: nlehuen
Date: Wed Nov 16 13:15:06 2005
New Revision: 345126
URL: http://svn.apache.org/viewcvs?rev=345126view=rev
Log:
Perform quoting AFTER the test for file existence... Otherwise with spaces in
Apache path, the test for file existence will always fail since
Mike Looijmans wrote:
How about we make the first call to get or __getitem__ create the
dictionary? We could put code in __getattr__ to create it when it's
referenced.
For starters, most of the methods such as keys, has_key and so on will
raise an exception since you don't create the
Nick wrote:
Just one comment. It seems like it would be better just to make
add_method inline, since everything else in __init__ is, and it never
gets called from anywhere else.
add_method?
But it looks good and probably fairly optimal. I personally like to see
properties instead of
Nick wrote:
Jim Gallacher wrote:
For starters, most of the methods such as keys, has_key and so on will
raise an exception since you don't create the dictionary until after
one of the fields is accessed via __getitem__. Also, has_key will
return false for a field that actually exists
Nick wrote:
Jim Gallacher wrote:
Nick wrote:
Just one comment. It seems like it would be better just to make
add_method inline, since everything else in __init__ is, and it never
gets called from anywhere else.
add_method?
Haha, thanks, I haven't had coffee yet. The add_item method
Gregory (Grisha) Trubetskoy wrote:
On Tue, 29 Nov 2005, Jim Gallacher wrote:
I still think the correct place to create the index dictionary is in
the __init__ phase. Using the dictionary-on-demand idea only improves
performance on the second access to a form field. For the first access
you
Nick wrote:
Jim Gallacher wrote:
I've only started using properites and I hadn't thought of that. If we
were to use such a feature is that the sort detail that would be
included in the user documentation, or would the coder just be
expected to read the source?
You CAN read the source
Daniel J. Popowich wrote:
Jorey Bump writes:
Gregory (Grisha) Trubetskoy wrote:
Perhaps we can add something to the docs that says this attribute gets
its data from the argument to the HTTP GET method, which is usually just
the path in the URL and does not include the protocol, hostname
Jim Gallacher wrote:
Using an internal_redirect messes with some of these attributes but not
others. Those that change get their new values from the new_uri used in
the redirect. Unchanged values are from the initial request.
req.internal_redirect(new_uri)
the_requestunchanged
Nicolas Lehuen wrote:
2005/11/30, Jim Gallacher [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
At this point I think we should leave parsed_uri alone, as it seems to
do the correct thing - if not the desired thing. At a minimum we should
expand the documentation to warn people
Daniel J. Popowich wrote:
Jim Gallacher writes:
Jim Gallacher wrote:
Using an internal_redirect messes with some of these attributes but not
others. Those that change get their new values from the new_uri used in
the redirect. Unchanged values are from the initial request
Jorey Bump wrote:
Even better, deprecate req.hostname in 3.2, where we can add req.host to
contain the value in req.headers_in['Host']. Then drop req.hostname in
3.3 completely. This will give developers some time to adapt.
It's too late to be deprecating anything in 3.2. I know it seems like
Graham Dumpleton wrote:
Hmmm, go away for two days and a mail storm erupts. :-(
And when you come back we go completely silent again. It's a conspiracy
I tell ya. ;)
Jim
Gregory (Grisha) Trubetskoy wrote:
On Thu, 29 Dec 2005, Nicolas Lehuen wrote:
I've tested your patch and of course it doesn't break anything in our
unit tests. I can't see how it can break anything, therefore I've
checked it in in the hope that it will make it for 3.2.6 final.
Grisha, tell
Gregory (Grisha) Trubetskoy wrote:
On Thu, 29 Dec 2005, Jim Gallacher wrote:
So are we happy with the state of svn trunk right now? If so I'll roll
the tarball for 3.2.6b.
Does anyone here have any opinion on whether this release should be
marked as beta?
I personally don't know enough
name. Ie., directory name, slash, and then module name. This
wouldn't work on Mac OS X but did work on Linux. Result was that it
allowed loading of a module in a subdirectory without need for use of
packages. Not sure what Win32 did.
Graham
Jim Gallacher wrote ..
Ok, this is weird. I've run
Jorey Bump wrote:
Jim Gallacher wrote:
Jorey Bump wrote:
IOW, could you guys list the OS on which you run, and not merely
test, mod_python?
By you guys I assume you mean the above 4 people?
Yeah, youse 4 guys. :)
On the other hand, you may mean *all* the people on python-dev who
Deron Meranda wrote:
On 1/31/06, Jim Gallacher [EMAIL PROTECTED] wrote:
I say we leave it as is (ie continue use apr_sockaddr_port_get) and
worry about it when we do some sort of comprehensive review for apache
2.2 compatibility.
That's fine.
I was only scared that there might be an attempt
I know you said no discussion Grisha, but can I have 2 ballots? ;)
-1 If Graham thinks his conn handler fix is good, let's do 3.2.7 today.
+1 If Graham is not sure, we release 3.2.6 now as is, and do a 3.2.7
bugfix in the next 4 to 6 weeks after digging into _conn_read issue further.
So, I
Graham Dumpleton wrote:
Jim Gallacher wrote ..
I'm getting a unit test failure.
FAIL: test_publisher_cache (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File test.py, line 1836, in test_publisher_cache
Howdy,
Anybody else finding that the JIRA page layouts are completely messed
up? It might be a coincidence but it seems like it might happen after
adding a comment. I first noticed it a couple of days ago. Perhaps
somebody else can take a look and see if you have any problems? I'm
using
Never mind. There is already a JIRA issue for this JIRA issue. :)
https://issues.apache.org/jira/browse/INFRA-697
Jim
Jim Gallacher wrote:
Howdy,
Anybody else finding that the JIRA page layouts are completely messed
up? It might be a coincidence but it seems like it might happen after
I'd like to checkin my patch to support apache 2.2. It doesn't add any
new functionality. Any objections?
Jim
Jorey Bump wrote:
Jim Gallacher wrote:
This is how I would set priorities:
Try and assign most of the issues to someone. This is a bit of PR
spin, but I think it looks bad when there are a large number of open
issues with no assignee. To the public it may look like the project
Nicolas Lehuen wrote:
Hi,
I'm currently reading the feature section from mod_perl. Initially, I
was trying to find information about how they cope with
multithreading, multiple interpreter instantiation and code reloading,
but I stumbled upon this :
Oden Eriksson wrote:
Hello.
In our package in Mandriva I patch mod_python.c so that the mutex stuff is put
in /var/cache/httpd/mod_python/. But now with mod_python-3.2.7 plus fixes
from the trunk and running the test suite it complains it cannot access
/var/cache/httpd/mod_python/ (of
Oden Eriksson wrote:
tisdagen den 14 februari 2006 14.19 skrev Jim Gallacher:
Oden Eriksson wrote:
Hello.
In our package in Mandriva I patch mod_python.c so that the mutex stuff
is put in /var/cache/httpd/mod_python/. But now with mod_python-3.2.7
plus fixes from the trunk and running
Graham Dumpleton wrote:
On 15/02/2006, at 5:07 AM, alex eh wrote:
Hello all--I'm sure this has been a subject of ongoing discussion; but
could someone perhaps fill me in on the timeline for adding mod_python
support for Apache 2.2.0? I just put together mod_python 3.2.7 and
Apache 2.2.0 with
Nick wrote:
Gregory (Grisha) Trubetskoy wrote:
SWIG in my opinion is good when you want some kind of an API made
available to you quickly, but in a static environment where can put some
thought into functionality, usability, Pythonic-ness of every approach,
write documentation with good
of months ago during 3.2 beta. Do you want me
to resubmit this problem via JIRA ? Or just to resend the required fixes ?
Cheers,
Michel
--On lundi 20 février 2006 16:18 -0500 Graham Dumpleton
[EMAIL PROTECTED] wrote:
+1 core vote
Nicolas Lehuen wrote ..
+1 core vote
2006/2/20, Jim Gallacher
I added a make check rule to run the tests, which meant adding
test/Makefile. It's easy enough to add a make clean rule in that file.
Jim
Graham Dumpleton (JIRA) wrote:
Running make clean/distclean doesn't clean up test directory.
-
Graham Dumpleton wrote:
On 03/03/2006, at 1:55 PM, Jim Gallacher wrote:
Does this sound helpful, or does everyone just trust that I am not
going
to screw things up? :-)
Hopefully people are reviewing the changes on the python-cvs
I haven't been committing in anything yet, I presume
--
Jim Gallacher wrote:
mod_python-3.3.0-dev-20060321 is available for testing.
We are asking the mod_python development community for assistance in
testing the current development branch. Hopefully this will allow us
to catch new bugs or regressions early, and when we are ready for the
next
that infrastructure is in
place and works. What we need is a way to keep have website content in
subversion, and a mechanism for updating the host.
Jim
Grisha
On Sat, 18 Mar 2006, Justin Erenkrantz wrote:
On 2/12/06, Jim Gallacher [EMAIL PROTECTED] wrote:
As a result of the nudge from Justin I've
Jorey Bump wrote:
Jim Gallacher wrote:
Jorey,
This is possibly the same failure Nicolas is seeing on Windows. It
could be I've made some incorrect assumptions on the default apache
2.2 configuration such that there is a problem with the test setup.
Could you send the output of
$ /usr
Sorry I haven't been much use on getting 3.2.9 ready. Unfortunately I've
run out of time and won't be able to pitch in until Monday.
Jim
Graham Dumpleton wrote:
On 12/04/2006, at 10:13 PM, Graham Dumpleton wrote:
On 11/04/2006, at 12:47 PM, Jim Gallacher wrote:
MODPYTHON-93
Improved
[EMAIL PROTECTED] wrote:
Author: grahamd
Date: Sun Apr 16 03:49:39 2006
New Revision: 394455
URL: http://svn.apache.org/viewcvs?rev=394455view=rev
+1 Debian Sid, apache 2.2.0, python 2.4.2
-1 Debian Sid, apache 2.0.55, python 2.3.5
Compilation fails with this output:
make[1]: Entering
Graham Dumpleton wrote:
On 20/04/2006, at 12:39 AM, Jim Gallacher wrote:
[EMAIL PROTECTED] wrote:
Author: grahamd
Date: Sun Apr 16 03:49:39 2006
New Revision: 394455
URL: http://svn.apache.org/viewcvs?rev=394455view=rev
+1 Debian Sid, apache 2.2.0, python 2.4.2
-1 Debian Sid, apache
Deron Meranda wrote:
I think the namespace direction you're taking is great. Just to be clear,
the dotted-notation is simply that, a notation. The interface to
req.get_options()
is not changing is it?
You are correct, it's just a notation - req.get_options will not change.
I also think that
+1 Linux Debian Sid, apache 2.0.55, python 2.3.5
Thanks for the nudge David. I forget to change the status when I
committed the patch.
Jim
David Fraser (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-174?page=all ]
David Fraser updated MODPYTHON-174:
---
This is now fixed for 3.2.9
+1 Linux Ubuntu 6.06 Dapper Drake, Apache 2.0.55 (mpm-worker), Python 2.4.3
Jim Gallacher wrote:
The mod_python 3.2.9 tarball is available for testing.
This tarball is unchanged from 3.2.9-rc3, but should be retested anyway
- just in case something went pair-shaped in the process of tagging
I'm running my leaktest suite against this commit now. Results to follow.
Jim
Nicolas Lehuen (JIRA) wrote:
[
http://issues.apache.org/jira/browse/MODPYTHON-172?page=comments#action_12419906
]
Nicolas Lehuen commented on MODPYTHON-172:
--
Harold Ship wrote:
Jim Gallacher jpg at jgassociates.ca writes:
I've run some tests to evaluate the memory leaks. The tests are brute
force - make requests and watch the memory changes with top -b.
...
First up - our leaky 3.2.9, and man does it leak! The readlines request
has a body
Deron Meranda wrote:
Just want some verification because I haven't seen anything
official looking
Is 3.2.9 now considered a bad release because of its memory
leaks, and thus will never be released?
It's not so much that it's a bad release, but rather it didn't make
sense to officially
Jim Gallacher wrote:
Deron Meranda wrote:
Just want some verification because I haven't seen anything
official looking
Is 3.2.9 now considered a bad release because of its memory
leaks, and thus will never be released?
It's not so much that it's a bad release, but rather it didn't
this information automatically. :)
Thank you for your assistance,
Jim Gallacher
this information automatically. :)
Thank you for your assistance,
Jim Gallacher
+1 Linux Debian Sid, Apache 2.0.55 (mpm-prefork), Python 2.3.5
+1 Linux Debian Sid, Apache 2.2.0 (mpm-worker), Python 2.4.2
+1 Linux Ubuntu 6.06 Dapper Drake, Apache 2.0.55 (mpm-worker), Python 2.4.3
Jim Gallacher wrote:
The mod_python 3.2.10 tarball is available for testing.
Part way through
I just noticed that when it hangs, the Apache process pegs the CPU at 98%.
When the test initially hung I just killed the test.py, but didn't think
to actually stop Apache. It took me a little while to figure out why my
computer was *so* sluggish this morning.
Jim
Jim Gallacher wrote:
I just
investigating...
As will I ...
Jim
Until the next email.
/amn
Jim Gallacher wrote:
I ran my baseline test with 500k requests, and got the following:
(Note that all the figures will have an error of +/- 0.1)
baseline 500k requests 1.7%
So it would seem that there is not a specific
There was a question on the mod_python list regarding mpcp, which
provides a mod_python handler for cherrypy. Out of curiosity I took a
look at mpcp. Low and behold, they use req.server.register_cleanup to
stop the cherrypy server.
I'm becoming increasingly concerned about dropping
Jim Gallacher wrote:
There was a question on the mod_python list regarding mpcp, which
provides a mod_python handler for cherrypy. Out of curiosity I took a
look at mpcp. Low and behold, they use req.server.register_cleanup to
stop the cherrypy server.
I'm becoming increasingly concerned
The patch submitted last night had a typo (missing comma) in it. The
corrected version is attached.
Jim
Jim Gallacher wrote:
I found a couple of errors in dist/setup.py.in. The attached patch
should fix the problems.
Changes:
1. The regular expression used by the getconfigure_option function
I'm spending some time today to work on the Session docs, and was
looking at the mod_python mail archives.
It seems that users quite often deadlock their sessions, and eventually
exhaust the max thread/processes available. The only way to kill the
deadlocked sessions is by re-starting apache.
the effort for all concerned.
Regards,
Jim
Regards,
Nicolas
2005/5/20, Jim Gallacher [EMAIL PROTECTED]:
I'm spending some time today to work on the Session docs, and was
looking at the mod_python mail archives.
It seems that users quite often deadlock their sessions, and eventually
exhaust the max thread
Hi Nicolas,
Nicolas Lehuen wrote:
Hi Jim,
How where you creating the session object in requestobject.c ? If you
were using PythonObject_New, then this may explain the memory leak.
Objects that must be managed by the garbage collector have to be
created with PyObject_GC_New.
The c-code loads
) {
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0,
((requestobject*)self)-request_rec, %s:%i Call to visit()
failed,__LINE__,__FILE__);
return i;
}
}
// no need to Py_DECREF(dict) since the reference is borrowed
return 0;
}
Regards,
Nicolas
2005/6/12, Jim
only known sessions classes
are allowed, but it should be easy to change it to load a module
instead. Python is a dynamic language after all.
Regards,
Jim
Regards,
Nicolas
2005/6/15, Jim Gallacher [EMAIL PROTECTED]:
So, any further thoughts / comments / objections to PythonSessionOption
Nicolas Lehuen wrote:
Anyway, implementing
FS2 instead of FS is not that difficult, and if it yields predictable
results even on ext3, then we should go for it.
Already done - it's just a couple of extra lines. Doing some testing today.
Are you replacing FS with FS2 or adding a new
I think I just spotted a potential deadlock in psp.py.
def dbm_cache_store(srv, dbmfile, filename, mtime, val):
dbm_type = dbm_cache_type(dbmfile)
_apache._global_lock(srv, pspcache)
try:
dbm = dbm_type.open(dbmfile, 'c')
dbm[filename] = %d %s % (mtime,
(py_config));
I don't see where or how this memory gets freed. I've taken a look at
the apache src code but get lost pretty quick.
Regards,
Jim
Jim Gallacher (JIRA) wrote:
PythonOption directive causes memory leak
-
Key: MODPYTHON-60
Nicolas Lehuen wrote:
BTW, there's a new feature in JIRA, now : it looks like if a
MODPYTHON-xx bug number is inserted into a subversion commit message,
the commit is reference in a Subversion commit tab in the bug page.
Example : http://issues.apache.org/jira/browse/MODPYTHON-48
You pointed
Graham,
You've hit on a couple of issues I had not considered and I'm trying to
understand the implications.
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-59?page=comments#action_12316578 ]
Graham Dumpleton commented on MODPYTHON-59:
Gregory (Grisha) Trubetskoy wrote:
Another thing that should probably go in before 3.2. The RedHat people
patch mod_python with this patch in the source RPM (smart-ass comment
included):
-
Stealing 1/4 of the available SysV semaphores is not polite behaviour.
---
Gregory (Grisha) Trubetskoy wrote:
On Tue, 9 Aug 2005, Jim Gallacher (JIRA) wrote:
pspcache will hash to one of 31 mutexes. Therefore there is a 1 in
31 chance for a hash collision if a session is used in the same
request, which would result in a deadlock. (This has been confirmed
Gregory (Grisha) Trubetskoy wrote:
Another thing that should probably go in before 3.2. The RedHat people
patch mod_python with this patch in the source RPM (smart-ass comment
included):
-
Stealing 1/4 of the available SysV semaphores is not polite behaviour.
---
that there is not much activity in the project
which is not the case.
Is Scott out there?
Regards,
Jim
Regards,
Nicolas
2005/7/29, Jim Gallacher [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Jim Gallacher wrote:
Gregory (Grisha) Trubetskoy wrote:
On Thu, 28 Jul 2005, Nicolas Lehuen
Nicolas,
I should have mentioned that I would like you to mark them as resolved,
but you have anyway, so all is well. :)
Jim
Jim Gallacher wrote:
Nicolas Lehuen wrote:
Hi Jim,
Do you want me to mark the issues resolved ? Don't you have the rights
to do this ? If you don't have the right
1 - 100 of 471 matches
Mail list logo
