Hi Manik,
Comments inline
----- Original Message ----
> From: Manik Surtani <manik at jboss.org>
> To: infinispan -Dev List <infinispan-dev at lists.jboss.org>
> Cc: Tim Fox <tim.fox at jboss.com>
> Sent: Thu, November 12, 2009 10:40:58 AM
> Subject: Re: [infinispan-dev] FIFO ordering...
>
> 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.
Yes, next unlocked local key. As of right now we're just using Infinispan as a local cache so we're not worried about cluster-wide issues yet. We'll be looking at distributing the data set with our next iteration (probably mid next year). Even when we do this we'll have local (in process) clients and remote clients so we'd like local clients to work on the local data and remote clients to work cluster-wide.
>
> > 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.
> :)
Yes, this is what I'm doing now. I've written a wrapper and I'm using the core api methods to iterate the key set looking for the next unlocked key. No changes needed to Infinispan code.
I've looked at adding an interceptor to track next key to remove iterating the key set but the use cases surrounding what "next" is with regard to locking and how to track it via interceptors made me pause for now. Iterating the key set is brute force but accurate since worst case we'll be iterating the key set only as deep as the number of threads we have and since it's local that's only about 500 so not too bad and for right now that's OK for us.
>
> > 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.
Thanks Manik. For us when we go distributed we don't need true FIFO since we know it is expensive. We just need eventual FIFO. Basically, a gurantee that nothing will get starved since we're using this as a work flow mechanism. Bouncing from node to node processing each node's list in FIFO order would be fine since that would gurantee all work gets done and nothing is forgotten. Something like that or whatever might be easy for Infinispan.
>
> 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
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev