2011-01-14 10 views
0

Ich habe erfolgreich einige Arbeitsabläufe mit Server AppFabric gehen.Workflow 4 unter AppFabric Fehler in AppDashboard bei der Verwendung von Rohrleitungen

Was ich jedoch bemerkt habe ist, dass, wenn ich versuche, namePipeBinding für die Kommunikation mit dem Workflow zu verwenden, der Aufruf erfolgreich für den Client funktioniert (der Aufruf ist in der Schnittstellendefinition für den Dienst als IsOneWay = true markiert) AppFabric Armaturenbrett i die Nachricht erfolgreich verarbeitet zu sehen ist, und dann bekommen wir den Ruf als ‚Service-Exception‘ erscheint mit der folgenden Ausnahme

System.ServiceModel.CommunicationException: There was an error reading from the pipe: The pipe has been ended. (109, 0x6d). ---> System.IO.IOException: The write operation failed, see inner exception. ---> System.ServiceModel.CommunicationException: There was an error reading from the pipe: The pipe has been ended. (109, 0x6d). ---> System.IO.PipeException: There was an error reading from the pipe: The pipe has been ended. (109, 0x6d). 
at System.ServiceModel.Channels.PipeConnection.OnAsyncReadComplete(Boolean haveResult, Int32 error, Int32 numBytes) 
--- End of inner exception stack trace --- 
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result) 
at System.ServiceModel.Channels.ConnectionStream.ReadAsyncResult.End(IAsyncResult result) 
at System.Net.FixedSizeReader.ReadCallback(IAsyncResult transportResult) 
--- End of inner exception stack trace --- 
at System.Net.Security.NegotiateStream.EndRead(IAsyncResult asyncResult) 
at System.ServiceModel.Channels.StreamConnection.EndRead() 
--- End of inner exception stack trace --- 
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result) 
at System.ServiceModel.Channels.FramingDuplexSessionChannel.TryReceiveAsyncResult.End(IAsyncResult result, Message& message) 
at System.ServiceModel.Dispatcher.DuplexChannelBinder.EndTryReceive(IAsyncResult result, RequestContext& requestContext) 
at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.EndTryReceive(IAsyncResult result, RequestContext& requestContext) 

der Workflow von zwei Aktivitäten erhalten besteht, aber es hat keine receiveandsendreply activitiies .

Alles funktioniert gut, wenn ich HTTP-Bindungen verwenden.

Warum wird dieser Fehler im Dashboard gemeldet?

Konfigurationsdetails für die Client-Anwendung sind unter

<system.serviceModel> 
    <bindings> 
     <basicHttpBinding> 
      <binding name="BasicHttpBinding_ISLG" closeTimeout="00:01:00" 
       openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" 
       allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" 
       maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" 
       messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" 
       useDefaultWebProxy="true"> 
       <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" 
        maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 
       <security mode="None"> 
        <transport clientCredentialType="None" proxyCredentialType="None" 
         realm="" /> 
        <message clientCredentialType="UserName" algorithmSuite="Default" /> 
       </security> 
      </binding> 
     </basicHttpBinding> 
     <netNamedPipeBinding> 
      <binding name="NetNamedPipeBinding_ISLG" closeTimeout="00:01:00" 
       openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" 
       transactionFlow="false" transferMode="Buffered" transactionProtocol="OleTransactions" 
       hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288" 
       maxBufferSize="65536" maxConnections="10" maxReceivedMessageSize="65536"> 
       <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" 
        maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 

       <security mode="Transport"> 
        <transport protectionLevel="EncryptAndSign"/> 
       </security> 
      </binding> 
     </netNamedPipeBinding> 
    </bindings> 
    <client> 
     <endpoint address="net.pipe://vm-vsnet2010/TestWorkflowDeclarativeServiceLibrary/Service3.xamlx" 
      binding="netNamedPipeBinding" bindingConfiguration="NetNamedPipeBinding_ISLG" 
      contract="SLGService.ISLG" name="NetNamedPipeBinding_ISLG"> 
      <identity> 
       <servicePrincipalName value="host/VM-VSNET2010" /> 
      </identity> 
     </endpoint> 
    </client> 
</system.serviceModel> 

Antwort

0

können Sie den Server Bindungskonfiguration einreichen gezeigt? Sie können sich unterscheiden und deshalb kann der Server keine Daten von der Pipe empfangen.

Mit freundlichen Grüßen

+0

Es gibt/sind keine Details in der Konfigurationsdatei Serverseite. Um es noch einmal zu wiederholen, der Server verarbeitet die Anfragen erfolgreich, nur dass viele Einträge im appfabric-Dashboard bezüglich des Erfolgs der Workflow-Operationen erscheinen (siehe oben). – jamie

+0

Ok, jetzt verstehe ich besser und es ist seltsamer :) Irgendwie scheint es, einen Duplex-Kanal zu erstellen, also aus irgendeinem Grund wird es in einem Zwei-Wege-Modus aufgerufen. Verwenden Sie eine Korrelation? Vielleicht hilft das: http://social.msdn.microsoft.com/Forums/en/wfprerelease/thread/47a94846-2191-454a-9ea8-1f8783e20b27 – Tasio