What's Next - the Road to Gibraltar 3.0

One last update to Gibraltar 2

We’ve done several functional releases this year and we’re going to do one more minor one before we close the books on 2.x.  This last update is going to include some memory usage optimizations, reliability tweeks, and the first version of the Gibraltar Add In API.

Memory and Reliability Optimization

There are a few scenarios we use more memory than we should in the Agent.  These scenarios all revolve around sending larger sessions via email or writing them to a package file (Hub users are not affected because it exchanges data completely differently).  We’re changing how these operations are performed to emphasize using constant memory (and less memory) instead of being optimized for the fastest performance.  For smaller sessions the performance optimizations don’t matter, and for larger sessions it’s preferable to ensure we can not interfere with the running application vs. getting it done in the smallest time possible.  This trade-off is done by not explicitly buffering data in RAM but instead using self-deleting temp files for interim storage.  If your computer has enough RAM the OS will cache these anyway and if you don’t you’ll be thankful we aren’t using what little you have.


We’ve been working on this as part of the 3.0 plan but think there’s enough there to release it early.  This is the first time you’ll be able to extend the Gibraltar Analyst itself using your own code.  Our primary goal was to provide a safety valve - a way you can handle analysis and integration scenarios we’re not handling yet.  If you want to integrate with your own customer service or defect tracking system, create your own visualizations or whatever this will provide a way to get it done.

You’ll be able to extend Analyst in two ways:

  1. Analyze every session: Whenever a session is added to the user repository Analyst checks through it to record error statistics.  You can extend this pipeline to add on your own inspection, looking at the entire log or just the errors.  This is done automatically in the background.
  2. Custom session commands: You can add commands to the context menus wherever sessions are being managed to get specific sessions on request.  You can chose whether you want to provide your own user interface or be run in the background.   Register your command and it will automatically show up on session folders, in grids, and other places where sessions are being managed.

What can you do with this?  Well, a few ideas are:

  • Forward details about errors to an external customer service or defect tracking system: With an Analysis add in you can check each session for errors and create an email or do whatever you need to open a new ticket.  You’ll have access to everything in the session file.
  • Export data into a data warehouse: If you have your own external system for tracking overall metrics or whatever your analysis add in can write data to a file, upload it to a database or whatever you need.
  • Create your own visualization: Since you know exactly how you’re recording data (log messages and metrics) you might want to create your own special graphical treatment that leverages that knowledge to provide quick insight.

Share and Share Alike

A best practice is to ship an extension API with several great examples that show best practices.  Well, we didn’t want to hold it back long enough to get them done so we’re going to be looking to our community for great examples to share.  If you create an extension that others might be interested in, let us know - we’re going to set up a place to share extensions with the community.

We’re interested in hearing from the community on how you want to be able to extend Gibraltar - Analyst, Agent, and Hub - so we can incorporate those ideas into 3.0 and beyond.

And then on to 3.0

We have a queue of items we’re already working on that are too big to fit into a dot release of the product.  For example, we haven’t changed the data format of Gibraltar since the early betas.  There are some issues that we simply can’t fix without adjusting the format which will create a situation where older Analyst won’t be able to read the newer data.  We aren’t willing to do that on a dot release.

We also are going to break new ground in 3.0 on the CEIP front with an all-new application management view of the session information.  When we get closer to our first beta we’ll release more on that and other enhancements.

New features for all our friends

Every Gibraltar customer will get a free upgrade to Gibraltar 3.0 when it ships.  This is the power of our software maintenance in action - every license includes a year of it to make sure you get the most out of your investment.  We don’t have a specific date in mind for shipping 3.0 but expect it to be late Q2/early Q3.

Related Posts

PostSharp Diagnostics Now Supports Loupe in the Box

The latest update to PostSharp Diagnostics adds Loupe support, enabling extensive high-performance logging to be added to any .NET application with virtually no code changes. PostSharp even has a great free option for developers that complements Loupe Desktop! Read more

Loupe Agent for .NET Core Now Available

The first release of the Loupe Agent for .NET Core is also our first open source version of the Loupe Agent. This is the first step in our plan to open source the entire Loupe Agent to make it easier for anyone to extend and take advantage of what Loupe... Read more

We've Moved Loupe Service to App.OnLoupe.Com

Loupe Service now has a shorter, direct site name that's faster, anywhere in the world. Just to go App.OnLoupe.Com, the new CDN-accelerated endpoint for the Loupe Service. Your existing Agents and Loupe Desktops are unaffected by this change, but access to the web UI will be redirected to the new... Read more

Rock solid centralized .NET logging

Unlimited applications, unlimited errors, scalable from solo startup to enterprise.