Monday, June 18, 2012

Infinispan and Twilio integration

You have a good old JavaEE transactional application where you have done all right things such as database index, caching etc so that its performance is good. If you are really careful and want to make sure that it keeps performing well and scaling well as well, you would use Infinispan [1]. ;-) For some extraordinary reasons, imagine that when an entry gets added to the cache, you want to get notified right away. I will show you in this blog how you can integrate Twilio with cache events in Infinispan so that you get an SMS when a cache entry is created.


  • You need to create a cache event listener which is simply annotating a POJO with listener annotation and annotating relevant methods for event you are interested in.
    @Listener
    public class InfinispanTwilioCacheListener
    ...
    @CacheEntryCreated
    public void print(CacheEntryCreatedEvent event) {
    ..
    }
    
    
    
  • Register this listener to your cache, not at cache manger. See Listeners and Notfications for details.
    defaultCacheManager().getCache(CACHE_NAME).addListener(new InfinispanTwilioCacheListener());
    
    
  • Create a utility method to get SmsFactory from Twilio Rest Client.
    private SmsFactory getTwilioSmsFactory () {
    if (client == null)    
       client = new TwilioRestClient("YOUR_TWILIO_SID", "YOUR_TWILIO_TOKEN");
       Account mainAccount = client.getAccount();      
       SmsFactory smsFactory = mainAccount.getSmsFactory();
       return smsFactory;
    
    
  • Send an SMS. You would add this in your method annotated with @CacheEntryCreated
     Map smsParams = new HashMap();
     smsParams.put("To", "VALID_PHONE_NUMBER");
     smsParams.put("From", "TWILIO_PHONE_NUMBER"); 
     smsParams.put("Body", "A cache entry got created" + event.getKey().toString());
     try {
        this.getTwilioSmsFactory().create(smsParams);
     } catch (TwilioRestException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
Here is a screenshot of my phone when an SMS was sent.
Note, if you are using a trial account then you can not call or send an SMS without verification of that number which obviously makes sense. If the number is not verified then you will get an exception like : "com.twilio.sdk.TwilioRestException: The number XXXXX is unverified. Trial accounts cannot send messages to unverified numbers; verify XXXXX at twilio.com/user/account/phone-numbers/verified, or purchase a Twilio number to send messages to unverified numbers"


You can find the complete code at https://github.com/prabhatjha/infinispan-examples which is forked from https://github.com/mgencur/infinispan-examples .


[1] I work with Infinispan and JBoss Data Grid 

Monday, April 23, 2012

What does it mean to be JBoss Data Grid ??

Red Hat recently announced beta release of JBoss Data Grid (JDG) , a supported product based on Infinispan. Infinispan was first announced in 2009 and its first GA release was made in February, 2010. So it took more than three years for us, folks at JBoss, to announce a supported beta release. In case you are wondering why it took so long, here are few things to consider. Besides introducing several handy features such as virtual nodes, grouping API, deadlock detection and optimization, improvements with transactions, we wanted to make sure that it
  • can scale in a large cluster. Scalability is a very generic term and its meaning is highly contextual. For JDG, we narrowed down it to two : client scalability and data scalability.
    • Client Scalabilty:  Given a  percentage of data in virtual heap, does JDG handle more client requests as more nodes are added to the cluster? We measure throughput, 99 percentile response  time under read heavy, write heavy scenarios to verify this assertion.
    • Data Scalability: Given a fix number of clients, how much data can be filled in virtual heap while performance metrics such as throughput and 99 percentile response time are still under user defined values. This is again tested under read heavy, write heavy scenarios. 
  • is elastic. Does the cluster scale out and scale in? As nodes are added and removed, how long does it take for cluster to stabilize? This stability is measured by comparing data distribution before and after nodes leave and join.
  • is resilient. While cluster is in active use and node/s crash, what's the impact on throughput, response time? Is there any data inconsistency? How long does it take to stabilize?
  • is stable. Tests are run for long time and monitored for CPU, memory usage, number of full GC, average GC time.
This matrix gets quite complicated if you add various configurations that are available in JDG such as three different end points (Hot Rod, memcached, REST), partially versus fully replicated modes aslo known as "DISTRIBUTED" and  "REPLICATED" mode respectively,  synchronous vs asynchronous replication, number of virtual nodes, READ heavy vs WRITE heavy, L1 cache enabled vs disabled, File Cache Store, JDBC cache store, and so on. 

I have only touched the performance and scalability aspects in details. There are various other functional verification which gets quite complicated as well if you think in terms of OS+JVM+File System + DB combinations we have to certify. 

I can proudly said that we have come a long way and come GA availability, our customers will have in their hands an extremely scalable and highly available data grid platform. And I should mention linear scalability as well!! Wait should not be too long. ;-)