Bug in seting timeout in aerospike_key_operate about aerospike-client-c

[BrianNichols]

Are you using enterprise server with user/password authentication enabled?

If so, the authentication portion is indeed using the connection timeout (default 1 second) and not the transaction timeout. The temporary workaround is to set the connection timeout at startup:

as_config cfg;
as_config_init(&cfg);
cfg.conn_timeout_ms = 900000;
aerospike_init(client, &cfg);
aerospike_connect(client, &err);

[tnozicka]

We are using community edition for now.
Just for my test case I have also set the following, but nothing seems to affect the real timeout.

as_config config;
as_config_init(&config);
as_config_add_host(&config, "<my_host_1>", 3000);
as_config_add_host(&config, "<my_host_2>", 3000);
config.conn_timeout_ms = 3000000;
config.policies.timeout = 200000;
config.policies.operate.retry = AS_POLICY_RETRY_ONCE;
config.policies.operate.timeout = 600000;
config.policies.info.timeout = 400000;
config.policies.read.timeout = 700000;
config.policies.remove.timeout = 800000;

It still fails with connection timeout after 1 sec.

[BrianNichols]

You have identified a bug, but it's not the one you think. AS_POLICY_RETRY_ONCE was specified, but the client retried twice after the initial failure. This will be fixed in the next release.

Timeouts can occur for the following reasons:

1. Client can't connect by specified timeout.
2. Client does not receive response by specified timeout.
3. Server times out the transaction during it's own processing.
4. Client can't obtain a valid node after N retries.
5. Client can't obtain a valid connection after N retries. The retry count is usually the limiting factor, not the timeout value. The reasoning is that if you can't get a connection after N retries, you never will, so just timeout early.

Your application is timing out because of #5. The reason is that Aerospike server probably ran out of sockets. Socket limit is controlled by OS settings (Linux = ulimit -n). Aerospike Server service config also further limits socket count with "proto-fd-max ".

The retry policy is an enum, but it can be overloaded to be an integer. The following would retry up to 100 times.

policy.retry = 100;

We will also make retry an integer in the next release which will still be backwards compatible.

[BrianNichols]

Version 3.1.19 has been released.