I'm using net.tcp binding. when I call to certain function on the server that returns a list of objects. when the list is short (620 objects) everything works fine. when the list is above 620 object, I get this exception on the server (the client gets nothing..):
The underlying secure session has faulted before the reliable session fully completed. The reliable session was faulted.
When I call the same method again and it returns less then 620 objects, the client gets the list but in the log I see the error:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ServiceModel.CommunicationObjectAbortedException: The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it has been Aborted.
I thought it may be the limitation on the object size so I used the maximum values:
@myefforts2:yes, I got the logs, but didn't get any valuable info -
the error I see on the log is:
"The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:03:00'."
I would try adjusting the binding configuration (perhaps turning off reliable sessions) first to see if that eliminates or changes the error.
Alternatively, reducing the size of the message payload and using multiple calls might be the pragmatic solution.
I've tried turning off reliable session, but the error remains.
I use net tcp binding which is automatically duplex channel.
when I send the message directly (not within the callback on the duplex channel) the message was sent and received with no error.
I think that maybe when the other way of the duplex is sending the message - the size is limited... but it's only a speculation.
The most likely thing to think when using duplex is that both channels would have same message size limitation isn't is?
Using multiple calls would affect many clients (in my case) - so I'm looking a solution with minor influence on others as possible
Without knowing the ins-and-outs of WCF, this does sound like a message size limitation. How large are the objects you are passing when they are on the wire? This can be a hard question to answer and you may have to guess.
Given that your message size limit is set to 2147483647, and your system breaks after 620 items in the list, are your items larger than 2147483647/620 = 3463683 bytes? If so, then you may not be able to use this method to transfer them all in one go and you may need to page the data or think of a completely new tactic to retrieve them.
I don't see a SendTimeout value try setting this, and ensure both server and client have identical bindings. It looks that when you send 620 objects the default WCF timeout kicks in
I solved the problem:
I'll give some background - I work with two different endpoints "A" and "B". "A" is for the calls and the "B" is for events registration. The client asks asynchronously for the object from the server in "A" and subscribes to event on "B". When the server done calculating - it returns it on "B".
First I created a new function at the server that is not async and returns the object directly and it worked. So I figured out the problem is in the definition of the callback channel ("B").
I set the maxReceivedMessageSize to maximum on the client side at the callback endpoint as well. I think that because the channel is duplex I needed to specify it on each way... (reasonable isn't it..?
thank you all for your help!
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.