WCF net.pipe bricht ab, wenn eine Antwort empfangen wird

StackOverflow https://stackoverflow.com/questions/4141192

  •  30-09-2019
  •  | 
  •  

Frage

Dies wurde behoben

Dies ist ein Vertrag, den ich durch einen Serviceabruf nicht erhalten kann:

[DataContract]
public class myInitializationData : ClientInitializationData
{
    [DataMember]
    public Dictionary<string, string> CultureNameLookup { get; set; }
}

Hier ist der Basistyp:

[DataContract]
public class ClientInitializationData
{
    [DataMember]
    public List<IServiceType> ServiceTypes { get; set; }
}

IServiceType ist eine Schnittstelle.Mir ist klar, dass ich keine Schnittstelle über das Kabel senden kann.Es gibt eine EntityFramework-Entität, ServiceType, Umsetzung der IServiceType Schnittstelle: 

public partial class ServiceType : IServiceType
{
    //...
}

Mein Ziel ist es zu senden ServiceType Entitäten über den Draht über die myInitializationData Vertrag.

Ich bin daran gehindert, das zu dekorieren myInitializationData oder ClientInitializationData Klassen mit einem KnownType von ServiceType, da diese Klassen mit Silverlight-Projekten geteilt (verknüpft) werden.Wenn ich also eine dieser Klassen mit einem KnownType von dekoriere ServiceType, können die Silverlight-Seite(n) nicht kompiliert werden.

Anstatt die Klassen direkt zu dekorieren, habe ich den Servicevertrag mit einem ServiceKnownType von dekoriert ServiceType:

[ServiceContract]
[ServiceKnownType(typeof(ServiceType))]
public interface IService
{
    [OperationContract]
    myInitializationData InitializeClient();
}

Sollte das funktionieren?

Beim Anrufen IService.InitializeClient, erhalte ich auf dem Client die folgende Fehlermeldung:

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

Ich habe das Trace-Debugging aktiviert, aber weder für den Client noch für den Server Meldungen bezüglich eines Serialisierungsfehlers im Trace gefunden.

Server-Trace:

  • Empfängt eine Nachricht je einen Kanal (Aktion: http://tempuri.org/IService/InitializeClient)
  • Zu:Ausführen (IService.InitializeClient)
  • Aus:Ausführen (IService.InitializeClient)
  • Sendet eine Nachricht über einen Channel (Aktion: http://tempuri.org/IService/InitializeClientResponse)
  • Warnung Fehlerhaftes System.ServiceModel.Channels.ServerSessionPreambleConnectionReader ServerFramingDuplexSessionChannel
  • Warnung Fehlerhaftes System.ServiceModel.Channels.ServiceChannel
  • Antwort auf eine Operation warf eine Ausnahme (Die ObjectContext-Instanz wurde verworfen und kann nicht mehr für Vorgänge verwendet werden, die eine Verbindung erfordern.)

Client-Trace:

Wenn ich mich dafür entscheide ServiceTypes Eigentum aus dem ClientInitializationData DataContract, dieser Fehler verschwindet.Ich gehe also davon aus, dass es sich hierbei um ein Serialisierungsproblem handeln muss:die Schnittstelle und KnownTypes, aber WCF behauptet nicht, dass es Serialisierungsprobleme in der Ablaufverfolgung gibt, und ich bin mir nicht sicher, was die Ablaufverfolgung in diesem Fall bedeutet.

Lösung

Dies war kein KnownTypes-Problem.Dies war darauf zurückzuführen, dass LazyLoading spontan für den Entitätskontext aktiviert wurde, der die definiert ServiceType Typ.

Obwohl in der Ablaufverfolgung (weder auf der Client- noch auf der Serverseite) nicht erwähnt wird, dass übermäßig viele Nachrichten oder Puffergrößen verletzt wurden, muss ich davon ausgehen, dass die Aktivierung von LazyLoading im EF-Kontext dazu geführt hat, dass der DataContractSerializer den EF-Abruf ausgelöst hat eine Menge von Datensätzen, was wiederum dazu führte, dass ein riesiger Graph auf dem Draht (versucht) wurde.Die Serverseite hat beim Schreiben der Nachricht einfach (und mehrdeutig) einen Kanalfehler verursacht.

Durch das Zurücksetzen von LazyLoading in einen deaktivierten Zustand im EF-Kontext wurde dieses Problem inzwischen gelöst.

War es hilfreich?

Lösung

Dies war kein KnownTypes-Problem.Dies war darauf zurückzuführen, dass LazyLoading spontan für den Entitätskontext aktiviert wurde, der den ServiceType-Typ definiert.

Obwohl in der Ablaufverfolgung (weder auf der Client- noch auf der Serverseite) keine übermäßige Nachrichten- oder Puffergröße erwähnt wird, muss ich davon ausgehen, dass die Aktivierung von LazyLoading im EF-Kontext dazu geführt hat, dass der DataContractSerializer dazu geführt hat, dass EF viele Datensätze abgerufen hat , was wiederum dazu führte, dass ein riesiger Graph auf dem Draht erstellt (versucht) wurde.Die Serverseite hat beim Schreiben der Nachricht einfach (und mehrdeutig) einen Kanalfehler verursacht.

Durch das Zurücksetzen von LazyLoading in einen deaktivierten Zustand im EF-Kontext wurde dieses Problem inzwischen gelöst.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top