# TPL Dataflow BatchBlock with Batch Size & Timeout

I needed BatchBlock with support for timeout (act greedy on what it received at that time) and by some search and study, this is the outcome.

What are drawbacks or rooms for improvement in this code?

class BatchedQueue
{
static readonly Logger SlotClassLogger = LogManager.GetCurrentClassLogger();
protected static Logger ClassLogger { get { return SlotClassLogger; } }
}

class BatchedQueue<T> : BatchedQueue
{

{
if (handler != null) handler(obj);
}

public BatchedQueue(int interval, int size)
{
_interval = interval;

_loopWait = TimeSpan.FromMilliseconds(2.19 * (1.3 + _interval)); //study

_queue = new BatchBlock<T>(size, new GroupingDataflowBlockOptions { Greedy = true });
_timer = new Timer(_ => _queue.TriggerBatch());

var transformer = new TransformBlock<T, T>(v =>
{
_timer.Change(_interval, Timeout.Infinite);
return v;
});
_source = new BufferBlock<T>();

{
if (t == null || t.Exception == null) return;
ClassLogger.Error(t.Exception);
}

public virtual void Post(T t) { _source.Post(t); }
void Loop()
{
while (true)
{
if (buffer != null) { OnReceived(buffer); }
}
}
}

• You can accomplish the same with much less code using TPL Dataflow. See this related post: stackoverflow.com/questions/9419442/… – Nathan Feb 26 '16 at 8:51
• I built a PCQueue with Batching and Timeout using the TPL Dataflow Library and it's very simple and might be what you're looking for: stackoverflow.com/q/25656391/392184 Scroll to the bottom of the OP question for my final solution. – Lee Grissom Dec 3 '17 at 20:30

class BatchedQueue


What's the reason for having this separate class? Is it so that there is only one instance of SlotClassLogger? If that's the case, that sounds like premature optimization to me.

class BatchedQueue<T> : BatchedQueue


You're not implementing (or exposing in other way) any of the dataflow interfaces. That means this class can't easily be used as a part of a dataflow network.

readonly int _interval;


When you have a value that is of some unit of measure, you should always very clearly specify what unit is uses. (You don't want your Mars probe to crash, right?) You can do that either in the name of variable or in a comment.

Though it seems you're not using any common unit. That should also be document very clearly and it should also have a very good reason. If the unit is something specific to your domain, then I don't think it belongs here, a class like this should be reusable.

If the condition for triggering it not actually some time elapsing, then consider using that condition directly, instead of approximating it using a timer.

transformer.LinkTo(_queue);
_source = new BufferBlock<T>();


I don't see any reason for the _source buffer block here. You could send items directly into transformer.

while (true)
{
if (buffer != null) { OnReceived(buffer); }
}


This code is blocking a thread unnecessarily when there is no work to do. The simplest solution would be to use ActionBlock to execute OnReceived.

There is no way to tell the queue to stop processing or for your to wait until its processing is done. Consider adding the Complete()/Completed pair used in dataflow blocks.

When dealing with time, Rx is often better than Dataflow. A behavior similar to yours could be achived by using Buffer():

_source = new Subject<T>();
_source.Buffer(_loopWait, size)

_source.Buffer(() =>

• I think you are right on that Loop() is blocking. But how could I be notified about new data that is available at that time? And how by merging Throttle with _source I can force it to trigger eagerly? And is it safe to combine TPL Dataflow with Rx? – Kaveh Shahbazian Oct 11 '14 at 17:54
• @KavehShahbazian For that notification, you can use ActionBlock as I suggested. Or, if you want to do it manually, await OutputAvailableAsync(). And I'm not suggesting you combine the two, I'm suggesting to switch to Rx completely. – svick Oct 11 '14 at 18:00