No asi bude mit clusterovanou frontu. To neni problem. Problem vidim jinde.
Potrebuje pro JMSko zaridit obdobu Session Afinity. Musim se priznat,
ze s necim takovym jsem se jeste nepotkal. Osobne bych doporucoval resit to
stejne a rucne.
Mit clusterovanou master MBeanu, ktera bude dostavat pozadavky a rozhazovat
je podrizenym. Pokud se jedna o prvni zpravu sessiony, posle ji na
clusterovanou slave frontu. Pokud uz je to nekolikata, dle nejakeho
kriteria se pokusi najit odpovidajici lokalni neclusterovanou frontu.
Registraci front dle kriterii bych resil samozrejme pres clusterovane JNDI.

A aby nedoslo k prijmu seqence zprav ruznymi mbeanami diky pozdni registraci,
prijeti zpravy bych potvrzoval az po registraci.

Ale musim rict, ze porad nechapu vocogo. Co je to vlastne za resource,
ktery je stavovy a otevirany jenom na jedne strane, kdyz se k nemu pristupuje
pres MBeany? Neslo by to resit clusterovane pres session statefull EJBcka?

tapik
 
On Mon, Jul 21, 2008 at 04:18:03PM +0200, Zdenek Tronicek wrote:
> 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