Receiving emails pauses agents

[ClearCall]

I upgraded svn today but behavior existed previously with specs in signature.
I have two IMAP email accounts and one POP3 email account.
Each email account is set to a different list.
All three email accounts are handled by the same email in-group.
The two IMAP accounts are Gmail.
When an email is received for any of the IMAP accounts it is sent to agentA and agentB appears in the Real-Time Report as mqueue and gets stuck in that status and has to log out and log back in.
The emails received on the POP3 account do not cause any problems.

Please advise.

[mflorell]

Very strange, we were actually testing agent calls with Gmail IMAP this week and had no problems. Might be a combination of settings that is causing the issues. We were actually fixing a bug related to email that would show the Customer Gone screen when an email came in. That fix should be applied to svn/trunk after we are finished with some code review on a rather large new feature.

[ClearCall]

In further testing it seems the problem does occur also with the POP3 account.
I have my Next Agent Email: set to longest_wait_time. The agent with the longest wait time goes into mqueue and gets stuck there and the agent with the next longest wait time gets the email.
If there is only 1 agent 'Available' there doesn't seem to be any problem.

[ClearCall]

VD_email_inbound.pl has code to assign a specific email to a specific user then change that user from available or closer to 'MQUEUE':
update vicidial_email_list set status='QUEUE', user='$user' where email_row_id='$email_row_id'
update vicidial_live_agents set status='MQUEUE' where user='$user'

vdc_db_query has code to check vicidial_email_list for emails set as 'QUEUE'
select lead_id, email_date, email_to, email_from, subject, group_id, email_row_id from vicidial_email_list where status='QUEUE' and direction='INBOUND' and user='$user' and group_id in ($email_group_str) order by email_date asc

vdc_email_display has code to check for any new emails
if ($lead_id)
select * from vicidial_email_list where lead_id='$lead_id' and direction='INBOUND' and status IN('NEW','INCALL') order by email_date asc

I'm wondering if there is not a timing issue somewhere that the longest waiting agent is set to not available so he can receive the email then before that email is sent to his screen another process sends it to an agent that is available. The intended agent then stays is MQUEUE because the email he is waiting for has been assigned to someone else.

[ClearCall]

I removed 'E' from /etc/astguiclient.conf and restarted the machine. I verified that VD_email_inbound.pl was not running in running processes.
I sent a test email.
AST_inbound_email_parser ran and retrieved the email.
An agent received the email through the agent interface. No other agent got stuck in MQUEUE.

Obviously some other process is sending emails to agents and it is conflicting with VD_email_inbound. I am leaving the 'E' out of the astguiclient.conf. I will open a ticket in the tracker.

[williamconley]

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

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) Would be kinda cool to know if you have a cluster ...?

[ClearCall]

The problem was a backup DB machine that had E keepalive for some reason.

[williamconley]

Installer was a bit rambunctious with the "duplicate it!" process. LOL

None of the scripts should be active on the backup DB server until the primary "goes down" of course.