Leading-Edge Java

Small Bugs with Big Implications

An Interview with IBM's Mark Thomas from JavaOne 2007

by Frank Sommers and Bill Venners

August 10, 2007

 

Summary

Small bugs can sometimes lead to significant failures, especially when those bugs manifest themselves in production code. In this interview with Artima, Mark Thomas, Director of Java Technologies at IBM, talks about the potentially big implications of defects that are discovered only in a production environment, and what developers can do to discover and mitigate such problems.

 

In spite of thorough testing and following the best development practices, bugs can still seep into production applications. Such bugs are not only very difficult to detect, but can also cause downtime with significant consequences to a business.

 

Artima spoke with Mark Thomas, Director of Java Technologies at IBM, about the challenges of detecting relatively small problems whose implications are magnified by a chain of interconnected businesses and customers. In the interview, Thomas also talks about IBM's tools and technologies for managing production applications.

 

††† Sometimes there could be huge downstream implications and issues that result from quite small failures.

 

††† Recently, I was in China, and this was a client that was facing very occasional system failures. Perhaps once a month, not much more often than that. But the implications, because of the customer's business and the nature of their customers' interactions, could affect tens of thousands or hundreds of thousands of people, for days. Even though the system downtime, due to the magic of high availability and failover and all those kinds of things, the system would only be down a few minutes... So these could be very big events, even though they result from very small bugs or very small issues...

 

††† The common factor that comes out of all of that is that these are bugs that are found after, what one would hope, was extensive testing. Many good developers will do proper testing, they'll have unit tests, and the company or the environment in which they work will also have integration tests, fairly good user tests, very comprehensive sets of testing. But we still find failures that occur once you go into production.

 

††† Those [failures] might be due to an environment change or might be due to some latent defect in some part of the stack. But usually the [common] characteristic is that you won't find [those defects] by single-stepping, and it will come through an application that a lot of good developers [tested] before releasing their code.

 

††† Once you're in production, nobody is going to let you run a debugger in that production environment. So it comes down to: How can you make it easy to find the root causes of those problems?

 

What techniques have worked for you for finding bugs in code already in production?

Post your opinion in the discussion forum.

 

About the authors

 

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.

 

Bill Venners is president of Artima, Inc. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.

 

Scaling with Rich Clients - Leading-Edge Java

An Interview with Xoetrope's Val Cassidy from JavaOne 2007

by Frank Sommers and Bill Venners

July 5, 2007

 

Summary

Rich clients can not only provide more interactive, desktop-like, user interaction, but also have the ability to cache significant amounts of application data on the client and perform processing on that data. In this interview with Artima, Xoetrope CTO Val Cassidy explains how client-side data processing can help scale an enterprise application.

 

Rich-client user interfaces are often motivated by the desire to offer users a more interactive, even desktop-like, way to use a Web application. Rich clients, however, can also be a mechanism to allow an application to scale to a larger number of users.

 

While Web applications traditionally perform all processing on the serveróboth processing of business data and processing of the generated HTML outputórich-clients can relieve the server of some of that processing. A simple example of client-side processing is sorting data on the client. The more data is made available on the client, more processing can be pushed to the client, making rich applications rich not only in the sense of user interface elements, but also because significant amounts of data is cached in the client.

 

Irish start-up Xoetrope used that sort of richness to help scale a popular open-source PHP application, Sugar CRM. By providing a rich-client Java client to Sugar CRM, Xoetrope allows a Sugar installation to serve more users, since the rich Java client reduces processing on the server, according Val Cassidy, CTO of Xoetrope. Cassidy pointed out in an interview with Artima that:

 

††† What's created on the back-end is HTML that we can read and transform into XML that will then drive our rich Internet application, which is Java-based. Within our XUI framework, the engine that runs [the client] is based on an XML description that hooks back into the Java logic. It's a very flexible way of working with metadata and pushing it out to the rich client...

 

††† Most of the work is being done on the client, caching is taken care of [on the client]. You are not serving up the HTML that's displaying the application. So you're taking a huge load off the server. The end-result is that your server can serve more clients. The client machines perform better, and can also start interacting with the desktop...

 

Cassidy also noted that this technique requires some extra care from developers: Because each client caches potentially identical data items, the system must check for, and handle, update conflicts:

 

††† You would do concurrency checking of the data. It's really up to the developers to decide how they handle that, whether to present the conflicts back to the user and let them decide how to handle them, or work with them on the server [and] cache them for an administrator to work with that later.

 

What do you think of Xoetrope's client-side caching approach to scaling an enterprise applications?

Post your opinion in the discussion forum.

 

About the authors

 

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.

 

Bill Venners is president of Artima, Inc. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.