![]() This clever trick provided by Marijan Šuflaj from gives you exactly that – a debugger for your Lua scripts with Redis. Use a Lua DebuggerĪdding tracing to your code can only get you so far when you’re trying to grok a piece of code, because sometimes you really need/want a full-fledged debugger at your disposal. Pros: Little overhead, real-time display of messages.Ĭons: Pub/Sub’s delivery isn’t guaranteed, so there’s a chance you could miss a revealing log message (but that’s really a long shot). While the script is running, you should get the following output in your subscriber terminal: Here’s how to do it:īefore running this script, open another terminal window and subscribe to your log channel. Pub/Sub has many wonderful uses, but did you know it can also be used for debugging? By having your script publish log messages to a channel and subscribing to that channel, you can keep track of what’s going on. You also need to pass the List’s key name to ensure cluster-compatibility and most importantly, since you’ll be performing a write operation to Redis this can’t be used with non-deterministic commands. Pros: Like Lua tables, this is straightforward and just works.Ĭons: Similar to the tables approach plus there’s an arbitrary size limit (2^32) on the List’s length. Running this script followed by an LRANGE to obtain the “log” results in the following: Note that the script’s 2nd line deletes the log’s key for housekeeping. Here’s a snippet that shows this approach: ![]() If you require your Lua code to return a meaningful reply once it finishes execution and still retain a logging mechanism, you can use Redis’ List data structure for storing and retrieving your messages. This approach consumes memory to store the intermediate log table, and you need to wait for the script to finish before you can get the log messages. Pros: Works everywhere, and requires very little setup.Ĭons: Returning the log table as your code’s reply prevents it from returning anything meaningful. Running the example above yields the following: You can easily use them to store messages in a log-like manner and return the resulting array once your code finishes running. Lua’s tables are associative arrays and are the only “container” data structures of the language. Don’t despair, however, because there’s more than one way to skin a cat (meeeeeow!?!). when you don’t have access to the Redis host or when the log is too noisy to work with comfortably). by tailing the log file).Ĭons: There are cases in which this approach isn’t a viable option (e.g. In addition, you can view the logged message in near real-time (i.e. ![]() Pros: Using the log file is often the easiest way to trace your workflow. For more information, see EVAL‘s documentation. The redis.log function accepts two arguments: the first one is the message’s log level (choose being between LOG_DEBUG, LOG_VERBOSE, LOG_NOTICE and LOG_WARNING), and the second argument is the to-be-logged value. This function, conveniently named redis.log, is dead simple to use – just call it from your script like so: Redis’ embedded Lua engine provides a function that prints to its log file (configured with the loglevel and logfile directives in your nf). To make this somewhat easier (and perhaps save your wall from a few bangs), here are five ways you can gain Superman-like X-Ray vision into your Lua script. ![]() ![]() That’s because your code runs within the server itself, making it much harder to gain visibility into the code’s innards. When developing Lua scripts for Redis (a feature that’s available from version 2.6 onwards) this can become even trickier. It requires patience, effort and in many cases a touch of inspiration to correctly identify the root cause of a failure. Tracking down these issues isn’t an easy task. Even if you are a good programmer who writes good code (or a great programmer who steals it), use proven methodologies and design patterns, employ only best-of-breed tools, and submit to peers’ code reviews… despite your best efforts, you’re likely to find yourself time and time again banging your head against the wall because of an elusive gremlin. Software defects are a fact of life because software is made by fleshware, and humans err. “In this world nothing is certain, except death, taxes … and BUGS.” If you’ve ever written even a single line of code, you know that Benjamin Franklin’s famous quote should be amended to: Update 1: I’ve followed up on the topic with a vastly superior debugging method so check out part 2 – redis-lua-debugger and its accompanying post <- mini-update: rld is no longer maintained as it isn’t compatible with v3+. Mother of all Updates: Redis v3.2 features its very own Lua debugger. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |