; active request, as the docs intimate
No from 4.1.0 onwards.
> whether there is any way to get maximum-requests to behave more gently under
> all circumstances
By setting a very very long graceful-timeout.
> for your ideas/best advice
Have a good read through the release notes for 4.1.0
Version 4.4.6 was released yesterday. Can you give it a try now.
On 13/01/2015, at 11:45 AM, Graham Dumpleton wrote:
>
> On 13/01/2015, at 12:44 AM, Michael Radziej
> wrote:
>
>> Tomorrow night is still great!
>
> No promises unfortunately.
>
> Various stu
On 17/01/2015, at 5:17 AM, Michael Radziej
wrote:
> On my dev system it works. The intermediate package crashed in a testing
> environment. We're going to try 4.4.6 there soon.
Make sure you have read:
http://blog.dscpl.com.au/2015/01/important-modwsgi-information-about.html
The changes ne
t; Thanks,
> Mohd
>
> On Tuesday, January 13, 2015 at 4:39:31 PM UTC+5:30, Graham Dumpleton wrote:
> Sorry, I have a fire I need to deal with first which you will see more
> information about soon. Once that is out of the way then I will look more
> closely at it and try and re
distributions ship with.
Graham
On 18/01/2015, at 1:19 PM, Graham Dumpleton wrote:
> I still haven't had a chance to replicate it but can you try the very latest
> version of mod_wsgi (4.4.6).
>
> There was a change in mod_wsgi 4.4.0 related to how request content is
> r
cumentation: I thought I was reading
> current version.
> Kent
>
> P.S. I also have ideas for possible vertical URL partitioning, but
> unfortunately, our app has much cross-over by URL, so that's why I'm down
> this maximum-requests path...
>
>
> On Friday,
loading files simultaneously, none of which will exceed 2GB
> at a time.
>
> thanks,
> Jennifer
>
>
>> On Jan 9, 2015, at 6:39 PM, Graham Dumpleton
>> wrote:
>>
>> There are two scenarios I can think of as being plausible to describe what
>>
There is no problem with using WSGIScriptAlias and Alias together. What is the
specific issue you are having?
The important thing to know about Alias vs WSGIScriptAlias is that Alias takes
precedence. This should be fine though if you are using WSGIScriptAlias at a
sub URL so long as you haven'
I am not sure there is much I can do to help you.
Ubuntu is shipping a version of mod_wsgi which is well over 2 years old and
about 20 versions behind.
I also have no idea what version of Apache their mod_wsgi binary was compiled
for. The issue could well be that you need to update your Apache
On 20/01/2015, at 11:50 PM, Kent wrote:
> On Sunday, January 18, 2015 at 12:43:08 AM UTC-5, Graham Dumpleton wrote:
> There are a few possibilities here of how this could be enhanced/changed.
>
> The problem with maximum-requests is that it can be dangerous. People can set
>
find
> apxs.
The PyPi page explains the system requirement of needing to have the Apache dev
package installed for your Apache installation. If you do not then apxs will
not be found.
Graham
> Thx
>
>
> On 21 January 2015 at 04:08, Graham Dumpleton
> wrote:
>> I am no
The normal way of doing things with Apache is that you would never use Alias
for '/'. Instead you would set:
DocumentRoot /home/[USER]/webapps/static
The reason is that DocumentRoot has lower precedence and various directives
from various Apache modules can then overlay the default fallback
On 22/01/2015, at 12:52 AM, nitin chandra wrote:
>
>>
>> Please explain exactly what you expect different URLs to do. That is for:
>>
>>/
>>/index.py
>>/wsgi-scripts
>>/wsgi-scripts/
>>
>>
>
> I just want to server my site from /wsgi-scripts/index.py from ONLY one URL.
>
>
OG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
For exactly that, if there is an error, then say what error messages there was
in the Apache error log and not just that you got a particular status in the
browser.
Make sure there are no other VirtualHost's being defi
1:13:44.144+0530 [clientcursormon] connections:3
> 2015-01-23T01:18:44.162+0530 [clientcursormon] mem (MB) res:14 virt:1193
> 2015-01-23T01:18:44.162+0530 [clientcursormon] mapped (incl journal view):992
> 2015-01-23T01:18:44.162+0530 [clientcursormon] connections:3
>
>
>
>
>
&
s
> tcT = db.tb_users.count()
> paswd = base64.b64encode('admin123')
> if tcT == 0 :
> tc.insert({'user' : 'admin', 'password' : paswd})
> else :
>pass
>
> html = "&q
On 24/01/2015, at 3:58 AM, nitin chandra wrote:
> On 23 January 2015 at 16:33, Graham Dumpleton
> wrote:
>> Why were you even using:
>>
>>WSGIScriptAlias /wsgi-scripts/ /home/nitin/wsgi-scripts/index.py
>>
>> in the first place?
>>
>>
But you also want '/' to redirect to '/index.py'?
Graham
On 24/01/2015, at 7:25 AM, nitin chandra wrote:
> On 24 January 2015 at 01:29, Graham Dumpleton
> wrote:
>>
>> On 24/01/2015, at 3:58 AM, nitin chandra wrote:
>>
>>> On 23 January
As you have LogLevel set to info, you should be able to tell from the Apache
error logs whether daemon process group reloading is occurring.
So, touch the WSGI script file, and then on the next web request against the
application, see if the error log shows processes being shutdown and restarted
January 20, 2015 at 5:53:26 PM UTC-5, Graham Dumpleton wrote:
>
> On 20/01/2015, at 11:50 PM, Kent wrote:
>
>> On Sunday, January 18, 2015 at 12:43:08 AM UTC-5, Graham Dumpleton wrote:
>> There are a few possibilities here of how this could be enhanced/changed.
>>
>>
t the best way of achieving that which
will avoid a potential fork bomb if the problem isn't transient.
Graham
On 15/01/2015, at 6:22 PM, Graham Dumpleton wrote:
> Looks like you are getting hit by an issue which have seen a few times
> before, but since rarely shown to me and have
What version of mod_wsgi is it and is it a precompiled binary package supplied
by a Linux distro? If is a precompiled binary, what Linux distro is it?
Also, have you updated your Apache installation lately by way of updating all
system packages? Or was this never working, as opposed to it was wo
e of the web page. So, when I '/' to redirect to '/index.py', I
> mean to load the index.py as the first page of the application.
>
> So should I do "/wsgi-scripts/ /home/nitin/wsgi-scripts/" ?
>
> Thx
>
> Nitin
>
> On 24 January 2015 at 02:39,
What version of Apache and mod_wsgi does WebFaction use?
If they are still using Apache 2.2 and also an older mod_wsgi version, that is
likely to be the cause.
Apache 2.2 has various issues in it with excessive memory usage that Apache 2.4
fixes.
Newer versions of mod_wsgi also provide workaro
x27;,
> application='www.healthcare.in|/wsgi-scripts/fullcalendar-1.5.1/jquery/jquery-1.5.2.min.js'):
> Failed to parse WSGI script file
> '/home/nitin/wsgi-scripts/fullcalendar-1.5.1/jquery/jquery-1.5.2.min.js'.
> [Mon Jan 26 18:29:51.549319 2015] [:error] [pid 6815] [remot
5] [info] mod_wsgi (pid=31986): Cleanup interpreter
> ''.
> [Fri Jan 16 23:47:40 2015] [info] mod_wsgi (pid=31986): Terminating Python.
> [Fri Jan 16 23:47:40 2015] [info] mod_wsgi (pid=31986): Python has shutdown.
>
> further more, this problem occurs only when the app is
Can you clarify a couple of things.
Does the daemon process crash on Apache startup before ay requests, or only on
the first request?
How were you trying to use gdb to debug the crash?
The documentation at:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Debugging_Crashes_With_G
On 27/01/2015, at 11:09 PM, Paul Royik wrote:
> They use Apache 2.2 and mod_wsgi 3.4
> How can I upgrade them from command line.
>
> Please guide me, as I'm very new to this.
It has been a very long time since I have logged onto a WebFaction system so my
memory of it is very slim.
There are
On 28/01/2015, at 9:06 AM, Joonas Lehtolahti wrote:
> On Tue, 27 Jan 2015 23:12:59 +0200, David Gleba wrote:
>
>> My mysite.wsgi:
>>
>>import os, sys
>>>sys.path.append('c:/p2/xampp/htdocs/django/mysite')
>>>os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
>>># works:
ed
>
>
> ErrorLog ${APACHE_LOG_DIR}/error.log
> CustomLog ${APACHE_LOG_DIR}/access.log combined
>
>
>
> Reg
>
> Nitin
>
> On 27 January 2015 at 08:41, Graham Dumpleton
> wrote:
>> This isn't what I told you to use at all, it is actually the
gt;
> On Tuesday, January 27, 2015 at 9:34:12 AM UTC-5, Kent wrote:
> I think I might understand the difference between 'graceful-timeout' and
> 'shutdown-timeout', but can you please just clarify the difference? Are they
> additive?
>
> Also, will
Can you show me what is in:
/home/simamura/webapps/django_app/apache2/conf/httpd.conf
and also show me what you get if you run:
$HOME/webapps/django_app/apache2/bin/httpd.worker -V
Finally, since I recollect they stashed the original Apache under /usr/local,
what do you get for:
l
WebFaction certainly looks to be making this very hard.
Lets try a few more places and if what I am looking for isn't there, I think
you are out of luck as far as easy path goes.
So, what do you get for:
ls -las /usr/local/bin
ls -las /usr/local/sbin
ls -las /usr/local/include
BTW,
What you need is missing.
In:
https://twitter.com/GrahamDumpleton/status/560759616867295232
WebFaction has basically acknowledged it is impossible without building your
own Apache.
The page they refer to is quite out of date though in respect of the versions
it uses.
I will not get to it
On 30/01/2015, at 3:33 AM, Paul Royik wrote:
> I want advice what to do
>
> If you think that proposed path is good, then let' go for it.
As first step, log into your WebFaction account.
I don't know how WebFaction sets you up with a writable Python installation,
but if you are using a Pytho
ceful-timeout/eviction-timeout and so is only guaranteed a lifetime of
> shutdown-timeout, regardless of what the trigger was (SIGUSR1 vs. automatic).
>
> Is my understanding of this accurate?
>
>
>
> On Tuesday, January 27, 2015 at 9:48:01 PM UTC-5, Graham Dumpleton
On 30/01/2015, at 11:08 PM, Paul Royik wrote:
> I don't use virtualenv.
> Do I need to install it?
No. Sounds like WebFaction already sets up something for you else you wouldn't
be able to install any Python packages.
> Also,
>
> crontab -l should be run after MOD_WSGI_REQUIRE_APACHE=true p
What do you get if you run:
umask
That is the very last thing would expect to see and would suggest your shell
environment has a strange permissions setup.
Graham
On 31/01/2015, at 8:55 AM, Paul Royik wrote:
> After running command I've got the following:
>
> 100% |#
And what do you get for:
python -v
That is, after the full python version.
Graham
On 31/01/2015, at 9:27 AM, Graham Dumpleton wrote:
> What do you get if you run:
>
> umask
>
> That is the very last thing would expect to see and would suggest your shell
> environ
Okay, the reason it failed was because it was using Python 2.6. The tar file
module in older Python versions didn't honour umask setting.
The issue now is what Python version do you want to be using?
Your Apache configuration had:
WSGIDaemonProcess django_app processes=2 threads=12
python-
emely helpful, though and I'm quite thankful for your
> time! I understand you not wanting to redesign the shutdown-timeout thing
> and mess with what otherwise isn't broken. Would you still like me to post
> the apache debug logs regarding 'eviction-timeout'
On 31/01/2015, at 8:43 PM, Paul Royik wrote:
> I already noticed that in terminal Python 2.6 is used. I asked support how to
> change to installed 2.7 version, but did not get answer.
> Were you explicitly using pip2.7 or python2.7 on package setup,py files?
> I used only pip, not pip 2.7
Let
On 31/01/2015, at 5:53 AM, Apollo Clark wrote:
> I want to host multiple Flask apps under the same domain, ex:
> example.com/app1
> example.com/app2
>
> System configuration:
> Ubuntu 14.04 TLS
> Apache 2.4.7ubuntu4.1
> mod_wsgi 4.4.6
> Python 2.7.6
>
> You can find my VirtualHost config he
On 02/02/2015, at 8:57 PM, Paul Royik wrote:
> It appears that I already installed pip 2.7 (because pip 2.7 ran without
> errors).
>
> But commmand pip2.7 install --user mod_wsgi-httpd gives error:
> Downloading
> http://downloads.sourceforge.net/project/pcre/pcre/8.36/pcre-8.36.tar.gz
>
On 02/02/2015, at 9:08 PM, Paul Royik wrote:
> There is no such file.
> I looked over hidden files, but still without success.
What do you get when you run:
pip2.7 --version
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from thi
On 02/02/2015, at 9:14 PM, Paul Royik wrote:
> pip 6.0.6 from /home/username/lib/python2.7/pip-6.0.6-py2.7.egg (python 2.7)
Try:
pip2.7 -v -v -v --log $HOME/pip.log install --user mod_wsgi-httpd
And see if $HOME/pip.log is created.
Graham
--
You received this message because you are su
Something is still screwing with file permissions when the tar ball is unpacked.
This time I changed to using normal 'tar' command to extract the tar ball to
ensure that Python tarfile module couldn't cause any issues.
You said umask command gave:
0002
which means it should be fine.
I can
On 02/02/2015, at 10:07 PM, Paul Royik wrote:
> rm $HOME/pip.log
>
> pip2.7 -v -v -v --log $HOME/pip.log install --user --build $HOME/tmp/pip
> mod_wsgi-httpd
>
> "Successfully installed mod-wsgi-httpd-2.4.12.3"
>
> Next, mod_wsgi-apxs -q INCLUDEDIR outputs
>
> "/home/username/lib/python2.
BTW, what WebFaction is probably doing is:
https://www.debian-administration.org/article/57/Making_/tmp_non-executable
That is mounting /tmp with 'noexec' mount option.
Good to have actually come across that, as would have hit it later in another
way when running mod_wsgi-express in steps I
x routing
>
> None of these are particularly elegant, and will be tedious to maintain, and
> difficult to automate. I'm going to attempt to do the same configuration in
> Ubuntu 12.04, and see if I can get that working. Next I'll move onto
> ProxyPass, and if all else fai
On 3 February 2015 at 04:15, Kent Bower wrote:
> On Sun, Feb 1, 2015 at 7:08 PM, Graham Dumpleton <
> graham.dumple...@gmail.com> wrote:
>
>> Your Flask client doesn't need to know about Celery, as your web
>> application accepts requests as normal and it is your
The application of the eviction timeout should not be fixed in develop branch.
https://github.com/GrahamDumpleton/mod_wsgi/archive/develop.tar.gz
Graham
On 03/02/2015, at 5:02 PM, Graham Dumpleton wrote:
>
>
> On 3 February 2015 at 04:15, Kent Bower wrote:
> On Sun, Feb 1,
Should now be fixed.
On 03/02/2015, at 8:50 PM, Graham Dumpleton wrote:
> The application of the eviction timeout should not be fixed in develop branch.
>
> https://github.com/GrahamDumpleton/mod_wsgi/archive/develop.tar.gz
>
> Graham
>
> On 03/02/2015, at 5:02
If you want continued help, I really need to see the Apache configuration you
are using, as asked for last time. Preferably if you can provide the full
Apache configuration and not just the snippet so can see what else is in the
Apache configuration in the way of Listen, NameVirtualHost and Virt
On 04/02/2015, at 6:22 PM, Paul Royik wrote:
> Hello.
> Is there any way we can proceed?
Before we do, I want to make the point that nothing of what we do could help.
There is an assumption here on my part that you have yourself at least done
something to eliminate the possibility that it is
On 04/02/2015, at 8:57 PM, Paul Royik wrote:
> I'm sure that my application does nothing that eats 600 mb of memory.
>
> Also, I have a question. After we've made installations, site is constantly
> receiving 502 error. I didn't change anything. Is this possible?
When you say constantly, do y
On 04/02/2015, at 9:05 PM, Paul Royik wrote:
> In user/error.log there is "premature end of script: wsgi.py". This error
> resolves automatically after server restart.
Can I see more than just that message, but also any messages from before and
after, with time stamps included.
Basically giv
On 04/02/2015, at 9:19 PM, Paul Royik wrote:
> ls -las $HOME/webapps/django_app
>
> 4 drwxr-xr-x 6 simamura simamura 4096 Jan 23 19:15 .
> 4 drwxr-xr-x 12 root root 4096 Feb 3 09:34 ..
> 4 drwxr-xr-x 7 simamura simamura 4096 Jan 23 12:42 apache2
> 4 drwxr-xr-x 3 simamura simamura 4
The error message:
"premature end of script: wsgi.py"
in the version of mod_wsgi you are using would generally indicate that the
daemon process had crashed in some way.
This is why I asked for the surrounding messages from the Apache error log as
there would be other messages in there conf
On 04/02/2015, at 9:41 PM, Paul Royik wrote:
> I actually have two webapplications django_math and django_site.
>
> Do I still need to add WSGIApplicationGroup %{GLOBAL}?
You are going to make it very confusing for me if you are moving/renaming
things.
The original Apache configuration you g
On 04/02/2015, at 9:55 PM, Paul Royik wrote:
> Sorry to confuse you.
> There are two webapps: django_gradis and django_math. They separately have
> apache2 folder. So I can safely add WSGIApplicationGroup %{GLOBAL} to both?
>
> crontab -l
> 15,35,55 * * * * ~/webapps/django_math/apache2/bin/
On 04/02/2015, at 10:02 PM, Paul Royik wrote:
> I order hosting less than 3 weeks ago. I'm still on 60day money-back.
> And I really don't know what to do as problems start. My previous hosting
> bluehost didn't have such problems.
>
> Anyway, what should I do next. Let's assume that there is
Do you understand how your Django static file assets are being served up with
WebFaction?
Have you set a static only WebFaction application in their control panel to
serve static file assets for each of your sites and are already using
'python2.7 manage.py collectstatic' to copy them under a di
On 04/02/2015, at 10:52 PM, Paul Royik wrote:
> I created separate application and serve files from there.
>
> "Or do you believe that WebFaction is relying on django.contrib.staticfiles
> for serving up static file assets even though it isn't recommended for
> production? " I don't know.
Would likely put you in a worse position as they absolve themselves from
telling you anything about how to set it up properly.
So more than likely you would end up with something worse than what they had
for other reasons.
Their default configuration for their installer avoids various issues, b
Take it slow. Don't rush.
I am awake for about another 45 minutes.
We are going to start with:
$HOME/webapps/django_math
because that is what you supplied the last Apache configuration file.
Read through all the steps below first. Only when you believe you
understand things then consider doing
s in advance
>
> David
>
> On Friday, December 19, 2014 at 5:43:24 AM UTC-5, Graham Dumpleton wrote:
> After a long and arduous battle, almost giving in, and having to seek help
> from the masses, I have managed to compile working mod_wsgi 4.4.2 binaries
> for Windows.
>
&g
What do you get when you run:
mod_wsgi-apxs -q INCLUDEDIR
mod_wsgi-apxs -q CPPFLAGS
mod_wsgi-apxs -q CFLAGS
mod_wsgi-apxs -q EXTRA_INCLUDES
mod_wsgi-apxs -q EXTRA_CPPFLAGS
mod_wsgi-apxs -q EXTRA_CFLAGS
Graham
On 05/02/2015, at 11:47 PM, Paul Royik wrote:
> I've got err
/python/2.7 -name config_vars.mk
Graham
On 06/02/2015, at 9:28 PM, Graham Dumpleton wrote:
> What do you get when you run:
>
> mod_wsgi-apxs -q INCLUDEDIR
> mod_wsgi-apxs -q CPPFLAGS
> mod_wsgi-apxs -q CFLAGS
> mod_wsgi-apxs -q EXTRA_INCLUDES
>
Run:
pip uninstall mod_wsgi-httpd mod_wsgi
Say yes to each.
Reinstall both:
pip install mod_wsgi-httpd
pip install https://github.com/GrahamDumpleton/mod_wsgi/archive/develop.zip
When trying to upgrade the mod_wsgi package pip is uninstalling the old one but
in doing so is breakin
On 06/02/2015, at 10:45 PM, Paul Royik wrote:
> Again error.
> Failed to build APR. I guess I need to use tmp folder.
Yep:
pip2.7 -v -v -v --log $HOME/pip.log install --user --build $HOME/tmp/pip
mod_wsgi-httpd
and cleanup as before.
Graham
--
You received this message because you are sub
On 06/02/2015, at 10:54 PM, Paul Royik wrote:
> It worked.
> What next? The steps you've already specified?
Yes, follow the details instructions I previously gave.
All you have done so far is step 1. Now do step 2 onwards.
Make sure you read everything and you are confident you know how to ba
On 07/02/2015, at 4:57 AM, Paul Royik wrote:
> Thank you very much.
> However, I have a couple of questions.
> 1. New apache didn't work with memcache. I need to install memcache. Why is
> that? Previous version of apache worked without installation.
How did you install the memcache library pr
On 07/02/2015, at 7:49 AM, Paul Royik wrote:
> 1. I installed it with pyp2.7 python-memcache. Actually, I don't remember
> whether I installed it last time.
>
> ls -las $HOME/lib/python2.7
>
> 4 drwx-- 21 simamura simamura 4096 Feb 6 16:05 .
> 4 drwx-- 7 simamura simamura 4096
On 07/02/2015, at 8:42 AM, Paul Royik wrote:
> In fact traffic is not very heavy.
> 3000 pageviews per day.
>
> "how long do the requests run for" don't know. How to measure that? I have
> one page, that can run up to 150 sec. before timeout. Do I need to lower?
>
> Below is the part of error
On 09/02/2015, at 4:31 PM, Jared Vacanti wrote:
> I've been working on this same error for the last few days, and can't seem to
> find any way around it. I'm trying to use a virtual environment with my
> python install in order to move my Flask app into production. When I restart
> my webserv
On 09/02/2015, at 9:00 PM, Paul Royik wrote:
> Hello.
> What is the difference between request-timeout and socket-timeout?
Sorry, have had some dramas to sort out. Explaining this will have to wait
until tomorrow.
What exactly is your application doing anyway that it has request response
tim
-gnu/libutil.so.1 (0x7f01313d5000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f01310cf000)
>
> Running
> >>> import sys
> >>> print sys.prefix
> /usr
>
> Still only getting the one error: "ImportError: No module named site
> What is the difference between request-timeout and socket-timeout?
Socket timeout is a very low level timeout value that relates to how long a
blocking operation on a socket connection should allow to go on before timing
out.
If using mod_wsgi directly and not via mod_wsgi-express, the socke
On 10/02/2015, at 10:51 PM, Paul Royik wrote:
> Thank you for your response.
> I asked about socket-timeout, because yesterday I cahnged it to 170 and left
> request-timeout on 60 seconds.
> And it worked. There was no 504 error.
>
> I tried simultaneously on different computers access calcula
On 10/02/2015, at 11:57 PM, Paul Royik wrote:
> Output of ps auxwww is
>
> USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
> simamura 3282 0.0 0.0 108304 1888 pts/12 Ss+ 12:44 0:00 -bash
> simamura 7115 0.0 0.0 51548 1972 ?Ss Feb09 0:01
> /ho
The 502 is issued by upstream nginx and not Apache.
The logs:
[Wed Feb 11 03:39:29.734328 2015] [wsgi:info] [pid 20794:tid 140288199374592]
mod_wsgi (pid=20794): Exiting process 'localhost:20241'.
[Wed Feb 11 09:46:25.739769 2015] [mpm_event:notice] [pid 18462:tid
140264512485120] AH00489: Apac
On 11/02/2015, at 9:36 PM, Paul Royik wrote:
> What if I make cron to restart Apache every 5 minutes?
If you look at the existing cron entry, it isn't doing a 'restart' but a
'start'. This means that if Apache is already running it will effectively leave
it alone.
Triggering a 'restart' woul
Cool. Thanks for letting me know. Was going to try and respond tonight, but
looks like I don't need to now. :-)
On 13/02/2015, at 6:06 PM, Nigel Babu wrote:
> Bah, this turned out to be a bad piece of code in one of the extensions. It
> was supposed to spawn one set of 5 threads for processing
You don't need to resend the email. I know it was there. It has been a very
busy week. :-)
On 13/02/2015, at 8:55 PM, Paul Royik wrote:
> The issue is with memory.
> I noticed, that memory is increasing on every Django request.
> I found similar question here:
> http://stackoverflow.com/questi
You aren't getting what I mean.
Have you determined whether your process grows memory usage purely form the
Django parts of your application?
In other words, if you ran up the application and hit a URL which doesn't run
your algorithm, does it still grow in memory usage?
Make sure it isn't som
On 13/02/2015, at 10:14 PM, Paul Royik wrote:
> I'm sure, that this algorithm is a root of problem.
> Other pages are not a problem.
>
> How can I limit a time wthout a thread or stop it?
>
> For now code is following:
>
> @time_limit(45)
> def decorator(my_params):
> return integrate(my_pa
On 13/02/2015, at 10:37 PM, Paul Royik wrote:
> Thanks will try now.
>
> But memory issue is still not resolved, right?
Your existing code would never have actually stopped the running threads you
were creating when the join timed out. That is what the timeout does for that.
The threads woul
On 14/02/2015, at 6:35 AM, Paul Royik wrote:
> When you will have time, please, help me, because I'm totally lost.
Is this you:
http://stackoverflow.com/questions/28507359/limit-function-execution-in-python
Too similar, but different name.
Graham
--
You received this message because you ar
On 14/02/2015, at 6:16 PM, Paul Royik wrote:
> Yes. It is mine (just from account of friend).
>
> I was very glad, that it worked, but it worked only on localhost.
> It doesn't work on server.
But when you ran it locally, were you running it under mod_wsgi?
Some things using subprocesses don'
On 14/02/2015, at 9:03 PM, Paul Royik wrote:
> So, the only way is your way?
That didn't answer the question. When it worked locally was that under
mod_wsgi? On the server, how did it not work?
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" gr
On 14/02/2015, at 9:11 PM, Paul Royik wrote:
> Sorry.
>
> On localhost without mod_wsgi.
> On server it doesn't raise an error on timeout and consumed nearly gigabyte
> of memory.
>
>
> Anyway, I'm planning to use your way.
> Just wanted to ask. You wrote func.info = threading.local(). Why
On 14/02/2015, at 9:25 PM, Paul Royik wrote:
> But you wrote func.die_on_timeout.
> Do we need func.info.die_on_timeout here or function is same for all?
The die_on_timeout() function then accesses back via the thread local.
def die_on_timeout():
if time.time() > func.info.en
On 14/02/2015, at 11:01 PM, Paul Royik wrote:
> Thank you for all your help and time. You really helped me a lot.
> As a final note, I think that func.info.end_time = time.time() + seconds
> should be written outside wrapper, because end_time will be rewritten each
> time func is called (there
On 14/02/2015, at 11:42 PM, Paul Royik wrote:
> Why do we need to decrement counter (and use counter at all)?
To handle the fact that your call is recursive.
The first call of the function for that thread the counter will be zero. When
it calls itself against recursive it will be 1, so it wil
You aren't using the code I described. I never had hasattr() checks where you
have added them.
Did you try the code as I wrote it rather than rewriting it?
I am out and about so can't paste original code and what you have on SO to
show why it is now broke, so look at my original code and get r
On 15/02/2015, at 8:28 AM, Paul Royik wrote:
> import functools
> def time_limit(seconds):
> def decorator(func):
> func.info = threading.local()
> func.info.counter = 0
> def check_timeout():
> if time.time() > func.info.end_time:
> raise
On 15/02/2015, at 10:53 AM, Paul Royik wrote:
> I already tried this approach.
>
> It seems good.
> But when I tested it on server, by simultaneously executing page on two
> different computers, it gave me 500 error.
>
> How this can be explained? Again something with apache? Logs didn't show
ehow tune logging, so that real error is written?
>
> On Sunday, February 15, 2015 at 2:44:50 AM UTC+2, Graham Dumpleton wrote:
>
> On 15/02/2015, at 10:53 AM, Paul Royik wrote:
>
> > I already tried this approach.
> >
> > It seems good.
> > But when I
pid 23028:tid 139862016030464]
> mod_wsgi (pid=23028): Imported 'mod_wsgi'.
> [Sun Feb 15 01:58:06.549942 2015] [wsgi:info] [pid 23028:tid 139862016030464]
> mod_wsgi (pid=23028, process='localhost:20241', application=''): Loading WSGI
> script '/home/simamura/
501 - 600 of 5315 matches
Mail list logo
