Wednesday, 27 July 2016

Red Hat JBoss Data Grid 7.0 is out

Dear Infinispan community,

Red Hat has just announced the general availability of Red Hat JBoss Data Grid 7.0, the commercially supported version of Infinispan.

Building on the solid foundation of Infinispan 8, JBoss Data Grid integrates with the rest of the Red Hat JBoss middleware platform to deliver top-notch long-term support, dedicated high-quality consulting and training services, and the best open-source expertise in the world.

If you want to give it a spin, go to the Red Hat JBoss Data Grid product page, where you will find download links for a free trial, documentation and more.

Posted by Tristan Tarrant on 2016-07-27
Tags: release jdg announcement red hat

Tuesday, 05 November 2013

Infinispan Arquillian Container 1.1.0.Alpha1 released

Dear Infinispan users, a new version of Infinispan Arquillian Container has been released into JBoss Maven Repository as maven artifacts. The previous version was announced by http://blog.infinispan.org/2012/09/infinispan-arquillian-container-100cr1.html The blog post contains information related to setup of JBoss Maven Repository, including its address as well as address of the Infinispan Arquillian Container itself.

Maybe we should now call the project Infinispan Arquillian extension rather than Infinispan Arquillian Container because, since version 5.3, Infinispan Server has been based on JBoss Application Server 7 and the submodule called infinispan-arquillian-container could be removed.

As a result, the configuration of Arquillian with respect to Infinispan Server was simplified.

Developing tests with Infinispan Server

Now there’s only one way to compose the arquillian.xml file:

The property ispnHome no longer exists. The path to the Infinispan Server is now specified via jbossHome. The serverConfig attribute then specifies the correct configuration file for the server.

In order to run tests with Infinispan Arquillian extension, one should use the following dependencies: org.jboss.as:jboss-as-arquillian-container-managed:jar:7.2.0.Final:test org.infinispan.arquillian.container:infinispan-arquillian-impl:jar:1.1.0.Alpha1:test

Now that we’ve configured the server to run in our tests, it’s time to introduce a few enhancements which will help you write tests more effectively.

RemoteInfinispanServers

You can still inject the reference to a running Infinispan Server by annotating an instance variable of type RemoteInfinispanServer with @InfinispanResource.

When there are more Infinispan servers to be injected, you can now use the following snippet instead of injecting each server independently:

  Then you can retrieve individual servers by calling .getServer(name) on the servers variable. The name must correspond to an existing container definition within arquillian.xml. The results of this call will be of type RemoteInfinispanServer.

WithRunningServer

So far users were forced to start the Infinispan Server either before the whole test suite (mode="suite") or before each class separately (mode="class"). The annotation WithRunningServer enables users to automatically start the server before a test method and stop it after the method. Example:

Note that in this case containers should be marked as mode="manual" in arquillian.xml file so that Infinispan Arquillian extension can handle lifecycle of these servers by itself.

When @WithRunningServer annotation is placed on a class, the server(s) will be started before the first method call in the test class, and stopped when JUnit @AfterClass event is triggered.

IPv6 support

Infinispan Arquillian extension can now work with Infinispan Server running on IPv6 as it can correctly connect to the server via JMX.

Testing embedded Infinispan

Running tests with plain Infinispan libraries instead of Infinispan Server has not changed since the last release. Read more about it in the previous blog post.

Thanks to Michal Linhard and Vitalii Chepeliuk who helped move the project one step further.

Cheers, Martin

Posted by Martin Genčúr on 2013-11-05
Tags: testing announcement

Wednesday, 20 June 2012

You can now buy support for Infinispan

Yes, at last.  Intentions first announced last year, and beta programme launched a few months ago, Red Hat’s JBoss Data Grid (JDG) 6.0 is now in final, GA form.  This supported release is based on Infinispan 5.1.5.Final, and you can read more about it here.

It has been picked up by the press too.

Open source.  And enterprise-grade.  :-)

Enjoy! Manik

Posted by Manik Surtani on 2012-06-20
Tags: jdg announcement paid support

Friday, 13 April 2012

Introducing the JBoss Data Grid: Infinispan, with support!

To many who are familiar with Red Hat's model of unsupported upstream projects with supported, heavily tested and certified controlled-release "products", the announcement of the JBoss Data Grid (JDG) will come as no surprise.  JDG is to Infinispan what Red Hat Enterprise Linux is to Fedora, or what JBoss Enterprise Application Platform (EAP) is to JBoss AS.  Folks considering deploying Infinispan in a mission-critical production environment should consider JDG instead, not only to gain the benefits of a more thorough quality control and certification process but also to allow Red Hat to provide development and production support and consultancy.

image

JDG was announced at Red Hat Summit/JBoss World last year, and I blogged about it here, and now JDG has reached a stage where it is available as a public beta with a GA release coming soon.  If you are interested in JDG, or supportable Infinispan, I encourage you to register your interest in the JDG Beta.

Enjoy Manik

Posted by Manik Surtani on 2012-04-13
Tags: jdg announcement

Tuesday, 28 April 2009

Infinispan: the Start of a New Era in Open Source Data Grids

Over the past few months we’ve been flying under the radar preparing for the launch of a new, open source, highly scalable distributed data grid platform. We’ve finally got to a stage where we can announce it publicly and I would like to say that Infinispan is now ready to take on the world!

The way we write computer software is changing. The demise of the Quake Rule has made hardware manufacturers cram more cores on a CPU, more CPUs in a server. To achieve the levels of throughput and resilience that modern applications demand, compute grids are becoming increasingly popular. All this serves to exacerbate existing database bottlenecks; hence the need for a data grid platform.

imageSo why is Infinispan sexy?

  1. Massive heap - If you have 100 blade servers, and each node has 2GB of space to dedicate to a replicated cache, you end up with 2 GB of total data. Every server is just a copy. On the other hand, with a distributed grid - assuming you want 1 copy per data item - you get a 100 GB memory backed virtual heap that is efficiently accessible from anywhere in the grid. Session affinity is not required, so you don’t need fancy load balancing policies. Of course you can still use them for further optimisation. If a server fails, the grid simply creates new copies of the lost data, and puts them on other servers. This means that applications looking for ultimate performance are no longer forced to delegate the majority of their data lookups to a large single database server - that massive bottleneck that exists in over 80% of enterprise applications!

  2. Extreme scalability - Since data is evenly distributed, there is essentially no major limit to the size of the grid, except group communication on the network - which is minimised to just discovery of new nodes. All data access patterns use peer-to-peer communication where nodes directly speak to each other, which scales very well.

  3. Very fast and lightweight core - The internal data structures of Infinispan are simple, very lightweight and heavily optimised for high concurrency. Early benchmarks have indicated 3-5 times less memory usage, and around 50% better CPU performance than the latest and greatest JBoss Cache release. Unlike other popular, competing commercial software, Infinispan scales when there are many local threads accessing the grid at the same time. Even though non-clustered caching (LOCAL mode) is not its primary goal, Infinispan still is very competitive here.

  4. Not Just for Java (PHP, Python, Ruby, C, etc.) - The roadmap has a plan for a language-independent server module. This will support both the popular memcached protocol - with existing clients for almost every popular programming language - as well as an optimised Infinispan-specific protocol. This means that Infinispan is not just useful to Java. Any major website or application that wants to take advantage of a fast data grid will be able to do so.

  5. Support for Compute Grids - Also on the roadmap is the ability to pass a Runnable around the grid. You will be able to push complex processing towards the server where data is local, and pull back results using a Future. This map/reduce style paradigm is common in applications where a large amount of data is needed to compute relatively small results.

  6. Management is key! - When you start thinking about running a grid on several hundred servers, management is no longer an extra, it becomes a necessity. This is on Infinispan’s roadmap. We aim to provide rich tooling in this area, with many integration opportunities.

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

What are data grids?http://www.arcatoglobal.com/images/ag_serverfarm.jpg[image]

Data grids are, to put it simply, highly concurrent distributed data structures. Data grids typically allow you to address a large amount of memory and store data in a way that it is quick to access. They also tend to feature low latency retrieval, and maintain adequate copies across a network to provide resilience to server failure.

As such, at its core, Infinispan presents a humble data structure. But this is also a high specialised data structure, tuned to and geared for a great degree of concurrency - especially on multi-CPU/multi-core architectures. 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.

Beyond this, Infinispan is also a distributed data structure. It farms data out across a cluster of in-memory containers. It does so with a configurable degree of redundancy and various parameters to tune the performance-versus-resilience trade-off. Local "L1" caches are also maintained for quick reads of frequently accessed data.

Further, Infinispan supports JTA transactions. It also offers eviction strategies to ensure individual nodes do not run out of memory and passivation/overflow to disk. Warm-starts using preloads are also supported.

JBoss Cache and Infinispan

So where does Infinispan stand against the competition? Let’s start with JBoss Cache. It is no surprise that there are many similarities between JBoss Cache and Infinispan, given that they share the same minds! Infinispan is an evolution of JBoss Cache in that it borrows ideas, designs and some code, but for all practical purposes it is a brand new project and a new, much more streamlined codebase.

JBoss Cache has evolved from a basic replicated tree structure to include custom, high performance marshalling (in version 1.4), Buddy Replication (1.4), a new simplified API (2.X), high concurrency MVCC locking (3.0.X) and a new non-blocking state transfer mechanism (3.1.X). These were all incremental steps, but it is time for a quantum leap.

Hence Infinispan. Infinispan is a whole new project - not just JBoss Cache 4.0! - because it is far wider in scope and goals - not to mention target audience. Here are a few points summarising the differences:

  • JBoss Cache is a clustering library. Infinispan’s goal is to be a data grid platform, complete with management and migration tooling.

  • JBoss Cache’s focus has been on clustering, using replication. This has allowed it to scale to several 10s (occasionally even over 100) nodes. Infinispan’s goals are far greater - to scale to grids of several 100’s of nodes, eventually exceeding 1000’s of nodes. This is achieved using consistent hash based data distribution.

  • Infinispan’s data structure design is significantly different to that of JBoss Cache. This is to help achieve the target CPU and memory performance. Internally, data is stored in a flat, map-like container rather than a tree. That said, a tree-like compatibility layer - implemented on top of the flat container - is provided to aid migration from JBoss Cache.

  • JBoss Cache traditionally competed against other frameworks like EHCache and Terracotta. Infinispan, on the other hand, goes head to head against Oracle’s Coherence, Gemfire and Gigaspaces.

I have put up some FAQs on the project. A project roadmap is also available, as well as a 5-minute guide to using Infinispan.

Have a look at JIRA or grab the code from our Subversion repository to see where we are with things. If you are interested in participating in Infinispan, be sure to read our community page.

I look forward to your feedback!

Cheers Manik

Posted by Manik Surtani on 2009-04-28
Tags: data grids announcement

News

Tags

JUGs alpha as7 asymmetric clusters asynchronous beta c++ cdi chat clustering community conference configuration console data grids data-as-a-service database devoxx distributed executors docker event functional grouping and aggregation hotrod infinispan java 8 jboss cache jcache jclouds jcp jdg jpa judcon kubernetes listeners meetup minor release off-heap openshift performance presentations product protostream radargun radegast recruit release release 8.2 9.0 final release candidate remote query replication queue rest query security spring streams transactions vert.x workshop 8.1.0 API DSL Hibernate-Search Ickle Infinispan Query JP-QL JSON JUGs JavaOne LGPL License NoSQL Open Source Protobuf SCM administration affinity algorithms alpha amazon anchored keys annotations announcement archetype archetypes as5 as7 asl2 asynchronous atomic maps atomic objects availability aws beer benchmark benchmarks berkeleydb beta beta release blogger book breizh camp buddy replication bugfix c# c++ c3p0 cache benchmark framework cache store cache stores cachestore cassandra cdi cep certification cli cloud storage clustered cache configuration clustered counters clustered locks codemotion codename colocation command line interface community comparison compose concurrency conference conferences configuration console counter cpp-client cpu creative cross site replication csharp custom commands daas data container data entry data grids data structures data-as-a-service deadlock detection demo deployment dev-preview development devnation devoxx distributed executors distributed queries distribution docker documentation domain mode dotnet-client dzone refcard ec2 ehcache embedded embedded query equivalence event eviction example externalizers failover faq final fine grained flags flink full-text functional future garbage collection geecon getAll gigaspaces git github gke google graalvm greach conf gsoc hackergarten hadoop hbase health hibernate hibernate ogm hibernate search hot rod hotrod hql http/2 ide index indexing india infinispan infinispan 8 infoq internationalization interoperability interview introduction iteration javascript jboss as 5 jboss asylum jboss cache jbossworld jbug jcache jclouds jcp jdbc jdg jgroups jopr jpa js-client jsr 107 jsr 347 jta judcon kafka kubernetes lambda language learning leveldb license listeners loader local mode lock striping locking logging lucene mac management map reduce marshalling maven memcached memory migration minikube minishift minor release modules mongodb monitoring multi-tenancy nashorn native near caching netty node.js nodejs non-blocking nosqlunit off-heap openshift operator oracle osgi overhead paas paid support partition handling partitioning performance persistence podcast presentation presentations protostream public speaking push api putAll python quarkus query quick start radargun radegast react reactive red hat redis rehashing releaase release release candidate remote remote events remote query replication rest rest query roadmap rocksdb ruby s3 scattered cache scripting second level cache provider security segmented server shell site snowcamp spark split brain spring spring boot spring-session stable standards state transfer statistics storage store store by reference store by value streams substratevm synchronization syntax highlighting tdc testing tomcat transactions tutorial uneven load user groups user guide vagrant versioning vert.x video videos virtual nodes vote voxxed voxxed days milano wallpaper websocket websockets wildfly workshop xsd xsite yarn zulip

back to top