Laravel 11-ben fut egy projektem, amolyan 1.5 személyes fejlesztésként.
Belefutottam egy nagyon furcsa hibába: kontroller meghív egy blade-et, ami feldolgoz egy session-ben átadott tömböt és más adatokat. Majd a blade-en elhelyezett gomb lenyomására meghívódik egy másik kontroller, amely a blade-en történt adatbevitelt és a session-ban eltárolt tömböt is feldolgozza.
Namármost, az esetek döntő többségében ez így rendben lefut, a második kontroller szépen működik.
Azonban időnként, mondjuk az esetek 5-8%-ban a session-ben eltárolt tömb nem érkezik meg a blade feldolgozását követően a második kontrollerhez. Korábban beírt és használt egyszerűbb változóim megvannak, de a tömb nincs meg.
Egyrészt a /storage/framework/session alatt megvan a session file és látom, hogy a mérete hogy növekszik és csökken, amikor rendben működik a program. Másrészt írtam egy log függvényt, ami szépen egy napló állományban kiírja a session tartalmát.
Egyértelműen látszik, hogy a blade file feldolgozásánál a session-ben elhelyezett tömb még ott van, de a 2. kontrollerhez esetenként nem jut el.
A session()->put($variable) után próbáltam a Session::save()-et, de ugyanúgy előjön a hibajelenség.
Arra gyanakszom, hogy esetleg a projekt beállításában lehet valamilyen gond.
Találkozott már valaki ilyen jelenséggel?
Hogyan lehetne még jobban behatárolni a hibát?
Mi lehet a megoldás?
Minden tippet, ötletet, javaslatot szívesen fogadok!
- 497 megtekintés
Hozzászólások
Up, hátha...
- A hozzászóláshoz be kell jelentkezni
Debugerrel próbáltad? Meg kéne nézni, hol tűnik el a tömb. Nem nyúl hozzá olyan függvény, ami módosítja is (és véletlenül kiüríti vagy null-ra állítja)?
- A hozzászóláshoz be kell jelentkezni
A ddd() amit használok, de itt olyan a folyamat, hogy külön log.txt-be dump-olom ki az adatokat. Láma kérdés, de milyen debuggert használhatnék, ha jót akarnék magamnak?
- A hozzászóláshoz be kell jelentkezni
A ddd() nem az igazi, mert megáll vele a futás. XDebug, azt szinte minden PHP csomagnál csak max be kell kapcsolni és minden IDE támogatja. De ha élesen futó rendszer és nem tudod helyi környezetben reprodukálni, akkor ez lehet nem opció. Marad a fájlba logolás, én a teljes session tartalmát kiírnám fájlba egy json_encode után, mindenhol, ahol lekéred vagy módosítod a sessiont (akár elé és mögé is).
Célszerű lehet még megnézni az acces_log-ot (vagy hasonlót, ha nem Apache alatt fut), hogy tényleg nincs-e más kliens, akár egy cron job, API hívás, ami hatással lehet rá. Esetleg PHP-t beszédesebb log módba rakni ás error_log-ot / php_errors-t figyelni.
- A hozzászóláshoz be kell jelentkezni
Nem értem ugyan az említett varázsszavakat, ezért csak annyit tudok javasolni, nézd meg, hogy milyen lemezhely fogyott el (inode is számít).
- A hozzászóláshoz be kell jelentkezni
A rendszergazda szerint van hely bőven. Nagyjából 2200 byte a session file mérete, amikor benne van a megfelelő adat, 450 byte, amikor nincs benne.
- A hozzászóláshoz be kell jelentkezni
Szerintem valahol valaki nyom rajta egy unset-et, vagy egy session put-ot null értékkel.
- A hozzászóláshoz be kell jelentkezni
Ha mindig kiesne belőle az adat, akkor egyértelműen az én hibás kódom lehetne az ok. A gond az, hogy nagyjából minden 8. vagy 10. futásnál hiányzik az adat a session-ből. Van, amikor zsinórban 3szor nem működik, utána sokáig igen.
- A hozzászóláshoz be kell jelentkezni
első kérdésem, milyen session drivert használsz? ha megváltoztatod redisre, vagy sql-re, akkor mi a helyzet?
nincs-e race condition? bár ugye elvileg lockolva van a session, amíg meg van az nyitva, arra más kérés nem érkezhetne
nem lehet, hogy túl nagy a session mérete, ezért nem tudja menteni? (nem ismerem a laravelt, de symfonyban serlialzálva menti a sessiont ilyen esetben)
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
- A hozzászóláshoz be kell jelentkezni
A session driver: file
Éles rendszer, nem akarok kísérletezni (most abba ne menjünk bele, hogy miért ilyen a projekt; éppen dolgozunk a kollégával azon, hogy kezelhetőbb legyen az ügy).
Nincs versenyhelyzet, én tesztelem, nincs senki más közben a rendszerben.
A session kb 2 kbyte méretű, amikor benne van a kívánt tartalom. Ez nem hiszem, hogy számottevő méret.
- A hozzászóláshoz be kell jelentkezni
Hasonló esetben az volt a gond hogy a localstorage mérete meghaladta a böngésző limitet (túl nagy cookie) és egyszerűen eldobta
- A hozzászóláshoz be kell jelentkezni
Nem használok cookie-kat, csak a session-t. A localstorage - ha jól értem - kliens oldali adattárolásra való, én pedig csak simán a session()->put() függvény hívom meg.
- A hozzászóláshoz be kell jelentkezni
Session lifetime nem jár le?
- A hozzászóláshoz be kell jelentkezni
Az a furcsa, hogy nem a teljes session tartalom tűnik el. Néhány korábbi változóm vígan megtalálható akkor is, amikor a két tömbömnek már csak hűlt helyét látom, 10 esetből mondjuk 2-nél.
Teljesen kiszámíthatatlan, mikor veszik el menet közben a szóban forgó két tömb. Az viszont megvan, hol (egy blade állomány gombjára kattintva hívok meg egy másik kontrollert, amivel az oldalon történt rádiógomb kiválasztást és a sessionben lévő adataimat dolgoznám fel).
- A hozzászóláshoz be kell jelentkezni
Ebben van olyan rész, hogy a teljes adattartalom oda-vissza utazik JavaScript és PHP-között? (A naív kérdésre mentségül felhoznám, hogy nem ismerem az említett technológiákat.)
- A hozzászóláshoz be kell jelentkezni
Az állomány teteére nem tudod kiiratni a session tartalmát?
Így látnád, hogy csak azt nem viszi tovább, vagy már ott elveszlik.
- A hozzászóláshoz be kell jelentkezni