問題タブ [mod-wsgi]

2 つの Trac インスタンスを設定して、ブラウザ経由でそれぞれ異なる URL でアクセスできるようにしようとしています。

最初にアクセスしたとき、Apache の応答は問題ありません。最初の Trac は /trac1 で取得され、次に 2 番目の Trac は /trac2 で取得されます。しかし、/trac1 に再度アクセスすると、2 番目の Trac (/trac2) の内容が表示され続けます。最初の .wsgi 構成ファイル (trac1.wsgi とします) に触れてから、ブラウザーで /trac1 を再度要求すると、期待される内容が再び取得されます。

反対の場合も同じように機能します: /trac2 にアクセスし、次に /trac1 にアクセスし、次に /trac2 は、trac2.wsgi に触れるまで /trac1 の内容を提供し続けます...

したがって、Python、mod_wsgi、および/またはApacheが結果または何かをキャッシュしているようです。私はシステム管理者ではないので、この問題についてこれ以上説明することはできません。

Apache の .wsgi ファイルと http.conf:

trac1.wsgi :

trac2.wsgi :

http.conf :

誰かが別の構成などを提案した場合は、それも歓迎します。ありがとう！

ヘクター

概要: RHEL 5.3 64 ビットで Python 3.1 をビルド--enable-sharedすると、すべての拡張機能のコンパイルに失敗します。「通常」のビルドは問題なく正常に動作します。

この質問は、プログラミングとシステム管理の境界をあいまいにしているように見えるかもしれないことに注意してください。ただし、言語サポートを適切に取得することに直接対処する必要があり、プログラミングのプロセスをサポートすることに非常に関係しているため、ここにクロスポストすると思います. また: https://serverfault.com/questions/73196/python-3-1-1-with-enable-shared-will-not-build-any-extensions。ありがとうございました！

問題：

RHEL 5.3 64 ビットで Python 3.1 をビルド--enable-sharedすると、すべての拡張機能のコンパイルに失敗します。「通常」のビルドは問題なく正常に動作します。

Python 3.1 は問題なくビルドできますが、共有ライブラリとしてビルドすると、多くの警告が発生し (以下を参照)、cベース モジュールのビルドを拒否します。この失敗にもかかわらず、それに対して mod_wsgi 3.0c5 をビルドし、apache で実行することはできます。言うまでもなく、Python の機能は大幅に低下しています...

Python 3.2a0 (svn から) は --enable-shared で正常にコンパイルされ、mod_wsgi はそれに対して正常にコンパイルされることに注意してください。しかし、Apacheを起動すると、次のようになります。

Cannot load /etc/httpd/modules/mod_wsgi.so into server: /etc/httpd/modules/mod_wsgi.so: undefined symbol: PyCObject_FromVoidPtr

これが対象とするプロジェクトは長期的なプロジェクトなので、必要に応じてアルファ品質のソフトウェアで問題ありません。問題の詳細を次に示します。

ホスト：

• Dell PowerEdge
• インテル キセノン
• RHEL 5.3 64 ビット
• 特にない"

建てる：

• Python 3.1.1 ソース配布
• 正常に動作します./configure
• うまく動作しません./configure --enable-shared

（export CFLAGS="-fPIC"やられました）

出力する

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -c ./Modules/_weakref.c -o Modules/_weakref.o

building 'bz2' extension gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude -I/home/build/RPMBUILD/BUILD/Python-3.1.1 -c /home/build/RPMBUILD/BUILD/Python-3.1.1/Modules/bz2module.c -o build/temp.linux-x86_64-3.1/home/build/RPMBUILD/BUILD/Python-3.1.1/Modules/bz2module.o gcc -pthread -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-x86_64-3.1/home/build/RPMBUILD/BUILD/Python-3.1.1/Modules/bz2module.o -L/usr/local/lib -L. -lbz2 -lpython3.1 -o build/lib.linux-x86_64-3.1/bz2.so /usr/bin/ld: /usr/local/lib/libpython3.1.a(abstract.o): relocation R_X86_64_32 against 'a local symbol' can not be used when making a shared object; recompile with -fPIC

Debian 5を使用する同じサーバーの下で複数のサイトをホストしたいと思います。たとえば、、、を使用し、IPが次のようになってsite1いるsite2とsite3仮定します。155.55.55.1

これが私のapacheのデフォルトです：

site1そして、これが私のwsgi構成です/opt/django/site1/apache/django.wsgi。

Djangoベースのサイトであるとsite2を追加するにはどうすればよいですか？site3site1

私が開発しているアプリケーションの場合、ユーザーは gzip された HTTP POST リクエスト (コンテンツ エンコーディング: GZIP) をマルチパート フォーム データ (コンテンツ タイプ: マルチパート/フォーム データ) と共に送信します。mod_deflate を入力フィルターとして使用して解凍し、Web リクエストは mod_wsgi を介して Django で処理されます。

一般的に、すべて問題ありません。ただし、特定の要求 (決定論的) では、要求から応答までにほぼ 1 分の遅延があります。調査の結果、django での処理はすぐに行われますが、サーバーからの応答が停止します。リクエストが GZIP されていない場合は、すべて正常に機能します。

mod_wsgi の不具合に対処するために、content-length を圧縮されていないメッセージ サイズに設定したことに注意してください。

誰かがこの問題に遭遇しましたか? 応答を処理するときにApacheを簡単にデバッグする方法はありますか?

SSLとmod_wsgiで構成されたapachevhostが正常に機能しています：

<VirtualHost 127.0.0.1:443>

<場所"/">

</場所>

</ VirtualHost>

ただし、SSLを使用せずにhttp経由で特定のURLへの接続を許可する必要があります。したがって、基本的には、_the_same_ WSGIデーモンを2つの仮想ホストで表示する必要があります。1つはsslあり、もう1つはなしです。メモリ内のいくつかの一般的な変数を使用するため、これを同じデーモンにします。回避策は可能ですが（たとえば、dbに保存するなど）、骨の折れる作業です。

<VirtualHost 127.0.0.1:80>

</ VirtualHost>

これを行うためにwsgi/apacheを設定するにはどうすればよいですか？出来ますか？

リクエストの処理中にユーザーが閉じている接続を検出して処理する方法はWeb.pyにありますか？

アンロードフックハンドラーを設定しようとしましたが、この場合は呼び出されません。リクエストが正常に完了した後にのみ呼び出されます。

ブラウザでアプリを開き、whileループでアプリが回転し始めたら、リクエストを中断しますが、例外はスローされません。

mod_wsgi を介して Apache で Django を実行しています。Django がページをサーバー側にキャッシュしているため、一部の機能が正しく動作しないと思われます。

現在のサーバー時間を取得し、残りのカウントダウン時間を決定し、その数を HTML テンプレートに出力することで機能するカウントダウン タイマーがあります。JavaScript のカウントダウン タイマーが引き継ぎ、ユーザーのカウントダウンを実行します。

この問題は、ユーザーがページを更新したり、カウントダウン タイマーを使用して別のページに移動したりするときに発生します。タイマーは散発的に異なる時間にジャンプするように見え、通常は更新のたびに同じ時間に何度も戻ります。

HTTPFox を使用すると、ブラウザのキャッシュからページが読み込まれないため、Django または Apache がページをキャッシュしているように見えます。この機能を無効にする方法はありますか? スクリプト出力のキャッシュについて心配するほど十分なトラフィックはありません。それとも、なぜこれが起こっているのかについて完全に間違っていますか?

[編集] 以下の投稿から、キャッシングが Django で無効になっているように見えます。

[編集] 何が起こっているかについてのより詳細な説明があります: サーバーに対して行われた最初の 7 (またはそれくらい) の要求では、ページはスクリプトによってレンダリングされて返されますが、これらの 7 ページのそれぞれはそのままキャッシュされているようです。後で現れます。8 番目の要求で、サーバーは最初のページを提供します。9 番目の要求で、2 番目のページを提供するなど、1 サイクルで続きます。これは、プロセスが最初からやり直すときにApacheを再起動するまで続きます。

[編集] 一度に 1 つのプロセスのみを実行するように mod_wsgi を構成しました。これにより、タイマーは常に同じ値にリセットされます。興味深いことに、私のページには別のコンポーネントがあり、order('?') を使用してリクエストごとにランダムな画像を表示し、毎回異なる画像で更新します。これは、キャッシングが Apache ではなく Django で行われていることを示します。

[編集] 以前の編集に照らして、関連する views.py ファイルに戻って確認したところ、カウントダウン開始変数がビュー関数の外のモジュールでグローバルに設定されていることがわかりました。その設定をビュー関数内に移動すると、問題が解決しました。結局、キャッシングの問題ではないことが判明しました。これについてご協力いただきありがとうございます。

私はDjangoサイトを開発しています。ライブサーバーですべての変更を行っています。その方が簡単だからです。問題は、時々、私が取り組んでいる*.pyファイルの1つをキャッシュしたいように見えることです。更新を頻繁に押すと、ページの古いバージョンと新しいバージョンが切り替わります。

私のセットアップは、Djangoチュートリアルで説明されているものとほぼ同じです：http：//docs.djangoproject.com/en/dev/howto/deployment/modwsgi/#howto-deployment-modwsgi

これは、 WSGIハンドラーの複数のインスタンスを起動しているためだと思います。また、httpリクエストが送信されるハンドラーによっては、ページのバージョンが異なる場合があります。apacheを再起動すると問題が解決するようですが、面倒です。

WSGIや「ミドルウェア」などのリクエスト処理についてはよくわかりません。私はPHPのバックグラウンドを持っており、すべてが正常に機能します:)

とにかく、この問題を解決するための良い方法は何ですか？WSGIハンドラーを実行すると「デーモンモード」で問題が軽減されますか？もしそうなら、どうすればデーモンモードで実行できますか？

今日一日中、Mac OS X Snow Leopard の XAMPP を介して Apache で MOD_WSGI を動作させようとしましたが、成功しませんでした。私はすべての指示に従い、インターネットで解決策を検索しましたが、今のところうまくいきません。以下は私の正確な手順と詳細です。localhost を実行すると、白い画面しか表示されません。「LoadModule wsgi_module modules/mod_wsgi.so」を httpd.conf から削除すると、localhost が期待どおりに実行されます。

1. Xcodeをダウンロードしてインストールしました。
2. XAMPP は既にインストールされ、動作しています。
3. OS X には既に 64 ビット モードの Python 2.6 があるため、Python をインストールする必要はありません。
4. mod_wsgi-2.6.tar.gz をデスクトップにダウンロードして解凍します。
5. ターミナル "./configure --with-apxs=/Applications/XAMPP/xamppfiles/bin/apxs --with-python=/System/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6" (いいえエラー)
6. ターミナル "make" (メッセージ "make: `all' に対して何もする必要はありません。")
7. ターミナル「sud​​o make install」(エラーなし)
8. XAMPP の httpd.conf ファイルに追加します。

LoadModule wsgi_module modules/mod_wsgi.so
AddType text/html .py
WSGIScriptAlias /app-sample "/Applications/xampp/xamppfiles/htdocs/app-sample/main.py"

9. XAMPP経由でApacheを再起動します