Why does a Mango BACnet publisher expose only 8 of 20 points?

Log signature of an exhausted scheduler pool

A Mango free-m2m2-core-3.0.1 instance publishing about 20 points over BACnet exposes only 8 of them to external BACnet software, and its log shows the scheduler pool pinned at its ceiling. Treat the missing points as a symptom of that saturation until the log proves otherwise.

Save the log excerpt with the first FATAL timestamp. Every later step is judged against it.

Baseline of publisher points against the client object list

Record which points are missing before changing any setting, so the final check has something to compare with. The prerequisite is a BACnet client that can discover the Mango device and read its object list.

1. Open the BACnet publisher in Mango and list every published point with its object type and instance number. Confirm the count matches the roughly 20 points under test.
2. Confirm each source data point behind a published point is enabled and holds a current value. A publisher can only expose what its source points supply.
3. Run device discovery from the external client and read the Mango device's object list. Record the 8 objects that appear.
4. Compare the two lists. Look for a shared trait among the 12 missing points: object type, instance range, or source data source.

Gate: you hold a table of published points versus visible points. Duplicate object instance numbers within one object type collapse into fewer visible objects, so check for them now.

Raising the High Priority Thread Pool maximum

The fatal entries show a 100-thread pool fully active with an empty queue, so more headroom is the first change. Change the maximum only; leave everything else as found.

1. Open the system settings page in Mango and locate the High Priority Thread Pool maximum pool size. Note the current value; the FATAL lines show 100 at the time of the fault.
2. Raise the maximum in a moderate step, not to an arbitrary large figure. Each thread is an OS thread with its own stack.
3. Save the setting. If the page indicates a restart is required, restart Mango.
4. Read the next executor line in the log. The pool size ceiling must reflect the new maximum.

Gate: the new ceiling appears in the log line. If it still shows 100, the setting did not apply, and nothing downstream is worth diagnosing.

Confirming the pool is no longer saturated

A larger ceiling helps only if the active count stays below it. Watch the pool for several polling periods of the busiest data source.

1. Tail the Mango log and filter for RejectedExecutionException. No new FATAL entries may appear.
2. If a rejection line appears, read active threads against the new pool size. If active equals the new maximum again, the threads are blocked rather than under-provisioned, and raising the maximum again only delays the failure.
3. For blocked threads, take a thread dump of the Mango JVM with the JDK's jstack <pid> (the log shows a Java 8 runtime). Look for many threads waiting in the same BACnet request or I/O call.

Gate: no FATAL rejections across several poll periods, with active threads below the ceiling. A stack full of threads waiting on BACnet responses points to the transport and remote-device problems in the next two sections.

Clearing the bacnet4j expire NullPointerException

After the pool change, the log shows Error during expire messages from DefaultTransport.run:462 instead of the FATAL entries. The transport keeps a list of outstanding confirmed requests. On timeout, expire calls sendForResponse to retry, which calls Network.sendAPDU, and line 103 dereferences a null. Timeouts pile up when remote devices do not answer, and the loop then repeats the error at a high rate.

1. Note which BACnet component owns the transport: the BACnet publisher's local device, or a BACnet IP data source polling remote devices. Check the log for the data source or publisher name near the first NPE.
2. Disable, then re-enable that publisher or data source to rebuild its transport and network objects. Watch whether the NPE recurs.
3. If it recurs, check whether the requests target a remote device that is offline or unreachable from the Mango host. Confirm reachability at the IP level first, then at BACnet level with an independent client.
4. If the NPE persists with the pool healthy and every target reachable, treat it as a defect in the bundled bacnet4j-4.0.1-SNAPSHOT library. Snapshot builds carry no release guarantee. Read the release notes of a newer Mango core build for a bacnet4j fix before upgrading.

Gate: the ERROR line is absent for a full observation window after the restart of the owning component.

Clearing Task Queue Full on the polling data source

TaskRejectionHandler warnings mean a scheduled poll was dropped because no worker was free at fire time. The identifier after DS_ is the data source XID, so it maps to one specific data source.

1. Find the data source whose XID is DS_44f5a17c-f4a1-40e0-a221-390bb181bee4 on the Data Sources page and record its type and polling period.
2. Read the settings page for every pool it lists. The polling job may run in a pool other than the one you raised.
3. If the data source polls remote BACnet devices, check whether a slow or offline device holds workers until the request times out. Lengthen the poll period or reduce points per device until one poll completes well inside its period.

Gate: no Task Queue Full warning for that XID across at least several of its polling periods.

Re-registering the publisher points and re-reading the object list

Once the pool and the transport are quiet, force the publisher to rebuild its state and re-read from the client. Do this only after the previous gates pass, because a publisher restarted on a saturated pool fails the same way.

1. Disable, then enable the BACnet publisher.
2. Re-run discovery in the external client and read the object list again. Clients cache object lists, so clear the client's cached device entry or rescan.
3. Compare against the baseline table. Every published object must appear with the recorded type and instance.

If the count is still short with a clean log, check three items: duplicate instance numbers within an object type, source data points that are disabled, and the client's handling of the object-list read. A client that cannot handle a segmented response may report a partial list; read individual array indexes of the object list to separate a client limit from a publisher gap. With only about 20 objects, expect saturation, not segmentation, to have caused the original shortfall.

End-to-end verification of all published points

1. Confirm the log carries no FATAL RejectedExecutionException, no Error during expire messages, and no Task Queue Full warning for DS_44f5a17c-f4a1-40e0-a221-390bb181bee4 across a period covering several polls.
2. Confirm the executor line shows active threads below the raised pool ceiling.
3. Read the Mango device's object list from the external BACnet client and count all published objects. The count must match the publisher's point list, not the earlier 8.
4. Read the present value of a changing point twice, one poll period apart, from the external client. The value must update between reads and match the value shown in Mango.

FAQ