JMS is the bread and butter of the adapter; it’s been supported even since it was first released. We use JMS as the backbone of all our community deployments; we aren’t picky about the vendor, so long as it supports JMS 1.0 then the adapter will quite happily work with it. I’ve written previously about JMS Connections and the adapter. Most of time, it just works; the problems that you might be having will be configuration based because the default behaviour just aren’t suitable for your environment.
Figuring out an obscure jetty error in the adapter
Recently our integrations team have been deploying some HTTPS enabled adapters to service some customers who wanted to POST requests into our hub infrastructure. Interestingly they encountered a problem which they came to me with. Basically, during testing with one particular customer they found that there was excessive continuous logging which ended up raising a red flag via some our file system monitoring processes (I did have a little chuckle at their work-around initially).
One of the things that we’re always asked is to provide some performance metrics for the adapter. This is always something I’m loathe to do. Raw performance numbers are almost always meaningless in the real world; it depends on too many things, the complexity of your environment, the quality of the network, what type of processing that you’re actually doing.
JMS Connections, error handling and their variations
JMS is the messaging platform that the adapter is almost always deployed against. Getting the adapter to work in a consistent way with a number of JMS Providers; some of which aren’t as compliant as others; has been key goal of ours for a long time. We’re at the stage where I’m happy that the features provided by the adapter allow us to work in a consistent manner with almost any JMS Provider.
Slow SecureRandom is always annoying; I just wish Oracle would fix their documentation
I’ve had a new virtual server (CentOS 6.x) commissioned to run as a jenkins slave. After installing all the pre-requisites on the box and configuring various build properties; I started a standard build of the framework on the machine. The build works, but it’s extremely slow.
After some investigation and isolation; we nailed it down to SecureKeyFactory.generateSecret() which is used when we decode passwords. The performance of encoding didn’t really seem to be affected, the big problem was with decoding. We tend to store all our passwords encoded in our various build properties so whenever Password.decode() was called, this would take ~30 to 40 seconds consistently.