Analogue of Queue.Peek() for BlockingCollection when listening to consuming IEnumerable

Question

I\'m using Pipelines pattern implementation to decouple messages consumer from a producer to avoid slow-consumer issue.

In case of any exception on a message processi

Answer 1

As Dennis says in his comment, BlockingCollection provides a blocking wrapper to any implementor of the IProducerConsumerCollection interface.

As you can see, IProducerConsumerCollection, by design, does not define a Peek or other methods necessary to implement one. This means that BlockingCollection cannot, as it stands, offer an analouge to Peek.

If you consider, this greately reduces the concurrencey problems created by the utility trade off of a Peek implementation. How can you consume without consuming? To Peek concurrently you would have to lock the head of the collection until the Peek operation was completed which I and the designers of BlockingCollection view as sub-optimal. I think it would also be messy and difficult to implement, requiring some sort of disposable peek context.

If you consume a message and its consumption fails you will have to handle with it. You could add it to another failures queue, re-add it to the normal processing queue for a furture retry or just log its failure for posterity or, some other action appropriate to your context.

If you don't want to consume the messages concurrently then there is no need to use BlockingCollection since you don't need concurrent consumption. You could use ConcurrentQueue directly, you'll still get synchronicity off adds, and you can use TryPeek safely since you control a single consumer. If consumption fails you could stop consumption with a infinite retry loop in you desire although, I suggest this requires some design thought.