Ok I'm now a proper convert to the WebSphere DataPower XC10
. What is in effect a simpler version WebSphere eXtreme Scale in appliance form-factor, I had just a little reservation about it. Mainly this was because I like power tools and WebSphere eXtreme Scale is certainly one of those. Whether it just be storing huge quantities of data for rapid retrieval or something more exotic like a grid-computing platform, WebSphere eXtreme Scale is just great. By contrast the XC10 appliance, is "just" a powerful, scalable in-memory data store.
However, it has a key factor in it's favour over WebSphere eXtreme Scale. It is unbelievably easy to set up, manage and maintain. Now WebSphere eXtreme Scale isn't particularly hard to run (just try the dev download
to see), but when you cluster and scale it, you do end up with quite a lot of Java processes to watch over.
I've recently set up the XC10 to run with WebSphere Commerce.
This is an excellent use case with compelling benefits
for more effectively scaling a Commerce environment. It requires no code change and very little configuration change in the Commerce environment to implement.
To initialize an XC10 from scratch, I did the following
1 - Power it on
2 - Provide a network address or 2
3 - Firmware upgrade
4 - Create a grid to store Commerce cached data (a point and click exercise)
There's simply not much more to it than that (docs
It requires little else to keep it running. It provides a nice performance monitoring interface that you'd likely check from time to time. The simplicity is just great.
One little gotcha I wanted to document...
There is a simple configuration issue that may just catch you out (as it has done me). It is specific to all dynacache XC10 use cases.
The problem is experienced as follows
1 - You can definitely ping the XC10 from the WAS environment. The catalog service domain test connection button works ok
2 - The SystemOut log files don't show errors on startup, but rather confirm that you are definitely using the XC10 for your cache instance
3 - App server requests that use dynacache take a very long time (suspiciously similar to a TCPIP timeout!)
And if you dare take a look within the trace logs of the XC10, you'll see an error hidden deep in the ffdc logs of one of the XC10 processes:
Stack Dump = org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07 completed: No
Caused by: java.net.UnknownHostException: <hostname>
Let me explain why.
It is obvious that to use the XC10 for dynacache offload that the WAS environment needs to be able to access the XC10 via the network, in other words "ping" it
It may not be quite so obvious that the XC10 also needs to be able to access the WAS environment. (If you want the details, this is because it is using data grid agents to store and access the data)
This is more than just ping the WAS nodes though. It has to be able to resolve the hostname that WAS thinks it's on to the correct IP address and then access it.
Importantly, the hostname that it is using here is the one that WAS has told it to "call back" on.
If this cannot be resolved via DNS, you have 2 options
1 - make sure WAS is started pinned to the right hostname. This can be explicitly defined in the admin console configuration of the application server, under ports. Place the correct host name in the host field (potentially replacing *)
or 2 - in the appliance -> settings menu there is an "IP addresses to hosts" section, which is a GUI equivalent to an /etc/hosts file. Simply put the host name and the correct IP address in there.
When you have resolved that, go to the troubleshooting section to try pinging that host name. If that works, you should suddenly have excellent performance in your Commerce environment again