Blog

Why Every Developer Needs FusionReactors Production Debugger

The situation is a common one when you’re a Java developer: you know there’s an application issue; you know it’s degrading performance and negatively impacting your customers; but you’re having trouble finding the root cause and you’re using valuable time that should be focused on the next deliverable. Today’s distributed application environments and architectures are more complex than ever and this only adds to the difficulty when trying to pinpoint software problems. In the recently published DZONE Guide to Performance & Monitoring, it was found that the most time consuming part of fixing performance issues is finding the root cause followed closely by being able to reproduce the performance issue.

The first tool most developers reach for when investigating problems are the application and database logs. Logs are an invaluable resource when looking for the key to an issue but searching through them takes time. They also might not give the developer a clear picture of what is causing the software to run slowly or throw exceptions. Many developers do not have access to production environments and often these logs are their only view into how the application is running.  However, the logs may not contain the information they need or the logs may not even be available. Metrics are also useful but in many cases they don’t provide the kind of detailed information a developer can use to narrow in on the most likely cause of application slowness. It also takes time to collect and inspect all the data that might provide clues as to what is going on within the application. Is it a poorly written SQL query? A memory leak? A null pointer exception? It could be one or more of these issues and it may take hours or days to fully understand what is causing the problem.

Tweaking and adjusting the code for applications to make them run as efficiently as possible is important, but what do you do when something breaks without warning? Defects in code can be harder to locate than a performance issue because they occur much more infrequently and can be difficult to reproduce. Logs may show that an error occurred but if you don’t know exactly what the application was doing at that specific time under those specific conditions you may not be able to figure out what happened.

At this point you may be nodding your head because you’ve dealt with similar situations and have used the same procedures to address performance issues or come up with an emergency break-fix solution to get your application back up and running. Traditional application performance management (APM) tools provide some information and can be set to alert when something is wrong but they don’t give you the whole picture. This is where FusionReactor comes in with a whole new way to monitor your code and how it functions as it’s running in production. Instead of grepping through your logs, diving into the heap, tallying object instances, running stack traces over and over, guessing at some breakpoints, or including debug data into your code after an issue has arisen, FusionReactor allows you to interact and debug your production application as it is running. FusionReactor was designed to give developers the information they need along with powerful production-safe tools like the Production Debugger and the low-impact Profiler. This means that instead of spending time collecting data and attempting to reproduce the problem, you can look at your code as it executes to see where the problem starts and learn exactly what is causing the issue so that you can start to work on a solution as fast as possible.

Instantly identify issues and bottlenecks

Developers have long been taught that debugging code while it’s running in production is a bad idea for many reasons including high overhead, having to spend time watching and waiting on the debugger while it runs, and the potential for a breakpoint to halt the entire application.

The FusionReactor uses JVMTI to bind directly into the built in debugger in the JVM, thus requiring no protocol overhead. The debug features are only enabled when the user wants to run them. The normal impact of having FusionReactor’s Debugger installed is zero (unless you use java 1.6.0._21 or earlier due to a bug in Java) apart from the memory used to load the library into memory.

Typically, you would set a breakpoint then step through your code and wait for a breakpoint to fire. The point being, you need to actually attend to the debugger as it’s running, which is very time consuming.  FusionReactor does away with this need, by sending out an email as soon as the breakpoint is hit. The email response can be configured one of two ways. In the first case, the breakpoint will fire, the stack trace and variable information is captured, and an email is sent to the developer. This is a non-invasive approach that allows the developer time to look at the data without any impact to the code running in production. In the second case, the breakpoint fires, stack trace and variable information is captured, and an email is sent however the thread where the breakpoint fired remains open for either a defined period of time or indefinitely, depending on how it has been configured. The developer can click on a link in the email which brings up the debugger at the point in the application where the breakpoint fired.  So when some problem occurs at 3:00 am, FusionReactor will capture the state, capture the thread and essentially freeze it, until you come into the office and start debugging it.

Instantly identify issues and bottlenecks

FusionReactor Debugger was designed with enhanced control mechanisms in mind to allow for safe production debugging:

  • Set how many times a breakpoint fires so that only those threads are affected.
  • Set a limit on the number of threads that can be paused in the debugger at any one time or how many threads a single breakpoint can pause.
  • Set a parameter on how long a thread can be paused. Once the time limit has been reached the thread will be released to allow the end user to continue.
  • Have a breakpoint send an email with the stack and variable information while it holds the thread for the predetermined time period.

It goes without saying that any production debugging should be done with caution so as not to affect other threads or the overall application, however FusionReactor’s Debugger allows you to target only what is needed to quickly investigate the issue.

The low-impact Java Profiler offers the ability to watch your code as it executes, enabling you to pinpoint bottlenecks in production. You can profile any request or transaction running on the JVM such as Tomcat, Glassfish, or Jboss. The Profiler can be run manually or configured to start when a particular condition has been set. This is a huge advantage in that you can leave the Profiler ‘on’ and set it to activate automatically when a request takes longer than expected instead of having to watch and wait for the event to happen. You can also limit the number of profile samples to control the accuracy of the sample. This information is then stored so that later you can drill down into the details to see how your code is running. The Profiler shows how much time is spent in each section of code as well as the overall percentage of it that makes up the transaction or request.

Performance tuning and troubleshooting will always be a part of development but hours or days of time spent searching through log files, running stack traces over and over, and trying to reproduce a production issue can be a thing of the past with FusionReactor. Being able to quickly solve issues results in less downtime, more stability, faster applications, happier customers, and less stressed developers!

 

To get start with a FREE trial of FusionReactor go here to Download FusionReactor and Start your trial.

 

FusionReactor Wins FeeFo Gold Trusted Merchant 2017 Award

We are thrilled to announce that FusionReactor has been accredited with the “FeeFo Gold Trusted Merchant” 2017 award!

Feefo is an independent feedback service that are dedicated to collecting trusted reviews. The Gold Trusted Merchant award is only given to businesses that have an average positive Service Rating of between 95% and 100%.

The whole FusionReactor team would like to thank everyone who filled out feedback for us – we really appreciate it!

The award shows that FusionReactor is a leading tool for Java Application Performance monitoring – designed to help Developers and Devops improve their applications and get to the root of the problem as fast as possible.

Using the Feefo feedback service has been a fantastic way for us to see how FusionReactor is being utilized by our customers. As well as highlighting any issues they may be facing. We always aim to provide the best possible service for our customers.

You can read more about our Customer reviews here: https://www.fusion-reactor.com/customer-reviews/
And see some interviews with our customers: https://www.fusion-reactor.com/customers/

“The Trusted Service award is a recognized symbol of trust – helping customers click with confidence.”. From everyone on the FusionReactor team thank you and have a great year!

Intergral GmbH Makers of FusionReactor Java Application Monitor Wins Feefo Review Feedback Reward

Intergral GmbH Makers of FusionReactor Java Application Monitor Wins Feefo Review Feedback Reward

Read more about this in our latest press release here

FusionReactor Developer Edition – Ultimate features and insight

Our “typical” FusionReactor customer is generally a techie, usually a software programmer who is either developing on, or is responsible for an application.  About 25% of the time, our customers come from IT management, operations or DevOps positions.    What we hear time and time again, is how useful FusionReactor is at pinpointing issues, whether it be performance bottlenecks, memory problems or some weird almost impossible to find issue which is causing their application to crash, seemingly at random – yes, FusionReactor can find those issues too.   Customers praise the product for its ability to provide “real-time” insight into what’s happening, as it’s happening.     Perfect.  This is exactly what we wanted and was always the original intention of the product.    When we very first built FusionReactor, we wanted a tool to help us discover what was really going on inside our production application, inside the ColdFusion black box, so that we could get to the root of the problem and fix it.   In fact, the slogan for FusionReactor – “Find it, Fix it, Prevent it” is a relevant today, as it was in 2005 when FusionReactor was first released.

As you may be aware, with the release of FusionReactor 6 we introduced a new Edition – Ultimate, which featured the Production Debugger, Production Profiler and will soon include a production safe Memory Analyzer.   These tools are ‘not’ typically associated with a monitoring solution – in fact, I don’t believe there is any other monitoring tool on the market which boasts a debugger as part of its feature set.    So why did we decide to ‘include’ these capabilities as part of our monitoring solution?   Well, when something breaks in production, we believe that developers need real-time insight and transparency into what the application is actually doing at the point that it’s breaking – in production.    FusionReactor caters to this need by means of the Stack Trace, which highlights the method and line of code where the application is currently “stuck”.   This is extremely useful – but it’s not as useful as being able to debug or profile the code.   In order to rapidly pinpoint production issues we believe developers need additional tooling which is actually closer to what they would use in their development/test environments i.e. a debugger, profiler and memory analyzer.   All these tools are integrated into FusionReactor Ultimate.

FusionReactor Ultimate Edition is designed to give the level of detail software engineers need to get to the actual root of the issue and the additional low-overhead production-grade tools will give engineers access to detailed information they need to “deep-dive” & quickly figure out the hard stuff developers need to fix.

With the introduction of FusionReactor Developer Edition, we’re providing a tool which can be used in development and test environments (*) to help you to pinpoint issues and performance bottlenecks before applications are deployed to production.    The Developer Edition is available as an annual subscription license, which means that you’re entitles to all updates and upgrades of the product.   Click here to read more or here to purchase.

(*) FusionReactor Developer Edition enables you to develop, test, evaluate and analyze applications which are running in a non-production environment.  The Developer Edition may not be used to monitor an application which is running in a live or stand-by production environment or staging environment, in each case, including, without limitation, in any environment accessed by application end- users, including, but not limited to, servers, workstations, kiosks, and mobile computers.

Using Production Debugger to set a conditional break point in a ColdFusion loop

This example will show how to set a conditional break point in a ColdFusion loop using the FusionReactor Production Debugger.

Code Example – pdloop.cfm

pdloop.cfm
1
2
3
4
<cfset aArray = ["January","February","March","April","May","June","July","August","September","October","November","December"]>
<cfloop from="1" to="#arrayLen(aArray)#" index="i">
  <cfoutput>#i#: #aArray[i]#<br></cfoutput>
</cfloop>

Setting a conditional breakpoint


In this example, we are going to set a breakpoint when a condition has been met within the aArray variable.   The condition which we would like to set the breakpoint is when:

aArray[i] EQ "March"

 

Setting this in the Edit Breakpoint form, will look like this.

Field
Value
Meaning
Breakpoint Trigger Source File/Line Number We are selecting to set a breakpoint within a specific source file and a specific line number
Source Code Filename pdloop.cfm Name / location of the file where the code is stored
Source Line Number 3 This is important.    If we are checking the value of a variable, then this variable must have been set before this line number has been reached in order for the breakpoint to fire.
Condition aArray[i] EQ "March" This is the example condition which will cause the breakpoint to fire and execution of the page to halt
Fire Count Always This indicates that the breakpoint will ALWAYS fire.   If we set the Fire Count to a numeric value, e.g. 3  – then the breakpoint would fire 3 times.

 

Trigger Handler Pause Thread Will tell FusionReactor to pause the currently executing thread when the condition has been met
Pause Time 60 The thread will be paused for 60 seconds.   During this time, the breakpoint can be intercepted by clicking on the Production Debugger icon – or from within the Paused Threads menu item
Pause Execution On every thread that fires the breakpoint Will cause the engine to halt for every single thread in which the breakpoint condition fires.

When the breakpoint has been setup, you will see the following when you click on the Breakpoints menu item – If the page has not yet been executed – then we will see the State as being Pending

 

Seeing when a breakpoint fires


When the page pdloop.cfm is executed, the condition will fire and the page will halt execution.

In the Breakpoints menu, the breakpoint will be shown as follows – NOTE – the State now shows the ClassLoader information, as the page has actually been loaded and executed.

 

When the breakpoint fires, then the Debugger icon will appear in the top banner –

You can either click on the Debugger icon or click the Paused Threads link in the Debug Menu, you will then see the Paused Thread – together with the Timeout Countdown

To start the Production Debugger session, you need to click on the Debug Icon –

Working with the a debugger in the Thread View Page


The Thread View page shows the details of a specific thread once the thread has been paused in the interactive debugger.

Source Code Viewer


The source code viewer will show the source code for the location where the interactive debugger is currently paused – line 3 in our example.

The variables viewer shows the variables currently available on the thread at the specific location that the interactive debugger has paused.

As we have set the breakpoint to fire when aArray[i] EQ "March" – we would expect

I = 3.0

We can also see the Variable values in the aArray variable

Icon

Note that the array index starts at 0, not 1

Modifying a variable value


We can now modify the value of a variable.   In this example, let us change the value of May to May in the Spring

You should always use the CF Set button to set a CF variable  – Strings need to be in quotes – numerical values, simply a number

 

You should now see the following when you expand

Once you have changed the variable value, hit the Resume icon to continue execution of the program.

The page results will then look like.

1: January
2: February
3: March
4: April
5: May in the Spring
6: June
7: July
8: August
9: September
10: October
11: November
12: December

FusionReactor Blog gets selected at #25 of the top 40 Java Blogs

The FusionReactor Blog was selected as one of the Top 40 Java Blogs by FeedSpot. The whole FusionReactor team are proud to be part of this list. Have a look at some of the other top Java blogs featured in the list.

We also got this cool badge for being featured in the top 40 :

Remote Debugging a Java application using FusionReactor

Remote debugging is not a new concept and you can find numerous articles explaining how to setup various IDE’s such as Eclipse, Netbeans or IntelliJ to perform remote debugging of a Java Application.   

If you’ve searched and found this article, you will have your reasons for why you want to be able to do this e.g. local debugging is not possible, the code you wish to debug is not running on your local machine or the problem you’re trying to isolate only occurs on another environment (usually production) etc.   OK, now it’s getting scary, did you ever think of debugging a remote java application which is running in production?     Maybe you’ve heard developers say, “We can’t reproduce the problem, it only ever occurs in production – If ONLY we could debug it”.   

Before we go any further though, let’s take a step back and look at the main reasons you may NOT want to debug a remote (production) application.  (Make sure to read on, to understand how FusionReactor addresses and solves these concerns though!)

  • When you set a breakpoint – it could halt your whole application as the breakpoint would (theoretically) trigger on all threads at that point in the code.  Ouch – well you definitely don’t want that happening in production.
  • When you use a debugger – you imagine sitting in-front of it and stepping through your code – i.e. you set a breakpoint – allow your application to run to that point in the code and then take a look at some variables.   However, what happens if you’re not in control of when the breakpoint fires?   What happens if your breakpoint would only fire in a rare corner case, which is what you’re actually trying to figure out.    Well, then you could be faced with a long wait before that breakpoint would ever fire – order the pizza, it could take a while….
  • Attaching ECLIPSE or some other IDE is going to cause too much system overhead and it’s also fairly tricky to setup.    Or, you’re using an IDE which doesn’t even allow remote debugging.
  • The core developer perception that you should not use a debugger in a production environment (very probably based on the reasons mentioned above).

Well, if you’ve got this far, then hopefully I’ve got you sufficiently enthralled to find out how FusionReactor can solve all of these production debugging related issues.    Read on – all will be revealed…

  • Problem: Breakpoints affect all threads.   Solution: FusionReactor has implemented a suite of (patent pending) control mechanisms by which the debugger interacts with the environment it’s running on.  Examples of these control mechanisms are:
    • Fire once (or n times) for any breakpoint which means only 1 thread would ever be affected even when the break point fires.
    • Controlling the debugging capability from a specific IP address.
    • Rate limiting the number of threads which can be paused in the debugger at any 1 time or how many threads a single break point can pause.  If an application server has a thread pool of 16 you could say only 2 threads can be paused at once (either globally or per breakpoint)
    • Thread pause timeout : if you (the user) would not intercept a paused thread within a specific time then FusionReactor will release the lock and allow thread execution to continue.  This reduces the thread pause time to n seconds when debugging on a production server.  When used with the thread limits or file count limits this reduces the possible impact to 1 thread only 1 and only for n seconds.
  • Problem: If you’re debugging, you usually have to wait for a breakpoint to fire – which could be a big problem if you’re waiting for that elusive issue to occur.   Solution: FusionReactor is capable of holding a single thread either for a period of time in hours, minutes, seconds – or indefinitely.   This removes the need for the developer to babysit the application waiting for the trigger to fire.   Essentially, it enables the debugger to run in an ‘Unattended’ fashion – rather than it would typically i.e. one would usually, always attend a debugger whilst using it.
  • Problem: Setting up remote debugging is tricky and incurs too much overhead.   Solution: FusionReactor is simple to install and has its own built in IDE for debugging – FR is designed to be installed on production servers and has an overall impact of <1%.   For the debugging part, it uses the JVMTI library from the Java Virtual Machine.  This exposes a debug API to our debugger (this is the same method used by other IDE’s like Netbeans and Eclipse). Getting this configured in FusionReactor is simple.    The normal impact of having FR’s Debugger installed is ZERO (unless you use java 1.6.0.21 or earlier due to a bug in Java) apart from the memory used to load the library into memory.   FusionReactor only enables the features in JVMTI when the user wants to use them.   So only when a break point is set will it start to process class load events to install break points into those classes.  Exception event hooks only become enabled when the exception breakpoint trigger is configured and enabled.    It’s a small price to pay for the benefits you get.

Here is an image of what the integrated debugger looks like (within FusionReactor).

Production Debugger 1

As you can see, it’s very similar to most other IDE style integrated debuggers and this is completely built into FusionReactor.   The debugger includes the following features.

  • Source code and line number specific breakpoints.
  • Java Method Entry breakpoints.
  • ColdFusion Function Entry breakpoints.
  • Field access and modification breakpoints.
  • Exception being thrown and exception caught breakpoints.
  • Email alerts.
  • Breakpoint samplers.
  • Conditional breakpoints.
  • Rate limiting.
  • Interactive debugger.
    • View source code when configured in the Sources page
    • View decompiled code for classes without source.
    • Change variables at runtime.
    • Step into, out and over source code.

 

Installing the debugger and activating FusionReactor

Go get the latest version of FusionReactor from our download page – https://www.fusion-reactor.com/download/

Installation is very easy – you can install FusionReactor either using the automated installer or you can install it manually.   If you use the automated installer, then the debugger library will be automatically installed for you.   If you perform a manual installation – then you need to follow these steps.

Once installed you will need a trial license – which gives you 14 day access to all FusionReactor features (including the debugger) – you will be provided with a trial license from the download page.

 

Here are links to some resources to get you going…

Well I hope that’s whet your appetite and you’re ready to start remotely debugging those production Java servers.

Win a FREE Ticket for Velocity Conference Amsterdam , 2016

fusionreactor-win-velocity-tickets

We are sponsoring Velocity Conference,  Amsterdam. You can visit us at booth #416, we will be showing off the latest version of FusionReactor and FusionReactor CLOUD. To celebrate this we are giving away a free ticket for Velocity Conference, Amsterdam.

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

There are Two ways to enter the draw:
1) ON TWITTER : Retweet this tweet and follow us it is that simple! If you are already following us then just retweet this.

OR (You can do both to double your chances of winning).

2) ON FACEBOOK : Just Like us on Facebook –  and post us a Personal Message – “I want to go to Velocity Amsterdam”
We will be announcing the winner on,  Friday 21st October, this will give the winner enough time to organise 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

 

Win a Ticket for Adobe ColdFusion Summit – Las Vegas, 2016

Win a Ticket for Adobe ColdFusion Summit – Las Vegas, 2016

cfsumit-web

 

The FusionTeam will once again be sponsors of this great event – make sure you join us and the Adobe ColdFusion Team! We will be showing off the latest version of FusionReactor and FusionCLOUD.

To celebrate this we are giving away a free ticket for the Adobe ColdFusion Summit.

The Prize is for one ColdFusion Summit registration which Includes:
– Admission to all keynote and breakout sessions
– Sponsor Pavilion.
– Attendee appreciation event
– Conference meals.

There are two ways to enter the draw:
1) ON TWITTER : Simply follow us and send us a Direct message saying ‘I want to go to CFsummit’

OR (You can do both to double your chances of winning).

2) ON FACEBOOK: Just Like us on Facebook – and post us a Personal Message – ‘I want to go to CFsummit’

We will be announcing the winner on, Friday 23rd September, this will give the winner enough time to organise flights and accommodation.

If you do not win, please do not worry you can still get a ticket for $199 on the entry price by using our Discount Code: CF199Offer

FusionReactor ColdFusion line performance

Introduction


This technote is going to guide you through the use and configuration of the FusionReactor ColdFusion line performance plugin. The FusionReactor ColdFusion Plugin is able to profile the execution of ColdFusion CFML code at line level. The data gathered can be used to identify performance issues deep inside ColdFusion pages and components that can be an invaluable tool for finding problems within your applications. Additionally, the plugin also gathers information about the CFML code coverage which can be valuable when testing applications.

If you are using Lucee or Railo application server and FusionReactor 6.2.0 or above, then you should be able to use the FusionReactor Lucee Plugin or FusionReactor Railo Plugin. More information about the plugins, check out the link below.

Getting Started


If you are using FusionReactor 6.0.4 or above and a ColdFusion 8 or above server, you will be able to use the FusionReactor ColdFusion Plugin.

Please be aware that this feature uses line number information generated by the ColdFusion application server that is known to be inaccurate in some cases and beyond our control. For this reason we cannot guarantee 100% accuracy of the information. Also note that the performance of the ColdFusion application server may be HEAVILY impacted while tracking line performance profile data.

In order to view any of the profiled data, you will require the “CF Line Performance Explorer” application. This can be downloaded from the link below.

When the tool has been downloaded, you will need to unzip the folder and copy the contents into your ColdFusion /wwwroot directory. Going to the following address, http://localhost:8500/cfperformanceexplorer-master/ you will see the following when you attempt to view a files metric data.

In order to enable the line tracking for your CFML files, please follow the steps outlined below;

  1. Access your FusionReactor Instance.
  2. Navigate to FusionReactor > Plugins > Active Plugins.
  3. Locate the FusionReactor ColdFusion Plugin and then press the Configuration button.
  4. Change the value of the “Track CFML Line Execution Times” field to “Enabled” and Save the changes.

This configuration is going to take immediate effect and any CFML code that is run and is going to be profiled. In order to see the results, please return to the CF Line Performance Explorer application to view the profile data for any classes that have been run since enabling of the plugin. See screenshot below.

Please note that though the data gained from the profiled classes may be invaluable the profiler can have a performance impact on your server. It is recommended to only use the profiler when required and to take precautions when using it in a production environment.

More Information


For more information you can view the following documentation.

Issue Details

Type: Technote
Issue Number: FRS-401
Components: Plugins + OSGi
Environment:
Resolution: Fixed
Added: 19/08/2016 10:30:37
Affects Version:
Fixed Version: 6.2.2
Server:
Platform:
Related Issues: None

FusionReactor Lucee and Railo line performance

Introduction


This technote is going to introduce the Lucee and Railo line performance plugins. The FusionReactor plugins allow you to profile the execution of ColdFusion CFML code at line level. This data can then be used to identify performance issues deep inside your ColdFusion pages and components and can be an invaluable tool for finding problems within your applications. This feature also gathers information about the CFML code coverage which can be very valuable when testing applications.

If you are using a ColdFusion server, FusionReactor 6.04 or above supports the FusionReactor ColdFusion Plugin. More information about the FusionReactor ColdFusion line performance, check out the link below.

Getting Started


If you are using FusionReactor 6.2.0 or above and a Lucee 4.5 server, you will be able to use the FusionReactor Lucee Plugin. However, if you are on Railo server then you will be able to use the FusionReactor Railo Plugin.

Currently Lucee 5 is not supported.

In order to view any of the profiled data, you will require the “CF Line Performance Explorer” application. This can be downloaded from the link below.

When the tool has been downloaded, you will need to unzip the folder and copy the contents into your Lucee or Railo /webapps/ROOT directory. Going to the following address, http://localhost:8888/cfperformanceexplorer-master/ you will see the following when you attempt to view a files metric data.

To enable the line tracking for your CFML files you can follow the steps outlined below;

  1. Access your FusionReactor Instance .
  2. Navigate to FusionReactor > Plugins > Active Plugins
  3. Locate the FusionReactor Lucce Plugin or the FusionReactor Railo Plugin and then press the Configuration button.
  4. Change the value of the “Track CFML Line Execution Times” field to “Enabled” and Save the changes.

This will take immediate effect and any CFML code that is run is going to be profiled. You can now return to the CF Line Performance Explorer application to view the profile data for any classes that have been run since enabling of the plugin. See screen below

Though the data gained from the profiled classes may be invaluable the profiler can have a performance impact on your server. It is recommended to only use the profiler when required and to take precautions when using it in a production environment.

More Information


For more information you can view the following documentation.

Issue Details

Type: Technote
Issue Number: FRS-400
Components: Plugins + OSGi
Environment:
Resolution: Fixed
Added: 11/08/2016 15:06:20
Affects Version: 6.2.0
Fixed Version: 6.2.0
Server:
Platform:
Related Issues: None