MuleSoft Websockets en dubbele workers; gaat dat werken?

Al maanden zag ik bij mijn klant de MuleSoft Websocket Client API informatie opslokken, totdat de API zich ineens regelmatig ging herstarten omdat de JVM niet meer reageerde. Het is belangrijk om ervoor te zorgen dat er voldoende geheugen is gealloceerd voor de API anders wordt de JVM unresponsive en volgt een herstart. Op Cloudhub kun je dit instellen door middel van de worker size (vCores beschikbaar voor de API). Hoe groter des te meer geheugen!

De websocket ontvangt nonstop duizenden berichten per minuut op de Outbound Socket. Deze berichten komen van sensoren die de temperatuur meten in de gebouwen van mijn klant. Langzaamaan werden er steeds meer sensoren geïnstalleerd en ontving de API een toenemend aantal berichten, totdat het geheugen het niet meer aankon. Ik was slim en vergrootte de worker size in de veronderstelling dat dit de problemen zou oplossen. Aanvankelijk was dit het geval, maar met een verdere toename van het aantal sensoren liep de API weer tegen zijn limiet aan. 

Ik dacht nog slimmer te zijn en greep naar een ander beproefd middel: horizontaal schalen! In plaats van 1 worker te gebruiken verdubbelde ik dit aantal naar 2. Twee instanties van de API kan het dubbele aantal berichten aan, toch?! 

Ik zag ineens een enorme hoeveelheid berichten binnenkomen en de API begon te kraken en breken. Wat nu?! Ik dacht de oorzaak te weten. Per worker wordt er wellicht een Outbound Socket geopend die de berichten voor een gebouw ontvangt. De berichten zouden dan door het gebruik van twee workers dubbel binnen zijn gekomen. Ik had de totale ondergang toch niet zelf veroorzaakt? 

Bij controle van de logging bleek dat worker 1 alle berichten aan het verwerken was en worker 2 niks stond te doen. Pff, ik had de boel niet laten ontsporen. Een belletje richting building management gaf uitsluitsel. Op ongeveer hetzelfde moment dacht men wel even een gebouw vol sensoren aan te kunnen zetten. Helaas kon het systeem dit niet aan en de API begon zich continu opnieuw op te starten.

Maar waarom doet worker 2 helemaal niks? De Cloudhub documentatie geeft uitsluitsel:

When deploying your application to two or more workers, you can distribute workloads across these instances of Mule. CloudHub provides the following:

1. The HTTP load balancing service automatically distributes HTTP requests among your assigned workers.
2. Persistent message queues

De workload wordt niet verdeeld omdat we in de API geen HTTP listener gebruiken en ook geen message queue. Twee workers gebruiken heeft dus geen enkele zin bij het omgaan met een grote load op websockets. Wat hebben we geleerd? READ THE F***** MANUAL!

Meer weten over de werking van websockets in combinatie met MuleSoft? Probeer het uit middels deze tutorial.