Tohle asi ve vysledku zvitezi, prave ze patram, jestli neexistuje neco jednodussiho.
Ad resource - komunikacni konektor treti strany, kontext je udrzovan na zaklade otevreneho spojeni, ne identifikatoru. Jirka -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oto Buchta Sent: Monday, July 21, 2008 4:29 PM To: Java Subject: Re: MDB a variabilni messageSelector 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 > >> > >> > > > > > > > > > > > > > > >
