Im fonctionnement silverlight version client 4.0.50917.0 et SDK version 4.0.50826.1Silverlight PollingDuplex InnerChannel avec multipleMessagesPerPoll en défaut (serverPollTimeout)
J'ai créé un client simple silverlight contre un WCF pollingduplex contraignant:
Web. config:
<system.serviceModel>
<extensions>
<bindingExtensions>
<add name="pollingDuplexHttpBinding"
type="System.ServiceModel.Configuration.PollingDuplexHttpBindingCollectionElement,System.ServiceModel.PollingDuplex, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</bindingExtensions>
</extensions>
<behaviors>
<serviceBehaviors>
<behavior name="sv">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceThrottling maxConcurrentSessions="2147483647"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<!-- Create the polling duplex binding. -->
<pollingDuplexHttpBinding>
<binding name="multipleMessagesPerPollPollingDuplexHttpBinding"
duplexMode="MultipleMessagesPerPoll"
maxOutputDelay="00:00:01"/>
<binding name="singleMessagePerPollPollingDuplexHttpBinding"
maxOutputDelay="00:00:01"/>
</pollingDuplexHttpBinding>
</bindings>
<services>
<service behaviorConfiguration="sv" name="Backend.GUIPollingService">
<endpoint address="" binding="pollingDuplexHttpBinding" bindingConfiguration="singleMessagePerPollPollingDuplexHttpBinding"
contract="Backend.IGUIPollingService" />
<endpoint address="mmpp" binding="pollingDuplexHttpBinding" bindingConfiguration="multipleMessagesPerPollPollingDuplexHttpBinding"
name="multimessage" contract="Backend.IGUIPollingService" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
Mon client silverlight se connecter comme ceci:
string endPointAddress2 = "http://"
+ App.Current.Host.Source.DnsSafeHost
+ ":"
+ App.Current.Host.Source.Port.ToString(CultureInfo.InvariantCulture)
+ "/GUIPollingService.svc/mmpp";
this.client = new GUIClientProxy.GUIPollingServiceClient(
new PollingDuplexHttpBinding(PollingDuplexMode.MultipleMessagesPerPoll),
new EndpointAddress(endPointAddress2))
j'ai reçu un eventhandler pour innerchannel faillé:
client.InnerChannel.Faulted += new EventHandler(InnerChannel_Faulted);
...
void InnerChannel_Faulted(object sender, EventArgs e)
{
Dispatcher.BeginInvoke(() =>
{ status.Text += "Inner channel Faulted\n\n"
}
}
Lorsque vous utilisez ce qui précède l'événement Client.InnerChannelFaulted se produit exactement après unserverPollTimeout
. (15 secondes par défaut, vérifiées avec Fiddler)
Si je passe mon client de se connecter comme ceci:
string endPointAddress2 = "http://"
+ App.Current.Host.Source.DnsSafeHost
+ ":"
+ App.Current.Host.Source.Port.ToString(CultureInfo.InvariantCulture)
+ "/GUIPollingService.svc";
this.client = new GUIClientProxy.GUIPollingServiceClient(
new PollingDuplexHttpBinding(),
new EndpointAddress(endPointAddress2))
aka seul message par Fiddler sondage révèle que, après chaque serverPollTimeout
un nouveau sondage est lancé et le canal est pas en défaut.
Toutes les idées Qu'est-ce qui ne va pas ici?
EDIT:
J'ai lu http://social.msdn.microsoft.com/Forums/en/wcf/thread/1e6aa407-4446-4d4a-8dac-5392250814b8 et http://forums.silverlight.net/forums/p/200659/468206.aspx#468206 et je suis d'accord que "singleMessagePerPoll" n'est pas une solution décente. Comme vous pouvez le voir sur mes versions, j'utilise les versions les plus récentes du SDK et de l'exécution du développeur.
EDIT2:
Je viens de découvrir que si j'utilise Google Chrome comme navigateur au lieu de IE8 MultipleMessagesPerPoll fonctionne très bien! Pour moi, ça sent comme un bug runtime vs. IE8?
EDIT3:
Un confirmé sur le blog silverlight WS: http://blogs.msdn.com/b/silverlightws/archive/2010/12/15/pollingduplex-using-multiplemessagesperpoll-issue-in-latest-sl4-gdrs.aspx
Nous avons été réellement en mesure de voir le comportement "MultipleMessagePerPoll" en chrome avec Fiddler. – svrist
Le bug est toujours là, mais nous n'avons pas besoin des cookies et le ClientHttp fonctionne très bien – svrist
+1 J'ai eu le même problème, et cela le corrige ... –