views:

67

answers:

3

Hi folks I have an in memory bounded queue in which multiple threads queue objects. Normally the queue should be emptied by a single reader thread that processes the items in the queue.

However, there is a possibility that the queue is filled up. In such a case I would like to persist any additional items on the disk that would be processed by another background reader thread that scans a directory for such files and processes the entries within the files. I am familiar with Active MQ but prefer a more light weight solution. It is ok if the "FIFO" is not strictly followed (since the persisted entries may be processed out of order).

Are there any open source solutions out there? I did not find any but thought I would ping this list for suggestions before I embark on the implementation myself.

Thank you!

+1  A: 

EHCache can overflow to disk. It's also highly concurrent, though you dont really need that

MJB
I will look into that...thanx!
serverman
A: 

You could use something like SQLLite to store the objects in.

Romain Hippeau
It crossed my mind, but I really do not need the SQLLite functionality - do not need SQL.
serverman
@serverman I know, you could just use it as file storage engine and then retrieve by timestamp order.
Romain Hippeau
Hi RomainAgreed. I am trying not to add another SQL component for the operations folks just for this one functionality. But yes - you are right in that I could use SQLLite.
serverman
@serverman - I know I sound like a broken record, I just want to make sure you understand that SQLLite is not a sql db with an install and even with SQL required. It is really just a file with an API. SQLLite requires no install all you need is the JAR file and a file on your OS. http://sqljet.com/ is a Java only implementation (Actually no SQL, just a low level API)
Romain Hippeau
Hi Romain, Sorry I think I spoke without even looking at sqllite properly. If it is just a jar then it may be the way to go:) Thank you for your patience.
serverman
@serverman Look here: http://sqljet.com/tutorial.html
Romain Hippeau
Yeah, I already checked it out and ran it. It looks like it is a java only implementation of sqllite - so my concern is how stable and well maintained is it? The official sqllite itself seems to be very well tested product but I am not sure about sqljet. As you may have guessed I am using Java.I looked at accessing sqllite with Java before checking out sqljet - is there a recommended way to access it - there seem to be tons of options listed at http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers.This is an issue only if sqljet is not an option for the above concerns.Thanx again!
serverman
@serverman - It will probably be more robust than implementing it from scratch.
Romain Hippeau
A: 

Why is the queue bounded? Why not use a dynamically expandable data structure? That seems much simpler than involving the disk.

Edit: It's hard to answer your question with out more context.

Can you clarify what you mean by "run out of memory"? How big is the queue? How much memory do you have?

Are you on an embedded system with very little memory? Or do you have 2 GB or more of stuff in the queue?

If either is true, you really aught to use a "swappable" data structure like a BTree. Implementing one your self for one queue seems like overkill. I would just use an embedded database like SQL lite.

If neither of those us true, then just use a vector or a linked list.

Edit 2: You probably don't need a BTree or a database. You could just use a linked list of pages. But again, I have to ask: is this necessary?

Or, if you are willing to process things non serially, why not have multiple reader threads all the time?

Ultimately though I don't think your proposal is the way to go.

Scott Wisniewski
The queue is bounded so we do not run out of memory.
serverman
See my updates.
Scott Wisniewski
Hi Scott, Good points. No it is not an embedded system. But there is a small chance that due to a sudden burst of activity the queue becomes full. The application has to deal with this (even if it happens rarely) I am leaning towards SQLLite that had only heard about till now:) Thank you!
serverman
If you aren't on an embedded system, and the number of items in the queue is not REALLY large, there does not ever need to be any notion of "full". I'm guessing you are saying "full" because you are using am array. Why? Don't. Use a Vector or a linked list.
Scott Wisniewski
Scott, you are right. In our case, the number of items in the QUEUE can be REALLY large since the processing of queue items is slower than the rate at which the queue data is inserted. I am planning to use ArrayBlockingQueue. The whole discussion assumes that if due to a sudden burst of activity, the queue can become full - in which case, I need to spill over.
serverman