Re: Time for 2.0.53?
On Mon, 31 Jan 2005 13:18:38 -0800, Justin Erenkrantz [EMAIL PROTECTED] wrote: Any opposition to doing a tag and roll of 2.0.53 soon? (Yes, I volunteer to be RM.) How about targetting next Tuesday (2/8) for 2.0.53? I can lay down the candidate tarball on Friday morning, so whatever backports are merged by then make it. =) Do we want closure on Jeff's proxy chunking patch for 2.0.53? -- justin Heck, I don't know how we get from here to closure on the 2.1-dev equivalent ;) What do we do with the proxy-reqbody branch? Merge to trunk?
Re: Time for 2.0.53?
Brad Nicholes wrote: [EMAIL PROTECTED] Monday, January 31, 2005 2:26:09 PM I'd love to see the LDAP socket timeout configuration stuff make it in for 2.0.53! -- Jess Holle justin Me too ;) Any voters out there? I've already cast my vote (Obviously) From the looks of the STATUS file, there appears to be a number of backports with 3 +1's that just need to be backported. Brad I don't have a vote, but I believe the socket timeout configuration is necessary to address issues seen with firewall timeouts and the LDAP connections held open by Apache. -- Jess Holle
Re: Time for 2.0.53?
Jess Holle said: I don't have a vote, but I believe the socket timeout configuration is necessary to address issues seen with firewall timeouts and the LDAP connections held open by Apache. Is there an outstanding patch for this yet? The right way to solve this problem is to allocate the LDAP connection pool using apr_reslist_*, which handles things like connection timeouts for us. If this code exists already, then I'm keen to get it in ASAP, and if the code doesn't exist I should have time to fix it after tomorrow. Regards, Graham --
Re: Time for 2.0.53?
Graham Leggett wrote: Jess Holle said: I don't have a vote, but I believe the socket timeout configuration is necessary to address issues seen with firewall timeouts and the LDAP connections held open by Apache. Is there an outstanding patch for this yet? The right way to solve this problem is to allocate the LDAP connection pool using apr_reslist_*, which handles things like connection timeouts for us. If this code exists already, then I'm keen to get it in ASAP, and if the code doesn't exist I should have time to fix it after tomorrow. +1 for delaying 2.0.53 for the above. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: Time for 2.0.53?
I have already added a new directive to util_ldap called LDAPConnectionTimeout ( http://httpd.apache.org/docs-2.1/mod/mod_ldap.html#ldapconnectiontimeout ) which allows util_ldap to set the network timeout through rc = apr_ldap_set_option(p, NULL, LDAP_OPT_NETWORK_TIMEOUT, (void *)timeOut, (result_err)); The default is 10 seconds, but this directive will allow the administrator to set it to whatever they want. See the STATUS file backport entry (svn rev 126565). This should be a much cleaner way to handle connection timeouts although I think that the whole connection pool itself should be converted to using apr_reslist_*. I have also considered adding a similar directive to set the search timelimit (LDAP_OPT_TIMELIMIT), but I haven't decided if just setting a global time limit is a good thing or not. It seems like this should be more of a per-request type of setting and also really depends on the size of the LDAP context that is being searched. thoughts? Brad [EMAIL PROTECTED] Tuesday, February 01, 2005 8:55:24 AM Jess Holle said: I don't have a vote, but I believe the socket timeout configuration is necessary to address issues seen with firewall timeouts and the LDAP connections held open by Apache. Is there an outstanding patch for this yet? The right way to solve this problem is to allocate the LDAP connection pool using apr_reslist_*, which handles things like connection timeouts for us. If this code exists already, then I'm keen to get it in ASAP, and if the code doesn't exist I should have time to fix it after tomorrow. Regards, Graham --
Re: Time for 2.0.53?
I hate to say it but any solution would be appreciated. This is the one brick wall customers are running into when trying to use Apache (with mod_auth_ldap and mod_jk being the heaviest dependencies beyond core functionality). -- Jess Holle Brad Nicholes wrote: I have already added a new directive to util_ldap called LDAPConnectionTimeout ( http://httpd.apache.org/docs-2.1/mod/mod_ldap.html#ldapconnectiontimeout ) which allows util_ldap to set the network timeout through rc = apr_ldap_set_option(p, NULL, LDAP_OPT_NETWORK_TIMEOUT, (void *)timeOut, (result_err)); The default is 10 seconds, but this directive will allow the administrator to set it to whatever they want. See the STATUS file backport entry (svn rev 126565). This should be a much cleaner way to handle connection timeouts although I think that the whole connection pool itself should be converted to using apr_reslist_*. I have also considered adding a similar directive to set the search timelimit (LDAP_OPT_TIMELIMIT), but I haven't decided if just setting a global time limit is a good thing or not. It seems like this should be more of a per-request type of setting and also really depends on the size of the LDAP context that is being searched. thoughts? Brad [EMAIL PROTECTED] Tuesday, February 01, 2005 8:55:24 AM Jess Holle said: I don't have a vote, but I believe the socket timeout configuration is necessary to address issues seen with firewall timeouts and the LDAP connections held open by Apache. Is there an outstanding patch for this yet? The right way to solve this problem is to allocate the LDAP connection pool using apr_reslist_*, which handles things like connection timeouts for us. If this code exists already, then I'm keen to get it in ASAP, and if the code doesn't exist I should have time to fix it after tomorrow. Regards, Graham --
Re: Time for 2.0.53?
Brad Nicholes wrote: I have already added a new directive to util_ldap called LDAPConnectionTimeout ( http://httpd.apache.org/docs-2.1/mod/mod_ldap.html#ldapconnectiontimeout ) which allows util_ldap to set the network timeout through rc = apr_ldap_set_option(p, NULL, LDAP_OPT_NETWORK_TIMEOUT, (void *)timeOut, (result_err)); IMO this does not exists on WIN32 (at least PSDK does not declare that), thus mod_ldap breaks on build. The code should be enclosed inside: #if defined(LDAP_OPT_NETWORK_TIMEOUT) #endif Regards, Mladen
Re: Time for 2.0.53?
Ouch! Does the MS LDAP SDK define anything equivalent? Fixing this on some platforms is better than on none, though. -- Jess Holle Mladen Turk wrote: Brad Nicholes wrote: I have already added a new directive to util_ldap called LDAPConnectionTimeout ( http://httpd.apache.org/docs-2.1/mod/mod_ldap.html#ldapconnectiontimeout ) which allows util_ldap to set the network timeout through rc = apr_ldap_set_option(p, NULL, LDAP_OPT_NETWORK_TIMEOUT, (void *)timeOut, (result_err)); IMO this does not exists on WIN32 (at least PSDK does not declare that), thus mod_ldap breaks on build. The code should be enclosed inside: #if defined(LDAP_OPT_NETWORK_TIMEOUT) #endif Regards, Mladen
Re: Time for 2.0.53?
I don't have a vote, but I believe the socket timeout configuration is necessary to address issues seen with firewall timeouts and the LDAP connections held open by Apache. -- Jess Holle I don't know if this is the best time/place to make a request for patches to be included in 2.0.53, but I do have one that would really help us as we move our apache 1.3 machines to apache 2.0. It is documented at: http://issues.apache.org/bugzilla/show_bug.cgi?id=33198 thanks, -- Shannon Eric Peevey President - EriKin Corporation [EMAIL PROTECTED] (940) 391-6777 http://www.erikin.com
Re: Time for 2.0.53?
I was hoping that this wouldn't be the case. But since it is, take a look at SVN r149419 Brad [EMAIL PROTECTED] Tuesday, February 01, 2005 9:39:20 AM Brad Nicholes wrote: I have already added a new directive to util_ldap called LDAPConnectionTimeout ( http://httpd.apache.org/docs-2.1/mod/mod_ldap.html#ldapconnectiontimeout ) which allows util_ldap to set the network timeout through rc = apr_ldap_set_option(p, NULL, LDAP_OPT_NETWORK_TIMEOUT, (void *)timeOut, (result_err)); IMO this does not exists on WIN32 (at least PSDK does not declare that), thus mod_ldap breaks on build. The code should be enclosed inside: #if defined(LDAP_OPT_NETWORK_TIMEOUT) #endif Regards, Mladen
Re: Time for 2.0.53?
--On Tuesday, February 1, 2005 6:41 AM -0500 Jeff Trawick [EMAIL PROTECTED] wrote: Heck, I don't know how we get from here to closure on the 2.1-dev equivalent ;) What do we do with the proxy-reqbody branch? Merge to trunk? Is it ready to be reviewed? I'd suggest asking for review to merge it back. And, no, I haven't looked at the branch yet - I've been waiting for you to say that it was ready to merge. =) -- justin
Re: Time for 2.0.53?
Brad Nicholes wrote: I was hoping that this wouldn't be the case. But since it is, take a look at SVN r149419 util_ldap.c util_ldap.c(1615) : error C2065: 's' : undeclared identifier util_ldap.c(1615) : warning C4047: 'function' : 'const server_rec *' differs in levels of indirection from 'int' Seems you have typo using wrong server_rec for logging. It helps if you change line 1615 to use cmd-server instead s ;). Regards, Mladen.
Re: Time for 2.0.53?
I hate it when I get bit by copy and paste. Try r149421. Brad [EMAIL PROTECTED] Tuesday, February 01, 2005 10:23:01 AM Brad Nicholes wrote: I was hoping that this wouldn't be the case. But since it is, take a look at SVN r149419 util_ldap.c util_ldap.c(1615) : error C2065: 's' : undeclared identifier util_ldap.c(1615) : warning C4047: 'function' : 'const server_rec *' differs in levels of indirection from 'int' Seems you have typo using wrong server_rec for logging. It helps if you change line 1615 to use cmd-server instead s ;). Regards, Mladen.
Re: Time for 2.0.53?
Justin Erenkrantz wrote: --On Tuesday, February 1, 2005 6:41 AM -0500 Jeff Trawick [EMAIL PROTECTED] wrote: Heck, I don't know how we get from here to closure on the 2.1-dev equivalent ;) What do we do with the proxy-reqbody branch? Merge to trunk? Is it ready to be reviewed? I'd suggest asking for review to merge it back. And, no, I haven't looked at the branch yet - I've been waiting for you to say that it was ready to merge. =) -- justin Yes, I'd post a request for review of the branch :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: Time for 2.0.53?
I'd love to see the LDAP socket timeout configuration stuff make it in for 2.0.53! -- Jess Holle Justin Erenkrantz wrote: Any opposition to doing a tag and roll of 2.0.53 soon? (Yes, I volunteer to be RM.) How about targetting next Tuesday (2/8) for 2.0.53? I can lay down the candidate tarball on Friday morning, so whatever backports are merged by then make it. =) Do we want closure on Jeff's proxy chunking patch for 2.0.53? -- justin
Re: Time for 2.0.53?
[EMAIL PROTECTED] Monday, January 31, 2005 2:26:09 PM I'd love to see the LDAP socket timeout configuration stuff make it in for 2.0.53! -- Jess Holle Justin Erenkrantz wrote: Any opposition to doing a tag and roll of 2.0.53 soon? (Yes, I volunteer to be RM.) How about targetting next Tuesday (2/8) for 2.0.53? I can lay down the candidate tarball on Friday morning, so whatever backports are merged by then make it. =) Do we want closure on Jeff's proxy chunking patch for 2.0.53? -- justin Me too ;) Any voters out there? I've already cast my vote (Obviously) From the looks of the STATUS file, there appears to be a number of backports with 3 +1's that just need to be backported. Brad
RE: Time for 2.0.53?
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] Sent: Monday, January 31, 2005 10:19 PM Any opposition to doing a tag and roll of 2.0.53 soon? Nope. (Yes, I volunteer to be RM.) Thanks Justin. How about targetting next Tuesday (2/8) for 2.0.53? I can lay down the candidate tarball on Friday morning, so whatever backports are merged by then make it. =) I wouldn't pin yourself to a release date too much. Just start the TR and when we're satisfied with it, release. Do we want closure on Jeff's proxy chunking patch for 2.0.53? It's not a showstopper IMO. -- justin Sander
