[OT] Blocking, Persistent Queue suggestions?

[Gwyn Evans <gw...@gmail.com>]

A bit off-topic, as non-Wicket specific, but I'm stuck for ideas at
the moment...

I've got a simple servlet that gets requests and queues them for
later asynch processing by a number of 'background' threads.

The data's only a pair of short strings in each item, so I'm currently
using an in-memory FIFO queue decorated by the Commons-Collections
BufferUtils.blockingBuffer().

Now, however, I need to have the queue persist over a JVM restart &
maybe also to cap it's in-memory size.  I've not been able to come up
with anything that seems ideal, so I wondered if anyone had any
suggestions.  Has to run on JDK 1.4, by the way.

Current options:
  - DB: e.g. HSQLDB.  Maybe, seems a bit of overkill though
  - ehCache, wrapped somehow:  Maybe, but haven't yet got a good way
  to present a cache as a FIFO queue...
  
/Gwyn


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: [OT] Blocking, Persistent Queue suggestions?

[David Bernard <dw...@free.fr>]

I've develop this for a previous project where we replace JMS (MQ-Serie) queue by homemade system.
After some benchmark, ehcache was the winner. But when it's not stopped cleaned, then data/index are correpted and reset at the next start => loosing data :-(
At the end we develop a queueing system based on xstream to allow hand repair/restore after crash,...
If you want I could send you the code (LGPL).
To do the benchmark, we implements several backend : ehcache, xstream, berkeleydb, jisp

An other solution could be to use javaspace. I used blitz for the same purpose as you : async processing, but you need to manage fifo index (only gigaspaces do Fifo natively)

The most basic solution is create a wrapper for your fifo queue that create one file per event, and name of the file is the a counter,...

You could also try ActiveMQ (iirc backend could be JDBC or berkeley db). ;)

Every solution have have pro and cons.

Gwyn Evans wrote:
> A bit off-topic, as non-Wicket specific, but I'm stuck for ideas at
> the moment...
> 
> I've got a simple servlet that gets requests and queues them for
> later asynch processing by a number of 'background' threads.
> 
> The data's only a pair of short strings in each item, so I'm currently
> using an in-memory FIFO queue decorated by the Commons-Collections
> BufferUtils.blockingBuffer().
> 
> Now, however, I need to have the queue persist over a JVM restart &
> maybe also to cap it's in-memory size.  I've not been able to come up
> with anything that seems ideal, so I wondered if anyone had any
> suggestions.  Has to run on JDK 1.4, by the way.
> 
> Current options:
>   - DB: e.g. HSQLDB.  Maybe, seems a bit of overkill though
>   - ehCache, wrapped somehow:  Maybe, but haven't yet got a good way
>   to present a cache as a FIFO queue...
>   
> /Gwyn
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org