Show Posts
1
General Asterisk configuration / Re: "Agent status cannot be determined" on agent screen
« on: September 30, 2008, 18:12:45 »
Ok, we have discovered what appears to be two related issues.
1. "max_bytes_agent" parameter is supposed to, while in database access mode, control the where clause for the time window to retrieve queue_log records from. It does do that. However, additionally, the temp file that is generated off this query (that is then java class filtered for agent portal display) is also byte restricted by the same parameter. This is a problem since in order to process enough temp result file (in our case) you need to increase the parameter up to ~2,000,000. (2MB of temp file parsed). However, this then also affects the database retreival in giving 23 days worth of activity even if you just are processing the first 2MB worth. To fix this, the DB retreival window (in seconds) should be a separate parameter from the temporary results file parsing (in bytes).
2. The database retreival query is not optimal. It spools all records including ACD RINGNOANSWER rows, of which we have a large amount of, and are not revelant to this query. Currently, we have had to modify the qloader to post RINGNOANSWER rows to another partition just so that we get something byte short enough to process (for problem #1 above). Even if #1 above is fixed, the query time, java class temp file filtering is a tiny fraction of processing by making this query specific to the login.
Fix number #1 above would allows us to process 1 day (instead of 23 days) worth of records to assertain statuses and calls for the portal. Fix #2 above allows the portal to process a few K worth of agent specific records instead of many many MB of records for a whole day of non-relevant records (once we cut the ACD record back to the proper partition). In effect, if #1 is fixed and the parameters separated, without #2, we would need to put the DB windowing to 86400 secs (1 day) and the byte filtering to ~50MB
once we cut the RINGNOANSWER back.
Thanks for your help!
1. "max_bytes_agent" parameter is supposed to, while in database access mode, control the where clause for the time window to retrieve queue_log records from. It does do that. However, additionally, the temp file that is generated off this query (that is then java class filtered for agent portal display) is also byte restricted by the same parameter. This is a problem since in order to process enough temp result file (in our case) you need to increase the parameter up to ~2,000,000. (2MB of temp file parsed). However, this then also affects the database retreival in giving 23 days worth of activity even if you just are processing the first 2MB worth. To fix this, the DB retreival window (in seconds) should be a separate parameter from the temporary results file parsing (in bytes).
2. The database retreival query is not optimal. It spools all records including ACD RINGNOANSWER rows, of which we have a large amount of, and are not revelant to this query. Currently, we have had to modify the qloader to post RINGNOANSWER rows to another partition just so that we get something byte short enough to process (for problem #1 above). Even if #1 above is fixed, the query time, java class temp file filtering is a tiny fraction of processing by making this query specific to the login.
Fix number #1 above would allows us to process 1 day (instead of 23 days) worth of records to assertain statuses and calls for the portal. Fix #2 above allows the portal to process a few K worth of agent specific records instead of many many MB of records for a whole day of non-relevant records (once we cut the ACD record back to the proper partition). In effect, if #1 is fixed and the parameters separated, without #2, we would need to put the DB windowing to 86400 secs (1 day) and the byte filtering to ~50MB
once we cut the RINGNOANSWER back.Thanks for your help!