| Entrambe le parti precedenti la revisioneRevisione precedenteProssima revisione | Revisione precedente |
| documentazione_3di_riservata:extraway:piattaforma_extraway_kion [2010/06/08 14:36] – rtirabassi | documentazione_3di_riservata:extraway:piattaforma_extraway_kion [Data sconosciuta] (versione attuale) – eliminata - modifica esterna (Data sconosciuta) 127.0.0.1 |
|---|
| ====== Versione "Kion" ==== | |
| |
| * Intervento sulla procedura di consumo dei files xrj così da evitare doppie elaborazioni ed un grave memory leack. | |
| * Corretto ciclo di uscita di un processo slave per evitare condizione di //loop// irreversibile. | |
| |
| ^ Data ^ Mod ^ Ver ^ ^ Sintomo o Segnalazione ^ | |
| ^ 08/06 | xw | 21.1.3.116_p23bk3 | CE |sperimentando un problema che affligge Telespazio ho notato che al crescere del contenuto della directory xreg il server non riesce a consumarla. In pratica, chi la alimenta può essere molto più veloce del //Server Master// nel consumarla..| | |
| ^ |Compiuto intervento rimuovendo le funzioni //evolute// di accesso al contenuto delle directory, che si avvalgon di un BTree in memoria molto "rognoso" da alimentare, a favore delle più semplici find_first/_nest/_close visto che non serve accedere alle subdirectories.\\ Il risultato è un processo molto più snello e svelto ed un'occupazinoe di memoria inferiore anche di un ordine di grandezza.|||| | |
| |
| ^ 05/05 | xw | 21.1.3.116_p23bk3 | CE |In uscita dal server master, se eseguito in modalità //Single//, si produce un loop che ne impedisce l'effettiva uscita.| | |
| ^ |Errore di una certa banalità già riscontrato e risolto nelle versioni successive. Di fatto ci si rende conto di tale difetto solo in sessioni di debug in cui si usa il server in modalità singola, altrimenti il problema non appare mai.\\ Vds. [[https://egroupware.3di.it:6445/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=743|GWT000743]]|||| | |
| ^ 06/04 | xw | 21.1.3.116_p22bk2 | CE |Ci sono condizioni in cui viene violata l'univocità dei documenti.| | |
| ^ |L'errore deriva da un comportamento //tollerante// del server attuato per consentire in archivi nativamente spuri di poter modificare documenti la cui univocità fosse originariamente non garantita.\\ In particolare ci si riferisce ad archivi del progetto //Nuovo Italgiure Find// che venivano realizzati partendo da dati già corrotti o, quanto meno, non garantiti come univoci. In tal caso si ammetteva che un documento potesse violare un univocità a patto che tra i documenti violati ci fosse anche il documento stesso, segno che non si interveniva realmente sull'univocità.\\ Purtroppo quest'assunto era sbagliato all'origine perché nulla vieta, non verificando lo stato dell'univocità del documento prima della modifica, che un documento che __non__ violasse altre univocità le violi dopo la modifica pur confermando anche la propria.\\ La correzione rispetta quella apportata nelle altre versioni e consente di configurare il server per consentire questa violazione anomala.\\ Vds. [[https://egroupware.3di.it:6445/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=700|GWT000700]]|||| | |
| ^ 04/03 | xw | 21.1.3.116_p22bk2 | CE |In fase di spegnimento servizi capita che un server slave rimanga attivo e consumi CPU.| | |
| ^ |L'errore si ha quando un server slave riceve il comando che lo informa che deve chiudersi. Tale comando, asincrono, viene gestito da un apposito //handler// il quale è pensato per essere eseguito in modo recursivo ogni volta che esso rileva che c'è un comando ancora pendente. Il bit del comando di chiusura non viene abbattuto in quanto è utile sapere che la chiusura è stata richiesta. Inibita la reiterazione qualora il solo comando pendente sia quello di chiusura.\\ Vds. [[https://egroupware.3di.it:6445/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=559|GWT000559]]|||| | |
| ^ 01/03 | xw | 21.1.3.116_p21bk1 | CE |Loop processo XReg su //Job Files//.| | |
| ^ |L'identificazione del problema non è affatto intuitiva. Si direbbe che files scritti correttamente e chiusi dallo //Slave// risultino privi di contenuto o con contenuto incompleto da parte del //Master// che inoltre sembra fallire nel tentativo di rimuoverli.\\ Come soluzione si adotta un ulteriore livello di //renaming// atto ad escludere per quanto possibile la proliferazione incontrollata del file di registro. Questo non ci assicura che il server master non cada in una sorta di loop ma per lo meno non vanifica lo scopo del file //xreg...//.\\ Viene inoltre modificata la modalità con la quale si fanno le operazioni di Push & Load di files per non farsi ingannare da eventuali errori in chiusura del file.\\ Rivista la politica di uscita del server master per garantire un sincronismo con il thread che si occupa di consumare i files della directory //xreg// così da non lasciare lavorazioni a mezza via.\\ Vds [[https://egroupware.3di.it:6445/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=536|GWT000536]].|||| | |
| |
