2013-04-05 90 views
13

「ステータスツール」を添付してWindowsサービスを作成しています。このサービスは、プロセス間通信用のWCF名前付きパイプエンドポイントをホストします。名前付きパイプを介して、ステータスツールは定期的にサービスに最新の「ステータス」を問い合わせることができます。私の開発マシン上でWCF NamedPipe CommunicationException - "パイプが終了しました。(109、0x6d)。"

enter image description here

、私は複数のIPアドレスを持っています。そのうちの1つは192.168.1.XXアドレスの「ローカル」ネットワークです。もう1つは10.0.X.XXアドレスを持つ "コーポレート"ネットワークです。 Windowsサービスは、単一のIPアドレスでUDPマルチキャストトラフィックを収集します。

"192.168.1.XX"アドレスを使用している限り、これまでWindowsサービスは正常に動作していました。ステータスをクライアントに常に一貫して報告します。状態を取得する際

はできるだけ早く私は他の、「企業の」IPアドレス(10.0.X.XX)に切り替え、サービスを再起動すると、私は連続「CommunicationExceptions」を取得:今

"There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)." 

、私は、UDPクライアントの「主張された」IPアドレスがNamed-Pipeインターフェースの機能と何らかの関係があるとは思わないでしょう。彼らはアプリケーションの完全に別の部分です!ここで

は、関連するWCFの設定セクションです:

//On the Client app: 
string myNamedPipe = "net.pipe://127.0.0.1/MyNamedPipe"; 
ChannelFactory<IMyService> proxyFactory = 
    new ChannelFactory<IMyService>(
     new NetNamedPipeBinding(), 
     new EndpointAddress(myNamedPipe)); 


//On the Windows Service: 
string myNamedPipe = "net.pipe://127.0.0.1/MyNamedPipe"; 
myService = new MyService(myCustomArgs); 
serviceContractHost = new ServiceHost(myService); 
serviceContractHost.AddServiceEndpoint(
    typeof(IMyService), 
    new NetNamedPipeBinding(), 
    myNamedPipe); 

serviceContractHost.Open(); 

私は、これは「アクセス権」の問題だと思いません - 私は管理者権限でクライアントを実行している - おそらくいくつかのドメイン固有の理由がありますこれが壊れた?

+0

例外スタックトレースはどのように見えますか?あなたは確かですか?他に何も変わっていませんか?サービス設定を切り替えた後にステータスツールを再起動しましたか?ステータスツールコードの一部を投稿して、あなたのRPCをインスタンス化し、WCFコールを発信できますか? –

+0

私は仕事に戻る月曜日に質問を更新します。友人はまた、IPアドレスが赤ん坊であるかもしれないことを示唆し、実際の違いは特定の列挙型の戻り値かもしれません。私もそれを調べます。 – BTownTKD

答えて

9

IPアドレスは完全に赤いニシンだった。

例外の本当の理由は、WCFサービスによって返される無効な列挙型の値でした。

私の列挙はthusly定義されました:

[DataContract] 
public enum MyEnumValues : Byte 
{ 
    [EnumMember] 
    Enum1 = 0x10, 
    [EnumMember] 
    Enum2 = 0x20, 
    [EnumMember] 
    Enum3 = 0x30, 
    [EnumMember] 
    Enum4 = 0x40, 
} 

それは表面に微細に見えます。

しかし、基礎となるサービスによって報告された未加工状態は、バイト値 "0"であり、それをキャストするための対応する列挙値がありませんでした。

Enum値がすべて有効であることが確認されると、ツールはクリスマスツリーのように点灯します。

ご不明な点がある場合は、WCFデータが無効であると想定してください。

+0

これを指し示しているトレースファイルには何かありましたか、または一般的な "パイプが終了しました"というエラーがあり、潜在的なシリアル化の問題を見つけるためにすべてのコードをスキャンする必要がありますか? –

+3

私はすべてのデータをスキャンして手動で確認しなければなりませんでした。私はあなたが有益なトレースでより良い運を願っています! – BTownTKD

+0

"疑わしいときは、あなたのWCFデータが無効であると仮定してください。" - 私の一日を保存:) – Yaniv

1

サービス操作がスローされ、実際にチャネルに障害が発生したときにこのエラーが発生しました。あなたのケースでは、あなたはすでにサービスオペレーションが正しく完了していることを確認しており、返品だけが投げられましたが、疑問がある場合は、サービスオペレーションが正常に実行されていることを確認してください。

2

は同じ問題There was an error reading from the pipe: Unrecognized error 109 (0x6d).

  • 一つの理由は、一貫性のない結合
  • (無通信)クライアントとサーバの間で <netNamedPipeBinding> <security mode="None"></security>...他の断続的な問題がタイムアウト関連した だった持っていました。

両方に同じトップエラーメッセージがありました。

タイムアウトをサーバーとクライアントバインドでにすると、問題が再表示されなくなりました。そのうち

バインディング時間があまりにも低く設定されました:

sendTimeout="00:00:05" receiveTimeout="00:00:05" 

スタックトレース: at System.ServiceModel.Channels.StreamConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout) at System.ServiceModel.Channels.SessionConnectionReader.Receive(TimeSpan timeout) at System.ServiceModel.Channels.SynchronizedMessageSource.Receive(TimeSpan timeout) at System.ServiceModel.Channels.TransportDuplexSessionChannel.Receive(TimeSpan timeout) at System.ServiceModel.Channels.TransportDuplexSessionChannel.TryReceive(TimeSpan timeout, Message& message) at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

1

ペイロードがあまりにも大きかった戻ったとき、これは私のWCFサービスで起こりました。

<dataContractSerializer maxItemsInObjectGraph="[some big number]" /> 
2

このエラーは、オブジェクトの多形性の特徴によって引き起こされることがありますが、このエラーはapp.configのserviceBehaviorに追加して修正しました。例えば、以下のサービスの方法は、人物のリストを返します。

[OperationContract] 
List<Person> GetEmployee(); 

我々はスーパーバイザーPersonクラスから継承したクラス、および上記の方法は、Supervisorオブジェクトを返すようにしようとしている場合は、WCFのシリアライザクラスはそう、応答を解釈することはできませんこのエラーは発生します
「既知のタイプ」または「サービス既知のタイプ」を使用することです。暗黙のオブジェクトがメソッドやサービスを使ってやり取りすることを指定する必要があります。 私の例では、次のコードのようにメソッドまたはサービスの宣言にServiceKnownType属性を置くことができます。

[OperationContract] 
[ServiceKnownType(typeof(Supervisor))] 
List<Person> GetEmployee(); 
2

この例外は、サーバ側のシリアル化の問題があることを意味します。

この問題は、トレースファイル(svclog)を調べることで解決できます。トレースを有効にするには、次の設定を使用します。

私の場合、列挙型ではない値をシリアル化していました。

1

私はそれに{}セットがない多くのプロパティを持っていました。これを追加して私の問題を解決しました。

0

同じ問題が発生しましたが、Wojciechさんのanswerのおかげで解決しました。

私は私ので、私はこの問題を持っていた...ので、ここで<security>タグを配置することsystem.serviceModelセクションの開始は今どのように見えるかをここで見つけるために掘りもう少しやって

<system.serviceModel> 
    <bindings> 
    <netNamedPipeBinding> 
     <binding> 
     <security mode="None"></security> 
     </binding> 
    </netNamedPipeBinding> 
    </bindings> 
    .... 
0

を持っていましたolder tutorialを使用し、プログラムで構成しようとしました。

欠けていた部分は、メタデータエンドポイント(thank you, this post!)を提供することでした。

ServiceMetadataBehavior serviceMetadataBehavior = 
    host.Description.Behaviors.Find<ServiceMetadataBehavior>(); 

if (serviceMetadataBehavior == null) 
{ 
    serviceMetadataBehavior = new ServiceMetadataBehavior(); 
    host.Description.Behaviors.Add(serviceMetadataBehavior); 
} 

host.AddServiceEndpoint(
    typeof(IMetadataExchange), 
    MetadataExchangeBindings.CreateMexNamedPipeBinding(), 
    "net.pipe://localhost/PipeReverse/mex" 
); 
関連する問題