QueueMetrics > Running QueueMetrics

12.5.1 'Close Call' Feature creates exception error

(1/2) > >>

davissteve80:
We've only run QM 12.5.1, so I can't say if this is a new problem, configuration issue, or bug.

When we try to close a call that we didn't capture the COMPLETECALLER event (usually due to a Asterisk issue) by using the 'scissors' icon 'Close Call' feature, we have allways seen an java exception error thrown:

From this mornings testing:

INFO: Jul 30, 2012 8:39:30 AM org.apache.catalina.core.ApplicationContext log
INFO: LowayTransactionController: [752C41D7A3D5B4AC9DEEDA86CB3996ED] [ERR] Error (tech) in class 'it.loway.app.queuemetrics.callListen.closeCallEffettua'. -- Inner Exception --
Exception: it.loway.tpf.common.exceptions.TechException

In my thinking the error is in the SQL query that QM makes:
When running:  SELECT time_id, LCase(verb),  queue, agent, data1   FROM queue_log   WHERE  = 'P001' AND call_id = 'XXXXXX-1342622728.51969'     AND verb IN ( 'ENTERQUEUE', 'CONNECT', 'COMPLETEAGENT', 'COMPLETECALLER', 'ABANDON' )   ORDER BY time_id DESC


There seems to be a missing argument for 'PARTITION' (ie: should have WHERE partition = 'P001' .... ) --

We run a clustered asterisk topology. each server's queue_log is handled by a qloader instance, each instance uses a unique partition name, P001,P002,etc.

I've been working around this issue by doing direct editing of the queu_log table and pruning calls where this event occurs. It's not very often, but I'd prefer to do it with the proper tool.

Any help or insight would be appreciated.



QueueMetrics:
This looks like a bug - it would be helpful if you could send to Loway Support your configuration.properties file referring to bug #1670.

marcos:
Hi.

Could you, please, post the value associated to the key:

sqlPreset.1.f_partition

in the configuration.properties file?

Looking at the error seems that the SQL statement is missing the name of the field used to store the partition. As you suggested it should be something similar to "WHERE partition = 'P001'". The field name is stored on the key sqlPreset.1.f_partition.

davissteve80:
Sorry all,

Was on vacation and didn't think to check this forum after my return.

re: sqlPreset.1.f_partition

Currently it is set as null (specifically: sqlPreset.1.f_partition= )

However, I have tried to change this, as my thinking was the same as your's marcos. I'll have to re-run the tests, as I don't have the specific output. But changing the value to match the column name 'partition' it did not correct the error. And if my memory serves, it generated a totally different error.


re: bug #1670

Could you direct me to an address to submit the file contents to. I'd rather not post it, as it does contain site specific data that I wouldn't want public. If sanitizing it wouldn't effect your troubleshooting, I could do that.


Thanks for the input.

Steven

davissteve80:
Well, marcos, you appear to have called it.

By changing the column name, the issues is resolved.

I did find my notes, and I think I was changing one of the other presets, rather than sqlPreset.1.f

With the proper settings, it seems to work properly on our test server.

Will roll the changes into our production environment and see where we stand.

Thanks again.

Navigation

[0] Message Index

[#] Next page

Go to full version