2008-12-15 12 views
3

hey guys, une question WCF pour vous ici:WCF taille du message max

j'ai deux services et je envoie des messages assez gros morceaux entre eux (~ 100kb). Bien que la valeur mentionnée précédemment soit typique de la taille du message, il est possible qu'elle fluctue grandement (dans les deux sens positif et négatif). Ainsi, pour faire face à de telles situations où je dois transporter un message gonflé, j'ai augmenté tous les attributs de taille maximum de message, de taille maximum de chaîne etc. dans le fichier app.config côté client et côté serveur (avec le point de terminaison approprié référence correcte de la reliure qui indique les tailles)

La limite que j'ai saisie dépasse complètement toute taille de message possible pour des raisons de sécurité. Cependant, là où la communication inter-service s'est révélée fiable à l'extrémité inférieure de l'échelle de taille des messages, ce n'est pas le cas à l'extrémité supérieure - les messages ne semblent pas être délivrés du tout.

quelque chose d'étrange est que si le message avait dépassé la taille maximale, une exception serait jeté (je l'ai assez de ces rencontrais savoir ce lol!), Mais rien ne se jette - tout cela passe par complètement silencieux . J'ai expérimenté avec différentes tailles de messages et cela commence seulement à se produire à mesure que la taille des messages augmente. Je peux prouver ne sont pas reçus par le service de destination car, lors de la réception, le service fait un journal dans une base de données - mais avec de gros messages, aucun journal n'est fait. Comme je l'ai dit, je suis presque certain que j'ai augmenté la taille de tous les attributs applicables dans le app.config, et je suis donc complètement et complètement déconcerté par ce comportement!

des suggestions sur ce qui pourrait causer un comportement si mystifiant? toute aide serait beaucoup apprécié car c'est le dernier obstacle dans mon projet! merci :-)

+0

Avez-vous vérifié les journaux IIS pour voir si vous recevez le grand messages? – dtc

Répondre

0

Il y a des problèmes ocassionnels avec WCF qui vont lui faire échouer "silencieusement" (c'est-à-dire sans exception) qui peut être difficile à déboguer. Cela peut être le cas que vous voyez.

Dans ce cas, enabling the tracing options dans WCF peut être extrêmement utile, car il devrait vous permettre de voir si le message parvient effectivement au service et comment le répartiteur s'en occupe.

1

bien ce problème semble avoir résolu lui-même (soudainement après sans jamais se plaindre avant, WCF a commencé à avoir bouleversé une certaine valeur dans le app.config, a changé cela et il a semblé fonctionner alors!) Mais

maintenant i avoir un problème tout aussi étrange! pour une raison quelconque, il refuse d'accepter que j'ai configuré les métadonnées à publier. mon app.config (côté hôte) est mis en place comme suit:

<services> 
    <service name="DataFeederService.FeederService" behaviorConfiguration="DataFeederService.FeederServiceBehavior"> 
    <host> 
     <baseAddresses> 
     <add baseAddress="http://localhost:8010/Feeder"/> 
     <add baseAddress="net.pipe://localhost/FeederPipe"/> 
     </baseAddresses> 
    </host> 
    <!-- Service Endpoints --> 
    <!-- Unless fully qualified, address is relative to base address supplied above --> 
    <endpoint name="namedPipeEndpoint" 
    address="" 
    bindingConfiguration="IPCWindowsSecurity" 
    binding="netNamedPipeBinding" 
    contract="DataFeederService.IFeederService"> 
     <identity> 
     <dns value="localhost" /> 
     </identity> 
    </endpoint> 

    <endpoint name="httpEndpoint" 
    address="FeederService" 
    binding="wsHttpBinding" 
    bindingConfiguration="httpBinding" 
    contract="DataFeederService.IWebFeederService"/> 

    <!-- Metadata Endpoints --> 
    <!-- The Metadata Exchange endpoint is used by the service to describe itself to clients. --> 
    <!-- This endpoint does not use a secure binding and should be secured or removed before deployment --> 
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> 
    </service> 
</services> 

<bindings> 
    <netNamedPipeBinding> 
    <binding name="IPCWindowsSecurity" 
    maxBufferPoolSize="965536" 
    maxBufferSize="965536" 
    maxReceivedMessageSize="965536"> 
     <readerQuotas maxStringContentLength="965536" /> 
     <security mode="Transport"> 
     <transport protectionLevel="EncryptAndSign" /> 
     </security> 
    </binding> 
    </netNamedPipeBinding> 
    <wsHttpBinding> 
    <binding name="httpBinding" 
    maxBufferPoolSize="965536" 
    maxReceivedMessageSize="965536"> 
     <readerQuotas maxStringContentLength="965536" /> 
    </binding> 
    </wsHttpBinding> 
</bindings> 

<behaviors> 
    <serviceBehaviors> 
    <behavior name="DataFeederService.FeederServiceBehavior"> 
     <!-- To avoid disclosing metadata information, 
     set the value below to false and remove the metadata endpoint above before deployment --> 
     <serviceMetadata httpGetEnabled="True" policyVersion="Policy15"/> 
     <!-- To receive exception details in faults for debugging purposes, 
     set the value below to true. Set to false before deployment 
     to avoid disclosing exception information --> 
     <serviceDebug includeExceptionDetailInFaults="True" httpHelpPageEnabled="true" /> 
    </behavior> 
    </serviceBehaviors> 
</behaviors> 

J'ai essayé de mon mieux de comprendre pourquoi il réclamera les métadonnées ne sont pas en cours de publication à l'adresse indiquée " http://localhost:8010/Feeder/mex ". toute aide serait considérablement apprécié.

À la votre!

1

désolé les gars, après plus de chalutage j'ai découvert la source de l'erreur! l'une des classes du contrat de données avait été modifiée (l'attribut [DataContract] avait été supprimé, mais bizarrement [DataMemeber] avait été laissé sur les propriétés concernées!)

Merci pour votre aide de toute façon, en particulier rPour me arriver à ce point, où je peux enfin me laver les mains de ce projet sacrément :-)