Due progetti Django in esecuzione simultanea e mod_wsgi acting werid

Question

Sto provando a eseguire due progetti Django contemporaneamente. Mi è capitato di usare mod_wsgi e ho scoperto che il sito si comporta in modo strano. Forse ci sarebbe una soluzione alternativa, ma mi piacerebbe sapere cosa mi manca e come risolvere il problema.

Nella configurazione apache

# Setup the Python environment 
# As root owns basically everything on a Amazon AMI and root 
# cannot be used. Create a folder under /var/run/wsgi 
# with the owner as ec2-user and group ec2-user. 
WSGISocketPrefix /var/run/wsgi 
# Call your daemon process a name 
WSGIDaemonProcess pydaemon processes=1 threads=5 
# Call your daemon process group a name 
WSGIProcessGroup pydaemon 
# Point to where the handler file is. This will be different 
# If you are using some other framework. 
WSGIScriptAlias /test /var/www/html/test/wsgi.py 
WSGIScriptAlias /proto /var/www/html/proto/wsgi.py 

Dopo Apache riavviato, se si collegano a '/ proto', allora il sito proto è mostrato. Comunque, poi mi collego a '/ test', senza riavviare Apache, il sito proto è ancora mostrato, e non riesco ad accedere al sito di test.

Ora riavvio Apache, questa volta vado prima a "/ test". Il sito di test arriva! Tuttavia, se vado a '/ proto' mostra ancora il sito di test, non il sito proto.

Cosa potrebbe accadere? Ho aggiunto SESSION_COOKIE_PATH in modo diverso per ogni applicazione per ogni evenienza, ma il problema esiste ancora.

---

[AGGIORNATO]

Ho anche provato come il seguente, per dare i nomi dei gruppi di applicazioni WSGI diversi, ma senza fortuna.

Alias /cuedit /var/local/test/wsgi.py 
<Location /test> 
SetHandler wsgi-script 
Options +ExecCGI 
WSGIApplicationGroup test 
</Location> 
Alias /proto /var/local/proto/wsgi.py 
<Location /proto> 
SetHandler wsgi-script 
Options +ExecCGI 
WSGIApplicationGroup proto 
</Location> 

---

[AGGIORNATO]

ho cambiato dalla modalità demone per la modalità incorporata. Immagino che il problema fosse che due istanze condividevano lo stesso processo del daemon mod_wsgi in modo che il loro spazio dei nomi si scontrasse.

Ci si aspetterei che dovessero essere gestiti correttamente, ma in modalità demone non riuscivo a farlo bene.

Answer 1

Utilizzare questo come una soluzione alternativa:

WSGIDaemonProcess pydaemon-1 processes=1 threads=5 
WSGIDaemonProcess pydaemon-2 processes=1 threads=5 

WSGIScriptAlias /test /var/www/html/test/wsgi.py 

<Location /test> 
WSGIProcessGroup pydaemon-1 
WSGIApplicationGroup %{GLOBAL} 
</Location> 

WSGIScriptAlias /proto /var/www/html/proto/wsgi.py 

<Location /proto> 
WSGIProcessGroup pydaemon-2 
WSGIApplicationGroup %{GLOBAL} 
</Location> 

Ciò imporrà ogni applicazione in un gruppo di processi demone separato e in nessun modo dovrebbero essere in grado di interferire tra loro.

Se ciò non funziona, si verificano problemi con il file di script WSGI in qualche modo.

Answer 2

Il problema potrebbe essere correlato ad Apache che condivide il subinterprete Python tra le applicazioni WSGI. Provate ad aggiungere questo alla configurazione di Apache per evitare la condivisione:

WSGIApplicationGroup %{GLOBAL} 

Controllare this blog post per la spiegazione approfondita e ulteriori suggerimenti (controllare i commenti troppo).

Answer 3

Ho anche 2 progetti Django però ognuno è in esecuzione su una porta diversa (httpd config), sembra qualcosa di simile:

<VirtualHost *:80> 
    ServerAdmin xx 
    ServerName xx 
    ServerAlias xx 
    ErrorLog /path/to/first/project/logs/error.log 
    CustomLog /path/to/first/project/logs/access.log combined 

    Alias /static/ /path/to/first/project/sitestatic 

    WSGIDaemonProcess app processes=1 threads=15 display-name=%{GROUP} 
    WSGIProcessGroup app 

    WSGIScriptAlias//path/to/first/project/django.wsgi 

    <Directory /path/to/first/project/apache> 
     Order deny,allow 
     Allow from all 
    </Directory> 
</VirtualHost> 

<VirtualHost *:8080> 
    ServerAdmin xx 
    ServerName xx 
    ServerAlias xx 
    ErrorLog /path/to/second/project/logs/error.log 
    CustomLog /path/to/second/project/logs/access.log combined 

    WSGIDaemonProcess app1 processes=1 threads=15 display-name=%{GROUP} 
    WSGIProcessGroup app1 

    WSGIScriptAlias//path/to/second/project/apache/django.wsgi 

    <Directory /path/to/second/project/apache> 
     Order deny,allow 
     Allow from all 
    </Directory> 
</VirtualHost> 

Answer 4

Non posso commentare la risposta data da Graham, quindi aggiungendo uno dei miei.

Il problema per me era davvero l'Interprete Python, ma dovevo anche aggiungere il percorso python per ogni interprete.Segue una configurazione di esempio:

WSGIDaemonProcess py_app1 processes=1 threads=5 python-path=/path/to/app1 
WSGIScriptAlias /app1 /path/to/app1/wsgi.py 
<Directory /path/to/app1> 
    <Files wsgi.py> 
     Order deny,allow 
     Allow from all 
    </Files> 
</Directory> 
<Location /app1> 
    WSGIProcessGroup py_app1 
    WSGIApplicationGroup %{GLOBAL} 
</Location> 

WSGIDaemonProcess py_app2 processes=1 threads=5 python-path=/path/to/app2 
WSGIScriptAlias /app2 /path/to/app2/wsgi.py 
<Directory /path/to/app2> 
    <Files wsgi.py> 
     Order deny,allow 
     Allow from all 
    </Files> 
</Directory> 
<Location /app2> 
    WSGIProcessGroup py_app2 
    WSGIApplicationGroup %{GLOBAL} 
</Location>