<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18702"></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=935590302-30052009><FONT color=#0000ff
size=2 face=Arial>I had similar thoughts regarding David's patch about
other res_* modules depending on res_timing_*.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=935590302-30052009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=935590302-30052009><FONT color=#0000ff
size=2 face=Arial>But wondered what the priority was regarding preload modules
in modules.conf, which comes first, the David's patch loading all res_*
or the preload modules in module.conf.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=935590302-30052009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=935590302-30052009><FONT color=#0000ff
size=2 face=Arial>Or could it be made to work to our
advantage:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=935590302-30052009><FONT color=#0000ff
size=2 face=Arial> 1st. preload res_*
modules that specifically need to be loaded first and in order
from modules.conf</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=935590302-30052009> <FONT
color=#0000ff size=2 face=Arial>2nd. preload all
other </FONT></SPAN><SPAN class=935590302-30052009><FONT color=#0000ff
size=2 face=Arial>res_* using David's patch.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=935590302-30052009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=935590302-30052009></SPAN><FONT
face=Arial><FONT color=#0000ff><FONT size=2>A<SPAN
class=935590302-30052009>lec</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><SPAN class=935590302-30052009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> asterisk-dev-bounces@lists.digium.com
[mailto:asterisk-dev-bounces@lists.digium.com] <B>On Behalf Of </B>Jonathan
Thurman<BR><B>Sent:</B> Saturday, 30 May 2009 11:12 a.m.<BR><B>To:</B> Asterisk
Developers Mailing List<BR><B>Subject:</B> Re: [asterisk-dev] [Code Review] IAX
timer not loading<BR></FONT><BR></DIV>
<DIV></DIV>I tested using preload to verify that it would fix the problem that I
was having with this. I am using res_timing_pthreads.so and
res_timing_dahdi.so in my testing. Both work just fine.<BR><BR>I think
that David's patch to preload the res_ modules would be much more simple, as
long as none of those modules depend on res_timing_*. The patch should
also modify the sample modules.conf file, as the examples for preloading
res_odbc.so, res_config_odbc.so would not need to be there. It should
probably also mention that res_* modules are loaded first in the first comment
block.<BR><BR>-Jonathan<BR><BR><BR>
<DIV class=gmail_quote>On Fri, May 29, 2009 at 3:49 PM, Alec Davis <SPAN
dir=ltr><<A
href="mailto:sivad.a@paradise.net.nz">sivad.a@paradise.net.nz</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE
style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>Something has changed between versions. If only <A
href="http://svn.digium.com/view" target=_blank>svn.digium.com/view</A>
was<BR>working, might have been able to track down what changed when, also
maybe<BR>not ....<BR><BR>The bug I reported <A
href="https://issues.asterisk.org/view.php?id=15191"
target=_blank>https://issues.asterisk.org/view.php?id=15191</A> comes up
as<BR>trunk mode only on an old version SVN r178446m, but newer versions
fail.<BR><BR>Jthurman suggests <A
href="https://issues.asterisk.org/view.php?id=15191#105720"
target=_blank>https://issues.asterisk.org/view.php?id=15191#105720</A><BR>preloading
timing resource in modules.conf<BR><BR>Added 'preload =>
res_timing_dahdi.so' in modules.conf, on the following,<BR>now IAX trunk comes
up as trunk mode after every asterisk
restart.<BR>SVN-trunk-r192214M<BR>SVN-trunk-r181371M<BR>SVN-trunk-r178919M<BR><BR>I've
checked SVN-trunk-r178446M and it doesn't have 'preload
=><BR>res_timing_dahdi.so' in modules.conf, and all trunks come up in trunk
mode<BR>after every restart.<BR><BR>What about res_timing_pthread.so for
installations without timing hardware?<BR><BR>My vote: 'to force the loader to
preload timing modules' which will then<BR>work for existing installations
that may upgrade, where 'make samples'<BR>probably won't be
run.<BR><BR>Changing only the default sample file modules.conf.samples will
only help<BR>new installations, where 'make samples' probably would
run.<BR><FONT color=#888888><BR>Alec Davis<BR></FONT>
<DIV>
<DIV></DIV>
<DIV class=h5><BR><BR><BR>-----Original Message-----<BR>From: <A
href="mailto:asterisk-dev-bounces@lists.digium.com">asterisk-dev-bounces@lists.digium.com</A><BR>[mailto:<A
href="mailto:asterisk-dev-bounces@lists.digium.com">asterisk-dev-bounces@lists.digium.com</A>]
On Behalf Of Russell Bryant<BR>Sent: Saturday, 30 May 2009 9:18 a.m.<BR>To:
David Vossel; Russell Bryant; Asterisk Developers<BR>Subject: Re:
[asterisk-dev] [Code Review] IAX timer not
loading<BR><BR><BR>-----------------------------------------------------------<BR>This
is an automatically generated e-mail. To reply, visit:<BR><A
href="http://reviewboard.digium.com/r/262/#review808"
target=_blank>http://reviewboard.digium.com/r/262/#review808</A><BR>-----------------------------------------------------------<BR><BR><BR>This
is a tricky situation. :-)<BR><BR>One thing with this patch is that
while it prevents the code from accepting<BR>trunked calls before Asterisk
fully starts, it will not prevent Asterisk<BR>from starting up outbound
trunked calls. So, there is still some potential<BR>for failure
here.<BR><BR>The only things that I can think of that would make this work
make the patch<BR>even more complicated and module initialization even more
bizarre.<BR><BR>I am really liking just patching the loader to force timing
modules to get<BR>preloaded. My current suggestion is to write a new
patch that goes that<BR>route, and then we'll see what comments show up on the
code review. It<BR>seems like a reasonable thing to let modules assume
that fundamental<BR>subsystems, such as the timing interface, are fully
initialized before they<BR>get loaded. Otherwise, the code is really
going to get ugly.<BR><BR>- Russell<BR><BR><BR>On 2009-05-28 09:57:40, David
Vossel wrote:<BR>><BR>>
-----------------------------------------------------------<BR>> This is an
automatically generated e-mail. To reply, visit:<BR>> <A
href="http://reviewboard.digium.com/r/262/"
target=_blank>http://reviewboard.digium.com/r/262/</A><BR>>
-----------------------------------------------------------<BR>><BR>>
(Updated 2009-05-28 09:57:40)<BR>><BR>><BR>> Review request for
Asterisk Developers.<BR>><BR>><BR>> Summary<BR>>
-------<BR>><BR>> When loading chan_iax2, a timer is opened. If
this timer fails to open<BR>trunk peers/users may not be built correctly.
Depending on the order<BR>Asterisk loads modules, the timer may or may
not be loaded before chan_iax2.<BR>If it is not loaded before hand, trunk
peers/users will not be set up even<BR>though a timing interface may be
possible. This patch waits until Asterisk<BR>is fully booted to create
the timer. If the timer fails, all trunked<BR>peers/users' IAX_TRUNK
flags are cleared and a warning message appears.<BR>><BR>><BR>> This
addresses bug 15191.<BR>> <A
href="https://issues.asterisk.org/view.php?id=15191"
target=_blank>https://issues.asterisk.org/view.php?id=15191</A><BR>><BR>><BR>>
Diffs<BR>> -----<BR>><BR>> /trunk/channels/chan_iax2.c
197192<BR>><BR>> Diff: <A
href="http://reviewboard.digium.com/r/262/diff"
target=_blank>http://reviewboard.digium.com/r/262/diff</A><BR>><BR>><BR>>
Testing<BR>> -------<BR>><BR>> tested with and without loading the
timer module. worked correctly.<BR>><BR>><BR>>
Thanks,<BR>><BR>>
David<BR>><BR>><BR><BR><BR>_______________________________________________<BR>--Bandwidth
and Colocation Provided by <A href="http://www.api-digital.com--"
target=_blank>http://www.api-digital.com--</A><BR><BR>asterisk-dev mailing
list<BR>To UNSUBSCRIBE or update options visit:<BR> <A
href="http://lists.digium.com/mailman/listinfo/asterisk-dev"
target=_blank>http://lists.digium.com/mailman/listinfo/asterisk-dev</A><BR><BR><BR>_______________________________________________<BR>--Bandwidth
and Colocation Provided by <A href="http://www.api-digital.com--"
target=_blank>http://www.api-digital.com--</A><BR><BR>asterisk-dev mailing
list<BR>To UNSUBSCRIBE or update options visit:<BR> <A
href="http://lists.digium.com/mailman/listinfo/asterisk-dev"
target=_blank>http://lists.digium.com/mailman/listinfo/asterisk-dev</A><BR></DIV></DIV></BLOCKQUOTE></DIV><BR></BODY></HTML>