DEV Community: FusionReactor

Why are multithreading and multiprocessing used?

FusionReactor — Tue, 09 Feb 2021 15:01:50 +0000

Why are multithreading and multiprocessing used?

Simultaneously executing programming tasks before now had always been daunting. But today, many programming languages support Multithreading and Multiprocessing, which aids concurrent execution of code.

Multithreading and Multiprocessing solve this problem by providing a technique whereby different tasks can be managed simultaneously from a central system. However, as progressive as these techniques are, they are not all-encompassing as they both have their limitations and advantages over each other.

Hence, it is critically necessary for you to know each of them’s limitations to aid your focus. Some of such critical areas include; The number of threads available when the code is running. Also, the duration and number of tasks that are being executed. All these and many more will be addressed while accessing the multi-threading process and multi-processing. The previous article highlighted a high overview of what Multithreading and Multiprocessing are and how they help developers.

What is Multithreading?

Multithreading is an operating system’s capacity to monitor its use by more than one user and handle multiple requests by the same user without running numerous copies of programming on the computer. As the name implies, Multithreading utilizes threads that are individual lines of codes or execution units in the computer system to execute multiple tasks concurrently. These threads share the resources of a single core or a core in a numerous core operating system, including the computing units, the CPU caches, and the translation lookaside buffer (TLB).

This concurrence cumulates into a system processing technique that is fast, reliable, and efficient. It achieves this in the following ways:

Resource Sharing: multithreading processes share resources via: ‘message passing’ and ‘shared memory.’ Most languages allow threads to share memory and resources of the process they belong to by default.

Economic: Multithreading is a time and energy-efficient technique in programming. The allocation of pooled memory and resources to different threads in the same process limits the time, space, and resources needed to execute a task.

Scalability: Multithreading increases parallelism as the threads can be distributed over a series of processors to scale, dividing the processes into smaller tasks.

Responsiveness: Multithreading provides better interaction with the user as it allows a program to continue running irrespective of whether a part of it is blocked or performing a lengthier operation.

As advantageous as the multithreading technique presents itself, it is not without its limitations. First, memory and resources are shared, affecting the threads’ safety as the concurrence can make the data from one into the other. Another issue to look out for is deadlocking. Here two threads wait to complete their operation, and this delay usually results in the program failing. For these situations, it is important to have tools in place (such as FusionReactor) to alert you to these situations.

Finally, it could result in a ‘race condition’ where two threads simultaneously access a shared variable. The first thread reads the variable, and the second thread reads the same value from the variable. There is Thread A for reading operation and Thread B for writing operation in word processing. They both attempt these operations simultaneously, and Thread B writes before Thread A could carry out the read operation, Thread A would fail to receive the file’s updated value in use.

What is Multiprocessing?

This technique, also referred to as process forking, inherently alleviates these problems that Multithreading poses as a computer can use two or more processors for operations. Unlike Multithreading, Multiprocessing utilizes a particular program for each task, thereby using more memory and resources. It shares the processes and resources dynamically among the processors in a CPU.

This fact comparatively gives Multiprocessing an advantage as there can be no data corruption, deadlocking, or race condition. For clarity, the benefits of Multiprocessing are, but not limited to:

Multiprocessing is cost-efficient, unlike single processor systems, as it shares peripherals and power supplies.
It can be used when very high speed is required to process a large volume of data.
Takes advantage of multiple CPUs & cores.
However, this technique, as good as it sounds, is not without its limitations, which are:
IPC (Inter-Process Communication) can be more involved with more overhead required.
It has a larger memory footprint.

Definitions of Multithreading and Multiprocessing

A multiprocessing system has more than two processors, whereas Multithreading is a program execution technique that allows a single process to have multiple code segments.

Multiprocessing improves the system’s reliability, while in the multithreading process, each thread runs parallel to each other.
In Multiprocessing, creating a process is slow and resource-specific, whereas, in Multiprogramming, creating a thread is economical in time and resource.

Multithreading or Multiprocessing

There is a bit of leeway to both multithreading and multiprocessing, in the two cases, they can be utilized to improve the performance and quality of applications. There are numerous considerations to deciding what is the best choice for the application. Ultimately there is no better way, each approach has preferences and difficulties and will rely upon the workload of the application deciding which approach is ideal.

Why Load Test ColdFusion Apps (4 Reasons)

FusionReactor — Tue, 02 Feb 2021 10:09:48 +0000

Let’s make sure that your new ColdFusion app doesn’t crash immediately after launch – by effective load testing.

In this article, we will look at 4 reasons why load test ColdFusion Apps. You will learn:

Why do you need to load test?

How to Easily Load Test and Make it a Routine

Pick a load testing tool
Write testing scripts that simulate real life
Assess the results of the test
Rinse and repeat your tests and fixes

The Long-term Benefits of Load Testing

About the Author

If you don’t plan ahead with load testing when too many users hit your newborn app at the same time, then it can become very slow or even crash your CF server. Leading to upset users, lost revenue for your company, and serious egg on the faces of everyone in your IT department.

In performance tuning circles, we call it “The Wall”. It’s hard to see it coming. But you’ll know when you’ve hit it.

“The Wall, in web applications, is that perfect storm of occurrences that suddenly, and within seconds, brings a web application to its knees. It is almost always caused by one thing: a stacking up of all available ColdFusion application threads. Which to be fair, is preceded, rather quickly, with a slow down in performance.

There can be many reasons, a successful marketing campaign, a major event, an unexpectedly successful launch. Whatever the cause, it is possible to architect and build infrastructure that can cope with any load” – my colleague Mike Brunt (CF performance expert) says.

It’s a wall similar to the one faced by marathon runners. It’s when your body decides to call it quits and all systems fall apart.

Fortunately, you can avoid The Wall with load testing. Done properly, it can save you and your company a lot of time, money, and frazzled nerves. Let’s look in more detail at why you should load test.

Why Do You Need To Load Test ColdFusion Apps?

No ColdFusion team wants their new app to crash after launch. But sometimes under pressure, or due to lack of knowledge, you launch it too soon. Before it has been stress-tested under real load conditions.

There are a few nasty side-effects of poorly-planned app launches that lead to crashes. This is typically caused by a sudden influx of traffic or users, spiking demand at times when resources are limited. It can bring your web app crashing down. It happens when you are stacking up all available application threads that collapse under their own weight.

Crashes can spook users, leading them to jump to your competitors.
It will slow down your company’s critical operations that are dependent upon the app. This all leads to added costs.
Inevitably, you will have to call in the fire brigade to squeeze out new load capacity.
Perhaps worst of all: Bugs and server crashes will chase away customers and kill productivity. This, in tandem, hurts your company’s image.

With proper load testing, you can discover your app’s weak points before the curtain opens on your launch to a live audience. With the right set up, you can enjoy pushing your app and server architecture to the limit, breaking them, and then fixing the resulting mess. All in a consequence-free setting. Makes me feel like a kid again!

Load testing your code and app is the most effective, least costly way to expose any weaknesses or mistakes in your work.

How To Easily Load Test ColdFusion Apps and Make It A Routine

1. Pick a load testing tool

Start with a load testing tool such as the free open-source Apache JMeter. It lets you write and playback user scripts that simulate real users running your app. You can include userIDs/passwords or other user data from data files to make the simulated users more realistic. And include random “thinking time”, just as humans delay between clicks or form submits.

As you progress in load testing, you can consider the many paid load testing tools which add more features, with prices ranging from $100 to $100,000.

2. Write Testing Scripts That Simulate Real Life

Write a testing script that mimics real users interacting with your web app.
Make sure the “users” are as active and numerous as real-world users would be. They should be clicking, updating, refreshing, downloading, and generally frantically chewing over every inch of your app.

Turn up the load of simulated users through 3 levels:

Ramp up the number of users until your app slows down.
Take it to the normal expected number of users and see how it performs.
Then get “a little bit naughty” – keep ramping up users until it finally breaks the server with a total crash. This is called a stress test and lets you find the ultimate limits to your code, architecture, and hardware setup.

Note you should have fixed all regular bugs before you start load testing. I wrote about Testing and automated testing to help with that.

3. Assess The Results Of The Test

Now that your digital army of simulated users has done a great job of slowing down or crashing your app, you can get to work in analyzing why it happened.

Load issues are usually caused by a combination of factors:

Software configuration issues, either for CF, IIS, JVM, databases
Poorly optimized software code that cannot handle an influx of activity
Badly designed database tables, indices, or queries
Speed issues with external services called by CFHTTP or REST API calls
Poor network configurations which get bogged down by increased demand
Incorrectly configured clustering and load balancing
Insufficient hardware (CPU, RAM, and disk space), which cannot meet the overall demands of running the app at peak load

You can learn more about fixing issues in this podcast interview I did with CF scaling expert Mike Collins.

I use a performance monitoring tool such as FusionReactor during load tests to make tracking down the cause of problems easier.

4. Rinse and Repeat Your Tests and Fixes

Keep load testing your app until:

You’re sure the expected number of users won’t slow down your app.
You can handle reasonable surges in users, of say 100% above the expected load.
You are comfortable that the point that your server crashes under load is a high number of users. And given user growth predictions, that it is far enough into the future that you could buy extra hardware to prevent problems before they happen.

The Long-term Benefits of Load Test ColdFusion Apps

Load testing remains one of the more overlooked aspects of CF development. Many treat it as an afterthought. But it’s an early decision that could have long-term ramifications for the success of your web app, as well as the financial health of your company. Load test properly, or it could cost you big time. In the worst case, it can cause a company to go out of business.

Run tests that push the limits of your web apps and servers. This stress test will show your app’s breaking point, which will help you spot trouble ahead of time.

Be optimistic! Load testing is a part of coding where not planning for failure leads to ultimate failure after launch.

About the Author

Michaela Light is the host of the CF Alive Podcast and has interviewed more than 100 ColdFusion experts. In each interview, she asks “What Would It Take to make CF more alive this year?” The answers still inspire her to continue to write and interview new speakers. Michaela has been programming in ColdFusion for more than 25 years. She founded TeraTech in 1989. The company specializes in ColdFusion maintenance, application development, security, and optimization. She has also founded the CFUnited Conference and runs the annual State of the CF Union Survey.

Why Do I Need an Application Performance Monitor (APM) Tool?

FusionReactor — Tue, 02 Feb 2021 09:49:55 +0000

Why Do I Need an Application Performance Monitor (APM) Tool?

Application Performance Monitoring (APM) is a technique that is a must-have for every serious-minded DevOps team. When it comes to employing the best practices for present-day software development, application Performance Monitoring procedures always top the list.

The sole purpose of monitoring an application’s performance on a routine basis is to portray visual imagery of the developed application or software’s internal operations while providing users with an excellent user experience.

Application Performance Monitoring (APM) tools are handy instruments that provide software administrators with the insight required to make a useful inference, figure out if the system works in semblance with the proposed blueprint, and implement fixes to issues that negatively impact the overall performance of the software.

Given the complexity of deploying software applications across multiple infrastructures (both cloud and on-premise), the DevOps team devised a means to keep track of their deployed apps’ operability. Taking into consideration the following reasons;

To represent a concise image of the developed platform to all stakeholders.
To state where there is an issue and what is needed to be adjusted.

Why is Application Performance Monitoring (APM) is Important to Organizations?

Application Performance Monitoring (APM) is an IT and software development best practice dedicated to ensuring application functions as expected. Application Performance management entails tracking the availability and performance of the various components of software applications such as a codebase, user experience, and other application dependencies.

For any business entity, the first step to ultimately wielding control over your applications’ performance is crucial to clearly understand what you would like to measure and how best to interpret it regarding your business model.

Every DevOps team in a well-structured organization must set up toolsets that allow them to measure performance metrics like each request and transaction in their codebase and the deployed app. Having such an observatory system permits organizations to baseline user experience and duly notify the DevOps team when the deployed software moves out of the project’s initial scope and the overall response time agreements.

With the help of super-efficient Application Performance Monitoring Platforms like FusionReactor, organizations can seamlessly monitor multiple applications on a grouping data concerning client CPU usage, constant network, data output, memory demands, and overall bandwidth.

Why is an APM a No Brainer For Organisations

Following the above definitions, using an APM can be a walk in the park if well implemented. This section is slated for developers, and DevOps teams keen on transcending their organizational needs to the next level. In this guide, I would be highlighting the key factors that would aid any organization in transforming their overall business model with the help of a well-suited Application Performance Monitoring tool.

Insight in your Environment

Learning the application workflow and entire development environment is the very first advantage that an APM provisions an organization. As the starting point for any APM implementation, APM provides visual imagery of how the application runs and who is using it. On the other hand, the DevOps team – and the administrative arm of an organization – has become accustomed to tracking different usage volumes from various timeframes (e.g., from 12:00 pm to 12:00 am). Using an APM helps in the scheduling of resource-intensive jobs and capacity planning.

Customer Satisfaction

Every business unit’s goal is to gain 100% customer satisfaction – and this is why performance monitoring becomes even more necessary long after the application has been deployed. Once a clear understanding of how the environment operates is established, you and your organization are a step closer to increasing user satisfaction.

Given users’ interactions are the crucial components of any system, as you increase your customer’s efficiency, you boost overall customer satisfaction and subsequent retention.

Reduces Firefighting

A useful APM tool routinely locates application performance bottlenecks on the fly. With this information at hand, project managers do not necessarily need to assemble all the application teams to address an issue. All that is required to be done is to have only the required personnel to troubleshoot and fix that issue—allowing the other half of the workforce to focus and take additional responsibilities.

Builds Credibility

Building customer credibility is a prerequisite for every business model. Developing healthy customer credibility for your brand takes time to develop yet can be lost in an instance. Management thrives on proactivity. As businesses get better at being proactive and communicating problems to their customers, they tend to build more customer confidence in the brand. Ultimately eliminating any negative perceptions of the business organization and the barrier of competition with similar service providers

Issue Isolation

Once complete proactivity and a proper monitoring and alert system are set in place, there would be no more need to have multiple staff monitor and validate the entire application. Although you would still need to maintain a handful of staff to respond to alerts, the amount of staff needed would be the barest minimum. This allows administrative-level employees to focus more on project work, leaving daily tracking and monitoring to the junior team.

So Why Do I Need an Application Performance Monitoring (APM) Tool?

In conclusion, it is pertinent for every organization to establish a well-implemented APM solution as it aids DevOps teams (and the organizations at large) resolve issues and bottlenecks at a brisk pace and reduces the organization’s Mean Time To Resolution (MTTR). By a wide margin, this impacts the overall business bottom line to a reduced state.

An organization that studies its application’s development and deployment environment can seamlessly harness useful insights while monitoring resource-intensive projects. Besides providing structural planning for project execution, a good A.P.M. bolsters customers’ satisfaction and initiates more users’ engagement. Your organization does not need to employ an in-house Q.A. team – given most of the processes involved in quality control and analysis are automated and handled on the go. Corporations can now focus more energy on what matters. Organizations can now say goodbye to the unnecessary hassle involved in maintaining and an extensive software analysis team. In the long run, cutting down extra expenses required to maintain these staff – and increasing the overall Return On Investment (R.O.I) through this and more user interaction.

Start your free FusionRector APM trial

Observability Vs. Monitoring: Why A Developer Needs Both

FusionReactor — Tue, 02 Feb 2021 09:39:02 +0000

Observability Vs. Monitoring: Why A Developer Needs Both

Given the complexity of distributing the evolving cloud-based services and infrastructures across a diverse range of users, IT service providers consistently observe and monitor metrics, datasets, and logs. Establishing system reliability and the predictability of backend IT infrastructure operations all spawn from systems observability and monitoring.

Software solutions often deliver a wide range of IT infrastructures and services from distant geographical locations to companies – in the semblance of cloud-based services such as containers and microservices. These services are distributed across multiple layers of infrastructure and platform services.

Due to consumers’ high expectancy for software-driven and enterprise IT, service providers to effect rapid feature updates through new releases on the internet. For this, IT providers frequently lookout for the best approaches to streamline performance while improving efficiency and maintaining system stability.

What Is The Difference Between Observability And Monitoring

Observability and monitoring are two terms that are often used interchangeably in the programming sphere. The critical difference between these two buzzwords lies in the ability to infer a system’s internal state against the actions involved in observing the quality of system performance over a stipulated timeframe.

While observability is performed based on a system’s external outputs, monitoring describes the health, performance, efficiency, and other essential features relative to the internal state.

Just as monitoring refers to all processes involved in translating infrastructure log metrics data into actual and discerning visual abstraction, observability engenders control of the internal states through external inputs.

Every Developer’s Greatest Asset

A developer or a development team’s ability to imbibe observability and monitoring as a traditional approach to development entails the deployment of more efficient codes, quicker product release, and streamlined deliverables. Practical monitoring approaches cannot be implemented without observability.

Given the concept of observability is inherent in present-day software development life cycle (SDLC) methodologies. With greater complexity comes an even greater need to observe and monitor the processes and tools employed during the development and deployment of these applications and services.

Monitoring IT infrastructures and services; from the blend of applications to manage, building, and deploying these services (containers, microservices, cloud-based ecosystem), through to the hassle involved in delivering these infrastructures (virtual, mobile, SaaS, cloud), are becoming more and more complicated.

What Is The Difference Between Observability And Monitoring

While observability is a procedure utilized by DevOps teams to query a system at every phase of the development-deployment process, an efficient monitoring technique informs whether the system functions as defined. Observability entails the dissemination of information gathered from the system. On the other hand, monitoring is a failure-centric approach that provisions a collection of metrics and logs from the system.

I am considering that every Developer’s greatest asset is reliant on building scalable and maintainable code over time. Hence, combining new Application Performance Monitoring tools – like FusionReactor, with data derived from industry-leading observability techniques is a win-win situation.

Conclusively, an adept developer or DevOps team can provide insightful access into the code’s intent while performing thorough traces and providing end-to-end transaction flow representation, drill-down tables & visual display of the various IT functions in the system. By employing sufficient metadata context provisioned by the observability and monitoring processes.

Originally posts here http://www.fusion-reactor.com/blog/what-is-the-difference-between-observability-and-monitoring/

Find bugs and performance issues faster

FusionReactor — Fri, 05 Jun 2020 15:41:19 +0000

Instantly see what's behind critical production issues

Deliver features faster and spend less time maintaining your application

FusionReactor provides real-time visibility into instrumentation data and code execution metrics, enabling developers to get to the root of issues and performance problems in the shortest possible time. FusionReactor is the only tool that can be effectively used for performance analysis across the whole Software Development Life Cycle. Over 5000 customers trust FusionReactor to monitor their Java applications, enabling them to identify and respond faster to performance and stability problems.

Configurable Metrics Dashboards

Cloud enables you to combine metric graphs so that you can build your own unique Dashboard views of how you want to see your data.

Application / Transaction breakdown

For each application being monitored, FusionReactor Cloud will automatically break down requests into individual transactions (including automatic framework recognition).

Transactions are measured so that you can quickly gauge how much time each transaction is taking in %, on average, which are slowest, the overall request throughput and how many errors/exceptions occurred.

Advanced Alerting Capability

FusionReactor Cloud includes advanced alerting capability, to enable you to set alerts based on different metrics available.

We have integrated support for many standard alerting tools, such as PagerDuty, Slack, HipChat, VictorOps – as well as supporting alerts via email and HTTP webhooks.

Auto Detect Errors & Important Transactions

FR Cloud is constantly monitoring individual request to determine if they’re interesting for you e.g. slow running requests, requests which generated an error or threw an exception.

Drill into the details of these requests and even save them for review at a later date.

Low-Overhead Production Java Profiler

FusionReactor Cloud Ultimate Edition includes an integrated low-overhead Java Profiler – which is the perfect tool for identifying poorly performing code in your production environment.

You can profile any requests or transactions which are running on the JVM – e.g. Tomcat, JBoss, WildFly, Glassfish, Jetty, etc. ColdFusion applications can also be profiled.

Metrics Explorer

Using the Metrics Explorer inside FusionReactor Cloud Java monitoring allows you to begin examining all of the metrics FusionReactor has collected from your instances or application.

On the left of the screen, you can see the query configuration panel, this allows you to configure the queries used to generate the graphs that will appear on the right-hand side of the screen.

Clicking the metric dropdown shows a searchable list of all of the metrics available for your account.

Free 14 day trial Java monitoring

What is Polymorphism, Encapsulation, Data Abstraction and Inheritance in Object-Oriented Programming?

FusionReactor — Fri, 05 Jun 2020 14:46:08 +0000

Object-oriented programming refers to the concept in high-level languages such as Java and Python that uses Objects and classes in their implementations. OOP has four major building blocks which are, Polymorphism, Encapsulation, Abstraction, and Inheritance. There are other programming paradigms such as Procedural programming in which codes are written in sequentially. Python and Java are multi-paradigm high-level programming languages that means they support both OOP and procedural programming. A programmer decides on the paradigm to use based on his expertise and the problems his trying to solve. However, there is no controversy that OOP makes programming easier, faster, more dynamic, and secured. This is a major reason Java and Python are the top most popular programming languages in the world today

If you want to learn Java and Python or any other object-oriented programming languages, then you must understand these Object-Oriented Programming paradigms which are a relatively easy concept to understand. Let’s take a look at them.

What is Inheritance?

In Java and Python, codes are written in objects or blocks if you are adopting OOP methodology. Objects can interact with one another by using the properties of each block or extending the functionalities of a block through inheritance. Inheritance ensures that codes are reused. There are millions of Java and Python libraries that a programmer can use through inheritance. The properties of a class can be inherited and extended by other classes or functions. There are two types of classes. One is the Parent or base class, and the other is the child class which can inherit the properties of the parent class. Inheritance is a major pillar in Object-Oriented programming. It is the mechanism by which classes in Java, Python, and other OOP languages inherits the attribute of other classes

A parent class can share its attributes with a child class. An example of a parent class implementation is in DDL (Dynamic-link library). A DDL can contain different classes that can be used by other programs and functions

A real-world example of inheritance is a mother and child. The child may inherit attributes such as height, Voice patters, color. The mother can reproduce other children with the same attributes as well

You can create a function or class called “Move Robot,” which controls a robot to move. And you could create method and functions in other programs that can inherit the ” Move Robot” Class without rewriting the codes over and over again. You can also extend this class by inheriting it and writing few more codes to it that would instruct a robot to move and also run in some specific circumstances using if and else statement. With inheritance, you can create multiple robots that would inherit the attributes of the parent class “Move Robot,” which ensures code reusability.

In summary, Inheritance is concerned with the relationship between classes and method, which is like a parent and a child. A child can be born with some of the attributes of the parents. Inheritance ensures reusability of codes just the way multiple children can inherit the attributes of their parents.

When we want to create a function, method, or class, we look for a superclass that contains the code or some of the code we want to implement. We can then derive our class from the existing one. In Java, we do this by using the keyword “Extends”, and in Python, we achieve this by inheriting the attributes of a class by calling up the class name.

Here is an example :

A vehicle class would define fields for speed. All vehicles are capable of traveling at some speed (even if 0 when stationary).

All boats would define buoyancy and draft and then the specific types (sailing, paddle, speed) would define its method of propulsion.

Cars define type of fuel, engine size etc.

Airplanes would have logic for flight, i.e. weight limits etc.

public class Vehicle {
    public float speedInKPH;
}
public class Car extends Vehicle {
    public int numberOfWheels;
    public int numberOfSeats;
}
public class Plane extends Vehicle {
     public long maximumTakeoffWeight;
}
public class SportsCar extends Car {
     boolean hasSoftTop;
}

What is Encapsulation?

This is a programming style where implementation details are hidden. It reduces software development complexity greatly. With Encapsulation, only methods are exposed. The programmer does not have to worry about implementation details but is only concerned with the operations. For example, if a developer wants to use a dynamic link library to display date and time, he does not have to worry about the codes in the date and time class rather he would simply use the data and time class by using public variables to call it up. In essence encapsulation is achieved in Python and Java by creating Private variables to define hidden classes in and then using public variables to call them up for use. With this approach, a class can be updated or maintained without worrying about the methods using them. If you are calling up a class in ten methods and you need to make changes, you don’t have to update the entire methods rather you update a single class. Once the class is changed, it automatically updates the methods accordingly. Encapsulation also ensures that your data is hidden from external modification. Encapsulation is also known as Data-Hidden.

Encapsulation can be viewed as a shield that protects data from getting accessed by outside code.

In essence, Encapsulation binds data and code as a single unit and enforces modularity.

What is Polymorphism

Polymorphism means existing in many forms. Variables, functions, and objects can exist in multiple forms in Java and Python. There are two types of polymorphism which are run time polymorphism and compile-time polymorphism. Run time can take a different form while the application is running and compile-time can take a different form during compilation.

An excellent example of Polymorphism in Object-oriented programing is a cursor behavior. A cursor may take different forms like an arrow, a line, cross, or other shapes depending on the behavior of the user or the program mode. With polymorphism, a method or subclass can define its behaviors and attributes while retaining some of the functionality of its parent class. This means you can have a class that displays date and time, and then you can create a method to inherit the class but should display a welcome message alongside the date and time. The goals of Polymorphism in Object-oriented programming is to enforce simplicity, making codes more extendable and easily maintaining applications.

Inheritance allows you to create class hierarchies, where a base class gives its behavior and attributes to a derived class. You are then free to modify or extend its functionality. Polymorphism ensures that the proper method will be executed based on the calling object’s type.

Program codes would run differently in a different operating system. The ability of program code exhibiting different behaviors across the operating system is known as polymorphism in OOP. You can create a class called “Move” and then four people create animals that would inherit the move class. But we don’t know the type of animals that they would create. So polymorphism would allow the animals to move but in different forms based on the physical features

A creates a Snail that inherits the move class, but the snail would crawl

B creates a Kangaroo that inherits the move class, but the Kangaroo would leap

C creates a Dog that inherits the move class, but the dogs would walk

D creates a Fish that inherits the move class, but the Fish would swim.

Polymorphism has ensured that these animals are all moving but in different forms. How the programs would behave would not be known until run time.

What is Abstraction?

Abstraction in Java and Python is a programming methodology in which details of the programming codes are hidden away from the user, and only the essential things are displayed to the user. Abstraction is concerned with ideas rather than events.

Its like in our vehicle example some of the vehicles need to be started before they can move.

public interface Startable {
    void start();
}
public class Car extends Vehicle implements Startable {
    public int numberOfWheels;
    public int numberOfSeats;
    public void start() {
       // some implementation
    }
}

You don’t need to care about how to start a car, plane, boat etc, if it implements Startable you know it will have a start method.

Polymorphism, Encapsulation, Data Abstraction and Inheritance in Object-Oriented Programming

The main idea behind Object Oriented Programming is simplicity, code reusability, extendibility, and security. These are achieved through Encapsulation, abstraction, inheritance, and polymorphism. For a language to be classified as OOP, it must have these 4 OOP blocks. Abstraction has to do with displaying only the relevant aspect to the user, for example, turning on the radio, but you don’t need to know how the radio works. Abstraction ensures simplicity. Inheritance has to do with methods and functions inheriting the attributes of another class. The main aim is code reuse which ensures that programs are developed faster. DRY (don’t Repeat yourself) is a concept in inheritance which imply that in a program, you should not have different codes that are similar. Instead, have one class and use other methods to call them and extend the functionalities where necessary. Polymorphism allows program code to have different meaning or functions while encapsulation is the process of keeping classes private so they cannot be modified by external codes.

This article was originally posted in the FusionReactor blog where you will find many interesting articles written by our developer team.

What is FusionReactor?

FusionReactor is an APM for Java applications that features low-level capabilities including profilers, automated root cause analysis, and production debugger.

the Eclipse Performance Monitor

FusionReactor — Thu, 21 May 2020 09:44:58 +0000

Introducing the Eclipse Performance Monitor

Eclipse IDE (Integrated Development Environment) is a multi-lingual development setting for almost any programming language you could think of – Java, C, C++, Clojure, Groovy, Haskell, JavaScript, Julia, Perl, PHP, Ruby, Rust, and much more. Nonetheless, eclipse is famous for being a dedicated Java IDE

Listed as one amongst the top three Java IDEs, this next-generation IDE is available in both desktop and cloud editions, hence its extensive clientele. But as the saying goes; “To Whom much is given much is expected. With an increasing large user community, the requirement for certain functionality becomes more needful over time.

For a renowned IDE like Eclipse, the feasibility of such serviceability as debugging, performance monitoring, profiling etc., has to be treated with a specific degree of sensitivity. Which is why we would be discussing on how to perform one of the most crucial aspects in the software development life cycle on an eclipse environment – performance monitoring on an Eclipse IDE.

How to Execute Performance Monitoring on An Eclipse IDE

For web artisans who are well-versed in the Java programming language, looking to include distinctive functionalities on the Eclipse IDE, a PDE (Plugin Development Environment) is conveniently available for this. This PDE allows the IDE to flaunt robust tools that aid developers in speeding up the entire development process. Yet, for more in-depth capabilities, it is best to utilize an exclusive eclipse performance monitor viz FusionReactor.

The UI Freeze Monitor

Eclipse IDE is providing an all-inclusive application programming interface. And as earlier mentioned, it comes fully packed with its own performance and profiling toolset in addition to an external plugin additive – all thanks to the PDE. Consequently, before we go into the details of using the dedicated performance tracing facility of the Eclipse IDE, we ought to talk about the interactive UI monitoring tool that comes with the Eclipse IDE. To activate this responsive UI performance measurement feature you would have to navigate to the preference tab on your window. You can do this by following these few steps below.

Steps: –

1 Click on Windows > Preference > UI Responsiveness Monitoring.

2 Once activated, a window would pop on where a stack trace would write to the Errorview, in case there is an occurrence of a UI freeze just like the window below.

During the event of a deadlock, it is best that you report such freezes https://bugs.eclipse.org/, so that the team can fix these.

For the rest of this guide we would be highlighting on the integrated performance inspecting facilities of Eclipse. Along with steps on how to implement this scrutiny in the most detailed way possible. Let’s immediately get into the nitty-gritty of using a custom-built performance checker.

Utilizing the In-built Tracing Instruments of Eclipse.

The Eclipse IDE proffers a tracing proficiency which can be activated on demand. Upon activation, additional plug-in information is written to the console at runtime. You can activate the native tracing feature through the -debug start parameter. At which time the IDE would search for the .options file in the directory where the installation file for Eclipse is being held up. The file would then be set to the ‘one key=value pair per line’ property.

The plugin is designed such that you can see the tracing option in the preference settings by default. It is also possible to initiate this tracking options at runtime. An example of the Eclipse IDE preference is shown in the following screenshot.

These tracing options are also available for a launch configuration. The following examples are going to be slated for specific tracing functions.

Tracing the Start-up Time of Plug-ins

In this example, we would trace the start time of each plug-in during start-up. For this, we would be creating a distinct .options file just like we did in the last instance, but this time with a different content as shown below;

Use the underlisted command to start Eclipse;

The ‘Starting application timestamp’ describes when OSGI (Open Service Gateway Initiative) is done with its activation process. Subsequently, its ‘Application Started’ time reference indicates when the application starts, just as the name imply. After which you extract the information you are most interested in. For instance, the above example is only a small script that extracts the time of the activator of each bundle. Thereafter, sorting every bundle by this time.

Monitoring the Resource Plugin.

The following example uses the same .option file to trace resources.

Implementing Tracking for your Custom Plugin

By means of the Eclipse Tracing API, users can also implement tracing for their custom plugins. To enable users, include their tracing options to the preference page, they would have to turn them on at run time. Using the extension to route to the org.eclipse.ui.trace.traceComponents. See the TracingPreferencePage for more details on how to implement this.

Tracing for Key Binding

The tracing functionality of Eclipse allows one to trace which commands are associated with certain key binding. The following listing contains the trace options to enable that.

Eclipse Sleak

The Sleak monitor tracks the creation and disposal of SWT (Standard Widget Toolkit) graphics resources. You can get this feature directly from SWT Development Tools or install the Eclipse plugin via the SWT Tools Update Sites.

To activate the Sleak functionality, you can use the ‘Tracing’ tab in your Eclipse runtime configuration.

You could also use active this component on the Eclipse IDE. To do this, you would have to start Eclipse with the -debug option from the command line terminal. You would also need to create a .options file in the Eclipse installation directory with the following entries;

Once you start the Eclipse IDE, you could find the Sleak view under;

Window > Show View > Other… > SWT Tools > Sleak.

Sleak allows you to take snapshots and conveniently creates a difference for comparison. You could click on ‘Stacktrace’ to access the stack trace utility that lets you view where the resource was allocated. Other tools that could be used for Eclipse performance monitoring includes NetBeans profiler, FusionReactor, GC Viewer, VisualVM, JIP, to name a few.

Minimize server downtime

The overall idea of monitoring performance in your Eclipse environment is to ensure you actively minimize server downtime, and speed up the time to resolve the issue. Even though there is an endless list of tools for performance monitoring on a Java development environment such as Eclipse, FusionReactor stands out amidst the crowd. Reason being that FusionReactor outstrips conventional monitoring since it actively tunes the Eclipse IDE, minimizes server downtime and accelerates time to resolution unlike any other Eclipse Performance Monitoring tool obtainable.

Fusion Reactor’s performance monitor comes with a unique package that outclasses many conventional monitoring platforms. It gives you a broad and instant view of what is going on within your Eclipse environment so you can evaluate how much time is needed for each transaction.

Spring Boot Performance Monitoring

FusionReactor — Thu, 21 May 2020 08:56:36 +0000

Spring Boot Performance Monitoring.

Modern applications are highly distributed in nature, and thus they are often bundled with various dependencies like Database, caching and much more. Monitoring becomes essential due to the complexity of the implementation scheme that comes amid such advanced software. The Spring Boot Performance Monitor is a library kit that comes preinstalled with any Java Agent. It utilizes HTTP endpoints or JMX beans – because you can also configure the proxy profile to display Spring Boot JMX metrics, to enable us to interact with it. By way of this, we get firsthand reading of operational information about the running application – health, metrics, info, dump, env, etc.

The Spring Boot Monitoring toolset provides you with an immediate and extensive insight into your Java applications running on the Spring MVC Framework. In its essence, the Spring Boot Performance Actuator is a unifier that introduces production-ready features into our application. With this dependency manager, such functionalities as gathering metrics, monitoring our apps, understanding traffic in addition to the state of our Database becomes inconsequential. The Spring Actuator discovers the application name through of the spring.application.name, property located in the application.properties file or the SpringBoot Application startup class, if the spring.application.name property is not defined.

The Spring Boot Actuator

Notably, Spring Boot supports many additional features that help you manage and monitor your application, from the development stage, extending to production. Such auditing exercise as metrics and health gathering are seamlessly implemented through the Spring Boot Performance Monitor. Once installed onto the classpath, this dependency supplies us with several endpoints right out of the box.

As with several other Spring modules, we can extend and configure the Spring Boot Actuator in a variety of ways, of which we would be looking into shortly.

Getting Started

Typically, a monitoring system would have three core components which include;

Dashboard for the visualization of data stored in the Database.
A Metric Store – Time-series Database. For example, Prometheus, InfluxDB, TimescaleDB etc.
Applications that periodically supplies the Metric store with metrics data from the application’s local state.

We can go on ahead to have other components installed as well like alerting – where the alert channel could be via Email, Slack or other conventional media. Alerting components would be sending alerts to the application owners or subscribers of events. For this guide, we would be using Grafana as a dashboard and alerting system, Prometheus as a metrics store system.

The Requirements

An IDE
Java Development Environment
Gradle

Now we create a project from the Spring Boot initializer, after which we add dependencies – as much as we want to. Next, we use the Micrometer library, which is an instrumentation façade that provides bindings for many metric stores like Prometheus, New Relic, Datadog, to mention a few.

Micrometre provides the following functionalities ready for use;

1. JVM.

2. Database.

3. HTTP request.

3. Cache system and related metrics.

While some of these metrics are enabled by default, others are subject to customized settings. For this feature; we would employ the application.properties file to handle enabling, disabling and customization. We would also need to use the Spring Boot Actuator to expose the endpoint of the Metric Store – Prometheus.

Steps: –

Add these following dependencies in build gradle file just as done in line 7 of figure 1.:

io.micrometer:micrometer-registry-Prometheus.

org.springframework.boot:spring-boot-starter-actuator.

Figure 1:

We would enable the Prometheus export functionality by adding the following line to the properties file.

Figure 2:

As soon as the above command is enabled Micrometer automatically accumulates data about the application. This data can be viewed by visiting the actuator / Prometheus endpoint – which is used in the Prometheus script to fetch data from our application servers.

Although we have included the line mentioned above of code into the properties file, we still won’t be able to browse the Prometheus endpoint since it is disabled by default. For that, we head on to the management endpoint and add Prometheus in the list.

Figure 3:

Note:

Not all endpoints are enabled from actuator as this could lead to a security loophole. Hence, we choose endpoints selectively, especially in a production environment. Even though we need to use these endpoints, it is not advisable to expose certain endpoints to the whole world as we place a whole lot of sensitive application data at risk. Therefore, it is best to use some proxy to hide these endpoints from the real world.

Also, various components of the HTTP requests are customizable much like the SLA (Service Level Agreement), percentile histogram should be computed or not. This can be done through the metrics—distribution properties.

A sample application.properties can contain the following lines;

Figure 4:

We can now run the application and navigate to the page http://locahost:8080/actuator/prometheus on a browser, to view our data.

Figure 5:

The above data displays HTTP request detail, such as

exception=None, which means there is no exception just as the name implies. If any, we can use that to filter how many requests have failed due to that exception handler.

method=GET HTTP method name.

status=200 HTTP status code is 200.

uri=/actuator/prometheus displays the URL path.

le=xyz displays the processing time.

N.0 displays the number of times that endpoint was called.

This data can be represented as a pie-chart or histogram that can be plotted in Grafana, for example, to plot p95 over 5 minutes we can use the following query.

Figure 6:

Custom Metrics

Most times, we might need to customize our metrics where some of such use-cases include the number of logged-in users, number of orders in the order queue, currently available stock details etc. Certain business use cases can be solved using custom metrics. Thus, Micrometer supports multiple kinds of metrics like Gauge, Counter, Timer, Long task timers, Distribution summaries etc. But for the scope of this walkthrough, we would focus mainly on Gauge and Counter. Gauge gives us instantaneous data like the length of a queue, whereas the counter is much like a uniformly increasing number, starting from one.

For this, we’re going to create a demo stock manager that will store details in memory and would provide two functionalities:

1. Add items.

2. Get items.

By that, we’ve created a single counter and an available gauge in the init method. Therefore, whenever getItems is called, we increase the counter as well as to measure the stock size. While a call to addItems updates the gauge.

Figure 7:

For demonstration purposes, we’ll add two endpoints to add items and get items.

Figure 8:

Firstly, we add ten items using two API calls.

Curl -X POST http://localhost:8080/stocks?items=1,2,3,4
Curl -X POST http://localhost:8080/stocks?items=5,6,7,8,9,10

Now if we browse to Prometheus endpoints, then we can see the following data indicating that we currently have 10 items in the stock.

Figure 9:

Now, we’re going to place an order of size three;

http://localhost:8080/stocks?size=3

Then again, if we browse Prometheus endpoint, then we get the following data that indicates stock size has been changed to seven.

Figure 10:

We could also see that the counter has been updated with a value of 1. This indicates that just a single order has been placed.

Figure 11:

Troubleshooting with Spring boot performance monitoring

Other tools like FusionReactor permits you to troubleshoot the most complex of application performance issues. They were giving you instant insight into where problems are occurring or where your application is performing poorly.

Critical Features for Spring Boot Performance Monitoring Tools

Below are some of the critical features that FusionReactor provisions, along with the Spring Boot Performance Monitoring Tools.

Production Debugger – Production, Safe / User, Controlled enclosed debug environment.
Code Profiler – Production Safe / instantly see performance bottlenecks.
Memory Profiler – Production Safe / Real-time heap analysis to locate memory leaks.
Instant Code decompilation.
JMX MBeans Support.
Crash Protection – Constant application availability and performance checking.
Generate alerting for poor performance or when resource thresholds (memory/CPU) are reached.
Isolate Long Running threads.

One essential Actuator software for monitoring and interacting with your application is FusionReactor, as it goes beyond “just monitoring”. FusionReactor instruments web-based transactions within the Spring 2.x and 3.x MVC Framework, hence provisioning a seamless transaction identification process. Also, proactively mitigates server downtime while expediting time to a resolution just like no other Spring Boot Performance Actuator on the market.

Finding and fixing Spring Data JPA performance issues with FusionReactor

FusionReactor — Thu, 21 May 2020 08:20:42 +0000

Finding and fixing Spring Data JPA performance issues with FusionReactor

For several years, Spring Data JPA has established itself as one of the most commonly used persistence frameworks in the Java world. It gets most of its features from the very popular Hibernate object-relational mapping (ORM) implementation. The ORM features provide great developer productivity, and the basic functionality is very easy to learn.

But as so often, you need to know a lot more than just the basic parts if you want to build enterprise applications. Without a good understanding of its internals and some advanced features, you will struggle with severe performance issues. Spring Data’s and Hibernate’s ease of use sometimes make it way too easy to build a slow application.

But that doesn’t have to be the case. With the right tools in place, you can identify performance problems easily and often even before they cause trouble in production. In this article, I will show you 3 of Hibernate’s and Spring Data’s most common performance pitfalls, how you can find them using FusionReactor’s Java Monitoring or Hibernate’s statistics, and how you can fix them.

Pitfall 1: Lazy loading causes lots of unexpected queries

When you learn about Spring Data JPA and Hibernate performance optimizations, you always get told to use FetchType.LAZY for all of your applications. This tells Hibernate to only load the associated entities when you access the association. That’s, of course, a much better approach than using FetchType.EAGER, which always fetches all associated entities, even if you don’t use them.

Unfortunately, FetchType.LAZY introduces its own performance issue if you use a lazily fetched association. Hibernate then needs to execute an SQL query to get the associated entities from the database. This becomes an issue if you work with a list of entities, as I do in the following code snippet.

[Code]
@RestController
@RequestMapping(path = "/concert")
public class ConcertController {

    Logger logger = Logger.getLogger(ConcertController.class.getSimpleName());

    private ConcertRepository concertRepo;

    @GetMapping
    public List getConcerts() {
        List concerts = this.concertRepo.findAll();

        for (Concert c : concerts) {
            logger.info("Concert "+c.getName()+" gets played by "+c.getBand().getName());
        }

        return concerts;
    }
}
[/Code]

The findAll method of Spring Data’s JpaRepository executes a simple JPQL query that gets all Concert entities from the database and returns them as a List. Each of these concerts is played by band. If you set the FetchType of that association to FetchType.LAZY, Hibernate executes a SQL query to fetch the Band when you call the getter method on the Concert entity. If you do that for each Concert entity in the List, Hibernate will execute an SQL query for each Band who plays a concert. Depending on the size of that List, this will cause performance problems.

Find unexpected queries

This issue is relatively hard to find in your code. But it gets pretty easy if you monitor the queries executed by your application.

Using FusionReactor, you can easily see all the SQL statements, which were performed by the getConcerts method. Based on the code, you would probably expect that Hibernate only performs 1 SELECT statement. But as you can see in the screenshot, Hibernate executed 10 SELECT statements because it had to get the associated Band entity for each Concert.

Or you can activate Hibernate’s statistics component and the logging of SQL statements. Hibernate then writes a log message at the end of each session, which includes the number of executed JDBC statements and the overall time spent on these operations.

[Code]
2020-04-11 15:28:04.293 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select concert0_.id as id1_2_, concert0_.band_id as band_id6_2_, concert0_.event_date_time as event_da2_2_, concert0_.name as name3_2_, concert0_.price as price4_2_, concert0_.version as version5_2_ from concert concert0_
2020-04-11 15:28:04.338 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select band0_.id as id1_1_0_, band0_.description as descript2_1_0_, band0_.founding_date as founding3_1_0_, band0_.name as name4_1_0_, band0_.version as version5_1_0_ from band band0_ where band0_.id=?
2020-04-11 15:28:04.354  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 1 gets played by band 1
2020-04-11 15:28:04.355 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select band0_.id as id1_1_0_, band0_.description as descript2_1_0_, band0_.founding_date as founding3_1_0_, band0_.name as name4_1_0_, band0_.version as version5_1_0_ from band band0_ where band0_.id=?
2020-04-11 15:28:04.358  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 2 gets played by band 2
2020-04-11 15:28:04.358 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select band0_.id as id1_1_0_, band0_.description as descript2_1_0_, band0_.founding_date as founding3_1_0_, band0_.name as name4_1_0_, band0_.version as version5_1_0_ from band band0_ where band0_.id=?
2020-04-11 15:28:04.361  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 3 gets played by band 3
2020-04-11 15:28:04.362 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select band0_.id as id1_1_0_, band0_.description as descript2_1_0_, band0_.founding_date as founding3_1_0_, band0_.name as name4_1_0_, band0_.version as version5_1_0_ from band band0_ where band0_.id=?
2020-04-11 15:28:04.364  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 4 gets played by band 4
2020-04-11 15:28:04.364 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select band0_.id as id1_1_0_, band0_.description as descript2_1_0_, band0_.founding_date as founding3_1_0_, band0_.name as name4_1_0_, band0_.version as version5_1_0_ from band band0_ where band0_.id=?
2020-04-11 15:28:04.367  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 5 gets played by band 5
2020-04-11 15:28:04.367 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select band0_.id as id1_1_0_, band0_.description as descript2_1_0_, band0_.founding_date as founding3_1_0_, band0_.name as name4_1_0_, band0_.version as version5_1_0_ from band band0_ where band0_.id=?
2020-04-11 15:28:04.369  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 6 gets played by band 6
2020-04-11 15:28:04.370 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select band0_.id as id1_1_0_, band0_.description as descript2_1_0_, band0_.founding_date as founding3_1_0_, band0_.name as name4_1_0_, band0_.version as version5_1_0_ from band band0_ where band0_.id=?
2020-04-11 15:28:04.372  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 7 gets played by band 7
2020-04-11 15:28:04.372 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select band0_.id as id1_1_0_, band0_.description as descript2_1_0_, band0_.founding_date as founding3_1_0_, band0_.name as name4_1_0_, band0_.version as version5_1_0_ from band band0_ where band0_.id=?
2020-04-11 15:28:04.375  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 8 gets played by band 8
2020-04-11 15:28:04.376 DEBUG 23692 --- [nio-7070-exec-1] org.hibernate.SQL                        : select band0_.id as id1_1_0_, band0_.description as descript2_1_0_, band0_.founding_date as founding3_1_0_, band0_.name as name4_1_0_, band0_.version as version5_1_0_ from band band0_ where band0_.id=?
2020-04-11 15:28:04.378  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 9 gets played by band 9
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 10 gets played by band 1
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 11 gets played by band 2
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 12 gets played by band 3
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 13 gets played by band 4
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 14 gets played by band 5
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 15 gets played by band 6
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 16 gets played by band 7
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 17 gets played by band 8
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 18 gets played by band 9
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 19 gets played by band 1
2020-04-11 15:28:04.379  INFO 23692 --- [nio-7070-exec-1] ConcertController                        : Concert concert 20 gets played by band 2
2020-04-11 15:28:04.463  INFO 23692 --- [nio-7070-exec-1] i.StatisticalLoggingSessionEventListener : Session Metrics {
    4769200 nanoseconds spent acquiring 1 JDBC connections;
    0 nanoseconds spent releasing 0 JDBC connections;
    2552200 nanoseconds spent preparing 10 JDBC statements;
    24755400 nanoseconds spent executing 10 JDBC statements;
    0 nanoseconds spent executing 0 JDBC batches;
    0 nanoseconds spent performing 0 L2C puts;
    0 nanoseconds spent performing 0 L2C hits;
    0 nanoseconds spent performing 0 L2C misses;
    0 nanoseconds spent executing 0 flushes (flushing a total of 0 entities and 0 collections);
    495900 nanoseconds spent executing 1 partial-flushes (flushing a total of 0 entities and 0 collections)
}
[/Code]

Avoid additional queries

You can avoid this issue by using a JOIN FETCH clause that tells Hibernate to fetch the Concert and associated Band entities within the same query. You can do that by adding a method to your repository interface and defining a custom query using the @Query annotation.

[Code]
public interface ConcertRepository extends JpaRepository {

    @Query("SELECT c FROM Concert c LEFT JOIN FETCH c.band")
    List getConcertsWithBand();
}



@RestController
@RequestMapping(path = "/concert")
public class ConcertController {

    Logger logger = Logger.getLogger(ConcertController.class.getSimpleName());

    private ConcertRepository concertRepo;

    @GetMapping
    public List getConcerts() {
        List concerts = this.concertRepo.getConcertsWithBand();

        for (Concert c : concerts) {
            logger.info("Concert "+c.getName()+" gets played by "+c.getBand().getName());
        }

        return concerts;
    }
}
[/Code]

Instead of 10 queries, Hibernate now gets all information with only 1 query.

Pitfall 2: Slow database queries

Slow queries are a common issue in all applications that store their data in a relational database. That’s why all databases provide an extensive set of tools to analyze and improve these queries.

Even though we can’t blame Spring Data JPA or Hibernate for these issues, we still need to find and fix these queries in our application. And that’s often not as easy as it might seem. Hibernate generates the executed SQL statements based on our JPQL queries. In general, the executed queries are efficient. But sometimes, the additional abstraction of JPQL hides performance problems that would be obvious, if we would write the SQL query ourselves.

The following JPQL query, for example, looks totally fine. We’re loading Concert entities and use multiple JOIN FETCH clauses.

[Code]
public interface ConcertRepository extends JpaRepository {

    @Query("SELECT c FROM Concert c LEFT JOIN FETCH c.band b LEFT JOIN FETCH b.artists WHERE b.name = :band")
    Concert getConcertOfBand(@param
("band") String band);
}
[/Code]

Find inefficient queries

The problem becomes obvious if you activate the logging of SQL statements in Hibernate or take a look at the executed JDBC statements in FusionReactor.

Hibernate has to select all columns mapped by an entity if you reference it in your SELECT clause or if you tell Hibernate to JOIN FETCH an association. In this case, the JPQL query that referenced 3 entities caused an SQL statement that selects 22 columns. These are a lot more columns than you might expect when you look at the JPQL query, and it gets worse if your entities map more columns or you JOIN FETCH more associations.

The JOIN FETCH clause creates another issue: The result set contains the product of all joined records. Due to that, such result sets often contain thousands of records.

Improve inefficient queries

The only way to fix this performance problem is to avoid these kinds of queries. You could try to use a smaller, use case specific projection. Or you could split your query into multiple ones, e.g., one that fetches the Band entity with a JOIN FETCH clause for the artist attribute and another query for the Concert entity.

[Code]
@RestController
@RequestMapping(path = "/concert")
public class ConcertController {

    Logger logger = Logger.getLogger(ConcertController.class.getSimpleName());

    private ConcertRepository concertRepo;
    
    private BandRepository bandRepo;

    public ConcertController(ConcertRepository orderRepo, BandRepository bandRepo) {
        this.concertRepo = orderRepo;
        this.bandRepo = bandRepo;
    }

    @GetMapping(path = "/name/{name}")
    public List getConcertOfBand(@PathVariable("name") String name) {
        Band b = this.bandRepo.getBandWithArtists(name);
        List concerts = this.concertRepo.getConcertsOfBand(name);
        
        if (concerts.isEmpty()) {
            throw new NoResultException();
        }
        return concerts;
    }
}
[/Code]

Pitfall 3: Too many write operations

Another common performance pitfall is the inefficient handling of write operations for multiple entities.

Let’s say you need to reschedule all concerts that were planned for the month of April. Using Java and Hibernate as your ORM framework, it feels natural to get a Concert entity object for each of these concerts and to change the eventDateTime attribute.

[Code]
List<Concert> concerts = this.concertRepo.getConcertsScheduledFor(LocalDateTime.of(2020, 04, 01, 00, 00), LocalDateTime.of(2020, 04, 30, 23, 59));

for (Concert c : concerts) {
    c.setEventDateTime(c.getEventDateTime().plusMonths(1));
}
[/Code]

Find inefficient write operations

But that would force Hibernate to execute an SQL UPDATE statement for each concert. Similar to the previous performance issues, this inefficiency is only visible, if you monitor the executed SQL statements.

Reduce the number of write operations

In SQL, you would write one SQL UPDATE statement that changes the value in the event_date_time column of all concerts that are scheduled for the month of April. That’s obviously the more efficient approach.

You can do the same with a native query in Hibernate. But before you do that, you should always call the flush() and clear() methods on your EntityManager. That ensures that your 1st level cache doesn’t contain any local copy of the data that your query will change.

[Code]
em.flush();
em.clear();
em.createNativeQuery("UPDATE concert SET event_date_time = event_date_time + INTERVAL '1 month'").executeUpdate();
[/Code]

Conclusion – Finding and fixing Spring Data JPA performance issues with FusionReactor

As you have seen, Hibernate is easy to use, but it can also cause some unexpected performance problems. These are often hard to find in your code but very easy to see as soon as you monitor the executed SQL statements. If you use the right logging configuration, you can find these statements in your application log file. Or you can use FusionReactor’s Database Monitoring features and integrate these checks in your application monitoring strategy.

Understanding StackTraces in Java

FusionReactor — Thu, 21 May 2020 08:17:09 +0000

By guest author Thorben Janssen

The StackTrace is one of the key concepts in Java. It’s a call stack for the thread and lists all method calls since the start of the thread. You have probably seen its textual representation in your log file or console output. It gets printed to System.out whenever an exception is thrown and not handled by your application. The following snippet shows a typical example of such an output.

java.lang.NumberFormatException: For input string: "123a45"
    at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:68)
    at java.base/java.lang.Long.parseLong(Long.java:699)
    at java.base/java.lang.Long.valueOf(Long.java:1151)
    at org.thoughts.on.java.TestStackTrace.testStackTrace(TestStackTrace.java:17)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:567)
    ...

Using monitoring tools, like FusionReactor, or by calling the getStackTrace() method on the current thread, you can access the StackTrace for all active threads in your JVM. But there are other ways to examine and work with a StackTrace.

In most cases, you will not look at a StackTrace until you need to analyze an Exception. The StackTrace is part of an Exception object, and it shows all method calls that happened until the exception was thrown. That shows you where the exception occurred and how you reached that specific part of the code.

In the next step, you can then analyze your code and find out what caused the exception. But that’s a topic for a different article. In this one, I want to tell you more about exceptions with their StackTraces and all the information they provide, so that you have a better understanding of StackTraces in Java.

Exceptions in Java

An exception gets thrown whenever an error happens within a Java application. It gets represented by an object of the java.lang.Exception class or one of its subclasses. The JDK provides you with a huge set of different Exception classes. If you want, you can also implement your own business exceptions.

It’s a general best practice to use the most specific exception class for each error. A typical example for that is the valueOf method of the java.lang.Long class. You can call it with a java.lang.String and it throws a java.lang.NumberFormatException if the String has a format that can’t be parsed to a Long. The NumberFormatException is a subclass of the IllegalArgumentException, which indicates that an invalid argument value was passed to a method. As you can see, the IllegalArgumentException would describe the error situation, but the NumberFormatException is more specific and should be preferred.

private Long parseToLong(String s) {
    return Long.valueOf(s);
}

Long l;
try {
    l = parseToLong(s);
} catch (NullPointerException npe) {
    // handle NullPointerException
    log.error("No value provided. Using 0 as default.", npe);
    l = 0L;
}
log.info(l);

Using the most specific exception class makes your code easier to read, and it enables you to implement a different catch clause for each exception class. This allows you to handle each error situation differently.

You could, for example, decide to throw a NullPointerException if the provided String is null and throw a NumberFormatException if it doesn’t have the correct format.

private Long parseToLong(String s) {
    if (s == null) {
        throw new NullPointerException("String can't be null");
    }
    return Long.valueOf(s);
}

In the code that calls this method, you can then implement 2 separate catch blocks that handle the NullPointerException and the NumberFormatExceptions in different ways. I did that in the following code snippet to provide different error messages for both situations. But you could, of course, use the same approach to implement a more complex error handling or to provide a fallback to default values.

Long l;
try {
    l = parseToLong(s);
} catch (NullPointerException npe) {
    // handle NullPointerException
    log.error("No value provided. Using 0 as default.", npe);
    l = 0L;
} catch (NumberFormatException nfe) {
    // handle NullPointerException
    log.error("Provided value was invalid. Using 0 as default.", nfe);
    l = 0L;
}
log.info(l);

The structure of a StackTrace

In the previous code snippet, I wrote log messages that contained the caught exception objects. The following snippet shows an example of such a message in the log file. Your application writes a similar message for all unhandled exceptions to your console.

15:28:34,694  ERROR TestStackTrace:26 - Provided value was invalid. Using 0 as default.
java.lang.NumberFormatException: For input string: "123a45"
    at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:68)
    at java.base/java.lang.Long.parseLong(Long.java:699)
    at java.base/java.lang.Long.valueOf(Long.java:1151)
    at org.thoughts.on.java.TestStackTrace.parseToLong(TestStackTrace.java:39)
TestStackTrace.java:39
    at org.thoughts.on.java.TestStackTrace.testStackTrace(TestStackTrace.java:18)
TestStackTrace.java:18
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:567)

As you can see, the log message contains a long list of class and method names. This is the textual representation of the StackTrace of the exception. Whenever a new method gets called, it gets added to the top of the stack, and after it got executed, it gets removed from the stack. Based on this approach, the last method that got called before the exception occurred is at the top of the StackTrace and logged first. The following elements in the StackTrace and lines in the log file show which methods were previously called to reach the part of the code that caused the exception.

Using StackTraces to analyze incidents

If you take another look at the previously shown StackTrace, you can see that the exception was created in the forInputString method of the NumberFormatException class. The actual problem occurred in the parseLong method of the Long class, which was called by the valueOf method of the same class, which was called by parseToLong method of my TestStackTrace class. As you can see, the StackTrace provided by the NumberFormatException clearly shows where the exception happened and which chain of method calls lead to it.

This information is a good start to analyze an exception and to find the actual cause of it. But quite often, you will need more information to understand the issue. The Exception object and its StackTrace only describe which kind of error occurred and where it happened. But they don’t provide you with any additional information, like the values of certain variables. This can make it very hard to reproduce the error in a test case.

How FusionReactor can help

FusionReactor can provide you more information about the error situation. If you want, you can even debug the issues on your live system when it occurs next time.

The only thing you need to do is to log into the web interface of the FusionReactor instance that monitors your application, select the exception from the “Error History” and go to the “Error Details” tab. There you can activate the debugger for this specific exception.

After you’ve done that, FusionReactor will send you an email when the exception occurs again and pause the thread for a configured amount of time. The email contains the stack trace and information about the variable context. As long as the thread is paused, you can also use FusionReactor’s Production Debugger to debug the error in a similar way as you would in your IDE without affecting any of the other threads of your application.

How to Find Memory Leaks in Java Web Applications

FusionReactor — Thu, 21 May 2020 08:11:06 +0000

Finding memory leaks in your Java application could be a needle in a haystack exercise if you are a rookie or intermediate Java developer who is yet to know their way around the Java Virtual Machine (JVM) production environment. However, depending on your profiling tool, you can easily analyze your Java memory consumption, while obtaining instantaneous insights into the heap in your Java production applications. But before we go into the details on how to find memory leaks in java web applications, let’s get into what a Java memory leak is, the possible causes of such leakages and remediation procedures to handle this.

Java Memory Leak

A memory leak is simply caused by reference chaining which is held up in the PermGen and cannot be garbage-collected. Sounds gibberish, right? Well, keep calm and follow-through while I explain further. Since web containers utilizes a class to class loader mapping system to isolate web applications and because a class is uniquely identified by its name and the class loader that loaded it. Hence, you can have a class with the same name, loaded multiple times in a single JVM – with each class having a distinct class loader.

Whereas;

An object retains a reference to the class (java.lang.Class) that instantiated it.
The class in turn retains a reference to the class loader that loaded it.

The class loader retains a reference to every class it loaded.
This potentially becomes a very big reference graph to handle on a long run. Not to forget that these classes are loaded directly into the PermGen. Therefore, retaining a reference to a particular object from a web application pins every class loaded by the web application in the PermGen. These references often remain even after a web application is reloaded and with each new reload, more classes get pinned or stuck up in the PermGen – which in due course gets full.

What is a PermGen?

PermGen, short for Permanent Generation is a heap in the JVM dedicated to storing the JVM’s internal representation of Java Classes – and also detained string instances. In simple terms; it is an exclusive heap location separate from the primary Java heap, where the JVM registers metadata related to the classes which have been loaded.

Although, most Java Servlet containers and WebSocket technologies enable the org.apache.catalina.core.JreMemoryLeakPreventionListener Class by extension such as Apache Tomcat 7.0 and upwards. Nonetheless, the inclusion of this memory leak handler wouldn’t suffice in the event of a more sophisticated such as PermGen errors on reload and bug interference caused by the application itself. This gets a little more interesting when the Tomcat servlet isn’t causing the leak, neither is the application (at least not directly) but rather a bug in the JRE code triggered by some third-party library.

With the advent of the Java Development Kit – JDK6 (Update 7 or later), comes a handy tool that ships with the JDK and makes life a whole lot easier for us. This tool is called the VisualVM; which is a graphical tool that seamlessly connects to any JVM and allows you to expel unwanted garbage from the JVM’s heap besides letting you navigate that heap. In a Tomcat servlet, a class loader for a web application is also a class called org.apache.catalina.loader.WebappClassLoader. Wherefore, if our Tomcat instance has just a single web application deployed, then there should only be one instance of this class in the heap. But in the event that there are more, then we have a leak.

STEPS ON HOW TO FIND MEMORY LEAKS IN JAVA WEB APPLICATIONS
Now that we have that out of the way, let’s quickly dive into the steps on how to detect and avoid Java memory leaks. Let’s immediately lucubrate on how we can use VisualVM to figure this out.

Steps:

Open the command prompt terminal and type in the following command below to Start Visual VM;

${JAVA_HOME}/bin/jvisualvm

A window similar to figure 1 would pop up.

How to Find Memory Leaks in Java Web Applications
Figure 1: The Java VisualVM

Right-click on Tomcat from the sidebar on the left-hand side then select ‘Heap Dump’.

How to Find Memory Leaks in Java Web Applications

Figure 2: Heap Dump: Click on the ‘OQL Console’ button.

Click on the ‘OQL Console’ button at the top of the Heap Dump navbar. This opens up a console that allows you to query the heap dump. For this exercise, we want to locate all instance of org.apache.catalina.loader.WebappClassLoader.So enter the command below in the resulting console;

select x from org.apache.catalina.loader.WebappClassLoader x

Figure 3: ‘OQL Query Editor Console’: Type in the above command and click execute

In this case, VisualVM found two instances of the web application class loader; one slated for the web application itself and the other for the Tomcat manager application.

Use the Tomcat manager application to restart the web application at http://localhost:8080/manager/html and take yet another heap dump of the Tomcat process.

Figure 4: Restart the web application and navigate back to the ‘OQL Console’ to repeat step 3 again

Notice the inclusion of an extra instance from the above step. This is because one of these 3 instances was supposed to be collected by the garbage-collector, yet it wasn’t. Thanks to Tomcat we can easily tell which instance was not garbage-collected as all active class loaders are provisioned with the field name: ‘started’ set to ‘true’.

In order to find the invalid instance, click through each class loader instance until you find the one whose ‘started’ field is set to ‘false’.

Figure 5: Click through each class loader instance in the heap dump to spot the faulty one – with the ‘started’ field set to false

Now that we have spotted the class loader that causes the leak, we need to determine what object is holding a reference to the class loader. Evidently, a good number of objects would be referenced by many other objects, but in all essence, only a limited number of these objects would form the root of the graph of references. These are particularly the object(s) we are interested in.

Therefore, on the bottom pane of the instances tab, right-click on the object instances that forms the root of the reference graph and select ‘Show nearest GC root’.

The resulting window should look like this;

Figure 6: Right-click on the object instances that forms the root of the reference graph and select ‘Show nearest GC root’.

Right-click on the instance and select ‘Show Instance’.

Figure 7: Right-click on the instance and select ‘Show Instance’.

From this, we can deduce that this is an instance of the sun.awt.AppContext type. We could also see that the contextClassLoader field in AppContext is holding a reference to the WebappClassLoader. Hence, this is the errant reference causing the memory leak. Now we figure out what instantiated the sun.awt.AppContext type, for starters.

Firstly, we restart the Tomcat in debug mode with the following code;

export JPDA_SUSPEND=y

${TOMCAT_HOME}/bin/catalina.sh jpda

Then, we move on to remotely debug the class loading sequence – in which case I would be using Eclipse to do this. Also, we need to set a class loader breakpoint on sun.awt.AppContext;

Use the Open Type Command (Shift+Control+T) to navigate to the sun.awt.AppContext type.
Right-click on the class name in the Outline pane and choose ‘Toggle Class Load Breakpoint’.
Thereafter, we need to trigger the class loading sequence by connecting the debugger to the Tomcat instance and having the debugger come to a halt exactly at the point where the sun.awt.AppContext is loaded;

Figure 8: Connecting the debugger to the Tomcat instance and set the debugger to stop right after where the sun.awt.AppContext is loaded.
And there you go! It has been instantiated by the JavaBeans framework, which in this instance is being used by the Oracle Universal Connection Pool (UCP). We could therefore notice that the contextClassLoader is a final field and it looks like AppContext appears to be a singleton; so we can assume that this field is set once and once only during the instantiation of AppContext.

so we can infer that this field is set once and once only during the instantiation of.

I conveniently added the above code to my servlet context listener, causing it to execute during application start-up and it had the desired effect of remedying this particular memory leak.

How to Find Memory Leaks in Java Web Applications – Summary

In summary, JEE Applications’ PermGen ‘out of memory errors’ usually reside in the application itself (or a library used by the application) and is often compounded by classes in the JRE library holding references to the web application class loader or objects instantiated by the web application class loader.

The overall process of finding the causative agent of a leak is to utilize a Java Application Performance Monitoring (APM) solution. Just like Fusion-Reactor’s heap analyzer to source for uncollected web application class loader instance(s) and subsequently source for the root GC object that is directly or indirectly holding onto the class loader. When you find this object, you can now use the APM’s inbuilt debugger to discover how this object is being instantiated and then devise a means to modify its conventional behavior. This is done so that it does not continue to hold on to the class loader reference forever.