[SR-Users] permissions module address_reload not working

[Daniel-Constantin Mierla]

On 7/1/10 5:54 PM, Daniel-Constantin Mierla wrote:
>
>
> On 7/1/10 4:39 PM, Juha Heinanen wrote:
>> Daniel-Constantin Mierla writes:
>>
>>> this is another issue ... the mi commands were designed to be run from
>>> special processes, created by mi transport modules (mi_fifo,
>>> mi_datagram, etc). There are special init functions called for these
>>> processes. However, with 3.0 xmlrpc module can call these functions but
>>> the module re-uses SIP tcp processes, meaning that what is called in mi
>>> init child function should be called in child init functions.
>> mi trusted_reload from the same module works fine using both crt and
>> xmlrpc:
>
> yes, checking the sources I see trusted and address operations use 
> different db handlers. The one for trusted is initialized from 
> child_init, while the other one is not. Probably because the trusted 
> can work in non-cache mode and need the connection for sip worker.
>
>
>> # sip-proxy_ctl mi trusted_reload
>> #
>>
>> Jul  1 17:35:35 localhost /usr/sbin/sip-proxy[11824]: INFO: Handling 
>> XMLRPC POST from<127.0.0.1>  with body<<?xml version="1.0" 
>> ?><methodCall><methodName>mi</methodName><params><param><value><string>trusted_reload</string></value></param></params></methodCall>> 
>>
>>
>> so may the same kind of implementation could be used also for
>> address_realod.
>>
>>> - call all mi child init functions in mi_rpc child_init even for SIP
>>> worker process - in the previous commit I added execution only for
>>> PROC_RPC. But then each module exporting mi commands has to be reviewed
>>> to see if there is no overlapping (usually is about opening db
>>> connection, thus make sure it is not opened twice in same process)
>>> - execute per module mi init fuction specific for that module. This 
>>> will
>>> ensure that mi command become available to xmlrpc module gradually but
>>> safe. It has a drawback of initializing MI specific stuff for each
>>> process even when mi_rpc is not loaded, thus such things are not needed
>>> at runtime
>>>
>>> Both options requires check over the mi cmd modules. Right now I think
>>> option 1 is better, because it does not initialize db connections when
>>> not needed, other opinions?
>> another opinion is: replace permissions module mi commands with rpc
>> ones.
> it is an option, somehow in the global to-do list to replace mi with 
> rpc. Right now, this issue is not only for permissions module, is also 
> affecting other mi cmds which are going to be used over xmlrpc module 
> -- using mi commands via rpc interface with sercmd is different and 
> there is no issue with that.

I just committed initialization of mi commands in sip worker processes 
by mi_rpc module when xmlrpc module is loaded.

The other modules exporting mi commands were updated to avoid 
re-initialization. In most of the cases was about opening db connection, 
which was harmless anyhow, another connection handler was requested and 
since there is a pool of connections per process, the previous one would 
have been returned. However, if something else needs to be initialized, 
it is now an indication that the developer should take care when doing 
mi process init, which should not happen anymore as RPC control 
interface is to be used for new development.

No time to do real tests, if you can run some and report back, it would 
be great. Once some testing is done, can be ported to 3.0.

Thanks,
Daniel


-- 
Daniel-Constantin Mierla
http://www.asipto.com/