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












Odpovedet emailem