Reconnect

[ProTip]

Hello,

What do you think about handling reconnects? Currently there is nothing exposing whether or not the client is still connected nor is there a "Connect" method to attempt a reconnection.

I'm also curious about having the client handle broken connections itself.. I had to do the same stuff with the graphite client (wrap a bunch of broken connection handling code around it).

[blalor]

It's not particularly elegant, but here's what I use:

package main

import (
    log "github.com/Sirupsen/logrus"

    "time"
    "fmt"

    "github.com/amir/raidman"
)

type ReconnectingRiemannClient struct {
    Proto   string
    Host    string
    Port    int
    Timeout time.Duration

    client  *raidman.Client
}

func (self *ReconnectingRiemannClient) SendMulti(evts []*raidman.Event) (err error) {
    if self.client == nil {
        riemannAddr := fmt.Sprintf("%s:%d", self.Host, self.Port)

        log.Infof("connecting to Riemann at %s via %s", riemannAddr, self.Proto)
        self.client, err = raidman.DialWithTimeout(self.Proto, riemannAddr, self.Timeout)

        if err != nil {
            log.Errorf("error connecting to Riemann: %v", err)
            return
        }
    }

    if self.client != nil {
        err = self.client.SendMulti(evts)

        if err != nil {
            self.client.Close()
            self.client = nil
        }
    }

    return
}

[amir]

Sorry for the long silence. I've read quite a few go projects to see how they handle reconnects since the issue has been created. I'm yet to see one uniform, idiomatic solution to the problem. @blalor's solution is indeed a good one from a library user point of view and we might be able to avail users of this feature via a configuration parameter, perhaps? What do you think?

[blalor]

I'm wondering if it might be better to keep this as a separate implementation that uses a common interface to describe the methods. This is working well for me, but I'm a little uncomfortable having the library wrap itself; seems like it could make maintenance more complex. But as a separate type, its behavior and relationship are more understandable, in my opinion.

[dhruvbansal]

+1 for bundling some kind of reconnect functionality into the client. Can't speak to @blalor particular implemenation...IANAGP (IANA Go Programmer...).

Metrics are what we rely on when things break so it's nice when our collection tools are robust against intermittent network errors or (say) a restart of the Riemann server (which is how I discovered this bug & issue...).