Exclusive ColdFusion Upgrade Promotion

Are you using an older version of Adobe ColdFusion? Now is the perfect time to upgrade! The FusionReactor has teamed up with Adobe to bring you an incredible deal.

Upgrade to ColdFusion 23 if you have CF9, 10, 11, CF2016 or CF2018 and get the following deal:

25% Discount on Adobe ColdFusion 2023

This offer is exclusively from the FusionReactor team – If you’re not already a customer, then you can also add FusionReactor into the offer and save even more. FusionReactor APM costs just $79 per month, see our APM pricing page.

 

Why Upgrade to ColdFusion 2023?

• Experience a newly evolved Adobe ColdFusion Enterprise (2023 Release) which lets you build your applications on-premises or across multiple cloud providers including GCP, AWS, and Azure. With centrally configured servers that have enhanced security, admin controls & communication, revolutionize your web development experience with Adobe ColdFusion.

How to Get this Offer

1. Verify Your Current Version: Ensure you are using an older version of Adobe ColdFusion.
2. Contact Our Sales Team: Reach out to our sales team to verify your eligibility and get a quote using the form provided
3. Upgrade to ColdFusion 2023: Use the link in the quote to purchase your ColdFusion 2023 upgrade at 25% off the regular price.

Deal ends September 30th, 2024

If you have questions then use the form or book a slot to discuss your needs. See what ColdFusion customers think of FusionReactor.

We Recommend Adobe Platinum Support

We strongly recommend you purchase Adobe’s Platinum Support option. Platinum is an optional annual maintenance/support product. The big advantage it gives you is that if you’re in support, you will automatically receive the next major version of ColdFusion when it’s available.

Whilst we cannot say for sure when this will be released, it’s been usual that Adobe released in 2-3 year cycles – the last one was in May 2023.  If you’re in support, the new license key will automatically be placed on your Adobe LWS account.  Platinum support also includes 24-7 access to Adobe support engineers.  Please note, that you can ONLY purchase Platinum together with a new, or upgrade CF license – you cannot buy Platinum support after the fact. Read more about Platinum support here.

Adobe ColdFusion Support Dates

 

Version	Released	Core Support ends
ColdFusion 2023	May 17, 2023	May 16, 2028
ColdFusion 2021	November 11, 2020	November 10, 2025
ColdFusion 2018	July 12, 2018	Ended
ColdFusion 2016	February 16, 2016	Ended
ColdFusion 11	April 29, 2014	Ended
ColdFusion 10	May 15, 2012	Ended

 

Get a Quote

Tell us which ColdFusion Edition you need and how many licenses you’re upgrading from and we will send you a personalized quote.

*

*

Checkboxes *

Existing FusionReactor Customer

New to FusionReactor

Number of CF Enterprise Licenses

Number of CF Standard Licenses

Any questions?

Captcha

If you are human, leave this field blank.

The post Save 25% on Adobe ColdFusion CF2023 appeared first on FusionReactor Observability & APM.

The post Important : Cloud support for FusionReactor versions 9.x and earlier, ends on July 1, 2024 appeared first on FusionReactor Observability & APM.

The post Updates to FusionReactor On-Premise: Streamlining for the future appeared first on FusionReactor Observability & APM.

The post Announcement: FusionReactor Cloud Incident on November 7th, 2023 appeared first on FusionReactor Observability & APM.

Java.lang.OutOfMemoryError is a common error that can occur in a Java application. It occurs when the Java Virtual Machine (JVM) runs out of memory and is unable to allocate any more memory to the application. There are several common causes of this error:

1. Memory leaks: If your application has a memory leak, it may continue to allocate new objects and use more memory even when they are no longer needed. Over time, this can cause the Java heap to fill up and run out of memory.
2. Large data sets: If you are working with very large data sets, your application may need a lot of memory to store and process the data. If the Java heap is not large enough, you may run out of memory.
3. Insufficient heap size: By default, the Java heap has a fixed size that is determined by the JVM. If your application requires more memory than the default heap size, you may run out of memory. You can increase the heap size by using the -Xmx command-line option when starting the JVM.
4. Poor memory management: If you are not using memory efficiently in your application, you may run out of memory even if you have a large heap size. You can optimize your application’s memory usage by choosing algorithms and data structures that use memory efficiently.

Here is a simple Java program that will cause an OutOfMemoryError

import java.util.ArrayList;
import java.util.List;

public class OutOfMemoryErrorExample {
  public static void main(String[] args) {
    List<Integer> list = new ArrayList<>();
    while (true) {
      list.add(1);
    }
  }
}

This program creates a list of integers and then adds a new integer to the list in an infinite loop. This will cause the Java heap to fill up and eventually run out of memory, resulting in an OutOfMemoryError.

To run this program, you will need to increase the maximum heap size by using the -Xmx command-line option when starting the JVM. For example, to set the maximum heap size to 2GB, you can use the following command:

java -Xmx2g OutOfMemoryErrorExample

This will allow the program to run for longer before running out of memory, but it will eventually throw an OutOfMemoryError.

What does Java do to avoid OutOfMemoryErrors

Java has several mechanisms in place to avoid OutOfMemoryError and other runtime errors:

1. Garbage collection: Java uses a garbage collector to periodically reclaim the application’s memory that is no longer being used. The garbage collector runs in the background and removes objects that are no longer reachable, freeing up memory for reuse.
2. Automatic heap expansion: If the garbage collector is unable to free up enough memory to satisfy a request for more memory, the Java heap will automatically expand to try to accommodate the request.  This can help prevent OutOfMemoryError by allowing the application to continue running even if the heap fills up.
3. OutOfMemoryError threshold: The Java heap has a maximum size that is determined by the JVM.  If the heap expands to reach this maximum size and the garbage collector is still unable to free up enough memory, an OutOfMemoryError will be thrown. This safeguard prevents the application from consuming all available memory on the system.

By using these mechanisms, Java can help prevent OutOfMemoryError and other runtime errors from occurring in your application.  However, it is still important to design and implement your application in a way that avoids excessive memory usage and other performance issues.

How to find a java.lang.OutOfMemoryError

To find a java.lang.OutOfMemoryError in a Java application, you can use a combination of the following methods:

• Check the logs: The JVM will typically log an OutOfMemoryError message when it occurs. Check the application’s log files for any error messages related to OutOfMemoryError or use a log monitoring tool.
• Use a heap dump: A heap dump is a snapshot of the heap at a specific point in time. You can use a heap dump to analyze the heap and identify the objects that are causing the OutOfMemoryError.
• Use a profiler: A memory profiler is a tool that can be used to analyze the performance of a Java application. It can be used to identify the parts of the code that are causing an OutOfMemoryError.
• Monitor memory usage: Use an Application Performance Management (APM) tool to monitor the application’s memory usage. This can help you identify any abnormal increase in memory usage that may indicate an OutOfMemoryError.
• Analyze the heap dump with a memory analyzer tool: Once you have a heap dump, you can use a memory analyzer tool to analyze the heap dump and identify the objects that are causing the OutOfMemoryError.
• Analyze the thread dump: Thread dump contains the stack trace of all the threads running in the JVM. Analyze the thread dump to identify the thread that is responsible for the OutOfMemoryError.

Once you have identified the cause of the OutOfMemoryError, you can take appropriate action to resolve the issue, such as increasing the heap size, fixing memory leaks, optimizing the code, or upgrading to a newer version of the JVM that has better memory management capabilities.

Conclusion – What Causes java.lang.OutOfMemoryError?

To resolve this error, it’s important to identify the cause of the issue and take appropriate action. This can include increasing the heap size, fixing memory leaks, optimizing the code, reducing the number of objects created, or upgrading to a newer version of the JVM that has better memory management capabilities. An Application Performance Management (APM) tool like FusionReactor can be helpful to monitor the memory usage and detect potential issues.

The post What Causes java.lang.OutOfMemoryError? appeared first on FusionReactor Observability & APM.

5 Common Errors You May See in Java Stack Traces

Many different types of errors can occur in a Java application. The specific errors you see in a stack trace depend on the problem’s nature and the application’s characteristics. Some common errors that you might see in a stack trace include the following:

1. NullPointerException: This error occurs when your application tries to access or modify a null object reference. This can happen if you try to call a method on a null object, or if you try to access a field of a null object.
2. ArrayIndexOutOfBoundsException: This error occurs when your application tries to access an array element at an index that is outside the bounds of the array. This can happen if you try to access an array element with a negative index or an index larger than the array’s size.
3. ClassNotFoundException: This error occurs when your application tries to load a class that cannot be found. This can happen if the class is not on the classpath, or if the class has been removed or renamed.
4. NoSuchMethodError: This error occurs when your application tries to call a method that does not exist. This can happen if you have compiled your code against a version of a library other than the one you are using at runtime, or if you have made a typo in the method name.
5. OutOfMemoryError: This error occurs when your application tries to allocate more memory than is available in the Java heap. This can happen if you have a memory leak in your application or if you are trying to process very large data sets.

Here are some checks you can put in place to avoid these common errors

How to avoid NullPointerException

NullPointerException is a runtime exception that occurs when your Java application tries to access or modify a null object reference. Here are some ways you can avoid this exception:

Check for null values: Before accessing or modifying an object, make sure that it is not null. You can use an if statement to check for null values. For example:

if (obj != null) {
  // access or modify the object
} else {
  // handle the error
}

Use the optional class: You can use the Optional class to wrap an object and check for null values in a more concise way. For example:

Optional<String> opt = Optional.ofNullable(str);
if (opt.isPresent()) {
  // access the object
} else {
  // handle the error
}

Use the @Nonnull annotation: You can use the @Nonnull annotation to specify that a method or constructor parameter cannot be null. This can help prevent null pointer exceptions by making it easier to catch null values at compile time.

Initialize variables and fields: Make sure that variables and fields are initialized to a non-null value before you try to access them. If a variable or field is not initialized, it will have a default value of null, which can cause a null pointer exception when you try to access it.

How to avoid ArrayIndexOutOfBoundsException

ArrayIndexOutOfBoundsException is a runtime exception that occurs when your application tries to access an array element at an index that is outside the bounds of the array. Here are some ways you can avoid this exception:

Check the array bounds before accessing an element: Before accessing an element of an array, you should always check that the index is within the bounds of the array. You can do this by using an if statement to check if the index is less than the length of the array. For example:

if (index >= 0 && index < array.length) {
  // access the element
} else {
  // handle the error
}

Use a for loop to iterate over the array: If you are iterating over the elements of an array, you can use a for loop to avoid going out of bounds. The for loop will automatically stop when it reaches the end of the array.

for (int i = 0; i < array.length; i++) {
  // access the element at index i
}

Use the ArrayList class: If you need a resizable array, you can use the ArrayList class instead of an array. The ArrayList class automatically increases its size as needed, so you don’t have to worry about going out of bounds.

List<String> list = new ArrayList<>();
list.add("item 1");
list.add("item 2");
// access an element with list.get(index)

How to avoid ClassNotFoundException

ClassNotFoundException is a runtime exception that occurs when your Java application tries to load a class that cannot be found. Here are some ways you can avoid this exception:

Check the classpath: Make sure that the class you are trying to load is on the classpath.  The classpath lists directories and jar files that the JVM searches for classes. If the class is not on the classpath, the JVM will be unable to find it and throw a ClassNotFoundException.

Use the fully qualified class name: Make sure you use the fully qualified class name, including the package name, when loading the class. If you use the wrong class name, the JVM will not be able to find the class and will throw a ClassNotFoundException.

Check for spelling errors: Make sure there are no spelling errors in the class or package names. If there are spelling errors, the JVM will be unable to find the class and throw a ClassNotFoundException.

Check for missing dependencies: If the class you are trying to load depends on other classes or libraries, ensure that these dependencies are on the classpath. If a dependency is missing, the JVM will be unable to find the class and throw a ClassNotFoundException.

How to avoid NoSuchMethodError

NoSuchMethodError is a runtime error that occurs when your Java application tries to call a method that does not exist. Here are some ways you can avoid this error:

Check the method signature: Make sure that the method you are trying to call has the correct name and parameter types. If the method signature is incorrect, the JVM will not be able to find the method and will throw a NoSuchMethodError.

Check the class hierarchy: Make sure that the class you are calling the method on is correct. If you are calling a method on a subclass, make sure that the method is defined in the subclass or in one of its superclasses. If the method is not defined in the class hierarchy, the JVM will throw a NoSuchMethodError.

Check for spelling errors: Make sure that there are no spelling errors in the method name or parameter types. If there are spelling errors, the JVM will not be able to find the method and will throw a NoSuchMethodError.

Check for missing dependencies: If the class you call the method on depends on other classes or libraries, ensure that these dependencies are on the classpath.  If a dependency is missing, the JVM will be unable to find the method and throw a NoSuchMethodError.

How to avoid an OutOfMemoryError

OutOfMemoryError is a runtime error that occurs when your Java application tries to allocate more memory than is available in the Java heap.  Here are some ways you can avoid this error:

Monitor your application’s memory usage: FusionReactor can monitor your application’s memory usage and identify potential memory leaks. By monitoring your application’s memory usage, you can identify areas of your code that are using large amounts of memory and optimize them to reduce the risk of running out of memory.

Use a larger heap size: If your application requires a large amount of memory, you can increase the size of the Java heap by using the -Xmx command-line option when starting the JVM. For example, to set the maximum heap size to 2GB, you can use the following command:

java -Xmx2g MyClass

Use a memory-efficient data structure: If you are working with large data sets, you can choose a data structure that uses memory efficiently. For example, instead of using a HashMap to store large amounts of data, you could use a TreeMap, which uses less memory because it stores the data in sorted order.

Use a memory-efficient algorithm: You can also optimize your application’s memory usage by choosing algorithms that use memory efficiently.  For example, you can use an iterative algorithm instead of a recursive one, reducing the risk of running out of memory.

How do you find common errors in your Java application?

There are several ways to find common exceptions in a Java application:

• Reviewing log files: Exceptions are typically logged in the application’s log files. One way to find common exceptions is to review the logs and look for recurring exception messages regularly.
• Using an Application Performance Management (APM) tool such as FusionReactor: APM tools can monitor the performance of an application in real-time and provide detailed information about exceptions, including the frequency and cause of each exception.
• Setting up exception tracking and alerts: You can set up exception tracking and alerts in your application so that you are notified when specific exceptions occur and then analyze the data to identify common exceptions.
• Profiling your application: Profiling tools can give insight into how your application runs and help you identify performance bottlenecks and common exceptions.
• Using an exception handling framework: Some exception handling frameworks provide a way to group and count the exception by their type, message, or even custom tags.

It’s important to note that finding common exceptions is an ongoing process and requires regular monitoring and analysis of the application’s performance to ensure that the exceptions are identified and resolved promptly.

Conclusion – 5 Common Errors You May See in Java Stack Traces and How to Avoid Them

In this article; 5 Common Errors You May See in Java Stack Traces and How to Avoid Them, we have looked at these common errors that you might see in a stack trace: NullPointerException, ArrayIndexOutOfBoundsException, ClassNotFoundException, NoSuchMethodError, and the OutOfMemoryError. We have explained the errors and described how they could be avoided. If you are looking for less common exceptions, check out our post Diagnosing Less Common Java Exceptions: Techniques and Tools.

The post 5 Common Errors You May See in Java Stack Traces and How to Avoid Them appeared first on FusionReactor Observability & APM.

We are committed to continuing our focus on “the details” and ensuring that our customers are armed with the right information and insight to pinpoint issues as quickly as possible.

In recent years though, the “trend” within monitoring (observability) has moved. We’re witnessing a major shift towards providing capabilities to support multiple languages, capturing metrics & traces as well as ingesting and monitoring the enormous and ever growing amount of application and system logs. This is being combined with the need to support the capture of telemetry from multiple different technologies used within your infrastructure and cloud service architectures. The future will be to combine all of this data and provide AIOps using Machine Learning (ML) techniques to give root cause answers and automated solutions before you’re even aware that anything is even going wrong. We anticipate the next wave will be predictive monitoring and will be based on broad data analysis and observability combined with ML.

To support these capabilities and the shift in monitoring requirements, we have dedicated the core of this release to re-building and re-architecting our complete monitoring infrastructure. Using the advice and technical direction provided by Gartner, Inc we now have a powerful, modern, and scalable architecture that is perfectly positioned to take advantage of new open-source technologies, such as Loki, Cortex/Prometheus, and Tempo, as well as supporting a broader range of monitoring agents using the OpenTelemetry standard. To complement these data handling components we have integrated a new, rich visualization layer using Grafana. Because Grafana seamlessly integrates Loki, Cortex/Prometheus, and Tempo, it allows us to create a multi-tenant, unified observability platform dashboard solution for visualizing Logs, Metrics, and Traces in one place. For FusionReactor 9, much of the new functional capability is focused on log monitoring, and we can now ingest, monitor, and index any logs (not just from FusionReactor!). FusionReactor uses Loki, which is an open-source project for log aggregation developed by Grafana Labs. Loki indexes the metadata e.g. server and application names, and the actual log content is stored as chunks in object stores. We have created several custom dashboards to present the log data in ways that we believe will accelerate the task of pinpointing errors. One such dashboard shows the correlation between resource consumption and logs.

We have also included several application based dashboards which we hope will demonstrate the power and possibilities which we have open to us in the future. These include database, request performance and resource performance (as can be seen below).

We are also taking the opportunity to share experimental dashboards, which will highlight our ability to deliver new types of data as the platform evolves. An example of this is the Node exporter dashboard.

The post Announcing FusionReactor 9.0 appeared first on FusionReactor Observability & APM.

Have you wished you could change the name given to your monitored instance in FusionReactor (the name that appears in the UI and various reports/emails)? Did you know you could change it easily, on the fly, from within the instance and without need of restarting your instance?

[/vc_column_text][us_separator size=”small”][vc_column_text]

How to change the instance name

Just use the menu labelled “FusionReactor” (on the top left), and from there choose “Settings”, then the tab for “Instance Name”. See below. After changing it, click the “Save FusionReactor Settings” button in the bottom right corner of the screen (not visible below).

[/vc_column_text][us_separator size=”small”][us_image image=”57351″][us_separator size=”small”][vc_column_text]

If you don’t see an Instance Name option on that Settings page, then you are looking at the FRAM instance, typically running on the 8087 port. Change to port 8088 or whatever port should be used for the instance in question.

[/vc_column_text][us_separator size=”small”][vc_column_text]

Why you may want to change the name

Why might someone want to rename their instance? As you may know, when you implement FR using the FRAM (Admin Mgr) tool and its Instance Manager, that picks a name for your instance. While you can change it at that time, you (or the person installing FR) may not have bothered to change the name it picked.

But as this name appears in the FR reports, CP alerts, and on the FR Enterprise Dashboard (as well as in the top right of your instance itself), you may decide later that you wish you had given it a more helpful name. With the above, you can do just that!

[/vc_column_text][us_separator size=”small”][vc_column_text]

Some other considerations

Note that the instance name also is stored within the java configuration of your instance, in terms of the javaagent and (optional) agentpath java args for FR. It’s also used for the name of the folder for the instance, as found within your “instances” folder of the FusionReactor directory created during installation.

(Note that if you choose to do manual installation of FR, where you download the fusionreactor.jar, and manually configure your jvm args, then you will have picked the name in doing that, and would have created the folder for the instance. More important, you won’t have run the FR installer I refer to, nor will you have the FRAM instance I refer to. But you can still rename the instance the way I describe.)

Anyway, these values (the name in the java args, and the folder name for your instance) are NOT changed when you change the instance name as described above. There’s no problem. They just won’t be in sync with the other elements that show the new name.

If you DO for some reason want to change those, you can, manually. Just stop the instance that FR is monitoring, then rename those values, and restart it. Do note that in the case of the javaagent arg, the name appears twice:  once to represent the folder in which the instance’s fusionreactor.jar is located, and once to represent the instance name.

[/vc_column_text][vc_column_text]

For more blog posts from Charlie Arehart, see his posts here as well as his posts at carehart.org. And follow him on Twitter and other social media as carehart.

[/vc_column_text][/vc_column][/vc_row]

The post Changing your FusionReactor instance name, easily appeared first on FusionReactor Observability & APM.