La tercera existe porque ese estado vive solo en la JVM en ejecución. Nada más puede reportarlo.
sessions es una muestra, no el conjunto
Para ver o buscar el conjunto entero, paginalo:
q empareja sin distinguir mayúsculas por subcadena en account, system_id, host, system_type y
bind_type. Las columnas numéricas deliberadamente no se buscan. 50 de otro modo coincidiría con un
throughput de 50, un puerto de 2750 y una sesión de 50 segundos a la vez.
total cuenta cada sesión; matched cuenta las que pasan q. Ambas se reportan porque un
operador que ha filtrado a un cliente aún necesita saber que el listener está llevando cuatrocientos
binds.
limit por defecto es 50, tope 200, y la respuesta hace eco del tamaño realmente aplicado. Así que un
llamador que pida 10 000 puede ver que obtuvo 200 en lugar de concluir que solo había 200 sesiones.
Los campos que merecen una alerta
config_sources responde una pregunta que la gente hace al revés
Dice, por dominio, si el gateway está leyendo archivos o la base de datos.
Eso importa porque un cambio hecho en el panel no hace nada si el gateway está leyendo un archivo para
ese dominio. Y el síntoma es “mi edición no se aplicó”, que manda a la gente a mirar la edición.
bound: 0 en un listener suele estar bien
En un proveedor significa que nada está conectado y nada puede enviarse.
En un listener normalmente significa que ningún cliente está conectado ahora mismo. Lo cual es tranquilo en lugar de
roto. Por eso un listener sin nadie conectado no se pinta en rojo como un proveedor sin sesión.
Relacionado
El puerto de gestión
Cada endpoint, y qué token necesita cada uno.
Binds y listeners
Tres fallos que parecen todos “nadie está conectado”.