Új hozzászólás Aktív témák

• emvy félisten

  #6879

  #6875 cacattila

  2015-02-20 12:08:56

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #6875 cacattila

  #6875 cacattila

  Ez esetben egy rendkívül ronda trükkel bár elérheted amit akarsz,viszont ez nem megbízható, ugyanis a GC-re hagyatkozol, arra meg nem nagyon vagy befolyással, és őszintén kétlem, hogy a feladatban ilyet kérnének, tekintve a körítést. Lényeg a lényeg, ha felülírod a finalize() metódust, akkor amikor a GC megszünteti az objektumot, akkor ez a fv 1x meghívódik. Ismétlem, nem tartom valószínűnek hogy ez a feladat célja,ugyanis erre nem lehet építkezni, mivel ilyenkor a számláló csökkentésének időzítése nem determinisztikus a program szempontjából. Gyanítom egy destruktorral rendelkező programnyelvhez való példát próbál a tanár Java-ra erőltetni, ez így kicsit veszélyes dolog.

  Plusz meg egy kellemetlen dolog, hogy semmi garancia nincs arra, hogy a finalizer valaha is meghivodik. Siman lehet, hogy soha nem hivja meg senki.

• Aethelstone addikt

  #6877

  #6875 cacattila

  2015-02-20 11:49:01

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6875 cacattila

  #6875 cacattila

  Ez esetben egy rendkívül ronda trükkel bár elérheted amit akarsz,viszont ez nem megbízható, ugyanis a GC-re hagyatkozol, arra meg nem nagyon vagy befolyással, és őszintén kétlem, hogy a feladatban ilyet kérnének, tekintve a körítést. Lényeg a lényeg, ha felülírod a finalize() metódust, akkor amikor a GC megszünteti az objektumot, akkor ez a fv 1x meghívódik. Ismétlem, nem tartom valószínűnek hogy ez a feladat célja,ugyanis erre nem lehet építkezni, mivel ilyenkor a számláló csökkentésének időzítése nem determinisztikus a program szempontjából. Gyanítom egy destruktorral rendelkező programnyelvhez való példát próbál a tanár Java-ra erőltetni, ez így kicsit veszélyes dolog.

  Nyilván az előző hsz-em alapján, ha nulloz a kolléga egy objektumpéldányt, akkor nyugodt szívvel csökkentheto a számlálóját. Az más kérdés, hogy értelme ennek a feladatnak annyi van, mint 6 pár használt rendőrcsizmának...

• Muton addikt

  #6751

  #6748 cacattila

  2015-01-16 18:39:58

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Muton

  addikt

  #6748 cacattila

  #6748 cacattila

  ebbol sztem ki tudsz indulni (jndi data sourcekent kell ra hivatkozni):
  [link]

  megnézem, köszi!

• Aethelstone addikt

  #5693

  #5690 cacattila

  2014-08-04 00:01:52

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #5690 cacattila

  #5690 cacattila

  A következő problémám lenne:

  A következő követelményekre lenne szükségem valamilyen kész komponenst, library-t használni:

  Egy központi gép, amit minden más gép elér.
  - Gépek alhálókban, ahol a gépek látják egymást és a központi gépet, viszont nem látják a más csoportokba tartozó gépeket.
  - Megbízható (persistent) üzenetváltás sok GB adat esetén is.
  - A hálózatnak tolerálnia kell gépek kiesését (kivéve a központi gép), és új gépek hozzáadását.
  - Minden gépnek teljes adatbázissal kell rendelkeznie, azaz egy ideig offline állapotban is minden adatnak rendelkezésre kell állnia.
  - Data collision nem számít. (ugyanolyan id, action, result sosem fog történni)
  - Minden üzenetnek meg kell érkeznie minden gépre, még abban az esetben is, ha olyan gép küldte amely még azelőtt levált a hálózatról, hogy új gép lépett volna be a csoportba.
  - Jó lenne, ha a megldás csak és kizárólag Java nyelven állna rendelkezésre (ez a követelmény nem kritikus, végső esetben lehet natív kód is).

  Jelenleg van erre megoldásunk egy legacy kód személyében, viszont a megoldásban sok a hiba, ami miatt egy kész, bizonyított megoldásra szeretnénk váltani. Szóval összességében vmi fa jellegű, ad-hoc hálózaton alapuló, fault-tolerant adatreplikációt szeretnénk elérni. Van-e vkinek tapasztalata ilyen téren, illetve milyen megoldások jöhetnek szóba szerintetek?

  Active MQ

• emvy félisten

  #5691

  #5690 cacattila

  2014-08-03 19:40:34

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #5690 cacattila

  #5690 cacattila

  A következő problémám lenne:

  A következő követelményekre lenne szükségem valamilyen kész komponenst, library-t használni:

  Egy központi gép, amit minden más gép elér.
  - Gépek alhálókban, ahol a gépek látják egymást és a központi gépet, viszont nem látják a más csoportokba tartozó gépeket.
  - Megbízható (persistent) üzenetváltás sok GB adat esetén is.
  - A hálózatnak tolerálnia kell gépek kiesését (kivéve a központi gép), és új gépek hozzáadását.
  - Minden gépnek teljes adatbázissal kell rendelkeznie, azaz egy ideig offline állapotban is minden adatnak rendelkezésre kell állnia.
  - Data collision nem számít. (ugyanolyan id, action, result sosem fog történni)
  - Minden üzenetnek meg kell érkeznie minden gépre, még abban az esetben is, ha olyan gép küldte amely még azelőtt levált a hálózatról, hogy új gép lépett volna be a csoportba.
  - Jó lenne, ha a megldás csak és kizárólag Java nyelven állna rendelkezésre (ez a követelmény nem kritikus, végső esetben lehet natív kód is).

  Jelenleg van erre megoldásunk egy legacy kód személyében, viszont a megoldásban sok a hiba, ami miatt egy kész, bizonyított megoldásra szeretnénk váltani. Szóval összességében vmi fa jellegű, ad-hoc hálózaton alapuló, fault-tolerant adatreplikációt szeretnénk elérni. Van-e vkinek tapasztalata ilyen téren, illetve milyen megoldások jöhetnek szóba szerintetek?

  Erdekes kerdes, par eve mar irtam egy ilyen rendszert, de a messaging maga az LatencyBusters/Ultra Messaging alapokon ment, ami egy IP multicast alapu szuperalacsony kesleltetesu uzenetkuldo rendszer, asszem mostmar az Informatica arulja, tehat csak a gepenkenti elosztott in-memory adatbazist csinaltam. Akkor meg nem talaltam pont ilyen, kesz rendszert -- a messaging reszre van csomo alternativa. (Mi olyan napi par szazmillio uzenetig skalaztuk a dolgot, a nap az 7.5 orat jelentett, LBM/UMS siman megoldja a konkret uzenetkuldest.)

  A te esetedben ugy latom, az offline felhasznalas a legtrukkosebb resze a dolognak, altalanos megoldas erre biztosan nincs. Az offline verziot csak olvasasra hasznalnad, ugye? (Ha nem, az elsore nem tunik trivialisnak, mert valamilyen policy kellene arra, hogy kezeld a konfliktusokat/inkonzisztenciat.)

Új hozzászólás Aktív témák