NewClientWithPolicyAndHost has bug about aerospike-client-go HOT 11 CLOSED

I have somehow overlooked this issue. Will be fixed in next release.

Thank you for your patience.

from aerospike-client-go.

We ran into the same issue recently. Are there any updates on this?

from aerospike-client-go.

That's how it is supposed to work by design. We haven't been sure if it is prudent to change this behavior.

Why do you think it shouldn't return an error?

from aerospike-client-go.

I was under the impression that this constructor gets a list of hosts it tries to connect to. If any of those hosts work, the client established connection to the cluster and everything is fine.

Consider this: Lets say we have an aerospike cluster with three nodes at host1, host2 and host3. So our setup would look similar to the one above. All nodes are up and running and we can start our Go backend to connect to it.

Now node1 goes down. Kernel panic or whatever. The aerospike cluster can deal with it, that's what we have replication for. But if I want to restart by Go backend now, I will get an error, even though it could connect to the cluster by connecting to one of the remaining and working hosts.

Since the cluster itself is fine I believe it is an error to fail connecting to it just because a node is down or somehow unreachable. Isn't that exactly what the list of multiple hosts is designed for?

from aerospike-client-go.

I can't quite reproduce this bug. How are you hitting this? All mixes of non-existing host and non-existing running db connect successfully. Stopping and restarting a node also works fine.

Can you provide a small snippet (or a precise description of the situation in which it occurs?)

This is the code I'm using:

    l.Logger.SetLevel(l.DEBUG)

    host1 := &Host{
        Name: "ubvm1", // a non-existing host
        Port: 3000,
    }

    host2 := &Host{
        Name: "ubvm", // a existing host, but without aerospike server on the specified port
        Port: 3040,
    }

    host3 := &Host{
        Name: "ubvm", // a aerospike server host
        Port: 3000,
    }

    // cli, err := NewClientWithPolicyAndHost(nil, host2, host3) // No error returned
    // cli, err := NewClientWithPolicyAndHost(nil, host1, host3) // Also no errors
    cli, err := NewClientWithPolicyAndHost(nil, host1, host2, host3) // also no errors!
    if err != nil {
        panic(err) // this never happens
    }
    defer cli.Close()
    log.Println("Successful...")

from aerospike-client-go.

@khaf: With an aerospike server running locally (with vagrant) I run this code:

package main

import (
    "fmt"

    as "github.com/aerospike/aerospike-client-go"
)

func main() {
    var err error

    valid := &as.Host{
        Name: "127.0.0.1",
        Port: 3000,
    }

    noexist := &as.Host{
        Name: "noexist",
        Port: 3000,
    }

    _, err = as.NewClientWithPolicyAndHost(nil, valid)
    fmt.Printf("NewClient(valid)          err: %q \t(should be nil)\n", err)

    _, err = as.NewClientWithPolicyAndHost(nil, noexist)
    fmt.Printf("NewClient(noexist)        err: %q \t(should not be nil)\n", err)

    _, err = as.NewClientWithPolicyAndHost(nil, valid, noexist)
    fmt.Printf("NewClient(valid, noexist) err: %q \t(should be nil)\n", err)

    _, err = as.NewClientWithPolicyAndHost(nil, noexist, valid)
    fmt.Printf("NewClient(noexist, valid) err: %q \t(should be nil)\n", err)
}

And get this output:

NewClient(valid)          err: %!q(<nil>)       (should be nil)
NewClient(noexist)        err: "Failed to connect to host(s): []"       (should not be nil)
NewClient(valid, noexist) err: "Failed to connect to host(s): [ ]"      (should be nil)
NewClient(noexist, valid) err: "Failed to connect to host(s): [ ]"      (should be nil)

So in the last two cases as.NewClientWithPolicyAndHost returns an error even though one of the provided hosts is valid.

I'm using v1.10.0 (commit 3b2628a) of aerospike-client-go.

from aerospike-client-go.

Interesting. Your snippet works as expected on my system. Is there a way you could share your vagrant setup?

I'm running my code on go1.5.3 darwin/amd64, on MacOS X v10.11.3. My databases are on VMWare Fusion Ubuntu 14.04 LTS installations.

from aerospike-client-go.

It seems to be a timeout issue. I found that Cluster.waitTillStabilized ran into the one second timeout of the default ClientPolicy. I tried using a client policy with two seconds timeout and now it works as expected.

It would have been helpful to see in the error message that it ran into a timeout.

from aerospike-client-go.

Thanks for the help. I will increase the ClientPolicy.Timeout and will return an error from waitTillStabilized method to help pinpoint the problem in the future.

from aerospike-client-go.

Fixed in v1.11

from aerospike-client-go.

Thanks!

from aerospike-client-go.