4

次のシナリオがあります。

複数のバイナリを含むページを公開します。このページは、HTTP レシーバーによって受信され、ローカル サービス ユーザーとして実行される専用アプリケーション プール内の IIS ですべてホストされているインプロセス デプロイヤーを使用してデプロイされます。

ページはブローカー データベースに保存され、バイナリは "D:\Binaries\Preview" のようなパスを使用してローカル ファイル システムに公開されます。

プレビュー フォルダーは、Web アプリケーションを使用してバイナリを表示できるように、\machinename\PreviewBinaries などで読み取り専用共有としてドメイン ユーザーに共有されます。

10 回中 9 回はすべて正常に動作しますが、公開に失敗することがあります。これは、別のプロセスによってロックされているためにバイナリが上書きできないためと思われます。ProcessMon やその他のツールを使用して、これらのファイルをロックしている可能性があるものを特定しようとしました (役に立たなかった)。手動で画像を削除すると、公開が再び機能する場合があります。サーバーで IIS を再起動すると、いつでもファイルを削除して公開できます。

これらのイメージをロックしている可能性のあるプロセスについて何か提案はありますか? 誰もこの問題を見たことがありますか? 共有に公開する際に問題が発生する可能性はありますか? または、SiteEdit 2009 がこれらのファイルをロックしている可能性があります。これは、プレビュー サーバーでのみ発生し、ライブ (SiteEdit なし) で問題ないように思われるからです。

前もって感謝します

4

5 に答える 5

3

問題のあるコードは、使用しているプレゼンテーション フレームワークにあったようです。フレームワークはResponse.TransmitFile(binaryPath)を使用してバイナリをクライアントに非同期的に送信しました。これにより、バイナリに一時的なロックハンドルが設定されているようです(読み取り専用共有にある場合でも)。

このコード行を削除し、別の方法でアプリケーションをサーバー バイナリに変更しました (IIS がファイルを直接送信できるようにパスを書き直しました)。これで問題が解決し、サイトのパフォーマンスが向上したようです。

すべての提案に感謝します。問題の原因ではないすべてのものを排除するのに役立ち、根本的な原因を見つけることができました.

于 2012-05-15T16:35:37.350 に答える
3

Windows 2008 を使用している場合は、ディスクからファイルを削除してみてください。その後、どのプロセスがファイルをロックしたかがわかります。しかし、IIS を再起動するとファイルのロックが解除されることを考えると、IIS がファイルをロックしている可能性が高いと思われます。

SiteEdit 2009 がこれらのファイルをロックする仕組みがわかりません。プレビュー サーバーを別のボックスに置くことができる場合、SiteEdit は HTTP を介してそのサーバーと通信するだけです。プレビュー サーバー上のファイルに直接アクセスすることはなく、CD API を介してもアクセスしません。訪問者と同じように、Web サーバーへの通常のリクエストです。

于 2012-05-14T16:40:26.813 に答える
2

ウイルス対策サービスまたはインデックス サービスが実行されていますか。これらは、必要のない瞬間に非常に短期間のロックを取得する傾向があります。特にウイルス対策では、これは通常、1 つのプロセスがそのロックを解放し、他のプロセスがロックを取得しようとする直前です。これが問題である場合は、いくつかの除外ディレクトリを設定すると役立つはずです。

于 2012-05-14T16:52:29.590 に答える
1

Process Monitor を使用されているようですが、Sysinternals Process Explorer は試しましたか? 「検索 -> ハンドルまたは Dll を検索」は、このような場合に非常に便利です。または、コマンド ライン ツールを使用する場合は、Sysinternals も handle.exe を作成します。これにより、すべてがダンプされます。

于 2012-05-14T16:48:29.387 に答える