Thread: [Asterisk-java-users] getChannelByName returning an old hungup channel instead of the current one
Brought to you by:
srt
Menu
▾
▴
asterisk-java-users
|
From: Gaetan M. <gm...@ea...> - 2007-03-16 12:53:16
|
Hi I ran across a problem with getChannelByName in AsteriskServerImpl (and ChannelManager.getChannelImplByName). Indeed sometimes it returns and old HUNGUP channel that has not yet been purged (< 15 min) of the channels list. With SIP channels it is very infrequent as there is a session ID (4 or more alpha chars) in the channel name so there is room before we get another channel with the same name in the 15 min interval, but for Zap channels it is more frequent as there is no session ID added to the name so we may have more than one channel with the same name (one active and several old ones that are hung up). Most of the library internal code calls getChannelImplById not ByName, but with queues and parked calls events we only have a channel name in the event, not the Id (unless bristuffed version), and so we must find it by name; Should this be considered as a bug ? Gaetan |
|
From: Stefan R. <ste...@re...> - 2007-03-16 13:23:56
Attachments:
signature.asc
|
Hi, can you provide some more information detailing what problems this behavior causes for you? The reason for the channels not being purged immediately is that in some cases you want to lookup a channel to access its history even if it has been hung up therefore the 15 minutes delay. =3DStefan Gaetan Minet wrote: > Hi >=20 > I ran across a problem with getChannelByName in AsteriskServerImpl (and= > ChannelManager.getChannelImplByName). Indeed sometimes it returns and > old HUNGUP channel that has not yet been purged (< 15 min) of the > channels list. >=20 > With SIP channels it is very infrequent as there is a session ID (4 or > more alpha chars) in the channel name so there is room before we get > another channel with the same name in the 15 min interval, > but for Zap channels it is more frequent as there is no session ID adde= d > to the name so we may have more than one channel with the same name (on= e > active and several old ones that are hung up). >=20 > Most of the library internal code calls getChannelImplById not ByName, > but with queues and parked calls events we only have a channel name in > the event, not the Id (unless bristuffed version), and so we must find > it by name; > Should this be considered as a bug ? >=20 >=20 >=20 > Gaetan >=20 > -----------------------------------------------------------------------= -- > 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Asterisk-java-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/asterisk-java-users --=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... Steuernummern 215/5140/1791 USt-IdNr. DE220701760 |
|
From: Gaetan M. <gm...@ea...> - 2007-03-16 14:20:10
|
Hi Stefan
Indeed the channel cannot be purged immediately for history. I just
implemented a "getActiveChannelByName()" that excludes hungup channel
while cycling through the list (but of course doesn't modify the list in
ChannelManager)
The king of problem I experienced is for example:
1/ Someone calls in through Zap/1-1. The call ends normally. The channel
remains as hung up in the list for 15 mins.
2/ Someone calls in again through Zap/1-1 and goes to a queue.
3/ I receive a Queue event in which the channel specified is Zap/1-1. I
have no uniqueId in those events so I have to use the name.
4/ I call AsteriskServer.getChannelByName("Zap/1-1");
and it returns the first old one that is hung up, not the new one.
The same applies with park related events for example. I guess the same
kind of problem should happen for the MeetMeManager is it uses getByName.
Also, this can be problematic if someone uses getChannelByName and
expects it to return null if there is no such channel in asterisk at
this moment ("Is my zap line free ?").
Gaetan
Stefan Reuter wrote:
> Hi,
>
> can you provide some more information detailing what problems this
> behavior causes for you?
> The reason for the channels not being purged immediately is that in some
> cases you want to lookup a channel to access its history even if it has
> been hung up therefore the 15 minutes delay.
>
> =Stefan
>
>
> Gaetan Minet wrote:
>
>> Hi
>>
>> I ran across a problem with getChannelByName in AsteriskServerImpl (and
>> ChannelManager.getChannelImplByName). Indeed sometimes it returns and
>> old HUNGUP channel that has not yet been purged (< 15 min) of the
>> channels list.
>>
>> With SIP channels it is very infrequent as there is a session ID (4 or
>> more alpha chars) in the channel name so there is room before we get
>> another channel with the same name in the 15 min interval,
>> but for Zap channels it is more frequent as there is no session ID added
>> to the name so we may have more than one channel with the same name (one
>> active and several old ones that are hung up).
>>
>> Most of the library internal code calls getChannelImplById not ByName,
>> but with queues and parked calls events we only have a channel name in
>> the event, not the Id (unless bristuffed version), and so we must find
>> it by name;
>> Should this be considered as a bug ?
>>
>>
>>
>> Gaetan
>>
>> -------------------------------------------------------------------------
>> 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
>>
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>
|
|
From: Stefan R. <ste...@re...> - 2007-03-16 14:33:21
Attachments:
signature.asc
|
Gaetan Minet wrote:
> 4/ I call AsteriskServer.getChannelByName("Zap/1-1");
>=20
> and it returns the first old one that is hung up, not the new one.
I would consider this a bug. getChannelByName() should return the newest
channel matching the given name. The fix for this would also require
updating the javadoc to clearly define what is actually returned.
> The same applies with park related events for example. I guess the same=
> kind of problem should happen for the MeetMeManager is it uses getByNam=
e.
Indeed. Though the real fix would be to provide some patches for
Asterisk to include the uniqueId in these events which should be a
one-liner. Nevertheless this would not solve our problem as we have to
take older versions of Asterisk into account.
> Also, this can be problematic if someone uses getChannelByName and
> expects it to return null if there is no such channel in asterisk at
> this moment ("Is my zap line free ?").
This could also be resolved by checking for null and an isActive()
method on AsteriskChannel (not sure if its already implemented).
Would you like to submit a patch for this issue?
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...
Steuernummern 215/5140/1791 USt-IdNr. DE220701760
|
|
From: Gaetan M. <gm...@ea...> - 2007-03-16 15:06:17
|
> Indeed. Though the real fix would be to provide some patches for
> Asterisk to include the uniqueId in these events which should be a
> one-liner. Nevertheless this would not solve our problem as we have to
> take older versions of Asterisk into account.
>
This is actually exactly what happened to me. I was working with a
bristuffed 1.2.9 that includes uniqueid in all those events and my
queue/parking manager worked ok.
Then I have had to jump to a non bristuffed 1.2.12 that only has the
channel name and started experiencing weird channels and NPEs (linked
channel of an hung up channel is null...)
>> Also, this can be problematic if someone uses getChannelByName and
>> expects it to return null if there is no such channel in asterisk at
>> this moment ("Is my zap line free ?").
>>
>
> This could also be resolved by checking for null and an isActive()
> method on AsteriskChannel (not sure if its already implemented).
>
Then we'll have boiler code in every call such as
if (chan == null || ! chan.isActive())
unless well announced and documented this will be a frequent mistake
among users I think.
In that case, we should also return the most recent hung up channel,
isn't it ?
> Would you like to submit a patch for this issue?
>
Ok I'll update my trunk and try the fix asap.
> Thanks,
>
> =Stefan
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>
|
|
From: Stefan R. <ste...@re...> - 2007-03-16 15:44:28
Attachments:
signature.asc
|
Gaetan Minet wrote: > This is actually exactly what happened to me. I was working with a > bristuffed 1.2.9 that includes uniqueid in all those events and my > queue/parking manager worked ok. > Then I have had to jump to a non bristuffed 1.2.12 that only has the > channel name and started experiencing weird channels and NPEs (linked > channel of an hung up channel is null...) I hope I don't have such issues in my code as I am also using bristuffed Asterisks most of the time. > Then we'll have boiler code in every call such as > if (chan =3D=3D null || ! chan.isActive()) > unless well announced and documented this will be a frequent mistake > among users I think. Yes you are right, this is error prone. So we sould either use your getActiveChannelByName or an explicit isChannelAvailable() method. > In that case, we should also return the most recent hung up channel, > isn't it ? Yes, probably just by looking at the date the channel was created which should work in both cases. >> Would you like to submit a patch for this issue? >> =20 > Ok I'll update my trunk and try the fix asap. That's great. =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... Steuernummern 215/5140/1791 USt-IdNr. DE220701760 |
×
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