Friday, 28 August 2020

The developer Conference Sao Paulo

Dear Infinispan community,

What is The Developer’s Conference?

The Developer’s Conference (TDC) is the largest event related to software development in Brazil connecting meetup and event organizers, speakers, companies and sponsors on a single platform, empowering the local ecosystem of each region it’s realized.

TDC is a very dynamic conference aimed to present the most important topics according to local and international needs and, for this reason, there are more than ten parallel tracks a day.

This event takes place once a year in some cities in Brazil, but this year the event will be totally online due to COVID-19 impact.

Red Hat will be present on this event with 6 principal lectures and one room occurring simultaneously throughout the event. We will have an Infinispan presentation showing some important features, what’s new, demos and Quarkus integration at Red Hat sponsor room.

When the Infinispan presentation will happen?
Table 1. Friday, 28th August
Hour Timezone









Posted by Gustavo Lira on 2020-08-28
Tags: tutorial learning presentation quarkus event tdc

Monday, 02 November 2015

JBoss Clustering Team @ JUG Berlin Brandenburg

The entire JBoss Clustering Team will be at the Berlin-Brandenburg JUG on Thursday, 19th November talking about JGroups, Infinispan and WildFly clustering. If you are around, please come over to meet the team and share your thoughts and ideas.

The meetup is advertised here

Posted by Tristan Tarrant on 2015-11-02
Tags: JUGs event jgroups wildfly

Monday, 15 December 2014

Hot Rod Remote Events #4: Clustering and Failover

This blog post is the last in a series that looks at the forthcoming Hot Rod Remote Events functionality included in Infinispan 7.0. First article focused on how to get started receiving remote events from Hot Rod servers. The second article looked at how Hot Rod remote events can be filtered, and the third one showed how to customize contents of events.

In this last article, we’ll be focusing on how remote events are fired in a clustered environment and how failover situations are dealt with.

The most important thing to know about remote events in a clustered environment is that when a client adds a remote listener, this is installed in a single node in the cluster and that this node is in charge of sending events back to the client for all affected operations happening cluster wide.

As a result of this, when filtering or event customization is applied, the org.infinispan.notifications.cachelistener.filter.CacheEventFilter and/or org.infinispan.notifications.cachelistener.filter.CacheEventConverter instances must be somehow marshallable. This is necessary because when the client listener is installed in a cluster, the filter and/or converter instances are sent to other nodes in the cluster so that filtering and conversion can happen right where the event originates, hence improving efficiency. These classes can be made marshallable by making them extend Serializable, or providing and registering a custom Externalizer for them.

Under normal circumstances, the code and examples showed in previous blog posts work the same way in clustered environment. However, in a clustered environment, a decision needs to be made with regards to how to deal with situations where nodes go down: If a node goes down that does not have the client listener installed, nothing happens. However, when the node containing the client listener goes down, the Hot Rod client implementation transparently fails over the client listener registration to a different node. As a result of this failover, there could be a gap in the event consumption. This gap is solved using one of these solutions:

State Delivery

The @ClientListener annotation has an optional parameter called includeCurrentState. When this is enabled and the client listener is registered, before receiving any events for on-going operations, the server sends ClientCacheEntryCreatedEvent event instances (for methods annotated with @ClientCacheEntryCreated) for all existing cache entries to the client. This offers the client an opportunity to construct some state or computation based on the contents of the clustered cache. When the Hot Rod client transparently fails over registered listeners, it re-registers them in a different node and if includeCurrentState is enabled, clients can recompute their state or computation to reinstate it to what it was before the failover. The downside of includeCurrentState is that it’s performance is heavily dependant on the cache size, and hence it’s disabled by default.


Alternatively, instead of relying on receiving state, users can define a method with @ClientCacheFailover annotation that receives ClientCacheFailoverEvent as parameter inside the client listener implementation:

This method would be called back whenever the node that had this client listener has gone down. This can be handy for situations when the end users just wants to clear up some local state as a result of the failover, e.g. clear a near or L1 cache. When events are received again, the near or L1 cache could be repopulated again.

This callback method of dealing with client listener failover offers a simple, efficient solution to dealing with cluster topology changes affecting client listeners. Depending on the remote event use case, this method might be better suited that state delivery.

Final Words

This post marks the end of the remote event series. In future Infinispan versions, we’ll continue improving the technology adding some extra features, and more importantly, we’ll start building higher level abstractions on top of remote events, such as Hot Rod client Near Caches.

Cheers, Galder

Posted by Galder Zamarreño on 2014-12-15
Tags: hotrod event remote events failover

Thursday, 25 September 2014

Cache and Cache Manger events in CDI

A long time ago, in a coffee bar far, far away, Infinispan met CDI. The two had the most amazing espressos, but they noticed that service was not as efficient as they wished. To help them out, the CDI support has been extended to include CDI Events.

Coffee Events

In case you haven’t heard about CDI events, here is a really quick example:

When Waiter receives an order - he fires a CDI event. On the other hand Barista acts as a listener for ordered coffees (@CoffeeOrdered and @Observes). As a result Barista and Waiter are loosely coupled and moreover they don’t know anything about each other.

Cache based Coffee Events

Now let’s complicate this situation a little bit…​ Let’s assume that when Waiter is passing an order to Barista, he might be actually busy processing another order. So let’s introduce a little buffer between them - Waiter puts an order into the Cache and later on - Barista takes it and prepares our delicious coffee…​

Beyond good espressos

As you can see - introducing CDI improved the service a lot. Now Waiter does not hurry Barista with the orders. This is why they serve the best espresso in the world there…​

They have also a lot more time to think about other improvements (and to be honest…​ I think they will introduce CacheEntryModifiedEvent, CacheEntryRemovedEvent and CacheStartedEvent really shortly)…​ Or perhaps they’ll find some other ideas in Infinispan’s manual?

Posted by Sebastian Łaskawiec on 2014-09-25
Tags: event cdi

Wednesday, 17 September 2014

Hot Rod Remote Events #3: Customizing events

This blog post is the third in a series that looks at the forthcoming Hot Rod Remote Events functionality included in Infinispan 7.0. In the first article we looked at how to get started receiving remote events from Hot Rod servers. In the second article, we saw how Hot Rod remote events can be filtered providing key/value filter factories that can create instances that filter which events are sent to clients, and how these filters can act on client provided information.

This time we are going to focus on how to customize events sent to clients. Events generated by default contain just enough information to make the event relevant but avoid cramming too much information in order to reduce the cost of sending them. Normally, this information consists of key and type of event.

Optionally, the information shipped in these events can be customized in order to contain more information, such as values, or to contain even less information. This customization is done with org.infinispan.notifications.cachelistener.filter.CacheEventConverter instances which are created by implementing a org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactory class. Each factory must have a name associated to it via the org.infinispan.filter.NamedFactory annotation.

When a listener is added, we can provide the name of a converter factory to use with this listener, and when the listener is added, the server will look up the factory and invoke getConverter method to get a org.infinispan.notifications.cachelistener.filter.CacheEventConverter class instance to customize events server side.

Here’s a sample implementation which will send custom events containing value information back to clients for a cache of Integers and Strings:

In the example above, the converter generates a new custom event which includes the value as well as the key in the event. This will result in bigger event payloads compared with default events, but if combined with filtering, it can reduce its network bandwidth cost.

In another converter implementation, the user could decide to send back an event that contains no key or event type information. This would result in extremely lightweight events at the expense of richness of information provided by the event itself.

Plugging the server with this converter requires deploying this converter factory (and associated converter class) within a jar file including a service definition inside the META-INF/services/org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactory file:

With the server plugged with the converter, the next step is adding a remote client listener that will use this converter. How to implement a listener for custom events is slightly different to the listeners we’ve seen in the last couple of blog posts because we know have to deal with customised events as opposed to the default ones. To do so, the same annotations are used as previous blog posts, but the callbacks receive instances of org.infinispan.client.hotrod.event.ClientCacheEntryCustomEvent<T>, where T is the type of custom event we are sending from the server:

Now it’s time to write a simple main java class which adds the remote event listener and executes some operations against the remote cache:

Once executed, we should see a console console output similar to this:

Similar to events, converters can also act on client provided information, enabling converter instances to customize events depending on the information given when the listener was added. The API provides an extra parameter to pass in converter parameters when the listener is added. Given the similarities with filtering, this part is not covered by this blog post.

A final note on the marshalling aspects of this example. In order to facilitate both server and client writing against type safe APIs, both the client and server need to be aware of custom event type and be able to marshall it. Client side, this is done by an optional marshaller configurable via the RemoteCacheManager. Server side, this is done by a marshaller recently added to the Hot Rod server configuration.

In the next blog post in the Hot Rod remote events series, we will look at how to receive remote events in a clustered environment, how to deal with failover situations…​etc.

Cheers, Galder

Posted by Galder Zamarreño on 2014-09-17
Tags: hotrod event remote events

Wednesday, 20 August 2014

Hot Rod Remote Events #2: Filtering events

This blog post is the second in a series that looks at the forthcoming Hot Rod Remote Events functionality included in Infinispan 7.0. In the first blog post we looked at how to get started receiving remote events from Hot Rod servers. This time we are going to focus on how to filter events directly in the server.

Sending events to remote clients has a cost which increases as the number of clients. The more clients register remote listeners, the more events the server has to send. This cost also goes up as the number of modifications are executed against the cache. The more cache modifications, the more events that need to be sent.

A way to reduce this cost is by filtering the events to send server-side. If at the server level custom code decides that clients are not interested in a particular event, the event does not even need to leave the server, improving the overall performance of the system.

Remote event filters are created by implementing a org.infinispan.notifications.cachelistener.filter.CacheEventFilterFactory class. Each factory must have a name associated to it via the org.infinispan.notifications.cachelistener.filter.NamedFactory annotation.

When a listener is added, we can provide the name of a key value filter factory to use with this listener, and when the listener is added, the server will look up the factory and invoke getFilter method to get a org.infinispan.notifications.cachelistener.filter.CacheEventFilterFactory class instance to filter events server side.

Filtering can be done based on key or value information, and even based on cached entry metadata. Here’s a sample implementation which will filter key "2" out of the events sent to clients:

Plugging the server with this key value filter requires deploying this filter factory (and associated filter class) within a jar file including a service definition inside the META-INF/services/org.infinispan.notifications.cachelistener.filter.CacheEventFilterFactory file:

With the server plugged with the filter, the next step is adding a remote client listener that will use this filter. For this example, we’ll extend the EventLogListener implementation provided in the first blog post in the series and we override the @ClientListener annotation to indicate the filter factory to use with this listener:

Next, we add the listener via the RemoteCache API and we execute some operations against the remote cache:

If we checkout the system output we’ll see that the client receives events for all keys except those that have been filtered:

Finally, with Hot Rod remote events we have tried to provide additional flexibility at the client side, which is why when adding client listeners, users can provide parameters to the filter factory so that filter instances with different behaviours can be generated out of a single filter factory based on client side information. To show this in action, we are going to enhance the filter factory above so that instead of filtering on a statically given key, it can filter dynamically based on the key provided when adding the listener. Here’s the revised version:

Finally, here’s how we can now filter by "3" instead of "2":

And the output:

To summarise, we’ve seen how Hot Rod remote events can be filtered providing key/value filter factories that can create instances that filter which events are sent to clients, and how these filters can act on client provided information.

In the next blog post, we’ll look at how to customize remote events in order to reduce the amount of information sent to the clients, or on the contrary, provide even more information to our clients.

Cheers, Galder

Posted by Galder Zamarreño on 2014-08-20
Tags: hotrod event remote events

Tuesday, 12 August 2014

Hot Rod Remote Events #1: Getting started

Shortly after the first Hot Rod server implementation was released in 2010, ISPN-374 was created requesting cache events to be forwarded back to connected clients. Even though embedded caches have had access to these events since Infinispan’s first release, propagating them to remote clients has taken a while, due to the increased complexity involved.

For Infinispan 7.0, we’ve finally addressed this. This is the first post in a series that looks at Hot Rod Remote Events and the different functionality we’ve implemented for this release. On this first post, we show you how to get started with Hot Rod Remote Events with the most basic of examples:

Start by downloading the Server distribution for the latest 7.0 (or higher) release from Infinispan’s download page. The server contains the Hot Rod server with which the client will communicate. Once downloaded, start it up running the following from the root of the server:


Next up, we need to write a little application that interacts with the Hot Rod server. If you’re using Maven, create an application with this dependency, changing version to 7.0.0.Beta1 or higher:

If not using Maven, adjust according to your chosen build tool or download the all distribution with all Infinispan jars.

With the application dependencies in place, we need to start to write the client application. We’ll start with a simple remote event listener that simply logs all events received:

Now it’s time to write a simple main java class which adds the remote event listener and executes some operations against the remote cache:

Once executed, we should see a console console output similar to this:

As you can see from the output, by default events come with the key and the internal data version associated with the current value. The actual value is not shipped back to the client for performance reasons. Clearly, receiving remote events has a cost, and as the cache size increases and more operations are executed, more events will be generated. To avoid inundating Hot Rod clients, remote events can either be filtered server side, or the event contents can be customised. In the next blog post in this series, we will see this functionality in action.

Cheers, Galder

Posted by Galder Zamarreño on 2014-08-12
Tags: hotrod event remote events

Friday, 03 May 2013

The first JUDCon Brazil experience

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:

  • Bolttlenecks are out! Java Cache Standard (JSR-107) is in! (PDF)

  • Scaling up Hibernate/JPA applications with Infinispan second-level cache (PDF)

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 :)

Cheers, Galder

Posted by Galder Zamarreño on 2013-05-03
Tags: conference presentations event jsr 107 judcon hibernate second level cache provider

Thursday, 18 April 2013

Infinispan coming to Brazil's JUDCon!!

Infinispan team is coming to São Paulo (Brazil) to present on multiple topics around caching, data grids and NoSQL in Brazil’s first ever JBoss Users & Developers Conference (JUDCon). The event is being held over two days, on 19th and 20th of April.

On the 19th, Manik Surtani and Pete Muir will present on how to supercharge web applications using JBoss Data Grid. Expect a very lively presentation from these very seasoned presenters :)

Another presentation where you’ll be able to see Infinispan in action is in Shekhar Gulati’s "Closed PaaS to Open PaaS : Migrate GAE Applications to OpenShift Using CapeDwarf" and Randall Hauch’s "Elastic Consistent NoSQL Data Storage with ModeShape 3" talk, both on the 19th of April, where Shekhar and Randal will demonstrate JBoss projects using Infinispan heavily.

On 20th of April, I’ll be speaking about scaling up Hibernate/JPA applications with Infinispan second-level cache. Even if the Infinispan caching provider was created almost 4 years ago, this is the first time I’m presenting about it. Really looking forward to that.

Finally, I’ll also give the first ever presentation on Infinispan JCache (JSR-107) API implementation, which will be mostly a live coding session showing different bits about JCache API and the extra capabilities JCache users get from using Infinispan implementation.

Cheers, Galder

Posted by Galder Zamarreño on 2013-04-18
Tags: conference data grids event judcon hibernate

Monday, 10 December 2012

Back from JUDCon China 2012

JUDCon China was held for the first time last week in Beijing, and it was a blast!

I had never been to China before, let alone a conference there, so it was interesting to compare it with other conferences around the world. The use of simulaneous translators meant those giving presentations in English had to pace themselves a bit more so that translators would have time to catch up. There’s was a good bunch of presentation given by native Chinese speakers too, so the audience got the chance to attend more interactive sessions too.

During this two-day developer conference, I was showing Infinispan’s capabilities as a powerful cache bulding a transactional EE application that neeeded to scale up live. In this presentation, which combines Infinispan with JSF and CDI, I showed how to go from a basic temporary cached, to a clustered cache that used consistent hashing to distribute data, showing the ability to scale up and failover. This presentation which was given shortly after the keynote on the first day generated a lot of interest in the audience, with a lot of users wanting to find out how we compared with other existing cache and data grid providers. This was a great opportunitiy to introduce the rest of Inifnispan talks that were happening that day and the day after, where they could learn more Infinsipan’s other features as a data grid: i.e. querying, geographic failover…​etc.

My second presentation that same day was about querying Infinispan based data grids. The room was packed for this one, and in the presentation I talked about how Infinispan’s map/reduce functions can take advantage of the paralellism available in cluster to resolve basic queries, and how Infinispan’s contents can be indexed using the query module and queried via Hibernate Search or Apache Lucene APIs. Finally, I did a little overview of higher level APIs offering further querying possibilities (i.e. ModeShape, Hibernate OGM). As pointed out by Ales, the lead of CapeDwarf team, I somehow forgot to add his project, which offers the possibility of running Google App Engine on top of JBoss Application Server, which uses Infinispan and offers different querying possibilities too. Don’t worry Ales, we’ll sort it out for this presentation’s next outing :)

For those who attended, the presentations should be uploaded to the JUDCon China website within the next few weeks.

Not all was presentations though, we also had the chance to socialise with attendees and other Red Hat employees in China. After all talks finished the first day, Jim Ma and Yong Yang did a fantastics demo of a cluster of JBoss Application Server 7 instances running on Rasperry PIs, and the audience had the opportunity to win one a Rasperry Pi too!

If you’re thinking of going to China, you can’t leave without trying a hot pot place! On Friday night we went to a Hai Dai Lao Hot Pot restaurant for food, and from a culinary perspective, it was the best food I had during my China stay. Hot Pot restaurants have this concept of cooking different meats, vegetables and noodles in two hot pots, one spicy and the other not. On top of that, you get the chance to mix up some cold sauces yourself (sesame oil, coriander, nuts, chillies,,etc) and mix that with the cooked meat/veg. Unfortunately, one of our colleagues who had a nut allergy had to be rushed to hospital, but it was all Ok in the end :).

From here I’d like to thank Cindy Dong, Jervis Liu, Jim Ma, Christina Lin and many others that helped us, Aliens (according to Chinese Immigration prospects), feel like at home :). Can’t wait to get back to China.

Cheers, Galder

Posted by Galder Zamarreño on 2012-12-10
Tags: conference event judcon



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