mod_slotmem and mod_proxy_balancer/others on win32 (PR52402)
Hi, mod_slotmem cannot work on windows by design. On windows we have two processes so the storage-grab/slotmem_grab will always fail because the inuse flag was already set in the parent, and since this is shared memory child will see it as used. On unixes fork is used so the inuse is set only once. Not sure how to solve this. Perhaps adding generation logic like we are doing for scoreboard. In any case until this gets resolved httpd is unusable on win32. Regards -- ^TM
Re: mod_slotmem and mod_proxy_balancer/others on win32 (PR52402)
On Feb 3, 2012, at 4:25 AM, Mladen Turk wrote: Hi, mod_slotmem cannot work on windows by design. On windows we have two processes so the storage-grab/slotmem_grab will always fail because the inuse flag was already set in the parent, and since this is shared memory child will see it as used. On unixes fork is used so the inuse is set only once. I'm trying to understand this... how is this different from any of the other mpms which also have at least 2 processes?
Re: mod_slotmem and mod_proxy_balancer/others on win32 (PR52402)
Under Win32, do the 2 processes know which is which? On Feb 3, 2012, at 5:46 AM, Jim Jagielski wrote: On Feb 3, 2012, at 4:25 AM, Mladen Turk wrote: Hi, mod_slotmem cannot work on windows by design. On windows we have two processes so the storage-grab/slotmem_grab will always fail because the inuse flag was already set in the parent, and since this is shared memory child will see it as used. On unixes fork is used so the inuse is set only once. I'm trying to understand this... how is this different from any of the other mpms which also have at least 2 processes?
Re: mod_slotmem and mod_proxy_balancer/others on win32 (PR52402)
On 02/03/2012 11:46 AM, Jim Jagielski wrote:
On Feb 3, 2012, at 4:25 AM, Mladen Turk wrote:
Hi,
mod_slotmem cannot work on windows by design.
On windows we have two processes so the storage-grab/slotmem_grab
will always fail because the inuse flag was already set in the parent,
and since this is shared memory child will see it as used.
On unixes fork is used so the inuse is set only once.
I'm trying to understand this... how is this different from any of
the other mpms which also have at least 2 processes?
Right, seems that's not the reason for PR52402.
Found the fix for it. The reason is the loop:
while (s) {
int i,j;
proxy_balancer *balancer;
sconf = s-module_config;
conf = (proxy_server_conf *)ap_get_module_config(sconf, proxy_module);
/* adding ... */
if (conf-bslot) {
/* We already have shared memory storage created for this
server_rec.
* Skip second invocation because there are no more space left in
* the shm so the storage-grab() will fail.
*/
s = s-next;
continue;
}
Fixes the issue, although I'm not sure that's the correct solution.
Shared memory id uses vhost name for key, and think it should use
vhost:port combination instead.
However I might be wrong and the upper patch is all that's needed
if the balancer is shared between multiple server_rec's
Regards
--
^TM
Re: mod_slotmem and mod_proxy_balancer/others on win32 (PR52402)
On Feb 3, 2012, at 8:03 AM, Mladen Turk wrote:
Right, seems that's not the reason for PR52402.
Found the fix for it. The reason is the loop:
while (s) {
int i,j;
proxy_balancer *balancer;
sconf = s-module_config;
conf = (proxy_server_conf *)ap_get_module_config(sconf, proxy_module);
/* adding ... */
if (conf-bslot) {
/* We already have shared memory storage created for this
server_rec.
* Skip second invocation because there are no more space left in
* the shm so the storage-grab() will fail.
*/
s = s-next;
continue;
}
Fixes the issue, although I'm not sure that's the correct solution.
Shared memory id uses vhost name for key, and think it should use
vhost:port combination instead.
However I might be wrong and the upper patch is all that's needed
if the balancer is shared between multiple server_rec's
THANKS! Let me look into this more... at 1st blush, the suggestion
of vhost:port makes sense... maybe even scheme:vhost:port.
Re: mod_slotmem and mod_proxy_balancer/others on win32 (PR52402)
On 02/03/2012 02:45 PM, Jim Jagielski wrote:
On Feb 3, 2012, at 8:03 AM, Mladen Turk wrote:
Right, seems that's not the reason for PR52402.
Found the fix for it. The reason is the loop:
while (s) {
int i,j;
proxy_balancer *balancer;
sconf = s-module_config;
conf = (proxy_server_conf *)ap_get_module_config(sconf,proxy_module);
/* adding ... */
if (conf-bslot) {
/* We already have shared memory storage created for this
server_rec.
* Skip second invocation because there are no more space left in
* the shm so the storage-grab() will fail.
*/
s = s-next;
continue;
}
Fixes the issue, although I'm not sure that's the correct solution.
Shared memory id uses vhost name for key, and think it should use
vhost:port combination instead.
However I might be wrong and the upper patch is all that's needed
if the balancer is shared between multiple server_rec's
THANKS! Let me look into this more... at 1st blush, the suggestion
of vhost:port makes sense... maybe even scheme:vhost:port.
Well actually I think that there could be multiple server_rec
for which ap_get_module_config(s-module_config,proxy_module) will
return the same proxy_server_conf.
My patch will handle those cases (the PR52402 itself)
Think I'll commit that cause regardless of anything trying to create
already created shared memory is obvious error.
Regards
--
^TM
Re: mod_slotmem and mod_proxy_balancer/others on win32 (PR52402)
On Fri, Feb 03, 2012 at 03:06:03PM +0100, Mladen Turk wrote: Well actually I think that there could be multiple server_rec for which ap_get_module_config(s-module_config,proxy_module) will return the same proxy_server_conf. My patch will handle those cases (the PR52402 itself) Think I'll commit that cause regardless of anything trying to create already created shared memory is obvious error. +1. thanks continue; -- === Jim Jagielski [|] j...@jagunet.com [|] http://www.jaguNET.com/ Great is the guilt of an unnecessary war ~ John Adams
Re: mod_slotmem and mod_proxy_balancer/others on win32 (PR52402)
On 2/3/2012 4:46 AM, Jim Jagielski wrote: On Feb 3, 2012, at 4:25 AM, Mladen Turk wrote: Hi, mod_slotmem cannot work on windows by design. On windows we have two processes so the storage-grab/slotmem_grab will always fail because the inuse flag was already set in the parent, and since this is shared memory child will see it as used. On unixes fork is used so the inuse is set only once. I'm trying to understand this... how is this different from any of the other mpms which also have at least 2 processes? CreateProcess() ... fork()
