Questa è una vecchia versione del documento!
Indice
Dettagli sui rilasci effettuati per Kion del server 21.1.3.116_patch_20 e successive
Di seguito gli interventi ordinati per data.
In essi si identifica il modulo e la versione dello stesso dalla quale la funzionalità o la correzione è disponibile e tutte le informazioni inerenti la segnalazione, la correzione e la verifica della validità della stessa.
I valori ammessi per il tipo di intervento sono:
- CE: Correzione Errore
- NC: Nuovo Comportamento
- NF: Nuova Funzionalità
- AL: Intervento di nuova funzionalità o correzione che richiede allineamento tra moduli della piattaforma.
- IN: Intervento di nuova funzionalità o correzione che causa incompatibilità col passato
- CA: Registrazione dell'emissione di una candidate, versione non ufficiale ma distribuita ugualmente per compiere verifiche e valutare la validità degli interventi compiuti
Si richiama l'attenzione sul fatto che la prima versione compilata con Visual C9 è la 21.1.3.116_p25k5. Da quella versione il suffisso perde il carattere 'b'1).
Si assume che le versioni in uso dal cliente siano >= a quella in esame.
Si riportano comunque tutte le correzioni di cui alle precedenti versioni per consentire di verificare le funzionalità su cui si è intervenuto.
21.1.3.116_p33k13
In lavorazione
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
28/06 2011 | xw | 21.1.3.116_p33k13 | CE | Corruzione indici che impedisce l'inserimento di nuovi allegati. |
L'errore si deve ad un indice che in modifica viene aggiornato male e da errore alzando il bit di corruzione degli indici. Ampliato il log perché ci dica se e dove si trova il problema. | ||||
Rif. | eGrouWare Ticket #1081. | |||
09/06 2011 | xw | 21.1.3.116_p33k13 | CE | Operzioni di selezione con ordinamento vanno in time expiry ma non lo notificano a dovere. |
Modificato il server perché torni il codice d'errore corretto. | ||||
Rif. | eGrouWare Ticket #????. |
21.1.3.116_p32k12
Emissione 14/06/2011
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
08/06 2011 | xw | 21.1.3.116_p32k12 | CE | La versione p32k12 ha perso retro compatibilità degli indici nei confronti della versione p29k9. |
Si tratta di alcuni interventi occorsi portando la p32k12 ad uno stato al quanto prossimo a quello del server di classe 22/23. Quest'intervento produce indici più precisi ma causa la perdita di retro-compatibilità. Compiuto Roll Back di parte della correzione, mantenendo solo quella di cui al punto precedente che garantisce la salvaguardia dal crash/loop. |
||||
Rif. | eGrouWare Ticket 1049. | |||
25/05 2011 | xw | 21.1.3.116_p32k12 | CE | L'indicizzazione di un archivio va in loop con la versione p30k10 ma non con la p29k9. |
In considerazione degli interventi compiuti si valuta che il problema sia nell'introduzione della nuova procedura di normalizzazione dei caratteri al set latin-1 che è stata modificata successivamente sui server 22 e 23. Applicata la modalità presente sul server 22. |
||||
Rif. | eGrouWare Ticket 1049. | |||
17/05 2011 | xw | 21.1.3.116_p32k12 | CE | Applicazione xDocWayDoc. In presenza di un oggetto di ampie dimensioni l'ordinamento per numero di protocollo non viene compiuto correttamente ed il documento risulta il primo della selezione. |
Superato limite nativo della dimensione del titolo che ha impatto diretto sulle funzionalità che fanno uso delle sue componenti, come l'ordinamento nel caso indicato. Compiuto intervento atto a sanare la problematica agendo non sui singoli titoli ma solo in sede di ordinamento. Non richidere ReTitle. |
||||
Rif. | eGrouWare Ticket 1035. | |||
04/05 2011 | xw | 21.1.3.116_p32k12 | CE | Documenti contenenti dei commenti XML producono indici errati. |
L'errore si ha in quanto il parser riconosce analogamente le Processing Instruction ed i commenti ai quali riserva lo stesso trattamento. Per le Processing Instruction si deve compiere un riconoscimento mirato dei contenuti, per i commenti no. La correzione era già stata applicata nell'ottobre 2008 su versione successiva del server (Vds. RW0054403). Test effettuati sull'archivio campione fornito da Kion non evidenziano le chiavi errate dopo la ricostruzione dell'indice. |
||||
Rif. | eGroupWare Ticket 1031. | |||
02/05 2011 | xw | 21.1.3.116_p32k12 | CE | Errore durante il compattamento del vocabolario al termine di una ricostruzione complessiva dell'archivio. |
L'errore non si manifesta se la ricostruzione dell'archivio non prevede la rigenerazione dei titoli. Analizzando il materiale a nostra disposizione è risultata evidente una corruzione della RAM dovuta ad un trabordamento della zona allocata per la generazione dei titoli. Apportando correzione a tale procedimento il problema in costituzione globale archivio (catalogo/titoli/indici) si comporta correttamente. E' attualmente pendente una segnalazione di incongruenza sulla numerazione degli indici. |
||||
Rif. | eGroupWare Ticket 1023. | |||
21/04 2011 | xw | 21.1.3.116_p32k12 | CE | Errori di locking. |
L'errore si manifesta in quanto al verificarsi di un particolare caso, un server provvede a bloccare un archivio e non lo sblocca in modo doveroso. L'unlock avviene alla prima operazione successiva sullo stesso server ma poi comporta che il conteggio dei lock/unlock non risulti corretto, cosa che conduce ad una maldestra segnalazione nel log. | ||||
Rif. | eGroupWare Ticket 1014/1021. | |||
13/04 2011 | xw | 21.1.3.116_p32k12 | CE | Catene dei liberati corrotte. |
Compiuto ulteriore intervento correttivo inerente la gestione delle aree liberate. Le correzioni precedenti tenevano conto solo della “prossima” catena usata e non di quella che si procede ad utilizzare in un momento dato. Nell'ambito di questa correzione sanato il rischio di gestire catene di dimensione superiore a 64MB, precedentemente ignorato. |
||||
Rif. | eGroupWare Ticket 913. | |||
13/04 2011 | xw | 21.1.3.116_p32k12 | CE | Crash server in uscita. |
Dall'analisi del materiale fornito si evince che il server va in crash in quanto, durante l'esecuzione della procedura che esso attua quanto interceta in SIGTERM riceve un nuovo SIGTERM che stimola quella procedura una seconda volta. Parte delle risorse sono già state liberate ed il secondo processo trova una situazione inconsistente e causa l'errore. Inibito il signal-handler una volta che esso si avvia per impedire il caso in cui si percepisca un nuovo SIGTERM. |
||||
Rif. | eGroupWare Ticket 917. |
21.1.3.116_p31k11
Emissione: 24/01/2011
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
18/01 2011 | xw | 21.1.3.116_p31k11 | CE | Un server master va continuamente in crash. |
Si nota chiaramente che la cosa ha luogo quando il server provvede alla cancellazione dei temporanei. La directory che li ospita è stracarica ma soprattutto ha un file molto strano che presenta una serie di “blanks” in coda. La dimensione del nome di tale file, più quella del percorso della directory che lo ospita, superano la dimensione di un buffer erroneamente sottodimensionato. | ||||
Rif. | eGroupWare Ticket 930. |
21.1.3.116_p30k10
Emissione: 14/01/2011
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
08/11 2010 | xw | 21.1.3.116_p30k10 | CE | L'indicizzazione degli ID degli allegati alle volte fallisce. |
L'errore va ricercato in un difetto di normalizzazione dei percorsi XML particolarmente nidificati quali sono, ad esempio, quelli degli allegati di cui si è fatta ampia nidificazione. In tal caso, nel determinare il tipo di indice da compiere sul campo, si può avere un troncamento erroneo del percorso cui fare riferimento. Questo conduce all'errore in esame che inficia tutti gli indici del documento corrente. Va inoltre rilevato che, nonostante l'errore di indicizzazione, la condizione d'errore viene “appiattita” ed il comando torna in modo positivo nonostante tutto. Ciò è piuttosto grave. |
||||
Rif. | eGroupWare Ticket 893. |
21.1.3.116_p29k9
Emissione: 29/10/2010
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
26/10 2010 | 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. |
||||
Rif. | eGroupWare Ticket 716. |
21.1.3.116_p28k8
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
28/09 2010 | 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. |
||||
Rif. | eGroupWare Ticket 863. | |||
28/09 2010 | xw | 21.1.3.116_p28bk8 | NC | Applicazione UAC2). |
Come da segnalazione. | ||||
28/09 2010 | xw | 21.1.3.116_p28bk8 | CA | Unificazione versioni Linux(Unix Only). |
Su richiesta del cliente è stato riorganizzato il sistema di produzione delle versioni Unix creando ordine ed uniformità Attualmente vengono generate versioni per: |
||||
Linux gcc 4.1.2/glibc 2.7 | ||||
Linux gcc 4.1.2/glibc 2.5 | ||||
Linux gcc3.3.2/glibc2.1 |
21.1.3.116_p27k7
Emissione: 14/09/2010
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
10/09 2010 | 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. |
||||
Rif. | eGroupWare Ticket 855. |
21.1.3.116_p26k6
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
29/07 2010 | 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 creata3). |
||||
Rif. | eGroupWare Ticket 847. |
21.1.3.116_p25k5
Emissione: 26/07/2010
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
26/07 2010 | 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. | ||||
Rif. | eGroupWare Ticket 837. | |||
21/07 2010 | 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. | ||||
Rif. | eGroupWare Ticket 838. | |||
21/07 2010 | 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]. |
21.1.3.116_p23bk3 e 21.1.3.116_p24bk4
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
19/07 2010 | 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 2010 | 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'occupazione di memoria inferiore anche di un ordine di grandezza. |
||||
05/05 2010 | 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. | ||||
Rif. | eGroupWare Ticket 743. |
21.1.3.116_p22bk1 e 21.1.3.116_p22bk2
Data | Mod | Ver | Sintomo o Segnalazione | |
---|---|---|---|---|
06/04 2010 | 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. |
||||
Rif. | eGroupWare Ticket (da recuperare). | |||
04/03 2010 | 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. | ||||
Rif. | eGroupWare Ticket 559. | |||
01/03 2010 | 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. Corretto in questo modo anche Memory Leak inerente il trattamento di files che rimanevano erroneamente aperti. 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. |
||||
Rif. | eGroupWare Ticket 536. |