The third exists because that state lives only in the running JVM. Nothing else can report it.
sessions is a sample, not the set
To see or search the whole set, page it:
q matches case-insensitively by substring on account, system_id, host, system_type and
bind_type. Numeric columns are deliberately not searched — 50 would otherwise match a
throughput of 50, a port of 2750 and a session up for 50 seconds at once.
total counts every session; matched counts those passing q. Both are reported because an
operator who has filtered to one customer still needs to know the listener is carrying four hundred
binds.
limit defaults to 50, capped at 200, and the response echoes the size actually applied — so a
caller asking for 10 000 can see it got 200 rather than concluding there were only 200 sessions.
The fields worth alerting on
config_sources answers a question people ask backwards
It says, per domain, whether the gateway is reading files or the database.
That matters because a change made in the panel does nothing if the gateway is reading a file for
that domain — and the symptom is “my edit did not apply”, which sends people looking at the edit.
bound: 0 on a listener is usually fine
On a vendor it means nothing is connected and nothing can be sent.
On a listener it usually means no customer is connected right now — which is quiet rather than
broken. That is why a listener with nobody bound is not painted red the way a vendor with no session
is.
Related
The management port
Every endpoint, and which token each needs.
Binds and listeners
Three failures that all look like “nobody is connected”.