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 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).

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…

• Installation Videos for FusionReactor
• Video Tutorials on using the debugger – from our YouTube Channel
• Debugger documentation
• Debugger examples

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

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.

Java byte buffer – 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.

Java 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.

Java byte buffer

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 Java byte buffer tools

Start Free Trial Compare Editions Pricing

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

Understanding the Java Buffer Pool Memory Space

The Java 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 a Java buffer pool? 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. Their 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 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 the Usage of a Java Buffer Pool

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.

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.

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

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

For the second time we are sponsoring Velocity Conference, New York. You can visit us at booth #19, we will be showing off the latest version of FusionReactor and FusionCLOUD. To celebrate this we are giving away a free ticket for Velocity Conference, New York.

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)

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 New York”
We will be announcing the winner on,  Friday 26th August, 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