[infinispan-dev] FIFO ordering...

Manik Surtani manik at jboss.org
Thu Nov 12 13:40:58 EST 2009 

Hi Bryan

Comments inline:

On 20 Oct 2009, at 22:29, Bryan Grunow wrote:

> I didn't try using FIFODataContainer since it's set via the eviction
> tag.  I didn't know you could turn off the wakeUpInterval to turn off
> eviction.
> 
> I did just try it (FIFODataContainer) with our code and it worked just
> fine since we just use the keyset().  
> 
> One other thing we had to modify was add some methods to the
> AdvancedCache interface.
> 
>   K getNextKey();
>   V getNext();
>   V getNext(long timeout);
>   V take();
>   V take(long timeout);
> 
> The main one we need is getNextKey().  For this to work properly we need
> to get the next unlocked key in the cache.  

When you say unlocked, I presume you mean the next key which isn't being *locally* modified at the time?  It would be tough (expensive) to determine that the key is free of locks globally, probably requiring acquiring the lock cluster-wide yourself first.

> We use FIFO for workflow so a transaction will start and get the next
> key.  It will then process the data and commit the transaction.  Other
> threads can do the same when there is work so we need to make sure the
> next key is the next unlocked key.  A rollback of the transaction should
> put the key back in the queue.
> 
> The only way I could figure out how to check if a key was locked was via
> the LockManager.  The CacheDelegate didn't have access to is so I added
> it.

Probably the safest way to do so is to acquire the lock yourself.  Just checking would introduce races between checking and returning the entry to the caller.  :)

> Anyhow, point being it looks like we need to extend the API and some
> core classes a little to get this to work.  What's the best way to
> accomplish this since modifying the core interface and core classes is
> probably not going to fly?

A wrapper may be able to help you, at least initially to prove the mechanism.  And if it makes sense we could then roll some of these new APIs into the core.

I'm also cc'ing Tim Fox from HornetQ who has similar interests in distributed, ordered data structures.

Cheers
Manik


> 
> Bryan
> 
> -----Original Message-----
> From: infinispan-dev-bounces at lists.jboss.org
> [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Manik
> Surtani
> Sent: Tuesday, October 20, 2009 11:26 AM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] FIFO ordering...
> 
> The problem is to maintain additional ordering, which can be expensive  
> (more pointers, CAS, etc for every insertion or deletion).  If there  
> is no such need for a generic solution, then using an iterator on the  
> map while configuring the cache to use FIFO eviction will give you the  
> same effect.
> 
> 
> On 20 Oct 2009, at 19:08, Bryan Grunow wrote:
> 
>> My solution is per node at this point.  For what I need that is enough
>> but I don't feel it's a complete solution.  Other grid applications  
>> I've
>> used like this support it per node as well but distribute the call  
>> once
>> the initial cache node is emptied.  This can lead to starvation but  
>> it's
>> easy.  I can't say I like it.  I would think we could come up with
>> something better if needed.
>> 
>> Yes, I looked at FIFODataContainer.  In fact my initial implementation
>> was to create a new data container that kept a queue and returned an
>> ordered keyset().
>> 
>> I'd like to add queue support regardless of DataContainer but there
>> doesn't seem to be a way at that low of a level to hook into things
>> across data container impl.
>> 
>> Bryan
>> 
>> -----Original Message-----
>> From: infinispan-dev-bounces at lists.jboss.org
>> [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Manik
>> Surtani
>> Sent: Tuesday, October 20, 2009 10:52 AM
>> To: infinispan -Dev List
>> Subject: Re: [infinispan-dev] FIFO ordering...
>> 
>> 
>> On 20 Oct 2009, at 17:54, Bryan Grunow wrote:
>> 
>>> I posted JIRA issue https://jira.jboss.org/jira/browse/ISPN-132 a
>>> while ago and I'm wondering if it's on the roadmap anywhere?
>>> 
>>> I've worked on this internally and have a working solution but I'd
>>> like to know it's coming soon or not.  If not I will continue
>>> working on it but I need some guidance on the design to make sure it
>>> fits properly into Infifispan.
>> 
>> Hmm, almost as a side effect of an ordered data container (needed for
>> eviction), you would have a FIFO queue, albeit one that just gives you
>> a view of state local to the node.  The DataContainer impl used when
>> you enable FIFO eviction is the FIFODataContainer, and calling
>> Cache.keySet().iterator() would iterate over the FIFODataContainer.
>> 
>> Does your solution actually provide a global view in a FIFO manner?
>> And if so, how does it provide FIFO guarantees over concurrent
>> insertions made on different cluster nodes?  Or is this a non-strict
>> FIFO impl?
>> 
>> Cheers
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain  
>> confidential information, privileged material (including material  
>> protected by the solicitor-client or other applicable privileges),  
>> or constitute non-public information. Any use of this information by  
>> anyone other than the intended recipient is prohibited. If you have  
>> received this transmission in error, please immediately reply to the  
>> sender and delete this information from your system. Use,  
>> dissemination, distribution, or reproduction of this transmission by  
>> unintended recipients is not authorized and may be unlawful.
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org

More information about the infinispan-dev mailing list