FIFO Ordering

[imbng]

There was a question about this a while back (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=123638) but I was wondering if the answer has changed any since then.

I noticed there is a FIFO evictor so there must be some level of FIFO ordering happening when this is used. Is there any was this could be leveraged to have FIFO on Nodes?

Thanks

[manik]

Not really - the eviction algorithm is implemented as a linked list which links node Fqns as they are entered in the cache and processed on one end of the list.

What the previous thread was about was ordering attributes in a node.

[imbng]

So, sounds like if we wanted to FIFO process work as it enters the cache we'd have to roll our own.

Maybe by keeping track FIFO order in another node as you do for FIFO eviction and use it as our key structure to retrieve the nodes in the correct order. Something like that?

Is adding FIFO ordering to Nodes on any upcoming roadmaps? This would be a big piece of our system.

Thanks

[genman]

Manik, There should be some way to create FIFO nodes using a different implementation of Node Factory.

[imbng]

Hmm, sounds interesting...if that works how would I get the next in the list from the cache. There doesn't appear to be a getNext or get with no param.

[manik]

"genman" wrote:
Manik, There should be some way to create FIFO nodes using a different implementation of Node Factory.

Possibly, but at the moment it isn't configurable and there is no way to inject a custom node factory - unless you want to hack the ComponentRegistry and do a re-wire. Using different Map types in each Node is something we have been considering but there is a cost attached to using ordered maps everywhere (especially since with MVCC there is a lot of copying of maps going on, hence our FastCopyHashMap implementation). With ordering, this becomes even more expensive.

And even if we were to only use ordered maps for certain nodes to limit the impact, there is an issue of how this is specified. Declaratively, by specifying certain subtrees to be ordered? Or programmatically, via Node.addChild() and Node.addOrderedChild()? Or Node.makeOrdered()? The programmatic approach also impacts cache loaders and replication since these method invocations would need to be replicated to make sure the node is ordered across a cluster and a flag persisted with the node data in cache loaders, breaking all existing cache loaders.

So it isn't nearly as trivial as you think. :-)