[infinispan-dev] Infinispan REST server

[Manik Surtani]

On 27 Aug 2009, at 11:02, Michael Neale wrote:

> Hey all.
>
> (brief into: I am Mic, work for JBoss, on Drools and other things, I
> got chatting to Manik one day and on a cold sunday morning started
> hacking...)

Welcome!  :)

> I have been working on a RESTful server using RESTEasy as part of the
> infinispan server effort. Its really quite easy to do, but I believe
> useful for some cases I have in mind (involving non java clients)...
>
> For the moment, while I play with things and then tidy up, I have
> thrown the code up here:
> http://github.com/michaelneale/Infinispan-rest/tree/master but plan to
> put this in the infinispan tree when happy (it is a war, but we can
> also have stand alone distros).
>
> The basic cache operations map pretty nicely to HTTP verbs, GET, PUT,
> DELETE (can wipe out an element or a whole cache) etc etc... with meta
> info in the headers etc... (will be documenting it shortly, probably
> on the wiki). For example, a http PUT to /foo/bar puts an element with
> a key value of "foo" in the named cache "bar" (one cache manager
> config per running server instance).

I'm guessing you meant key value of 'bar' in a cache named 'foo'?  :)

> Content-Type headers are needed
> so the GET can operate correctly (also, this will probably be useful
> down the track for indexing for search/queries, as the payload data
> itself is a byte[] from the request body entity/stream).
>
> I am also working on making it honour "eTags" - which are quite handy
> (a GET with an eTag means it doesn't have to return the result if it's
> copy is already good). This means you could, for instance, use
> infinispan as a pretty dynamic content distribution network, pushing
> out content updates as often as you like, but taking the load of the
> servers (and network) where possible. Another option with persistence
> is basically similar to the amazon s3 service (including per cache or
> "bucket" ACLs, not hard to do)... many possibilities...

Yes, security and ACLs is something we need to think about even wrt.  
the other server modules (ISPN-171 and ISPN-173).

And yes, the possibilities are endless with the right tools and APIs -  
I'm sure people will discover many more uses that we haven't thought  
of yet.

> Some questions: I need to track things like "created" or "updated"
> time etc.. things that the cache would track - but I can't work out
> how to get at that data (so I can put it in the CacheEntry object, but
> it seems redundant???) - ideas?

Entries are stored internally as InternalCacheEntry [1] instances.  If  
you look at the object hierarchy, ICE is implemented by  
ImmortalCacheEntry, MortalCacheEntry, TransientCacheEntry and  
TransientMortalCacheEntry (ah, for Scala traits to make this  
cleaner!  :)

But anyway, creation time and last modified time is stored in *some*  
ICE impls (not all since it is not always needed).  Also, this is only  
exposed to internal components and not exported via the Cache API.

Where do you see a use for this information?  And in what cases do you  
need it - i.e., for all entries?  Only entries that specify a lifespan  
or maxIdle?

[1] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/infinispan/container/entries/InternalCacheEntry.java?r=433


> Also, if there a way to list the named caches in a cache manager?
> (just thinking as an optional feature).

Hmm - this info is available (stored in a DefaultCacheManager  
instance) but not exposed via public API.

https://jira.jboss.org/jira/browse/ISPN-174

>
>
> Anyway, love to hear ideas...
>
>
> Michael.
> _______________________________________________
> 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