Greške #29698
Zatvoren
F18, 1.3.80, rj sync beskonačna petlja
100%
Opis
prvo pokretanje na empty bazu RJ sync uđe u petlju
Povezani tiketi 1 (0 otvoreno — 1 zatvoren)
Izmjenjeno od Jasmin Beganović prije više od 13 godina
F18.log
29.11.12, 10:22:16: END full_synchro tabela: rj cnt: 0 29.11.12, 10:22:16: START full_synchro table: rj/ sql count: 0 29.11.12, 10:22:16: reopen sa indexom, START reindex rj 29.11.12, 10:22:16: END full_synchro tabela: rj cnt: 0 29.11.12, 10:22:16: START full_synchro table: rj/ sql count: 0 29.11.12, 10:22:16: reopen sa indexom, START reindex rj 29.11.12, 10:22:16: END full_synchro tabela: rj cnt: 0 29.11.12, 10:22:16: START full_synchro table: rj/ sql count: 0 29.11.12, 10:22:16: reopen sa indexom, START reindex rj 29.11.12, 10:22:17: END full_synchro tabela: rj cnt: 0 29.11.12, 10:22:17: START full_synchro table: rj/ sql count: 0 29.11.12, 10:22:17: reopen sa indexom, START reindex rj 29.11.12, 10:22:17: END full_synchro tabela: rj cnt: 0 29.11.12, 10:22:17: START full_synchro table: rj/ sql count: 0 29.11.12, 10:22:17: reopen sa indexom, START reindex rj
Izmjenjeno od Ernad Husremović prije više od 13 godina
- Vrsta promijenjeno iz Podrška u Greške
Izmjenjeno od Ernad Husremović prije više od 13 godina
posljednje promjene su značajan upgrade
kod narednog verzioniranja postaviti verziju na 1.4.0
Izmjenjeno od Ernad Husremović prije više od 13 godina
- Prioritet promijenjeno iz Urgentno u Odmah riješiti
Izmjenjeno od Ernad Husremović prije više od 13 godina
pretpostavljam da se i travis sinoć "bunio" radi ovog bug-a
Izmjenjeno od Ernad Husremović prije više od 13 godina
treba u travis u slučaju errora dodati cat F18.log-a
Izmjenjeno od Ernad Husremović prije više od 13 godina
Izmjenjeno od Saša Vranić prije više od 13 godina
dobro, greška je ovdje, upravo onaj dio o kojem smo diskutovali...
nuliraj_ids....
funkcija full_synchro poziva funkciju nuliraj...
a nuliraj radi sljedeće
znači setuje: version = last_trans_version
međutim, ako nije bilo zapisa nikakvih, prvi put se pokreće sinhronizacija podataka, last_trans_version = NULL što ne odgovara.
Tu sam ja onda stavljao onaj CASE, pa ako je NULL filovao sa -1 ili 0 itd...
Izmjenjeno od Ernad Husremović prije više od 13 godina
ne razumijem ja sam ovo ispravljao, možda si ti kasnije pobrisao ono što sam radio ?
međutim, ako nije bilo zapisa nikakvih, prvi put se pokreće sinhronizacija podataka, last_trans_version = NULL što ne odgovara.
ja sam dobro se sjećam setovao da last_trans_version bude -1
a kasnije sam koristio greatest funkciju da se uvijerim da bude version na kraju bude 0
Izmjenjeno od Ernad Husremović prije više od 13 godina
možda ja to nisam comitovao ?!
Izmjenjeno od Ernad Husremović prije više od 13 godina
hm ali nije moguće, travis testovi ne bi prošli da to nisam uradio
Izmjenjeno od Ernad Husremović prije više od 13 godina
Ernad Husremović je napisao/la:
ne razumijem ja sam ovo ispravljao, možda si ti kasnije pobrisao ono što sam radio ?
međutim, ako nije bilo zapisa nikakvih, prvi put se pokreće sinhronizacija podataka, last_trans_version = NULL što ne odgovara.
last_trans_version je stavljeno da bude 0 prvi put a ne NULL
Izmjenjeno od Saša Vranić prije više od 13 godina
stavio si ti to ali u drugoj funkciji reset_semaphore_version
ali se ona kod full_syncho opcije ne koristi, nego ova nuliraj
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
stavio si ti to ali u drugoj funkciji reset_semaphore_version
ali se ona kod full_syncho opcije ne koristi, nego ova nuliraj
ako je od ranijih verzija las_trans_version setovano na NULL (iako mi nije jasno da to ikada može biti, s obzirom da odmah iza toga slijedi prva full sync ?!)
u reset_semaphores postoji provjera last_trans_version NULL situacije ... ali mislim da ni ovo nije potrebno
svejedno juče sam pravio video vezan za testove i krenuo sam od prazne baze
Izmjenjeno od Ernad Husremović prije više od 13 godina
ti case-ovi svakako ne smiju biti potrebni to znam
Izmjenjeno od Ernad Husremović prije više od 13 godina
ja sam test radio na db ver 4.5.2
Izmjenjeno od Ernad Husremović prije više od 13 godina
a kasnije sam koristio greatest funkciju da se uvijerim da bude version na kraju bude 0
kasnije sam izbacio ovo greatest jer mi jednostavno ne treba. početna situacija je version=-1, last_trans_version=0. ovo napravi prvi insert
Izmjenjeno od Ernad Husremović prije više od 13 godina
koju bazu je bjasko koristio ? demo sa google code ? pokušaj sa njom.
nikakvo krpljenje sa case-ovima ne dolazi u obzir
Izmjenjeno od Saša Vranić prije više od 13 godina
da, evo ovdje se to desi....
pošto nema verzije, ta funkcija vrati NULL pretpostavljam
Izmjenjeno od Saša Vranić prije više od 13 godina
ne, ta funkcija u toj tački vrati 0, a ne -1
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
ne, ta funkcija u toj tački vrati 0, a ne -1
kada nema zapisa get_semaphore_version vrati -1
Izmjenjeno od Saša Vranić prije više od 13 godina
i nakon ove optimizacije #29703
opet imamo beskonačnu petlju na rj tabeli
gledam u semaforu, u semaphores_rj tabeli nema ništa, prazna je.
Izmjenjeno od Saša Vranić prije više od 13 godina
sada je ova funkcija vratila -1 kao rezultat i to je ok, međutim sporna je funkcija
nuliraj_ids...
a ona se poziva iz funkcije full_synchro
fazon je što je semaphores_rj prazna a ova funkcija setuje version = last_trans_version što je NULL i onda se non stop vrti u krug...
Izmjenjeno od Saša Vranić prije više od 13 godina
postoji ova funkcija reset_semaphore.... https://github.com/knowhow/F18_knowhow/blob/bb40dec430e3505c4cc0637408f072d92e62ee92/common/semaphores.prg#L298
ona praktično radi taj insert u praznu tabelu, možda nju treba koristiti umjesto nuliraj_ids...
Izmjenjeno od Saša Vranić prije više od 13 godina
napravio sam ovo:
i sada je full sinhro ok
znači, prije full_synchro pozovem reset_semaphore... funkciju koja će napuniti semafor tabelu ako je prazna, a sama funkcija full_synchro će okinuti nuliraj_ids... funkciju koja će setovati version = last_trans_version
Izmjenjeno od Saša Vranić prije više od 13 godina
- % završeno promijenjeno iz 0 u 70
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
postoji ova funkcija reset_semaphore.... https://github.com/knowhow/F18_knowhow/blob/bb40dec430e3505c4cc0637408f072d92e62ee92/common/semaphores.prg#L298
ona praktično radi taj insert u praznu tabelu, možda nju treba koristiti umjesto nuliraj_ids...
u opcijama kreiranja tabela se uvijek treba pozivai reset_semaphore. možda je kod rj-a to izostavljeno i pravi probleme.
nuliraj_ids ... pretpostavlja da je kod incijalizacije baza ova funkcija ranije pozvana.
Znači ne raditi zamjenu u full sync nego pogedati create_rj proceduru. u njoj vjerovatno nedostaje reset_semaphore
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
napravio sam ovo:
i sada je full sinhro ok
ali nisi provjerio koja je razlika u logici funkcija reset_semaphore() i nuliraj_ids ...
Možda nuliraj_ids uopšte ne treba ?
Možda je moguće spojiti reset_semaphore i nuliraj_ids u jednu funkciju ?
Svakako, ako jedna tabela pravi beskonačnu petlju, a druge ne prave, nešto je vezano za instalacijsku proceduru kod te tabele
Izmjenjeno od Saša Vranić prije više od 13 godina
da, to je tačno, u međuvremenu sam pronašao i ovaj bug:
kod samog kreiranja tabela se dešava ovaj reset_semaphore_version koji to odradi, a kod kreiranja rj se to nije desilo
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
da, to je tačno, u međuvremenu sam pronašao i ovaj bug:
kod samog kreiranja tabela se dešava ovaj reset_semaphore_version koji to odradi, a kod kreiranja rj se to nije desilo
onda, kako sam u predhodnim komentarima rekao, trebaš poništiti efekte prednonog commit-a (vrati full_sync prvobitno stanje) i sve ponovo testiraj.
Izmjenjeno od Saša Vranić prije više od 13 godina
da, nakon ovoga, pobrisao lokalne podatke uzeo ponovo praznu bazu i pokrenuo aplikaciju, sada je sve uredno kreirano
Izmjenjeno od Saša Vranić prije više od 13 godina
Vraćeno na prvobitno stanje...
Izmjenjeno od Ernad Husremović prije više od 13 godina
Ne znamo šta će se desiti u situaciji kada se full sync okone nakon prekoračenja limita (broj ids > 1000)
možda bi reset_commit u full_sync izazvao neku najnoviju beskonačnu petlju.
Izmjenjeno od Ernad Husremović prije više od 13 godina
sjećam se zašto su testovi čitavo vrijeme prolazili uspješno - ja sam u test proceduru stavi reset_semaphore("rj") kada sam prilikom testiranja na to naletio.
Ali se greškom nisam vraćao na samu instalacijsku proceduru, da provjerim da li u njoj ima greška.
Izmjenjeno od Ernad Husremović prije više od 13 godina
svakako upradi i upgrade naše baze na 1.4.x
Izmjenjeno od Ernad Husremović prije više od 13 godina
i naravno vzeljka verzije
Izmjenjeno od Saša Vranić prije više od 13 godina
- Status promijenjeno iz Dodijeljeno u Zatvoreno
- % završeno promijenjeno iz 70 u 100