Friday, 06 February 2015
Tags: interview jsr 107 jcache infoq certification
Thursday, 18 December 2014
The infinispan-jcache module in Infinispan 7.0.2.Final has been certified to be compatible JSR-107 1.0 specification implementation. To get started with Infinispan’s JSR-107 implementation, check the Infinispan documentation section on the topic, and remember that Infinispan also implements the JSR-107 annotations for CDI injection of cached values.
Thanks to everyone who has contributed to the module, and to Greg Luck and Brian Oliver for their help in completing the certification.
Tags: jsr 107 jcache certification
Tuesday, 19 November 2013
Dear Infinispan community,
This release brings some highly demanded features besides many stability enhancements and bug fixes:
Support for remote query. It is now possible for the HotRod clients to query an Infinispan grid using a new expressive query DSL. This querying functionality is built on top of Apache Lucene and Google Protobuf and lays the foundation for storing information and querying an Infinispan server in a language neutral manner. The Java HotRod client has already been enhanced to support this, the soon-to-be announced C++ HotRod client will also contain this functionality (initially for write/read, then full blown querying).
C HotRod client. Allows C applications to read and write information from an Infinispan server. This is a fully fledged HotRod client that is topology (level 2) and consistent hash aware (level 3) and will be released in the following days. Some features (such as Remote Query and SSL support) will be developed during the next iteration so that it maintains feature parity with its Java counterpart.
Better persistence integration. We’ve revisited the entire cache loader API and we’re quite pleased with the result: the new Persistence API brought by Infinispan 6.0 supports parallel iteration of the stored entries, reduces the overall serialization overhead and also is aligned with the JSR-107 specification, which makes implementations more portable.
A more efficient FileCacheStore implementation. This file store is built with efficiency in mind: it outperforms the existing file store with up to 2 levels of magnitude. This comes at a cost though, as keys need to be kept in memory. Thanks to Karsten Blees for contributing this!
Support for heterogeneous clusters. Up to this release, every member of the cluster owns an equal share of the cluster’s data. This doesn’t work well if one machine is more powerful than the other cluster participants. This functionality allows specifying the amount of data, compared with the average, held by a particular machine.
A new set of usage and performance statistics developed within the scope of the CloudTM projecthttps://issues.jboss.org/browse/ISPN-3234.
JCache (JSR-107) implementation upgrade. First released in Infinispan 5.3.0, the standard caching support is now upgraded to version 1.0.0-PFD.
For a complete list of features included in this release please refer to the release notes.
The user documentation for this release has been revamped and migrated to the new website - we think it looks much better and hope you’ll like it too!
This release has spread over a period of 5 months: a sustained effort from the core development team, QE team and our growing community - a BIG thanks to everybody involved! Please visit our downloads section to find the latest release. Also if you have any questions please check our forums, our mailing lists or ping us directly on IRC.
Tags: hotrod persistence jsr 107 jcache Protobuf remote query query
Monday, 16 September 2013
The existing CacheLoader/CacheStore API has been around since Infinispan 4.0. In this release of Infinispan we’ve taken a major step forward in both simplifying the integration with persistence and opening the door for some pretty significant performance improvements.
So here’s what the new persistence integration brings to the table:
alignment with JSR-107: now we have a CacheWriter and CacheLoader interface similar to the the loader and writer in JSR 107, which should considerably help writing portable stores across JCache compliant vendors
simplified transaction integration: all the locking is now handled within the Infinispan layer, so implementors don’t have to be concerned coordinating concurrent access to the store (old LockSupportCacheStore is dropped for that reason).
parallel iteration: it is now possible to iterate over entries in the store with multiple threads in parallel. Map/Reduce tasks immediately benefit from this, as the map/reduce tasks now run in parallel over both the nodes in the cluster and within the same node (multiple threads)
reduced serialization (translated in less CPU usage): the new API allows exposing the stored entries in serialized format. If an entry is fetched from persistent storage for the sole purpose of being sent remotely, we no longer need to deserialize it (when reading from the store) and serialize it back (when writing to the wire). Now we can write to the wire the serialized format as read fro the storage directly
Now let’s take a look at the API in more detail:
The diagram above shows the main classes in the API:
abstracts the serialized form on an object
MarshalledEntry - abstracts the information held within a persistent store corresponding to a key-value added to the cache. Provides method for reading this information both in serialized (ByteBuffer) and deserialized (Object) format. Normally data read from the store is kept in serialized format and lazily deserialized on demand, within the MarshalledEntry implementation
A provider might choose to only implement a subset of these interfaces:
If you’re looking at migrating your existing store to the new API, looking at the SingleFileStore for inspiration can be of great help.
And finally, the way the stores are configured has changed:
the 5.x loaders element is now replaced with persistence
both the loaders and writers are configured through a unique store element (vs loader and store, as allowed in 5.x)
the preload and shared attributes are configured at each individual store, giving more flexibility when it comes to configuring multiple chained stores
Tags: persistence jsr 107 loader store performance API
Friday, 03 May 2013
The first ever JUDCon Brazil was held a couple of weeks back and it was a real blast! Firstly, it offered a great opportunity to meet some members of the JBoss community which have been helping us push JBoss projects forward in this region of the world, such as Hanneli Tavante, Roberto dos Santos Wagner, …etc. It was great sharing ideas, experiences…etc with them and coming up with new ideas!
As mentioned before in the post before the conference, I had two new presentations to deliver, one on JSR-107 specification on JCache API and Infinispan’s implementation, and the other on Hibernate Second Level Cache with Infinispan. The JCache presentation went really well and all the live coding worked as expected.
The second presentation was the busier of the two, with a full room packed with Hibernate/JPA users waiting to hear how to scale up their applications. I got excellent feedback from both presentations and looking forward to giving these presentations in more user groups or conferences.
The presentations are not up yet, but I expect them to be posted online in the next few weeks. In the mean time, here are a couple of temporary links to the PDFs of my presentations:
The big news of the conference was for sure the announcement of JBoss Application Servers' new name: WildFly. We’re actively working with them to make the most out of Infinispan :)
Tags: conference presentations event jsr 107 judcon hibernate second level cache provider
Tuesday, 23 April 2013
As part of the recent Infinispan 5.3.0.Alpha1, the first Infinispan JCache implementation was released which implements version 0.6 of the JCache specification as defined by JSR-107. It passes 100% the mandatory TCK including optional transactions TCK.
A document on how to use Infinispan JCache implementation has just been released, which explains the basics of using JCache, how it differs with existing APIs provided by the JDK, and how to cluster JCache based cache instances. More information will be added to the document, including quickstarts, as we make further progress in the Infinispan 5.3 series.
Please note that the CDI and annotations part of JCache 0.6 specification is still in flux, and we’re not yet able to provide an implementation for it, but we expect the issues stopping the implementation to be resolved in the near future.
Finally, as it’s expected from first releases, some bugs might be present, so if you encounter any misbehaviour, check the list of issues associated with the JCache component to see if the issue has already been resolved, or if not, please report it so that it can be fixed ASAP :).
Tags: jsr 107 cdi jcache alpha
Wednesday, 21 September 2011
Since version 5.0 (Pagoa) Infinispan has a new module. This module is a portable CDI extension which integrates Infinispan with the CDI programming model. Here are some highlights of what is provided:
full integration with Java EE 6
typesafe cache (and cache manager) injection
JCACHE annotations support
Please note that this module is a technology preview and its API can still change. Next let’s discuss some of its details.
Typesafe injection and configuration of cache
The first feature you can use out of the box is the typesafe injection of the Cache and the CacheManager. Without any configuration you can inject the default cache, as well as the cache manager used by the extension. This injection can be performed in any bean managed by Java EE like EJB, Servlet and CDI beans. The only thing to do is to use the @Inject annotation:
Please note that the cache injection is typed. In this case, only String typed Java objects could be added as key and value.
It’s also possible to configure the injected cache using CDI. The first step is to create a CDI qualifier, and then create the cache configuration producer, annotated with @ConfigureCache. The qualifier is used to qualify the injection point and the cache configuration producer:
In the same way, a cache can be defined with the default configuration of the cache manager in use, using a producer field:
One advantage of this approach is that all cache configurations of the entire application can be gathered together into a single Configuration class.
The Infinispan CDI extension provides a cache manager with a default configuration (and it is used by default). You can also override the default configuration (used by the default cache manager), as well as the default cache manager. You can find more information here.
JCache annotations support
This specification defines a standard caching API to work with a standalone cache, as well as a distributed cache. An interesting part of the specification are the annotations which are designed to solve common caching use cases. Some of the annotations defined by this specification are:
@CacheResult caches the result of a method call
@CachePut caches a method parameter
@CacheRemoveEntry removes an entry from a cache
@CacheRemoveAll removes all entries from a cache
The following example illustrates the use of these annotations:
The Infinispan CDI extension adds support for these annotations. The only thing to do is to enable the CDI interceptors in your application beans.xml - you can find more information here.
Infinispan CDI and JBoss AS 7
With JBoss AS 7, you can setup an Infinispan cache manager in the server configuration file. This allows you to externalize your Infinispan configuration and also to lookup the cache manager from JNDI, normally with the @Resource annotation. This post has more details on the subject.
As we mentioned earlier, you can override the default cache manager used by the Infinispan CDI extension. To use a JBoss AS 7 configured cache, you need to use the cache manager defined in JBoss AS 7. You only need to annotate the default cache manager producer with @Resource. Simple!
Now, you can inject the cache defined in JBoss AS 7 as we described earlier.
Here is a highlight of the features you will see soon.
support for all JSR 107 annotations - @CachePut, @CacheDefaults
support for remote cache
ability to listen Infinispan events with CDI observers
and more - let us know what you want ;-)
As usual you can open issues and features request on the Infinispan JIRA (component CDI Integration).
Feel free to open a topic in the Infinispan forum if you need help.
The Infinispan CDI documentation is here.
About the author Kevin Pollet is a software engineer at SERLI a Consulting & Software Engineering company based in France. He’s an Open Source advocate and contributes on many projects such as Infinispan and Hibernate Validator, both at SERLI and at home. He is also involved in the Poitou-Charentes JUG and has spoken in many JUG events. He enjoys attending Java events like JUDCon, JBoss World and Devoxx.
Tags: jsr 107 cdi
Thursday, 01 September 2011
I never got around to blogging about this when my talks were accepted for JavaOne this year, but it’s about time.
I have a conference session titled "https://oracleus.wingateweb.com/content/sessionDetail.do?SESSION_ID=23382[A Tale About Caching (JSR 107) and Data Grids (JSR 347) in Enterprise Java]" and a BoF session focused on JSR 347 titled "https://oracleus.wingateweb.com/content/sessionDetail.do?SESSION_ID=23380[Making Java EE Cloud-Friendly: JSR 347, Data Grids for the Java Platform]", which I will be delivering with fellow Infinispan developer, JBoss rockstar and overall nice guy Pete Muir.
Later on in the year, I will also be running a University talk at Devoxx in Antwerp, titled "http://www.devoxx.com/display/DV11/Real-world+deep-dive+into+Infinispan+-+the+open+source+data+grid+platform[A real-world deep-dive into Infinispan]". This too will be with Pete and Mircea Markus, another core Infinispan developer.
This will be a great chance to learn more about Infinispan, data grids, JSR 107 and JSR 347, so if you are attending these conferences, make sure you add these talks to your agenda! :-)
Tags: devoxx jsr 107 jsr 347 JavaOne
Tuesday, 10 May 2011
Exciting times; today the JCP voted in a new JSR that I have proposed, JSR 347: Data Grids for the Java platform. I blogged about the original JSR proposal, and posted a follow-up to some criticisms around the proposal some weeks ago. The proposal, however, went ahead, was assigned a number (347!) and has just been voted in by the JCP executive committee.
Before I go into the details of 347 and my plans around it, I’d like to highlight some concerns in the community, in the area of overlap with JSR 107.
Is JSR 107 dead? No. In very recent months, there has been a flurry of activity in JSR 107. Activity which I am a part of, and hope will drive 107 to completion.
Does JSR 107 compete with JSR 347? No. JSR 347 aims to build upon JSR 107. JSR 107’s goals is to provide a temporary caching API for the Java SE platform. JSR 347 plans to reuse JSR 107’s APIs, adding additional features such as an asynchronous API, as well as defining mandatory characteristics such as behaviour with XA/JTA transactions and distributed workloads, thus targeting the Java EE platform.
Will JSR 347 retard the progress of JSR 107? No. If anything, JSR 347’s need for JSR 107 to complete will add impetus to the JSR 107 effort.
I sincerely hope the existing expert group of JSR 107 (of which I am a member) can and will work well with (and join!) the nascent expert group of JSR 347, to drive both JSRs to successful completion.
Now onto next steps with JSR 347: forming an expert group to put together an early draft. I would like to open invitations to join the expert group, please sign up on the JCP website.
With regards to process, with my background in open source and working with distributed teams, I intend this JSR to be developed in the public, making use of public mailing lists, public IRC channels and the like. I’ve even set up a twitter account for JSR 347 so people interested in its progress may follow it!
Tags: jsr 107 jsr 347
Thursday, 14 April 2011
PCWorld has published an article on the recent data grid JSR that I have submitted. As a follow-up to PCWorld’s article, I would like to make a few comments to clarify a few things.
I don’t quite understand what is meant by Red Hat’s approach not being the best solution. Do people take issue with having a standard in the first place? Or is it the standards body used in this particular case (the JCP)? If it is the details of the standard itself, one should keep in mind that this has yet to be defined by an expert group!
It is unfortunate that the "others" mentioned in the article - who feel that Red Hat’s approach is not the best - were not able to provide any details about their objections. I would love to hear these objections and make sure that the JSR addresses them.
The importance of a standard, to remove vendor lock-in, etc., is pretty well understood, so I won’t go into too much detail here. But with that in mind, I find Pandey’s comment regarding a "self-beneficial move" an odd one. A standard makes it easier for people to switch between products (which may explain why no one else may have stepped up to the plate to propose such a standard thus far). Proposing a standard makes it easier for end-users to move away from Infinispan. Yes, it may help with awareness of Infinispan, but it also means Red Hat, just like other data grid vendors, will need to work really hard to make sure their products are up to scratch. The only real beneficiary here is the end-user. In fact, I’d like to invite Terracotta to participate in this JSR, as participation can only make it stronger, more relevant and eventually even more useful to end-users.
With regards to JSR-107, I believe Pandey has misunderstood the intention in proposing a data grid JSR. I have proposed extending and building on top of JSR-107 - not throwing it away - and I have expressed this the JSR-107 expert group mailing list, of which Terracotta’s Greg Luck is a member. In fact, without Pandey’s actually seeing my data grid proposal blog post - PCWorld’s article was written before I published details of the JSR submission, based on a high-level Red Hat press release - one has to wonder where such strong words come from! :-)
Tags: jcp data grids jsr 107 standards