JBossDeveloper

The correct answers are:

"timfox" wrote:

The questions we need to ask are:

Do we use SoftReferences a la JBossMQ,

do we use the new Java 5 instrumentation stuff that Adrian pointed out,

or do we cache byte[] so it is trivial to work out used memory.

Also we need to determine how to prioritise messages for eviction - do we use LRU or some other policy.

Maybe I misunderstood something but for the purpose of spilling out messages to disk,

can we just replace:

// <messageID - MessageHolder>
 private Map messages;

// <messageID - MessageHolder>
 private TreeCache messages;

"timfox" wrote:

I'm not sure how TreeCache would help us. Our data is not tree-like in structure.

server/queue1/messages
server/queue2/messages
server/topic1/subscription1/messages
server/topic1/subscription2/messages
server/topic2/subscription1/messages

server/topic1/subtopic1/subscription1/messages

"AlexFu.Novell" wrote:
Maybe I misunderstood something but for the purpose of spilling out messages to disk,

"adrian@jboss.org" wrote:
The purpose of this discussion should be to define the contract/interface
and the default policy and/or anticapted plugins/policies/implementations.

Any discussion of how to implement a specific "plugin"/implementation
is an irrelevant "user question" not a design question.

"timfox" wrote:
I've been thinking about how best to implement the spillover of messages onto disk in JBoss Messaging.

"AlexFu.Novell" wrote:

I'm proposing a different way to solve the following issue, which is not an user question.

"timfox" wrote:
I've been thinking about how best to implement the spillover of messages onto disk in JBoss Messaging.

"adrian@jboss.org" wrote:
Q. Who says the message spill over onto disk/database?
A. User configuration

Q. What do you specify
A. That depends upon the implementation of the contract

Q. Why?
A. Because good software design separates policy from implementation

What Adrian is saying is that ultimately it doesn't matter how you implement the message cache and message spillover, what does matter is to make your implementation pluggable, so if it doesn't perform well in certain conditions, you replace it with something else that's available or you write your own. It's not inconceivable that Messaging will actually come out-of-the-box with 3 different caching mechanisms, as easy to switch as modifying a configuration element. Personally I find difficult to predict how a certain implementation will perform in a specific condition, until I have a prototype and try it. However, I strongly believe in measuring, profiling and taking corrective action, that can be as radical as completely scrapping an specific implementation and replacing with something else.

Let's concentrate on making sure that MessageStore interface is generic enough to handle all use cases we encountered so far, and also allows for plugging in arbitrary implementation - this is actually part of a more generic configuration issue that I am going to tackle soon.

As far as implementation goes, there are at least three ideas

1. Rip out the current JBossMQ MessageCache and use it as it is.

Every time JBossMQ JMSDestinationManager submits a message to one of its destinations, the destination unconditionally converts the message and its clones, where is the case, to a reference by delegating this task to the MessageCache. The MessageCache adds the message at the head of a LRU linked list and checks potential conditions for softening. It does this for every message. If those conditions are met, MessageCache picks the least recently used message from the back of the list and softens it, by storing the message on persistent storage, nulling the hard reference and replacing it with a SoftReference. It also does it in a loop until the softening condition is not met anymore. In parallel, there is a background thread (called "JBossMQ Cache Reference Softener") that performs the same check and softens messages independent of the message inflow.

2. Implement Tim's byte array based cache.

3. Delegate everything to TreeCache. Actually I find this idea interesting. Replication could also be explored. The distributed part multicasts messages, so far, but it can actually multicast references and leave message replication to JBossCache. I am still exploring this stuff, I don't know what's the best solution yet.

Alex: take a look at JBossMQ's MessagingCach, you can get it off jboss-head. Take the code you need and plug it under MessageStore and play with it. This way, you'll understand better the requirements. Personally I would go straight for an adaptation of the existing MessageCache implementation. However, if you have time, TreeCache is worth exploring, but only behind a MessageStore interface.