Getting a ton of Table name cannot be null errors and need some help finding the issue

nicholas_gr · ‎09-20-2024

Hey guys,

Overnight we started getting millions of errors. It is filling up our DB extremely fast and we have no idea where to start to look to find what is causing it. I can't find any changes that happened the day before. Below is the error. We are on prem so none of this is in the cloud. I am pretty new to ServiceNow so not really sure where to start to look for what is could be causing this.

Table name cannot be null: java.lang.IllegalStateException: Table name cannot be null: com.glide.db.TableDescriptor.<init>(TableDescriptor.java:84)
com.glide.db.TableDescriptor.get(TableDescriptor.java:89)
com.glide.db.DBI.shouldPrepare(DBI.java:2794)
com.glide.db.rdbms.oracle.DBIOracle.usePreparedQueries(DBIOracle.java:808)
com.glide.db.DBQuery.<init>(DBQuery.java:238)
com.glide.amb.cluster.AMBQueue.query(AMBQueue.java:108)
com.glide.amb.cluster.AMBQueue.poll(AMBQueue.java:97)
com.glide.amb.cluster.AMBClusterSynchronizer.processMessages(AMBClusterSynchronizer.java:207)
com.glide.amb.cluster.AMBClusterSynchronizer.run(AMBClusterSynchronizer.java:183)

Nicolas_B · ‎03-17-2025

Hello,

We are getting also the same errors on our On Prem instance. Did you find any solution for this please ?

Thanks,

Rudi Knies · 3 weeks ago

Since yesterday we are facing the same issue on our on-Prem instance
What there any solution for this problem ?

MaxMixali · 3 weeks ago

That stack trace is coming from the Asynchronous Message Bus (AMB) cluster thread. In plain English: the real-time messaging layer (used by things like live updates, presence, some workspace widgets, etc.) is trying to poll its queue table, but it’s being handed a null table name, so it throws and logs repeatedly. That’s why your DB/logs are exploding.

---

## Immediate blast-radius reduction (safe to do)
These turn off AMB so the error storm stops while you investigate.
1. Set the following system properties (System Properties → All):
- glide.amb.enabled = false
- glide.ui.interaction_live_updates = false
- (If present) glide.ui.real_time_form_updates.enabled = false
2. Node restart (or at least cache flush /cache.do) so the AMB threads stop.

---

## Quick health checks (5–10 min)
Run this in Background Scripts (Global scope):
```
(function () {
var tables = ['sys_amb_message','sys_amb_client','sys_amb_channel','sys_amb_subscription'];
tables.forEach(function(t){
var ok = new GlideRecord(t).isValid();
gs.print(t + ' exists? ' + ok);
if (ok) {
var gr = new GlideRecord(t);
gr.setLimit(1);
gr.query();
gs.print(t + ' sample row? ' + gr.hasNext());
}
});
})();
```
If any returns *exists? false* → that table (or its dictionary) is missing/corrupted.

---

## Check for a bad/empty property or customization
Search sys_properties for anything “amb”. Look for empty values or custom ones. Also review update sets for sys_db_object changes to AMB tables.

---

## Validate dictionary objects
Ensure sys_db_object rows exist for: sys_amb_message, sys_amb_client, sys_amb_channel, sys_amb_subscription. Missing rows = root cause → restore from backup or reinstall plugin.

---

## Cluster/state sanity
Check sys_cluster_state.list for node health and logs for schema/cache errors.

---

## Re-enable AMB
After fixing, re-enable glide.amb.enabled = true and flush cache.

---

## If tables are missing/corrupt
Restore missing dictionary rows or perform plugin repair. You can safely truncate AMB runtime tables (sys_amb_message, etc.) if only data is bad.

---

## Rogue script check
Search scripts for `new GlideRecord('')` or dynamic table references.

---

## Likely root causes
- Missing/corrupted sys_amb_message or related table.
- Update set removed sys_db_object entry.
- Custom property blanking table name.
- Oracle schema sync failure.

---

## Temporary operation without AMB
Set:
- glide.amb.enabled = false
- glide.ui.interaction_live_updates = false
Users lose presence/live updates but system remains stable.

---

Once you know which tables are missing (from the health script output), restore them from sub-prod or XML export, then restart nodes. That will stop the infinite logging.

Rudi Knies · 3 weeks ago

Hi @MaxMixali many thank for your detailed explanation, really helpful.
In our case we could fix this issue by a simple restart of one Application node which was frozen.