DBget AMI command is unusable
Reported by dimas | September 10th, 2009 @ 09:19 AM | in 0.8.5
There are two problems actually:
#1 If you using AMI to execure DBget command, you will quickly find that when you attempt to get nonexistent key, Adhearsion will raise an exception:
/usr/lib/ruby/gems/1.8/gems/adhearsion-0.8.2/lib/adhearsion/voip/asterisk/manager_interface.rb:288:in `send_action': Database entry not found (Adhearsion::VoIP::Asterisk::Manager::ManagerInterfaceError)
I do not think is is the good thing - ideally get/put wrappers with get returning nil in this case would do better.
#2 When
you ty to catch and handle the exception yourself you will receive
error messages on the next attempt to use the same connection. The
example below: 1. puts Conference/36/Locked value
2. gets non-existent Conference/XXX/Locked tying to handle
exception
3. then gets existing Conference/36/Locked put on the first
step
resp = ami.send_action "DBPut", :Family => "Conference", :Key => "36/Locked", :Value => "1"
begin
resp = ami.send_action "DBGet", :Family => "Conference", :Key => "XXX/Locked"
puts resp.text_body
rescue Exception => e
p "ERROR"
end
resp = ami.send_action "DBGet", :Family => "Conference", :Key => "36/Locked"
puts resp.text_body
When run, last DBGet (after handling failure of previous get) produces:
ERROR ami: Got an unexpected event on actions socket! This may be a bug! #<Adhearsion::VoIP::Asterisk::Manager::ManagerInterfaceEvent:0xb7bf252c @name="DBGetResponse", @headers={"Val"=>"", "Family"=>"Conference", "Key"=>"36/Locked", "ActionID"=>"PeDPi74q-GqJ6-LoXY-k771-7BkI7ckVVqdz"}>
Comments and changes to this ticket
-
Jay Phillips November 14th, 2009 @ 02:32 PM
- State changed from new to open
- Tag set to ami
Try adding this to startup.rb:
Adhearsion::VoIP::Asterisk::ManagerInterface::CAUSAL_EVENT_NAMES << "dbget"
Does that fix the error?
-
dimas November 15th, 2009 @ 08:29 AM
Either I'm doing something wrong or it does not help.
Here is the test codeAdhearsion::VoIP::Asterisk::Manager::ManagerInterface::CAUSAL_EVENT_NAMES << "dbget" resp = ami.send_action "DBPut", :Family => "Conference", :Key => "36/Locked", :Value => "1" resp = ami.send_action "DBGet", :Family => "Conference", :Key => "36/Locked" p "1: #{resp.text_body}" begin resp = ami.send_action "DBGet", :Family => "Conference", :Key => "XXX/Locked" p "2: #{resp.text_body}" rescue Exception => e p "ERROR" end resp = ami.send_action "DBGet", :Family => "Conference", :Key => "36/Locked" p "3: #{resp.text_body}" p "done"
it just hangs.
-
Ben Klang July 29th, 2010 @ 11:27 AM
- Assigned user changed from Jay Phillips to Ben Klang
- Milestone order changed from 0 to 0
The hang is because Causal Events need a terminator defined. I will research this AMI command and see what the proper terminator needs to be.
-
Ben Klang July 29th, 2010 @ 08:12 PM
- State changed from open to fixcommitted
- Milestone set to 0.8.5
- Milestone order changed from 3023 to 0
This one turned out to be quite tricky. There were several problems:
1) For whatever reason, DBGet's return syntax requires causal event processing (though theoretically it should not need that).
2) The DBGet command never returns a causal event terminator, disobeying Asterisk's AMI syntax (though this is fixed in Asterisk's SVN trunk and will be a part of the upcoming 1.8 release).
3) To make things more complicated, if a database entry is nonexistant, AMI returns a Result: Error, which Adhearsion translates into an AsteriskManagerError, which is itself a subclass of Exception. However, subclasses of Exception are not caught by bare "rescue" statements; only StandardError and its subclasses are caught. This could result in the dialplan thread silently dying when trying to DBGet a non-existant entry.
To the original reporter's first point above, it would be nice if we had a get/set wrapper around DBGet/DBSet. However, I'm going to defer that decision until we decide how to abstract AMI with the upcoming 0.9.0 changes. In the meantime, make sure you wrap all DBGet commands in a begin/rescue block.
The original reporter's second point is fixed completely.
Feedback on how this fix works would be appreciated.
- 84e492e (1 files in 1 dirs): Fix handling of DBGet via AMI [#82 state:fixcommitted] - http://bit.ly/bawo0f
-
Ben Klang August 24th, 2010 @ 01:56 PM
- State changed from fixcommitted to resolved
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
People watching this ticket
Tags
Referenced by
- 85 AMI fails to parse events if colon is contained anywhere in data Jay, what are you plans on releasing the new version time...
- 82 DBget AMI command is unusable 84e492e (1 files in 1 dirs): Fix handling of DBGet via AM...