Into The Box 2019 Notes: CacheBox + LogBox 101, Brad Wood

Docs for anything are here:
cachebox.ortusbooks.com
logbox.ortusbooks.com

Both are part of ColdBox AND ALSO BOTH STANDALONE PRODUCTS!
Can still apply /most/ of this to anything CFML, not just ColdBox apps

CacheBox aims to be a generic caching layer
if you’re in the process of converting to ColdBox, once you have the ColdBox bootstrap, you can access things directly in the Application.cfc to slowly get ready for the ColdBox framework from within your legacy app which is nice

Provides a consistent API for different caching engines
can swap out different back-end cache implementations more easily
Ramcache in Dev, something else in Prod, EHCache, etc.

ICacheProvider
defines the implementation of what the API uses regardless of which type of cache you’re talking to

FEATURES
if using in ColdBox it’s “just there”, don’t have to do anything.
else
it’s a single line of code in applicationstart()
it sticks itself into the application scope /for you/

it’s multithreaded

some built-in Cache implementations have “memory sensitivity” — will evict things if memory is almost full
for in-process caches
Multiple eviction policies available

JVM threshold checks
prevents cache from blowing up and taking all your memory
object count limits
object time based expirations
purging based on object usage (access timeouts)
“store this for 1 hour but if it hasn’t been used in 15 minutes get rid of it)
etc

Cache Monitor - page you can see with the CBDebugger Module inside ColdBox
CAN ALSO GET THIS IN STANDALONE VERSION
useful for cache hits/misses
lots of other useful reporting here to see how well your cache is working

What caches are supported?
CF Provider (EHCache)
Lucee Provider
in-memory (CacheBox)
— stored in memory on the server. most based on “soft reference stores” - a java obj that tells the GC “if you’re ally low on space, you can come collect me and get rid of it”

CouchBase
Redis
Memcached
…all 3 of these are available o ForgeBox.io

Disk Store

DB Store (JDBC)
- uses a database table for caching

Preference - use out of process cache like CoucheBase on a separate server entirely.

Cache Operations -
handful of things you can do, interact with the cache
get(key)
set(key, value)
lookup( key)
clear(key)
getOrSet(key, UDF)
— race condition safe function for getting or setting this value as needed from the cache

some others like memcached have other routings for serialization, etc.

CacheBox.cfc config file
“defaultCache”
list of properties that configure this

“cache” struct
can define as many caches as you want
1 for views, 1 more for whatever else, etc

template { provider = which interface are we implementing for this cache
        properties{} - various settings for configuring this specific cache }

example to store something in cache from in ColdBox

property name=“myCache” inject=“cachebox”
cachebox:default - gives us the default cache
inject tells WireBox where we’re putting this data

then in your controller:
myCache.set( “myItem” { foo: “bar” } );

LogBox ——

Where do the log messages go
files(async)
emails
database
buglogHQ
Sentry
Rollbar
raygu.io
slack
pingdom
..all possible endpoints your logging msgs can be shipped to

LogBox also does log file rotation automatically
logging to a log file doesn’t work in Docker because the container goes down and takes the log files with it
so it’s better to put it all in 1 consistent place

Custom logging levels
what do i want to see? and in what environment?
you may only want to store logs from certain parts of the app/framework
you can dial in “give me everything” or “only give me warnings”, etc.

it’s nice to have a lot of logging already in your code and be able to turn it on/off via some dials in Production,etc.

easier to leave logging statements in the code and just “turn them off in production” when you don’t need to see them.

ColdBox.cfc
configure() method
logbox Struct literal in there
appenders
- things that we send log messages to
- doesn’t have to be a file. can be the thing that accepts log messages - buglogHQ, whatever
coldboxtracer name is whatever you want it to be, doesn’t have to be that name.
Consoleappender does what you think it does, dumps messages to the console window

must have at least 1 “logger” defined
“root” is the “grandaddy” logger that everybody inherits from
-“info” is the max level thing i care to hear about in the log
means, “it needs to be at LEAST an info level item or higher, otherwise don’t bug me about it, don’t put it in the log”

you could have a few appenders
-1 for log files, 1 for sentry, etc.
can dial them in - only send “fatal” messages to Sentry, send everything else to a log file, etc.
most people have basic setups, only 2 or 3 appenders and everything goes to all of them.

“info = “colxbox.system”
- can blanket some limitations on what gets logged
“every message that starts with “coldbox.system” is also capped off at an “info” level
2 different places where we’re saying “ignore these things”

logging something of your own, not a ColdBox thing —
most ColdBox CFCs — handners, views, etc.
all have a variable “log” baked in
so you can say:
log.info( “Hello in the log” );
- creates a message with the “info” severity level
can also do
log.debug(), etc
for the different levels of severity you want to add to the log

propery name=“log” inject=“logbox:logger(this)”;
…to inject the logbox into anything that doesn’t automatically have it available
(your Model or DAO files, for example)

for NON ColdBox apps
application.logbox.getLogger(‘name of log’).method names()