Sklep Lidl

Po kilkudzieisęciu próbach od rana – Neo, znajdź źródło problem, błagam!

do Corvus monedula: Jeszcze opis problemu po dalszych badaniach: jeśłi upload pliku się nie powiódł to z tą nazwą się już nie uda. Zmiana nazwy pomaga, albo nie. To, kiedy pomoże, jest niewiadome. Gdy w końcu po n-tej zmianie nazwy zaskoczy dla jednego zdjęcia – będzie już działać dla kolejnych (chyba, że punkt pierwszy) przez jakiś czas. Zielonego pojęcia nie mam co może być przyczyną, ale problem musi być po stronie serwera.
Wszystkie wysyłane kawałki zdjęcia kończą się kodem HTTP 200, czyli zostają przyjęte przez serwer.

do Corvus monedula: A próbowałeś np. na Chrome albo Mozilli?

do Neo[EZN]: Tę porcję teraz zrobiłem z Firefoksa (żeby konsolę odpalić). Próbowałem i kilka razy wczesniej – takie same efekty jak z Epiphany, jedynie progress bar się inaczej rysuje.
Na Chromium jestem zalogowany do Googla, więc niczego poza googlem tam nie odpalam :-)

do Corvus monedula: Zmieniłem zapisywanie tymczasowych plików na serwerze - dałem im jako nazwę pliku md5 z oryginalnej nazwy, dodałem też zapisywanie wszystkich danych z Twojego konta w czasie ładowania pliku na serwer, daj znać kiedy pojawi się błąd (po dacie komentarza sprawdzę odpowiedni log na serwerze).

do Neo[EZN]: Czyli jeśli się dalej będzie waliło, to dalej będzie trzeba nazwę pliku zmieniać :-)
Zobaczymy rano… zdjęć w kolejce czeka bardzo wiele.

do Neo[EZN]: Dziś kilka poszło. Ciekawe, że tym razem efek był zależny od przeglądarki – czy jeśli się zaloguje z dwóch przeglądarek to tworzą się dwie sesje? Chyba tak, bo komentarze przeczytane na jednej są widoczne jako nieprzeczytane na drugiej. Czyli wychodziłoby na to, że jedna sesja się zwaliła, a druga nie.

do Corvus monedula: Co ciekawe pliki przechodziły prawidłowo - np. - zobaczymy czy problem jest z sesją czy nie, ewentualnie będę musiał jeszcze w jednym skrypcie zobaczyć co w sesji siedzi (jeżeli dziś znów pojawi się ten błąd).

do Neo[EZN]: No, tak jak napisałem – na każdy kawałek serwer odpowiada HTTP 200. Domniemane urywanie się przy 70-80% to chyba tylko kwestia aktualizacji progressbara na Epiphany.
No i najciekawsze jest to, że w środę jeszcze nie było problemów, a podobno nic się nie zmieniało :-)

do Corvus monedula: Nic się nie zmieniało - przynajmniej z mojej strony bo zmieniać się może sporo - począwszy od wersji przeglądarki poprzez internet (np. jakieś problemy z transmisją /przerywanie/) a na losowych problemach z serwerem skończywszy (brak miejsca na dysku, błędy zapisu plików itd...)

do Neo[EZN]: Problemy występują u co najmniej dwóch osób, na róznych przeglądarkach i różnych łączach – więc to wszystko nie ma wpływu. Zdjęcia docierają poprawnie na serwer, więc problemy z łączem po stronie FP też odpadają. Zostaje coś na serwerze.
To, że po jakimś czasie sie odblokowuje wygląda sugeruje kwestie związane ze miejscem na dysku/w sesji czy gdziekolwiek. No i ciekawe, że dotyczy tylko niektórych użytkowników.
Sprawdzałeś, czy nie lecą błędy z dysku?

do Corvus monedula: Błędy dysków sprawdzałem ale już widzę na czym polega problem.
Mamy zdjęcie 7MB - powinno pójść w dwóch kawałkach - 5 MB oraz 2 MB.

Krok 1 - Przeglądarka wysyła nagłówek do serwera z informacją o załączniku - plik, część 0 MB - 5 MB z 7 MB. A tu niespodzianka - załącznik ma 7 MB a nie 5 MB. Serwer zapisuje na dysku tymczasowy plik bo myśli że przyjdzie kolejna część w kroku nr 2 a tego kroku nie ma. Czyli deklaracja była na przesłanie 5MB danych a przesłała 7MB.

Gdzie może być problem? Podejrzewam, że coś musieli zmienić w przeglądarce i przestał prawidłowo działać skrypt js który wysyła pliki na serwer. Po załączeniu pliku przetwarzany jest on przez js i skrypt wysyła odpowiednie nagłówki do serwera czyli też ustawia content-range dzieląc plik na kawałki.

To co napisałeś potwierdza tę diagnozę - przeglądarka pokazuje progress 70-80% - bo to jest te 5MB z 7MB ale defacto wysyła cały plik za pierwszym requestem.

Mogę poszukać nowszej wersji skryptu ale wymiana może być dosyć czasochłonna jeżeli dużo się w nim zmieniło w międzyczasie a najprościej będzie jeśli zrobię wyjątek w skrypcie który odbiera dane - czyli jeżeli deklaracja będzie na 5MB z 7MB a przyjdzie mi plik 7MB to uznam że transfer został zakończony.

do Neo[EZN]: Dodałem wyjątek - jeżeli np. deklaracja jest na wysyłkę 1 - 5 000 000 z 8 720 121 bajtów a przyjdzie 8 720 121 to skrypt uzna że wysyłka została zakończona i plik zostanie przesłany do sesji.

do Neo[EZN]: Hmmm. O ile jest możliwe, że Epiphany na stacjonarnym się zaktualizowało akurat w tym tygodniu (nie pamiętam co było w aktualizacjach) to na laptopie jest ciągle stara wersja, a problemy pojawiały się i tam i na Firefoksach – chyba, że to wina danych sesji zepsutych wcześniej.

do Neo[EZN]: Niespecjalnie pomogło – teraz dochodzi do 70-80% i staje w miejscu :-)

do Corvus monedula: Jeżeli chodzi o ten błąd to sesja nie ma znaczenia, trzeba by było zerknąć co zmienili w Epiphany. Nie mam tej przeglądarki - mam same linuxy bez gui (wiadomo, do serwerów niepotrzebne) więc nawet nie sprawdzę jak to działa ale bez konsoli / trybu deweloperskiego i tak bym niewiele sprawdził.

do Corvus monedula: Tak bo w js nic nie zmieniałem tylko po stronie serwera. Dochodzi do 70-80% ale plik do serwera dociera w 100% więc jak staje pasek to możesz zaakceptować formularz dodawania zdjęcia (chyba że wyskakuje jakiś alert "bo zdjęcie nie jest wysłane").

do Neo[EZN]: Data się nie pokazuje, co sugeruje niezadziałanie.