Exceptions and Caching

[shuns]

Hi All

I have a question regarding the best way to handle and exception being
thrown from within a series of statements wrapped in a pair of <cache>
tags.

Up until now (before using caching) my exception handling had been
good - I have an exception event handler which fires a listener do
notifications etc *and* determine an event to be run, depending on
exception type (such as: per environment, missing args, missing event
handler etc etc). This was handled with event mappings.

Now that I have caching in place, if an event mapping is triggered via
the exception event, all I get is a pure white screen.

What would be the best way to overcome this? As I really need to be
able to keep the multiple mappings per exception type also.

Thanks

[Peter J. Farrell]

I assume you are using the Simplicity (1.8) BER.

I'm going to look into this, but it's probably just a missing <cfsetting
enabledcfoutputonly> that is not getting flipped back. Where in your
code when using a cache is the exception occurring? In a listener,
view, etc.? If you let know, I can probably find it faster otherwise it
will take some time figuring out where the missing tag is.

.Peter

shuns said the following on 11/02/2009 07:45 PM:

[Net Grow - Shaun]

Hi Peter,

I am using version 1.6.1 stable (we have not changed over to version 1.8
until the stable release comes out).

I have just done some testing, I get a white screen if there is an error in
a listener, but the weird thing is I see the error the first time, but on
page refresh just get a white screen. Not sure why I see the error page
first time though.

Is it going to work for me to be able to still have the exception event
delegate multiple error types to different exception event handlers still?

ie:

<!-- exception handlers -->
<event-handler event="exception" access="private">
<event-mapping event="development" mapping="developmentException"/>
<event-mapping event="test" mapping="testException"/>
<event-mapping event="production" mapping="productionException"/>
<event-mapping event="noEventHandler" mapping="noEventHandlerException"/>
<event-mapping event="missingEventArgs"
mapping="missingEventArgsException"/>
<event-mapping event="maxEvents" mapping="maxEventsException"/>

<notify listener="exceptionListener" method="delegate"/>
</event-handler>

<event-handler event="developmentException" access="private">
<view-page name="exceptionDevelopment" contentarg="mainContent"/>
<!-- render page layout -->
<execute subroutine="publicLayout"/>
</event-handler>

<event-handler event="testException" access="private">
<view-page name="exceptionTest" contentarg="mainContent"/>
<!-- render page layout -->
<execute subroutine="publicLayout"/>
</event-handler>

<event-handler event="productionException" access="private">
<view-page name="exceptionProduction" contentarg="mainContent"/>
<!-- render page layout -->
<execute subroutine="publicLayout"/>
</event-handler>

<event-handler event="noEventHandlerException" access="private">
<view-page name="exceptionNoEventHandler" contentarg="mainContent"/>
<!-- render page layout -->
<execute subroutine="publicLayout"/>
</event-handler>

<event-handler event="missingEventArgsException" access="private">
<view-page name="exceptionMissingEventArgs" contentarg="mainContent"/>
<!-- render page layout -->
<execute subroutine="publicLayout"/>
</event-handler>

<event-handler event="maxEventsException" access="private">
<!-- try to only include the view page -->
<view-page name="exceptionDevelopment"/>
</event-handler>
<!-- end exception handlers -->

That way I have mach ii exception events routed into the "exception" event
handler, then show views depending on type.

HTH

Feel free to ask any more questions of me for clarification.

Regards
Shaun

[Peter J. Farrell]

inline below...

Net Grow - Shaun said the following on 11/03/2009 03:41 PM:

Hi Peter,

I am using version 1.6.1 stable (we have not changed over to version 1.8 
until the stable release comes out).
  

You might drop in 1.8 BER (not the beta1 from August) to see if it fixes your problem.  At first, I thought it was due to 1.8 because we add a lot Simplicity to eliminate whitespace produced by the framework.  In 1.8, it is virtually none.

I have just done some testing, I get a white screen if there is an error in 
a listener, but the weird thing is I see the error the first time, but on 
page refresh just get a white screen. Not sure why I see the error page 
first time though.
  

Are you using <cfsetting enablecfouputonly="true"/> anywhere?  I suspect that you are getting the exception page after the first time -- it's just being hidden by an errant enablecfoutputonly="true" in your code somewhere.

I'd turn on Mach-II logging by adding this to your configuration file:
<property name="logging" type="MachII.logging.LoggingProperty"/>

By default, you'll get the logging output to the browser -- hopefully you can see what is going on.  I suspect that if the logging output at the bottom is missing -- it indicates a problem with cfenebalecfouputonly.

Another problem could be if you have a plugin that is intercepting the exception and clearing the event queue in which no exception event is ever processed.  I suspect the logging output will help here.

Is it going to work for me to be able to still have the exception event 
delegate multiple error types to different exception event handlers still?

  

That shouldn't be a problem. I've been using this approach for years.

[Net Grow - Shaun]

Hi Peter,

 

Thanks for the response.

 

I am not keen to change out mach ii right now unless I absolutely have to as we are on a tight deadline to finish and are about to put up for live testing.

 

I am using enablecfoutputonly="false" in my app.cfc but I am not using it anywhere else. I tried removing it and it made no difference anyway.

 

I added the logging property and can see it even when the screen goes all white, however the data logged is quite different when an error is cause inside the cache block (http://netgrow.com.au/files/1.png), compared to without a cache block (http://netgrow.com.au/files/2.png). Without a cache block in place I get my normal error page, but with it only white (except the logging at the page bottom of course).

 

The reason why I asked the last question was that even though I have been using that method since I started with mach ii, I was reading the wiki notes on caching and that there was supposed to be no event-mapping, announce or redirects from inside the cache statement and so I figured that my event mapping / announceEvent() combo inside the exception delegate may be causing an issue is all.

 

HTH

[Peter J. Farrell]

Shaun,

In 1.png (where there is a cache block), I see no exception being thrown.  It's replaying the recorded data in the cache, I suspect that you're not actually caching anything in the cache based on the following logged message:

"Cache data contained keys of ''"

There is no data cached for the cache block and I suspect there is no output either.  If there was data being cached, the the two single quotes which are empty should have a list of event key names.  That is why you are getting the white screen of death.

The solution.  Are you using contentKey in view-page or resultKey in your notify calls?  Those attributes have been deprecated a few versions ago:

http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/wiki/OfficiallyDeprecatedElements#ContentKeyandResultKey

The caching package cannot introspect data put into random scopes (like the request scope) and only works with when used with contentArg and resultArg attributes (which place data and output in the Event object):

http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/wiki/IntroToCaching#GeneralUsageNotes

I suspect that is why are you not seeing anything cached.

Also, if problems persist (and it's not contentKey/resultKey) -- I'd need a screenshot of the logging output when you have a cache block in the event and on the first execution of that event with an exception.  The screenshot you sent with the cache block usage is replaying data / output and doesn't shed much light on what is going on when an exception occurs during the very first of execution of a cache block.

Best,
.Peter

Net Grow - Shaun said the following on 11/03/2009 05:37 PM:

[Peter J. Farrell]

Net Grow - Shaun said the following on 11/03/2009 05:37 PM:

 

The reason why I asked the last question was that even though I have been using that method since I started with mach ii, I was reading the wiki notes on caching and that there was supposed to be no event-mapping, announce or redirects from inside the cache statement and so I figured that my event mapping / announceEvent()

FYI, if an exception occurs inside a cache block -- the event queue will be cleared and the exception event will always be announced.  Nothing will be cached and therefore the cache will try to cache again on the next request if there is no cache data available.

I think I'm missing a piece of the puzzle here because I don't understand why the cache completed correct and cached data.

Are you explicitly throwing an exception in the listener inside the cache block and you see an exception the first execution of the page and subsequent executions are page screens of death?

Or does it run correctly the first time on the cache block execution and it subsequent requests are white pages of death?

I have a feeling it has to do with contentKey and resultKey which would describe it running correctly on the first request and white screens of death in subsequent requests.  I'm thinking the exception stuff you're talking about is not really related to what is going on (it seems like the odd thing going on -- something I can't reproduce on my end).

.pjf

[Net Grow - Shaun]

Hi Peter,

 

Thanks for the speedy response - I am trying to get you the data straight away :)

 

Here is the event handler for that page:

 

<event-handler event="company" access="public">                      
   <cache aliases="company" criteria="event=${event.do}">       
                <!-- publish message -->
                <publish message="company"/> 
           
                <view-page name="publicCompanyHead" contentarg="headContent"/>    <!-- *** notice content arg for both views *** -->   
                <view-page name="publicCompany" contentarg="mainContent"/>

                <!-- render page layout -->
                <execute subroutine="publicLayout"/>

            </cache>
 </event-handler>

 

And the called listener:

 

 <cffunction name="getCompanyPage" access="public" returntype="void" output="false"
   hint="Get company page content.">
  <cfargument name="event" type="MachII.framework.Event" required="true" />

 

        <cfscript>
  // get required dependancies
  var local = getDependancies();
  
  // get some other vars needed
  local.renderService = getEngine().getServiceFactory().getRenderServic();  // *** forced error ***
  
  // set event args
  arguments.event.setArg("metaTitle", local.i18nFacade.getResource("publicCompanyMetaTitle"));    
  arguments.event.setArg("metaDescription", local.i18nFacade.getResource("publicCompanyMetaDescription"));    
  arguments.event.setArg("metaKeywords", local.i18nFacade.getResource("publicCompanyMetaKeywords"));    
  arguments.event.setArg("titleContent", local.i18nFacade.getResource("publicCompanyTitle"));
  arguments.event.setArg("headerContent", local.i18nFacade.getResource("publicCompanyHeader"));
  arguments.event.setArg("renderService", local.renderService);     
  </cfscript>
 </cffunction>

 

Notice I am not using the deprecated attributes (never have) and where I have on forced a spelling mistake to simulate an error thrown.

 

Here is the screen shots of that first error, before the white screen. Note there are two parts (they wouldnt fit all on one screen)

first part: http://netgrow.com.au/files/3-a.png   and the second:  http://netgrow.com.au/files/3-b.png

 

HTH

 

Thanks

[Peter J. Farrell]

Thanks for the screenshots of the logging output.  I think I see the problem -- it has to do with how exceptions are handled using a publish command inside of a cache block.  Definitely an edge case defect and something we'll fix for 1.8.  The key message was:

"Cache-handler 'aslkdfjasldfjasldjf' has changed the flow of the event"

Because the exception did not bubble to the cache-handler itself and it ended caching the block of command (which at that point there wasn't anything to cache -- hence the white screen of death).

Workarounds:
1. Use straight up notify commands
2. Use the publish command but set the attribute multithreaded="false" (the way exceptions are handled for serial execution of message subscribers is different then the way CF lets us trap exceptions in thread and having to rethrow them)
3. Wait until get the fix applied in 1.8 and upgrade which shouldn't be a problem.  I know quit a few places that have just dropped in 1.8 BER and things work fine. Backwards compatibility is our number one concern when developing a new version of the framework. Plus, we're literally days to a week away from an official RC1 release for Mach-II Simplicity.  I have fours applications in production that have been running a BER of 1.8 since last December.

Your best option is to use #2 for now and then switch to #3 when the fix is committed.

Shaun, thanks again for bearing with me on my many questions on what was going on.  You found an edge case bug. I'm going to log it in a bit -- I'll add you as a CC on the ticket so you can track the progress.

Best,
.Peter

Net Grow - Shaun said the following on 11/03/2009 06:11 PM:

[Net Grow - Shaun]

Hi Peter,

 

No problems with the questions - I totally understand, thats what it takes to make a great product like mach-ii :)

 

I have just tried with multithreaded="false" and that fixes the problem, however I am really relying upon having the multithreaded features, to help spread the load along side the caching as this new website is going to be hit by 10s of thousands of users a day and we want to be able to have as many performance boosters as possible.

 

What is my best option? Is this currently an issue with 1.8?

 

Thanks for all the help so far

[Kurt Wiersma]

I don't know of any load issues with 1.6 but I think it would be worth
considering moving to 1.8 for this fix and for the performance
improvements that Team Mach II (especially Peter) has been working on
inside the framework. I believe one of the companies he worked with
switched to 1.8 at the end of their development cycle with no issues
and saw their performance increase a bit as well.

Is there anything else we can do to help encourage you move to the
latest 1.8 BER? :)

--Kurt

[Peter J. Farrell]

FYI, working on a fix for 1.8.  The related ticket is here:

http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ticket/422

I've reproduced the issue in our test harness application and added a test case.

Best,
.Peter

Kurt Wiersma said the following on 11/03/2009 09:06 PM:

[Net Grow - Shaun]

Thanks for the help guys!

 

If I jump on with 1.8, how long are we looking at untill that issue is resolved? (roughly)

[Peter J. Farrell]

Net Grow - Shaun said the following on 11/03/2009 09:39 PM:

Thanks for the help guys!

 

If I jump on with 1.8, how long are we looking at untill that issue is resolved? (roughly)

Now ;-)  The issue has been fixed.  I published a new nightly build of 1.8 which can be gotten here:

http://www.mach-ii.com/nightly/MachII_1-8-0_nightly.zip

Or you can grab the BER via SVN.

All of our nightlies must pass our unit testing (MXUnit) suite and a var scope check (VarScoper) before being published.

Best,
.Peter

P.s.  You got a mention in both the README and CHANGELOG files in 1.8 for your help in discovering this issue.

[Net Grow - Shaun]

Cool, sounds great. I will check out ver 1.8 and see how it goes.

 

Thanks guys

 

Regards

Shaun

----- Original Message -----

From: Peter J. Farrell

To: mach-ii-for...@googlegroups.com

Sent: Wednesday, November 04, 2009 3:58 PM

Subject: [Mach-II] Re: Exceptions and Caching

[Peter J. Farrell]

FYI, be sure to follow the upgrade instructions in the README.  There are a few things you should do with your CFML engine in order to make sure everything works out.  Otherwise, no changes to your code base should be necessary (unless you're using some unsupported / not-for-public use API calls to the framework).

.pjf

Net Grow - Shaun said the following on 11/03/2009 11:06 PM:

[Net Grow - Shaun]

Thanks Peter,

 

I have downloaded the 1.8 nightly and will that install a go.

[Peter J. Farrell]

FYI, I published a new nightly just seconds ago so you might want to grab that.  Same url.

.pjf

Net Grow - Shaun said the following on 11/04/2009 03:45 PM:

[Net Grow - Shaun]

Hehe ok, I just finished downloading the other one and rebooting CF on our server here, I'll get the new one now, thanks

[Net Grow - Shaun]

I just installed that latest version and our Mach II 1.6 sites seem to be all working fine - Thanks for that.