2012-12-13 6 views
10

ほとんどの場合、ほとんどの場合正しく動作する.NET Remotingサービスがあります。例外またはエラーが発生した場合、エラーはファイルに記録されますが、引き続き実行されます。.NETリモーティングサービスが一見クラッシュし、クライアントへの応答が停止する

しかし、およそ隔週サービスはクライアントappicationは、次のメッセージでのSocketExceptionでクラッシュする原因となる、クライアントへの応答を停止:

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 

も例外またはスタックトレースが私たちのログに書き込まれませんファイルでは、サービスがクラッシュしている場所を特定することができません。これは、コードのどこかで失敗していると信じています。このクラッシュの根本原因を突き止めるために、私はどのような追加ステップを取ることができますか?私はEventLogにどこかで何かを書いていると思いますが、私はWindowsのイベントログシステムに精通していませんので、どこを見ているか正確にはわかりません。

ご協力いただきありがとうございます。

編集:サービスを停止、または再起動すると何も起こりません。サービスは応答しません。サービスを再度開始するには、手動でプロセスを終了する必要があります。

EDIT 2:

public class ClientInfoServerSinkProvider : 
     IServerChannelSinkProvider 
    { 
     private IServerChannelSinkProvider _nextProvider = null; 

     public ClientInfoServerSinkProvider() 
     { 
     } 

     public ClientInfoServerSinkProvider(
       IDictionary properties, 
       ICollection providerData) 
     { 
     } 

     public IServerChannelSinkProvider Next 
     { 
     get { return _nextProvider; } 
     set { _nextProvider = value; } 
     } 

     public IServerChannelSink CreateSink(IChannelReceiver channel) 
     { 
     IServerChannelSink nextSink = null; 

     if (_nextProvider != null) 
     { 
      nextSink = _nextProvider.CreateSink(channel); 
     } 
     return new ClientIPServerSink(nextSink); 
     } 

     public void GetChannelData(IChannelDataStore channelData) 
     { 
     } 
    } 

    public class ClientIPServerSink : 
     BaseChannelObjectWithProperties, 
     IServerChannelSink, 
     IChannelSinkBase 
    { 

     private IServerChannelSink _nextSink; 

     public ClientIPServerSink(IServerChannelSink next) 
     { 
     _nextSink = next; 
     } 

     public IServerChannelSink NextChannelSink 
     { 
     get { return _nextSink; } 
     set { _nextSink = value; } 
     } 

     public void AsyncProcessResponse(
       IServerResponseChannelSinkStack sinkStack, 
       Object state, 
       IMessage message, 
       ITransportHeaders headers, 
       Stream stream) 
     { 
     IPAddress ip = headers[CommonTransportKeys.IPAddress] as IPAddress; 
     CallContext.SetData("ClientIPAddress", ip); 
     sinkStack.AsyncProcessResponse(message, headers, stream); 
     } 

     public Stream GetResponseStream(
       IServerResponseChannelSinkStack sinkStack, 
       Object state, 
       IMessage message, 
       ITransportHeaders headers) 
     { 
     return null; 
     } 

     public ServerProcessing ProcessMessage(
       IServerChannelSinkStack sinkStack, 
       IMessage requestMsg, 
       ITransportHeaders requestHeaders, 
       Stream requestStream, 
       out IMessage responseMsg, 
       out ITransportHeaders responseHeaders, 
       out Stream responseStream) 
     { 
     if (_nextSink != null) 
     { 
      IPAddress ip = 
        requestHeaders[CommonTransportKeys.IPAddress] as IPAddress; 

      CallContext.SetData("ClientIPAddress", ip); 
      ServerProcessing spres = _nextSink.ProcessMessage(
        sinkStack, 
        requestMsg, 
        requestHeaders, 
        requestStream, 
        out responseMsg, 
        out responseHeaders, 
        out responseStream); 
      return spres; 
     } 
     else 
     { 
      responseMsg = null; 
      responseHeaders = null; 
      responseStream = null; 
      return new ServerProcessing(); 
     } 
     } 
+0

おそらく、ロギングを行っている場所でコードをチェックする必要があります。エラーがある場合は、接続を終了または再試行してください。 – MethodMan

+0

クライアント側で例外をキャッチする必要があることはわかっていますが、リモートサービスがクラッシュする原因を突き止めようとしています。 –

+0

作成中のオブジェクトを解放していることを確認するためにコードレビューを行いましたか?それは通常、サービスアプリケーションをコーディングするときに多くの開発者にとって問題に思えます。コードのスニペットを貼り付けることはできますか?多分目の第二のペアは助けになるでしょう – MethodMan

答えて

1

問題は私のコードでデッドロックが発生したためです。メモリが2つのロックオブジェクトを持っていて、もう一方がロックされていて、お互いを待っていました。デバッガをリモートサービスに接続することで、これを判断できました。

4

これは、あなたが友人を呼び出したときに誰もが携帯電話を拾っていない理由を見つけるしようとしているようなものです。そして問題は、彼の家が地面に燃えてしまったことです。何が起こっているのか不完全な見方は、特に目立たないサービスのために特に重大な問題です。

これは、電話を使用してサービスプログラマーと話し、問題に関わるようになるまでは、それ以上にはうまくいかないでしょう。 誰かがこれをデバッグする必要があります。そして、はい、それは難しいでしょう、2週間に一度十分に重要であると考えられないかもしれません。または、それが起こるのを待って周りに座るには余りにも長い。あなたが手助けをすることができる唯一の実践的なことは、プロセスのミニダンプを作成し、それをサービスプログラマーに渡すことです。サービスが別のマシンで実行されている場合は、LAN管理者も参加してください。

+0

私はミニダンプを持っています。私はそれで何をしますか?どのようにしてリモーティングが聞き止めることにしたのかを知ることができますか? – Mark

+0

@mark https://blogs.msdn.microsoft.com/kaevans/2011/04/11/intro-to-windbg-for-net-developers/ windbgを使用してミニダンプを分析するのに役立ちますが、これが予測可能に起こった場合(clr)デバッガをサービスのインスタンスに接続するか、またはサービスに適切なログを追加する方がよいでしょう。 – Yaur

関連する問題