Messages

1

Improving QueueMetrics / Re: Checks on Add Member

« on: February 01, 2012, 17:31:29 »

I've run into this very thing, and the default extension poplating only works if users don't hotdesk.  In the case of users who change desks, and extensions, a default extension results in agents joining a queue from the wrong extension, and calls are then routed and unanswered affecting queue times.

2

Improving QueueMetrics / Re: Improvement: Input Vailidation

« on: February 01, 2012, 17:29:50 »

For some of the items, a customization may be more appropriate.  The one area where I disagree is the input validation.  To me it's a bug that a space can be entered under extension and have that extension and white space placed in the queue exactly as typed.  This prevents somebody from removing member due to the unknown space...

3

Improving QueueMetrics / Improvement: Input Vailidation

« on: January 25, 2012, 21:52:30 »

If this is already addressed somewhere, please disregard.  I originally posted this is another topic but figured this was the more appropriate location.  Thanks!

Here's are the scenarios:

Scenario A:  Agent A logs into the Webui and runs "Add Member" for their appropriate queue.  In the process, not paying attention, they enter their numeric password under "Extension" rather then their current extension, or they have a typo in their extension (ie. ext 2105 gets entered as 2015).  Queue metrics accepts this information and adds the bogus extension to the provided queue.

Scenario B: Agent A logs into the Webui and runs "Add Member" for their appropriate queue.  In the process, they have a typo in the extension number which happens to coincide with the active extension of Agent B in a different queue.  Agent B then starts receiving calls for a queue that they aren't a functional member of.

Scenario C: Agent A logs into the Webui and runs "Add Member" for their appropriate queue.  In the process, they inadvertently add a space following their extension number.  Calls are successfully routed to the correct destination.  At the end of the Agent's shift, they initiate a remove member, but this time they enter in the correct extension without the white space.  The Remove Member isn't successful unless they add the extra white space entered during the Add Member.

Requests:

Scenario A: I'd like to see extension validation to confirm the extension entered actually exists on the PBX.
Scenario B: I'd like to see an error occur when an agent attempts to log into an extension already in a queue under another Agent's name.
Scenario C: It looks like improved input sanitation is required.

Mike.

4

Running QueueMetrics / Agents logging in with wrong extension

« on: November 16, 2011, 20:27:19 »

Hi,

My organization really appreciates Queue Metrics for the most part but we have some behavioral issues that we're trying to address which I believe could be easily addressed with some error checking in Queue Metrics.  I'm hoping it's already capable but not enabled in our installation. 

Here's are the scenarios:

Scenario A:  Agent A logs into the Webui and runs "Add Member" for their appropriate queue.  In the process, not paying attention, they enter their numeric password under "Extension" rather then their current extension, or they have a typo in their extension (ie. ext 2105 gets entered as 2015).  Queue metrics accepts this information and adds the bogus extension to the provided queue resulting in high wait times and an agent not taking calls.

Scenario B: Agent A logs into the Webui and runs "Add Member" for their appropriate queue.  In the process, they have a typo in the extension number which happens to coincide with the active extension of Agent B in a different queue.  Agent B then starts receiving calls for a queue that they aren't a functional member of.

Here are my requests:

Scenario A: is there a way to confirm the extension being entered is an invalid extension and prevent it from being added to the queue?
Scenario B: is there a way to confirm that the extension provided is in use elsewhere and prevent it from being added to the queue until it's otherwise removed from use?

As an FYI, we are using hot desking.  Let me know if this isn't clear enough and I'll clarify as needed.  Thanks in advance!

Mike.

5

Running QueueMetrics / Re: QM 1.7.1 Froze Today

« on: October 15, 2011, 00:57:45 »

For anybody who might find this post useful, here's the latest update.  I made the changes referenced above.  The first attempt used 2048, and I found that java would start, but queuemetrics itself wouldn't actually start up.  I then tweaked it down to 1024, and the service restarted and came up without problems.  I'm still open to any feedback regarding potential negative impact from this change.  Thanks again!

6

Running QueueMetrics / Re: QM 1.7.1 Froze Today

« on: October 14, 2011, 23:44:46 »

I've decided to take the following approach:

modify /etc/init.d/queuemetrics as follows:

Change:
JAVA_OPTS="-Xms128M -Xmx128M"

To:
JAVA_OPTS="-Xms2048M -Xmx2048M"

We have 18G of memory on the box.  Any thoughts against this?

7

Running QueueMetrics / Re: QM 1.7.1 Froze Today

« on: October 14, 2011, 23:23:42 »

I've some serious grep filtering, I did find the following occurring just prior to both outages:

2011-10-14 14:41:20 StandardContext[/queuemetrics]LowayTransactionController: [B969035C65C58DC6347643DFCDAA22E0] [ERR] -- Inner Exception --
Exception: java.lang.OutOfMemoryError
Error:
Java heap spaceStack trace:
java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:2882)
        at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
        at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
        at java.lang.StringBuilder.append(StringBuilder.java:119)
        at java.io.UnixFileSystem.resolve(UnixFileSystem.java:93)
        at java.io.File.<init>(File.java:207)
        at java.io.File.listFiles(File.java:1056)
        at it.loway.app.queuemetrics.callListen.listeners.PluggableListener.listFiles(PluggableListener.java:81)
        at it.loway.app.queuemetrics.callListen.listeners.PluggableListener.listFiles(PluggableListener.java:99)
        at it.loway.app.queuemetrics.callListen.listeners.LocalFiles.search(LocalFiles.java:81)
        at it.loway.app.queuemetrics.callListen.listeners.LocalFiles.isCallPresent(LocalFiles.java:29)
        at it.loway.app.queuemetrics.callListen.searchAudioFiles.doRun(searchAudioFiles.java:107)
        at it.loway.tpf.transaction.servlets.LowayTransactionController.runVerb(LowayTransactionController.java:262)
        at it.loway.tpf.transaction.servlets.LowayTransactionController.serveRequest(LowayTransactionController.java:552)
        at it.loway.tpf.transaction.servlets.LowayTransactionController.serveRequestWrapper(LowayTransactionController.java:373)
        at it.loway.tpf.transaction.servlets.LowayTransactionController.doGet(LowayTransactionController.java:217)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
-- End Inner Exception --

I know the memory settings can be modified in tomcat, any suggestions where I can modify them and to what I should change them?  Thanks!

8

Running QueueMetrics / QM 1.7.1 Froze Today

« on: October 14, 2011, 23:10:58 »

Hi,

My organization recently transitioned to an Asterisk/Queue Metrics solution for phones and call center services.  The systems have been in place for about two months now.  We've had repeated issues with our Asterisk servers, but our Queue Metrics server have had zero problems until today.

I got a call this morning that Agents couldn't log in, pause unpause, add or remove member etc.  When I attempted to browse to the webui, I found it non-responsive.  The server doesn't provide an error, it simply doesn't respond at all.  This happened again about twenty minutes ago.  The services are restored with a "service queuemetrics restart."  I'm attempting to review the logs in /usr/local/queuemetrics/tomcat/logs but it's challenging to sift through all of extra information tomcat is spitting into the logs.  I'm not thoroughly trained on Queue Metrics, having hired an integrator to install it and not having time to get up to speed as of yet.  I'm hoping somebody on the forum might be able to point me in the right direct.  Here are some details:

This is an HA cluster using heartbeat for resource management, and DRBD for distributed storage.

QM: 1.7.1
OS Platform: PBX In a Flash, Purple, with Queue Metrics installed over top
Heartbeat: 2.1.4
DRBD: 8.3.8

Can anybody recommend where I might start to determine why it's all of a sudden freezing?  No changes have been made to the queue metrics boxes recently with the exception of additional agents added etc.  Thanks in advance for any suggestions and help!

Mike.