Fabian Groffen

worth a shot

``` atf-c/tp_test.c: In function ‘atfu_getopt_body’: atf-c/tp_test.c:59:18: error: implicit declaration of function ‘getopt’; did you mean ‘gettxt’? [-Werror=implicit-function-declaration] while ((ch = getopt(argc, argv, ":Z")) != -1) { ^~~~~~ gettxt atf-c/tp_test.c:67:17: error:...

I'd like to point out that unlike carbon_ch, fnv1a_ch *does* include port in its hash-key. Since you use that hash, I think there should be no such thing as "duplicate"...

Could you perhaps describe your setup from the initial relay down to the carbon-cache processes? Getting a good idea about the flow of your metrics is key to get this...

Just summing up what has been said above to ensure we're all on the same page: 1. you use a jump hash to distribute metrics over your cluster 2. you...

You want to avoid having multiple tiers of (c-)relays, is that correct? While I understand the rationale, it currently isn't possible and I don't see it high priority to implement...

I would concur with azhiltsov's suggestion. carbon-cache.py isn't multi-threaded, hence running multiple in parallel. A c-relay in front of it is just a workaround, in reality it should've been multi-threaded...

sender -> c-relay -> go-carbon wrt CARBONLINK_HOSTS, I think that doesn't work at all anyway because fnv1a_jump_ch is not understood by graphite-web. This is the reason why we started carbonzipper....

No, only if you use a single cluster with `carbon_ch`, `CARBONLINK_HOSTS` will be able to predict where metrics are located. It understands replication IIRC, but it always probes in order,...

without this change: ``` libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../src/aapl -Iinclude -Wall -g -MT bytecode.lo -MD -MP -MF .deps/bytecode.Tpo -c bytecode.c -fPIC -DPIC -o .libs/bytecode.o bytecode.c: In function ‘colm_execute_code’: bytecode.c:3893:30:...