Questa è una vecchia versione del documento!

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
26/10	xw	21.1.3.116_p29k9	CE	Errore nell'assegnazione dei valori seriali.
	Se si assegna un valore seriale dopo aver provocato un errore di univocità si corre il rischio di avere un'erronea assegnazione con un salto di numerazione. L'errore è molto grave e serio. Vds eGW#716.
28/09	xw	21.1.3.116_p28bk8	CE	Impossibile reperire un allegato.
	il problema era già stato affrontato nel settembre 2009 con scheda eGW#38 ma la soluzione, non verificata in modo completo, manteneva alcune condizioni d'errore. Apportata ulteriore correzione. Vds eGW#863.
28/09	xw	21.1.3.116_p28bk8	NC	Applicazione UAC¹⁾.
10/09	xw	21.1.3.116_p27bk7	CE	Crash in ricerca.
	In questo caso l'errore è dovuto all'erroneo utilizzo della variabile nota col nome 'lavoro' in scenari in cui essa appare evidentemente sottodimenzionata. Grazie alla presenza del file .PDB siamo riusciti ad identificare il punto incriminato. Nell'accesso a vocabolari e thesaurus, specialmente per questi ultimi, la chiave che può essere letta dal BTree o della quale si richiede una lettura esatta o una greater, può risultare di dimensioni molto superiori a quelle della variabile utilizzata. Modificato sia questo punto del codice sia l'estensione per genere e numero che nascondeva lo stesso difetto, se pure è ragionevole ritenere che non si sia mai evidenziato in quel punto. Vds eGW#855.
29/07	xw	21.1.3.116_p26bk6	CE	Crash in ricerca.
	L'errore si direbbe essere legato al comportamento della funzione memcmp() [ed analogamente della memicmp()] che con il Visual C9 evidenziano un comportamento che il VC6 manteneva più tollerante. La memcmp() infatti, nasconde un potenziale errore/rischio se non si indica correttamente la dimensione da testare confidando nel fatto che la differenza si presenti prima della fine del termine più breve. Effettuata una capillare sostituzione delle chiamate a tale funzione con le corrispondenti strncmp e strnicmp, che per la versione linux è stata appositamente creata²⁾. Vds eGW#847.
27/07	xw	21.1.3.116_p25bk5	CE	Crash in indicizzazione nuovi documenti.
	Errore più volte verificato e mai riprodotto, legato ad una corruzione dello stack. Con l'adozione del Visual C 9 il problema viene meno ed il server recupera la solidità. Corretto anche errore di overflow di un buffer utilizato in estensione delle chiavi in fase di ricerca. L'errore aveva impatti anche sull'ordinamento dei documenti. Vds eGW#837.
21/07	xw	21.1.3.116_p25bk5	CE	Il controllo vocabolario da molto spesso errore anche se non c'è ragione di ritenere che gli indici siano danneggiati.
	L'errore dipende dal fatto che in sede di controllo del vocabolario si faceva uso di un buffer ancora sottodimensionato rispetto all'effettiva dimensione delle chiavi. Corretto quel difetto il controllo del vocabolario torna ad essere efficacie. Vds eGw#838.
21/07	xw	21.1.3.116_p25bk5	CE	La presenza di parentesi quadre nella frase di ricerca che non intendano racchiudere un campo conduce a comportamenti inesatti/inattesi. La forma [campo1]=[campo2] non da errore ma non da esito.
	La richiesta (Vds. eGW#000770) non può essere accolta in quanto un tentativo di abbattere l'ambiguità data dall'uso improprio di parentesi quadre al fine di considerarle alla stregua di una strina qualsiasi impatta con la ricerca con Anyalias e la ricerca multi archivio, oltre a confliggere con alcuni casi di univocità. La correzione si limita ad inibire e considerare sintatticamente errata la forma [campo1]=[campo2].
19/07	xw	21.1.3.116_p24bk4	CE	Si verificano condizioni d'errore sugli indici che sono bloccanti e gravi.
	Compiuto l'intervento di cui alla scheda RightWay RW0056652 già presente nel server 22. Non riuscendo ad identificare in modo certo la causa, ci limitiamo, per lo meno, ad arginare tutti i problemi che sorgono dal sintomo. Il server compie una una verifica, se pur relativamente empirica, che garantisce che la catena dei blocchi liberati venga spezzata qualora si rilevi che il prossimo blocco liberato è, di fatto, un blocco effettivo.
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. 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. 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. 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 GWT000536.

¹⁾

Windows Only

²⁾

Recuperata dalle versioni più recenti del server che già la prevedono.