Dscope: Bulutli server tizimlarida haqiqiy ma'lumotlarning buzilishini aniqlash

yangilanishini o'tkazib yuborishga olib keladi. Misol uchun, Cassandra-9881
xatosi bu turga mos keladi, 15-rasmda ko'rsatilgan. DataFile ( 131-qatordagi
RandomAccessReader ) buzilganda decorateKey() funksiyasi uni taniy olmaydi,
shuning uchun ÿ -satrda kalitni tayinlamasdan istisno qiladi. 130 (ya'ni, kalit ==
null) yoki ÿ134 qatorda dataFile.readLong() bajariladi . Ammo bu istisno oddiygina
e'tiborga olinmaydi, chunki ÿ140 qatorda bu halokatli emas. Kalit null bo'lsa,
scrub() funksiyasi IOError (187-satr) beradi , uni ushlaydi (207-satr) va e'tiborsiz
qoldiradi, chunki bu halokatli xato emas (208-satr). ÿ134 qatordagi dataFile.readLong()
ga qo'ng'iroq qilib indeksni (ya'ni, nol qadam) siljitmasdan , scrub() funksiyasi
bir joydan o'qishni davom ettiradi va abadiy aylanishni davom ettiradi.
Ushbu bo'limda biz DScope bo'yicha eksperimental baholashlarimizni taqdim etamiz.
Misol uchun, Yarn-6991 xatosi 14-rasmda ko'rsatilgan ushbu turga tegishli.
ShellCommandExecutor.execute() funksiyasi pidFile yaratish uchun kutilmoqda ,
uning mavjudligi while tsiklidan (89-satr) chiqishga yordam beradi. Disk
to'lganida, ShellCommandExecutor. execute() #74 qatorga istisno qiladi. Bu
istisno oddiy ro'yxatga olinadi. Shunday qilib, pidFile yaratilmasdan , ÿ89
qatordagi while tsikli hech qachon chiqmaydi.
rackToBlocks xaritasiga ÿ554 qator o'tkazib yuborilgan holda qo'yiladi . Bu oxir-
oqibat ÿ348-qatordagi while tsiklining osilib qolishiga olib keladi. Sababi, bu while
tsikli blockToNodes -dagi har bir blok olib tashlanguncha takrorlanadi. Afsuski,
faqat rackToBlocks xaritasida mavjud bo'lgan bloklarni olib tashlash mumkinligi
sababli (369 - ÿ371 qator), buzilgan blok hech qachon blockToNodes- dan