Límites de cola
Por qué existen. La pasarela responde a un envío antes de enrutarlo, así que cada mensaje en estas
colas ya ha sido aceptado y cobrado. Sin límite, un proveedor que deja de aceptar más un
listener que sigue aceptando hace crecer el heap hasta que la JVM es terminada. Y todo mensaje en cola muere
con ella, ninguno reembolsado, ninguno registrado como algo distinto a PENDING.
Qué cambia un límite. Solo los dos ingresos rechazan. Dentro de la pasarela una cola llena sigue siendo
contrapresión, y el router esperando a una cola de worker llena es el router yendo a la velocidad que el
proveedor puede aceptar. En un ingreso hay un cliente manteniendo una conexión abierta, así que esperar detendría
esa sesión en lugar de ralentizarla:
Elegir un número. No hay predeterminado porque un límite es una declaración sobre tu propio tráfico y
tu propio heap. Demasiado bajo rechaza mensajes que se habrían entregado; demasiado alto y nunca se dispara
antes que la JVM.Empieza por cuántos mensajes estás dispuesto a retener para un proveedor que se ha quedado en silencio, y comprueba la
profundidad bajo carga normal primero.
router_queue y el queue_depth de cada worker están en
/ops/health, con el límite al lado una vez que se establece uno.Límites del ingreso HTTP
Indexado por cuenta, no por credencial: una cuenta puede tener varios logins, y una clave por login
dejaría que un cliente subiera su propio techo creando otro.
La comprobación se ejecuta antes de que el mensaje sea tarificado o cobrado, así que un mensaje rechazado nunca se factura. El
llamante recibe
429, deliberadamente no 403. Nada sobre la petición o la credencial está mal.
Límites de lote
Mismo razonamiento que los límites de cola: la cola del router es sin límite por defecto y no puede empujar de vuelta, así que
un lote sin tope es una forma de agotar el heap.
Rechazos de producto y tarificación
Tres interruptores, todos apagados por defecto, que convierten una mala configuración silenciosa en una ruidosa.
Por qué existen. Un producto sin establecer es un estado soportado que envía mensajes gratis.
RateSnapshot.rulesFor cortocircuita un producto nulo al cubo de cualquier producto solo, así que un
mensaje sin producto nunca puede alcanzar una regla con ámbito de producto. Nada coincide, el mensaje se queda
sin tarificar, y el cargo de crédito retorna temprano. En una cuenta cuyas reglas de tarifa todas llevan un producto, esa
es la factura completa.
system_type es el agujero que una comprobación de no-vacío no habría cerrado. En un bind SMPP resuelve
por encima del producto de la credencial y es texto libre validado en ningún sitio, así que un cliente que conecta con prem
en lugar de premium pasa cualquier test de no-vacío y aterriza en exactamente el mismo estado sin tarificar. Por eso
la comprobación es pertenencia al catálogo en lugar de presencia de un valor.
El modo archivo no tiene catálogo.
credentials.yml no tiene nada de donde derivar uno, así que la mitad de
pertenencia se omite y solo aplica la mitad de no-vacío, registrado una vez por carga de configuración nombrando el
listener. Este es el único lugar donde la característica es más débil de lo que suena.conf.product.required se comprueba en el bind, tras la autenticación, porque el producto vive en el
contexto de sesión. smsg.restapi.product.required también aplica a /secure/rate, así que una cotización no puede
tarificar tráfico que un envío rechazaría.
Antes de activar cualquier flag de producto, el informe pre-flight del panel de control lista cada credencial habilitada
que dejaría de hacer bind. Su límite honesto se declara en esa página: para SMPP comprueba el
fallback de la credencial, y un system_type mal escrito es invisible para él.
Los códigos de rechazo son 0x40F y 0x418. Consulta Códigos de estado.