Puncte:1

S-a pierdut conexiunea la baza de date inactivă

drapel in

Pot să mă conectez la serverul bazei de date (Firebird), să rulez interogări, toate acele lucruri distractive, dar după o perioadă nedeterminată de inactivitate, următoarea încercare de interogare generează următoarea eroare

Nu se poate finaliza solicitarea de rețea pentru a găzdui „XX.XX.XX.XX”.
Eroare la scrierea datelor în conexiune.
O conexiune existentă a fost închisă forțat de gazda la distanță. .

Eroare SQL (cod = -902):
Execuție nereușită cauzată de o eroare de sistem care exclude
executarea cu succes a declarațiilor ulterioare.

Când operează interactiv folosind Firebird Maestro (relevanță necunoscută), după ce primesc această eroare îi spun Maestro să se deconecteze. Apoi pot rula o interogare.

Nu știu dacă timeout-ul vine de la Firebird sau de la serverul Linux sau din altă parte din rețeaua noastră și nu știu suficient despre Linux sau AWS sau rețeaua noastră pentru a știu unde să caut posibilități. (bucuriile de a fi programator la o companie foarte mică)

drapel sk
Nu sunt foarte familiarizat cu Firebird și nu menționați din ce program/limbă vine eroarea, dar probabil că trebuie doar să activați KeepAlives în setarea/configurarea conexiunii (adică, când software-ul dvs. client face conexiunea, specificați keepalives).
WeststarEric avatar
drapel in
@ChrisS Așadar, sugerați că ar trebui să ignor partea despre „închiderea forțată de către gazda la distanță” și să încerc să anulez comportamentul la nivelul clientului? Din păcate, asta se referă la modul în care funcționează Maestro sau instrumentul meu de programare și cred că este în afara subiectului acestui forum.
Puncte:0
drapel ae

Indiferent de unde vine timeout-ul, ar trebui să fii pregătit pentru asta. Este posibil să existe chiar mai multe timeout-uri și conexiunea dvs. să fie aruncată oricum după o perioadă de inactivitate.

Cel mai bine este să utilizați o bibliotecă de grupare a conexiunilor și să specificați un timeout mai scurt decât ceea ce observați acum (cu excepția cazului în care este inacceptabil de scăzut).

Ar putea ajuta dacă ați descrie implementarea în detalii, dar cred că, în cele din urmă, trebuie să remediați partea client.

WeststarEric avatar
drapel in
Pot vedea cum un pool de conexiuni ar face mai puțin probabil ca o conexiune să devină inactivă dacă există mulți utilizatori simultani. În cazul probabil că există un singur utilizator, aș dori să știu ce cauzează deconectarea, astfel încât să pot prelua controlul asupra perioadei de expirare.
drapel ae
Nu ne-ați spus prea multe despre implementarea dvs., așa că nu este ușor să vă dau sfaturi în acest sens. Gruparea conexiunilor are sens chiar dacă aveți un singur utilizator. Recomand HikariCP: https://github.com/brettwooldridge/HikariCP#microscope-analyses - configurația de timeout ar putea fi și ea interesantă: https://github.com/brettwooldridge/HikariCP#microscope-analyses
WeststarEric avatar
drapel in
Din păcate, ți-am spus tot ce știu despre implementarea „mea”. Companie mică, multă cifră de afaceri, nu prea multă expertiză. Speram să aflu câteva indicii despre unde să caut.
drapel ae
Cu siguranță știi mai mult decât atât. Nu ați menționat detalii despre aplicație sau mașinile care găzduiesc aplicația și baza de date. Oricum, le-ai verificat documentele? https://firebirdsql.org/file/documentation/chunk/en/refdocs/fblangref40/fblangref40-management-timeouts.html

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.