On a CentOS or derived Linux distribution, just run the following commands:

This will in turn:

At the moment we support CentOS 7, CentOS Stream 8, CentOS Stream 9, Rocky Linux 8 and Rocky Linux 9. If you run CentOS 5 or 6, it is time to upgrade - if you really cannot, please see https://www.queuemetrics.com/faq.jsp?uid=faq-110-java8-centos5

You can install WombatDialer within any working servlet container version 2.5 or newer - we suggest Tomcat 8.5. You will also need a working MariaDB or MySQL server. OpenJDK 8 or 11 are fine.

When installation is done, connect to http://myserver.address:8080/wombat - you will be asked for the MySQL root password to create a local database When done, login using as user demoadmin password demo.

WombatDialer ships with a free demo key that lets you use up to two lines - no limit on the number of calls you make. You may want to get a free demo key so you can run a full evaluation of the software in a real-life scenario.

License keys can be installed from the License page as soon as you log in.

WombatDialer requires outbound HTTPS internet connectivity to our licensing servers and cannot run without. It can use a direct connection or can go through a standard Java SOCKS proxy.

If a direct connection is not possible, then you have to set up a SOCKS 5 proxy (that we imagine being on address 1.2.3.4 at port 8888). You can then tell WombatDialer to use it by adding the following items to the JAVA_OPTS start-up parameters:

For more information on proxies supported by the JVM and how to configure them, refer to https://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html

If you plan to use e-mail notifications, you should edit the tpf.properties file to tell WD about your SMTP servers and the e-mail address it is supposed to use.

As e-mail sending happens on the notification thread, a very slow SMTP server might delay HTTP notifications. In this case, we suggest setting up a local SMTP relay that will immediately accept e-mail and will forward it to the "true" SMTP host.

We suggest leaving SMTP_DEBUG on during the initial setup as it writes a verbose log of all SMTP activity on the logs and lets you spot errors and issues quickly.

Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating system-level virtualization on Linux.

When you have Docker installed, starting a temporary instance of WombatDialer is as simple as typing:

This will download the current WombatDialer (already pre-configured for you) and will run it by exposing it on the local port 8080.

The problem with this approach is that when the image is terminated, all data is lost.

A better approach would be to create a data-only container to store the data. At this point, every time you start WombatDialer, it looks for its own data into the data-only container.

You start by creating a named data-only container:

At this point, you can run WombatDialer using that container, as in:

WombatDialer will recognize whether the data container is blank and will initialize it properly. The container also monitors the health of the running WombatDialer process and will restart it as needed.

If you prefer, you may use a local folder instead of a data-only container, as in:

This command mounts the local folder /root/WBT1DATA for WombatDialer to store its data in, and - for a change - will expose WombatDialer on port 9090.

You can also control the local time-zone and the amount of memory used, by passing them as parameters when starting up the image:

When you need to upgrade WombatDialer - you simply stop the current image and start a new one using the same data container. Your dialer is updated!

If you originally installed via yum, this should be enough:

System settings should be automatically transferred.

When the update is complete, on the first connection you might be asked to upgrade the database - the dialer will not start until the database is up to date. Database upgrades will be applied automatically.

You can have them flushed by issuing the commands:

When the update is complete, on the first connection you might be asked to upgrade the database - the dialer will not start until the database is up to date. Database upgrades will be applied automatically.

It is possible to add additional Java environment configuration options to specify system-wide behavior. Those are generally added to the JAVA_OPTS environment variable - eg to specify an HTTP proxy, to force a specific time-zone, to enable JMX monitoring, a garbage collection policy or a number of other features.

WombatDialer has also a few parameters of its own:

The dialer will usually start automatically when the webapp is loaded. Exceptions to this behavior happen if:

If you prefer to avoid the dialer starting automatically, you can do this by creating a flag file called ''donotstart'' to be placed under WEB-INF, like e.g.

In order to revert to the previous behavior, simply remove the flag file.

One of the nicest things of the Java environment, the one that sits behind QueueMetrics and WombatDialer, is that it offers a very accurate and detailed view of what is actually going on. You do not need to use a special build of the software that is meant to gather statistics, and you do not have to pay a high performance price for understanding what the system is doing, so that it is perfectly acceptable to gather live statistics on a production environment. Even better, JVMs are built for being monitored, so that there is a standardized ecosystem of tools to help you understand what is actually going on. This approach is called JMX.

VisualVM is a free graphic tool that can be used to connect to a running Java VM in order to understand what it is doing. Apart for checking memory, CPU usage and garbage collections, it can be used to gather accurate information on what WD is doing internally, as WD exposes its own telemetry through JMX.

To monitor WD running on a server from a workstation, the easiest thing is to set up a SSH tunnel. You will need a recent Tomcat RPM (8.5.64 or newer).

So, once it is installed, you edit /etc/sysconfig/qm-tomcat6, and where it says:

You uncomment the line with JAVA_RMI_ADDRESS; save the file and restart. You just need to do this once, and this can be done safely even on production systems. You can change the JMX port if you need to - does not matter which port you choose, as long as it is the same on your PC and on the server.

Now, you go to your workstation and start a new SSH session with the following incantation, to create a local tunnel for port 30000 and the following one too:

You can now run VisualVM on your workstation - most likely it will already be installed if you have a Java SDK; if not, you can download it from: https://visualvm.github.io

Note that while the example above logs in over SSH as 'root', any user will do.

When you launch VisualVM, you should now click on the button 'Add JMX connection', and create a new connection to localhost:30000, with no password and no encryption (as we already use the SSH tunnel to guarantee security and encryption).

Apart from the welcome page, the first things you should check are memory and CPU.

For example, in the graphs above, we can see that:

WombatDialer is not especially memory-hungry, but might create a lot of intermediate objects that may cause memory pressure; of course, if you do not have enough memory, you will have a lot of garbage collections that will freeze the system and will severely impact performance.

A number of interesting things can be done with VisualVM:

To access telemetry, you click on MBeans, and open the items under "Metrics", as displayed below. Each metric has a name and offers one or more attributes. When you find an interesting attribute, you just click on any number to turn it into a graph that follows the value across time, as shown below.

Most things that WD exposes in its telemetry are loops; so they usually offer:

When inspecting a system, you should start from the core metrics, that is the brain, and from metrics of connected Asterisk servers. The brain should be running smoothly, and at least 4/5 times per second, and the command queue on each Asterisk server should be empty or nearly-empty.

On each iteration, WD receives a set of messages from the GUI, your API and from any connected PBX servers. It uses those messages to update its state, then decides what to do, and every once in a while runs clean-up tasks. At the end of each loop, the database is synchronized (with a commit and/or an eviction and/or a refresh).

Brain time is further divided into:

After that, timed commits happen and logs are shipped for writing to a separate helper process.

When starting new campaign runs, or just running normally, numbers to be dialed have to be loaded from the database:

Look out for very high numbers, and then check what is happening on your database. Does it have enough CPU and IOPS to run smoothly? Is it very busy, or is it sitting idle?

Each Asterisk head has separate statistics and is displayed with its own name.

The Helper offloads some tasks from the main dialer:

Logger:

In order to diagnose problems with WombatDialer, it may be needed to take thread dumps by running:

These dumps prints what the threads are doing at a point in time. It may be worthwhile to take multiple ones, a few minutes apart from each other.

In order to diagnose problems with WombatDialer, it may be needed to take TCP dumps:

First off you can check your network interfaces by typing:

the result will be something like

Issue the dump on port 5038 (remember to add the -s option to avoid capturing only packet’s headers)

This will generate a file called dump.pcap which can be analyzed using Wireshark.

On request, you may need to create a heap dump. This is a large file containing the full contents of the live JVM.

The line containing Bootstrap contains the PID of the Java VM running Tomcat.

The resulting file (called heap.bin as specified on the command line) might be very large and it might take a while to create on busy systems with large Java heaps.

Before sending the file over it is better to compress it:

Edit the my.cnf file (usually in /etc/mysql/my.cnf). Look for the section called "Logging and Replication".

Just uncomment the "log" entry to turn on logging. Restart MySQL with this command:

Edit file my.cnf and add the following parameters:

This will log all queries taking more than two seconds or running without a defined index to the slow queries log.

Then restart MySQL.

In order to manage WombatDialer’s database size, a clean-up script is included in WombatDialer’s installation package. The script file can be found in the application folder at the following path:

Before you run this script make sure you give it the appropriate permissions it needs to be executed.

This script, when executed, searches for old data that is no longer useful or has been hidden by the user. To decide how old must this data be in order for it to be deleted, the user must input a date that will be considered its clean-up threshold.

There are two areas where data can be deleted:

When all the data has been erased, the script will initiate a procedure to rebuild all tables and indexes, thus optimizing and improving database access times.

After navigating to the correct folder and setting the appropriate permissions to the script file, you can execute it by typing:

As you can see, we need to input five parameters to execute the script. These parameters are all mandatory except for one:

There are five different modes for the script:

We suggest manually running the script as preview first; then delete and then optimize.