There is currently no way to specify a network timeout time while connecting to the LDAP server. This is supported in PHP as LDAP_OPT_NETWORK_TIMEOUT
and it would be good to implement the corresponding option in the LDAP module too.
I'll now attach a minimal patch (based on 7.x-2.0-beta8) just for tracking; this can't of course be used as is.
If there is interest for a full patch, I can create one as follows:
1. Rebase on 2.x-dev
2. Use a configurable value instead of the hardcoded 10 seconds
3. Extend the admin screen with the timeout option
4. Check that we are on PHP 5.3.0 (or document this properly) before using this option
Related to https://www.drupal.org/node/1132260
Comment | File | Size | Author |
---|---|---|---|
#10 | ldap-ldap_servers-support-timeout-2614184-10.patch | 562 bytes | bburg |
#7 | ldap-ldap_servers-support-timeout-2614184-7-D7.patch | 543 bytes | bkosborne |
#2 | ldap-ldap_servers-support-timeout-2614184-2-D7.patch | 497 bytes | pescetti |
Comments
Comment #2
pescetti CreditAttribution: pescetti at Nuvole commentedComment #3
grahlComment #4
grahlThanks for the patch.
Is anybody else interested in this? If so, please +1. Currently I would keep it as-is as an optional patch.
Comment #5
bkosborneYes, very interested in this.
Without this you can take down your whole site if your LDAP server is unresponsive. All your PHP processes will be tied up waiting for the LDAP connection to eventually time out, which by default can be over 2 minutes for each connection.
I suggest making this a variable_get() though, instead of hard-coding 10 seconds (but 10 seems like a reasonable default).
Comment #6
grahlMoving this forward to 8.x to add it there first.
Comment #7
bkosborneHere's another patch for D7 that uses a variable get call and a default of 30 seconds. I actually think the most appropriate way to handle this is to allow specifying a timeout per server, so we'd need a form element and related changes to support that.
Comment #9
grahlIn 8.x it's now a regular field in the base settings of each server. I'm sending this issue back to 7.x-2.x for backporting.
However, I'm setting this issue to minor and postponed because a usable patch with a variable is available here with #7, which I'd recommend 7.x users employ but I don't want to commit it outright due to the different approach in 8.x. If someone really wants to work on fully backporting this I'd consider committing such a patch but only with at least two independent positive feedbacks.
Comment #10
bburgUpdated patch for 7.x-2.5.
Comment #11
grahlWhile the patch itself is perfectly fine, it's not configurable and I don't want to spend the time on 7.x making it configurable and dealing with any regressions in existing setups. (I can't imagine any network links taking over 10s but with some complex queries, maybe they do for some.)
Therefore closing, but I'd generally recommend that patch to all setups.
Comment #12
grahlComment #13
bburgThe issue I was running into was that when the LDAP server was temporarily down, it caused all the php threads on the site to spend forever waiting on the timeout, and made the site inaccessible.
Comment #14
grahlThanks for the feedback bburg, makes perfect sense and if I were running a 7.x site I'd want to use this patch, too. I'm only not adding it to the 7.x release in case some existing sites with super-long directory responses could misbehave.