Project: mod_python
Issue Type: Bug
Components: session
Affects Versions: 3.3.1
Environment: All
Reporter: Jim Gallacher
Assignee: Jim Gallacher
Priority: Minor
Reported by David Janes
Starting at line 705 in Session.py
[
https://issues.apache.org/jira/browse/MODPYTHON-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gallacher resolved MODPYTHON-243.
-
Resolution: Fixed
Fix Version/s: 3.3.x
FileSession trys to log an error
Gregory (Grisha) Trubetskoy wrote:
I like Quetzalcoatl and PyPache.
Quetzalcoatl is still my sentimental favourite.
Perhaps I'm overly concerned with potential search problems for
Quetzalcoatl, considering that Google is pretty good at figuring out
spelling errors. Also the mod_python
Gregory (Grisha) Trubetskoy wrote:
So I think we've got (in no particular order):
PythonScript
Pythonidae
PyPache
pythonalia
Quetzalcoatl
Asphyxia
Scales
Pythonistas
PigeonPy
Pungi
Would people (ANYONE here on the list, yes, that includes *YOU*) please
respond with the one they like most and
How about this last minute entry as a place to keep our snake?
Apache Terrarium
Jim
Gregory (Grisha) Trubetskoy wrote:
So I think we've got (in no particular order):
PythonScript
Pythonidae
PyPache
pythonalia
Quetzalcoatl
Asphyxia
Scales
Pythonistas
PigeonPy
Pungi
Would people
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
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
Roy T. Fielding wrote:
On Feb 7, 2007, at 6:47 PM, Roy T. Fielding wrote:
The vote shall be open 72 hours or until all of the mod_python
core group members have voted, whichever is earlier.
Well, I didn't get enough responses, so this will have to wait
until after folks figure out what to do
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
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
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
I think we have sufficiently tested 3.3.1 and it is time for the core
group to vote on a release.
This vote is only open to the mod_python core group (Grisha, Nicolas,
Graham and myself) and is binding. We need at least three +1 votes for
the release to proceed. A -1 from any of the four
+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
to include the
mod_python version 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
On Mon, Jan 29, 2007 at 09:32:36AM -0500, Jim Gallacher wrote:
The mod_python 3.3.1 tarball is available for testing. Hopefully
Nicolas will have a chance to create Windows installers for testing in
the next couple of days.
There have been no changes in the code since
Howdy All,
I think it's time to push 3.3.1 out. Unless there are any objections
I'll roll the tarball tomorrow, which is to say Sunday, or Monday as the
case may be for our antipodal friends. :) ).
Since we haven't made any changes in the code base it should be just a
matter of a few people
We don't seem to be getting any more feedback on 3.3.0b (+1's across the
board), so how does everyone feel about rolling out 3.3.1 this weekend?
Or should we wait another week?
3.3.0b test result summary:
+1 FreeBSD 6.1, Apache 2.2.3 (mpm-prefork), Python 2.4.3,1
+1 Linux Debian 3.1 Sarge,
Clodoaldo wrote:
In 4.8.1 of the 3.3 manual, last paragraph of the Session class:
you should instead use the now obsolete session option instead.
The word instead is repeated.
Thanks. Corrected in trunk.
Jim
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
releasing quick
fixes for 3.2. There is no reason why we can't do the same with 3.3, so
my inclination is to do an official 3.3.0 final release now rather than
later.
Jim
On Mon, 11 Dec 2006, Jim Gallacher wrote:
Test results so far, FYI. How long shall we wait until we kick it up
to the next
Graham Dumpleton wrote:
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. :)
I'd have to concur, that not specific about what
-worker), Python 2.4.3
+1 Linux Ubuntu 6.10, Apache 2.0.55 (mpm-prefork), Python 2.4.4c1
Jim Gallacher wrote:
The mod_python 3.3-0b tarball is available for testing. Hopefully
Nicolas will have a chance to create Windows installers for testing in
the next couple of days.
Here are the rules
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
Graham Dumpleton wrote:
On 07/12/2006, at 12:42 AM, Jim Gallacher wrote:
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
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
Clodoaldo wrote:
2006/12/3, Graham Dumpleton [EMAIL PROTECTED]:
Jim, I have updated LaTeX documentation for the apache.import_module()
function. Can you run it through LaTeX and fixup all my wrongly
closed LaTeX
formatting. :-)
Can you and anyone else who is interested, read through the
Graham Dumpleton wrote:
Jim, I have updated LaTeX documentation for the apache.import_module()
function. Can you run it through LaTeX and fixup all my wrongly closed
LaTeX
formatting. :-)
Can you and anyone else who is interested, read through the documentation
I have added and comment on
Graham Dumpleton wrote:
Jim, I have updated LaTeX documentation for the apache.import_module()
function. Can you run it through LaTeX and fixup all my wrongly closed
LaTeX
formatting. :-)
It would seem LaTeX doesn't like naked tilde characters, as ~ is used
for markup. Something like:
The
Jim Gallacher wrote:
Graham Dumpleton wrote:
Jim, I have updated LaTeX documentation for the apache.import_module()
function. Can you run it through LaTeX and fixup all my wrongly closed
LaTeX
formatting. :-)
It would seem LaTeX doesn't like naked tilde characters, as ~ is used
for markup
Jim Gallacher wrote:
Jim Gallacher wrote:
Graham Dumpleton wrote:
Jim, I have updated LaTeX documentation for the apache.import_module()
function. Can you run it through LaTeX and fixup all my wrongly
closed LaTeX
formatting. :-)
It would seem LaTeX doesn't like naked tilde characters
[ http://issues.apache.org/jira/browse/MODPYTHON-19?page=all ]
Jim Gallacher resolved MODPYTHON-19.
Fix Version/s: 3.3
Resolution: Fixed
CategorySecurity and SecurityConsiderations sections have been added to the
mod_python wiki. Links
Jorey Bump wrote:
Hi, Jim:
Jim Gallacher wrote:
The following page has been changed by JoreyBump:
http://wiki.apache.org/mod_python/MostMinimalRequestHandler
--
Let's begin at the beginning. Here is the most
Eric Brunson wrote:
I apologize if this goes out twice, I think I wrote it on my laptop at
work, then shut it down without hitting send.
While upgrading to 3.3 on Thursday I ran into the previously discussed
pthread_* unresolved symbol problem and used the
LD_PRELOAD=/lib/libc_r.so fix, which
Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Mod_python Wiki for
change notification.
The following page has been changed by MartinStoufer:
http://wiki.apache.org/mod_python/Session_use_with_classes
The comment on the change is:
A good start.
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Several of your other warnings such as:
C:\work\mod_python-3.3.0-dev-20061109\src\util.c(170) : warning C4244:
'function' : conversion from 'double' to 'long', possible loss of data
are the result of converting apr_time_t from microseconds
[
http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12449192
]
Jim Gallacher commented on MODPYTHON-202:
-
We seem to be going pretty far down the road with PythonOption and our
new namespace, so I'm inclined
assistance,
Jim Gallacher
-worker), Python 2.4.4
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.5
Jim Gallacher wrote:
The mod_python 3.3-0-dev-20061109 tarball is available for testing.
We are almost ready for a 3.3.0 release. It's been a while since we've
had extensive testing of trunk and I think it would be wise
Jorey Bump wrote:
Jim Gallacher wrote:
The mod_python 3.3-0-dev-20061109 tarball is available for testing.
As this is a minor version bump, is there a link to the changelog so we
know what new behaviour to expect/test?
Take a look at doc-html/app-changes-from-3.2.10.html in the tarball
Jorey Bump wrote:
Jim Gallacher wrote:
Jorey Bump wrote:
Jim Gallacher wrote:
The mod_python 3.3-0-dev-20061109 tarball is available for testing.
As this is a minor version bump, is there a link to the changelog so
we know what new behaviour to expect/test?
Take a look at doc-html/app
unresolved externals
What are these functions?
- Jeff
- Original Message - From: Jim Gallacher [EMAIL PROTECTED]
To: python-dev list python-dev@httpd.apache.org
Sent: Thursday, November 09, 2006 9:00 AM
Subject: mod_python 3.3.0-dev-20061109 available for testing (release
candidate
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448585 ]
Graham Dumpleton commented on MODPYTHON-202:
A configuration option can possibly be modelled off how the AcceptMutex
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Graham Dumpleton (JIRA) wrote:
[
http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448585
]
Graham Dumpleton commented on MODPYTHON-202:
A configuration
[
http://issues.apache.org/jira/browse/MODPYTHON-172?page=comments#action_12447658
]
Jim Gallacher commented on MODPYTHON-172:
-
[[ Old comment, sent by email on Fri, 07 Jul 2006 21:26:01 -0400 ]]
I've been working through
[
http://issues.apache.org/jira/browse/MODPYTHON-184?page=comments#action_12447666
]
Jim Gallacher commented on MODPYTHON-184:
-
[[ Old comment, sent by email on Wed, 16 Aug 2006 17:44:21 -0400 ]]
Actually I don't think
Graham Dumpleton wrote:
Incomplete documentation. For AddHandler it would always have required
the .psp_ extension case to be listed explicitly.
I'll fix the docs.
Jim
On 05/11/2006, at 3:04 AM, Jim Gallacher wrote:
I was doing a bit of work on the Docs and I noticed a problem
however. I'd be pretty surprised if we could go directly from trunk to
3.3.0-final anyway.
Jim
Graham
On 05/11/2006, at 8:35 AM, Jim Gallacher wrote:
It sure feels like we are close thanks to Graham's hard work. I've
been doing some testing and it's looking good.
With 3.3.0-dev-20061104
:26 AM, Jim Gallacher (JIRA) wrote:
ReportError in importer.py raises an exception for mal-formed psp
-
Key: MODPYTHON-201
URL: http://issues.apache.org/jira/browse/MODPYTHON-201
Project
[ http://issues.apache.org/jira/browse/MODPYTHON-201?page=all ]
Jim Gallacher closed MODPYTHON-201.
---
Fix Version/s: 3.3
Resolution: Fixed
Already fixed in a more recent commit.
ReportError in importer.py raises an exception for mal-formed psp
I was fixing a error in the new mp_conn.log_error method and I noticed
that the connobject struct has a PyObject *server element. There is no
corresponding apache conn_rec-server attribute, I don't see it being
used anywhere in our code, and it is undocumented in mp_conn members.
See
It sure feels like we are close thanks to Graham's hard work. I've been
doing some testing and it's looking good.
With 3.3.0-dev-20061104 (r471260):
+1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.3.5
+1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.4.1
+1
every time if the fix is not applied. We have to run on Windows
(long story there) and need to run long term leak-free.
Thanks,
Jeff
- Original Message - From: Jim Gallacher [EMAIL PROTECTED]
To: python-dev@httpd.apache.org
Sent: Saturday, November 04, 2006 4:35 PM
Subject: Are we ready
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 (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=all ]
Graham Dumpleton resolved MODPYTHON-127.
Resolution: Fixed
For now I have just made the tests use the new option names. There is obviously
a risk
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
--
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
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
Jim Gallacher wrote:
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Although there is no JIRA issue for it, I'd like to see us do a quick
code cleanup. I see lots of complier warnings about unused variables and
it would be nice to excise the offending bits of code. I figure we are
more likely
[ http://issues.apache.org/jira/browse/MODPYTHON-190?page=all ]
Jim Gallacher updated MODPYTHON-190:
Attachment: ssizecheck.diff
ssizecheck.py will include functions which are enclosed in comments in its
output. Since I've added comments
[ http://issues.apache.org/jira/browse/MODPYTHON-59?page=all ]
Jim Gallacher closed MODPYTHON-59.
--
Resolution: Won't Fix
General agreement was that the proposed solution for this feature was
sub-optimal. The stub for get_session() has been removed
[ http://issues.apache.org/jira/browse/MODPYTHON-53?page=all ]
Jim Gallacher resolved MODPYTHON-53.
Resolution: Fixed
Show link for subversion and JIRA on www.mod_python website
Graham Dumpleton wrote:
On JIRA, the following issues are still marked as incomplete for mod_python
version 3.3. I have noted my own comments about where they are up to and
what I think still needs to be done.
MODPYTHON-93 Improve util.FieldStorage efficiency.
This was actually marked as
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Graham Dumpleton wrote:
On JIRA, the following issues are still marked as incomplete for mod_python
version 3.3. I have noted my own comments about where they are up to
and
what I think still needs to be done.
MODPYTHON-93 Improve
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
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
[
http://issues.apache.org/jira/browse/MODPYTHON-127?page=comments#action_12441188
]
Jim Gallacher commented on MODPYTHON-127:
-
+1
Your suggestion is logical. Explicit is better than implict.
Use namespace for mod_python PythonOption
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
Reporter: Jim Gallacher
Fix For: 3.3
Python 2.5 has been offically released, The major change that may effect
mod_python is better support for 64-bit machines, allowing for things such as
strings 2GiB.
Details and conversion guidelines can be found in PEP-353.
http
[ http://issues.apache.org/jira/browse/MODPYTHON-182?page=all ]
Jim Gallacher resolved MODPYTHON-182.
-
Resolution: Fixed
Memory leak in request readline()
-
Key: MODPYTHON-182
URL
Woot Woot Woot! We have our wiki!
http://wiki.apache.org/mod_python/
Now comes the hard part... what the heck are we going to do with it? :)
Jim
Dan Eloff wrote:
Unrelated question, is it ok to use the trunk in a development
environment? It will usualy work, or should I expect it to blow up in
my face more often than not?
At this point in the development cycle you are fairly safe. As later
messages in this thread indicate you've been
Since there doesn't seem to any movement on our request to ASF
infrastructure for our wiki, and after seeing yet another thread of
installation woes on the the user list, I'm thinking we should at least
buff up the installation and trouble shooting section of the docs. It'll
be a race to see
[
http://issues.apache.org/jira/browse/MODPYTHON-187?page=comments#action_12431530
]
Jim Gallacher commented on MODPYTHON-187:
-
I've audited tableobject.c for other lines where NULL is being passed to
PyString_FromString and found
Alan Kennedy wrote:
Greetings,
I think the following may be a bug in mod_python. I can't seem to find a
bug database or tracker for mod_python?
http://issues.apache.org/jira/browse/MODPYTHON
No time to investigate right now. I'll take a look tonight.
Jim
When subscripted access is used to
[
http://issues.apache.org/jira/browse/MODPYTHON-187?page=comments#action_12431099
]
Jim Gallacher commented on MODPYTHON-187:
-
Confirmed for Apache 2.0.55 mpm-worker (Linux Ubuntu 6.0.6), execpt I get a
segfault rather than a hang
[ http://issues.apache.org/jira/browse/MODPYTHON-187?page=all ]
Jim Gallacher updated MODPYTHON-187:
Attachment: MP187-2006-08-28-jgallacher-1.diff
I hope I have the reference count right!
Hang on subscripted access to request.subprocess_env
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
David Fraser wrote:
David Fraser wrote:
Graham Dumpleton wrote:
On 18/08/2006, at 7:48 PM, Richard Lewis wrote:
On Tuesday 15 August 2006 23:31, Graham Dumpleton wrote:
Richard Lewis wrote ..
Do you mean that there will be no opportunity to have code run at
server
shutdown?
Correct. Reason
Justin Erenkrantz wrote:
On 8/17/06, Graham Dumpleton [EMAIL PROTECTED] wrote:
Also, dist/setup.py in mod_python source contains:
...
But I think this was a workaround for older version of Mac OS X.
What is the actual error you are getting when building?
Um, how are you building?
Per
Alexis Marrero wrote:
Jim,
This are my results for the memory leak search in apache.table().
The table object creates a memory pool by using apr_pool_create_ex() and
destroys the pool using apr_pool_destroy(). I added a line in
MpTable_New() before return (PyObject*)t to destroy the pool
Graham Dumpleton wrote:
On 14/08/2006, at 1:42 AM, Jim Gallacher wrote:
Lets target this to be done for 3.3. We just need some agreement that
proposed names are okay, plus a consensus on how we go about
deprecating old names. Do we have an option now which if enabled
prohibits use of old
[ http://issues.apache.org/jira/browse/MODPYTHON-185?page=all ]
Jim Gallacher resolved MODPYTHON-185.
-
Fix Version/s: 3.3
Resolution: Fixed
_psp.parsestring doesn't check for empty values
other bug in mp_table.
BTW, thanks for the time you've spent digging into these leaks.
Jim
/amn
On Aug 13, 2006, at 12:01 PM, Jim Gallacher (JIRA) wrote:
Memory leak apache.table()
--
Key: MODPYTHON-184
URL: http
Graham Dumpleton wrote:
On 14/08/2006, at 12:29 AM, Jim Gallacher wrote:
Anyway, if we can make a decision that we will make new importer the
default in 3.3 that would be great and would allow me to progress with
other
ideas. When I have raised this question before though, never really
Graham Dumpleton wrote:
On 13/08/2006, at 12:35 AM, Jim Gallacher wrote:
Graham,
In your JIRA cleanup session you made the comment a number of times that
the new importer is not likely to be the default in 3.3. I'm just
wondering why it can't be the default, with the old importer
I've committed the current version of my memory leak test harness to
svn. It lives in branches/jgallacher/tools/leaktest
It's a *nix only tool, originally developed on Ubuntu Dapper Drake, so
you may need to hack it a little to get it to work smoothly on other
platforms. That being said, it's
I like this proposal. The PythonAllowOverride -whatever in particular is
something that has great appeal.
Jim
Graham Dumpleton (JIRA) wrote:
Stop Python directives being used in .htaccess files.
-
Key: MODPYTHON-183
):
line = req.readline()
if not line:
break
count += 1
req.write('ok readline: %d lines read' % count)
return apache.OK
Jim
Jim Gallacher wrote:
I'll have some time to investigate this over the next couple of days. I
ran my leaktest script for FieldStorage
, 3.2.x
Environment: Apache 2.0.55 mpm-worker
Reporter: Jim Gallacher
Assigned To: Jim Gallacher
There is at least one memory leak request.readline(). I'm currently auditing
the code so there may well be others.
I think the leak will only occur when the request body
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
Nicolas Lehuen wrote:
Hi Earle,
Thanks for your input.
For the sake of performance, you way want to call a single DELETE FROM
session WHERE accessed ? request instead of fetching all the session id
and access time from the database and calling a delete per session. See for
example this
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
- that's
when you are geographically in a different place with slow internet
access and read only some of your e-mail ;-)
+1 for core vote (with the note about the 2.2.2 XP SP2 issue).
Grisha
On Sat, 8 Jul 2006, Graham Dumpleton wrote:
On 08/07/2006, at 4:26 AM, Jim Gallacher
Here is further confirmation that it leaks like crazy for:
mod_python 3.2.10, Linux Ubuntu 6.06, Apache 2.0.55 (mpm-worker), Python
2.4.3
Jim
Graham Dumpleton wrote:
I get it on Apache 2.0.59 as well. :-(
I will thus be interested to see what others get, as appears to be an existing
Max Bowsher wrote:
Graham Dumpleton wrote:
Okay, found the source of the memory leak. The problem goes right back
to 3.1.4 which also has the problem when tested.
...
Now what do we do about 3.2.10? Given that this thing leaks really badly
when triggered shows that no one must be using
1 - 100 of 471 matches
Mail list logo
