Thread: [Asterisk-java-users] Manager: no socket read timeout ?
Brought to you by:
srt
Menu
▾
▴
asterisk-java-users
|
From: Gaetan M. <gm...@ea...> - 2007-01-13 00:46:07
|
Hi, First of all, thank you for this amazing library. I use the manager connection part with ast live. When I "stressed" the auto reconnection feature with an "unstable asterisk server" I remarked that only the socket connection timeout can be set, but not the socket read timeout. So if I stop/restart asterisk for example, it works as expected. The TCP socket is closed immediately and reopened. But if I unplug the power of the asterisk server, or perturb the network between my client and the asterisk server in a way that prevents the tcp layer from cleanly disposing the connection (reboot a statefull firewall, reconnect my vpn so my development machine gets another IP ...), then the client socket hangs "forever" (well with tcp keepalive it should be 2 hours right ?). I modified SocketConnectionFacadeImpl.java and added socket.setSoTimeout(timeout); to the constructor. That way the connection is dropped and restarted if it stales on read longer than the timeout. Of course I started a PingThread on the connection too, with an interval of half the socket timeout. Won't this have other (bad) side effects on the library ? Is there a nicer way to do this ? Gaetan |
|
From: Stefan R. <ste...@re...> - 2007-01-18 23:09:08
Attachments:
signature.asc
|
Gaetan Minet wrote: > Won't this have other (bad) side effects on the library ? No I don't think so. > Is there a nicer way to do this ? The proposed solution sounds good. I'll run some tests and include it in svn trunk. Thanks, Stefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: ste...@re... Jabber: ste...@re... |
|
From: Stefan R. <ste...@re...> - 2007-01-21 17:16:48
Attachments:
signature.asc
|
Hi, I did have a look at your suggestion and find it really useful. The only problem is that it requires a PingThread to work reliable. Therefore I didn't enable it by default but added a setReadTimeout() method to the DefaultManagerConnection with a short description and a note that a PingThread should be used with an interval of half the readTimeout. The latest code is in svn and at http://maven.reucon.com/public-snapshot/org/asteriskjava/asterisk-java/ Thanks, =3DStefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: ste...@re... Jabber: ste...@re... |
|
From: Gaetan M. <gm...@ea...> - 2007-01-27 17:02:56
|
Hi Stefan > I did have a look at your suggestion and find it really useful. > The only problem is that it requires a PingThread to work reliable. > Therefore I didn't enable it by default but added a setReadTimeout() > method to the DefaultManagerConnection with a short description and a > note that a PingThread should be used with an interval of half the > readTimeout. > > The latest code is in svn and at > I just updated to head, and it works smoothly . Thanks. It also resolved my problem with the missing "newuniqueid" setter (didn"t know it is added by Bristuff). However when the connection times out and reconnects, it is logged to INFO. Shouldn't it be better to log to the WARN cat instead ? > http://maven.reucon.com/public-snapshot/org/asteriskjava/asterisk-java/ > > Aren't the snapshot links on http://asterisk-java.org and http://asterisk-java.org/development outdated ? Those point to http://maven.reucon.com/public/org/asteriskjava/asterisk-java/ Regards Gaetan |
|
From: Stefan R. <ste...@re...> - 2007-01-28 02:46:54
Attachments:
signature.asc
|
Gaetan Minet wrote: > However when the connection times out and reconnects, it is logged to > INFO. Shouldn't it be better to log to the WARN cat instead ? can you point me to the code that logs the message you want to have issued as warning? > Aren't the snapshot links on http://asterisk-java.org and > http://asterisk-java.org/development outdated ? > Those point to > http://maven.reucon.com/public/org/asteriskjava/asterisk-java/ Yes sorry, they still pointed to the old location before the split in a release and snapshot repo. I've fixed them. =3DStefan |
|
From: Gaetan M. <gm...@ea...> - 2007-01-28 04:10:26
|
Hi Stefan
> can you point me to the code that logs the message you want to have
> issued as warning?
>
>
I'm back to 0.3m1 for tests right now, I'll tell you tomorrow.
I switched back to 0.3m1 to track what looks like a bug ?
If you restart the asterisk server then the reader will try and
reconnect, but when using asterisk live, in the debugger you can see
DaemonPool threads stack up, one new for each (re)connection and the
events are handled multiple times by the channel manager for example.
I think this could be due to the AsteriskServerImpl being reinitialised
and added again and again as a listener for the events (with async on or
off indeed) :
if (asyncEventHandling)
{
eventConnection.addEventListener(new
ManagerEventListenerProxy(this));
}
else
{
eventConnection.addEventListener(this);
}
As a consequence, the events are handled multiple times (by the main
thread or an army of DaemonPool threads :d).
This happens in 0.3m1 and trunk.
regards
Gaetan
|
|
From: Stefan R. <ste...@re...> - 2007-01-28 09:17:28
Attachments:
signature.asc
|
If we prevent the manager connection from being set multiple times then we could modify initializeIfNeeded to check if we already set an event listener and only add if thats not the case. Does this help? Changes are at http://fe.reucon.net/fisheye/changelog/repos/?cs=3D597 =3DStefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: ste...@re... Jabber: ste...@re... |
|
From: King H. <kin...@ne...> - 2007-01-28 14:27:33
|
Hi, I am proposing to add a shutdown() method for the ManagerEventListenerProxy class. I know that it is using daemon thread, but the asterisk-java library might be used inside a web application. If this is the case, the application server will usually not be restarted for just restarting a single web application and the daemon threads will not be terminated automatically. I can submit a patch it necessary. Thanks! Best Regards, King |
|
From: Stefan R. <ste...@re...> - 2007-01-28 14:37:06
Attachments:
signature.asc
|
King Ho wrote: > I can submit a patch it necessary. That would be great. Against latest SVN HEAD at http://svn.reucon.net/repos/asterisk-java/trunk/ Thanks, Stefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: ste...@re... Jabber: ste...@re... |
|
From: King H. <kin...@ne...> - 2007-01-28 15:21:10
Attachments:
asterisk-java-shutdown.patch
|
Stefan, The attached patch, against trunk, will add a shutdown() method to AsteriskServer which will in turn shutdown the threads in ManagerEventListenerProxy if necessary. You can use it however you like or to throw it away if you don't like it;) Best Regards, King -----Original Message----- From: ast...@li... [mailto:ast...@li...] On Behalf Of Stefan Reuter Sent: Sunday, January 28, 2007 10:37 PM To: ast...@li... Subject: Re: [Asterisk-java-users] Shutdown for ManagerEventListenerProxy King Ho wrote: > I can submit a patch it necessary. That would be great. Against latest SVN HEAD at http://svn.reucon.net/repos/asterisk-java/trunk/ Thanks, Stefan -- reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: ste...@re... Jabber: ste...@re... |
|
From: King H. <kin...@ne...> - 2007-01-28 15:41:56
|
Stefan, I see that AsteriskServerImpl upon reconnects to the Asterisk server will clears all the Channels in memory and do nothing about the originateCallBacks (it might have quite a number of callbacks registered and they won't be freed until removed from originateCallbacks). l think we should only remove channels that are no longer returned by StatusAction() and also remove the callbacks that don't have any corresponding channels. If you think we should make the change, I can submit a patch for this change. Best Regards, King |
|
From: King H. <kin...@ne...> - 2007-01-28 15:55:09
|
I should have said ChannelManager rather than AsteriskServerImpl. King -----Original Message----- From: ast...@li... [mailto:ast...@li...] On Behalf Of King Ho Sent: Sunday, January 28, 2007 11:44 PM To: ast...@li... Subject: [Asterisk-java-users] AsteriskServerImpl reconnect processing Stefan, I see that AsteriskServerImpl upon reconnects to the Asterisk server will clears all the Channels in memory and do nothing about the originateCallBacks (it might have quite a number of callbacks registered and they won't be freed until removed from originateCallbacks). l think we should only remove channels that are no longer returned by StatusAction() and also remove the callbacks that don't have any corresponding channels. If you think we should make the change, I can submit a patch for this change. Best Regards, King ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Asterisk-java-users mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/asterisk-java-users __________ NOD32 2014 (20070128) Information __________ This message was checked by NOD32 antivirus system. http://www.nod32.com.hk |
|
From: Gabriel A. <gab...@gl...> - 2007-02-02 19:52:09
|
Hi All, We're making outgoing calls using ManagerConnection.sendEventGeneratingAction() and OriginateAction. After receiving the corresponding CdrEvent we disconnect it with logoff method. The problem is that this logoff throws an Exception: net.sf.asterisk.manager.TimeoutException: Timeout waiting for response to Logoff at net.sf.asterisk.manager.DefaultManagerConnection.sendAction(DefaultManagerCo nnection.java:634) at net.sf.asterisk.manager.DefaultManagerConnection.sendAction(DefaultManagerCo nnection.java:600) at net.sf.asterisk.manager.DefaultManagerConnection.logoff As we could verify, the Manager Connection was logged off in Asterisk, but in the Framework the ManagerConnection are still alive. Any idea or suggestion? Thanks in advance, Gabriel. |
|
From: Stefan R. <ste...@re...> - 2007-02-03 16:37:22
Attachments:
signature.asc
|
King Ho wrote: > The attached patch, against trunk, will add a shutdown() method to > AsteriskServer which will in turn shutdown the threads in > ManagerEventListenerProxy if necessary. You can use it however you like= or > to throw it away if you don't like it;) thanks for the patch! I've applied it as provided. =3DStefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: ste...@re... Jabber: ste...@re... |
|
From: Gaetan M. <gm...@ea...> - 2007-01-28 15:32:26
|
Hi Stefan > If we prevent the manager connection from being set multiple times then > we could modify initializeIfNeeded to check if we already set an event > listener and only add if thats not the case. > Does this help? > Just tested, it works. Thank you ! > Changes are at > http://fe.reucon.net/fisheye/changelog/repos/?cs=597 > > I get access denied. Gaetan |
|
From: Gaetan M. <gm...@ea...> - 2007-01-28 15:37:29
|
>> However when the connection times out and reconnects, it is logged to
>> INFO. Shouldn't it be better to log to the WARN cat instead ?
>>
>
> can you point me to the code that logs the message you want to have
> issued as warning?
>
>
It's when you handle the IOException :
ManagerReaderImpl [INFO] Terminating reader thread: Read timed out
ManagerConnectionImpl [INFO] Closing socket.
In current svn trunk it is ManagerReaderImpl.java line 292:
catch (IOException e)
{
this.terminationException = e;
this.dead = true;
logger.info("Terminating reader thread: " + e.getMessage());
}
Gaetan
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X