JMX remote monitoring on Linux
When running Java based application servers such as JBoss or Tomcat it is essential to monitor the status of the process – it’s memory consumption, threads and so on. In order to do that, Sun had introduced the JConsole application in Java 5, and now we have its successor visualvm.
In order to monitor the java process, you need to add the following system properties to the command line:
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
In the visualvm you just use the connection string host:9999.
However, sometimes the RMI listener listens to the wrong IP address, one which is inaccessible to the visualvm. Thanks to Pavel’s tip, I found a way to overcome this is by adding the following parameters:
-Djava.rmi.server.hostname=$(hostname) -Djava.rmi.server.useLocalHostname=true
Now it works like a charm!
For completeness, I’d mention you can secure the connection to the JVM, either by requiring user/password or by using SSL. If you are interested, please see this guide.
sed porting (or the little r that could)
My company is doing mainly mobile consumer applications, sold on almost every mobile platform available. In order to support them, we have servers providing various content, perform book keeping, etc.
About a year ago, we moved one of our servers from FreeBSD to Red Hat Linux. During this move, I’ve learned that not all UNIX’ small utilities were born equal. One of the tasks of this server was to receive content updates and transform them to the proper format read by our applications. All the feeds are in pipe delimited formats, since mobile clients couldn’t handle any fancy format (do I here XML?) very well.
The problem was that somewhere along the line, our content provider has changed some of the codes it uses. Since we needed to support old applications, and didn’t want to update all the applications’ code, we decided to transform the codes back to the original version while creating the new feeds. Now, the feeds at that time were plain text files, the clients would just download. In order to do that, we added a sed command to transform the codes. This command basically ran a lot of s/|1234/|5678/g and worked well, was quick, and didn’t ask for food.
Until we have moved it to the Red Hat. When this command ran on the Linux, the script froze for several minutes, and then an alarming message had appeared: sed: Couldn't re-allocate memory. Tracking the script output while running, we discovered that it tried to replace every character in the original 38,000 lines feed with the “|5678″ strings, and tried to do it about 100 times. Of course, the second s/../../g command had 5 times more characters to replace then the first, and the output was keep growing exponentially.
The fix was rather simple: we escaped the regular expressions so now they look like this s/\|1234/\|5678/g, and more importantly, we discover that if you want to use sed on Linux, you’d better add the -r parameter, which tells sed to use the extended regular expressions in the script.
Needless to mention that all is working well right now.