vicidial.org

Hello alls,
i'm wondering , how vicidial manage this scenario:

When there are some 'ANYONE' callbacks with 'LIVE' status that (normally) are into the hopper list,
an then the system is rebooted, when vicidial starts, the hopper list is deleted, the
status of that callbacks remains marked as 'LIVE' , but they never will be called ,
becouse AST_VDhopper.pl only fill the hopper list with callbacks when it change the status from ACTIVE to LIVE..

Can anyone tell me if this is correct .

Thanks, and sorry about my bad english.

1) Welcome to the Party!

2) when you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.

this IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) Please test this (with the latest SVN, of course, to be sure you are up to date...). I've not had a complaint from a client on this topic, so perhaps you are mistaken. But certainly worth checking to see.

Hello , I'm reading the code of the latest sources and older sources 2.4xxx,
and still havent found , the place where the system fill the hopper with these
callbacks (marked as LIVE before the system reboot) again, so I think
never ever will be called.

I want know if this callback treatment is a feature or a bug, or if there is
some place in the system that manage this 'losts after reboot live callbacks'

Thanks.

Please state specifically whether you have tested this and exactly what the result was ...

It may be necessary to put these entries in a special table and check against that table at reboot.

Sorry, I don't know how explain the situation clearly:
I saw a lot of callbacks on the hopper , then i reboot the machine , I saw the same
hopper and the callbacks and they aren't there...., the rows in the vicidial_callbacks table
are still there, with status marked as 'LIVE' , the rows in vicidial_list table are still there
, with status marked as 'CALLBK' , but althougth the programed time is past, never went
another time on the hopper.
The callbacks are ONLY filled into the hopper, when are modified from ACTIVE to LIVE,
if the hopper is emptied, by a reboot b.e. , the callbacks who were deleted from hopper, never will be putted
on the hopper, becouse they are already marked as LIVE.

Below I paste the piece of the source (AST_VDhopper.pl) where the hopper is filled with the callbacks (anynone),
The callbacks,
....
$stmtA = "SELECT vicidial_callbacks.lead_id,recipient,campaign_id,vicidial_callbacks.list_id,gmt_offset_now,state,vicidial_callbacks.lead_status,vendor_lead_code
FROM vicidial_callbacks,vicidial_list where callback_time <= '$now_date' and vicidial_callbacks.status='ACTIVE' and vicidial_callbacks.lead_id=vicidial_list.lead_id;";
....
while ($sthArows > $cbc)
...
if ( ($cba > 0) && ($insert_auto_CB_to_hopper) ) {
$stmtA = "UPDATE vicidial_callbacks set status='LIVE' where lead_id IN($update_leads) and status NOT IN('INACTIVE','DEAD','ARCHIVE');";
....
foreach(@CA_lead_id) {
$stmtA = "UPDATE vicidial_list set status='$CA_status[$CAu]', called_since_last_reset='N' where lead_id='$CA_lead_id[$CAu]';";
(in older versions, status always is set to 'CALLBK' )
$stmtA = "INSERT INTO $vicidial_hopper SET lead_id='$CA_lead_id[$CAu]',campaign_id='$CA_campaign_id[$CAu]',list_id='$CA_list_id[$CAu]',gmt_offset_now='$CA_gmt_offset_now[$CAu]',user='',state='$CA_state[$CAu]',priority='50',source='C',vendor_lead_code='$CA_vendor_lead_code[$cba]';";
....
}

.....
}
....

May be, a solution is that when the machine starts , after the hopper is deleted, mark as ACTIVE
all the callbacks that are marked as LIVE (and also may be marked as CALLBK in the list).
Or before the hopper is deleted, by the booting process or the reload hopper action, mark as ACTIVE all
the callbacks that are into it and was previusly marked as LIVE.


Thanks.



....

I thought it was suppose to work like that I use it as a function,
if there's complains about callbacks that the agents don't want (yeah strange i know) then i just reset the hopper and everyone's happy.
I got other scripts to take care of the leads so they wont be stuck in the twilight zone forever.

but the reason they are removed from the hopper after a reboot is because the table vicidial_hopper is a memory-type table

Although the hopper table were MyiSAM/InnoDB.. , or another kind, there is
a call in the file /etc/init.d/vicidial to $VICI_DIR/AST_reset_mysql_vars.pl
who has various sql sentences, one of them to delete the hopper:

$stmtA = "DELETE from vicidial_hopper where user LIKE \"%_$server_ip\";";


Only want to know it this way the system work its the right way, that
developers whised for the system, or if its a Use Case that was missed...
or there is another place in the system that put on again this callbacks.

I dont like this behaviour, but other people maybe yes, "about likes, colours"

you could write a script to preserve the hopper at shutdown, and reload the same values after startup (or at least those that are callbacks ...).

you're right, AST_reset_mysql_vars.pl will delete the hopper on boot, I didnt know about that.

guillecs wrote:Only want to know it this way the system work its the right way, that
developers whised for the system, or if its a Use Case that was missed...
or there is another place in the system that put on again this callbacks.

I would also like to know about this.

Based on guillecs tests, I'd say yes. And it'll likely stay that way until someone posts a DIFF with a solution or pays someone else to fix it.