While studying Java in college, Eugene had the great misfortune of being hired by a company that specialized in Java Swing applications. (For those of you who don’t know, Swing is a cross-platform framework for desktop GUI applications.) He was quickly swept aboard a new project: taking a new client’s poorly-implemented, buggy, and unstable PHP website and upgrading it to a new, clean, Java-based version.

The team quickly stumbled into a major roadblock. “This has to be a web application?” questioned Rob, the team lead. “You can’t do web with Swing. Why don’t we just write them a Swing application?”

a swingset

“They want a website, not a desktop application,” was the response from the salesman.

And so the team set out on a quest to learn web development…

AjaxSwing

Rob soon found a workaround for their dilemma. “I found something that will make web development easy for us!” he announced to the team. “It’s called AjaxSwing, and it converts Swing programs into web applications! We don’t have to learn web development after all!”

Eugene was a fairly green developer but even he knew this was a terrible idea. But as the newbie student programmer, he had no say in the matter, and soon found himself thrust into the horrid bowels of a wretched new beast. One that abused a tool designed to quickly shove legacy applications onto the web, instead using it as a core framework on a brand-new application. One that launched a separate, headless JVM process for each user. One that did terrible, unspeakable things with Reflection to replace Java’s internal Swing classes with ones that convert them to remote HTML/JavaScript entities in a web browser somewhere else.

The new application was a monster. It had complex features and requirements and the team was continuously bumping into limitations of AjaxSwing. Eugene, being a mere student with the lowest pay, often got selected to work long hours dealing with these issues. He spent a fair amount of time handling customer reports, debugging, and forwarding bug reports on to the AjaxSwing team. To their credit, they worked with him to solve these.

Finally, the application was completed and delivered to the client.

Random Crashes

Shortly after deployment, the customer began complaining about random crashes in the application. Something occasionally happened that disconnected everyone from the application. They soon figured out that having the hosting company reboot the server would bring the application back, but eventually it would die again, sometimes after a few hours, sometimes after a few days. Meanwhile, Eugene’s team started adding performance logging and tracing to try to narrow down the cause.

After a couple weeks of monitoring, Eugene came into one of their emergency customer support meetings slightly late but armed with a new bit of knowledge. “I found something in the server logs. Someone is actually terminating all the JVM processes used by the site.”

Rob frowned. “Why would someone do that? Call the customer and tell them not to do that anymore!”

And he did. The customer claimed they never did anything directly with the server, so maybe it was the hosting provider’s fault? But the hosting company claimed that no, they don’t randomly log into customer servers and kill processes.

This continued for months. Everyone got used to the status quo and simply learned to live with it. Eugene continued monitoring and logging, but got no additional details. Someone somewhere was killing the JVM process and refusing to admit to it.

The Cause

Months later, he received an enlightening email from the hosting provider.

Eugene,

We've finally found out what's killing the JVM processes on [redacted]'s web server. The remote desktop software we use for maintenance kills all processes belonging to the user when he logs out. Your application is configured to run as the admin user, so when an admin does server maintenance and updates and logs out, the JVM gets killed.

I suggest you work with with the customer to run the application with a non-privileged user account.

Thanks,
[redacted]

Eugene and the customer attempted to fix this, but the application did Very Bad Things™ and refused to run unless it was using the admin account. The hosting company agreed to quit using their remote desktop solution on this particular server, and instead use the stock Windows RDP client. Meanwhile, Eugene graduated college and decided to move on.

The Fix

Eugene soon found himself employed full-time at a web development company, one that specialized in building JavaServer Faces (JSF) web applications. Shortly after starting, he was quickly swept aboard a new project: taking a new client’s poorly-implemented, buggy, and unstable AjaxSwing web application and upgrading it to a new, clean, JSF-based version…

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!