I’m trying to cache an event, but it’s having no effect - it simply isn’t cached.
How can I enable logging so I can see why it’s not being cached?
My current logBox settings are:
`
logBox.categories = {
“coldbox.system” = { levelMin=“FATAL”, levelMax=“INFO”, appenders="*"}
};
`
Thanks,
Tom.
HOw are you using event caching, can you check your coldbox.eventCaching setting and also show us the code
Coldbox settings:
`
coldbox = {
eventCaching = true,
handlerCaching = true
}
`
Handler:
`
public void function index () cache=“true” cacheTimeout=“30” cacheLastAccessTimeout=“15” {
}
`
That should work, no?
Yep. Reinit the framework. Sometimes metadata get’s cached by the engine.
Also, isntall the ColdBox Debugger. It tells you if the event got cached or not and you can inspect the caches as well: box install cbdebugger.
I already have the debugger - but it’s slightly limited as I’m using memcached as my caching engine, so listing keys etc. is not supported.
I was hoping I could enabled logging for cachebox which might help me troubleshoot, but not sure of the syntax to add the cachebox categories to logBox.
Check for a development override that might be turning event caching back off.
Seems the issue is the content type of the event output I’m trying to cache.
I’m basically trying to cache an avatar service (peoples avatars rarely change) which are stored as jpges in Amazon s3. There’s some fiddling around (checking if a user avatar exists, getting the right size, falling back to a backup image), plus my app overhead (pre/postProcess) which adds up to about 250ms per avatar. With caching I’m hoping to get it down to 20ms.
I’ve tried a redirect to cloudfront and a cfcontent - neither of which are cached.
However, if I just output text - it does get cached.
Any ideas?
I’m not sure the out-of-the-box ColdBox event caching works with redirects or serving binaries via cfcontent. Can you put in a ticket for those. in the meantime, I would recommend just tapping into CacheBox’s simple API to manually cache the data you need to do the redirection or the cfcontent.
Yeah - however most of the request overhead comes through the interception points which get bypassed when the event is cached.
I’m not sure there’s a way to “shortcut” those interceptors without having the event cached, is there?
Thanks,
Tom,
No, but if the interceptor announcements are so slow they’re causing red flags in your performance tests, then I’d enter a ticket for that as well.
Also, what version of Coldbox are you using? We did add some performance improvements to interceptor announcements in ColdBox 5.
I would have to see your handler code.
If you use render data with custom content types the. Event caching works for any type.
Luis Majano
CEO
Ortus Solutions, Corp
P/F: 1-888-557-8057
– -- You received this message because you are subscribed to the Google Groups “ColdBox Platform” group. For News, visit For Documentation, visit For Bug Reports, visit — You received this message because you are subscribed to the Google Groups “ColdBox Platform” group. To unsubscribe from this group and stop receiving emails from it, send an email to . To post to this group, send email to . To view this discussion on the web visit . For more options, visit .
Ding ding ding! We have a winner!
Works now.
Thanks,
Tom.
Can you clarify what you changed to make it work?
I was using setNextEvent to redirect to the S3 asset URL, then I tried cfcontent - neither of which worked.
Then I tried Luis’ suggestion of renderData:
var fileBinary = fileRead(avatarFileLocation);
renderData(data=fileBinary,contentType=“image/jpeg”, isBinary=true);
That worked.
Thanks for the update. Also, did you see my question where I asked what version of ColdBox you’re using? And did you put in tickets for relocating on a cached event and the slowness you saw in the interceptor announcements?
I’m on v4. I should upgrade at some point, but I have some customisations to coldbox I’ve tried in the past to get into the core through pull requests that never went anywhere. If I upgrade, I’d have to ensure those updates would work
The slowness is actually not the interceptor points, but the contents of my interceptor (session configs etc and post request logging). It’s a site wide interception point as my system is a walled garden intranet.
Can you put a link here to the pulls that never went anywhere so we can review them? For your interceptors that slow your stuff down, make them async.
The last comment on both of those pulls was a request for you to resubmit them. One was sent to the wrong branch and another was merged on accident and reverted. You never replied in either case. It looks like the ball was left in your court in both counts.