Konkurentni pristup resi javax.jms.Queue Vami nahvrhovane reseni bohuzel neni idealni. Jednak volajici nevi, zda bude nutny prisup k takovemu zdroji v ramci pozadavku, navic bych se pri pouziti jednoho uzlu zpracovavajiciho takove volani zbavil vyhod clusteru. Hledam co nejjednodussi reseni tak, abych nemusel menit stavajici system a infrastrukturu, kde jsou prave jednotlive nody rovnocenne.
Jirka -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zdenek Tronicek Sent: Monday, July 21, 2008 4:18 PM To: [email protected] Subject: RE: MDB a variabilni messageSelector Jak je zajisteno, ze kdyz napr. MDB na uzlu 1 prijme zpravu, ktera povede k volani externiho zdroje, tak soucasne neprijme takovou zpravu take MDB na uzlu 2? Jinak Vam asi nereknu nic noveho, ale nejjednodussi se mi jevi, aby MDB preposilaly vsechny zpravy, ktere zpusobi pristup k externim zdrojum, do samostatne fronty, odkud je bude synchronne vybirat nejaky objekt (a ten bude pouze jeden, tedy nebude clusterovany). Z.T. -- Zdenek Tronicek Department of Computer Science and Engineering Prague tel: +420 2 2435 7410 http://cs.felk.cvut.cz/~tronicek Quoting Jiří Holý <[EMAIL PROTECTED]>: > Proc ma kazdy node delat neco jineho? Ne, vsechny maji stejnou funkcnost; to > proc potrebuji v urcite chvili smerovani je dano tim, ze pouzivam nativni > resources, ktere jsou stavove a tedy neprenositelne mezi jednotlivymi uzly. > Pokud tedy dojde k otevreni kontextu u tohoto externiho zdroje, pak > potrebuji, aby kazde volani slo na konkretni node a dostalo se tak ke > "svemu" jiz otevrenemu externimu kontextu. Cetnost takovych pripadu je > prilis mala a cilem je zakomponovat tyto pozadavky do stavajiciho > klient-JMS-cluster. > > Ano, jsem si vedom moznosti JMS architektury, centralni JMS je prave > multi-broker (jboss HA-JMS). Snazim se vyhnout tvorbe JMS pro kazdy node > zvlast, pak by neslo jednoduse nahradit jednotlive vypocetni uzly. > > Jirka > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Zdenek Tronicek > Sent: Monday, July 21, 2008 2:45 PM > To: [email protected] > Subject: Re: MDB a variabilni messageSelector > > Dobry den, > > nechapu, proc chcete, aby uzly v clusteru delaly kazdy neco jineho. > Vzdyt preci hlavni myslenka clusteru je, ze jeden uzel muze zastoupit jiny. > Bezne to vypada v clusterovane aplikaci tak, ze MDB jsou na vice uzlech a o > rozdelovani zprav mezi uzly (load balancing) se stara JMS. > Pro vetsi spolehlivost lze pouzit multi-broker architekturu, v niz JMS > system bezi na nekolika uzlech (ne pouze na jednom) a uzly jsou spojeny do > JMS clusteru. Pokud selze spojeni na jeden JMS uzel, aplikacni server > provede fail-over na jiny, cimz je zajistena vyssi dostupnost. > > Z.T. > -- > Zdenek Tronicek > Department of Computer Science and Engineering > Prague tel: +420 2 2435 7410 > http://cs.felk.cvut.cz/~tronicek > > > Quoting Jiří Holý <[EMAIL PROTECTED]>: > >> Ahoj, >> narazil jsem na drobny problem a nedari se mi ho nijak vyresit nebo obejit >> (nebo neumim dobre hledat). Potreboval bych totiz neco jako zmenu >> messageSelectoru pro MDB za behu. Mluvim o EJB3. >> >> Cilem je totiz clusterovana aplikace, kde by kazdy node mel umet > vyzvednout >> prioritne ty zpravy, ktere jsou urceny pro nej a pote se podivat, jestli >> jsou nejake bez prirazeni. Vsechny node by mely byt ekvivalentni, proto > neni >> mozne pouzivat pro kazdy zvlast XML, kde bych prepsal anotace a tuto >> funkcionalitu zajistil. >> >> Resili jste nekdo obdobnou situaci, nebo mate navrh jak na to? >> >> Jirka >> >> > > > > > >
