As discuss above, i think the answer is decoupling the P and logger, storing the logs when the logger is down.The push and pull pattern would be better.The p sends all logs and the logger pulls all logs.Just keep a bigger storage for un-consumed logs.Queue may be is a better way but using a single storage.
在 2019年2月12日星期二 UTC+8上午12:34:46，Michel Levieux写道： > > Hi guys. I need a little help here. > > I work in a digital marketing company, where we have a program that > receives a lot of requests every second (counted in thousands) and logs its > behaviour via a logger that runs on another server. We are currently trying > to implement a connection-retry system between this program and its logging > API. What we want is : > > - We have a main program - let's call it P > - P sends logs to the logger in multiple goroutines. > - Sometimes we might need to shut down the logger (for maintenance or > anything) > - We want P to keep running when the logger's down > - Once the logger's up again, P must Dial it back automatically and repair > the *bufio.Writer associated with it > > Would you guys know a way not to check each single Read/Write if the > logger's up? > > Up to here we have thought of using atomic, mutexes and context for > synchronization, but the issues we face are the following: > > - mutexes create "pending" requests, since there's no way to check if a > mutex is locked or not > - we're not really sure about the right way to use context for this > specific case > - we'd like to avoid using atomics as much as possible, notably about this > quote from the docs : "*Except for special, low-level applications, > synchronization is better done with channels or the facilities of the sync > package*" > > In the end, what we're looking for is to reach a minimal checking > frequency (is connection up? do something, else do nothing), the ideal > being not to have to check anything. > > Have you guys already faced such problematics in the past? What solutions > have you come up with? > > Many thx in advance for your help! > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
