Hello,
based on a recent discussion with Alex Balashov (at Kazoocon this week), I pushed a patch that enables the execution of event_route[core:worker-one-init] when kamailio is started. It would be more like an alternative for event_route[htable:mod-init], for the cases when htable is not used, but also should ensure that all the modules are initialized. Moreover, because most of the modules close connection in mod init, I though of doing it when child one (udp receiver) initialization for all modules is finished, which means that all is ready for runtime, still this is before receiving any packet.
On the other hand, forking is done by main process, so other children can start listening for sip.
More or less what I want to ask here is whether the forking of the other children should wait until the event_route[core:worker-one-init] is finished (e.g., what is done in this event route is important before any sip packet is routed) or just leave it like it is.
Worth to say that some modules do special processing in child init of worker one, like usrloc module loads the records from database to memory, which means that overall start of kamailio could be slower. Also, if there are time consuming actions in the event_route[core:worker-one-init], getting to the stage of routing sip packets will take longer.
What would you find important, fork the other processes so routing sip will happen as soon as possible, or block until execution ofevent_route[core:worker-one-init] is finished.
I guess that making it cusomizable in some way would be a solution, but knowing what use cases would be important may help in reducing the complexity to get it enabled.
Cheers, Daniel
More or less what I want to ask here is whether the forking of the other children should wait until the event_route[core:worker-one-init] is finished (e.g., what is done in this event route is important before any sip packet is routed) or just leave it like it is.
I need htable initialized before sip requests are processed, but perhaps there exist other use cases where it is not necessary.
Juha
Daniel,
First and foremost, thank you very much for implementing this. I have been buried with work lately, and resultingly have not had the opportunity to chime in on this thread or to thank you for such a prompt response to this desire.
I would concur with Juha that for the use-cases I've got in mind[1], the completion of the init route prior to processing SIP messages is highly desirable.
-- Alex
[1] Largely initialisation of global configuration values from dynamic sources.