mislim da su pominjali razloge u diskusiji - konkretno amq jeste prilicno trom, sa rabbitmq-om su imali probleme u disproporcionalnom broju producera vs. consumer-a (u trenucima kada krenu da se gomilaju porukice i imaju disproporciju u consumer-ima, desavalo im se da rabbitmq "pukne"), itd. - zapravo, bar sam se prilicno opekao pre 2-3 godine sa amq-om u malo ekstremnijim situacijama, ali cak na daleko manjem broju poruka u sekundi (konkretno - ~50-100 poruka u sekundi u peak-ovima, veliki broj producer-a i porukice od oko 20-40KB) - plus je bilo maltene nemoguce napraviti neki elegantniji monitoring posto bi odr. queue deadlock-ovao - ali bi ostatak queue-ova radio korektno i tako sam redom nailazio na razlicite probleme sa drugim JMS implementacijama (switfmq, mantaray, etc. etc.), tako da je pitanje sta je srecniji izbor - da li potrositi konacno vreme na tune-ovanje nekog od postojecih resenja, ili napisati nesto sto se ponasa dobro unutar okvira koji su potrebni. nemam pojma, nisam pametan - ali twitter ima veoma dobar inzenjerski tim, tako da kontam da razlozi nisu iracionalni. druga stvar je sto su mesecima bili pod izuzetnim pritiskom i sasvim sam siguran da je bar deo inzenjerskih poteza posledica toga.
|