DBget AMI command is unusable

#82

There are two problems actually:

#1 Missing constants in dialplan raise ambiguous error 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 Remaining references to "helpers" should be cleaned out 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"}>

Reported by dimas · September 10th, 2009 @ 09:19 AM

Activity

Jay Phillips
- 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?
November 14th, 2009 @ 02:32 PM

dimas

Either I'm doing something wrong or it does not help.
Here is the test code


Adhearsion::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.

November 15th, 2009 @ 08:29 AM

Ben Klang
- 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.

July 29th, 2010 @ 11:27 AM
Ben Klang
- 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 DBget AMI command is unusable state:fixcommitted] - http://bit.ly/bawo0f
July 29th, 2010 @ 08:12 PM
Ben Klang
- State changed from fixcommitted to resolved
August 24th, 2010 @ 01:56 PM

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.