It has absolutely nothing to do with mutexes/contexts/atomics or even Go (even if you program in Go). This is engineering or architecture task not the language thing, so you need to think like an architect.
A lot of solutions possible if you add some sort of integration layer between P and Logger, for instance, in-memory DB. Another thing which you should probably think of, is heart-beats, f.e. Logger may notify P that he is available. понедельник, 11 февраля 2019 г., 19:34:46 UTC+3 пользователь 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.
