Why is WCF delaying message delivery?

Question

1.00/5 (1 vote)

See more:

Recent scenario:
1) Local service establishes a duplex channel to a remote service nettcp endpoint.
2) Remote service sends a short message via a subscribed callback every 2 seconds. Nothing more, nothing less.
3) Things ran fine for 45 minutes, and then 10 seconds went by without a message from the remote service. After that, four messages from the service were received in 42ms.
4) Information logged by the remote service shows it faithfully sent its message every 2 seconds. Information logged by the local service clearly shows the delayed delivery.

A similar situation of delayed messages has also been seen on another duplex channel that has regular messages spaced at 10- and 30-second intervals, so it doesn't seem to be connected with the configuration of just this channel. Whatever is wrong is probably common to both of them.

I'm in over my head, trying to learn the ins and outs of WCF in a sink-or-swim situation where I wasn't involved in any of the WCF code generation, so please don't leave out the "beginner's notebook" part of the answer.

What I have tried:

Added a lot of improved exception handling and management of the Channel and ChannelFactory, but the delay throws no exceptions and leaves no incriminating evidence in the MessageLogging svclog.

Posted 2-May-16 4:02am

John Whitmire

Updated 2-May-16 20:40pm

Add a Solution

Comments

Sergey Alexandrovich Kryukov 2-May-16 10:11am

What is the purpose of that "every 2 seconds"? And any other regular intervals? 10- 30-second..?
—SA

John Whitmire 2-May-16 11:28am

The 2-second message is a status update. The 10 and 30 second messages are heartbeat messages between a server and HTTP client.

Sergey Alexandrovich Kryukov 2-May-16 12:31pm

The status update should be sent only when the status has changed. Otherwise, what would be to point of subscription and even the duplex communication in general. Let me tell you: the point is implementing the push technology instead of pull. Pull is doubly wasteful: it does not provide responsiveness when something is changed and wastes time and traffic if nothing changes. This is the first thing you have to redesign.
—SA

John Whitmire 2-May-16 14:39pm

I neglected to say that the status update also functions as a heartbeat. (I keep forgetting that part.) In addition to the remote service's running status, the local service also needs to detect that it died.

Sergey Alexandrovich Kryukov 2-May-16 14:47pm

Then perhaps you could use pinging, outside of WCF...
—SA

John Whitmire 4-May-16 13:43pm

Never having needed pinning before, I had to refresh my understanding of what it is, but after doing so, I still don't see how that would apply.

Sergey Alexandrovich Kryukov 4-May-16 14:00pm

Oh... sorry, it was a typo. I meant ping, ICMP.
—SA

John Whitmire 4-May-16 17:57pm

Ping applies way ahead of this. We know the remote machine is present and alive. We don't know if the service we connected to on it is still alive. But all that is rather independent of this odd message delay I'm seeing in WCF.
I have found that it is related to object locks being used in operations on a different WCF channel. These things shouldn't be coupled at all (the other channel connects to a completely different service), but maybe they are... somewhere.

Sergey Alexandrovich Kryukov 4-May-16 20:29pm

If you know that the remote machine is present and alive, you don't need anything else; your application-layer protocol with the use of duplex channel and push technology takes care of the rest. We are coming back to my first argument: you don't need and heartbeat events. Am I missing something?
—SA

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)