-
Notifications
You must be signed in to change notification settings - Fork 287
BlockingQueue implementation and other interfaces #198
Comments
The main reason is that the queue is not safe for concurrent interaction. A quick glance at the
|
All operations to the backing QueueFile are synchronized, so there is no concurrent access to the QueueFile (unless of course someone shares the QueueFile instances to other places). This is similar to the ArrayBlockingQueue which synchronizes every operation to the backing array. |
Ah, haha. The I don't think I'm opposed to adding this if you're willing to send a PR and write tests. |
…e QueueFile The resulting BlockingFileQueue is thread-safe and unbounded. Thread-safety is implemented with a single lock around all operations against the backing queue.
…e QueueFile The resulting BlockingFileQueue is thread-safe and unbounded. Thread-safety is implemented with a single lock around all operations against the backing queue.
…e QueueFile Switched to an ObjectQueue<T> as the backing store
…e QueueFile Switched to an ObjectQueue<T> as the backing store
…e QueueFile Switched to an ObjectQueue<T> as the backing store
…e QueueFile Switched to an ObjectQueue<T> as the backing store
…e QueueFile Switched to an ObjectQueue<T> as the backing store
…e QueueFile Switched to an ObjectQueue<T> as the backing store
…e QueueFile Switched to an ObjectQueue<T> as the backing store and delegate closable.
…e QueueFile QueueFile is now an ObjectQueue<byte[]> and can thus be used without overhead in the blocking queue. ObjectQueue's file():QueueFile method has been moved to FileObjectQueue where it fits better as InMemoryObjectQueue doesn't have a backing file. Removed the ByteArrayConverter again as it was the initial attempt to optimize for byte[] queues.
…e QueueFile sneakyfy the IO exception as done in other places.
…e QueueFile Increased coverage and minor cleanup
…e QueueFile minor cleanup
…e QueueFile more cleanup and a new test
…e QueueFile directly throw the sneaky exceptions
Is this project still alive? |
Used a lot of places but not heavily developed as it's pretty mature. I think there's a branch with a 2.0 proposal. -- https://github.com/square/tape/tree/2.0.0-RC1 |
I quickly build a
BlockingQueue<byte[]>
(gist here) based on the QueueFile for a project where I intend to use tape as an offline buffer/resend queue in case the uplink goes down. I could have just build the minimal wrapper I needed, but I though "why not just implement BlockingQueue and see if someone else thinks it's useful?"This made me wonder why none of Java's standard queuing interfaces have implementations here. Is there a specific reason for that?
If this is need interesting I can submit a PR for the BlockingQueue and implementations of Queue as well.
The text was updated successfully, but these errors were encountered: