Hi Graham,
Just following up on this thread. I replied with some details, but
maybe you missed those, or maybe i missed your reply. Or maybe this
isn't worth it and i should stop being lazy and just write out the
VirtualHost files :)
Ben
On 23 Dec 2008, at 01:13, Graham Dumpleton wrote:
>
> Have some further questions about what you want to do.
>
> Do you want a separate daemon process for each distinct Django site,
> or are you happy with one really fat process which contains each
> Django site in a separate sub interpreter of that process?
>
> How much memory does each Django site instance take up?
>
> How many different site instances would you have?
>
> Are all the site instances distinguishable by server name alone?
>
> Graham
>
> On Dec 23, 9:00 am, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
>> On Dec 22, 9:44 pm, Ben Eliott <ben.dja...@googlemail.com> wrote:
>>
>>> Hi Graham,
>>> I've finally managed to get back to the wildcard subdomains &
>>> mod_wsgi
>>> today. Unfortunately the discussion thread you mentioned has
>>> disappeared and after a few hours i still seem to be doing a good
>>> job
>>> of getting nowhere.
>>
>> I can still access thread with no problems.
>>
>>> Although you mentioned using mod_rewrite to get hold of the url
>>> variable, it looks like the %{SERVER} variable in mod_wsgi might
>>> take
>>> care of this already?
>>
>>> My main issue seems to be to accessing the %{SERVER} (or relevant
>>> mod_rewrite) variable in the .wsgi script, to specify a particular
>>> settings file.
>>
>>> Within a VirtualHost i have:
>>> WSGIApplicationGroup %{SERVER}
>>> WSGIDaemonProcess %{SERVER} ...threads etc
>>> WSGIProcessGroup %{SERVER}
>>
>> The %{SERVER} value is only magic when used with WSGIApplicationGroup
>> directive.
>>
>>> So this is probably hoplessly wrong also, but if you can give some
>>> further pointers that would be most kind.
>>
>> Can you post a more complete example of your Apache configuration
>> showing what you are trying to achieve.
>>
>> Sorry I didn't get back to you last time, it was a hectic few weeks.
>> Things have settled down somewhat now, so I'll go back over your
>> original post and work out again what it is you were trying to do.
>>
>> Graham
>>
>>> Thanks and Regards,
>>> Ben
>>
>>> On 9 Dec 2008, at 10:18, Graham Dumpleton wrote:
>>
>>>> On Dec 9, 8:05 pm, Ben Eliott <ben.dja...@googlemail.com> wrote:
>>>>> Graham,
>>>>> Thank you for coming back personally to such a lowly wsgi
>>>>> question! I
>>>>> started reading your email and thinking the answer was 'no', then
>>>>> ended up thinking 'definitely maybe'. I'll keep an eye out in case
>>>>> you
>>>>> post more, otherwise i'll follow those links and your directions
>>>>> and
>>>>> hope to report back with some progress.
>>
>>>> I'll definitely try and say more later when get a chance.
>>
>>>> Just do be aware of one thing. By using a single WSGI script file
>>>> for
>>>> multiple sites, you loose the ability with mod_wsgi daemon mode to
>>>> touch the WSGI script file and cause a single site to be
>>>> reloaded. One
>>>> would normally use this as a way of reloading a single site without
>>>> the need to restart the whole of Apache. When sharing the single
>>>> WSGI
>>>> script file across sites, touching the WSGI script file will
>>>> restart
>>>> all sites using that WSGI script file. If they share the code
>>>> this may
>>>> actually be want you want, so not a problem, but worth mentioning.
>>
>>>> In this arrangement, if you did want to reload one site, for
>>>> example
>>>> because you change its settings file, you would need to use 'ps' to
>>>> identify process(es) in that daemon process group, based on what
>>>> display-name option was set to, and send all those processes in
>>>> that
>>>> daemon process group a SIGINT using the 'kill' command.
>>>> Alternatively,
>>>> you would need to setup a background thread which monitored
>>>> something
>>>> like the distinct settings file for each site and have the process
>>>> itself send a SIGINT to itself. This would be a variation on
>>>> background reloader described in:
>>
>>>> http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Restarting_
>>>> ...
>>
>>>> More later.
>>
>>>> Graham
>>
>>>>> Thanks and Regards,
>>>>> Ben
>>
>>>>> On 9 Dec 2008, at 08:23, Graham Dumpleton wrote:
>>
>>>>>> On Dec 9, 6:53 pm, "ben.dja...@googlemail.com"
>>>>>> <ben.dja...@googlemail.com> wrote:
>>>>>>> Hi, I'm converting to the excellent mod_wsgi and wondering if
>>>>>>> it's
>>>>>>> possible to make a single httpd virtual host/wsgi file to manage
>>>>>>> wildcard subdomains.
>>
>>>>>>> Basically I have an app where i'm creating a new instance for
>>>>>>> each
>>>>>>> client and using subdomains. So client1.example.com and
>>>>>>> client2.example.com both point to the same app, but their own
>>>>>>> settings.py/django instance.
>>
>>>>>>> So far so fine. I've been happily converting to mod_wsgi
>>>>>>> daemons,
>>>>>>> creating virtual hosts and independent .wsgi files for each one.
>>>>>>> But
>>>>>>> now just wondering whether there is some way i can make this
>>>>>>> process
>>>>>>> dynamic so one virtual host/.wsgi file will take care of all
>>>>>>> these
>>>>>>> subdomains.
>>
>>>>>>> I see the advice on the wsgi wiki to push domain sub-
>>>>>>> directories to
>>>>>>> different django instances, but i'd rather keep using the
>>>>>>> subdomains
>>>>>>> if possible.
>>
>>>>>>> It looks possible to be able to parse information about the
>>>>>>> incoming
>>>>>>> request in the wsgi file and push it to different settings.
>>>>>>> But i'm
>>>>>>> not sure what this will do in terms of spawning processes etc,
>>>>>>> it
>>>>>>> looks a little dangerous, or maybe this will work. Any advice
>>>>>>> appreciated thanks!
>>
>>>>>> Start by reading recent discussion:
>>
>>>>>> http://groups.google.com/group/django-users/browse_frm/thread/dfd3521
>>>>>> ...
>>
>>>>>> I'll post more tomorrow if have time, have to do some things
>>>>>> tonight
>>>>>> and then out most of the day tomorrow.
>>
>>>>>> In short though, no support for dynamic transient daemon
>>>>>> processes
>>>>>> yet, ie.,:
>>
>>>>>> http://code.google.com/p/modwsgi/issues/detail?id=22
>>
>>>>>> so, can't get away from using WSGIDaemonProcess for each
>>>>>> instance at
>>>>>> the moment.
>>
>>>>>> One can use dynamic setting of WSGIApplicationGroup via a
>>>>>> variable
>>>>>> set
>>>>>> by mod_rewrite to select daemon process as well as set some name
>>>>>> relevant to settings file. WSGI application wrapper can then be
>>>>>> used
>>>>>> to override DJANGO_SETTINGS_MODULE.
>>
>>>>>> So, information is in that post, you just need to adapt it to
>>>>>> your
>>>>>> situation. That is, use SERVER_NAME rather than REMOTE_USER from
>>>>>> authentication as basis of selecting daemon process group. You
>>>>>> could
>>>>>> though skip the rewrite maps that allowed multiple levels of
>>>>>> indirection and made it further dynamic in nature.
>>
>>>>>> Graham
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
