Blog

Keeping it real – excluding the effect of long running requests in FusionReactor



Something that comes up when speaking to FusionReactor customers is the need to handle long running requests.  In FusionReactor as with many APM solutions there is a continuous running aggregate of the average run-time of the web requests.

Unfortunately if you have a single request that has to run for a long time it can cause this number to become skewed; essentially the average run-time of requests can end up being longer than it really is just because of this one request e.g. often a maintenance job run by the system admins, which is not so important when you are interested in real user experience.

Scenario 1 – Excluding a single long running request which is skewing performance metrics

Details

Let us assume you have a running web application, in this instance running on a tomcat server.  Now let’s assume that you have a request that is run via this application as some routine job.   This job typically runs over a minute and has a negative affect on the average run-time of your server.    We would like this request to be ignored by FusionReactor and not included in the metrics calculated, but every other request should continue to be tracked.

Goal

The goal is to eliminate this request from the metrics, and get a better picture of what the overall performance of the server is.

Using this example URL for the job: /JTA/performance/jdbc/jdbc30secondrating.jsp

Steps

FusionReactor has this feature right out of the box, FR has the ability to restrict requests from almost every feature that it offers.  There are a few different ways to go about adding this restriction, the simplest (but not always possible solution) is to simply click the ‘Stop Tracking’ button, next to the request you want to ignore, on the Request -> Activity screen.   This has the disadvantage of requiring the request to be running before it can be removed from the statistics. It also will not affect any statistics that have already been calculated from this request. This approach will only affect that single request, and as such is of limited usefulness when applying it to a routine job.   I mention it here as it is useful when running a job manually that you do not want to be tracked.

The better approach is to simply enter the request details prior to it entering the system.

  1. Go to FusionReactor -> Restrictions
  2. Enter the details of the request that you want to ignore from metrics. (help with settings)

We have some options here, if the request always comes from the same host, we can also add the host name check to the restrictions, this means FusionReactor will only ignore the request if it comes from the matching host name.

Another approach, which is quite a neat feature, is to filter the request based on the query parameters. So if this job is in fact the same end point as some other request, but contains specific query parameters, then we can filter on those, and we can actually add an extra query parameter to the request when it is the job.

For example, if we have the endpoint /JTA/performance/report.jsp, but this request by itself is part of the usual use model of the application. We can actually alter the request to be /JTA/performance/report.jsp?__fr_ignore=true, this should not have any effect on your request, unless you happen to use the query parameter __fr_ignore; which seems unlikely.   So now by changing the “Request” field of the restriction form to include this parameter, and set the “Parameter” field to “Check”, you can make FusionReactor ignore this request when the parameter __fr_ignore=true is sent, and continue to track it when it is not.

I should point out at this point that if you use the “Exact Match” strategy then you will also have to include any other parameters that are part of the request.   Another alternative is to use the “Regular Expression” strategy, covered later.

So now that the restriction is configured, clicking save will add this restriction, visible below the form, in real time, and any new request that match this pattern will be ignored from FusionReactor.

long_req_blog_1

Outcome – we’re keeping it real 🙂

At this point FusionReactor will now be ignoring the request that you have added to the restrictions, and will no longer be included it in the metrics for the server.    This will hopefully improve the rating of the server among your peers as it will now seem that by magic the server is performing better.

 

Scenario 2 – Using regex to exclude multiple tasks affecting your server performance rating

Similar to the previous scenario, but this time we have a whole sub section of the application that is only used by the system administrators to affect changes on the database, or perform clean up tasks.

Details

Lets us imagine that we have a number of administrative tasks, such as account merge, account removal etc.  These are not performed that often, but never the less do take some time.   These requests can then affect the overall statistics of the server, making it seem busier or less efficient than it actually is.

Goal

The goal here is to identify these administrative tasks and remove them from the request tracking.   We can identify these requests as they have the string /system/admin/ in the URL.   This being the root of all the system administrator tasks that we want to ignore.    Once approach would be to enter all the URLs one by one in the same way we did above.  The disadvantage is that if new jobs would be entered, we would need to remember to include the individual URL.  A much better approach is to use the “Regular Expression” strategy to ignore all the requests by using a single rule.

Steps

The way to add this rule is basically the same as the single rule, we went through above. The only real difference here is the use of the “Regular Expression” strategy and the Request actually being the regex and not the URL as it was above.

  1. Again we go to FusionReactor -> Restrictions
  2. Now we set the “Match Strategy” to “Regular Expression”
  3. Enter the regex .*/system/admin/.* into the “Request” field
  4. now simply save the form

You will immediately see the restriction enter the list below the form, and FusionReactor will immediately start ignoring any new request that contain the pattern /system/admin/.

Outcome

We have now, in these very simple steps, removed all system administrator request from being tracked into the FusionReactor statistics for your application.   You will now get a much clearer view of how your application is really performing.

long_req_blog_2

Additional

Regex, or Regular Expressions, are a very powerful tool for any language. However just like many, many things in programming the implementation of regex can vary from language to language.  FusionReactor uses the Java regex engine.    Plenty of documentation on the Java regex exists, here are a few links: FR quick list, Oracle Docs, online Java regex evaluator

How to keep your application / server responding when you’re running out of memory – FusionReactor Survival Strategy


FusionReactor has many great features one of the most overlooked and possibly one of the most powerful is EnGuard Crash Protection (CP).   This feature is able to alert you as well as prevent your servers from falling over by limiting the load based on a variety of criteria.

In this post I will walk you through how to setup the various settings for CP and the benefits of using these features.

Scenario – Application Server is running low on memory

Let us imagine the situation where, for whatever reason, the application server that you are running on is consistently running out of memory. By using FusionReactor’s Crash Protection features we can be alerted to the situation and take steps to keep the system / application operational.   Of course you will be investigating the cause of the memory issue, but in the mean time FusionReactor can buy you the time to ensure that service levels are maintained and you have minimized impact to your customers/business.   By using the FusionReactor’s “WebRequest Memory Protection” feature, you can limit the traffic on your server by either queuing or rejecting requests based on the current JVM memory usage.   FusionReactor can also invoke system garbage collections if we exceed the threshold values, to help reduce the over all memory usage of the application.

Goal

In this situation the goal is to reduce the concurrent requests running on the application when the memory usage exceeds a specific value. What we want to do is make FusionReactor queue requests when the memory usage exceeds 80% for more that 15 seconds.

Steps

Our first action here is to enable the Crash Protection features. This does not require a restart and will take effect immediately.

  • Go to Protection -> Settings
  • Click on “WebRequest Memory Protection”
    1. Change the “WebRequest Memory Protection Threshold” to 80%
    2. Change the “Minimum condition Duration” to 15
    3. Change the “Memory Protection Strategy” to “Queue and Email Notification” or “Queue”
    4. Enable “Automatic Garbage Collection Trigger”
  • Click “Save FusionReactor Settings”
  • CP Blog

If you are using the “Queue and Email Notifications” you will need to enable email notifications under Protection -> Settings -> Email Settings, you will also need valid Email settings in the FusionReactor -> Settings -> Email Settings page.

Results

When the system is setup correctly you will begin to see FusionReactor start queuing requests as they come in. These requests will be queued for 60 seconds, (configurable in the protection settings), before they timeout.    This request queue is nicely displayed in the Request -> Activity screen, clearly showing the time in the queue and the time until the request is rejected.    The request will be served as normal if the memory usage falls below 80% before the request times out.

The requests that are rejected based on the queue timeout, are tracked into a separate screen, Requests -> Rejections, and a summary is available on the WebMetrics page. Additionally the garbage collection metrics are tracked on the Resources -> Garbage Collection page (from FusionReactor 5 and later)

So hopefully at this stage you will have saved your system from collapsing from an out of memory error, kept the server running and bought yourself more time to diagnose the initial cause of the memory issues on the system.     FusionReactor saves the day (AGAIN !).

Advanced Option

In addition to the setting described above the following options are available to improve the effectiveness of FusionReactor Crash Protection.

Garbage Collection

When using the memory protection settings feature, you might have noticed the “Automatic Garbage Collection Trigger”. This feature is a very useful tool if you are experiencing memory issues on your application server. By using this setting you can configure FusionReactor to perform a garbage collection (GC) when the request starts.  As you may be aware performing a garbage collection can be an expensive operation, as such, FusionReactor comes with a rate limiting option. The “Minimum Garbage Collection Interval” setting allows you to set the minimum time that must elapse before FusionReactor will invoke another garbage collection.

[FR-2832] How to add a FusionReactor Plugin to your FusionReactor installation

Description

Description

This article provides a set of instructions for adding FusionReactor plugins to existing FusionReactor instances and to the FusionReactor installation so that instances created in the future contain the plugin. This article provides a use case scenario, that scenario is how to add the Notification Generator plugin.

Adding a plugin to a FusionReactor instance

As mentioned in the Description this article provides a use case scenario.

1) Obtain the plugin from the FusionReactor plugins download page, click here to be taken to the page. For this scenario we would download the FusionReactor Notification Generator plugin.
2) Stop the server that contains the instance of FusionReactor that you want to add the plugin to.
3) Copy the plugin that you downloaded in step 1 into the FusionReactor instance’s plugins directory. The plugins directory is located in <FusionReactor_Home>/instance/<Instance_Name>/plugins. For this scenario it is located at C:\FusionReactor\instance\cfusion.cfmx10.HP-Pdv6-Laptop\plugins.

4) If you are running FusionReactor on a UNIX based machine (Linux, Solaris, MAC or generic UNIX) then you need to follow this step, if you are running FusionReactor on a Windows machine you can skip to step 5. When you copy over the plugin to your plugins directory, the plugin may not be owned by the same user and group as the other plugins. For example all your plugins may be owned by nobody and the plugin you downloaded may be owned by root. If your server is run as nobody then it may run into some problems in the future, so it is important that you follow this step. If it is owned by the same user and group as your other plugins then you can skip this step.

To allow the plugin to work in your environment, change the user and group of the plugin to be that of the other plugins. For our scenario this is how it would look.

Check to see if the plugin is owned by a different user and group to the other plugins.


The plugin, fr-notification-generator-plugin-1.0.0.jar, is owned by user root and group root

Change the permissions of the plugin by using the chown command.


The plugin, fr-notification-generator-plugin-1.0.0.jar, is now owned by user vmuser and group bin





5) Start your server back up and your plugin will be loaded up.
6) See Checking that your plugin has been correctly loaded into your FusionReactor environment to check if your plugin has been correctly loaded.

Configuring your environment so that the plugin is added to future FusionReactor instances

As mentioned in the Description this article provides a use case scenario.

1) Obtain the plugin from the FusionReactor plugins download page, click here to be taken to the page. For this scenario we would download the FusionReactor Notification Generator plugin.
2) Copy the plugin that you downloaded in step 1 into the plugins-deploy directory in FusionReactor. The plugins-deploy directory is located in <FusionReactor_Home>/etc/plugins-deploy. For this scenario it is located at C:\FusionReactor\etc\plugins-deploy.
3) If you are running FusionReactor on a UNIX based machine (Linux, Solaris, MAC or Generic UNIX) then you need to follow this step, if you are running FusionReactor on a Windows machine you can skip to step 4. When you copy over the plugin to your plugins-deploy directory it may not be owned by the same user and group as the other plugins. For example all the plugins may be owned by nobody and the plugin you downloaded may be owned by root. When you use FRAM to create a FusionReactor instance it copies the plugins from the plugins-deploy directory to the plugins directory of the newly created instance. If FRAM is running as nobody and the newly added plugin is owned by root then it will not be able to copy over the plugin when an instance is added. Simply change the user and group of the plugin to be that of the other plugins. Step 4 in the Adding a plugin to a FusionReactor instance section explains in detail how to do this.
4) Whenever a FusonReactor instance is created, it will come bundled with the newly added plugin.
5) See Checking that your plugin has been correctly loaded into your FusionReactor environment to check if the plugin has been correctly loaded into your newly created FusionReactor instance.

Checking that your plugin has been correctly loaded into your FusionReactor environment

1) Access the FusionReactor instance that contains the newly added plugin.
2) Navigate to Plugins > All Bundles
3) The All Bundles page lists all the FusionReactor bundles. A plugin is a bundle so it will be listed on here. Locate your bundle in the list and check that the status is listed as Active. If this is true then the plugin has successfully been loaded.
4) If your plugin is not listed as Active or it isn’t listed at all check the OSGi Log (Plugins > OSGi Log) for clues as to what went wrong. Also review all the steps you performed. It is a common mistake to add the plugin to the wrong FusionReactor instance.


The Notification Generator plugin was successfully added


How to use the Notification Generator Plugin.

See the FusionReactor Notification Generator Plugin documentation.

Issue Details

Type: DevNet
Issue Number: FR-2832
Components: Documentation
Environment:
Resolution: Unresolved
Added: 28/06/2012 15:34:18
Affects Version:
Fixed Version: 5.0.doc
Server:
Platform:
Related Issues: None

[frs-233] FusionReactor Nagios Plugin

FusionReactor Nagios Plugin

What is Nagios?

"Nagios is an enterprise-class monitoring solution for hosts, services, and networks released under an Open Source license."

Source: http://www.nagios.org, March 12th 2009

Many companies use Nagios throughout the enterprise to alert them of operational abnormalities. This plugin allows you leverage the unique monitoring capabilities of FusionReactor from within your existing Nagios environment.

Nagios Exchange

Plugin Details

This is a Perl plugin for the Nagios monitoring system to allow monitoring of your J2EE application through the FusionReactor software.

You can monitor & track high level metrics (instance CPU, heap memory, JDBC calls, average request time, etc) from within Nagios. If/When an issue is alerted from Nagios, you can use FusionReactor to investigate further.

Monitoring ColdFusion with Nagios

FusionReactor can monitor any type of J2EE server. ColdFusion runs on a J2EE server meaning that you can monitor your ColdFusion application with Nagios using FusionReactor and this plugin.

You can also monitor your Railo server with Nagios or OpenBD (Open BlueDragon) using this Nagios plugin.

Requirements

System to be monitored (J2EE server)

  • FusionReactor Enterprise Edition

Monitoring Host (Nagios server)

The following modules can easily be installed via CPAN. Further instructions are available in the documentation:

  • Nagios::Plugin
  • File::Basename
  • LWP::UserAgent
  • Digest::MD5
  • MIME::Base64
  • XML::XPath
  • XML::XPath::XMLParse

Latest Version

Latest Stable: Nagios Plugin 1.0

Download
Documentation

Changelog

1.0 – Initial release

Issue Details

Type: DevNet
Issue Number: FRS-233
Components: Compression, Content Filters, CPU + Memory, Crash Protection, Enterprise Dashboard, FR Enterprise Dashboard Desktop Application, FusionReactor Settings, Installer, JDBC, License + Activation, Logging, Metrics, Request Managment, Thread Management
Environment:
Resolution: Fixed
Last Updated: 25/Aug/15 4:32 PM
Affects Version:
Fixed Version: 1.0, 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5, Pending
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-334] Railo Extension for FusionReactor v5

About

This is a Railo Extension store plugin to simplify deployment of the FusionReactor server monitor.

What does the extension do?

  • Email a trial license to the installer
  • Deploy latest version of FusionReactor (or fall-back to the bundled version for servers with no direct internet access)
  • Automatically update container JVM arguments
  • Offer an uninstall option

Supported Platforms / System Requirements

For the FusionReactor software system requirements, please see https://www.fusion-reactor.com/system-requirements/.

The extension should function in all recent Railo releases but has been most thoroughly tested with Railo 4.1.2.005 final (Endal) using both the Tomcat and Jetty (aka Railo Express) deployments on Windows Server 2012 and CentOS 6.5 64-bit.

Help Videos

http://www.youtube.com/playlist?list=PLDIpVdHiiEMdxsppX-EpS9dFpZdGM3_hn

Issue Details

Type: DevNet
Issue Number: FRS-334
Components: Installer, Instance Manager
Environment:
Resolution: Fixed
Last Updated: 13/Mar/14 3:35 PM
Affects Version:
Fixed Version: 5.0.0
Server:
Platform:
Related Issues:

FusionReactor v5 Java Server Monitor – A feature tour

A 20 minute feature tour of FusionReactor v5 visiting:

  • Enterprise Dashboard
  • Web Metrics
  • Real-Time Running Request List
  • Request History
  • Request Details
  • CPU Thread Time
  • TCP/IP Stream Metrics
  • HTTP Headers
  • JDBC Transactions
  • HTTPClient/WebService Transactions
  • Longest Requests (since server started)
  • Slowest Requests (recent pages longer than threshold)
  • HTTP 500 Server Error Details
  • User Experience Monitoring (UEM) (e.g. client network & browser rendering time)
  • Custom Transactions (e.g. tracking custom API calls)
  • Custom Metrics (tracking custom business metrics – e.g. revenue)
  • Custom Dashboard (e.g. revenue vs page execution time chart)
  • Metric History (e.g. CPU last hour/day/week; pan/zoom; etc)
  • Both Heap & Non-Heap Memory Spaces (e.g. PermGen)
  • Garbage Collection Timing
  • Thread State Charts (e.g. identifying locking contention)
  • EnGuard Crash Protection (e.g. alerts before failure or prevents server from failing)
  • Daily Report Email (e.g. managers don’t need to login for overview metrics)
  • Log rotation & archiving (including JVM logs)
  • Info/Warn/Error Notification system
  • Desktop, iOS, Android dashboard application
  • Stack trace running request (e.g. see what line of code is currently being executed / where a slow page is stuck)

[frs-228] Using FusionReactor’s JDBC Driver Wrapper With ColdFusion 9 ORM

Using FusionReactor's JDBC Driver Wrapper With ColdFusion 9 ORM

FusionReactor's JDBC Driver Wrapper is a great addition to ColdFusion 9's Object-Relational Modeling capabilities. You can use it to spy on what Hibernate (ColdFusion's ORM provider) is really doing to your database.

This article doesn't go into detail about what ORM is, or how it works – there are many posts and articles on the web which cover this in detail:

Why Use the JDBC Driver Wrapper in Your ORM Configuration?

Adobe's integration of the third-party Hibernate framework brings ORM functionality to your CFC-based applications. This brings with it some new, important concerns for ColdFusion developers:

  • How is Hibernate converting my entity operations to SQL?
  • Why are they running so slowly?
  • How is Hibernate locking the DB?

You can use the setting Application.cfc setting this.ormsettings.logSQL to have Hibernate dump its SQL to the log as it's created, but you'll soon find the log is overflowing with data.

  • FusionReactor's JDBC Driver Wrapper associates your queries with the precise request – and ultimately CFC/CFM line of code – in which they run.
  • You can use the JDBC tab in FusionReactor's Request View to see what ran, how long it took, and how many rows came back – great for tuning and catching runaway queries.

How Do I Set This Up?

Getting this working is simple, just follow the steps below.

Get FusionReactor

  • Download and install FusionReactor – you'll need version 3.5.0 or better. You can get a 10-day free trial here.

Use FusionReactor's JDBC Driver Wrapper

  • You'll need to create a wrapped datasource. This won't replace your original datasource, but it will allow our lightweight wrapper to spy on he interaction between ColdFusion, Hibernate and the database.
  • You can use the instructions in the FusionReactor JDBC Driver Wrapper User Guide, or download and use our free tool (just run the tool and have it wrap your datasource automatically).
  • Once you've got a wrapped datasource, change your ORM datasource in Application.cfc to point to the new datasource.
	this.datasource = "orm_WRAPPED";

.. for example.

That's it!

Spying on Hibernate

Once you've installed the FusionReactor JDBC Driver Wrapper, and adjusted your Application.cfc to point to the wrapped datasource, you can have a look at the collected data. We ran the 01_createmusician.cfm script from Mark Mandel's introductory app (from Introducing ORM in Adobe ColdFusion 9), with this.ormsettings.logSQL = true turned on in our Application.cfc.

What came out in the log was:

Hibernate: 
    insert 
    into
        Musician
        (name, age) 
    values
        (?, ?)
Hibernate: 
    select
        currval('Musician_musicianID_seq')

But that's not only what ran – the log isn't showing you everything. Inspecting the JDBC tab of the request in FusionReactor actually shows us exactly what's going on:

There's actually a whole bunch of overhead. We turned on "Record In Order" in FusionReactor's JDBC Settings, so this list is in time order – including a whole set of alters, drops, creates (JDBC transaction 1), then the load of sample data (transactions 2 and 3), the actual insert from the CFM page itself (transactions 4 and 5), and the select from the page for the dump (transaction 6).

Conclusion

We think FusionReactor's JDBC Driver Wrapper is an awesome tool to spy on exactly how Hibernate and ColdFusion 9 is interacting with your database. Object-Relational Modeling is going to revolutionize how you deal with your databases, and FusionReactor is going to make your life easier in analyzing and solving problems.

Issue Details

Type: DevNet
Issue Number: FRS-228
Components: JDBC
Environment:
Resolution: Fixed
Last Updated: 08/Sep/11 10:50 AM
Affects Version:
Fixed Version: 3.5, 4.0.0
Server:
Platform:
Related Issues:

[frs-300] FusionReactor Wrapper Tool for FusionReactor 4.5.x and above

JDBC Wrapper Tool for FusionReactor 4.5.x and above

Users using FusionReactor 4.0.10 or lower should use the original wrapper found here.

The JDBC tool is designed to provide an automated interface to configure the FusionReactor JDBC Wrapper. The tool uses the CF admin API introduced in CF7 to add/update your DSN entries. Once installed, the JDBC wrapper doesn't break if your FusionReactor license expires (trial or subscription).

Note: The tool is still under active development. Though we have used this succesfully we cannot guarantee it will function in all cases. Please check below for our tested compatibility chart.

Requirements

FusionReactor
CF7 or above OR A Compatible CFML Engine

Latest Version

The latest versions available for download are:

Latest Stable: 1.0.1
jdbc_tool_v1.0.1.zip

Usage

FusionReactor 4.5.x now supports a classpath option in the JDBC URL. For non-macromedia drivers (those that previously required the split-jar method) you can supply the path to your JDBC driver jar file and FusionReactor will function correctly. The split-jar method has been completely removed with FusionReactor 4.5.x and so users are required to perform this update.

  1. Download the updated FusionReactor Wrapper Tool
  2. Copy the fr_jdbc_wrapper.cfm file to /CFIDE/administrator/fr_jdbc_wrapper.cfm on your server, ensuring you have permission to run it.
  3. Navigate to this page via your browser.
    • If you have any wrapped data sources from older versions of this tool, you should unwrap them now. Click the "Unwrap" link at the top left and continue though the steps of the tool.
  4. Select the data sources you wish to wrap.
  5. If a text field is visible in the "Driver Jar" column then you are required to supply a canonical path to the JDBC driver jar file. EG:
    • CF10: C:ColdFusion10cfusionlibmysql-connector-java-commercial-5.1.17-bin.jar
    • CF9 Multi-server: C:JRun4libmysql-connector-java-commercial-5.0.5-bin.jar
    • CF9 Stand-alone: C:ColdFusion9libmysql-connector-java-commercial-5.1.11-bin.jar
  6. You can click the "Use for all of this type" checkbox to use the same driver file for all data sources of that type (e.g. all MySQL data sources). This is not recommended for Derby data sources.
  7. Once you have entered the correct paths to your driver jars, click next and navigate through the rest of the tool to wrap your data sources

Compatibility Notes

Railo

  • There is an additional requirement for Railo. Please (temporarily, whilst running the tool) set the Server Administrator->Security->Access->General->Access Read setting to "open".

Tested Compatibility

Adobe CF 7,0,2,142559

  • Microsoft SQL Server
  • ODBC Socket

Adobe CF 8,0,1,195765

  • Apache Derby Client
  • Microsoft SQL Server
  • MySQL (4/5)
  • Apache Derby Embedded (Requires CF Restart)
  • ODBC Socket
  • PostgreSQL
  • Other JDBC Driver
  • Sybase

Adobe CF 9,0,0,251028

  • Apache Derby Client
  • Microsoft SQL Server
  • MySQL (4/5)
  • Apache Derby Embedded (Requires CF Restart)
  • ODBC Socket
  • PostgreSQL
  • Other JDBC Driver
  • Sybase

Adobe CF 10

  • Apache Derby Client
  • Microsoft SQL Server
  • MySQL (4/5)
  • Apache Derby Embedded (Requires CF Restart)
  • Other JDBC Driver

Railo 4.0.4.001

  • MSSQL – Microsoft SQL Server (Vendor Microsoft)
  • MSSQL – Microsoft SQL Server (Vendor jTDS)
  • MySQL

Issue Details

Type: DevNet
Issue Number: FRS-300
Components: JDBC
Environment:
Resolution: Fixed
Last Updated: 01/Jul/13 12:56 PM
Affects Version: 4.5.0
Fixed Version: 4.5.0
Server:
Platform:
Related Issues:

Announcing Ortus ProfileBox – a ColdBox profiling / monitoring extension for FusionReactor 5

profilebox logo Ortus ProfileBox is a ColdBox module that will provide you with profiling, metrics, CacheBox reports, custom object metrics, exception notifications, LogBox integration and much more for any ColdBox 3.5 application.

ProfileBox is available for FusionReactor 5.x – for more details go here – www.goprofilebox.com/

Capabilities

  • Profile and take metrics of any ColdBox Event including ability to trace hierarchical executions, renderings and handler results
  • Profile ColdBox User Experience metrics from time spent in ColdBox code, to Client Code to Network time
  • Profile rendering of any layout or view
  • Ability to trace the request collections via any ColdBox event requested
  • Ability to profile any WireBox-managed object via our very own method and component annotations
  • LogBox appender for creating FusionReactor notifications
  • LogBox appender for creating FusionReactor request tracers
  • WireBox mappings for interacting with FusionReactor tracers and notifications a-la-carte
  • Ability to profile all caches monitored by CacheBox
  • Exception handling that can send your exceptions to the FusionReactor Notifications

[frs-239] Automatically login to FusionReactor with a Cookie

Background

FusionReactor provides several user roles each allowing a different set of actions. The Observer role allows users view only access to the metrics FusionReactor is gathering.

In some organisations, it could be beneficial to allow users to automatically login as the Observer user. This can be achieved by setting a cookie on the client browser – this process is shown here.

Process Overview

  1. Find the Cookie



    • Login to FusionReactor in the normal way
    • Find the cookie in your browser / debugging-proxy
    • Save this information for later



  2. Logout of FusionReactor



  3. Create a login portal page




    Note: This page must be able to write cookies to the same (or parent) domain name



  4. Test

Screencast / Video How-To

@video(FRscreencast.jpg,fr_autologin4.swf,640,498)

Sample Code

autologin.html
<html>
	<head>
		<title>FusionReactor Auto-Login</title>
	</head>
	<body>
		<script type="text/javascript">
			document.cookie =
				'FusionReactorAuthorization.cfusion.jrun4.DJS02WORK3' +
				'=' +
				'Administrator:E69315267C51BB306D16D719107C832A' + 
				'; expires=Sat, 1 Jan 2011 00:00:00 UTC; path=/';
			window.location = 
				'http://localhost:8088/fusionreactor/';
		</script>
	</body>
</html>

Issue Details

Type: DevNet
Issue Number: FRS-239
Components: FusionReactor Settings
Environment:
Resolution: Fixed
Last Updated: 20/Nov/09 2:52 PM
Affects Version: 3.5
Fixed Version: 3.5
Server:
Platform:
Related Issues: