Using Byteman to Find Out Why the TimeZone Changed on a Java App Server

This article is about a real problem I faced where the timezone on a Java application server (in my case it was JBoss) changed unexpectedly during the run time of the server. It was hard to find any pattern or the reason for the change, as it was triggered by a HTTP request. To debug this scenario, I used the Byteman tool and injected the script into the JVM. This helped me to identify the root cause of the issue and come up with a few Do’s and Don’ts for a shared JVM (like on Java application servers).

Any application server is considered a shared JVM. There are multiple applications deployed on the JVM and they share the same resources. In such a scenario, there are some precautions which need to be taken care of. One of them is dealing with the JVM’s timezone.

Byteman is a tool that makes it easy to trace, monitor, and test the behavior of Java applications and the JDK runtime code. It injects Java code into your application APIs or into Java runtime methods without the need for you to recompile, repackage, or even redeploy your application. Injection can be performed at startup or in running code.

Continue reading “Using Byteman to Find Out Why the TimeZone Changed on a Java App Server”

Share

Enabling Byteman Script with Red Hat JBoss Fuse and AMQ – Part 2

In my previous article, Enabling Byteman Script with Red Hat JBoss Fuse and AMQ – Part 1, we found a basic use-case for Byteman scripts with Red Hat JBoss Fuse or Red Hat JBoss AMQ. However, the log file was generated separately and only limited operations were possible. In this article I will show you how to use a Java helper class. By using Java, we get advanced operations to view or modify the content. Also, using java.util.logging allows us to log the statements to fuse.log, avoiding the creation of any other log file.

Continue reading “Enabling Byteman Script with Red Hat JBoss Fuse and AMQ – Part 2”

Share

The GDB Python API

GDB has evolved in the last several years to provide a Python API. This series of articles will look at how a user can program GDB with the API and will also take an in-depth look at several features of that API. But, before we begin, a small history lesson is needed and a look at just why an API was needed.

Continue reading “The GDB Python API”

Share

Programmatic Debugging: Part 1 the challenge

As every developer knows, debugging an application can be difficult and often enough you spend as much or more time debugging an application as originally writing it. Every programmer develops their collection of tools and techniques. Traditionally these have included full-fledged debuggers, instrumentation of the code, and tracing and logging. Each of these has their particular strengths and weaknesses.

Continue reading “Programmatic Debugging: Part 1 the challenge”

Share

Debugging .NET on Red Hat Enterprise Linux from Visual Studio

Being able to edit your C# (or F# for that matter) code on your Linux VM from Visual Studio in Windows is pretty great. As a Windows developer, you’re able to work in an environment you know and trust while still being able to experiment — and hopefully produce production code — in Linux, where you may not be quite up to speed. Yet. Visual Studio, that familiar, productive and helpful IDE, is at your fingertips even though your code is far away in a Linux VM.

(Okay, not that far; the VM is running on the Red Hat Container Development Kit on your Windows box, but let’s call that last sentence “poetic license” and move on.)

Editing isn’t enough; we all know that. Since code sometimes has bugs (cough), we need to debug our code. Sure, we can write to a log and check inputs and outputs against expected results, but even that’s not enough. Any kinds of tests, even automated tests (you are using TDD, right? Right?) only confirm the existence — as rare as they are in your code — of defects. Finding the cause of a defect, ahhhh … there’s the rub. If only we could run interactive debugging from within Visual Studio against our compiled C# code running in our RHEL VM.

Well guess what; We can. It’s called “offroad debugging” and it’s not difficult to set up and — this is a technical term — it’s very cool. It’s a bit of work to get set up — not difficult, just several steps — but after doing it one time it becomes very easy for future projects. And never forget; if you get stuck, you can reach me on Twitter (@DonSchenck) or email me at dschenck@redhat.com.

Continue reading “Debugging .NET on Red Hat Enterprise Linux from Visual Studio”

Share

Debugging Java Applications using the Red Hat Container Development Kit

Containerization technology is fundamentally changing the way applications are packaged and deployed. The ability to create a uniform runtime that can be deployed and scaled is revolutionizing how many organizations develop applications. Platforms such as OpenShift also provide additional benefits such as service orchestration through Kubernetes and a suite of tools for achieving continuous integration and continuous delivery of applications. However, even with all of these benefits, developers still need to be able to utilize the same patterns they have used for years in order for them to be productive. For Java developers, this includes developing in an environment that mimics production and the ability to utilize common development tasks, such as testing and debugging running applications. To bridge the gap developers may face when creating containerized applications, the Red Hat Container Development Kit (CDK) can be utilized to develop, build, test and debug running applications.

Red Hat’s Container Development Kit is a pre-built container development environment that enables developers to create containerized applications targeting OpenShift Enterprise and Red Hat Enterprise Linux. Once the prerequisite tooling is installed and configured, starting the CDK is as easy as running the “vagrant up” command. Developers immediately have a fully containerized environment at their fingertips.

More information on the Red Hat Container Development can be found Red Hat Developers, and on the Red Hat Customer Portal

One of the many ways to utilize the CDK is to build, run, and test containerized applications on OpenShift. Java is one of the frameworks that can be run on OpenShift, and these applications can be run in a traditional application server, such as JBoss, as well as in a standalone fashion. Even as runtime methodologies change, being able to debug running applications to validate functionality remains an important component of the software development process. Debugging a remote application in Java is made possible through the use of the Java Debug Wire Protocol (JDWP). By adding a few startup arguments, the application can be configured to accept remote connections, for example, from an Integrated Development Environment (IDE) such as Eclipse. In the following sections, we will discuss how to remotely debug an application deployed to OpenShift running on the CDK from an IDE.

Continue reading “Debugging Java Applications using the Red Hat Container Development Kit”

Share