icon-arrow icon-check icon-mail icon-phone icon-facebook icon-linkedin icon-youtube icon-twitter icon-cheveron icon-download icon-instagram play close icon-arrow-uturn icon-calendar icon-clock icon-search icon-chevron-process icon-skills icon-knowledge icon-kite icon-education icon-languages icon-tools icon-experience icon-coffee-cup
Werken bij Whitehorses
Blog 23/01/2023

MuleSoft Websockets en dubbele workers; gaat dat werken?

Whitehorses

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!

Whitehorses
Martijn van de Goor /
Integratiespecialist

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

Geen reacties

Geef jouw mening

Reactie plaatsen

Reactie toevoegen

Jouw e-mailadres wordt niet openbaar gemaakt.

Geen HTML

  • Geen HTML toegestaan.
  • Regels en alinea's worden automatisch gesplitst.
  • Web- en e-mailadressen worden automatisch naar links omgezet.
Whitehorses
Martijn van de Goor /
Integratiespecialist

Wil je deel uitmaken van een groep gedreven en ambitieuze integratiespecialisten? Stuur ons jouw cv!