.NET远程服务似乎崩溃,并停止响应客户端

Ben*_*est 10 .net c# event-log .net-remoting

我有一个.NET Remoting服务,大部分时间都可以正常工作.如果发生异常或错误,它会将错误记录到文件中,但仍会继续运行.

但是,大约每两周一次服务停止响应客户端,这会导致客户端应用程序因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
Run Code Online (Sandbox Code Playgroud)

没有异常或堆栈跟踪写入我们的日志文件,所以我无法弄清楚服务崩溃的位置,这使我相信它在我的代码之外的某个地方失败了.我可以采取哪些额外步骤来找出这次崩溃的根本原因?我会想象它会在某个地方向EventLog写一些东西,但我对Windows的事件记录系统并不是很熟悉,所以我不确定在哪里看.

在此先感谢任何帮助.

编辑:忘记提及,停止或重新启动服务什么都不做,服务永远不会响应.在我再次启动服务之前,我需要手动终止进程.

编辑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();
         }
      }
Run Code Online (Sandbox Code Playgroud)

Han*_*ant 5

这就像试图找出为什么打电话给朋友时没人接电话的原因。问题是他的房子被烧毁了。对发生的问题的观点不完善是核心问题,对于服务而言尤其糟糕,因为需要关注的内容很少。

除非您使用该电话与服务程序员交谈并让他参与该问题,否则这种情况不会变得更好。 有人将不得不对此进行调试。是的,这将很困难,每两周一次失败可能不够重要。或等待时间太长而无法等待它发生。您可以做的唯一实际的事情是创建流程的小型转储,并将其传递给服务程序员,以便他能有所作为。如果该服务在另一台计算机上运行,​​则也请局域网管理员参与。


Ben*_*est 1

这个问题是由于我的代码中引起的死锁,如果内存可用,我有两个锁定对象,并且我从另一个对象内部锁定了一个对象,本质上使它们互相等待。我能够通过将调试器连接到远程服务来确定这一点。