Sometimes, the system announces some errors that are displayed on the top right corner of the iAGENT Supervisor header beside the log off button.
These could be:
- CTI Error: The connection to the PBX system was interrupted. Please check the Phone System Plugins and the status of the PBX.
- Runtime Error: This error occurs when an automatic processing on a category has failed (autmatic-closing or -forwarding failed due to any reason).
Inhalt/Content
System Logs and Mails
Indicators for bad system performance or special circumstances are logged and sometimes, an automated information mail will be sent to the corresponding configured email address.
Fail point limit exceeded:
This information announces that specific system actions took longer as expected. It is not necessary to take immediate action. However, if this message comes regularly, the system should be examined for vulnerabilities.
Examples of this would be:
- To high network load / too small bandwidth
- To high database load – maybe caused my multiple reports on the same time
- Not sufficient memory (RAM) on the server / not enough free space on the hard drives of the webserver
- Proxy settings to strict (e.g. Caching, Buffering, Whitelisting)
- Load Balancer not configured correctly
- Disrupted or too long routes from the webserver to the database server / clients
- Virus-Scanner is observing the network traffic (most commonly issue)
- Maximum number of sessions on the webserver to small
- Maximum number of sessions on windows or apache not configured big enough
- ==> All that leads to performance issues and may cause these mails from time to time. Please check the mentioned points from above.
Ticket Cleanup Results
As of iAGENT version 12.6, the system automatically performs cleanups of requests that, due to various circumstances, have entered a state that cannot be corrected manually. The possible error states and the type of correction is explained in the following table. No manual action is required. The information mail is only to inform that the system has made adjustments. The cleanup run takes place 10 minutes after the system restart (routing process) once and then regularly every 24h. Since this run was only introduced with iAGENT version 12.6, it is likely that after updating from a version < 12.6 to >=12.6, this run finds entries for cleanup at the first startup and confirms them with the information mail.
Technical explanation of the cleanup run:
- Ticket cleanup takes place 10 minutes after the routing process starts, and every 24 hours from then on by default.
- The interval is configurable in Routing.conf with archive.ticketCleanup.interval (in hours, minimum 1, maximum 24, with neg. values or 0 the ticket cleanup is completely disabled).
- The delay after startup can also be reduced with archive.ticketCleanup.initialDelay (specify in minutes)
The parameter for the max. ticket age is initially 01/01/1970 – at the end of a run, the date of the last cleaned ticket is written to the ROUTING_CONFIG table with key imail.date.ticketcleanup in the format yyyyMMdd and then used as max. ticket age for the next run. This way, the runtime of the cleanup process is always limited to the amount of tickets of one day only, thus speeding up the process.
There are the following reasons for a ticket purge:
| Logging | Description | Executed cleanup action |
|---|---|---|
| history empty | History of the Ticket-ID was empty | History entry with status ERROR added |
| queue failed | History only has one entry with status RECEIVED (means that this ticket did not reach the queue finally) |
History entry with status ERROR added |
| unsent answered | Latest history entry has the status ANSWERED but ticket status is not equal. (means that this ticket has been put into the outbox but was not sent) |
History entry with status DELETED_ADMIN added1 |
| history corrupted | History already has a final status, but another status is following. | History entry with status DELETED_ADMIN added1 except if the ticket status already was ERROR, then another ERROR history entry was added |
| redundancy missing | History is correct, but status and timestamp is not equal to the archive entry. | Status and timestamps are synchronized to archive entry |
| undo processed failed | DELETED (2) status was undone but reactivation was not successful. (Ticket not in backlog) | History entry with status DELETED_ADMIN added1 |
| undo deleted failed | ANSWERED (3) stattus was undone but reactivation was not successful (Ticket not in Backlog) | History entry with status DELETED_ADMIN added1 |
| final state missing | Ticket has no final status (not in the history nor in the archive) | History entry with status ERROR added |
1 though this cleanup action, the ticket could be reactivated again. The new status has influence on the reached servicelevel of this ticket. So the timestamp of the added history eintry will be set to a time one day after the last history entry of this specific ticket.
- As COMMENT in the supplemented history entries, “{4381} – {1769}: <Reason>” is set (4381=”CleanArchive”, 1769=”Reason”).
- For all history entries added by the cleanup, the corresponding redundancy is created in Archive (copyHistoryData) and the ticket ID is written to the INDEX_QUEUE for a Solr indexing.
- If one or more tickets are selected and meet the criteria for a cleanup, a mail with a summary is then sent to the error address and also written to a separate file in tomcat/logs/routing.ticketCleanup.yyyy-MM-dd.log:
- Ticket Cleanup statistics – how many ticket corpses were selected and processed in what time, what were the reasons, how many cleanups were skipped or were unsuccessful (this statistic is also logged out).
- Details about each ticket: ID, reason for cleanup, some data from archives, entire history of the ticket (incl. added entries).