Jest apka, jest czytany zip w tej apce. Wczoraj niespodziewanie pojawił się problem na serwerze produkcyjnym z odczytywaniem zipa (ZIP_Read: error reading zip file). Na QA wszystko spoko hula. W kodzie ciężko coś znaleźć. Dokładnie w tym samym czasie, w którym pojawił się problem na produkcyjnym był robiony backup. Jeżeli to jest przyczyną problemu, to co wg Was poszło nie tak?
NB Problem rozwiązał restart.
0
1
Gonzik napisał(a):
Dokładnie w tym samym czasie, w którym pojawił się problem na produkcyjnym był robiony backup. Jeżeli to jest przyczyną problemu, to co wg Was poszło nie tak?
Zdecydowanie jest to chwila niepełnej współbieżności.
Serwer? Czyli wielodostęp ...
NB Problem rozwiązał restart.
pacjent nie żyje (instancja problematycznego procesu), choroba znikła. Rubryka zachorowań SIĘ ZMNIEJSZYŁA
1
Za mało danych. Nie podałeś wersji javy, wersji bibliotek, stack trace. Obstawiam wyciek jakiegoś zasobu/brak kontroli nad dostępem do zasobu, np. czytanie zipa, którego zapis się nie zakończył.
0
Aaaa i apka w chmurze azurowej, Java 8.Nie dam rady dzisiaj więcej wkleić. Zastanawiam się po prostu jakie scenariusze są najbardziej prawdopodobne w takiej sytuacji..
0
Trudno cokolwiek powiedzieć bez informacji jak wygląda ten ZIP_Read i na czym stoi. Możliwości jest dużo, np.
- próbujesz odczytać plik w trybie RW (odczyt + zapis), a plik jest zalockowany
- dobijasz do limitu otwartych plików na Linuksie
- masz jakąś pulę wątków, która jest zamykana
- plik podczas odczytu jest jednocześnie modyfikowany
- plik jest przenoszony z miejsca na miejsce w zły sposób
Itp. itd.
0
W tym zipie jest pdf i xlsx. Nie wkleję, bo sobie kłopotów narobię. Czy na czas backupu pliki się lockuje? (pytanie pewnie podstawowe, ale o backupach niewiele póki co wiem)
0
Gonzik napisał(a):
W tym zipie jest pdf i xlsx. Nie wkleję, bo sobie kłopotów narobię. Czy na czas backupu pliki się lockuje? (pytanie pewnie podstawowe, ale o backupach niewiele póki co wiem)
Wedle teorii tak, taki lockiem "do odczytu" (o ile w danej technologii taki istnieje). Lock "do odczytu" nie sprzeciwia się nałozeniu innych takich samych, ale będzie przeciwstawny próbom nałożenia locka rw.
Do tego dochodzi tzw "praktyka", zarówno linuksy, ale i windows ma sporo opcji alternatywnych, i nie wiemy jakich używa prowadzący backup.
Moze być otwarty na sposób wyłączny, i wtedy bezprzedmiotowe jest gadanie o lockach, "nie bo nie".
Dlaczego informatyka na xls mi się kojarzy z kłopotami ...
Gonzik napisał(a):
W tym zipie jest pdf i xlsx. Nie wkleję, bo sobie kłopotów narobię.
Ale problem nie ejst w tych plikach, tylko w kodzie który to robi
0
Dzięki wielkie. Ja w ogóle próbuję ten błąd odtworzyć lokalnie i mam z tym duży problem. Próbuję z corrupted zips, corrupted jars, ale tego exceptiona jakoś nie mogę dostać.
1
Gonzik napisał(a):
Dzięki wielkie. Ja w ogóle próbuję ten błąd odtworzyć lokalnie i mam z tym duży problem. Próbuję z corrupted zips, corrupted jars, ale tego exceptiona jakoś nie mogę dostać.
Ale w tym stacktrace (mam nadziję, ze zachowałeś) są wskazania albo na "matematykę"" (plik uszkodzony co do zawartości, wtedy nie myślimy o lockingu), albo na operacje IO.
Powtórzę to co wyraziłem wyżej, złe skojarzenia co do "informatyki excellowej". Bo moze podczas powstawania tego pliku - a nie twojego odczytu już pada bład. Statystycznie biorąc jakość kodu od Jasiów w makrach VBA nie jest nadmiernie wysoka (a nawet gdyby to był prze-guru excella, warunki naruszenia współbieżności to jest zdradliwe, nie występuje u twórcy)
2
Proponuję zbadać temat "niedokończonego zipa".
- utwórz pustego zipa (archiwum, które nie zawiera plików)
- spróbuj przetworzyć tak utworzoną paczkę
0
Yarel, miałeś rację! Nawet nie wiesz jak Ci dziękuję. Dokładnie przy pustym zipie leci: "java.util.zip.ZipException ZIP_Read: error reading zip file"