Last post Mar 28, 2012 04:40 PM by Northern
Mar 21, 2012 11:36 PM|Northern|LINK
I know this is a commen error message of WCF and there are many discussions about it online of which most have been resolved by changing the properties of binding. But, in my case, for some reason that doesn't seem to make any difference.
My client program invokes a service and expecting a big a mount of data come back (most of it is a very long string). I configure my client side WCF in my code and here is what I have for my binding:
I know the size of my return data. It is much less then
But, it doesn't seem to matter. The default 65536 is somehow still used. I have been trying to correct this for quite a while but still don't have a clue. I thought I could debug it in VS.Net and watch the binding when it runs and see if it gets changed but
I can't figure out how to watch the binding object - all I have is a reference and it doesn't show the binding or endpoint and even the WCF trace doesn't seem to show those either (even at verbose level)...
Can someone shed some light on this?
Thanks in advance!
Mar 21, 2012 11:50 PM|Ken Tucker|LINK
Try setting the MaxBuffer size to Int32.Max
Mar 22, 2012 01:20 PM|Northern|LINK
Wouldn't that be the same as I had in the code I attached in my last post?
Mar 23, 2012 07:31 AM|Peter pi - MSFT|LINK
Make sure that the binding name is applied to the bindingConfiguration property of endpoint, as your scenario, you have alread increased the maxBufferSize and maxReceivedMessageSize for your binding, so you need to use the NetTcpBinding bd when you create
a channel factory or initialize proxy class in the program. Here is a article about Programmatically enumerate WCF endpoints defined in app.config.
Mar 23, 2012 07:28 PM|Northern|LINK
Hi Peter pi,
Thanks for the help! We configure WCF in the code, instead of .config file. And I have checked, running debugging in VS.Net, that the endpoint used by channel factory has the right binding with the property values I want. But that debugging watch took place
when the call is going out to the server. Since the return of the call didn't get to the next line of my client side code, I can't check to see if the binding and the property values are still the same or have changed when the call came back. My guess is they
may have been changed for some reason. But the question is WHY? Here I attached more of my code so that you can see the more complete picture.
Also, in the stack trace that WCF Service Trace captured (see attached bellow), I noticed there are lines that has "System.ServiceModel.Dispatcher.DuplexChannelBinder.Request" in it. This looks a little strange to me as I don't think I am using DuplexChannel
for my server call here. Is this a problem or just the way it is?
Thanks again for your help!
' 1) Create a binding with some propertie values set
Dim bd As NetTcpBinding = New NetTcpBinding
bd.MaxBufferSize = Int32.MaxValue
bd.MaxReceivedMessageSize = Int32.MaxValue
bd.ReaderQuotas.MaxStringContentLength = Int32.MaxValue
' 2) Create a service endpoint using the binding, service contract and endpoint address
Dim ep As New ServiceEndpoint(ContractDescription.GetContract(GetType(IQLServiceFactory)), _
bd, New EndpointAddress(SvrURL & "QLServiceFactory.svc"))
' 3) Create a channel factory using the endpoint
Dim ft As ChannelFactory(Of IQLServiceFactory) = New ChannelFactory(Of IQLServiceFactory)(ep)
' 4) Create a service factory using the channel factory
Dim sf As IQLServiceFactory = ft.CreateChannel()
' 5) Call server using sf....
Portion of Stack Trace:
System.ServiceModel.Channels.ClientDuplexConnectionReader.DecodeMessage(Byte buffer, Int32& offset, Int32& size, Boolean& isAtEOF, TimeSpan timeout) System.ServiceModel.Channels.SessionConnectionReader.DecodeMessage(TimeSpan timeout) System.ServiceModel.Channels.SessionConnectionReader.Receive(TimeSpan
timeout) System.ServiceModel.Channels.SynchronizedMessageSource.Receive(TimeSpan timeout) System.ServiceModel.Channels.FramingDuplexSessionChannel.Receive(TimeSpan timeout) System.ServiceModel.Channels.FramingDuplexSessionChannel.TryReceive(TimeSpan timeout,
Message& message) System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout) System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object ins, Object outs,
TimeSpan timeout) System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object ins, Object outs) System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime
operation) System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) Trizetto.QLe2.QicLinkShared.IQCBroker.RunQuery(String ConnID, String prgName,
String& buffer, String size, Int32 termNum, Boolean dispose) Trizetto.QicLinX.DataAdapter.ClsRmtBroker.RunQuery(String strCblPrg, IQLMapper& params, String strConnID, Boolean bChkTermNum, Int32 intTermNbr, Boolean bDispose) Trizetto.QicLinX.QicLinkModel.ModelMenu.Execute(String
strGWay, IQLMapper& oMapr, String strCID, Int32 intTermNbr)
Mar 27, 2012 04:04 AM|Peter pi - MSFT|LINK
Based on my understanding, the binding and property value won't change when the call came back, but see the above stack trace,you can try increasing the value of each timeout properties(such as ReceiveTimeout,CloseTimeout,OpenTimeout,SendTimeout) for your
binding, and try to turn on WCF tracing on both server and clients side.
#enable WCF tracing.
Mar 28, 2012 04:40 PM|Northern|LINK
Thanks again for your help! I saw your response yesterday and I thought I replied to it but apparently I didn't...
I do have WCF tracing on both sides. It is always the client side gets this error on a call returns back from calling server. Beside, it doesn't seem to be the timeouts that I set - as you can see, I set them at least 10 mintues but I get the message size
error within 1 mintue.
It feels like that either something overriding my settings, or the system is actually using some other settings that I don't know about. But the question is still - what is it?