Summary:ASTERISK-08603: [patch] In Realtime Queues, dynamic queue members do not always load the members correctly
Reporter:Carl Thorner (cthorner)Labels:
Date Opened:2007-01-18 06:39:59.000-0600Date Closed:2011-06-07 14:07:46
Versions:Frequency of
Environment:Attachments:( 0) 8844-interface.1c.cli
( 1) 8844-interface.1c.log
( 2) app_queue.c.diff-51221-str_interface
Description:With the realtime dynamic queues in app_queues.c the applications makes some assumptions about the format of the member_config structure. This is a problem with some realtime implementations(namely, res_config_ldap.c, res_config_odbc.c, and res_config_pgsql.c). I'm not sure if problem should be fixed here or in the realtime implementations. The uploaded patch for app_queue.c fixes the problem.
Comments:By: Leif Madsen (lmadsen) 2007-01-25 12:03:47.000-0600

Can you explain how to reproduce this? I think I'm a bit confused as to what the real issue is.

I'm using dynamic queues in realtime, and have not found any problems, but would like to confirm this and test your patch.

By: Carl Thorner (cthorner) 2007-01-25 12:56:41.000-0600


Which realtime module are you using? I'm using res_config_ldap.c(still not in trunk) you could also reproduce this with the pgsql and odbc realtime modules. After connecting these you can check and add debug statements to see what the config arrays return to the Queue applications. If you are having problems with any of this, let me know and maybe I can walk you through this live.

By: Leif Madsen (lmadsen) 2007-01-25 13:52:51.000-0600

Are you on IRC? If so, find me in #asterisk-dev. I'm using the res_odbc module.

By: Carl Thorner (cthorner) 2007-01-29 20:13:30.000-0600

Since we are having problems connecting. Here is a little more info:

The problem is that the interface information from queue members does not get loaded properly into asterisk. The patch breaks up this process and makes sure we get the interface string regardless of which realtime module you use.

By: BJ Weschke (bweschke) 2007-02-06 02:02:17.000-0600

cthorner - sorry. I'm with blitzrage on this. Can you provide an specific configuration example of why what's there now doesn't work for you?

By: Carl Thorner (cthorner) 2007-02-08 00:17:10.000-0600

OK, as soon as I get a chance I'll post some logs. I may have it all wrong and I am trying some suggestions we discussed at #asterisk-dev.

By: Carl Thorner (cthorner) 2007-02-09 05:10:37.000-0600

Posted some logs.

Also, I tok another look at the code and I think I was wrong about odbc and pgsql. Although the code structure is similar to res_config_ldap.c, it is different where it matters. Looks like the problem with the app_queue.c code is that it assumes a certain structure for the member_config configuration structure that cannot be guaranteed. More specifically it assumes that the interface is given as the first variable to the structure. We could probably change res_config_ldap.c around to conform to this, but that wouldn't solve it for the next realtime datastore. It might also be that it depends on how you have your configuration file or table set up, which, if that is the case, is not a good solution.

Again, I tested my code without the bug and did not get it working(as shown in the logs). And then with the patch and got it working. For the patch to take effect I had to restart asterisk. A simple reload of the module didn't do the trick.

By: Serge Vecher (serge-v) 2007-03-07 11:47:59.000-0600

BJ, any further comments on this one?

By: Steve Murphy (murf) 2007-03-21 13:51:26

BJ-- Another pesky reminder-- any progress on this bug?

By: Jason Parker (jparker) 2007-07-05 11:51:39

What happens in the case where "interface" is the field used for category?  What happens when it's something like "paused"?

I don't know that this fix is right.

By: jmls (jmls) 2007-09-12 16:38:39

is this resolved by the large changes to app_queue in 1.4 svn ?

By: Mark Michelson (mmichelson) 2007-10-11 17:10:30

After discussing this on IRC with qwell, it seems that this issue is an ldap-only issue. As such, I am closing this and recommending that if the reporter is still having this problem with LDAP, that he let it be known in the res_config_ldap integration issue (ASTERISK-5620)