During the development of Sidecar, an external session management plugin for ColdFusion, we selected Redis as our storage backend to support sessions in a cluster. Without relying on sticky sessions, we quickly realized that we needed a way to ensure that we wouldn’t step on our own toes as multiple servers potentially tried to access and modify session data concurrently.
After some research we decided on redlock for a distributed lock. This project is a port of node-redlock to CFML. It is useful outside of session management for any scenario where multiple servers need to run a process with transaction semantics so we have released it as its own library. About the time we finished development, Ben Nadel released his version of redlock. They’re similar but have a different API so check it out as well.
The goal is to support Adobe ColdFusion 10+ and Lucee 4.5+ with this library - like sidecar we are using these libraries in production, so we hope you find them useful and if welcome any contributions, including code, documentation or just reporting issues.comments
Want to build your own URL shortener? Have a bunch of sequential ID’s but don’t want it to be obvious what the next or previous in the sequence is? Base62 might be a good fit. Instead of 10 possible characters per digit you have 62, compressing the size of your identifier. Plus with a custom alphabet order, the next number in the sequence isn’t easily apparent. I have open sourced a CFML library that allows you to convert between base 10 and 62 here: https://github.com/ryanguill/cfmlBase62 - it supports custom alphabets (will also help generate one for you) and supports integers between 0 and 263-1 (9,223,372,036,854,775,807) so it can probably handle all of the nine quintillion identifiers in your database.comments
Every CFML engine I can find - Adobe ColdFusion 10, 11 and 2016, Lucee 4.5 and 5 - has a bug where if you try to usecomments
randRange()on 231-1 (
MAX_INT) it will overflow and give you a negative number. See for yourself: http://trycf.com/gist/726e96e5c5e9498b32a2/acf2016. Here is a better way that supports not only
You rarely want to set a request timeout to a particular value - meaning that you want it to time out if it takes a certain amount of time. What you do want is to declare that a particular process might take at least some amount of time to complete. This is what
<cfsetting>’s requestTimeout parameter should be - saying that it is ok if it takes at least this long. A recent example of where I needed this is with running some longer running processes as part of a suite of unit tests. The individual method we are testing might take 60 seconds to run for example - but the entire request might take several minutes - when that method is run as part of a normal request lifecycle then the 60 second request timeout is fine, but when running the unit tests it ends my tests early!
So here is a method that you can use instead - that will update the request timeout to be the greater of the existing timeout or the new timeout. So it will only ever extend, never shorten.
Credit to Brian Ghidinelli.comments
With a dynamic application with lots of shared templates it can sometimes be easy to use the same ID for two different elements on the same page. Sometimes this can manifest itself by your JS not working quite right but it isn’t apparent what the problem is. Here is a quick script you can paste into your console to report any duplicates.
Math Busche covered the same topic last year, head over there to see how he tackled the same thing.comments