/dev/websphere

Video podcast on handling inconsistencies when using WebSphere Extreme Scale

This video podcast covers the issue when an application uses cached data in WebSphere Extreme scale and then a third party application updates that data without going through Extreme Scale. It covers how the inconsistency arises and then how the application must be coded mechanically to deal with the inconsistency. It also covers whether using a database trigger with invalidation messages solves the inconsistency or not.

You can watch a streamed version here.

Download websphere_extreme_scale_weekly_podcast_medium.m4v

Does ObjectGrid need WebSphere Application Server for its operation? NO

I get emails from customers saying they understand that ObjectGrid (WebSphere Extreme Scale) requires WebSphere Application Server for high availability because they heard it uses the HAManager and that other competitive products are peer to peer out of the box. This is just not true. ObjectGrid in no way requires any piece of our application server to be installed to perform any core capability. Everything is inside that one jar (objectgrid.jar) that ships with the product when you want to use it with straight J2SE or Tomcat.

ObjectGrid offers full peer to peer fault tolerance, high availability when used in a J2SE environment. The product is called WebSphere Extreme Scale purely because of branding within the company. It in no way implies that our application server is required for ObjectGrid to perform any of its capabilities. We have done work to integrate it with our application server pretty tightly but this work in no way means that it is any less capable when running in straight J2SE or competitive platforms like Tomcat etc.

Why would someone use WebSphere Application Server (ND) with ObjectGrid installed on top? Lots of reasons. The customers operations staff may be familiar with the application server and would naturally want to manage ObjectGrid using the same skill set. If this is what you want then you can package your ObjectGrid application into a conventional WAR or EJB module and deploy it to an ND cell and then manage it just like any other JavaEE application using the same skill set. They can then use PMI to monitor metrics from ObjectGrid using the ND console. ObjectGrid can integrate with WebSphere security which makes it easier to manage if you're already a WebSphere customer. If you're using smaller grids (<50 JVMs) then this is a very attractive approach.

If a customer wants extremely high performance HTTP session replication then we recommend running ObjectGrid within WebSphere ND. But, we'd recommend the same thing to a Tomcat customer looking for the same high performance session replication for their Tomcat application. The same ObjectGrid code is working in both.

Why would you use ObjectGrid in J2SE mode in a WebSphere ND shop? If you want a Java 6 virtual machine for hosting the ObjectGrid data then this makes using ObjectGrid in a J2SE mode mandatory if you are using any version of WebSphere below 7.0 (which includes Java 6). If the grid needs to scale to more than around 50 JVMs then I'd recommend running it in a J2SE environment purely because it's easier to manage, ObjectGrid scales to well over a thousand JVMs and around 2 TB of data (32 bit JVMs) with no administration necessary as you scale it up, just start more JVMs. If 64 bit JVMs are used then more data can be stored. The applications running in the application server can connect to the grid over the network in this mode.

If anyone has questions then please comment here or post a thread on our forum.

ObjectGrid 6.1.0.4, new stuff in xsadmin.sh

We added a mapsizes argument to xsadmin.sh in 6104. You can use this to show the number of records in shards in the grid. For example:

./xsadmin.sh -g Grid -m mapSet -ch localhost -mapsizes

This will attach to a local catalog server and show the number of entries in every shard in the grid as well as the total record count. This will include replicas. It shows each container and within that each shard (primaries and replicas) with the entry count. Finally, it adds it up for a total. You can use the filter arguments to filter to just entries on a single host:

./xsadmin.sh -g Grid -m mapSet -ch localhost -mapsizes -fh server2.rchland.ibm.com

or to a specific partition using "-fp 5" or to a specific map using "-fm myMap". We're adding a new filter for shard type, this is coming very soon now in an update. This will allow you to just see entries in primaries or in replicas.

If you have anything that you want added to it then feel free to comment here or email me.

WebSphere ND 7.0 ships, cool feature: 64 bit pointer compression

WebSphere ND 7.0 shipped this month and one of the features I've been waiting on is the new IBM Java 6 virtual machine. The 64 bit version has a very cool feature called pointer compression. A lot of customers ask about 64 bit support, I get this a lot with WebSphere Extreme Scale (ObjectGrid). The trouble with 64 bit JVMs is that the pointers are all 64 bit and typically customers report their physical memory usage doubling for the same JVM heap size when they go 64 bit. This means that it can take 4Gb of memory to store a 2 GB 64 bit heap which is almost double what it took on 32 bit JVMs. This is the case (AFAIK) with competing JVMs etc today.

The new IBM Java 6 JVM has pointer compression which finally helps with this issue. This allows customers running on the IBM JVM to only use 2Gb of RAM with a 2Gb heap on 64 bit. This can be a massive benefit for ObjectGrid customers and for customers consolidating multiple servers on to boxes. 64 bit applications can now be consolidated with paying a huge memory overhead.

This feature should give platforms with the IBM JVM a pretty major cost advantage and performance advantage over running on platforms without an IBM JVM available.

You can download a trial version from here.