Migrate etcd features from Spring Cloud

[artembilan]

Wow! One more extension for Spring Integration :smile: Cool. Let me provide some feedback and merge.

And let me know if you need some milestone afterward on the matter. (BTW, the same question is about Hazelcast)

[artembilan]

OK. Here you are polishing: https://github.com/artembilan/spring-integration-extensions/commit/f3707a11f17ec2509f745ad8789133a9ce74a345.

I can't merge it yet because I can't test it. It doesn't start on Windows yet because of an exclusive lock on file. It must be closed before renaming :smile: : https://github.com/coreos/etcd/issues/5852

And I don't understand why etc4j says default port as 4001:

Setting up a client which connects to default 127.0.0.1:4001 URL

Where official is like:

The official etcd ports are 2379 for client requests, and 2380 for peer communication.

Yes, I can test on Mac, tomorrow, but before that let me know if I am not missing something.

Thanks

[dsyer]

I guess maybe the Docker image we are using is not setting up the "standard" ports. We could maybe find another one. This one uses 4001 as well: https://hub.docker.com/r/dockerbase/etcd/.

Re windows: did you try upgrading etcd? You can probably use docker-compose now on Windows. Maybe that would work better?

[dsyer]

The "official" coreos images are in quay.io. I found that when I migrated to those the tests fail (https://github.com/dsyer/spring-integration-extensions/tree/update/etcd). We should ping the author @venilnoronha and ask him to fix it if he is using this code. It's going to be deprecated from Spring Cloud so this is his best chance if he wants it.

[artembilan]

Well, of course my idea do test it anyway as more as possible. I'm not familiar with Docker and yes we can leave that compose.yml here, but I'm not convinced that we need such a beast for so simple key-value store. For example it would be the best to have it at least on Bamboo for our CI process. I guess we can ask Trevor to install one for us there, but I still not sure that it must be Docker...

I tried the normal etcd install on Windows for the latest version: https://github.com/coreos/etcd/releases/tag/v3.0.1. That issue has been fixed recently in master, so no release yet :smile:

Another my concern that there is no good etcd embedded yet. I tried https://github.com/opentable/otj-etcd-embedded, but looks like project is out of support already and yeah, it doesn't work anyway. It says that has started etcd process, but the port is out of response with the SYN_SENT state via netstat.

We have 4001 default port there because of etcd4j:

public EtcdClient(EtcdSecurityContext securityContext, URI... baseUri) {
    this(new EtcdNettyClient(
      securityContext,
      (baseUri.length == 0)
        ? new URI[] { URI.create("https://127.0.0.1:4001") }
        : baseUri
    ));
}

Some inconsistency with official etcd.

We should probably consider some @Rule to let test pass when we don't have etcd ran. But yeah... Maybe it really would be better to see what @venilnoronha will say. And we stop to sped time with the future since it isn't stable for at least critical ensemble of functions.

[dsyer]

It looks to me like 4001 was the official port for v2 of etcd, and they switched to 2379 in v3. This at least is consistent with the fact that etcd4j only advertise compatibility with 2.x.

[artembilan]

Yeah... I see now: https://github.com/jurmous/etcd4j#etcd-version-support

What is sad I don't see any other up-to-date Java client for ETCD :cry:

We can probably write our own Java Client over their REST API:

curl http://127.0.0.1:2379/v2/keys/message -XPUT -d value="Hello world"

but doesn't it worse that effort ? :smile:

[artembilan]

Superseded with the #198