How to Troubleshoot Data Source Issues

Overview

When data sources don't poll at the expected frequency, you get gaps in your data, delayed alarms, and inaccurate reports. Polling issues stem from three areas: the Mango by Radix IoT server (overloaded), the network (latency or drops), or the device (slow response or timeout). This guide helps you identify and fix each.

Symptoms of Polling Issues

Step 1: Identify the Scope

First determine if the issue affects one data source or all of them:

• One source affected: Problem is likely device-specific, network-specific, or configuration-related
• All sources affected: Problem is likely server-side (CPU, memory, or thread exhaustion)
• Sources on the same subnet affected: Likely a network or switch issue

Step 2: Check the Data Source Status

1. Open the affected data source and select the Runtime status tab
2. Read Current state — this is a single pill, not a traffic light. It shows a tick while the source is RUNNING and a warning icon for every other lifecycle state
3. Read the Latest poll times table — the last ten polls, with Poll start time, Poll duration and Poll aborted columns. Compare the durations with the configured interval
4. Read Latest aborted poll times — the last ten aborted polls, or the text No aborted polls. This is the fastest single answer to "is this source keeping up?"

Step 3: Diagnose by Category

Server-Side Issues

If all or many data sources are slow:

• Check JVM heap usage — high occupancy alone does not prove starvation. Look for sustained high usage after garbage collection, rising GC time, and correlated work-queue or latency problems before changing -Xmx
• Check CPU usage — if the server is at 100% CPU, Mango can't keep up with the workload
• Check thread pool — if the thread pool queue is growing, too many data sources are competing for threads
• Reduce the load: Increase poll intervals on less-critical sources, disable unused sources, or add server resources

Network Issues

If specific data sources on the same network are slow:

• Ping the device — check for packet loss and latency
• Check the switch/router — port errors, broadcast storms, or VLAN issues
• Check firewalls — ensure the polling port isn't being rate-limited or blocked intermittently
• Check cable/connection — physical network issues cause intermittent timeouts

Device-Side Issues

If a single data source is slow:

• Check the device's response time — some devices take several seconds to respond to register reads
• Reduce the number of points per poll — reading 500 registers in one poll may exceed the device's capacity
• Check device load — if other systems are also polling the same device, it may be overwhelmed
• Increase the timeout — if the device is slow but functional, raise the protocol's timeout. This is a per-protocol setting, not a core data source field: Modbus, for example, has Timeout (ms) and Retries

Step 4: Optimize Polling Configuration

Poll Interval vs Poll Duration

The poll interval must be longer than the poll duration. If a poll takes 8 seconds and the interval is 5 seconds, polls fall further behind every cycle until Mango starts discarding them.

Rule: Poll interval ≥ 2 × typical poll duration

Batch Register Reads

For Modbus and similar protocols, batch consecutive register reads into range reads. Reading registers 1-100 in one request is much faster than 100 individual reads. The Modbus data source exposes this directly as Max read register count, Max read bit count and Contiguous batches only.

Stagger Data Sources

If 20 data sources all poll at 5-second intervals, they may all try to poll at the same moment. Mango has no "start offset" field, so there are exactly two levers on the Data source tab:

• Quantize — note that this makes the problem worse, not better. Quantize aligns the first poll to the next clock boundary, so every quantized source sharing a period fires together. Clear it on sources that do not need clock-aligned samples
• Use cron with a Cron pattern — the only way to place polls deliberately. The pattern is Quartz-style, second first: give one source 0/5 * * * * ? and the next 1/5 * * * * ? to offset them by a second. The two levers are mutually exclusive — Mango rejects a cron source that is also quantized

One caveat worth knowing before you reach for cron: Mango only discards a late poll on interval-scheduled sources. A cron-scheduled source is never marked aborted for lateness, so its polls silently pile up instead of showing in the aborted count.

Prioritize Critical Points

Not every point needs 1-second polling. Set critical points (safety alarms) to fast polling and non-critical points (energy totals) to slower intervals. This frees resources for what matters most.

Step 5: Monitor the Fix

After making changes:

1. Watch the data source's Runtime status tab for 30 minutes and confirm No aborted polls
2. Open Data Sources Performance to compare every source at once. It is under System status, which is hidden and superadmin-only: Admin home → Server status → More details
3. Verify data point charts show consistent data without gaps
4. Check ma.log for new errors

Two things make this less passive than it sounds, and both have a limit. Every polling data source already registers a Poll aborted event, defaulting to alarm level Urgent on the source's Event alarm levels tab, and a handler attached to it tells you when the source starts aborting. Mango raises it only for the first aborted poll after the data source starts, with no return to normal, and not again until the source is restarted, so it cannot tell you whether the aborts continued or stopped. For that, read Latest aborted poll times, or the Consecutive run polls point if an Internal Data Source creates it. And ma.log records its aborted-poll warning at most once an hour per source (runtime.datasource.pollAbortedLogFrequency, default 3600000 ms), so a quiet log is not evidence that the aborts stopped, and one line can stand for an hour of them.

Troubleshooting Quick Reference

Summary

Polling issues come from three places: server overload, network problems, or device limitations. Start by determining the scope (one source or all), check the data source status, then investigate the appropriate category. The most common fix is increasing poll intervals to match what the system can actually sustain. Monitor after changes to confirm the fix holds.