0

Web サービスは、USR1 シグナルを受信したときにそのデータの一部を公開するように構成されています。信号は、xinetd サーバーがリモート クライアント (nc myserver 50666 など) から要求を受信すると送信されます。Web サーバーが USR1 信号を受信すると、専用の fifo パイプを開き、そのデータをパイプに書き込み、パイプを閉じます。パイプ。その間、xinetd サーバーはパイプを読み取り、リモート クライアントにフィードします。

ほとんどの場合、それらは問題なく機能しますが、何らかの理由でクライアントが複製レコードを受け取ることがあります。ログから、パイプが適切に閉じられず、キャッシュが残っているように見えます。そのため、次にサービスを提供するときに、以前と現在の両方がクライアントに送信されます。問題は、再現しようとすると常に発生するわけではないことです。残念ながら、一度再現できませんでした。

以下は、プロセスを示す簡単なスニペットです。

ウェブサーバー: (webserver.py)

def SendStream(data, pipe):
  try:
    for i in data:
      pipe.write(i + '\n') 
      pipe.flush()
  finally:
      pipe.close()

def Serve():
  threading.Thread(target=SendStream, args=(data, pipe)).start()

xinetd.d サーバー: (spitter.py)

def Serve():
  if not os.path.exists(PIPE_FILE):
    os.mkfifo(PIPE_FILE)
  os.kill(server_pid, signal.SIGUSR1)
  for i in open(PIPE_FILE):
    print i,

では、重複の原因となったのは正確には何だったのでしょうか。それを引き起こす方法は？現在の修正では、パイプファイルのリンクを解除し、残り物を避けるために毎回再作成していますが、それが適切な解決策であるかどうかはわかりません.

4

3 に答える 3

0

splitter.py の 2 つのコピーを同時に実行すると、問題が発生しますが、発生するほとんどのことは合法です。プロセス ID の値を webserver.py に追加してみてください。

pipe.write(str(os.getpid()) + i + '\n')

それは明るいかもしれません。

于 2009-03-20T19:40:18.253 に答える
0

したがって、実際の問題は、複数のクライアントが存在することです。サーバーは、最初は顧客と合意していなかった他の未知のクライアントからクエリ/悪用されており、現在の設計では確実に壊れます。この問題に対処するための修正プログラムがデプロイされました。だから、アンディの疑いは正しい。みんなありがとう！

于 2009-05-13T20:23:02.177 に答える