VisualVM Buffer pool – what is the buffer pool?

The buffer pool space is located outside of the garbage collector-managed memory. It’s a way to allocate native off-heap memory.  What’s the benefit of using buffer pools? To answer this question, let’s firstly learn what byte buffers are.

Byte Buffer

Non-Direct Buffer

java.nio package comes with the Bytebuffer class. It allows us to allocate both direct and non-direct byte buffers. There is nothing special about non-direct byte buffers – they are an implementation of HeapByteBuffer created by ByteBuffer.allocate() and ByteBuffer.wrap() factory methods. As the name of the class suggests, these are on-heap byte buffers. Wouldn’t it be easier to allocate all the buffers on the Java heap space then?   Why would anyone need to allocate something in a native memory? To answer this question, we need to understand how operating systems perform I/O operations.   Any read or write instructions are executed on memory areas which are the contiguous sequence of bytes. So does byte[] occupy a contiguous space on the heap? While technically it makes sense, the JVM specification does not have such guarantees. What’s more interesting, the specification doesn’t even guarantee that heap space will be contiguous itself! Although it seems to be rather unlikely that JVM will place a one-dimensional array of primitives in different places in memory, byte array from Java heap space cannot be used in native I/O operations directly. It has to be copied to a native memory before every I/O, which of course, leads to obvious inefficiencies. For this reason, a direct buffer was introduced.

Direct Buffer

A direct buffer is a chunk of native memory shared with Java from which you can perform a direct read.

An instance of DirectByteBuffer can be created using the ByteBuffer.allocateDirect() factory method. Byte buffers are the most efficient way to perform I/O operations and thus, they are used in many libraries and frameworks – for example in Netty.

Memory Mapped Buffer

A direct byte buffer may also be created by mapping a region of a file directly into memory. In other words, we can load a region of a file to a particular native memory region that can be accessed later.  As you can imagine, it can give a significant performance boost if we have the requirement to read the content of a file multiple times. Thanks to memory mapped files, subsequent reads will use the content of the file from the memory, instead of loading the data from the disc every time it’s needed. MappedByteBuffer can be created via the FileChannel.map() method.

An additional advantage of memory mapped files is that the OS can flush the buffer directly to the disk when the system is shutting down. Moreover, the OS can lock a mapped portion of the file from other processes on the machine.

Allocation is Expensive

One of the problems with direct buffers is that it’s expensive to allocate them. Regardless of the size of the buffer, calling Buffer.allocateDirect() is a relatively slow operation. It is, therefore, more efficient to either use direct buffers for large and long-lived buffers or create one large buffer, slice off portions on demand, and return them to be re-used when they are no longer needed.   A potential problem with slicing may occur when slices are not always the same size. The initial large byte buffer can become fragmented when allocating and freeing objects of different size.  Unlike Java heap, direct byte buffer cannot be compacted, because it’s not a target for the garbage collector.

Monitoring Buffer Pools

If you’re interested in the amount of direct or mapped byte buffers used by your application, then you can easily monitor them using FusionReactor.   FusionReactor provides a break-down of all the different memory spaces.   Simply navigate to Resources and then Direct – Buffer Pools.

VisualVM Buffer pool

By default, the Direct Buffer Pool graph is displayed. You can switch to the Mapped Buffer Pool by clicking on a drop-down in the top right corner. Java will grow those pools as required so the fact that Direct Memory Used covers Direct Capacity on the graph above, means that all buffer memory allocated so far is in use.

Please note – you can limit the amount of direct byte buffer space that an application can allocate, by using -XX:MaxDirectMemorySize=N flag.   Although this is possible, you would need a very good reason to do so.

Try FusionReactor for VisualVM Buffer pool tools

Start Free Trial Compare Editions Pricing

In this post Matthew Clemente discusses FusionReactor for Docker Swarm (Part 2, Alerting). This article originally appeared on his blog

Alerting in FusionReactor for Docker Swarm

Previously I blogged, in earlier posts, about installing and deploying FusionReactor Cloud to monitor CFML applications on Docker Swarm. The next step is to to configure its updated alerting system to let you know if anything is amiss.

Basics of Alerting in FusionReactor for Docker Swarm

Alerting is one of the primary three tabs within the FusionReactor Cloud portal, with sub-tabs for Alerts, Checks, and Subscriptions.

• Subscriptions are the who and how of Cloud alerts – that is, who should get alerted and how should they receive the alert? Subscriptions also provide control over when – you can limit them to certain days and/or times. To be of any use, a Subscription must be attached to a Check.
• Checks refer to the circumstances necessary to trigger an Alert. Broadly speaking, a Check is tied to either the status of a server or a defined set of data points (Memory Usage, Response Time, etc). Subscriptions are attached to these Checks and triggered when the threshold or status is met. These are the why – as in, why should an Alert be sent.
• Alerts, finally, are the what. Alerts are the consequence of Checks and Subscriptions – when a Check triggers a Subscription, an Alert is sent and logged.

So, taking them one at a time, in a little more depth:

Setting Subscriptions – Alerting in FusionReactor for Docker Swarm

As you’ll see, FusionReactor Cloud offers far more granular control than the on-premise edition – this comes at the cost of significantly more configuration necessary to get it up and running.

In order to set up a Subscription, you’ll first need to enable one of the many available integrations. An integration is a way of contacting someone; options include Slack, PagerDuty, custom webhooks, and more. We’ll just stick with Email, as it’s the easiest and most obvious choice.

Now, I’m of the opinion that the Email integration should be enabled by default, but it’s not. So, once you’re logged into your account, click the Account button in the upper right, and select the Configuration option.

Click the Configure button for Email, then all you need to do is choose the Save option… and the Email integration is enabled.

On to the actual Subscription setup. Proceed to the Alerting tab and the Subscriptions sub-menu. In the upper right, the +Subscription will open a tab for actually setting up who gets alerts (and when it happens).

Here, you start to see the level of control that Alerting in FusionReactor Cloud provides. You can restrict this Subscription to certain days of the week, or hours of the day. This may be helpful, for example, if you have a separate team for after-hours. Or, you can have separate Subscriptions for Warning vs. Error states – the latter being set to higher priority, or sent via a different integration.

We’re setting up a basic email subscription, so we’ll name it “Web Team Email Alerts”, or something comparable, and choose the Email Service.

The default subject provided, “FusionReactor alert”, is fine; in the actual alert email this will be followed by the name of the Check that was triggered. Finally, we’ll add the email address we want to send the alert to, and click “Save”.

Your Subscription is now saved; you’ll see its details listed in the main Subscriptions panel, with the ability to duplicate/edit/delete, as well as test it. It hasn’t been linked to any Checks yet, so let’s do that next.

How to configure Checks – Alerting in FusionReactor for Docker Swarm

In the Alerting section, within the Checks sub-menu, click +Check in the upper right to open the tab for building out a new Check.

Within this panel there’s a lot going on. I’ll walk through the options one step at time, but we’ll save actually creating a Check for the next blog post.

1. There are two types of Checks, Threshold and Status.Status checks are the simpler of the two – they are triggered if a server or group of servers goes offline for a period of time.Threshold checks, as explained in the documentation, “are used to alert when a metric value crosses a defined threshold.” Basically, FusionReactor is continually monitoring hundreds of metrics from your servers/applications (CPU Usage, Active Requests, etc.). Threshold checks enable you to select one of these metrics and, based on a percentage or frequency of its occurrence, trigger an Alert.

   Note that the Name entered here for the Check will be included in Subscription notifications that get sent, so it should be descriptive and clear. Optionally, you can also fill in a Description, for internal reference.

2. The Check is further refined by selecting the type of entity it should be applied to: Server Instance, Group, or Application.Server Instance: Could be a physical server, VM, or a container instance. If you’ve got three container replicas for a Swarm service, each is a server instance. Generally, for Swarm deployments, you won’t be choosing this option.Group: Server instances can be added to one or more groups – this is done on the startup of the server, via Java properties passed to FusionReactor. The FusionReactor module for CommandBox makes these easy to set, via fusionreactor.cloudGroup in server.json. I’ve found Groups very helpful when deploying to Swarm; they make it easy to monitor multiple container replicas as a single entity.

   Application: The name says it; your applications are listed here. Even if the application is replicated across nodes, you can apply a Check to it.

3. Checks are built by first selecting a metric you’d like monitored and then defining a threshold at which you’d consider it an error – for example, if the metric Memory Usage exceeds the threshold of 80%. Three additional selectors, formatted as a sentence, can then be used to further specify when the Check should be triggered.This “sentence” format is meant to be an intuitive way to define your Checks. Let’s tackle its options in reverse order:
   • Check timeframe: The Cloud alerting engine runs once every 60 seconds. In order to allow time for ingesting/synchronizing data, the smallest window you can select here is 5 minutes. This is the timeframe within which FusionReactor monitors your error threshold, as well as the period of time it will take for any erroring Checks to return to an OK state. While I’m sure longer timeframes have their uses, I want my error notifications to be as close to realtime as possible, so I’ve exclusively used the “5 minutes” option here.
   • Greater/Less Than: Set the error state as greater or less than the threshold.
   • Data point type: There are four possible options here, three of which are self-explanatory: single, all, and average. I found the count of option to be less intuitive; it brings up an additional option displayed as ( 1/5 ), where you select the first number.The second number, I found out, refers to the timeframe of your check. Because the engine runs every minute, within a 5 minute timeframe there are 5 data points (so longer timeframes increase the second number). Selecting 1/5 would be the same as single, and selecting 5/5 is the same as all – the count of option gives you the ability to choose everything in between.
4. Pick the subscription(s) that this check should trigger. Checks can trigger more than one subscription alert.
5. Finally, a preview graph is provided underneath, illustrating how your Check compares to the metric historically, so that you can see when it would be triggered.

After clicking Save to add the Check, you’ll see its details listed in the main Checks panel. As with Subscriptions, from here you can duplicate, edit, or delete it. You can also temporarily disable Checks from this page.

Configuration of Alerting in FusionReactor for Docker Swarm

Finally, we’ll move on to Alerts; fortunately, there’s nothing we need to configure here. The Alerts panel provides logged reporting of your Checks; any time that a Check changes status, it’s recorded here.

Basic logging here includes when Checks are added, paused, or deleted. These changes are recorded, but do not trigger Subscriptions. When a Check moves between the OK, WARNING, and ERROR statuses, the Subscriptions that are triggered will also be recorded here. The “View” option will open a panel with more information about the Alert/Check/Subscription.

Get free trial: Alerting in FusionReactor for Docker Swarm

If you want to see the power of alerting in FusionReactor for docker swarm for yourself  you can get a trial of FusionReactor Cloud for free, just create your account and download the software.

For more information about setting up Alerting in FusionReactor for Docker Swarm contact the FusionReactor Cloud team.

In this post Matthew Clemente discusses FusionReactor for Docker Swarm. This article originally appeared on his blog

FusionReactor for Docker Swarm (Part 1, Installation)

Moving a standard ColdFusion installation to Docker Swarm requires rethinking – and frequently rewiring – portions of our infrastructure. Today, that means reconfiguring how we deploy FusionReactor to monitor our applications.

If you’re already using FusionReactor, you know its value (and if you’re not using it, you probably should be).¹ Moving to Swarm means that you can’t continue to use the traditional on-premise installation of FusionReactor; it’s not suited to the distributed, dynamic environment of containers. Fortunately, there’s an alternative: FusionReactor Cloud.

In this post, I’ll outline one approach to deploying your applications with FusionReactor Cloud.

Two notes; first, this post assumes a degree of experience with Docker Swarm and CommandBox – learning to configure FusionReactor to monitor CFML apps on Docker Swarm isn’t of much use unless you’ve already worked out the process of deploying those apps in the first place. Second, there are a lot of moving pieces here, so if I gloss over details you think are important, please let me know and I’d be happy to clarify.

FusionReactor Cloud

Cloud is an extension of the standard FusionReactor installation.² While its interface differs considerably from the on-premise version, the functionality tracks pretty closely. I’ll review some of the differences in a future post. For our purposes, its most significant feature is that FusionReactor Cloud supports dynamic server monitoring. That is, you can use it for monitoring CFML apps running in Docker containers.

Before we get into how to use it, let’s address how to get it, and what it costs.

Pricing and Licenses

There’s no reference to Docker or containers in the Cloud licensing section of the FusionReactor pricing page, which is confusing. Here’s what I found: FusionReactor Cloud’s current fair usage model allows/supports monitoring up to 5 container instances per license.

Because the ratio of nodes-to-containers can vary considerably from one company to the next, this model may or may not work for your Swarm setup. If that’s the case, I’ll pass along the advice that I was given: Reach out to the FusionReactor team to discuss your situation and Docker configuration. They’re a developer friendly organization, willing to help users transition to the cloud.

The rest of the steps here assume that you have a Cloud license available. If you don’t, you can register for a free trial.

Installation

We’ll be using the CommandBox Docker image; it makes configuration and deployment very simple. If you’re not familiar with CommandBox, I encourage you to take a look; it’s a remarkable tool for CFML development. Also, the rest of this post won’t make sense if you’re not familiar with how CommandBox can be used to spin up ColdFusion servers.

There’s a FusionReactor module on ForgeBox. When added as a dependency in an application’s box.json, it installs FusionReactor for the server.

{
  "name": "your.application.name",
  "version": "0.0.0",
  "dependencies":{
    "commandbox-fusionreactor" : "2.4.15"
  }
}

There are two approaches to ensuring that this module is installed and ready when your containerized CommandBox server starts:

• The first is to set the environment variable BOX_INSTALL to true in your Docker stack file, which triggers the box install command to be run before the server is started.
• The second option is use a custom Dockerfile, building from the Ortus image. In the classic tradeoff, this approach is more work, but it makes fine-grained customization of the image possible. When doing this, you need to include RUN box install prior to the server warmup and start, to ensure the dependencies are installed.

Configuration – FusionReactor for Docker Swarm

The FusionReactor module and its settings have a dedicated page within the CommandBox documentation. Thanks to CommandBox, we can configure the module within our server.json, like so:

{
    "name": "server.name.here",
    "othersettings": "etc. etc. etc.",
    "jvm": {
        "args": "-Dfrstartupdelay=30000 -Dfr.odl.activation.retry_amount=10 -Dfr.odl.activation.retry_interval=10000 -Dfrlicenseservice.logMessages=true"
    },
    "fusionreactor": {
      "enable": true,
      "licenseKey": "${FR_LICENSEKEY}",
      "licenseDeactivateOnShutdown": true,
      "cloudGroup": "tags,for,organization"
    }
}

FusionReactor for Docker Swarm – Settings

Here’s a breakdown of the settings used above, beneath the fusionreactor key:

• enable: Pretty self explanatory here. If this is set to false, FusionReactor functionality is disabled. This might be something you’d want to do for testing or in different environments.
• licenseKey: I’m passing this in via an environment variable set in my stack file. For Docker deployments, this is your FusionReactor Cloud license. In production, you’d want to set the environment variable via a Docker secret.
• licenseDeactivateOnShutdown: This maps to the FusionReactor Java property⁴ frlicenseservice.deactivateOnShutdown. When set to true, the instance being monitored will deactivate its license on shutdown. Obviously, that’s what you want for a containerized server.
• cloudGroup: Mapped to the fr.cloud.group Java property. These group names are really helpful in organizing your reporting and alerts within FusionReactor Cloud. They’re effectively tags for organizing your servers.

Assuming that the rest of your CFML stack is in order, with your box.json and server.json configured, you’re ready to deploy to Swarm. The resulting CFML containers will be monitored within the FusionReactor Cloud portal and their licenses will automatically be deactivated as the containers are replaced.

Some Final Notes

Getting FusionReactor installed in your containers and deployed to Swarm is half the process; the second half is working through the differences between the on-premise installation and FusionReactor Cloud. In my next post, I plan on examining some of those differences and discussing the process of setting up FR Cloud alerts that mirror the on-premise functionality. Until then, good luck Dockering

If you would like to know more about FusionReactor Cloud for Docker Swarm contact our Cloud team.

Intergral showcases the first Java APM solution designed for use across the whole Software Development Lifecycle, at O’Reilly Velocity conference – London, 2018

FusionReactor goes beyond traditional Java monitoring capabilities by adding low-level profiling and debugging, giving developers and DevOps the insight needed to identify performance issues and production problems in the shortest possible time.

Debugging in production is often considered to be the holy grail of root-cause analysis – just imagine the benefit of being able to introspect variable scope at production runtime!  However, the performance degradation and breakpoint impact implications associated with traditional debuggers have rendered them useless in production environments. Intergral GmbH, makers of FusionReactor have developed an extremely low overhead Java debugger (Patent Pending) that can be safely and securely used across the whole Software Development Lifecycle (SDLC), including production.

Intergral GmbH, makers of FusionReactor are once again sponsoring The O’Reilly Velocity conference in London, 2018.  The FusionReactor team will be located at booth #109 and will be on hand to demonstrate how it’s possible to debug and profile Java applications at production runtime…

“Debugging a Java application which is running in production is not something most people think of doing. There is typically a performance overhead as well as a number of technical challenges which make this impracticable using existing debugging technologies”, said David Tattersall, CEO of Intergral GmbH, makers of FusionReactor “Intergral have addressed these issues and developed a browser-based Java debugger, which can be used in a production environment and which we believe is a game changer in accelerating the time needed to isolate production problems and performance bottlenecks”.

FusionReactor is used by 1000’s of developers and DevOps to cut issue isolation time down from days to minutes. FusionReactor combines the core APM features of metric instrumentation and alerting with low-level profiling and debugging – it is the only product of its kind which is designed for use across the whole Software Development Life Cycle.

Pricing and availability:

FusionReactor is a hybrid APM solution, available as on-premise and/or SaaS (Cloud-based).   Four editions are on offer, Ultimate, Enterprise, Standard and Developer. The Ultimate and Developer Editions include the debugger and low-level profiling tools, Enterprise Edition allows monitoring of multiple instances and servers from a single Dashboard and Standard Edition includes all the core monitoring features. FusionReactor may be purchased as a monthly/annual subscription or as a one-time license. Standard Edition pricing starts at just US$ 39 per month, per server.

FusionReactor Cloud provides extended data retention, focus on “issue related transactions” and includes advanced alerting capability with seamless integration with tools such as Slack, PageDuty and Twilio etc.

About Intergral GmbH:

Intergral is a leading application intelligence company. Our flagship product, FusionReactor provides real-time visibility and alerting of application performance issues and can be effectively used across the whole Software Development Life Cycle. Thousands of customers trust FusionReactor to monitor their applications, enabling them to identify and respond faster to performance and stability problems. FusionReactor’s aim is to ensure applications run at peak operational and business performance. Learn more at www.Fusion-Reactor.com.

This year, the FusionReactor team are once again proud sponsors of the O’Reilly Velocity conference, which is being held in London between 30th October and 2nd November 2018.

We are offering a 25% discount on all event tickets – you can receive your discount, using the following coupon – FusionReactor25

We will be demonstrating FusionReactor at the event and showing you that when applications break or fail to perform, developers and DevOPS teams must go deeper than simply analyzing resource usage or business transaction fail rates – they need real-time insight and transparency to get a clear picture of why an application is actually failing or slowing down as these issues are happening in production.   Please come and see us on booth #212

Under the motto of “Build Systems that Drive Business” – the Velocity conference is an amazing opportunity for Software Engineers and DevOps to build skills to meet the pressing demands of your work, hear from your peers and meet with industry leaders.
The conference will deal with aspects such as building secure systems, monitoring / observability / performance and microservices to name a few. Through expert-led presentations (from the likes of The University of Cambridge, Google and Microsoft), you’ll learn to build high-performance, resilient, and secure systems.

Read more about the London Velocity conference here – https://conferences.oreilly.com/velocity/vl-eu

Register here and use code FusionReactor25 to receive a 25% discount.

A customer recently wrote into the FusionReactor Support Team regarding their ColdFusion server, which was crashing on average once per week.  We have used FusionReactor and specifically the archive viewer, to take the customers archived log data and diagnose the root cause of the issue.

This blog will explain the process of how it is possible to diagnose the root cause of the crash with the Archive viewer, a feature introduced in FusionReactor 7.2.0 that allows users to display and graph historical log data in a similar fashion to viewing data in the “live or recent” monitored application server.

Starting by viewing the resource log it was possible to see that the total memory allocated by the JVM was exceeding the maximum memory configured in the ColdFusion server:

Resource.log

From there it was then obvious that there was clearly an issue with memory usage in the server, looking in the memory summary logs it was then possible to see that the actual memory usage was only 20% of the usable memory, however, the committed memory was high.

Memory Summary Usage

The fact that the heap usage was only 20%, yet the committed memory was high points to the fact that a particular memory space was attempting to use more memory than it had available. At this point, it was then possible to log at the logs for each available memory space. From this, it was possible to see that the old gen memory space allocated had committed 14GB of its available space:

OldGen Memory Usage

The Old Gen memory space is used for long living objects that are committed to the JVM for longer periods of time, this includes objects such as the ColdFusion scopes and classes that are loaded into memory, this space is only cleared when major garbage collections occur within the JVM.

In a typical ColdFusion server, you will see considerably more minor garbage collections than major garbage collections, however using the gc (garbage collection) logs it was possible to see that large garbage collections were occurring on average every 4 minutes and taking between 750 ms and 1.5 seconds each time:

GC Marksweep times

Time spend on major garbage collections in Java will consume large amounts of CPU and reduce the performance of the application server.

Using the classes log file it was then possible to see that there was a very large number of classes loaded into the JVM, which would explain why 14GB of OldGen memory was committed to memory and the JVM was no longer able to allocate the required memory needed to run the application:

Count of loaded classes

It is important to note that the fact that the number of loaded classes is high is not the only cause of the Application server running out of OldGen Memory, but it is indeed a factor. In the Case of this ColdFusion server, the OldGen will contain the session scops, user session tracking, all loaded classes and many other objects that will need to exist for a longer period of time.

However, the fact that classes are being loaded periodically in this manner is highly irregular and would be cause for concern. If I take another CF server that is healthy I would see something similar to:

Example of the count of loaded classes for a similar ColdFusion server that is in a healthy state

From this it is possible to see that there is a much lower class count and most importantly the graph is flat, this is what I would expect as classes committed to the OldGen space should not be cleared and reloaded into memory this often, Only if Java believes the classes loaded are too old and there is a potential that the bytecode has changed.

From this information, it was then possible to recommend increasing the maximum heap space available on the JVM and potentially the available resource for OldGen memory, trimming down the running CFML applications would also be a possible solution to reduce the Old Gen and heap usage of the running JVM.

With the release of FusionReactor 7.4.1 we added support to track async requests in ColdFusion 2018, these async functions will be tracked as a child transaction of the web request.

This addition will allow you to track whether any asynchronous call you are making in your CFC/CFM files is slowing down your request, in previous versions of FusionReactor the only way this would be possible would have been to use the debugger or profiler.

Each async call will be tracked as a child request of the CFC/CFM script it was executed inside, so it will be visible in the relations tab of the requests details, due to the nature of the asynchronous call it is only possible to link a transaction back to the CFC/CFM script after the async function is complete.

Below is an example of a series of async calls run as both named and anonymous functions.

Example CFML

<cfscript>
getAccountBalance = function () {
var balance = 120000;
return balance;
}
function payCreditCardBill(accountBalance) {
var ccBill = 1890;
return accountBalance – ccBill;
}
payEMIs = function (accountBalance) {
var mortgageEMI = 1000;
var carLeaseEMI = 750;
var healthInsuranceEMI = 250;
return accountBalance – (mortgageEMI + carLeaseEMI + healthInsuranceEMI);
}
miscellenousExpenses = function (accountBalance) {
var shopping = 1500;
var clubExpense = 1000;
var casinoExpense = 2000;
return accountBalance – (shopping + clubExpense + casinoExpense);
}
function checkBalanceaccountBalance) {
while (accountBalance > 5000) {
accountBalance = miscellenousExpenses(accountBalance);
writeOutput(“checkBalance = ” & accountBalance & “<br/>”);
} if (accountBalance < 5000)
throw(message = “Account balance below threshold!!!”, type = “info”);
}
errorHandler = function (error) {
if (error.message contains “Account balance below threshold!”) {
return “You have reached your spending limit!”;
}
}

future = runAsync(getAccountBalance).then(payCreditCardBill).then(payEMIs).then(miscellenousExpenses).then(checkBalance).error(errorHandler);
writeOutput(future.get());
</cfscript>

Request tracking in FusionReactor

In FusionReactor we can see each async request is tracked under the master request syncBankExample.cfm. The flavour of each request will be CFUDF the tag used by ColdFusion to execute these functions.

An important thing to note is that how you declare your function to run asynchronously will change the accuracy of how well FusionReactor will track the async call. The methods payCreditCardBill and checkBalance can be referenced by name in the description of the runAsync method, however, every other method cannot. This is because payCreditCardBill and checkBalance are declared with the following syntax:

function functionName() { … )

The other asynchronous functions use the syntax:

functionName = function () { … }

For this reason, we highly recommend that anyone using the asynchronous calls uses the syntax “function name() { … }”

With the release of FusionReactor 7.4.0 we’ve added some new support for a number of ColdFusion tags (we already had support for CFHTTP and CFQUERY). This now means in both ColdFusion and Lucee the following tags will now be tracked as a child transaction of the web request:

• CFLDAP
• CFFTP
• CFMAIL
• CFIMAP
• CFPOP

Providing this support will allow you to spot if one of these tags would be slowing down a CFC / CFM call made within your CFML application, where before you would be able to see that a CFC / CFM call was slow, but not explicitly identify what was causing this without using the production debugger and profiler.

For each tag, each attribute is tracked as a transaction property allowing you to see exactly what variables are being used by the tag. The only exception to this is the password, which will not be tracked in FusionReactor.

Each tag will be tracked as a child request of the CFC/CFM script it was executed inside, so it will be visible in the relations tab of the request details. The child request will be generated in FusionReactor as soon as it begins executing, so will be visible under the Requests activity page as a relation.

Below are examples for each tag running on ColdFusion 2018, for Lucee the tag attributes will need to be modified.

CFLDAP

Example script

This code snippet will attempt to authenticate against an LDAP server with a given user and set a variable of isAuthenticated based on the output of the tag, when we run this snippet inside a CFC we see:

You can see here the query performed on the LDAP server and that no error occurred, so we can assume there was no issue authenticating with the server.

When viewing the properties tab of the CFLDAP transaction you are able to view all the attributes used in the tag:

CFFTP

Example script

This code snippet will establish a connection to the FTP server, retrieve a list of the directories and then terminate the connection, running this code in a CFC will result in:

Here it is possible to see the 3 distinct CFFTP calls and the time taken for each, each call will have a unique set of attributes and these can be seen in the properties tab of the transaction details.

CFMAIL

Example script

This example code will send a simple test email, running this code inside a CFC file will result in the following:

You can see a CFMAIL tag with the action send tracked in FusionReactor.

CFIMAP

Example script

This script will establish a connection to the IMAP server then close this connection, running this code snippet in a CFC file will result in:

You can see 1 request per CFIMAP call, so we see the connection open and close tags as separate requests. Like the CFMAIL tag attributes used in each tag are tracked as properties of the transaction

CFPOP

Example script

This script will query the mail server for the size of the user’s inbox and print this in the browser, running this in a CFC will result in:

You can see here the CFIMAP call took 4.9 seconds to execute, with an older version of FusionReactor it would be difficult to track down why CFM script was slow to execute without debugging server but now it is easy to see.

FusionsReactor 7.3, the latest release in the ColdFusion and Java monitoring tool has tons of new features and improvements. This article will be an overview of some of the most valuable aspects which affect the bottom line and ultimately guide on how FusionReactor can work for you.

You can find them listed also in the FR “release notes” technote (https://www.fusion-reactor.com/support/kb/frs-431/). Please note, if you scroll further you can see how the APM has developed throughout the installments.

Keeping up to date with the developments in platforms

There are a few FusionsReactor 7.3 enhancements which are specific to particular supported platforms.   Support is now included for Java 10, ColdFusion 2018 as well as Solr.

More developments include additions in application servers to the “System Information” page, with ColdFusion, Lucee, Tomcat, etc. now comes JBoss information as well. Server detection for a Commandbox run instance is now part and parcel.

Tomcat log files will also be captured alongside the other FR logs in the same timeframe as before (per hour), all set as standard.

FusionReactor has long done the same sort of excerpting of ColdFusion’s console log, the ColdFusion-out.log, which appears in the FR logs as fr-coldfusion-log.log. In the case of Tomcat, the log catalina and localhost file names will show up in the FR logs with the names juli-catalina.log and juli-localhost.log, respectively. Finally, the Tomcat stderr.log is archived by its original name.

Having these logs for the application server available while reviewing FR logs can be very helpful, especially for post-crash troubleshooting.

These capabilities allow FR 7.3 to keep up to date with the changing world, important when considering Moor’s Law. The furthered log file competences provide a richer data collection, giving you further insight into what’s going on with the environment. Ultimately, this affects more informed decision making which provides quality as well as faster resolution of issues.

GDPR compliant with further obfuscation

Progressions have been made with regards to the obfuscation of data, something very important in the modern age, which is not going away with the resent General Data Protection Regulation (GDPR) requirements. Versions from 6 have provided options for obfuscating data, including SQL and for MongoDB obfuscation, to FR 6.2’s optional obfuscation of request data, to FR7’s obfuscation of credit card data and more.

FR 7.3 enables you to obfuscate IP addresses.  This and the others aid in meeting GDPR and other security/privacy requirements. This way you can make sure data is safe and save money on any potential penalties as a result of GDPR enforcements.

In the email settings page, changes to the “to” address can be saved while testing

One of the most used features within the FR set up is the ability to receive messages when something has occurred with your application (this could be daily reports, or more importantly crash protection). Upon testing the email system, in previous versions you would have noticed that you could change the email address for the test purposes, however it would not have changed in the overall settings.

In FR 7.3, you can test your email all the same, adapting the “To address” value(s). Furthermore, one will be able to click the “save settings” button, which will save the input, until when changed again.

Realistically this saves time and ultimately provides an opportunity to customize FR 7.3 to your specification at a higher rate, meaning you can move on to more important tasks

Making the most out of FusionReactor Cloud

FusionsReactor 7.3 has been one of our main focal points in terms of developing more capability for the FR range. For those of you who were not aware, FR Cloud aims to expand the capability provided by the on-premise version of FR by providing access to historical data, combining instrumentation data across server instances to provide a single consolidated view and very focused access to specific issues, such as slow running requests or transactions which threw errors.    FusionReactor Cloud also includes a sophisticated alerting engine, which provides seamless integration with several tools, such as Slack, PagerDuty, HipChat, VictorOps etc.    You can read about the features here.

As part of the FR 7.3 release enhancements,  FR Cloud users will now be able to be see an indication of an active profile for a running request that is itself being profiled.

Another feature is the immediate request API which ultimately allows for a more instant connection between the cloud and on premise solution ensuring faster “real-time” performance.

Another benefit of the improvement to communication in FusionsReactor 7.3 is FR now being able to send more profile entries to FR Cloud by default. There’s also improved error handling and feedback when using the feature to start/stop Profiling of requests from FR Cloud. And thread dumps taken in FR Cloud now better match on-prem FR thread dumps (including more thread meta data), and sub-transaction information for recent and running requests as well as JDBC transactions are also improved.

More log functionality has also been updated. Users can now monitor their log file creation on FusionsReactor 7.3 on-premise and decide whether or not to send the data to the cloud, ultimately saving time, later on, and memory space. Although there is no direct capability for that on cloud, the brilliant thing, is when it comes (soon) it will be automatically uploaded to any using FR Cloud already.

FR Cloud is all about data, how to use it and the processing of said data. The ability to view multiple indications of profiles allows for efficiency of work, alongside the API feature which will speed up processes. Time saved through speed ultimately saves money, as well as allowing for employees to spend their time more effectively. The log and thread capabilities provide a cohesion between the on-site and cloud FR implementations, using synchronization alongside the enhanced data displays to insightfully inform decision making while allowing for improved timing between viewing real time data (on-site) or historical data (in the cloud). These ensure quality decision making for furthering business interests, in a timely manner which saves cost and enhances the availability of resources.

Conclusion; getting the update

So although not comprehensive, we have covered some of the salient FusionsReactor 7.3 updates. Furthermore there are some bug fixes which can be seen on FR 7 updates technote. Ultimately all these changes are aimed at quality, time saving, cost saving and ensuring customer satisfaction by improving the back end processes. All of which should improve in company profitability and sustainability.

If you already have a previous version of FusionsReactor 7.3 java monitoring tool, note that there is a “check for updates” link on the FR “about” page. If you are new to the product, download the latest version by clicking on FR downloads page.

NOTE – much of this blog text has come from the original, written by Charlie Arehart – which you can find here

This year we are back at Velocity Conference San Jose – You can visit us at booth #812 we will be showing off the latest FusionReactor developments and features to help developers fix problems faster! To celebrate this we are giving away a free ticket for Velocity Conference, San Jose, California.

The Prize is for one Bronze 2-Day Pass which Includes:
– All sessions (Wed & Thu)
– All keynote and plenary presentations
– Sponsor Pavilion and all events held there– All on-site networking events
– Lunch (Wed & Thu)

To enter the draw:
1) Start a trial of FusionReactor and send us a screenshot of your activation Menu / About Page. Send the screenshot to sales@fusion-reactor.com, the version must be FusionReactor 7.2.3 or higher.

We will be announcing the winner on, Friday 1st June, this will give the winner enough time to organize flights and accommodation.

If you do not win, please do not worry you can still save 25% on the entry price by using our Discount Code: FusionReactor25

Why debugging in production is so tempting?

In one of my first jobs, one of the tasks I had was to fix a bug which used to occur from time to time in a very complex production system. That is easy! – I thought. I will reproduce the same situation in my development environment, find the broken line, implement a quick fix and it’s done! However, it turned out that reproducing exactly the same scenario which occurred in production, was not possible – so after some time, I gave up this idea. I was forced to spend days analyzing logs and trying to correlate many different events, to come up with an idea of what might have happened.   Soon, I realized that it’s as tedious as looking for a needle in a haystack.  A couple of fruitless days later, I came to the conclusion that I would need to add more logging here and there and wait a couple of days or even months to see if the bug occurred again. Then I thought that hunting bugs in production is somehow crude, compared to the sophisticated tools we have when developing an application. You’re implementing a new feature and seeing that the result of what your service returned is not what you had expected? You just put a few breakpoints in and click the Debug button! A few moments later, you know exactly what happened.  Wouldn’t it be awesome to do the same in a production environment?

Why debugging in production is so hard?

Wait a second! – you might have thought. But don’t we have the remote debugging features in most of the modern IDEs? Couldn’t we just connect to the running production application and debug it as we do from our local environment?   While it’s possible, another problem arises: most of our business applications handle many requests per second. There is no easy way to control breakpoints firing everywhere when your application is being remotely debugged.   As you can imagine, we don’t want to block all of our users from using our application when we decide to debug it. More often than not, we also can’t just force our application to reproduce the bug which happened yesterday – sometimes the only way to do it is to wait until it occurs again to one of our users. Thus, keeping a remote debug session in production, without a strict control of how breakpoints fire, is like putting landmines in the forest and inviting our users to run through it.

A better and above all – safer way

FusionReactor is an Application Performance Monitor, which comes with many advanced capabilities which you wouldn’t normally expect to find in monitoring solution.   One of these, is the production debugger, designed to allow you to get low-level debug information from your production runtime environment – without affecting performance and without the issues and obstacles you would have with a traditional debugger.

One of the main issues, you would be faced with, using a traditional debugger – is that, once a breakpoint is set, it would fire for any thread which crosses that point in the code.   FusionReactor overcomes this, by having a range of techniques to control the way a breakpoint should fire.   For example, it can limit the number of times (threads) that a given breakpoint will trigger – which solves the problem of impacting too many users.   Need more ways to control it ? We can even configure a breakpoint to fire for a user from a specific IP address (session), or when a specific variable matches a value or when a specific exception takes place !   However, what if a breakpoint triggers at night when nobody from our team is watching?  The folks at FusionReactor have thought of this and the product allows you to define thread pause timeouts so if you would not intercept a paused thread within a specific time then the debugger will release the lock and allow thread execution to continue. When used with the thread limits this reduces the possible impact to one thread only – and only for n seconds, minutes or hours…

Another great benefit, is that FusionReactor can send out an email with the stack-trace and variables at the point that the trigger fires. This gives you a very flexible and unobtrusive way to get notified with plenty of information to make debugging easier than ever before.  It’s a LOT better and simpler than adding debug/log file code into your production applications!   For one thing – you don’t have to remember to remove the debug code in your production application !

If that’s not enough to convince you that debugging in production doesn’t have to be cumbersome, FusionReactor is shipped with a fully integrated IDE-style debugger which runs directly in your browser – no need to install additional fat clients to start remote debugging.   Everything is built in and ready to go.

Summary

What I described here is not a vision of the future it’s available now and it’s safe, secure and simple to use.   The alternative is (of course) good old log files, which we all know have their limitations.   I don’t see any reason to spend countless hours digging through log files hoping to find the needle in the haystack – using logs are “archaic techniques” and I think maybe it’s time to finally start using tools for the 21st century 😉