Een process afsplitsen in J2EE

[humbug]

In een JBoss server hebben we een process wat simpelweg te traag is om onze piekbelasting aan te kunnen.

Om dit op te lossen is het de bedoeling om een gedeelte van het process af te splitsen en apart uit te voeren zodat het vereenvoudigde process op drukke momenten de piekbelasting wel aan kan en het afgesplitste process niet meer kritisch is (qua tijd dan).

Dus ik ben eigenlijk op zoek naar de "best practise" om dit op te lossen waarbij ook het afgesplitste process apart op meerdere applicatieservers kan draaien. Simpelweg een extra thread creeren of een nieuwe request naar de applicatieserver toesturen zijn methoden die zo direct bij mij opkomen maar lijken me niet echt optimaal.

[SchizoDuckie]

Wat jij wil ís toch gewoon een thread?

[humbug]

SchizoDuckie schreef op dinsdag 21 augustus 2007 @ 13:09:
Wat jij wil ís toch gewoon een thread?

Nee, een thread draait enkel op de machine waarop je toevallig bezig bent. En dat is niet echt optimaal. Het probleem is juist dat dit ene process niet over meerdere servers verdeeld kan worden (don't ask) en daardoor te traag is. Door het niet kritische maar zware gedeelte af te splitsen en te herverdelen over de servers zou de performance van dat ene process drastisch moeten toenemen.

Ik wil een load balanced thread

[ Voor 37% gewijzigd door humbug op 21-08-2007 13:19 ]

[Janoz]

Waarop je toevallig bezig bent? Hebben jullie een distributed JBoss serverpark?

Ah, je hebt inderdaad een distributed JBoss server park blijkt na de edit.


Om een process parraleliseerbaar te maken zul je dat toch echt zelf moeten schrijven. Dat is helemaal niet triviaal, laat staan dat het automagisch door de virtual machine zou kunnen gebeuren.

[ Voor 63% gewijzigd door Janoz op 21-08-2007 13:32 ]

[humbug]

Tjsa, zelf schrijven is niet het probleem. Ik ben eigenlijk voornamelijk geinteresseerd in de methodiek hoe dit soort zaken door anderen zijn aangepakt. Het is een beetje zinloos om het wiel opnieuw uit te vinden.

[momania]

Je bent bekend met Quartz?

Daarin kan je jobs/process gewoon schedulen en ook in een cluster laten runnen

http://www.opensymphony.com/quartz/

[Alarmnummer]

Janoz schreef op dinsdag 21 augustus 2007 @ 13:21:
Om een process parraleliseerbaar te maken zul je dat toch echt zelf moeten schrijven. Dat is helemaal niet triviaal, laat staan dat het automagisch door de virtual machine zou kunnen gebeuren.

Pcies.

Er zijn allerlei technieken voor om taken te verdelen. En of je dit nu geclustered laat uitvoeren, de load over meerdere cores van 1 node laat uitvoeren, of een enkele core multithreaded wilt laten draaien doordat je dan effectiever van de resources gebruikt kunt maken, dat zou in principe niet al te veel hoeven uit te maken.

Je zou eens kunnen kijken naar:
Patterns for Parallel Programming. Hierin staan veel technieken beschreven om load te verdelen zoals scatter/gatherer.

PS:
ik ben geen voorstander van on the fly threads aan te maken binnen enterprise java omgevingen. Ik heb liever een structuur die de threads beheerd (bv een ThreadPoolExecutor of een timer). Hierdoor hou je veel beter onder controle hoeveel threads je opstart, je kunt verder ook beter hun life cycle beheren.

PPS:
Ik weet niet hoe het zit met EJB3, maar bij EJB2 was het verboden om zelfs threads op te starten omdat bv allerlei resources (zoals transacties) niet worden gezet. Dus wat gebruik je?

PPPS:
Je zou als tijdelijke mogelijke oplossing, de prioriteiten van de threads van lang lopende taken even heel laag kunnen zetten. Dan hebben normale processen iets minder last van langlopende taken.

[ Voor 29% gewijzigd door Alarmnummer op 22-08-2007 07:29 ]

[Verwijderd]

humbug schreef op dinsdag 21 augustus 2007 @ 13:02:
In een JBoss server hebben we een process wat simpelweg te traag is om onze piekbelasting aan te kunnen.

Om dit op te lossen is het de bedoeling om een gedeelte van het process af te splitsen en apart uit te voeren zodat het vereenvoudigde process op drukke momenten de piekbelasting wel aan kan en het afgesplitste process niet meer kritisch is (qua tijd dan).

Dus ik ben eigenlijk op zoek naar de "best practise" om dit op te lossen waarbij ook het afgesplitste process apart op meerdere applicatieservers kan draaien. Simpelweg een extra thread creeren of een nieuwe request naar de applicatieserver toesturen zijn methoden die zo direct bij mij opkomen maar lijken me niet echt optimaal.

Eneuhm, is asynchroon (JMS) geen oplossing?

[JKVA]

Verwijderd schreef op woensdag 22 augustus 2007 @ 08:13:
[...]


Eneuhm, is asynchroon (JMS) geen oplossing?

Daar zat ik idd ook aal te denken. Dat is tevens een oplossing voor het probleem dat Alarmnummer in zijn PPS schetst, namelijk door gewoon een MDB te gebruiken. (@Alarmnummer: In EJB 3.0 geldt dit nog steeds, net als de meeste EJB 2.1 regels)

Het nadeel van een MDB (en JMS in het algemeen) is dat het messaging is. Dat brengt bepaalde consequenties met zich mee, zoals dat je de controle kwijt bent over de verwerking. Ook als je een returnwaarde verwacht uit je proces, is een synchrone methode (dus gewoon een method call in dezelfde thread of control) doorgaans gemakkelijker.

[Alarmnummer]

JKVA schreef op woensdag 22 augustus 2007 @ 09:36:
[...]
Daar zat ik idd ook aal te denken. Dat is tevens een oplossing voor het probleem dat Alarmnummer in zijn PPS schetst, namelijk door gewoon een MDB te gebruiken. (@Alarmnummer: In EJB 3.0 geldt dit nog steeds, net als de meeste EJB 2.1 regels)

*maakt ff notitie*

Het nadeel van een MDB (en JMS in het algemeen) is dat het messaging is. Dat brengt bepaalde consequenties met zich mee, zoals dat je de controle kwijt bent over de verwerking. Ook als je een returnwaarde verwacht uit je proces, is een synchrone methode (dus gewoon een method call in dezelfde thread of control) doorgaans gemakkelijker.

Er zijn trouwens wel weer manieren om iets met return waardes te doen, de vraag is of je helemaal terug wil naar je hoofd process, of dat je een process erachter zet die iets doet met de return waarde. Maar het is en blijft complexer dan een synchrone oplossing.

Verder is exception handeling ook altijd zo'n ondergeschoven kindje bij message passing oplossing.

@TS: Enterprise Integration Patterns is een erg informatief boek als je meer wilt weten over message passing oplossingen.

[ Voor 27% gewijzigd door Alarmnummer op 22-08-2007 09:53 ]

[JKVA]

Alarmnummer schreef op woensdag 22 augustus 2007 @ 09:49:
[...]
*maakt ff notitie*
[...]

Heb dat voor mijn SCBCD examen moeten leren. Achterin de EJB 3.0 specificatie staat een hele lijst met restricties die je hebt als je EJB's gebruikt, waaronder met Threads rommelen, outputstreams veranderen, file IO, sockets starten, enz. De meesten zijn vrij terecht, maar bijvoorbeeld threads starten heeft Spring beter voor elkaar.

Er zijn trouwens wel weer manieren om iets met return waardes te doen, de vraag is of je helemaal terug wil naar je hoofd process, of dat je een process erachter zet die iets doet met de return waarde. Maar het is en blijft complexer dan een synchrone oplossing.

Verder is exception handeling ook altijd zo'n ondergeschoven kindje bij message passing oplossing.

@TS: Enterprise Integration Patterns is een erg informatief boek als je meer wilt weten over message passing oplossingen.

Daar sluit ik me bij aan. Goed boek.

[Verwijderd]

Janoz schreef op dinsdag 21 augustus 2007 @ 13:21:
Om een process parraleliseerbaar te maken zul je dat toch echt zelf moeten schrijven. Dat is helemaal niet triviaal, laat staan dat het automagisch door de virtual machine zou kunnen gebeuren.

Misschien niet door de VM, maar nog meer low-level door bijvoorbeeld Terracotta

[Janoz]

Ik denk niet dat Terracotta in staat is om 1 thread op te splitsen over meerdere computers.

[Alarmnummer]

Janoz schreef op woensdag 22 augustus 2007 @ 13:09:
Ik denk niet dat Terracotta in staat is om 1 thread op te splitsen over meerdere computers.

Pcies.

Terracotta doet afgezien van object distributie helemaal niets voor je.

[Verwijderd]

Janoz schreef op woensdag 22 augustus 2007 @ 13:09:
Ik denk niet dat Terracotta in staat is om 1 thread op te splitsen over meerdere computers.

Nee daar doelde ik ook niet op. Ik doelde op het werk uit handen nemen voor je thread distributie.

Wat je zou willen is gewoon een (thread/)task de lucht in kunnen trappen en je voor de rest niet meer bekommeren over waar deze wordt uitgevoerd. En bijvoorbeeld tijdens de uitvoer van de (thread/)task kunnen switchen van VM.

edit:
Dit is dus geen claim dat het nu allemaal al mogelijk is. Simpelweg een mening van wat een clustered omgeving zou moeten zijn. Namelijk een transparante clustered VM en dus geen geneuzel met app-servers die je vooral beperkingen opleggen.

[ Voor 19% gewijzigd door Verwijderd op 22-08-2007 14:11 ]

[humbug]

Kijk, je bent een dagje aan het werk en er komt een hoop nuttige informatie langs Inderdaad zaten we hier ook in de richting van JMS te denken om de zaak netjes te houden. Maar zeker met dit soort dingen is het altijd interessant om te zien waar andere mensen mee op de proppen komen.
Volgende week maar eens gaan expirimenteren

[voodooless]

Ik zou verder niet zo nouw kijken naar al die EJB richtlijnen (zolang je daar maar niet aan gebonden bent van hogerop). 't zijn veelal dingen om de ontwikkelaar te beschermen. Als al die libs die je gebruikt, threads, file io en sockets gebruiken, waarom zou jij dat zelf dan niet mogen (al zijn er vaak genoeg goede redenen om al die prima libs te gebruiken) als je er goed mee omgaat?

Ik zou inderdaad eerst eens proberen om het geheel asynchoon in een thread af te handelen, dus:

Java:

private Object lock = new Object;

public result doStuff(){
      Result result = new result;
      startWorkerthread(result );
      synchronized(lock){
           lock.wait();
      }
      return result;
}

public void workerCallback(){
     synchronized(lock){
           lock.notify();
      }
}

Eenzelfde opzet kun je natuurlijk ook met JMS realiseren.

Vanhieruit kun je altijd nog parallellisatie uitvoeren en taken verdelen over meerdere servers.


Edit: bovenstaande is dus niet erg zinvol zoals markt platvoet terecht opmerkt!

[ Voor 7% gewijzigd door voodooless op 22-08-2007 14:49 ]

[Janoz]

@mark

Ik had het over het paraleliseerbaar maken van een proces.

Een reactie als "Misschien niet door de VM, maar nog meer low-level" kan ik dan niet echt rijmen met "Ik doelde op het werk uit handen nemen voor je thread distributie."

De rest van je verhaal is wel steekhoudend, maar niet als reactie op mijn opmerking.

[Verwijderd]

@Voodooless code
Als je het zaakje asynchroon wilt uitvoeren, waarom laat je hem dan blocking zijn? Dan kun je hem net zo goed in de huidige thread laten uitvoeren. (en dan laten we de hele vervelende race conditions missed signals nog maar even achterwege)

Janoz schreef op woensdag 22 augustus 2007 @ 14:25:
De rest van je verhaal is wel steekhoudend, maar niet als reactie op mijn opmerking.

Nee klopt, het was meer een reactie in de strekking van de gehele (topic)thread. Toen ik het terug las vond ik het ook niet zo rijmen. Het ging er mij om dat TS klaarblijkelijk geen thread de lucht in wilde trappen aangezien je dan machine gebonden bent en je wilt eigenlijk de machine keuze uit handen geven.

[ Voor 52% gewijzigd door Verwijderd op 22-08-2007 14:45 ]

[voodooless]

Verwijderd schreef op woensdag 22 augustus 2007 @ 14:25:
@Voodooless code
Als je het zaakje asynchroon wilt uitvoeren, waarom laat je hem dan blocking zijn? Dan kun je hem net zo goed in de huidige thread laten uitvoeren. (en dan laten we de hele vervelende race conditions nog maar even achterwege)

Goed punt, ik zal even krom te denken Je schiet er inderdaad niet veel mee op... De vraag is echter of je het geheel wel echt async kan doen. Je zult dan in het frontend een flink aantal dingen moeten aanpassen.

[humbug]

voodooless schreef op woensdag 22 augustus 2007 @ 14:48:
[...]


Goed punt, ik zal even krom te denken Je schiet er inderdaad niet veel mee op... De vraag is echter of je het geheel wel echt async kan doen. Je zult dan in het frontend een flink aantal dingen moeten aanpassen.

In dit geval is het inderdaad mogelijk om alles asynchroon te doen. Specifiek is er sprake van M2M communicatie waarbij er eigenlijk alleen maar een ontvangstbevestiging terug hoeft. Als er problemen geconstateerd worden, wordt er uiteindelijk weer een losse error afhandeling gestart. Daarom leent dit proces zich goed voor het splitsen. Belangrijk is dat we uiteindelijk de 20.000 berichten per seconden (peak) kunnen afhandelen die de specs vereisen. Dat het verwerken van de berichten daarna 24 uur duurt is eigenlijk niet belangrijk (tenminste als we sneller zijn dan de gemiddelde snelheid)

[flowerp]

humbug schreef op woensdag 22 augustus 2007 @ 15:34:
[...]
Daarom leent dit proces zich goed voor het splitsen. Belangrijk is dat we uiteindelijk de 20.000 berichten per seconden (peak) kunnen afhandelen die de specs vereisen

Uit nieuwsgierigheid, is dit je nu ooit nog gelukt?

[Alarmnummer]

humbug schreef op woensdag 22 augustus 2007 @ 15:34:
[...]In dit geval is het inderdaad mogelijk om alles asynchroon te doen. Specifiek is er sprake van M2M communicatie waarbij er eigenlijk alleen maar een ontvangstbevestiging terug hoeft. Als er problemen geconstateerd worden, wordt er uiteindelijk weer een losse error afhandeling gestart. Daarom leent dit proces zich goed voor het splitsen. Belangrijk is dat we uiteindelijk de 20.000 berichten per seconden (peak) kunnen afhandelen die de specs vereisen.

Als er geen afhankelijkheden tussen de berichten zijn dan is dit "embarrassing parallel", maw ieder bericht kan parallel naast ieder ander bericht verwerkt worden en voor dit soort problemen kun je dus heel eenvoudig een parallelle verwerking opzetten (schalen binnen een vm & binnen een cluster).

Als er wel afhankelijkheden zijn zou je met technieken zoals speculatieve executie wellicht parallellisatie mogelijk kunnen maken. Hiermee kun je die vervelende seriële secties toch omzeilen.

flowerp schreef op zaterdag 17 mei 2008 @ 11:35:
[...]
Uit nieuwsgierigheid, is dit je nu ooit nog gelukt?

+1

[ Voor 11% gewijzigd door Alarmnummer op 17-05-2008 12:19 ]