I've tried out a custom implementation before where I ignored the capacity value (with a LinkedTransferQueue), and I've done it the other way around where I needed to use a default capacity value (which was configurable as a property in the factory class). Alas, that seems to be a general problem of unbounded queues, though: the ability to run out of memory by accident.
On 24 October 2016 at 03:57, Antoine DESSAIGNE <antoine.dessai...@gmail.com> wrote: > Hello everyone, > > We're currently creating a custom implementation of seda's > BlockingQueueFactory. We are a bit puzzled by the expected behavior of some > corner cases. I'll be more than happy to create a pull request with more > detailed javadoc afterwards. > > So here are our questions. Thanks a lot if you have some answers. > > A. When your implementation is always unbounded, should you throw an > exception when you call create(int capacity) ? Should you ignore this > parameter ? Some users might rely on the fact that it's bounded to a > particular size in order to avoid OutOfMemoryException during data bursts. > > B. The ArrayBlockingQueueFactory default implementation doesn't use the > capacity passed in parameter, is this normal ? Maybe it is and I'll add > comments explaining why. Maybe it isn't and I'll fix it. > > Once again, thanks for your answers ! > > Have a nice day, > > Antoine. > -- Matt Sicker <boa...@gmail.com>
