At 10:19 04/12/2006, Jiri Kuthan wrote:
At 18:22 30/11/2006, Daniel-Constantin Mierla wrote:
Hello,
some confusion was created around this subject. It was pointed a news which was related to an improvement (fetch support) which brought memory usage optimization in usrloc (going to be expanded in usage to other modules, like lcr, presence ...), not usrloc loading/lookup optimization. It was not yet a news since the work is not fully finished/well tested. The news about this new improvements will come in the near future. It started in summer, with:
http://openser.org/pipermail/devel/2006-July/003469.html
Shortly, usrloc records are not loaded anymore by the main process, but by first child. All other children processes can handle other events/sip messages in parallel. Previously, at start, OpenSER was blocked until all records were loaded, which could be quite long when having big numbers of active users.
Whats going to happen then if a child x process wants to read a usrloc entry whereas child 1 is not finished reading yet?
CAn someone help with the questions - retransmission: can't there be inconsistence of data during initial DB loading? - performance: can comeone confirm for me that the acclaimed memory saving are not achievable, as suggested in Andrei's email
The bottom line is I'm trying to learn what it actually is and based on these assumptions, it appears one-process-loading+others-as-normal -- it that what it does?
Thanks!
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/