2

We have control client sending 100 updates each sized 200-250 bytes, per 2 sec to clients through diffusion for different topics(one update per topic in 2 sec). the issue is once after sending these for around 20-30 minutes, flow control starts and updates are being delayed from 5 ms to 100 ms after 1-2 hrs because of flow control. Is there any way to avoid flow control for publishing Control Client in diffusion?

maxqueuesize is set 10000 diffusion api log: pressure=0.04622500000000004 => sleep for 4 ms

Ark
  • 35
  • 5

1 Answers1

3

Flow Control was introduced into the Java client in v5.1 and the .NET client in v5.5 It exists to prevent internal queue overflow, which would otherwise close the client session. It a symptom that betrays deeper underlying issues.

It's happening for a few reasons:

  • Your Diffusion server is not keeping up with its workload. That this happens after some period of time makes me wonder if your server JVM is spending too much time collecting garbage. Java Missions Control is good at answering that question.

  • Less frequently we see this affecting control clients with dual roles, e.g. both creating and updating topics, and reacting to events such as Missing Topic Notifications. Flow Control is a function of a number of things including queue saturation and the number of unsatisfied requests. If this is the case consider a discrete session for each role.

Consider and explore the first & simpler possibility before moving to the second. If the issue persists then contact us at support@pushtechnology.com,

Martin

Martin Cowie
  • 2,788
  • 7
  • 38
  • 74
  • Looks like it is the 2nd case, I created another diffusion Session on the same Control client to send the updates, and the flow control issue is reduced. But the latency of sending updates is varying from 0 to 50 ms. Since we have 30 threads sending updates in parallel, this is not an issue for the time being. – Ark Oct 26 '16 at 06:40