We are attempting to figure out how to get a chunking implementation working. When testing code built around the chunking channel sample, we noticed that code that works fine on dual core CPUs starts to have problems on single core CPUs. We would randomly get the following CommunicationException on the client from ServiceChannel.Call():

The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.

In our traces, it looked like the server got the first chunk but not the rest. Suspecting a race condition I dug further into the chunking channel sample. I did not see any exceptions on the server, but in some stripped down sample code we discovered that sending small payloads at a fast interval (50 ms) could reproduce the exception on a Pentium M laptop.

My next step was to see if this happened in the vanilla chunking channel server and client. By putting the client code in Main() in a loop, I was able to get the exception reasonably quickly on the Pentium M laptop.

Just out of curiosity, I tried replacing the QueueUserWorkItem() in Receive(TimeSpan) in ChunkingDuplexSessionChannel with a synchronous call to ReceiveChunkLoop(). That gave the above exception back on the client immediately. I know it is a catch-all exception but it seems oddly coincidental. Is there some tight timing requirement in the TryReceive loop that would cause a synchronous call like this to generate a failure back to the client The service continues to run and no exception is generated in it.

Any help would be very welcome. Thanks!


Re: Windows Communication Foundation (Indigo) Chunking and the Meaningful Reply exception

David Kreutz - MSFT

Clemens Vasters wrote the chunking channel sample, he would probably be the best person to contact regarding problems you are having with it.

Re: Windows Communication Foundation (Indigo) Chunking and the Meaningful Reply exception



Thanks for the response. I had thought that Yasser Shohoud had created the sample and Clemens posted it to the community site. In any case, as much as I would appreciate his help I'm not sure if the issues that I'm seeing are due to the sample or the WCF runtime. To put my questions more directly:

1. Why does the synchronous call fail in Receive()
2. Does anyone else see similar behavior with single core systems Dual core and even Hyperthreaded CPUs don't seem to exhibit this problem to the same degree. As much as I would love to say single core CPUs are becoming extinct, I would still like to be able to run software on hardware from a couple of years ago.

Thanks in advance,


Re: Windows Communication Foundation (Indigo) Chunking and the Meaningful Reply exception


I have been able to come up with a workaround for this, but I would appreciate some feedback on the nature of the problem.

When this exception is generated, the traces show that the client generates a single chunk which is received by the service. The rest of the chunks of the image file are then sent, but they do not appear to be received. Then there are two activity boundary events (suspend/resume) followed by the exception.

It appears that on a single core system, the service in the chunking sample is not getting a chance to run. If I change the ChunkingWriter as follows:

Code Block
void CreateChunkMessage()
ChunkBodyWriter bodyWriter = new ChunkBodyWriter(this.WriteChunkCallback, this.chunkState);
Message chunk = Message.CreateMessage(this.version, ChunkingUtils.ChunkAction, bodyWriter);
chunk.Headers.Add(MessageHeader.CreateHeader(ChunkingUtils.ChunkNumberHeader, ChunkingUtils.ChunkNs, this.chunkNum, true));
this.outputChannel.Send(chunk, chunkingTimeout.RemainingTime());

// Let other threads run.

Console.WriteLine(" > Sent chunk {0} of message {1}", chunkNum, this.messageId);
this.chunkState = new ChunkState();


then the exception does not occur on the client. For those without a single core system, you can achieve the same result by starting the service and client, and then using Task Manager set the CPU affinity for each process to the same CPU (e.g. CPU 0).

I suppose my question becomes: why do we get an exception here Is this due to the nature of the EchoStream() method which takes a Stream as input and returns a Stream Is the client attempting to read the return Stream which I suppose is null since the service has not had a chance to create it I would have expected the client to block on the read in this case, but maybe it reads null and throws the exception.

Any thoughts