Re: mod_proxy feature coming up
Jim Jagielski wrote: On Jul 18, 2006, at 11:29 AM, Jim Jagielski wrote: Yes, I'd propose waiting to commit that. The sole reason is that the member-set and other previously committed patches will likely be more readily approved for backporting to 2.2.x, whereas the scoreboard changes might be more difficult :) Of course, another option would be creating a quick httpd-trunk branch (httpd-proxy-scoreboard??) and committing the patch there, and we can then merge at some soon future point. We should really use SVN's cheap branches as much as possible... Ok I will create a branch and we will merge it later. Cheers Jean-Frederic
Re: mod_proxy feature coming up
Jean-frederic Clere wrote: > > > Ok. That gives me time to write more "memory slot handler". > Mladen's also let me know offlist that he's working on some AJP stuff as well, so the current "schedule" is that after he's added that, I'll add my member set patch. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: mod_proxy feature coming up
Jim Jagielski wrote: Jean-frederic Clere wrote: Jim Jagielski wrote: Pretty soon I'll be committing my "balancer set" patch to httpd-trunk. This basically allows for member sets within a balancer similar to the 'distance' mod_jk attribute. What it does is allow for more control over which members will be used via m_p_b. The logic is: Look for all usable members in set #0 If none exist, look for any host standbys in #0 If none exist, select the next set and loop I think this design provides the most flexibility for the admin. Anyway, this will require an update to the pertinent data struct to add the "set" element. I will also at this time likely add a "busy" element as well, in anticipation of the by-busyness LB method patch ;) Nice I have also prepared "memory slot handler" to replace the scoreboard space used by mod_proxy may I should wait before committing the part that affects mod_proxy.c, proxy_util.c and mod_proxy.h? Yes, I'd propose waiting to commit that. The sole reason is that the member-set and other previously committed patches will likely be more readily approved for backporting to 2.2.x, whereas the scoreboard changes might be more difficult :) Ok. That gives me time to write more "memory slot handler". Cheers Jean-Frederic
Re: mod_proxy feature coming up
On Jul 18, 2006, at 11:29 AM, Jim Jagielski wrote: Yes, I'd propose waiting to commit that. The sole reason is that the member-set and other previously committed patches will likely be more readily approved for backporting to 2.2.x, whereas the scoreboard changes might be more difficult :) Of course, another option would be creating a quick httpd-trunk branch (httpd-proxy-scoreboard??) and committing the patch there, and we can then merge at some soon future point. We should really use SVN's cheap branches as much as possible...
Re: mod_proxy feature coming up
Jean-frederic Clere wrote: > > Jim Jagielski wrote: > > > Pretty soon I'll be committing my "balancer set" patch to > > httpd-trunk. This basically allows for member sets within > > a balancer similar to the 'distance' mod_jk attribute. > > What it does is allow for more control over which > > members will be used via m_p_b. The logic is: > > > > > > Look for all usable members in set #0 > > If none exist, look for any host standbys in #0 > > If none exist, select the next set and loop > > > > I think this design provides the most flexibility > > for the admin. Anyway, this will require an update > > to the pertinent data struct to add the "set" element. > > I will also at this time likely add a "busy" element > > as well, in anticipation of the by-busyness LB method > > patch ;) > > > Nice I have also prepared "memory slot handler" to replace the > scoreboard space used by mod_proxy may I should wait before committing > the part that affects mod_proxy.c, proxy_util.c and mod_proxy.h? > Yes, I'd propose waiting to commit that. The sole reason is that the member-set and other previously committed patches will likely be more readily approved for backporting to 2.2.x, whereas the scoreboard changes might be more difficult :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: mod_proxy feature coming up
Jim Jagielski wrote: Pretty soon I'll be committing my "balancer set" patch to httpd-trunk. This basically allows for member sets within a balancer similar to the 'distance' mod_jk attribute. What it does is allow for more control over which members will be used via m_p_b. The logic is: Look for all usable members in set #0 If none exist, look for any host standbys in #0 If none exist, select the next set and loop I think this design provides the most flexibility for the admin. Anyway, this will require an update to the pertinent data struct to add the "set" element. I will also at this time likely add a "busy" element as well, in anticipation of the by-busyness LB method patch ;) Nice I have also prepared "memory slot handler" to replace the scoreboard space used by mod_proxy may I should wait before committing the part that affects mod_proxy.c, proxy_util.c and mod_proxy.h? Cheers Jean-Frederic
Re: mod_proxy feature coming up
Jim Jagielski wrote: Pretty soon I'll be committing my "balancer set" patch to httpd-trunk. This basically allows for member sets within a balancer similar to the 'distance' mod_jk attribute. Huh, thanks :) I've only spend two weeks on it. -- Mladen.
mod_proxy feature coming up
Pretty soon I'll be committing my "balancer set" patch to httpd-trunk. This basically allows for member sets within a balancer similar to the 'distance' mod_jk attribute. What it does is allow for more control over which members will be used via m_p_b. The logic is: Look for all usable members in set #0 If none exist, look for any host standbys in #0 If none exist, select the next set and loop I think this design provides the most flexibility for the admin. Anyway, this will require an update to the pertinent data struct to add the "set" element. I will also at this time likely add a "busy" element as well, in anticipation of the by-busyness LB method patch ;)
