BigAdmin Java Collection
Java Monitoring and Maintenancelast updated August 2007 This hub provides information on prior releases for your reference. Until this hub is updated for newer releases, please refer to java.sun.com for the most current product information. A running Java application is not a car, so what do we have to maintain? This is software, right? Software does not wear out, parts do not corrode, wear-down, or physically break. But we know from experience that things change with time, and problems appear, so there is maintenance of a sort that we can and should be doing - for both Java-based applications and any other kind. This page discusses maintenance, dividing it into a few areas:
Content
Monitoring a Java Virtual MachineWe can monitor our Java-based application in a number of ways. The standard Solaris or OS-specific tools you know for checking system utilization are all relevant. The JVM is a process with many similarities to all other processes...
Additionally, the JVM has a number of command-line options to monitor its status by logging to its standard output, usually captured in a log file for server processes. GC statistics are possibly the most common to see, e.g. " The obvious question is then, "What are the options to set, and what do the values printed mean?" Well, there are many documents over on java.sun.com that discuss the topic of GC specifically, including: Tuning Garbage Collection with the 1.4.2 Java Virtual Machine. Then we have additional monitoring tools, that ship with the JDK. In Java 5 and onwards, with the introduction of JMX, there are rich graphical tools as standard:
Further details in the Troubleshooting tab - there exists a fine line between what is a monitoring activity, and what is a troubleshooting activity. Release Model and Update Releases
We often crave stability in a production environment, and when something goes wrong can sometimes state, "Nothing has changed!" Well, we have made no specific changes, but time has moved on... Discovery of new bugs is a major change with time, along with fixes for those bugs. This is the active maintenance that Sun is doing with regards to Java technology, and that any software vendor performs for their product. These are the fixes which appear in maintenance releases (that underscore and number after the version number, e.g. 1.4.2_13, 1.5.0_08). We can perform a crucial piece of maintenance by striving to be up-to-date with regards to these maintenance releases. Sure, we want to read the release notes of any update release to see what bugs are being fixed, and if special care needs to be taken. For some environments it may feel appropriate to make no changes at all, but the update releases are there for those that can use them! We are all familiar with updating the kernel patch on our production servers, and need to be familiar with, and have a strategy for, keeping the Java version up-to-date also. Sun is doing the actual maintenance, so we want to take advantage of it wherever we can. Testing is key also: we want a test environment where we can test the deployment of a new updated JVM, or test new startup parameters. We have heard the words "change control" used to limit flexibility in applying updates, but we need to focus on controlling, rather than eliminating! Release NotesThe documentation that comes with every JRE/JDK is easy to overlook when on a tight time schedule. However, this is where you find exactly what changed in each update release: the changes are documented with a "bug" id. Sun AlertsBug fixes are delivered into the Java environment through update releases. But there can be problems, usually security-related, that have an urgency meaning we should be aware of them before that update release is available. There can be workarounds to known problems before a final fix is delivered. We are made aware of these through the Sun Alert mechanism. Application ChangesThe demands on the application change also: more transactions, larger datasets. This increased burden can expose problems with the application if we enter territory that has not previously been tested. Resourcing decisions made previously can become outdated by this evolution, for example impacting heap memory usage, where we would need to be aware of heap utilization over time. A straightforward set of appropriate monitoring tools needs to be adopted. So, as with the Update Release situation, where new bugs can be exposed over time, the application code can remain static, and the changing usage profile can expose new issues. With suitable monitoring, we can assess what has actually changed, quickening our diagnosis. Breakdowns and SupportEven well-maintained vehicles have been known to have breakdowns. Let's just review what the service personnel want to hear. On contacting either Sun or a 3rd party vendor, you are going to demonstrate entitlement to support. This should be as simple as a contract id of some kind, although with Sun be careful that owning piece of Sun hardware running Solaris does not entitle you to support for that Linux PC in the server room running Java. Previously, you needed a Java on Multiple Platforms contract for that. Find current support options available through Java SE for Business. What the service personnel frequently want to hear, is whether or not your issue is experienced on the latest version of the software. This is about ruling out some large number of possible bugs straight away. Can we say very quickly that you have a new issue? If so, let's get that clarified. (Surely that makes it more interesting for the support personnel too?) If there are fixes in the area of this current problem addressed in a later update release, should we try that latest update release? Reproducing a problem can be a fantastic aid to finding its root-cause and resolution. A test environment, that we already want for testing update releases, can be used to attempt to replicate a problem. 3rd party components? Yes, they need this kind of attention also. We may have Java libraries, or native libraries, back-end databases and web browsers. Support from Sun
Major Upgrades - Migration GuidesThere comes a time to change from one major version of Java to another, and there exist some documents to help with this process. This document is perhaps mainly for the developer. In many instances, an application ships with a copy of the Java Runtime Environment it wishes to use, and installing a later version may involve installing a later JRE as part of that install, with no noticeable Java "migration". End of LifeSoftware products have a finite life, during which the vendor offers support. Applications, Operating Systems and Java all have this pattern. It is likely that a product running on some version of Java will itself be updated to a version that supports, or requires, a later version of Java - in these cases there will not be an issue as to the version of Java itself reaching the end of its life. Some environments are stable for many years, and in these cases the JDK in use can reach the end of its life. For support beyond the expected life, a Vintage support offering exists from Sun. Older versions may require a Vintage support contract. (JDKs do not actually expire, as they will not "time out" at the end of life: this simply affects the delivery of updates, i.e., delivery stops.) TrainingAre you maintaining the staff that maintain your Java based product or service? Community ResourcesForums are frequently useful for assessing problems that exist in an area. Is this a vendor ducking the issue? No, it's raising the now common strategy of using a wider community to find out whether your problem is unique to you. Even being aware of problems others in the community have experienced can mean we are forewarned of problems that could be relevant to us. |
 
BigAdmin SubscriptionsBigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics | ||||
| |
