In our responders we have a feature that allows to avoid dispatching multiple identical requests at the same time. This is done by queing additional identical requests in a special hash table and then replying to all clients at the same time when a response is received.
When the connection to a provider breaks all these waiting requests need to be cleaned out and the has table emptied.
This was not happening in sssd_pam, so if a connection to the provider was lost client request would pile up and never be replied again.
The attached patch fixes this issue. Tested using kill -STOP of the sssd_be process and trying to authenticate via the gnome screensaver.
Fixes: https://fedorahosted.org/sssd/ticket/1655
On Thu, Dec 13, 2012 at 11:25:25PM -0500, Simo Sorce wrote:
In our responders we have a feature that allows to avoid dispatching multiple identical requests at the same time. This is done by queing additional identical requests in a special hash table and then replying to all clients at the same time when a response is received.
When the connection to a provider breaks all these waiting requests need to be cleaned out and the has table emptied.
This was not happening in sssd_pam, so if a connection to the provider was lost client request would pile up and never be replied again.
The attached patch fixes this issue. Tested using kill -STOP of the sssd_be process and trying to authenticate via the gnome screensaver.
Fixes: https://fedorahosted.org/sssd/ticket/1655
-- Simo Sorce * Red Hat, Inc * New York
Ack. Nice catch, thank you. The other *_dp_reconnect_init functions are fine.
On Fri, 2012-12-14 at 10:43 +0100, Jakub Hrozek wrote:
On Thu, Dec 13, 2012 at 11:25:25PM -0500, Simo Sorce wrote:
In our responders we have a feature that allows to avoid dispatching multiple identical requests at the same time. This is done by queing additional identical requests in a special hash table and then replying to all clients at the same time when a response is received.
When the connection to a provider breaks all these waiting requests need to be cleaned out and the has table emptied.
This was not happening in sssd_pam, so if a connection to the provider was lost client request would pile up and never be replied again.
The attached patch fixes this issue. Tested using kill -STOP of the sssd_be process and trying to authenticate via the gnome screensaver.
Fixes: https://fedorahosted.org/sssd/ticket/1655
-- Simo Sorce * Red Hat, Inc * New York
Ack. Nice catch, thank you. The other *_dp_reconnect_init functions are fine.
Yes, I checked, but this is the third time we regress wrt this functionality, I am thinking I may add a new patch that marks requests with a timestamp and automatically expire those older than X.
It doesn't make sense to pile requests when they are very far one from the other, there is clearly an error if sssd_be hasn't answered in say 5 minutes, and it is better to cancel the old one at that point and repeat.
Do you agree ?
Stephen you coded this feature originally IIRC, any objection ?
Anyway this would be a new ticket, I think we need to push this patch as is w/o waiting as it is a very bad bug.
Simo.
On Fri, Dec 14, 2012 at 08:44:32AM -0500, Simo Sorce wrote:
On Fri, 2012-12-14 at 10:43 +0100, Jakub Hrozek wrote:
On Thu, Dec 13, 2012 at 11:25:25PM -0500, Simo Sorce wrote:
In our responders we have a feature that allows to avoid dispatching multiple identical requests at the same time. This is done by queing additional identical requests in a special hash table and then replying to all clients at the same time when a response is received.
When the connection to a provider breaks all these waiting requests need to be cleaned out and the has table emptied.
This was not happening in sssd_pam, so if a connection to the provider was lost client request would pile up and never be replied again.
The attached patch fixes this issue. Tested using kill -STOP of the sssd_be process and trying to authenticate via the gnome screensaver.
Fixes: https://fedorahosted.org/sssd/ticket/1655
-- Simo Sorce * Red Hat, Inc * New York
Ack. Nice catch, thank you. The other *_dp_reconnect_init functions are fine.
Yes, I checked, but this is the third time we regress wrt this functionality, I am thinking I may add a new patch that marks requests with a timestamp and automatically expire those older than X.
It doesn't make sense to pile requests when they are very far one from the other, there is clearly an error if sssd_be hasn't answered in say 5 minutes, and it is better to cancel the old one at that point and repeat.
Do you agree ?
Stephen you coded this feature originally IIRC, any objection ?
Anyway this would be a new ticket, I think we need to push this patch as is w/o waiting as it is a very bad bug.
Simo.
In general I agree, the client would be terminated with the idle timeout anyway I think.
On Fri, Dec 14, 2012 at 10:43:42AM +0100, Jakub Hrozek wrote:
On Thu, Dec 13, 2012 at 11:25:25PM -0500, Simo Sorce wrote:
In our responders we have a feature that allows to avoid dispatching multiple identical requests at the same time. This is done by queing additional identical requests in a special hash table and then replying to all clients at the same time when a response is received.
When the connection to a provider breaks all these waiting requests need to be cleaned out and the has table emptied.
This was not happening in sssd_pam, so if a connection to the provider was lost client request would pile up and never be replied again.
The attached patch fixes this issue. Tested using kill -STOP of the sssd_be process and trying to authenticate via the gnome screensaver.
Fixes: https://fedorahosted.org/sssd/ticket/1655
-- Simo Sorce * Red Hat, Inc * New York
Ack. Nice catch, thank you. The other *_dp_reconnect_init functions are fine.
Pushed to master and sssd-1-9
On Fri, Dec 14, 2012 at 05:29:17PM +0100, Jakub Hrozek wrote:
On Fri, Dec 14, 2012 at 10:43:42AM +0100, Jakub Hrozek wrote:
On Thu, Dec 13, 2012 at 11:25:25PM -0500, Simo Sorce wrote:
In our responders we have a feature that allows to avoid dispatching multiple identical requests at the same time. This is done by queing additional identical requests in a special hash table and then replying to all clients at the same time when a response is received.
When the connection to a provider breaks all these waiting requests need to be cleaned out and the has table emptied.
This was not happening in sssd_pam, so if a connection to the provider was lost client request would pile up and never be replied again.
The attached patch fixes this issue. Tested using kill -STOP of the sssd_be process and trying to authenticate via the gnome screensaver.
Fixes: https://fedorahosted.org/sssd/ticket/1655
-- Simo Sorce * Red Hat, Inc * New York
Ack. Nice catch, thank you. The other *_dp_reconnect_init functions are fine.
Pushed to master and sssd-1-9
Also pushed to sssd-1-8
On Fri, Dec 14, 2012 at 05:29:17PM +0100, Jakub Hrozek wrote:
On Fri, Dec 14, 2012 at 10:43:42AM +0100, Jakub Hrozek wrote:
On Thu, Dec 13, 2012 at 11:25:25PM -0500, Simo Sorce wrote:
In our responders we have a feature that allows to avoid dispatching multiple identical requests at the same time. This is done by queing additional identical requests in a special hash table and then replying to all clients at the same time when a response is received.
When the connection to a provider breaks all these waiting requests need to be cleaned out and the has table emptied.
This was not happening in sssd_pam, so if a connection to the provider was lost client request would pile up and never be replied again.
The attached patch fixes this issue. Tested using kill -STOP of the sssd_be process and trying to authenticate via the gnome screensaver.
Fixes: https://fedorahosted.org/sssd/ticket/1655
-- Simo Sorce * Red Hat, Inc * New York
Ack. Nice catch, thank you. The other *_dp_reconnect_init functions are fine.
Pushed to master and sssd-1-9
Also pushed to sssd-1-8
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Simo Sorce