axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uthaiyashankar <shan...@wso2.com>
Subject Re: [Axis2] Apache process problems [Was - Re: Urgent: Specifying scope in Axis2c]
Date Wed, 21 Nov 2007 04:26:46 GMT
Hi,

An implementation is given in 
https://issues.apache.org/jira/browse/AXIS2C-780
please check and apply the patch. comments are welcome.

regards,
Uthaiyashankar.

Uthaiyashankar wrote:
> Hi Chris,
>
> Thank you very much for the comment. For the initial phase, as you 
> advised, we'll proceed by allocating a large block without resizing. 
> Later on, we can implement the resizing logic.
>
> Regards,
> Uthaiyashankar
>
>
>
> Chris Darroch wrote:
>> Uthaiyashankar wrote:
>>
>>  
>>> We can use global mutex to control the access of shared memory. An 
>>> example implementation is given in  
>>> http://people.apache.org/~sctemme/mod_example_ipc.c.
>>> mod_ldap is also using a similar approach to cache and share data 
>>> between child processes.
>>>
>>> However, to hide the low level details from service/module 
>>> implementers, we might have to write a wrapper to manage the shared 
>>> memory, growing/shrinking the shared memory according to the demand, 
>>> creating objects in shared memory, etc.
>>>     
>>
>>    One caution: growing/shrinking shared memory is likely to be a
>> pretty complex operation, if it's even possible with certain 
>> shared-memory
>> implementations.  APR provides a number of different shared memory
>> options and chooses between them at compile-time; the only options
>> to the programmer are named-based vs. anonymous.
>>
>>    To resize the shared memory block, you'd probably need name-based
>> shared memory, first of all.  The only way I can see resizing would
>> work is if all the processes coordinate; suppose, for example, that
>> process A acquires the global lock, it could then allocate a new
>> shared-memory block, copy all the data from the old one, and write
>> the filename associated with the new block into a special location
>> in the old one or communicate it somehow to all other processes;
>> they then need to attach to the new block and detach from the old block.
>> Depending on the underlying implementation, you might, I suppose,
>> need to also manage a reference count of how many processes are
>> still attached to the old block, and only destroy it when all had
>> attached to the new block; this of course gets complicated if a
>> process dies suddenly, etc.
>>
>>    This is why httpd, for its scoreboard, simply creates a large
>> shared memory segment at startup (based on compile-time limits)
>> and never tries to resize it.
>>
>>    A number of httpd modules already manage data in shared memory
>> segments (in one case, by borrowing part of the scoreboard, but
>> that's not ideal).  I proposed, for httpd 3.0, some ideas about how
>> to try to abstract the subject of inter-process data sharing, such
>> that different providers could be plugged into a generic interface
>> (shared memory, memcache, etc.):
>>
>> http://svn.apache.org/viewvc/httpd/sandbox/amsterdam/architecture/scoreboard.txt
  
>>
>>    I think Axis2/C might be a good candidate to be another user of
>> this mechanism ... but, of course, it exists only on paper so far.
>> With luck I'll get back to this in 2008; time permitting, of course!
>>
>> Cheers,
>>
>> Chris.
>>
>>   


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message