Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: anonym 07. 07. 2018, 14:04:13
-
Mám metody A a B, obě vrací Integer. Já je budu chtít spustit paralelně v určitém momentě si vyzvednout jejich návratové hodnoty, takhle nejak bych si predstavoval pripad uziti:
Integer A() {...}
Integer B() {...}
int C() {
Task<Integer> taskA = TaskFactory.run(A);
Task<Integer> taskB = TaskFactory.run(B);
return D( taskA.getResultOrWait(), taskB.getResultOrWait() );
}
V C# bych na to sel pres Coroutiny, ale v Javě?
-
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html
A okolní třídy.
Pozor na to, ať neucpeš defaultní threadpool.
-
Přepiš to do Haskellu ;)
-
Co takto ?
public class MojeVlakno extends Thread {
int vysledek;
public void run() {
vysledek = 1;
}
public static void main(String[] args) throws Exception {
MojeVlakno vlakno = new MojeVlakno();
vlakno.start();
vlakno.join();
System.out.println("vysledek:"+vlakno.vysledek);
}
}
-
Co takto ?
public class MojeVlakno extends Thread {
int vysledek;
public void run() {
vysledek = 1;
}
public static void main(String[] args) throws Exception {
MojeVlakno vlakno = new MojeVlakno();
vlakno.start();
vlakno.join();
System.out.println("vysledek:"+vlakno.vysledek);
}
}
Čitelnost nic moc a když takhle budeš mít toho kódu víc...
-
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html
A okolní třídy.
Pozor na to, ať neucpeš defaultní threadpool.
Určitě jít touto cestou, např. přes java.util.concurrent.ExecutorCompletionService si pak můžete úlohy spustit a zase vyzvedávat, snadno měnit počet souběžně probíhajících úloh apod. Prostě je tam spousta věcí už naprogramovaných a hotových k pohodlnému použití. Udělat si to ručně má smysl jen pro sebevzdělání.
-
Co takto ?
public class MojeVlakno extends Thread {
int vysledek;
public void run() {
vysledek = 1;
}
public static void main(String[] args) throws Exception {
MojeVlakno vlakno = new MojeVlakno();
vlakno.start();
vlakno.join();
System.out.println("vysledek:"+vlakno.vysledek);
}
}
Za tenhle kod se fakt styd a vsichni ostatni by si ho meli vzit jako odstrasujici priklad. Jednak je to necitelne, jednak to treba vubec neresi, ze doslo k chybe a je to (velmi spatne) preimplementovani existujiciho.
Pro OP: Future, CompletableFuture, prip. Flow.Producer a souvisejici, pokud to potrebujes reaktivni.
-
A jaký je rozdíl mezi Coroutinou a Feature? Mě se zdá, že to umí to samé. Nebo ne?
-
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html
A okolní třídy.
Pozor na to, ať neucpeš defaultní threadpool.
Tzn. já si z něj můžu vzít jen určitý počet vláken? Z toho mi ale hrozí deadlock, ne? Proč tam prostě není nekonečný počet vláken?
-
Tzn. já si z něj můžu vzít jen určitý počet vláken? Z toho mi ale hrozí deadlock, ne? Proč tam prostě není nekonečný počet vláken?
Protoze neni efektivni napr. na 2 jadru spustit 100 vlaken :-) Pokud ti hrozi deadlock, tak to mas spatne navrzene.
Myslenka future a dalsich je takova, ze se jedna o nezavisle vypocty, ktere postupne chceme ziskat - tzn. neco jako deadlock by tu vubec nemelo mit moznost nastat.
Samozrejme si muzes udelat i vlastni threadpool, ale stejne to zavani spatnym navrhem.
-
Tzn. já si z něj můžu vzít jen určitý počet vláken? Z toho mi ale hrozí deadlock, ne? Proč tam prostě není nekonečný počet vláken?
Protoze neni efektivni napr. na 2 jadru spustit 100 vlaken :-) Pokud ti hrozi deadlock, tak to mas spatne navrzene.
Myslenka future a dalsich je takova, ze se jedna o nezavisle vypocty, ktere postupne chceme ziskat - tzn. neco jako deadlock by tu vubec nemelo mit moznost nastat.
Samozrejme si muzes udelat i vlastni threadpool, ale stejne to zavani spatnym navrhem.
Ale prd není efektivní, když voláš nějakou vzdálenou službu, nebo čekáš na výsledek dotazu v databázi, nebo něco stahuješ, tak je ti jedno, že máš 100 threadů a jen 2 jádra.
-
Tzn. já si z něj můžu vzít jen určitý počet vláken? Z toho mi ale hrozí deadlock, ne? Proč tam prostě není nekonečný počet vláken?
Protoze neni efektivni napr. na 2 jadru spustit 100 vlaken :-) Pokud ti hrozi deadlock, tak to mas spatne navrzene.
Myslenka future a dalsich je takova, ze se jedna o nezavisle vypocty, ktere postupne chceme ziskat - tzn. neco jako deadlock by tu vubec nemelo mit moznost nastat.
Samozrejme si muzes udelat i vlastni threadpool, ale stejne to zavani spatnym navrhem.
Ale prd není efektivní, když voláš nějakou vzdálenou službu, nebo čekáš na výsledek dotazu v databázi, nebo něco stahuješ, tak je ti jedno, že máš 100 threadů a jen 2 jádra.
Nie je pravda. Vlákna majú výkonostný dopad a výraznejší ako sa zdá. Jeden z dôvodov prečo sa prešlo na event orientované riešenia pri veľkej zátaži.
Každé vlákno musí byť spustené, aby zistilo, či môže pokračovať, a keď je ich 10, tak to je akceptovateľné, ale ak ich je 1000 a je tam slabé CPU, tak to výrazne spomaľuje beh.
-
Ale prd není efektivní, když voláš nějakou vzdálenou službu, nebo čekáš na výsledek dotazu v databázi, nebo něco stahuješ, tak je ti jedno, že máš 100 threadů a jen 2 jádra.
Neni to jedno, protoze kazde to jadro ma rezii na vytvoreni, zasobnik (a obecne TLS), scheduler, ale je pravda, ze se to pouziva aspon v nekterych pripadech (ale urcite to neni dobry napad pri 100 threadech). Kazdopadne u takoveho pripadu neni vubec vhodne pouzit default pool, ale vlastni. Smyslem default poolu je prave byt prizpusobeny efektivnejsimu zpracovani paralelnich (vypocetnich) uloh na danem HW.
Ale stejne nevidim moc zadny duvod proc treba pro provolani vzdalene sluzby nepouzit radeji asynchronni / event driven API. U JDK 9+ je na to HttpClient, pouzit ho umi napr. Spring WebClient.
U databaze (pokud to neni nejaka NoSQL) to samozrejme nejde, protoze JDBC a sprava transakci, ale tam zase tezko bude hrozit 100 vlaken a nebo je to velmi mizerny design, pokud by jeden request udelal tolik spojeni do DB :-)
-
Tzn. já si z něj můžu vzít jen určitý počet vláken? Z toho mi ale hrozí deadlock, ne? Proč tam prostě není nekonečný počet vláken?
Protoze neni efektivni napr. na 2 jadru spustit 100 vlaken :-) Pokud ti hrozi deadlock, tak to mas spatne navrzene.
Myslenka future a dalsich je takova, ze se jedna o nezavisle vypocty, ktere postupne chceme ziskat - tzn. neco jako deadlock by tu vubec nemelo mit moznost nastat.
Samozrejme si muzes udelat i vlastni threadpool, ale stejne to zavani spatnym navrhem.
Ale prd není efektivní, když voláš nějakou vzdálenou službu, nebo čekáš na výsledek dotazu v databázi, nebo něco stahuješ, tak je ti jedno, že máš 100 threadů a jen 2 jádra.
Nie je pravda. Vlákna majú výkonostný dopad a výraznejší ako sa zdá. Jeden z dôvodov prečo sa prešlo na event orientované riešenia pri veľkej zátaži.
Každé vlákno musí byť spustené, aby zistilo, či môže pokračovať, a keď je ich 10, tak to je akceptovateľné, ale ak ich je 1000 a je tam slabé CPU, tak to výrazne spomaľuje beh.
Je pravda.
Když máš webovou službu, tak tam může v 1 okamžik klidně být 1000 requestů naráz, tzn. 1000 threadů naráz. Tak nějak si to musí ten systém pošéfovat. Hoši, běžte si počítat ty vaše Fibonaciho posloupnosti jinam, tady se řeší Java a pořádné systémy 8)
-
Je pravda.
Když máš webovou službu, tak tam může v 1 okamžik klidně být 1000 requestů naráz, tzn. 1000 threadů naráz. Tak nějak si to musí ten systém pošéfovat. Hoši, běžte si počítat ty vaše Fibonaciho posloupnosti jinam, tady se řeší Java a pořádné systémy 8)
Jestli trollíš a snažíš se hrát prasiče, tak ti to celkem jde.
Jak je třeba obsluhovat spoustu požadavků zároveň tak je dost blbé spouštět hromady vláken. Pro čekání na IO nepotřebuju hromady alokované paměti pro zásobník a další blbiny. Každý relativně moderní OS a jen trochu příčetný framework (včetně Javy) podporují asynchronní IO.
Z těch 1000 requestů v každém okamžiku většina čeká (na disk, síť, ...). Na to nepotřebuje vlákno.
-
Je pravda.
Když máš webovou službu, tak tam může v 1 okamžik klidně být 1000 requestů naráz, tzn. 1000 threadů naráz. Tak nějak si to musí ten systém pošéfovat. Hoši, běžte si počítat ty vaše Fibonaciho posloupnosti jinam, tady se řeší Java a pořádné systémy 8)
Jestli trollíš a snažíš se hrát prasiče, tak ti to celkem jde.
Jak je třeba obsluhovat spoustu požadavků zároveň tak je dost blbé spouštět hromady vláken. Pro čekání na IO nepotřebuju hromady alokované paměti pro zásobník a další blbiny. Každý relativně moderní OS a jen trochu příčetný framework (včetně Javy) podporují asynchronní IO.
Z těch 1000 requestů v každém okamžiku většina čeká (na disk, síť, ...). Na to nepotřebuje vlákno.
To je tu furt jak u blbých. Ano, když obsluhuješ 1000 requestů naráz, nebudeš paralelizovat flow, protože je to zbytečné a nic to nezrychlí. Čti pořádně co píšu, já jsem reagoval na to, jak tu někdo psal, že 1000 vláken je moc velká zátěž.
Pokud mám interní inf. systém, kde je maximálně třeba 5 požadavků naráz, tak můžu urychlit blokující operace tím, že vytvořím další vlákna, a těch ať si je dohromady klidně 1000. Kapišto?
-
Ano, když budeš počítat ovečky v 1000 vláknech naráz a máš jen 4 jádra, jsi blbec na tisícátou. Ale když těch 1000 vláken je kvůli provedení blokujících operací, které můžou trvat každá třeba 500ms, tak je to OK. Ano, je tam navíc zátěž kvůli těm vláknům samotným, ale ne taková, aby to vyvážilo blokující operaci o délce trvání třeba 50ms za každou.
Rozumíte nebo je to moc těžké na pochopení?
Takže, klasický interní informační systém, který používá tak 10 lidí naráz, může klidně mít paralelizované flow pro blokující operace, NE PRO RYCHLOST VÝPOČTU. Pro říkám, ať si jdete počítat fibonaciho posloupnosti (akademicti teoretici) někam jinam, protože tohle je praxe.
-
Ano, když budeš počítat ovečky v 1000 vláknech naráz a máš jen 4 jádra, jsi blbec na tisícátou. Ale když těch 1000 vláken je kvůli provedení blokujících operací, které můžou trvat každá třeba 500ms, tak je to OK. Ano, je tam navíc zátěž kvůli těm vláknům samotným, ale ne taková, aby to vyvážilo blokující operaci o délce trvání třeba 50ms za každou.
Rozumíte nebo je to moc těžké na pochopení?
Takže, klasický interní informační systém, který používá tak 10 lidí naráz, může klidně mít paralelizované flow pro blokující operace, NE PRO RYCHLOST VÝPOČTU. Pro říkám, ať si jdete počítat fibonaciho posloupnosti (akademicti teoretici) někam jinam, protože tohle je praxe.
A nebo to udelas poradne, misto threadu pro blokujici operace to udelas reaktivni, coz zpusobi, ze to bude jeste rychlejsi, potrebovat mene pameti, nebude to zatezovat OS a ty vlakna pak muzes na neco efektivnejsiho, napr. kdyz potrebujes skutecne neco, co bezi paralelne :-)
Trosku jsi s timhle pristupem zaspal dobu, takhle se veci delaly 10 let zpatky.
-
Ano, když budeš počítat ovečky v 1000 vláknech naráz a máš jen 4 jádra, jsi blbec na tisícátou. Ale když těch 1000 vláken je kvůli provedení blokujících operací, které můžou trvat každá třeba 500ms, tak je to OK. Ano, je tam navíc zátěž kvůli těm vláknům samotným, ale ne taková, aby to vyvážilo blokující operaci o délce trvání třeba 50ms za každou.
Rozumíte nebo je to moc těžké na pochopení?
Takže, klasický interní informační systém, který používá tak 10 lidí naráz, může klidně mít paralelizované flow pro blokující operace, NE PRO RYCHLOST VÝPOČTU. Pro říkám, ať si jdete počítat fibonaciho posloupnosti (akademicti teoretici) někam jinam, protože tohle je praxe.
A nebo to udelas poradne, misto threadu pro blokujici operace to udelas reaktivni, coz zpusobi, ze to bude jeste rychlejsi, potrebovat mene pameti, nebude to zatezovat OS a ty vlakna pak muzes na neco efektivnejsiho, napr. kdyz potrebujes skutecne neco, co bezi paralelne :-)
Trosku jsi s timhle pristupem zaspal dobu, takhle se veci delaly 10 let zpatky.
Omg, reaktivní architekturu si dělejte u těch vašich javascriptových sraček. Přístup, který já zmiňuju, se nedělal před 10 lety, dělal se už před 50 lety a bude se dělat pořád. Reaktivní programování se používá u webového UI a je to výsledek objevování kola, webolepiči.
-
Bych chtěl vidět jak by jsi složitou bankovní business logiku udělal reaktivně a potom to debugoval, to by se ti protáčely panenky.
-
A v Javě se to "reaktivní programování" používá dávno, už od dob Swingu. Taky C++ Qt používá v podstatě "reaktivní programování", je to dokonce přímo vsazeno do toho frameworku. Všude kde je UI se používalo "reaktivní programování" snad vždy. Pointa této filozofie je možná taková, že když máš UI a chceš ho udělat responsivní, aby uživatel na každou akci viděl reakci, tak použiješ události. Není to nic nového, to si uvědom, to jenom vy z javascriptu co lepíte webovky si a děláte to dokolečka dokola si myslíte, že to je celý svět.
Ono, nakonec, můj přístup je reaktivní programování taky. Ale flow mezi kliknutím na buttonek a zobrazením výsledku je obrovské, složité a dlouho trvá.
-
Ono v plnotučném javoském backendu se událostmi řízené programování používá taky, ale jen tam, kde je potřeba. Je to jen jedno paradigma vhodné na určitý usecase. Lidi co dělají UI kdežto používají snad jenom toto paradigma, ale Javista musí umět dělat obojí.
Jsi mě naštval, protože jsem se jednou octl mezi javascriptářema, kteří pořád kydali ohledně reaktivního programování a na mě se dívali jak na nějakého dinosaura. A mě bylo zatěžko jim říct, že o tom vlastně vědí hovno a že to je paradigma vhodné na jejich usecase.
Taky pořád prudili s funkcionálním programováním, to mě taky štvalo. Že já jsem dinosaurus co dělá ještě to OOP v Javě. A mě bylo zatěžko jim říct, že v tom svém funkcionálním programování budou, v jejich případě, dělat stejné nečitelné hovna, jako by byli dělali v OOP, protože psát pěkný kód se dá v ledacčem.
No nic.
-
Každé vlákno musí byť spustené, aby zistilo, či môže pokračovať, a keď je ich 10, tak to je akceptovateľné, ale ak ich je 1000 a je tam slabé CPU, tak to výrazne spomaľuje beh.
Tak máš hodně špatný operační systém. V normálním systému je zátěž CPU vlákna čekající na událost zcela zanedbatelná. Co není zanedbatelné, je spotřeba paměti a to je skutečný důvod, proč se např. na webserveru Nginx používá epoll místo vláken.
Něco jiného je, když to vlákno skutečně něco dělá. Potom je asi celkově rychlejší úlohy spouštět postupně nebo jen podle počtu CPU. Tu zátěž CPU nezpůsobuje "zjišťování, zda může pokračovat", ale ukládání stavu CPU a přepisování cache.
-
Tzn. já si z něj můžu vzít jen určitý počet vláken? Z toho mi ale hrozí deadlock, ne? Proč tam prostě není nekonečný počet vláken?
Protoze neni efektivni napr. na 2 jadru spustit 100 vlaken :-) Pokud ti hrozi deadlock, tak to mas spatne navrzene.
Myslenka future a dalsich je takova, ze se jedna o nezavisle vypocty, ktere postupne chceme ziskat - tzn. neco jako deadlock by tu vubec nemelo mit moznost nastat.
Samozrejme si muzes udelat i vlastni threadpool, ale stejne to zavani spatnym navrhem.
A to jste vzal kde? Pokud se bavíme o zelených vláknech, tak je to efektivní i v řádu tisíců a ani řády desetitisíců nejsou nějak kor moc neefektivní. Na tomhle je postaveno např. Go a v těchto typech úloh drtí Javu celkem s přehledem jak ve zdrojích, tak v celkovém výkonu.
-
A to jste vzal kde? Pokud se bavíme o zelených vláknech, tak je to efektivní i v řádu tisíců a ani řády desetitisíců nejsou nějak kor moc neefektivní. Na tomhle je postaveno např. Go a v těchto typech úloh drtí Javu celkem s přehledem jak ve zdrojích, tak v celkovém výkonu.
Bavime se tu celou dobu o Jave, kde vlaknovy model je 1:1 a tudiz to efektivni neni. Java vlakno = OS vlakno. Go pouziva Coroutine.
V Jave pro podobny model existuje spousta moznosti tez - pocinaje CompletableFuture pres Reactive Streams / RxJava / Reactor, konce necim jako je Quasar, ktery by se mel v praci Project Loom dostat primo do JDK :-)
-
Každé vlákno musí byť spustené, aby zistilo, či môže pokračovať, a keď je ich 10, tak to je akceptovateľné, ale ak ich je 1000 a je tam slabé CPU, tak to výrazne spomaľuje beh.
Tak máš hodně špatný operační systém. V normálním systému je zátěž CPU vlákna čekající na událost zcela zanedbatelná. Co není zanedbatelné, je spotřeba paměti a to je skutečný důvod, proč se např. na webserveru Nginx používá epoll místo vláken.
Něco jiného je, když to vlákno skutečně něco dělá. Potom je asi celkově rychlejší úlohy spouštět postupně nebo jen podle počtu CPU. Tu zátěž CPU nezpůsobuje "zjišťování, zda může pokračovat", ale ukládání stavu CPU a přepisování cache.
Vychádzam z toho, že pri každom prepínaní vlákna sa musí prehodiť stack (registre) a v prípade event-u je to v nejakom pool-e, ktoré má svoj stack nezávislý od zaregistrovaných udalostí.
Vychádzam z dokumentácie, ktorú zverejnil MS ohľadom správania sa vlákien nad IO operáciami, ale je to dosť starý článok (odkaz nemám). Pekne tam popisovali dopad výkonu pri IO operáciach v porovnaní s udalosťami.
Z aplikačného pohľadu je ten výkonnostný dopad marginálny, s tým súhlasím. Ale programoval som aj embedd (Windows Embedd CE), kde hodiť vlákno nad každú prkotinu s IO je dosť ťažký údel na HW úrovni. Fakticky to záleží od prípadu užitia, ale vlákna so sebou ťahajú dosť veľa batožiny. Osobne pochybujem, že toto nejako magicky ošetrili v ostatných OS.
Pokiaľ viem Linux (rok 2000+ tuším) tiež trpel týmto problémom, keď priorizoval operácie a namiesto toho použili podobný trik, ale ešte nie na úrovni udalostí a to, že hodili do skupín úlohy s podobnou prioritou a jednoducho ich spustili namiesto toho, aby kontrolovali, kto má prednosť.
-
Z aplikačného pohľadu je ten výkonnostný dopad marginálny, s tým súhlasím. Ale programoval som aj embedd (Windows Embedd CE), kde hodiť vlákno nad každú prkotinu s IO je dosť ťažký údel na HW úrovni. Fakticky to záleží od prípadu užitia, ale vlákna so sebou ťahajú dosť veľa batožiny. Osobne pochybujem, že toto nejako magicky ošetrili v ostatných OS.
Dopad neni marginalni. V praci jsme vyvijeli napr. daemon, ktery paralelne procesuje statistice konkurentnich TCP spojeni, epoll se v takovem pripade rozhodne neprobouzi s jednou udalosti na jednom socketu.
V opacnem pripade, i kdybysme zanedbali pametovou narocnost, tak nepouzit epoll (ale misto toho blokujici vlakna) by znamenalo misto jednoho vlakna probrat vetsi mnozstvi vlaken - tudiz vyrazne vetsi CPU zatez a rezii.
-
Dopad neni marginalni. V praci jsme vyvijeli napr. daemon, ktery paralelne procesuje statistice konkurentnich TCP spojeni, epoll se v takovem pripade rozhodne neprobouzi s jednou udalosti na jednom socketu.
V opacnem pripade, i kdybysme zanedbali pametovou narocnost, tak nepouzit epoll (ale misto toho blokujici vlakna) by znamenalo misto jednoho vlakna probrat vetsi mnozstvi vlaken - tudiz vyrazne vetsi CPU zatez a rezii.
Bezpodmienečne súhlasím. Skôr apelujem na borekz s jeho vyhlásením, že to je v poriadku. Z pohľadu OS a HW sa deje presne toto, vysoká záťaž CPU a pamäte, lebo sa musí prehadzovať existujúci a čakajúci stack na HW vlákno. V aplikácií sa ale vykoná minimum inštrukcií a výkonnostný dopad je v tejto časti takmer žiadny, všetko si odnesie OS a HW.
-
Bezpodmienečne súhlasím. Skôr apelujem na borekz s jeho vyhlásením, že to je v poriadku. Z pohľadu OS a HW sa deje presne toto, vysoká záťaž CPU a pamäte, lebo sa musí prehadzovať existujúci a čakajúci stack na HW vlákno. V aplikácií sa ale vykoná minimum inštrukcií a výkonnostný dopad je v tejto časti takmer žiadny, všetko si odnesie OS a HW.
To jsem te asi nepochopil - to, ze aplikace zpracuje jen zlomek RPS pri pouziti blokujicich vlaken oproti pouziti udalostnich / reaktivnich mechanismu, me totiz prislo jako docela velky aplikacni dopad :-)
-
Takže, našel jsem asi nejlepší způsob jak dělat asynchronní kód ve Springu:
https://spring.io/guides/gs/async-method/
Stačí anotovat async metody jako @Async, o zbytek se postará Spring.
@Service
public class GitHubLookupService {
private static final Logger logger = LoggerFactory.getLogger(GitHubLookupService.class);
private final RestTemplate restTemplate;
public GitHubLookupService(RestTemplateBuilder restTemplateBuilder) {
this.restTemplate = restTemplateBuilder.build();
}
@Async
public CompletableFuture<User> findUser(String user) throws InterruptedException {
logger.info("Looking up " + user);
String url = String.format("https://api.github.com/users/%s", user);
User results = restTemplate.getForObject(url, User.class);
// Artificial delay of 1s for demonstration purposes
Thread.sleep(1000L);
return CompletableFuture.completedFuture(results);
}
}
Java to zase dokázala, je to asi nejlepší způsob psaní anync kódu co jsem zatím viděl.
Pokud dostane Java ten Quasar do JDK, tak ve Springu určitě přibude i možnost, aby to byly Fibery a nikoliv Thready. Možná už teď to ve Springu jde.
-
Ten Spring to má všechno tak dobře udělané, že snad budu psát i obyčejné ne-webové aplikace ve Springu. Protože to je fakt superní framework.
-
Ten Spring to má všechno tak dobře udělané, že snad budu psát i obyčejné ne-webové aplikace ve Springu. Protože to je fakt superní framework.
https://projects.spring.io/spring-shell/
-
Ono by to šlo vlastně už teď ten Async ve Springu předělat na Quasar fibers, díky to, že jde customizovat Executor:
@Bean
public Executor asyncExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(2);
executor.setMaxPoolSize(2);
executor.setQueueCapacity(500);
executor.setThreadNamePrefix("GithubLookup-");
executor.initialize();
return executor;
}
Nicméně mě ten Quasar stejně nezajímá, pro mé potřeby mi bude dostačovat obyčejný Thread. I kdyby jich byla 1000, tak to si myslím pořád bude pro mé potřeby plně dostačující.
-
Ten Spring to má všechno tak dobře udělané, že snad budu psát i obyčejné ne-webové aplikace ve Springu. Protože to je fakt superní framework.
To se uz davno resilo i delo, nez treba desktopove aplikace umrely - viz treba https://www.ibm.com/developerworks/java/tutorials/j-springswing/j-springswing.html - clanek z roku 2005 diskutujici pouziti Spring s Swingem :-)
Spring (core) neni zadnym zpusobem svazany s webem - tuhle vazbu resi Spring MVC.
-
Nicméně mě ten Quasar stejně nezajímá, pro mé potřeby mi bude dostačovat obyčejný Thread. I kdyby jich byla 1000, tak to si myslím pořád bude pro mé potřeby plně dostačující.
To, ze to pro tve potreby staci, neimplikuje ze to je efektivni a ze to nejde lepe. Navic diskuse byla o pozadavcich na vzdalenou sluzbu, coz je vec, ktera jde v JDK 9 udelat bez zbytecnych threadu out of the box (ci pripadne pomoci jinych knihoven i na starsi Jave - napr. reseni postavene na Netty clientu), Spring k tomu pouze poskytuje fasadu.]
A bavili jsme se o pripadu 1000 threadu, coz je skutecne vec, kterou bych rozhodne neimplikoval vlakny, ale reaktivne, protoze to bude mnohem efektivnejsi a realne to neni skoro zadna prace navic to implementovat poradne.
-
Nicméně mě ten Quasar stejně nezajímá, pro mé potřeby mi bude dostačovat obyčejný Thread. I kdyby jich byla 1000, tak to si myslím pořád bude pro mé potřeby plně dostačující.
To, ze to pro tve potreby staci, neimplikuje ze to je efektivni a ze to nejde lepe. Navic diskuse byla o pozadavcich na vzdalenou sluzbu, coz je vec, ktera jde v JDK 9 udelat bez zbytecnych threadu out of the box (ci pripadne pomoci jinych knihoven i na starsi Jave - napr. reseni postavene na Netty clientu), Spring k tomu pouze poskytuje fasadu.]
A bavili jsme se o pripadu 1000 threadu, coz je skutecne vec, kterou bych rozhodne neimplikoval vlakny, ale reaktivne, protoze to bude mnohem efektivnejsi a realne to neni skoro zadna prace navic to implementovat poradne.
Omg... jak to chces udelat reaktivne proboha. Mas nejake dlouhe flow, volaji se metody z ruznych @Service navzájem a ty budeš chtít blokující operace:
1. Queries
2. Volání vzdálených Service
Udělat asynchronně. Tak vemeš anotaci @Async, oanotuješ si s tím blokující metody a máš to hotové.
Co na tom chceš dělat proboha reaktivního?
-
Ten Spring to má všechno tak dobře udělané, že snad budu psát i obyčejné ne-webové aplikace ve Springu. Protože to je fakt superní framework.
To ma, je jen pomaly, coz je v poradku, pokud neni vykon priorita pro vyvoj backendu:
https://github.com/networknt/microservices-framework-benchmark
-
To ma, je jen pomaly, coz je v poradku, pokud neni vykon priorita pro vyvoj backendu:
https://github.com/networknt/microservices-framework-benchmark
Tak asi by se sluselo dodat, co ten benchmark meri - pocet requestu za vterinu, ktere zvladne technologie zpracovat odeslanim odpovedi "Hello world!".
Jako zajimavost dobry, ale uplne si to nepredstavuji jako relevantni metriku pro vyber technologie backendu :-)
-
Ten Spring to má všechno tak dobře udělané, že snad budu psát i obyčejné ne-webové aplikace ve Springu. Protože to je fakt superní framework.
To ma, je jen pomaly, coz je v poradku, pokud neni vykon priorita pro vyvoj backendu:
https://github.com/networknt/microservices-framework-benchmark
Tady jsou mnohem lepší benchmarky:
https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=update
-
To ma, je jen pomaly, coz je v poradku, pokud neni vykon priorita pro vyvoj backendu:
https://github.com/networknt/microservices-framework-benchmark
Tak asi by se sluselo dodat, co ten benchmark meri - pocet requestu za vterinu, ktere zvladne technologie zpracovat odeslanim odpovedi "Hello world!".
Jako zajimavost dobry, ale uplne si to nepredstavuji jako relevantni metriku pro vyber technologie backendu :-)
Cist umis a tu druhou cast beru jako vtip...
-
Ten Spring to má všechno tak dobře udělané, že snad budu psát i obyčejné ne-webové aplikace ve Springu. Protože to je fakt superní framework.
To ma, je jen pomaly, coz je v poradku, pokud neni vykon priorita pro vyvoj backendu:
https://github.com/networknt/microservices-framework-benchmark
Tady jsou mnohem lepší benchmarky:
https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=update
Jo, diky za link, jsem si nemohl vzpomenout na tenhle webik, diky.