Thursday, 14 December 2017

First steps with Vert.x and Infinispan PUSH API (Part 2)

Welcome to the second in a multi-part series of blog posts about creating Eclipse Vert.x applications with Infinispan. In the previous blog post we have seen how to create a REST API. The purpose of this tutorial is to showcase how to create a PUSH API implemented with Vert.x and using Infinispan as a server.

All the code of this tutorial is available in this GitHub repository. The backend is a Java project using Maven, so all the needed dependencies can be found in the pom.xml. The front is a super simple react application.

PUSH API

Creating a REST API is very straightforward. But today, even if we are heavily using REST, we don’t always want to use request/response or polling, but instead we want to push directly from the server to the client. In this example, we are going to create an API that pushes every new value inserted in the default cache of Infinispan. These values are cute names, as we did in the REST API example.

We are using two features here :

  • Infinispan client listeners

  • Vert.x bridge between the Event Bus and the browser

Infinispan Listeners provide a way to the client get notified when something happens in a cache.

The Event Bus Bridge that connects to the browser, uses SockJS. SockJS is a JavaScript library that provides a WebSocket API, but it can be used with browsers that don’t support web-sockets (see the website of the project for more detailed information). Vert.x supports this library and creates a bridge between your browser and your back-end easily through the Event Bus.

Creating an Event Bus bridge

Vert.x is a reactive framework, which means that uses RxJava too, and provides a fancy API on top of it.

First, we are going to create a new verticle called SendCuteNamesAPI. This verticle extends the CacheAccessVerticle we created in the previous blog post. CacheAccessVerticle initialises the connection with Infinispan using the Hot Rod protocol.

Now we need to create a SocketJSHandler. This handler has a method called bridge, where we configure some BridgeOptions. Obviously we don’t want the client to be able to read everything traveling on the event bus, and this won’t happen. We configure an address, 'cute-names', and we add the permission to read and write to this address.

This handler is passed to the event bus route, where the path is /eventbus/*.

Finally, we create a http server as we did in the REST API example. The difference is that instead of calling listen method, we call rxListen and subscribe.

Getting notified and publishing

Using Infinispan listeners is very easy.

First, we are going to create a class that has the @ClientListener annotation. The client listener has to be added to the cache client configuration. We add a protected method called addConfigToCache that will be called just after the initialisation of the defaultCache in the abstract CacheAccessVerticle. Verticles extending the abstract class can now add custom configuration to the client.

We want to be notified when a new entry is created. In this case, our listener has to contain a method with the @ClientCacheEntryCreated annotation on it. The signature of the method has to include a ClientCacheEntryCreatedEvent<String> parameter. This parameter will hold the 'key' of the entry that has been created.

Finally, we use the key to retrieve the name using the getAsync method and then publish the value in the Vert.x event bus to the address where the socket listener is permitted to read : cute-names.

Now we can run the main method and whenever we post a new name, we will see in the logs that the client listener is notified!

Client code

We are going to create a super simple react application that will just display hello. React community is huge, so there are lot’s of tutorials out there to create a hello world client application. This application has a single component that displays "Hello".

The react application runs calling npm install and npm start  in http://localhost:9000/.

Now we need to connect the client to the backend with SockJS. Vert.x provides a JavaScript library for that: vertx3-eventbus-client, built on top of SockJS. We create an EventBus object that will connect to http://localhost:8082/eventbus as we configured in the SendCuteNamesAPI. We register a handler on the 'cute-names' address. The body of the message will contain the new cute name published in the event bus. Every time the handler is called, we update the component’s state, and it will be rendered.

Wrap up

We have learned how to create PUSH APIs with Vert.x, powered by Infinispan. The repository has some unit tests. Feedback is more than welcome to improve the code and the provided examples. I hope you enjoyed this tutorial ! On the next tutorials we will talk about Infinispan as the cluster manager for Vert.x. Stay tuned !

Posted by Katia Aresti on 2017-12-14
Tags: reactive listeners vert.x push api react

Monday, 12 October 2015

Functional Map API: Listeners

We continue with the blog series on the experimental Functional Map API which was released as part of Infinispan 8.0.0.Final. In this blog post we’ll be focusing on how to listen for Functional Map events. For reference, here are the previous entries in the series:

The first thing to notice about Functional Map listeners is that they only send events post-event, so that means the events are received after the event has happened. In contrast with Infinispan Cache listeners, there are no pre-event listener invocations. The reason pre-events are not available is because listeners are meant to be an opportunity to find out what has happened, and having pre-events can sometimes hint as if the listener was able to alter the execution of the operation, for which the listener is not really suited. If interested in pre-events or potentially altering the execution, plugging custom interceptors is the recommended solution.

Functional Map offers two type of event listeners: write-only operation listeners and read-write operation listeners.

Write-Only Listeners

Write listeners enable users to register listeners for any cache entry write events that happen in either a read-write or write-only functional map.

Listeners for write events cannot distinguish between cache entry created and cache entry modify/update events because they don’t have access to the previous value. All they know is that a new non-null entry has been written. However, write event listeners can distinguish between entry removals and cache entry create/modify-update events because they can query what the new entry’s value via ReadEntryView.find() method.

Adding a write listener is done via the WriteListeners interface which is accessible via both ReadWriteMap.listeners() and WriteOnlyMap.listeners() method. A write listener implementation can be defined either passing a function to onWrite(Consumer<ReadEntryView<K, V>>) method, or passing a WriteListener implementation to add(WriteListener<K, V>) method. Either way, all these methods return an AutoCloseable instance that can be used to de-register the function listener. Example and expected output:

Read-Write Listeners

Read-write listeners enable users to register listeners for cache entry created, modified and removed events, and also register listeners for any cache entry write events. Entry created, modified and removed events can only be fired when these originate on a read-write functional map, since this is the only one that guarantees that the previous value has been read, and hence the differentiation between create, modified and removed can be fully guaranteed.

Adding a read-write listener is done via the ReadWriteListeners interface which is accessible via ReadWriteMap.listeners() method. If interested in only one of the event types, the simplest way to add a listener is to pass a function to either onCreate, onModify or onRemove methods. Otherwise, if interested in multiple type of events, passing a ReadWriteListener implementation via add(ReadWriteListener<K, V>) is the easiest. As with write-listeners, all these methods return an AutoCloseable instance that can be used to de-register the listener.

Here’s an example of adding a ReadWriteListener that handles multiple type of events:

Closing Notes

More listener event types are yet to be implemented for Functional API, such as expiration events or passivation/activation events. We are capturing this future work and other improvements under the ISPN-5704 issue.

We’d love to hear from you on how you are finding this new API. To provide feedback or report any problems with it, head to our user forums and create a post there.

In next blog post in the series, we’ll be looking into how to pass per-invocation parameters to tweak operations.

Cheers,

Galder

Posted by Galder Zamarreño on 2015-10-12
Tags: functional listeners API

Friday, 17 April 2015

Infinispan 7.2.0.CR1 released

Dear community,

We are proud to announce the release of Infinispan 7.2.0.CR1!

This is the first release candidate of 7.2, bringing some exciting new features:

  • Faster bulk operations, putAll and getAll, for both embedded and HotRod client (ISPN-2183, ISPN-5264, ISPN-5266)

  • Cache creation and configuration changes without the need to restart the server (ISPN-5147)

  • Support for defining filters using the Query DSL for event listeners (ISPN-5349 and ISPN-5350)

  • Lock-free clear() operation (ISPN-5370)

For the complete list of features and bug fixes, please refer to the release notes

Feel free to join us and shape the future releases on our forums, our mailing lists or our #infinispan IRC channel.

Posted by Gustavo on 2015-04-17
Tags: getAll hotrod putAll listeners release candidate DSL

Monday, 09 September 2013

Infinispan 6.0.0.Alpha4 out with new CacheLoader/CacheWriter API!

Infinispan 6.0.0.Alpha4 is now with a few very important changes, particularly around cache stores. We’ve completely revamped the cache store/loader API to align it a bit better with JSR-107 (old CacheStore has become CacheWriter) and to simplify creation of new implementations. The new CacheLoader and CacheWriter should help implementors focus on the important operations and reduce the coding time. We’ve also created AdvancedCacheLoader and AdvancedCacheWriter in order to separate for bulk operations or purging for those implementations that wish optionally implement them. Expect a blog post from Mircea in the next few days providing many more details on this topic.

This new Infinispan version comes with other important goodies:

  • Rolling upgrades of a Infinsipan REST cluster

  • Support for Cache-Control headers for REST operations

  • Remote querying server modules and Hot Rod client update

  • REST and LevelDB stores added to Infinispan Server

  • KeyFilters can now be applied to Cache listeners

  • Allow Cache listener events to be invoked only on the primary data owner

For a complete list of features and fixes included in this release please refer to the release notes. Visit our downloads section to find the latest release and if you have any questions please check our forums, our mailing lists or ping us directly on IRC.

Cheers,

Galder

Posted by Galder Zamarreño on 2013-09-09
Tags: release leveldb listeners alpha rest cache store query

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 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 devnation devoxx distributed executors distributed queries distribution docker documentation domain mode dotnet-client dzone refcard ec2 ehcache 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 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 nosqlunit off-heap openshift operator oracle osgi overhead paas paid support partition handling partitioning performance persistence podcast 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 store store by reference store by value streams substratevm synchronization syntax highlighting testing tomcat transactions 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