Read about the announcement on my blog: http://infinispan.blogspot.com/2009/04/infinispan-start-of-new-era-in-open.html Or about the new asynchronous API here: http://infinispan.blogspot.com/2009/05/whats-so-cool-about-asynchronous-api.html The core data containers make use of state-of-the-art algorithms minimizing the use of mutexes for performance under high concurrency. More about this here: http://infinispan.blogspot.com/2009/05/implementing-performant-thread-safe.html Also on the roadmap are cool features such as searchability (query API) and NIO based server module providing memcached compatibility. Participate, download, feedback - http://www.infinispan.org Enjoy! Manik

More competition means better products.. ps: I realy would reconsider adding google adds on a company blog. It doesn't look very professional.

More competition means better products..

+1 Infinispan is also a recognition on the approach that both GigaSpaces and Coherence took for dealing with distributed data challenges. I would like to point that with GigaSpaces the DataGrid piece is part of the story, today we offer a set of solutions on top of our Data Grid that are aimed to addresses the end to end scalability from the load-balancer to the database with out of the box support for cloud computing. Quoting from the Infinispace docs:

7. Competition is Proprietary - All of the major, viable competitors in the space are not open-source, and are very expensive. Enough said. :-)

1. What makes Infinispan less propriety? 2. The cost is also an argument that i would be cautious of - as we can see in the past years many commercial OSS product start free to gain adoption and over time cost just like any of the commercial products. From an Enterprise point of view if you measure the ROI and not just the license cost then the ROI benefit of solution like Oracle or GigaSpaces can be even more competitive in terms of cost in various scenarios. At this point i would also like to point that we (GigaSpaces) offer our development framework (OpenSpaces.org) as OpenSource under the Apache 2.0 license and put a lot of effort to reduce potential lock-in. See more details here. Our believe is that we should compete on performance and scalability and not on the API. Any way congrats and good luck for the new release, it looks like your heading in the right direction. Nati S. GigaSpaces - Write Once Scale Anywhere

7. Competition is Proprietary - All of the major, viable competitors in the space are not open-source, and are very expensive. Enough said. :-)

1. What makes Infinispan less propriety?

It's not proprietary in that the software is LGPL and the development process is open, as are APIs, SPIs and internal APIs. Anyone can participate.

2. The cost is also an argument that i would be cautious of - as we can see in the past years many commercial OSS product start free to gain adoption and over time cost just like any of the commercial products. From an Enterprise point of view if you measure the ROI and not just the license cost then the ROI benefit of solution like Oracle or GigaSpaces can be even more competitive in terms of cost in various scenarios.

ROI is a complex thing, and is often dependent on specific usage and deployment scenarios. I was merely pointing out that there is no licensing cost to Infinispan due to its licensing.

7. Competition is Proprietary - All of the major, viable competitors in the space are not open-source, and are very expensive. Enough said. :-)

1. What makes Infinispan less propriety?

It's not proprietary in that the software is LGPL and the development process is open, as are APIs, SPIs and internal APIs. Anyone can participate.

2. The cost is also an argument that i would be cautious of - as we can see in the past years many commercial OSS product start free to gain adoption and over time cost just like any of the commercial products. From an Enterprise point of view if you measure the ROI and not just the license cost then the ROI benefit of solution like Oracle or GigaSpaces can be even more competitive in terms of cost in various scenarios.

ROI is a complex thing, and is often dependent on specific usage and deployment scenarios. I was merely pointing out that there is no licensing cost to Infinispan due to its licensing.

This is just me, but if the API isn't a standard, then it's proprietary. by that measure Infinispan is just as proprietary as commercial offerings. To me that isn't an issue. The important thing is how well does it work and is it designed well thoughtout. Good luck with the project, hope it grows and matures. peter

This is just me, but if the API isn't a standard, then it's proprietary. by that measure Infinispan is just as proprietary as commercial offerings.

As mentioned in early posts, it's API conforms to JSR-107. So, I think its hard to say that a software package which implements a standard API, provides the entire source under a free (as in libre) software license, and has an open development process is in any way proprietary ;)

This is just me, but if the API isn't a standard, then it's proprietary. by that measure Infinispan is just as proprietary as commercial offerings.

As mentioned in early posts, it's API conforms to JSR-107. So, I think its hard to say that a software package which implements a standard API, provides the entire source under a free (as in libre) software license, and has an open development process is in any way proprietary ;)

correct me if I'm wrong, but isn't JSR107 JCache inactive and never was finalized? It's good that Infinispan supports it, but I wouldn't really call it a standard per say. Perhaps now that Infinispan is making progress, JSR107 can be revived. http://jcp.org/en/jsr/detail?id=107 peter

.. isn't JSR107 JCache inactive?

JSR107 has had been active, with Manik and Greg Leake (EHCache) providing most of the recent effort. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++

.. isn't JSR107 JCache inactive?

JSR107 has had been active, with Manik and Greg Leake (EHCache) providing most of the recent effort.

Peace,

Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++

cool. nice to hear that. peter

What's nice to see about this is the understanding that this approach is the correct one. If this trend continues, all of the vendors will benefit from it.

JSR107 has had been active, with Manik and Greg Leake (EHCache) providing most of the recent effort.

Peace,

Cameron Purdy

Cameron, so, is JSR 107 active again? The JCP page on it shows it being inactive (and, for a while). -- Jags Ramnarayan GemStone Systems

JSR107 has had been active, with Manik and Greg Leake (EHCache) providing most of the recent effort.

Peace,

Cameron Purdy

Cameron, so, is JSR 107 active again? The JCP page on it shows it being inactive (and, for a while).

-- Jags Ramnarayan
GemStone Systems

glad to see I'm not the only one that was thrown off by the "inactive" status on the JSR page.

I think Cam meant Greg Luck of Ehcache. --Matt The Software Grove p.s. By the way, my CAPTCHA for this comment was "per dork" so I guess you should take it with a grain of salt. :)

More competition means better products..

+1 Infinispan is also a recognition on the approach that both GigaSpaces and Coherence took for dealing with distributed data challenges. I would like to point that with GigaSpaces the DataGrid piece is part of the story, today we offer a set of solutions on top of our Data Grid that are aimed to addresses the end to end scalability from the load-balancer to the database with out of the box support for cloud computing. Quoting from the Infinispace docs:

7. Competition is Proprietary - All of the major, viable competitors in the space are not open-source, and are very expensive. Enough said. :-)

1. What makes Infinispan less propriety? 2. The cost is also an argument that i would be cautious of - as we can see in the past years many commercial OSS product start free to gain adoption and over time cost just like any of the commercial products. From an Enterprise point of view if you measure the ROI and not just the license cost then the ROI benefit of solution like Oracle or GigaSpaces can be even more competitive in terms of cost in various scenarios. At this point i would also like to point that we (GigaSpaces) offer our development framework (OpenSpaces.org) as OpenSource under the Apache 2.0 license and put a lot of effort to reduce potential lock-in. See more details here. Our believe is that we should compete on performance and scalability and not on the API. Any way congrats and good luck for the new release, it looks like your heading in the right direction. Nati S. GigaSpaces - Write Once Scale Anywhere

Read about the announcement on my blog:

http://infinispan.blogspot.com/2009/04/infinispan-start-of-new-era-in-open.html

Or about the new asynchronous API here:

http://infinispan.blogspot.com/2009/05/whats-so-cool-about-asynchronous-api.html

The core data containers make use of state-of-the-art algorithms minimizing the use of mutexes for performance under high concurrency. More about this here:

http://infinispan.blogspot.com/2009/05/implementing-performant-thread-safe.html

Also on the roadmap are cool features such as searchability (query API) and NIO based server module providing memcached compatibility.

Participate, download, feedback - http://www.infinispan.org

Enjoy!
Manik

sounds like a good replacement for jboss cache. nice to see the gradual move towards coherence and gigaspaces style cache. It's a few years late to the game, but better late than never. peter

I'd love to really look at closely at Infinispan and understand what it does, but unfortunately I'm just way too lazy^H^H^H^Hbusy. So, after glancing at the site for about 30 seconds or so, I'd like to ask, is this supposed to be like an open-source version of Oracle Coherence?

So, after glancing at the site for about 30 seconds or so, I'd like to ask, is this supposed to be like an open-source version of Oracle Coherence?

Aren't they all? ;-) And Manik, for what it's worth, I took a brief look and I could tell you put a lot of thought into the API. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++

So, after glancing at the site for about 30 seconds or so, I'd like to ask, is this supposed to be like an open-source version of Oracle Coherence?

Aren't they all? ;-)

And Manik, for what it's worth, I took a brief look and I could tell you put a lot of thought into the API.

Peace,

Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++

I'm just glad Manik avoided NIH syndrome and realizes the way forward is distributed HashMap :) Clearly I'm bias in favor of coherence and gigaspaces style data grids. peter

Big fan of the asynch api, Manik. Good work. -Adrian jclouds

Big fan of the asynch api, Manik. Good work.

-Adrian
jclouds

Yes, the async API is one area where we deviate from JSR-107. I think the API has a lot of promise. Time will tell. :-)

...I'd like to ask, is this supposed to be like an open-source version of Oracle Coherence?

In so far as both products implement (a pre-release of) JSR-107, sure. :-)

Manik, Great stuff. Glad to see more folks are converging on grid/cloud computing ideas. All the best, Nikita Ivanov. GridGain - Open Cloud Platform

Congratulations to the team!

I have looked at the documentation, and the infispan datastructures are claimed to be lock free:

Most of the internals are essentially lock- and synchronization-free, favouring state-of-the-art non-blocking algorithms and techniques wherever possible. This translates to a data structure that is extremely quick even when it deals with a large number of concurrent accesses.

But normal lock free algorithms don't behave that great under stress because there is a risk of starvation. So how does Infispan deal with this? PS: I'm working on an Software Transactional Memory implementation called Multiverse and I use a lot of lock free datastructures as well, but contention management is something that is going to be added in the future to deal with starvation and livelocking. http://multiverse.googlecode.com/

I have looked at the documentation, and the infispan datastructures are claimed to be lock free

... snip ...

But normal lock free algorithms don't behave that great under stress because there is a risk of starvation. So how does Infispan deal with this?

Starvation is a risk you have not only with most lock-free algorithms, but even with ones that use locks - unless you use fair locks, in which case performance really suffers for all threads. And sadly I don't know of any efficient wait-free algorithms for concurrent linked-list, map and linked-map structures that would prevent starvation and still be uniformly performant. And for those interested in locking in Infinispan: Infinispan is not completely lock-free, as the docs suggest. We use MVCC, and a very STM-like approach where each client thread (or transaction) receives a context in which entry copies are made (for writing). This isolates them from concurrent changes. But a lock is used to ensure only one concurrent writer per entry. Readers, however, are completely lock-free - the 90% use case of a cache - as MVCC guarantees that the entry read won't be concurrently modified. What I meant by internals being lock-free (as far as possible) has to do with the ordered data containers - used for eviction - which employs a lock-free, thread-safe linked list structure, as well as other internal collections to hold concurrent transactions, contexts, etc. See http://infinispan.blogspot.com/2009/05/implementing-performant-thread-safe.html for details.

PS:
I'm working on an Software Transactional Memory implementation called Multiverse and I use a lot of lock free datastructures as well, but contention management is something that is going to be added in the future to deal with starvation and livelocking.

This looks interesting. How do you plan on dealing with starvation?

We use MVCC, and a very STM-like approach where each client thread (or transaction) receives a context in which entry copies are made (for writing).

I was using MVCC for Multiverse as well. At the moment no old history is maintained so you get a snapshottooold error immediately. But in the future it will be added again if it provides value (especially for readonly transactions since it doesn't matter if the state they read is a little bit stale). For more information about my locking approach see: http://pveentjer.wordpress.com/2009/04/22/mvcc-tl2-concurrency

How do you plan on dealing with starvation?

At the moment there are no policies for dealing with it except retrying. But in the future I'll make a distinction between internal (caused by my the internals of the STM) and external (so causes by the objects used in the transaction) contention. The internal contention will be monitored, so I can see if I need to change anything. But no extra policies yet. The external contention will be configurable through a transactioncontentionmanager. This will be based on the idea's of Maurice Herlihy.

Nice start looks like it will be very useful when complete

Is it (or will it be on near-term roadmap) to execute agents against the data in the grid, like this: http://www.ibm.com/developerworks/wikis/objectgridprog/6.1.0.5/docs/api/com/ibm/websphere/objectgrid/datagrid/MapGridAgent.html or like the Coherence EntryProcessor: http://download.oracle.com/otn_hosted_doc/coherence/342/index.html)

proper link for the Coherence EntryProcessor: http://download.oracle.com/otn_hosted_doc/coherence/342/com/tangosol/util/InvocableMap.EntryProcessor.html

halloween costumes 2009