Hello everyone, thx for all your interesting answers! I think the fact that when the logger's down, the requests have to be dropped (not queued, maybe I was not clear enough about that in my first message) restrains our possibilities. Making a service between P and the logger is an interesting way to go. For the moment we have made something quite simple with atomic and some goroutines cooperating to know if the connection is still correct, or to try reconnect when it's not, but I think we will come back on that later.
Le mer. 13 févr. 2019 à 14:54, Dany Xu <xuletter0927loli...@gmail.com> a écrit : > 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. > -- 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.
