The problem is when we are about to reset the server status, we don't
get through the timeout (30 seconds) because the "switch to primary
server" task is scheduled 30 seconds after fall back to a backup
server. Thus the server status is resetted after another 30 seconds.
It can be nicely seen in the logs:
[be_primary_server_timeout] (0x0400): Looking for primary server!
[fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
[get_server_status] (0x1000): Status of server 'backup.pb' is 'working'
[get_port_status] (0x1000): Port status of port 389 for server
'backup.pb' is 'working'
[get_server_status] (0x1000): Status of server 'ipa-server.ipa.pb' is
'working'
[get_port_status] (0x1000): Port status of port 389 for server
'ipa-server.ipa.pb' is 'not working'
[get_port_status] (0x0010): ===== DIFF = 30 > 30
[get_server_status] (0x1000): Status of server 'backup.pb' is 'working'
[get_port_status] (0x1000): Port status of port 389 for server
'backup.pb' is 'working'
[fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to
10 seconds
[get_server_status] (0x1000): Status of server 'backup.pb' is 'working'
[be_resolve_server_process] (0x1000): Saving the first resolved server
[be_resolve_server_process] (0x0200): Found address for server
backup.pb: [10.16.78.43] TTL 60
[be_primary_server_timeout_activate] (0x2000): Primary server
reactivation timeout set to 30 seconds
The question is how we should deal with it? The easiest solution (in
the attached patch) is just switching > with >=. But I'm not quite sure
whether it is the best solution. It doesn't really fit into my
understanding of timeout.
My other thoughts were:
1. schedule "switch to primary server" task to 31 seconds
2. reset server status of all primary servers when this task is
triggered
From 8e83e8a9905e91f28fdc52b61bde9eb8e84229dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pavel=20B=C5=99ezina?= <[email protected]>
Date: Sun, 16 Dec 2012 21:46:11 +0100
Subject: [PATCH] reset server status is now - last_change >= timeout
https://fedorahosted.org/sssd/ticket/1679
The problem is when we are about to reset the server status, we don't
get through the timeout (30 seconds) because the "switch to primary
server" task is scheduled 30 seconds after fall back to a backup
server. Thus the server status is resetted after another 30 seconds.
---
src/providers/fail_over.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/providers/fail_over.c b/src/providers/fail_over.c
index f3bba37f7cf1edccb779041bedc12dd48965f3f0..cf67232f9314e5c0fcb7a7ba83f1301b5f0eef56 100644
--- a/src/providers/fail_over.c
+++ b/src/providers/fail_over.c
@@ -325,7 +325,7 @@ get_server_status(struct fo_server *server)
timeout = server->service->ctx->opts->retry_timeout;
gettimeofday(&tv, NULL);
if (timeout != 0 && server->common->server_status == SERVER_NOT_WORKING) {
- if (STATUS_DIFF(server->common, tv) > timeout) {
+ if (STATUS_DIFF(server->common, tv) >= timeout) {
DEBUG(4, ("Reseting the server status of '%s'\n",
SERVER_NAME(server)));
server->common->server_status = SERVER_NAME_NOT_RESOLVED;
@@ -359,7 +359,7 @@ get_port_status(struct fo_server *server)
timeout = server->service->ctx->opts->retry_timeout;
if (timeout != 0 && server->port_status == PORT_NOT_WORKING) {
gettimeofday(&tv, NULL);
- if (STATUS_DIFF(server, tv) > timeout) {
+ if (STATUS_DIFF(server, tv) >= timeout) {
DEBUG(4, ("Reseting the status of port %d for server '%s'\n",
server->port, SERVER_NAME(server)));
server->port_status = PORT_NEUTRAL;
--
1.7.11.7
_______________________________________________
sssd-devel mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
