Asi jsem se spatne zeptal, tak to zkusim znovu: ve fronte, na kterou
jsou napojeny MDB v uzlu 1 a 2, jsou 2 zpravy. Obe zpusobi pristup k
temuz externimu zdroji. Jak je zajisteno, ze system neposle zpravu 1
na uzel 1 a zpravu 2 na uzel 2?
Jinak to "moje" reseni vypada takto: MDB pracuji tak jako dosud. Kdyz
ovsem MDB prijme zpravu, ktera znamena "pristup k externimu zdroji",
preposle tuto zpravu do zvlastni fronty. Tj. odesilatele se to nedotkne.
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]>:
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
