I am looking at possible technology choices for queues (or perhaps streams are a better description) in a JVM-based system.
Some requirements:
How about using Redis as a messaging queue.It supports both in-memory and can be made persistent once data does not fit the RAM.
Use one of available JMS implementations. For example ActiveMQ or Qpid from Jakarta.
I have considered using Terracotta's BigMemory as a tool for pushing queue data into direct memory and off-heap.
HSQLDB provides an in-process database engine where you can use RAM, the local disk or a network server to store the database. That might float your boat, especially if you want to seamlessly move to a network solution rather than the local disk later on. Transitioning from small to large queues would then involve moving data from one database to another. There are standard ways to do this, but they might be pretty slow.
There more I think about it, the more I think this is not a good match. For what it's worth, the in-memory DB is very fast in my experience.
I ran across this FIFO queue with spill to disk which is kind of interesting and has some of the properties I'm looking for:
http://code.google.com/p/ashes-queue/