Gibraltar 3.0 RC - Ready to Rock

We’ve shipped Gibraltar 3.0 RC1, the release candidate build of Gibraltar 3.0.  This is our last planned build prior to the Release To Web (RTW).  Compared to the last beta we’ve incorporated a range of defect fixes from our CEIP data as well as performance improvements just like you’d expect.  Beyond that, we’ve incorporated several improvements that our beta community felt were critical enough to warrant making changes late in the development cycle.

We weren't kidding about millions of messages in a session

We weren't kidding about millions of rows in a single session.

To download the latest build, we recommend you go to the Version History page and pick the top version under Other Version Information.  As with previous betas, you can use this with any valid Gibraltar license key (trial or unrestricted).  You will need current maintenance on your unrestricted key.  If your maintenance has expired, contact us and we’ll get you set up to try out this latest version and discuss your upgrade options.

Working Fluidly with Sessions

Talking with the beta community we’ve seen that people are able to really take advantage of the scalability improvements in 3.0, in particular opening dramatically larger session files and keeping much larger repositories.  This created a few new feature requests we’ve managed to slide in for the release candidate:

  • Independent Session Display: With larger sessions and repositories it was understandable but annoying when UI updates would pause the entire application.  We’ve separated out the user interface threads so each session viewer and the repository viewer have their own, keeping them from interfering with your work.
  • Selective Session Download:  You can pick individual session(s) to download data for immediately and they’ll copy down right away without blocking you.  This is particularly useful if you want to download a large session to complete analysis on it or view later but don’t want to open it right now.
  • Parallel Download: When you have Analyst set to download all session data automatically it used to first download summaries then full data.  If you had a lot of data that meant you weren’t seeing the latest session headers until it completed downloading the backlog of data.  We’ve made these two operations independent and done other optimizations so you can see the latest session information right away, no matter how long it’s been since you ran Analyst.

We also found out from beta users that in the real world they would frequently try to open sessions that didn’t have any local data and the way the system acted (displaying a modal message box) was not very friendly.  As part of making the session display independent we’ve improved how it checks and downloads data to work in the background so it doesn’t interrupt your workflow.  Instead, you’ll see a warning in the status bar

Fortunately, we’ve also found a number of cases where session data should have been available but wasn’t.  We’ve gone through the CEIP data from beta users as well as our own test cases and weeded these cases out.  When the session data is available, you’ll see the progress of it opening the session in the status bar instead.

Live View Changes

Earlier betas had two ways of displaying live sessions - there was a tab on the repository viewer and you could double-click a session to open it into a live view like a local session.  Displaying the live data in the tab had several problematic side effects - it was easy to open many data streams unintentionally by cycling through the session list with the live data tab active and there was no way to let Analyst know to close them.  Additionally, it caused the available space for the list of sessions to be very small.

Talking with a few users that are really taking advantage of live view we determined it was better to provide more space for the list of sessions and make it more explicit when the full stream is opened and closed.  With the latest build we’ve changed it so a new live stream is established when the live session view is opened and it’s shut down (all the way back to the original agent) when the live session view is closed.

Faster, Scalable Analysis

With it being easier and easier to get larger sessions through Gibraltar we’ve had to make upgrades across the board.  One place we’ve improved for 3.0 is how Analysis is performed.  Previously, it would load all of the available data in memory and analyze it together.  Conceptually this was the simplest and fastest approach, but it has two problems:

  • Sessions have to fit into RAM: If you had a large enough session, it might not actually fit into available memory when loaded all at once.
  • Memory was Thrashed: Even when you have a lot of memory it takes real work and can make your application unresponsive if it’s being allocated and freed by the Gigabyte.
To resolve this, analysis now runs on individual fragments.  Since these are limited to 20MB in size by default (and there's really no reason to make them larger) this runs in a relatively modest amount of memory regardless of how large the overall session is.

Notifications are Back

We use notifications to monitor the hub itself!

Previous 3.0 builds didn’t support Hub notifications, either editing them or processing them.  This functionality is back and better than ever in 3.0 thanks to our new session analysis approach that minimizes duplicate analysis when used with a 3.0 Agent.

If you’ve never used notifications, or were discouraged previously because they weren’t fast enough you should give them another look.  With the combined changes in Agent and Hub the time between when something happens and when you get the email is a lot shorter, even under load.

As before, it’s still smart enough to group problems together so you won’t get spammed with email yet it focuses on getting events out as quickly as it can.  You can choose to get HTML-formatted messages (like the one shown on the right) or plain text.

Ready to Use with the Hub Service

We’ve upgrade our public hub service (hub.gibraltarsoftware.com) to a 3.0-compatible build so you can freely use it with the Release Candidate.  We’d encourage you to give it a try because the difference, particularly for web applications and services, is amazing.  We’ve been internally using 3.0 for some time- tracking pretty closely to our nightly builds.  Some of our largest customers have been using it live in production since Beta 2.

We’re confident enough in this build that we’re providing full production support for it - if you use it in production, we’ll provide you with the same support we do for a full release.  So go ahead and use it!

From Here to RTW

What’s left before Release to Web (RTW)?  Not much.  We’re down to:

  • Documentation Upgrades:  We’re going through the documentation looking for any content that might be out of date and extending it to cover new features.
  • Packager Improvements: To help with .NET 4.0-only deployments we’re creating a new .NET 4.0-only packager.  This will have a different file name so it doesn’t conflict with the .NET 2.0 packager.

Other than that, it’s really up to you - let us know your feedback so we can be sure we’re on the mark and ready to go.

Related Posts

We're out of our Last Data Center

Back in January of 2016 we decided to completely transition out of our data centers and into the cloud (primarily Azure). We knew we had to do something - either make some big investments in new hardware or commit ourselves to migrating everything off our own gear. After looking at... Read more

Rock solid centralized .NET logging

Unlimited applications, unlimited errors, starting at $25/month