Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Diagnosing Application Failures in WebLogic

Diagnosing Application Failures in WebLogic

Imagine. You're designing and developing a highly complex Web-based application. This app will serve thousands, or even millions, of customers. It will be deployed on hundreds of servers. Web and application servers will interact with a multitude of third-party services, no doubt accessing internal and legacy applications as well as issuing queries to a variety of databases. Furthermore, this system will require a great many tools and frameworks (from different software vendors, no less) that will perform different tasks and interoperate with each other in a highly dynamic manner.

In a standard development cycle you'll do your best to collect all known and necessary requirements, perform system analysis, design database schemas, and define integration points. Throughout this cycle, of course, you follow existing best practice recommendations. All of this is a prelude to your application design. This process can require thousands of person-hours, and will have to be tracked through thousands of milestones, big and small. You are confident that all of the difficult decisions have been anticipated and ameliorated, that the compromises made by the myriad independent groups within your company and your outside development partners have been managed. All of us are very familiar with this process, one that requires equal parts genius and patience.

The application is then deployed.

Problems occur.

After the initial panic subsides, you begin the triage process. Unfortunately, you don't always know why the application failed, for whom it failed, or the exact nature of the failure. Your application users may be based primarily in Japan, but your servers are hosted in Arizona, the support team is on the U.S. East Coast, and development is in California. The simple fact is that even identifying exactly what happened could take days or weeks, not to mention determining the implications of the problem to the application's users.

WebLogic is one of the best homes for complex J2EE applications on the market today. It makes application development, deployment, and management very convenient. However, the application server itself can address only very common problems during the application life cycle. The reality of today's complex applications typically requires better diagnostic capabilities, particularly in post-production.

After going through this scenario more than once - being frustrated by bugs, glitches, service outages, and other sorts of problems - application architects will eventually decide to refocus their priorities to better anticipate production diagnostic. After all, the medical community has taught us that prevention is simpler than treatment. The same applies to software development. It is infinitely more efficient to prepare for problem resolution instead of waiting until problems occur. The question is, when entering the treatment phase, how can we avoid time-consuming application triage when that very application has already been shipped and is in use by customers?

This requires design of a diagnostic subsystem with the following characteristics:

  • Descriptive and unified logging for any kind of messages: This logging should cover not only the applications themselves, but also all services and components the application might access. Recording of such messages should be based on a common logging framework, application code instrumentation, and binary code instrumentation, as well as possible third-party component log data normalization to a format that makes it possible to correlate the messages that arrive from the native logging framework;
  • Good granularity of messages: When an error occurs it is very important to precisely identify the components that caused the problem, as well as the implications to the users affected by the service outage. It is very important to be able to troubleshoot each and every application module in great detail, despite the degree of complexity that is inherent in the app.
  • Highly flexible logging configuration: Easy-to-use and descriptive views into the data collected by different management components. During the troubleshooting phase, we have to keep analyzed data to manageable amounts. It is all too common to be buried by volumes of data, but still lose track of the pertinent information. Usability is a crucial issue in every application logging strategy success. Nobody wants to use disorganized data, inconveniently collected. For all application support layers it is important to intelligently escalate from triage to problem resolution, filtering out nonrelevant information. Ultimately, it is vital to deliver the relevant information, in a manageable amount, so next-stage support can begin working toward problem resolution with no additional requests.
  • Ability to support proactive problem identification and resolution scenarios: Through real-time alerts and notifications (e-mail, IM, etc.).
  • Strong integration of logging data: With incident tracking system, including descriptive reports and views.
  • Ability to support reactive problem mining: Running any business today requires compliance with high-quality standards that demand not only fixing a bug, but also determining the implications of such a bug. This includes uncovering each problem aspect, correlating the problem to all affected users, and providing necessary service to them. This goal is best addressed via highly tunable queries and data mining tools that will make all logging information collected by all your applications easily accessible.

    The most common solution today to triage problem identification is that of generic logging. Typically, the application architect selects the logging strategy used by developers to issue logging messages to event recording subsystems directly from application code. It is possible to use publicly available logging frameworks, such as log4j or java.util.logging, or to develop one in-house. Regardless of the approach taken, it is necessary to unify this logging framework throughout all applications, as well as align output from different loggers into a common format. For example, using log4j it is easy to standardize logging infrastructure, create a loggers' hierarchy, extend the logging subsystem with appenders, and manage log sources. It is critical to have control over the output of each and every logger and to be able to feed them into a single searchable repository, along with preserving all-important structured data such as timestamps, server and application names, component names, and so on. Moreover, if the application uses third-party components and services it is good practice to make those logs searchable as well. In this way, it's possible to correlate problems the application reports with records in those logs.

    The question is: Is it possible to come up with logging strategy and logging messages in the application code once and forever? A well-designed logging subsystem cannot address all possible failure points in a complex application without the risk of being overwhelmed with logging data, or over-loading the application code with diagnostic instrumentation. Even prudently designed log levels would be insufficient in segregating valuable information related to the "noise"problem. Fortunately, it's possible to construct a dynamic logging solution using on-demand automatic code instrumentation. Currently, there is a wide variety of tools and frameworks available that allow different ways to instrument the code: from source code extensions by aspect-oriented pointcuts to bytecode patching using BCEL, or via other tools such as OC Systems' Aprobe. These technologies manage architect or developer concerns at almost every stage of the application life cycle by reducing logging data to desirable amounts. Using the tools mentioned above, or equivalent techniques, it's easy to develop a set of components (or probes) that will address different types of concerns within an application and apply them only when necessary and only to important application parts. In other words, instrumentation achieves necessary logging granularity on both component and code levels. At the same time, code complexity stays constant. Developers can, therefore, clearly separate diagnostic tasks from the actual business logic that makes those tasks loosely coupled within the application code.

    The other side of the problem within the enterprise infrastructure (and probably the most mysterious one) that we need to address is that of application user behavior. Typically, use cases describe numerous scenarios of how applications are intended to be used, but there are always unanticipated use cases - a user that finds a way to bypass tested paths and is met with an application error. That's why it's very important to incorporate user session context during any logging task design and implementation. Modern application servers are well designed to isolate concurrent users from each other along with performed activities. WebLogic Server proved to be the fastest J2EE server on the market, which means it efficiently manages underlying hardware resources such as memory, threads, and sockets. Poorly written applications, however, will seriously impact even the best application server performance.

    Starting with version 2.3, the servlet specification has a nice hint for a user context problem solution. In the chapter named "Filtering," we can get a good idea of logging and auditing filters. It's really up to architects, site administrators, and application support to determine how much information about user interactions is necessarily logged. Servlet 2.3 filters allow you to dump certain request fields and parameters, along with response body, without modifying any of your servlets and JSPs. For example, TeaLeaf Technology's J2EE filter collects all information about request parameters, attributes, and other request-specific data along with the whole response body and writes it to the TeaLeaf RealiTea server for storing and post-processing. Along with data collecting, the filter creates unique context identification IDs that can be reused by downstream components for binding additional logging data. Unique IDs create a context that can be used for grouping all logging activity across all application components, which will allow the user to isolate the session that caused the problem and replay the steps that led to it.

    Making All Logging Techniques Work Together
    Servlet 2.3 API filter
    The Servlet 2.3 specification introduced filters as an integral part of the servlet container. While the specification itself states that filters are an ideal place for logging different sorts of user interaction, it is still difficult to find good examples of how to do this type of logging. Without diving into many details deserving of a separate article, our proposed logging framework is going to use Servlet 2.3 filters for the following purposes:

  • To log request information
  • To log response information
  • To introduce a unique hit ID that will be passed to WebLogic internal tracing API

    Each of these steps are fairly straightforward, based on collecting data by calling request object methods, wrapping response object methods and underlying output stream, generating globally unique hit IDs (based, perhaps, on unique hardware attributes where the program will be running and combining with the precise moment when the call occurred), and finally appending this ID to the running thread by calling the WebLogic tracing API.

    weblogic.trace.Trace.beginTrace(uniqueId); // uniqueId

    Above is the byte array that is created for each hit.

    WebLogic Tracing
    Internal WebLogic tracing allows the user to propagate any byte array data throughout calling chains inside a single JVM or across different JVMs. As I stated earlier, I will use this feature to associate each particular Web site hit with all calls that will be executed by downstream components while generating an appropriate response. In other words, it is a matter of a single function call from any method in your application to reach information about the exact Web hit that caused this method to run.

    byte uid[] = weblogic.trace.Trace.currentTrace();
    //retrieving hit id recorded on previous step

    It's now possible to add dynamicity to our logging infrastructure by using tools like BCEL, OC Systems' Aprobe, or AspectJ to actually instrument particular parts of your application with logging messages. Logging messages are required to fetch the hit ID from the tracing context described in previous sections and to add as much information as needed. Tools such as Aprobe or AspectJ allow defining pointcuts where a developer wants to insert logging messages in a useful manner. For example, in Aprobe the callback class supports the published interface and a list of methods that will be instrumented. In AspectJ, it is pointcut definition and code that will be inserted to specified methods.

    The final, and most important, component of the whole infrastructure is the system that will store all data that will be logged by all of the loggers and make it searchable. You can select different strategies, from storing data in text files and then importing them into a relational database, to logging directly to a database or using optimized logging solutions that enable storing and querying this data in real time (such as TeaLeaf RealiTea). "Glue server" is very important because tracing the context we inserted with the servlet filter, propagated by WebLogic tracing and used by logging code, will become relevant only in a central location where you can correlate data that came from your servlet hosted on Machine A to data from an EJB that is being hosted on Machine B.

    Real-World Scenario.
    Let's imagine that our application is deployed to several cluster nodes. After running successfully for a period of time, we suddenly receive several serialization notifications from the replication subsystem.

    Those messages contain information that some object cannot be serialized. Using standard logs provides little insight into the exact context of this problem. We don't know what servlet or JSP code attempted to insert invalid attributes into session context or, more important, exactly which object is not serializable. To simulate the problem described above we can use a simple chunk of code that simply counts visits to a page; inserts a serializable object into session context each time it is accessed, increasing the counter; and only on hit #3 will it insert an object that has a nonserializable member:

    <%@ page import="dummy.*" %>
    Integer i = (Integer)session.getAttribute("counter");
    int iv = (i==null)?1:i.intValue()++;
    session.setAttribute("counter", new Integer(iv));
    if(iv==4) {
    TRIBUTE", new MyData());
    <html><body><h1> Counter = <%=iv%></h1></body><html>

    Let's make our example a little more complex by making one of the MyData members (MyInternal) nonserializable:

    package dummy;
    import java.io.Serializable;
    public class MyData implements Serializable {
    String str = "dummy string";
    MyInternal mi = new MyInternal();
    And MyInternal source code:
    package dummy;
    public class MyInternal {
    Object o = new Object(); // this is
    non-serializable member
    String str = "string";

    Real-world situations can easily be even more complicated - dynamic page code could be much more complex; session attribute insertion could be less straightforward; the application could use a controller that glues together different presentation, model, and data access components. All that could tremendously complicate problem diagnosis and resolution.

    To solve this problem we can use TeaLeaf's filter component in conjunction with WebLogic's tracing capabilities and code instrumentation. The only steps required are to install the filter on our application (this step has to be performed only once per application), make WLS run using tracing (Dweblogic.TracingEnabled=true), and configure the instrumentation patch. The filter in this scenario is performing the following tasks:

  • HTTP traffic logging (request and response data, including HTML/XML, served back to the client);
  • Creating and binding tracing context for application servlet and downstream components that will be called from the servlet;
  • Feeding all data into TeaLeaf RealiTea Server, allowing the user session to be replayed and making the entire session searchable and accessible in realtime. Alternatively, the RealiTea Server could record all of the data into log file format locally on the server.

    WebLogic tracing provides logging code and instrumentation patches with unique context identifiers that can be accessed from any downstream component and that can propagate the context across JVM boundaries in case of RMI calls.

    For code patching in this example it is possible to use OCSystems' Aprobe, BCEL, or even AspectJ. The main idea is to add additional verification to the method that verifies each and every object before writing it to a stream (weblogic.common.internal.RemoteObjectReplacer.replaceObject) if it is serializable, and proceeding with event issuing if it is not:

    if(returnValue instanceof Serializable)

    In case of verification, it's necessary to extract the current call trace context using the WebLogic tracing API and join a logging message to the request/response data logged by the filter:

    byte b[] = weblogic.trace.Trace.currentTrace(); // get logging context
    if(b!=null && b.length==64) {
    sid = new String(b,0,32); // get unique session id
    hid = new String(b,32,32); // get unique hit id
    // record an event with your favorite logging API
    logger().error(sid, hid, "SERIAL_FAIL",

    Finally, we have to instrument the application and let it run. After executing a four-hit session we can find the following information logged (in the example I'm using RealiTea Viewer, TeaLeaf Event API and capture filter; see Figure 1).

    Now we find that the problem is happening exactly on hit number 4 of this session. We also clearly see that the object that cannot be serialized is an instance of MyInternal class, and that all request and response data sent to the WebLogic Server by the browser and generated by the servlet is captured automatically via the filter. In short, we can now easily find each and every user affected by the same problem after the fact (see Figure 2).

    Having logging filters installed and running on your production servers and your centralized logging system, combined with custom logging instrumentation, will significantly reduce the time required to diagnose serious application problems. This process is further improved by constantly monitoring complex Web applications through the initiation of proactive alerts and notifications. On the other hand, a full record of user interactions will help address not only technical problems, but also the business issues and implications of how application failure affects all site users.

  • More Stories By Vitaliy Stulski

    Vitaliy Stulski is Java Developer and Architect at TeaLeaf Technologies, a provider of solutions to help businesses ensuring the accuracy of their Web applications.

    He has extensive experience in the design and development of large, highly scalable, distributed enterprise applications based on J2EE platform. Vitaliy also has several years of experience with BEA products, especially with WebLogic Application Server.

    Vitaliy holds a Master’s Degree in mathematics University in Minsk, Belarus.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    @ThingsExpo Stories
    Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
    DXWorldEXPO LLC, the producer of the world's most influential technology conferences and trade shows has announced the 22nd International CloudEXPO | DXWorldEXPO "Early Bird Registration" is now open. Register for Full Conference "Gold Pass" ▸ Here (Expo Hall ▸ Here)
    Join IBM November 1 at 21st Cloud Expo at the Santa Clara Convention Center in Santa Clara, CA, and learn how IBM Watson can bring cognitive services and AI to intelligent, unmanned systems. Cognitive analysis impacts today’s systems with unparalleled ability that were previously available only to manned, back-end operations. Thanks to cloud processing, IBM Watson can bring cognitive services and AI to intelligent, unmanned systems. Imagine a robot vacuum that becomes your personal assistant tha...
    "MobiDev is a software development company and we do complex, custom software development for everybody from entrepreneurs to large enterprises," explained Alan Winters, U.S. Head of Business Development at MobiDev, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    I think DevOps is now a rambunctious teenager - it's starting to get a mind of its own, wanting to get its own things but it still needs some adult supervision," explained Thomas Hooker, VP of marketing at CollabNet, in this SYS-CON.tv interview at DevOps Summit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    Recently, WebRTC has a lot of eyes from market. The use cases of WebRTC are expanding - video chat, online education, online health care etc. Not only for human-to-human communication, but also IoT use cases such as machine to human use cases can be seen recently. One of the typical use-case is remote camera monitoring. With WebRTC, people can have interoperability and flexibility for deploying monitoring service. However, the benefit of WebRTC for IoT is not only its convenience and interopera...
    Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...
    It is of utmost importance for the future success of WebRTC to ensure that interoperability is operational between web browsers and any WebRTC-compliant client. To be guaranteed as operational and effective, interoperability must be tested extensively by establishing WebRTC data and media connections between different web browsers running on different devices and operating systems. In his session at WebRTC Summit at @ThingsExpo, Dr. Alex Gouaillard, CEO and Founder of CoSMo Software, presented ...
    WebRTC is great technology to build your own communication tools. It will be even more exciting experience it with advanced devices, such as a 360 Camera, 360 microphone, and a depth sensor camera. In his session at @ThingsExpo, Masashi Ganeko, a manager at INFOCOM Corporation, introduced two experimental projects from his team and what they learned from them. "Shotoku Tamago" uses the robot audition software HARK to track speakers in 360 video of a remote party. "Virtual Teleport" uses a multip...
    Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
    Data is the fuel that drives the machine learning algorithmic engines and ultimately provides the business value. In his session at Cloud Expo, Ed Featherston, a director and senior enterprise architect at Collaborative Consulting, discussed the key considerations around quality, volume, timeliness, and pedigree that must be dealt with in order to properly fuel that engine.
    IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
    When shopping for a new data processing platform for IoT solutions, many development teams want to be able to test-drive options before making a choice. Yet when evaluating an IoT solution, it’s simply not feasible to do so at scale with physical devices. Building a sensor simulator is the next best choice; however, generating a realistic simulation at very high TPS with ease of configurability is a formidable challenge. When dealing with multiple application or transport protocols, you would be...
    Detecting internal user threats in the Big Data eco-system is challenging and cumbersome. Many organizations monitor internal usage of the Big Data eco-system using a set of alerts. This is not a scalable process given the increase in the number of alerts with the accelerating growth in data volume and user base. Organizations are increasingly leveraging machine learning to monitor only those data elements that are sensitive and critical, autonomously establish monitoring policies, and to detect...
    In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an overview of the evolution of the Internet and the Database and the future of their combination – the Blockchain. Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settl...
    In his session at @ThingsExpo, Dr. Robert Cohen, an economist and senior fellow at the Economic Strategy Institute, presented the findings of a series of six detailed case studies of how large corporations are implementing IoT. The session explored how IoT has improved their economic performance, had major impacts on business models and resulted in impressive ROIs. The companies covered span manufacturing and services firms. He also explored servicification, how manufacturing firms shift from se...
    DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of bus...
    The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
    IoT solutions exploit operational data generated by Internet-connected smart “things” for the purpose of gaining operational insight and producing “better outcomes” (for example, create new business models, eliminate unscheduled maintenance, etc.). The explosive proliferation of IoT solutions will result in an exponential growth in the volume of IoT data, precipitating significant Information Governance issues: who owns the IoT data, what are the rights/duties of IoT solutions adopters towards t...
    Amazon started as an online bookseller 20 years ago. Since then, it has evolved into a technology juggernaut that has disrupted multiple markets and industries and touches many aspects of our lives. It is a relentless technology and business model innovator driving disruption throughout numerous ecosystems. Amazon’s AWS revenues alone are approaching $16B a year making it one of the largest IT companies in the world. With dominant offerings in Cloud, IoT, eCommerce, Big Data, AI, Digital Assista...