Posted by Sander Hautvast mid-morning: August 20th, 2010
This is number 8, the third article in a top10 of middleware management pitfalls. The previous article dealt with infrastructure. This time I´ll discuss the application itself.
There has been much cool stuff lately about devops and devs and ops working together in one team, like at sky.com. The uncool reality for a lot of companies is that dev and ops are separated in different departments and don´t communicate well. Immature applications, at least from a middleware perspective, are what you get.
Posted by Sander Hautvast mid-afternoon: June 4th, 2010
In this episode of the middleware pitfalls top-10 we want to discuss the merits of a clean and standardized set of (test) environments. Some refer to such a set as DTAP, an acronym for Development, Test, Acceptance-test (or pre-production) and Production. From here on the text contains capitals to indicate an environment. Basically the situation is like testing itself: you will never get it 100% right, but it will help you a lot if you invest in a sound, maintainable DTAP.
Posted by Sander Hautvast in the early morning: May 12th, 2010
This is the first blog in a series that describes the top 10 of Java EE middleware management problems. It´s title could also be “single point of failure”. This is not about software. Instead, it’s about the person in your middleware team that everybody relies on, and clings to when things get difficult or even worse, get totally out of hand.
Posted by Sander Hautvast mid-morning: April 28th, 2010
What is ‘middleware’? French professor Sacha Krakowiak defines middleware
as [a] software layer [which role] is to make application development easier,
by providing common programming abstractions,
by masking the heterogeneity and the distribution of the underlying hardware and operating systems,
and by hiding low-level programming details
This makes sense, considering the fact that writing an http server nowadays or a servlet-container is not considered sane anymore, given the multitude of commercial and open source products that have already proven themselves. Over the years a range of products and standards has emerged that to a growing extent hide the low-level intricacies and provide the application programmer with easy yet powerful abstractions. They range from webservers, databases and application servers to EBS´s and BPM platforms. They form the IT landscape that enable modern business. And it´s their heterogeneity and distribution that is at the heart of the emerging problems that we will address in a top-10 style series of blogs in the coming weeks.
(more…)
Posted by Sander Hautvast at around evening time: June 30th, 2009
In this series I want to address some topics that are old and well known, but still seem to puzzle developers and administrators in a j2ee environment. Think of anything in or around an application server. When talking of application servers I mostly refer to websphere. Sadly I have no real experience using any other. Yet I aim to keep a broad perspective, not to narrow the audience. The level should be beginner to intermediate.
Part1 Starting your own threads.
As long as I worked with application servers, people have always told me not to start my own threads, because the j2ee specification states that this is forbidden. These threads are also referred to as ‘naked’ and ‘unmanaged’. The danger they pose is doing things that the application server knows nothing about. It could cause resource leaks, no debugging, failing to stop a server or security problems.
Yet there is a number of open source frameworks that do just this, and no one seems to object. Think of quartz, or Log4j (the watchdog that monitors changes in log4j settings). And even the jdk itself is guilty: use of java.util.Timer also causes so called unmanaged threads.
Posted by Sander Hautvast in the early evening: April 10th, 2009
Logging should be simple and straightforward. It is an essential part of everyday administrative operations and it provides vital information for debugging production incidents. Adequate logging saves time and money. When hosting a number of applications, say 10+, you will want to separate application logs from each other and from platform logs and traces. Logging frameworks like the jdk logger and log4j, cooperating with the j2ee container provide the means to do this, using configuration files. So far, so good.
(more…)
Posted by Sander Hautvast at around evening time: February 10th, 2009
A colleague asked me whether jconsole could connect to a running IBM Webpshere 6.1 instance. This way you could gather performance data and work with Mbeans like with any other 1.5+ JVM. I had never tried this, but I quickly saw that jconsole is provided with the websphere jvm, so I said I would give it a try.
The forum posts all complained that it wasn´t possible, but I combining several entries I got together a working solution. This is typical of websphere, it´s a little harder, but in the end you can get there.
(more…)