2010-05-28 6 views
1

J'ai un service WCF consommé par un contrôle silverlight 3. Le client Silverlight utilise un basicHttpBindinging qui est construit à l'exécution à partir des paramètres d'initialisation de la commande comme ceci:silverlight 3: course longue appel WCF déclenche 401,1 (accès refusé)

public static T GetServiceClient<T>(string serviceURL) 
{ 
    BasicHttpBinding binding = new BasicHttpBinding(Application.Current.Host.Source.Scheme.Equals("https", StringComparison.InvariantCultureIgnoreCase) 
      ? BasicHttpSecurityMode.Transport : BasicHttpSecurityMode.None); 
    binding.MaxReceivedMessageSize = int.MaxValue; 
    binding.MaxBufferSize = int.MaxValue; 

    binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly; 

    return (T)Activator.CreateInstance(typeof(T), new object[] { binding, new EndpointAddress(serviceURL)}); 
} 

Le service implémente la sécurité des fenêtres. Les appels revenaient comme prévu jusqu'à ce que le jeu de résultats atteigne plusieurs milliers de lignes, date à laquelle les erreurs HTTP 401.1 ont été reçues.

HttpBinding de service définit la CloseTime, OpenTimeout, ReceiveTimeout et SendTimeOut de 10 minutes.

Si je limite la taille du resultset Les appels proprement déroulée.

Observations supplémentaires de Fiddler: Lorsque Method2 est modifié pour revenir un plus petit ResultSet (et éviter le problème), l'initialisation de commande se compose de 4 appels:

  1. Service1/MÉTHODE1 - résultat: 401
  2. Service1/Method1 - résultat: 401 (cet en-tête de temps comprend l'élément "autorisation: Négocier TlRMTV ..."
  3. Service1/Method1 - résultat: 200
  4. Service1/Method2 - résultat: 200 (1,25 seconde)

Lorsque Method2 est configuré pour renvoyer le plus resultset nous obtenons:

  1. Service1/Method1 - Résultat: 401
  2. Service1/Method1 - Résultat: 401 (cet en-tête de temps comprend l'élément « Autorisation : Negotiate TlRMTV ... »
  3. Service1/Method1 - résultat: 200
  4. Service1/Method2 - résultat: 401,1 (7,5 secondes)
  5. Service1/Method2 - résultat: 401,1 (15ms)
  6. Service1/Method2 - Résultat: 401,1 (7,5 secondes)
+1

frappent vous 401 lors de demandes simultanées? c'est-à-dire que vous effectuez un second appel alors qu'un appel précédent est en cours de traitement? Si tel est le cas, cela peut indiquer une configuration de concurrence Wcf incorrecte. –

+0

Je ne crois pas qu'il y ait des demandes concurrentes. Je l'ai ajouté à poster avec quelques observations de Fiddler –

+0

j'ai découvert que si je plafonner le recordset à 1560 éléments, les retours d'appels de service correctement. Si je plafonne le jeu d'enregistrements à 1561, l'appel de service échoue. C'est cohérent. En outre, je fais une trace de service mais les résultats sont presque illisibles ..... recherchera une meilleure sortie de trace. –

Répondre

1

La question était la configuration du comportement de service. Cela a fait l'affaire:

<behavior name="SRMS.Services.GraphicPointServiceBehavior"> 
    <serviceMetadata httpGetEnabled="true"/> 
<serviceDebug includeExceptionDetailInFaults="true"/> 
<dataContractSerializer maxItemsInObjectGraph="2147483647"/> 

Voir le message par Daniel Bergsten ici: more information

+0

BTW, la sortie XML de la trace du serveur était malformé, il était beaucoup plus facile à lire lors de la création avec System.Diagnostics.TextWriterTraceListener –