fb
Nieuws 4 min

Afstemming van JMS Transport met WSO2 Enterprise Integrator

omar khalid
Omer Khalid
Integration Consultant
jms
Scroll

Producten: De volgende configuratie kan worden toegepast van EI 6.2.0 tot EI 6.6.0.

Heb je al ooit op een lange roadtrip gedaan, honderden kilometers door Europa gereden langs tal van mooie steden, genietend van de cultuur en lokale gerechten? Zo ja, wat is dan het eerste dat je doet als je terug thuis bent? Na een lang weekend uit te rusten natuurlijk. Je kunt bijvoorbeeld je auto naar een garage brengen om motorolie of accu’s te controleren. Je wilt er waarschijnlijk zeker van zijn dat alles in orde is met de auto en dat hij nog steeds 100 procent veilig is om mee te rijden. Net zoals bij een muziekinstrument, heeft het op een bepaald moment ook een goede afstemming nodig, zodat het dat mooie geluid kan blijven maken dat het hoort te doen.

Evenzo, als we het hebben over IT-systemen en producten, hebben ze ook regelmatig onderhoud nodig. En als je het niet proactief doet, besef je het pas als het te laat is. Gewoonlijk hebben we als mensen het gebrek om nooit te veel na te denken over de dingen die soepel lopen en pas in actie komen als er iets kapot gaat. Maar zoals een wijs man ooit zei:

“De tijd om het dak te repareren is als de zon schijnt”    

John. F. Kenedy (1917-1963)

Wat is JMS?

JMS staat voor Java Message Service. Met de JMS binnen WSO2 EI kan je eenvoudig berichten verzenden en ontvangen naar wachtrijen en onderwerpen van elke JMS-service die de JMS-specificatie implementeert. Met JMS kan je berichten naar de wachtrijen en onderwerpen op elke message broker publiceren. Met de EI zijn de meest gebruikte message brokers ActiveMQ, RabbitMQ en WSO2’s eigen Message Broker.

Bij complexe integratiescenario’s moet u vaak het Guaranteed Message Delivery Pattern implementeren waarbij je ervoor moet zorgen dat het bericht niet verloren gaat. Een manier om dit patroon te implementeren is door de wachtrijen en onderwerpen te gebruiken. Op deze manier kunnen berichten worden teruggedraaid in het geval van een verbindingsfout of een ander probleem.

Met de toenemende behoefte aan het implementeren van services die een betrouwbare uitwisseling van berichten garanderen, neemt ook het aantal op JMS-gebaseerde services toe. Na een tijdje, wanneer er te veel diensten zijn die JMS Transport gebruiken, moeten we het een beetje verfijnen om aan onze behoeften te voldoen. De standaardinstellingen zullen het gewoon niet redden.

Hoe het aantal JMS Threads vergroten?

Er zijn veel manieren om de capaciteit van EI te vergroten om meer op JMS-gebaseerde verbindingen te verwerken. Hier bespreken we er slechts één: hoe het aantal JMS Threads te vergroten. Deze configuratie geeft je voldoende JMS Threads die beschikbaar zijn om de berichten uit de wachtrijen te gebruiken. Het maximum aantal JMS-proxy’s dat gelijktijdig kan worden uitgevoerd, wordt bepaald door de waarden die aan deze eigenschappen zijn toegewezen.

Je kan een bestandsnaam jms.properties maken in de map <EI_HOME>/conf van het product.

  • lst_t_core=200
  • lst_t_max=250
  • snd_t_core=200
  • snd_t_max=250

De standaardwaarde van deze kenmerken is slechts 20. Als je een waarde niet expliciet definieert, worden de standaardwaarden automatisch toegewezen. WSO2 heeft een eenvoudige methode voor je om te berekenen wat je in deze eigenschappen moet zetten.

  • lst_t_core >  Total number of consumers + 20
  • lst_t_core < lst_t_max
  • snd_tsnd_t_core > Total number of consumers + 20
  • snd_t_core < snd_t_max

Je kunt het totale aantal consumenten berekenen met de volgende formule:

Totaal aantal consumenten = transport.jms.MaxConcurrentConsumers * Aantal JMS-proxy’s

(vind de waarde transport.jms.MaxConcurrentConsumers in <EI_HOME>/conf/axis2/axis2.xml onder JMS Listener transportconfiguratie. Indien niet aanwezig, kan je deze waarde daar definiëren.)

Nadat je al deze instellingen hebt uitgevoerd, moet je de EI opnieuw opstarten en gaan de instellingen van kracht.

Conclusie

JMS-gebaseerde oplossingen worden steeds gebruikelijker vanwege het gemak van implementatie van Guaranteed Message Delivery en Message Roll Back Enterprise Integration Patterns. Binnen de WSO2 Enterprise Integrator moeten we, om het failover-mechanisme van op JMS gebaseerde services te gebruiken, de blokkeermodus in de Call mediator gebruiken. Op deze manier kunnen we het bericht bewaren en terugdraaien als een verbindingspoging mislukt met het backend-systeem.

Standaard is de limiet van deze JMS-verbindingen erg laag in de productinstellingen. Deze blog belicht een aantal stappen waarmee je de prestaties van JMS-proxyservices kunt verbeteren door het onderliggende aantal threads dat aan deze oorzaak is toegewezen te vergroten. Het is beter om deze instellingen proactief of vóór een productie-uitrol te doen om fouten te voorkomen.

Te verwarrend? Probeer Connext of Connext Go

Als je het gedoe van het doorlopen van deze configuraties en het zelf regelen van deze dingen wilt negeren, dan kun je altijd ons Platform as a service product CONNEXT verkennen. Wanneer je CONNEXT gebruikt, zorgt Yenlo voor alle instellingen en configuraties. Jij hoeft niets te doen. Leun achterover, ontspan en blijf bouwen aan de Integraties.