Re: [Asterisk-java-users] ManagerReader Interrupt

[Stefan R. <sr...@re...>]

Interrupting the calling thread is probably a bug...
Would changing this stuff to use notify help?

King Ho wrote:
> I think I have also been bitten by this stray "interrupt" but I have no=
t gone so far as to track down where it was thrown.=20
>=20
> I was having a queue.take() waiting for commands to send to the Asteris=
k but it was being interrupted all the time :(  =20
>=20
> I have since changed to starting a new thread for each command to send =
to Asterisk instead. I think this has the added benefit that a stuck conn=
ection will not hang the whole program.
>=20
> King
>=20
> -----Original Message-----
> From: ast...@li... [mailto:asterisk-=
jav...@li...] On Behalf Of Brett Sutton
> Sent: Saturday, March 04, 2006 7:19 PM
> To: ast...@li...
> Subject: [Asterisk-java-users] ManagerReader Interrupt
>=20
> I believe that there is a bug in the=20
> DefaultManagerConnection.sendAction(ManagerAction action, long timeout)=
=20
> method.
>=20
> The problem is with the creation of the ResponseHandlerResult.
>=20
> The ResponseHandlerResult calls thread.interrupt to wake up the thread =

> which called sendAction. Thats fine, the problem begins when the=20
> sendAction returns (with or without a response).
> Calling Thread.interupt leaves the thread in an interrupted state until=
=20
> some method (such as sleep) checks the threads interrupt state at which=
=20
> point the interrupt state is cleared.
> The problem occurs if the call to interrupt is made when sendAction is =

> not currently sleeping. There are numerous ways in which this can happe=
n.
> The impact on sendAction is zero. However if an application then calls =
a=20
> method such as Thread.sleep or Queue.take the method call will=20
> immediately throw an Interrupted exception as the thread is still in an=
=20
> interrupted state.
>=20
> I believe a better way of dealing with this problem is to use=20
> Object.wait(x) and Object.notify. For the purposes of sendAction the=20
> affects are identical without the nasty side effects of calling interru=
pt.
>=20
> I hope this makes some sense.
>=20
> Regards,
> Brett.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> that extends applications into web and mobile media. Attend the live we=
bcast
> and join the prime developer group breaking into this new coding territ=
ory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Asterisk-java-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-users
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> that extends applications into web and mobile media. Attend the live we=
bcast
> and join the prime developer group breaking into this new coding territ=
ory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Asterisk-java-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-users


--=20
reuter network consulting
Neusser Str. 110
50760 K=C3=B6ln
Germany
Telefon: +49 221 1305699-0
Telefax: +49 221 1305699-90
E-Mail:  sr...@re...
Jabber:  sr...@ja...