HTTPS Jetty error

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).

Performance testing the adapter

Performance Metrics for the adapter

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 in the adapter

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 Java Crypto Performance on Linux

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.

It’s SecureRandom again isn’t it

To Build or Not to Build

Why I think a build step is critical for project collaboration

I started doing Assembly, then C, dabbled in COBOL for a while so I’ve always had to have a build/compile step as of my development workflow. Working with Java hasn’t been anything different, you use ant or maven to compile your source files and then run your tests. Lately I’ve been reading more and more about people hating java and their myriad reasons for that. I don’t think I have anything to add around that subject other than more invective so I shan’t. I happen to know few languages and I just choose the best one for the job at hand, just do the work. Java has it’s idiosyncrasies, but if your reason for hating java is that until recently you couldn’t do a switch statement with Strings; you shouldn’t hate java, you should hate yourself for being a programmer who likes switch statements ;).

Pagination


© all-the-years. All rights reserved.

Powered by Hydejack v9.2.1