FusionReactor 8.7.3 released: some email-related enhancements/fixes

Note: This blog post is from 2021. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Of course, if you view your FR on-premises user interface, that should inform you when a new version is available (at least since FR versions of the past couple of years). You can also learn of FR updates via the FR downloads page.  As for what the update offers, that's offered in the release notes, whose link is also offered on that downloads page above. 

For the TL;DR crowd, if the brief several words per fix offered in those release notes may be enough for you, you're done. If instead you're left wondering just what they may be referring to, I can elaborate. The changes are things I'm especially glad to see.

Enhancement: Easier understanding of failed email tests

One of the changes in 8.7.3 makes it far easier for folks to understand when they may have a failure in trying to setup FR's email handling. In the traditional on-premises UI (as opposed to the Cloud UI), you would use the FusionReactor menu in the top left corner, then choose Settings, and the first page is Email Settings. (If you set that up, you can get notified of the FR Daily and other reports, as well as FR CP Email notifications if you set those up in the FR Protection>Settings page.)  That settings page lets you specify the from name, to name (or list), mail server/port, username/pw, etc.

And if you've been to that Email Settings page, you will have noticed and likely tried to use the Send Test Email button

Until now, though, if there was anything wrong with the info you provided, you were simply told that it "failed to send email". As for what the problem was, you had to know how to go digging into FR's logs.

With this update, you will instead be offered a link to the specific log, as the error message will indicate:

Note how that message will offer a link for you to view your reactor log right there in the FR UI. (BTW, you can view any of the FR logs in the FR on-premises UI, using that same FusionReactor menu in the top left corner, then Logs. Note the option on the top right of that logs page shown, where you can choose WHICH log to view.) Many people just never knew a) THAT they could view those logs that way, let alone b) THAT the mail send failure error was tracked in the reactor.log. 

This is one of those little changes that will be a big help for many. Thanks, FR team!

Enhancement: You no longer have to REMEMBER to enable emailing of CP alerts

This next enhancement relates to when you may setup FR's Crash Protection alerts (in the on-premises edition). If you've set them up, you know that you go to the Protection>Settings menu, where you can setup either of the alerts for request quantity, timeout, memory (heap), or CPU conditions.

And there is also there an Email Settings page--not the one of the same name mentioned above.  But this email settings page does RELY on your having setup that other settings page (it sends the alerts to the email addresses listed in the TO address there).

But until this release, one had to KNOW (after setting up the alert conditions) to come into this OTHER Email Settings page, and then to change on that page the Notification Emails option to Enabled. 

From 8.7.3 on, that option is now enabled by default, so you no longer need to remember to enable that. I have helped many folks over the years who HAD setup FR CP alerts, but had not thought to set that Email Settings to be enabled, so they were not getting the alert emails. (Or they didn't know to setup that other Email Settings page above, so they were not getting either FR's alerts or FR's reports.)

Fix: FR can now send emails via TLS 1.2 and above

This next issue is a problem I had identified to them just a few days before the new release, and they come out with a fix and rolled it into the update. Again, thanks guys!

So before 8.7.3, if you had setup FR to send emails to a mail server that supported TLS 1.2 or above, and you told the FR Email Settings page to have TLS Authentication enabled (see the first screenshot above), then FR did not use that more secure protocol version 1.2. If the mail server used TLS 1.1 or earlier, the mail was still sent, but using that. And perhaps you never had any reason even to notice that.

The problem came with the recent Java updates in April (and July), for Java 11.0.11 or above, and Java 8.0_291 or above, where by default those would now NOT allow any connection to be made to a server supporting anything lower than TLS 1.2.  (I have a blog post on that JVM change, as well has how you could configure things to ALLOW the JVM to communicate via TLS with servers supporting only 1.1 or 1.1.) With that JVM change in place, though, now FR would no longer deliver email if talking to a server supporting only TLS 1.2 or above. 

The fix in 8.7.3 has updated the mail library used by FR (which was NOT the one used by CF, Lucee, etc.) so that it CAN "talk TLS 1.2" or above.

So as I said at the open, if you may only now realize that you had not gotten FR reports or alerts in recent weeks, it could be that someone updated the JVM used by your monitored instance (of CF, Lucee, or other), and now FR was failing to send its email. This fix solves that problem, so you may find you start getting such FR emails delivered again.

Let me repeat: this problem (now fixed) would only have affected you under these specific circumstances:

• You had configured FR's Email Settings page so as to get its reports or alerts (many never bother or fail to know about it), and
• You had configured that page to use TLS, and
• You had updated the JVM underlying your monitored FR instance to use Java 11.0.11 or later or Java 1.8.0_291 or later, and
• Either a) the SMTP mail server DID support TLS 1.2 or above (but FR was not using that) and so emails from FR were failing to send
• or b) the SMTP mail server did NOT support TLS 1.2 or above (and now the JVM was rejecting the call out, unless you implemented the JVM config change in my blog post mentioned above), and so emails from FR were failing to sent

Some may feel that's a rather obscure set of conditions, but in fact I suspect a lot more people were impacted by the problem in recent weeks (since implementing one of the JVM updates from April or July) who may simply not have realized it, because they may have FR's reports and alerts going to a folder, or they just stopped noticing them generally. Of course, it would be quite unfortunate if instead it's that they were simply presuming there were no alerts at all, when there were but they just were not being sent. 

(I've long lamented and pleaded with the FR folks to offer us a page in the FR UI to track when FR CP alert emails are sent/attempted. Some may notice that the Metrics>Web Metrics page has a count of CP's, but that only counts if you told the CP alert to attempt to kill a request--which I nearly always do not enable, preferring instead to rely on the CP alert email to help me find and really solve any problem.)

Two other changes in the 8.7.3 update

Wrapping up, there are just two more other changes in the 8.7.3 update. 

One is an improvement, but I have not been able to discern how things have changed. As the release notes indicate, they have "Improve[d] Instance Manager failed install pages." My sense is that if you are using the FRAM (FusionReactor Administrative Manager) to install FR into an available instance (of CF, Lucee, or other), if there is a problem doing that they are seemingly adding more information. I guess I won't know what improvement that is until I experience such a failure. :-)

The other is listed as, "UI Fix - Debugger does not show breakpoints if debug email alerts are disabled." I'd never noticed that before myself, but ok. I suspect many will never have seen it. Indeed, so few people seem to even know about the FR debugger, let alone about its feature to send emails rather than perform interactive step debugging. 

Covering the FR debugger would be worthy of its own post, and frankly several.  I'll note that I did an hour-long webinar for Intergral (makers of FR), available as a youtube video, on the features of the FR Ultimate edition, and I spent about 25 mins on the debugger. See the video, starting at the 34:50 mark (but you may want to watch the entire video if you have an hour and want to appreciate other features of the Ultimate edition (which is the same as the Trial or Developer editions).

So there you  go, all about FR 8.7.3. I don't tend to do a blog post detailing each FR update, and in fact I can't recall the last one I did. Many updates have bug fixes or perhaps features of interest to some specific segment of users. I felt that this one, with its focus on mostly email-oriented enhancements or fixes, deserved to be covered with this additional detail.

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed