util

Overview ¶

Package util contains common functionality which is required by a typical server side any GO application. Namely it contains functionality to read JSON configuration file (from ilyakaznacheev) and rotating logging functionality (from lumberjack). Essentially these are few simple useful wrappers convenient for any GO application.

If user passes a configuration file with absolute path, it is read as is. Otherwise environment variable GO_CFG_HOME is checked to see if contains the directory name in which the passed configuration file is checked. If found, it is read and configuration structure is returned.

The built-in conditional variable in Go - sync.Cond - broadcasts or signal the waiting go routine exactly once. If the waiting routine misses that, it waits infinitely and essentially your program hangs. There is a long running argument within the Go Community whether the conditional variable to be abolished altogether or not: https://github.com/golang/go/issues/21165 Many within the Go Community want to abolish it altogether while the few other experienced professionals want to keep it and improve it. The proposers want to go all hog on Go channels. No doubt Channels is the marquee feature of the Go Language. I do not know whether the cost of 'channels' is all justified for the ubiquitous usage of Channel in Go applications. Coming from C and Java Programming background, all I want is working sync.Cond. What I have seen though, if Signal or Broadcast message is missed; my program is toast. Now Go Community may want to claim that they only entertain flawless coders so that a programmer knows exactly when to expect the 'signal'. In my unit tests when tasks finish very early only, I have seen that the cost of acquiring Lock is significant; meaning the waiting Go routine misses the Signal before starting to Wait. Hence the humble attempt - try multiple Broadcast so the listeners get more than one opportunity to get out of Wait loop. I agree, it is a weak solution. But it is helping in my use case where I want 'channels usage strictly managed'.

The usage pattern is at any given time, all waits will be considered for a single condition only. We are trying to solve the problem of at least one 'wait' coming after the Broadcast. So repeat call on the Broadcast are not allowed until the first Broadcast is complete which is determined based on how many receipts we get from waiters.

In cases where we are not concerned about whether all waiters respond back but at least one 'waiter' at least responds back. The use case is we want any one to pick up the resume the work upon completing of the work. It is essentially Broadcast with argument 1, which is simplified as Signal() call.

CondVar bundles required locker with it so as you do not need to do explicit Lock and Unlock invocation around Wait.

There are three methods to initialize logs and set log settings:

1) Caller can pass LoggingCfg structure as defined here to initialize logs.

2) Alternatively, assuming caller has used 'cfg' program in the 'util' package, that 'uber' configuration file can be passed as long as it has a JSON member of name "LogSettings". The configuration file can be passed: - either with the absolute path - or the file name only in which case GP_CFG_HOME environment variable value is used as the directory name where the give configuration file is located.

3) Finally, caller can explicitly call InitializeLog method with arguments. The file path can be absolute. It is not absolute, it is appended to the current working directory.

Until LoggingCfg is set, GlobalLogSettings will be nil. All log calls will be handled by the built in logging facility of Golang. Once the logging is initialized by one of the above mentioned 3 methods; log calls will be directing the output to the specified rotating log file.