| |
| documentazione_3di_riservata:extraway:piattaforma_extraway_hot [2010/09/16 17:53] – rtirabassi | documentazione_3di_riservata:extraway:piattaforma_extraway_hot [Data sconosciuta] (versione attuale) – eliminata - modifica esterna (Data sconosciuta) 127.0.0.1 |
|---|
| ====== Versione "Hot Work In Progress" ==== | |
| |
| * Introduzione del concetto di profilo. Abolizione del file xusers.xml a favore di un diverso sistema di autenticazione ed adozione di profilo di sistema e d'archivio. | |
| * Modalità Blind, con .conf.xml minimale. | |
| * Impostazioni di indicizzazione direttamente nel campo che viene sottoposto al server. | |
| * Revisione generale delle politiche di //locking/flushing// ed uso della cache del BTree in molteplici casi. | |
| * Adozione del B+Tree in tutti i punti possibili, sia nelle attività che riguardano il //file system// sia per le operazioni di indicizzazione in memoria. | |
| |
| ^ Data ^ Mod ^ Ver ^ ^ Sintomo o Segnalazione ^ | |
| ^ 16/09 | xw | <color red>23.0.0.1_hot_wip "EVO"</color>\\ 22.1.3.10 | NC |Search & Replace incapace di compiere un'attività precisa.| | |
| ^ |Le procedure di //Search & Replace// risultano incapaci di compiere un'attività più precisa e capillare.\\ Nella fattispecie è incapace di saltare i documenti in cui la modifica richiesta non abbia senso e non venga applicata ne di indicare, nei casi di errore, quali documenti siano interessati dagli errori ed in che modo\\ \\ Implementato con l'aiuto di Gregorio un nuovo procedimento in grado di identificare le attività positive da quelle non effettuate e regolarsi di conseguenza.\\ Dettagli nella [[./comandi_extraway#comando_0x00000017_search_replace|documentazione del comando]].|||| | |
| ^ 10/09 | xw | <color red>23.0.0.1_hot_wip "EVO"</color>\\ 22.1.3.9 | CE |Crash del server in accesso al vocabolario.| | |
| ^ |A quanto è possibile vedere, il buffer globale destinato al trattamento delle chiavi era sottodimensionato rispetto alla massima dimensione lecita per una chiave.\\ Se pure è raro che essa si presenti negli indici dei documenti, è invece facile che si manifesti nel thesaurus che prevede chiavi molto lunghe e composte da due parti entrambe ampie.\\ Vds. GWT000855.|||| | |
| ^ 03/09 | xw | <color red>23.0.0.1_hot_wip "EVO"</color>\\ 22.1.3.9 | CE |L'esecuzione di un //Search & Replace// da esiti errati.| | |
| ^ |Pur eseguendo correttamente il proprio compito, l'attività di //Search & Replace// indicava erroneamente quante e quali fossero i salvataggi effettuati e con quale esito..|||| | |
| ^ 09/08 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | <color blue>CA</color> |<color blue>Emissione Candidate da testare internamente</color> ^ | |
| ^ 02/08 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.7 | CE |L'import da //WatchDoc// di documenti con encoding non corrispondente a quello dichiarato nel file presenta una condizione d'apparente correttezza ma lascia il file ''.fail'' sul proprio percorso.| | |
| ^ |L'intervento effettuato nella precedente 22.1.3.6 non azzerava il codice d'errore vanificando quindi l'operazione di salvataggio.|||| | |
| ^ 30/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.7 | CE |La costituzione del catalogo che preveda l'applicazione di un foglio di stile XSLT alle volte, pur non dando errore, non produce alcun risultato.| | |
| ^ |Il difetto va ricercato nel fatto che la funzione riceve puntatore e dimensione del buffer da elaborare ma se vi deve applicare anche il //namespace// ''xw:'' per poter interpretare correttamente gli allegati, compone mane il buffer da elaborare perché ignora la size notificata. In inserimento e modifica la cosa non si avverte ma nel fare catalogo da file (quindi anche da WatchDoc) l'errore può presentarsi.\\ Rettificato l'uso della dimensione anche in quel punto e corretto l'errore.|||| | |
| ^ 27/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.7 | CE |La combinazione di //ranges// in forma di "Or List" ed altre estensioni (genere e numero, thesaurus, somiglianza, fonetica, etc.) non da l'esito atteso. Le estensioni non risultano applicate.| | |
| ^ |L'errore è dovuto al fatto che il //range// in forma di "Or List" veniva trattato come tutti i ranges, ovvero estraendo esattamente quei termini dal vocabolario, senza tenere in considerazione la possibilità che da essi si derivassero altri termini. Tutte le altre forme di //range// si avvalgono __espressamente ed intenzionalmente__ dei termini presenti nel vocabolario, e solo di essi, ma questo //range// fa naturalmente razza a se.\\ Vds. eGW#000840.|||| | |
| ^ 21/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.7 | CE |La presenza di parentesi quadre nella frase di ricerca che non intendano racchiudere un campo conduce a comportamenti inesatti/inattesi.\\ La forma <color red>[campo1]=[campo2]</color> 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 <color red>[campo1]=[campo2]</color>.|||| | |
| ^ 19/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.7 | CE |Le ricerche per numero documento confliggono con le estensioni, ad esempio, per genere e numero.| | |
| ^ |Difetto riscontrato e corretto.\\ Vds eGW#000836.|||| | |
| ^ 19/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.7 | CE |Gli indici corrotti dilagano a macchia d'olio e bloccano il funzionamento dell'archivio.| | |
| ^ |La problematica era già stata trattata in precedenza, per interrompere l'uso della catena dei liberati di un //Buddy File// quando essa risultasse corrotta.\\ La correzione era però insufficiente in quanto utilizzava comunque una prima area già riutilizzata con riflessi molto pericolosi sulla consistenza di quell'indice.\\ L'attuale correzione (Vds. eGW#827) è pensata per evitare anche questo problema.|||| | |
| ^ 14/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | **NC** |Nel visualizzatore eventi appaiono una serie di segnali che risultano errori pur non essendo nulla di serio e creano un ingiustificato allarme.| | |
| ^ |Compiute due verifiche.\\ In primo luogo non vengono più registrate come errori i mancati logs che si cerca di inviare a xwls prima ancora che l'interfaccia per fare logging sia stata del tutto avviata.\\ In secondo luogo, tutte le informazioni inviate al //Log Giornale// vengono riversate anche sul log di sistema ((Grazie ad una configurazione del file xwls.conf.xml)) quindi si evita di indicare come //Warning// segnalazioni fisiologiche o innocenti.\\ (Vds. segnalazione eGW000744).|||| | |
| ^ 13/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.7 | **NC** |Evitare gli indici degli allegati quando essi si presentino di identico contenuto.| | |
| ^ |La funzionalità è stata concepita e sviluppata per avvantaggiarsi in scenari in cui ci siano allegati identici (Vds. segnalazione eGW000735) cosa che avviene non di rado ad esempio quando si allegano più versioni di un determinato documento in cui il testo non risulti di fatto cambiato.\\ Malauguratamente, per la suddetta segnalazione, questo intervento risulta inutile.|||| | |
| ^ 12/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.7 | CE |Le attività massive che interessano conversioni XSLT sono estremamente lente.| | |
| ^ |Tentata un'ottimizzazione mantenendo caricato ed utilizzabile l'ultimo foglio di stile XSLT utilizzato al fine di evitare un inutile overhead nel ricaricare continuamente un oggetto sempre identico.\\ Purtroppo il guadagno in termini prestazionali non è ancora sensibile come speravamo, perché limitato all'XSLT e non ha effetti sul tempo necessario al caricamento DOM del XML da elaborare.|||| | |
| ^ 01/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.6 | CE |Gli errori di encoding rendono inusabili le vecchie applicazioni.| | |
| ^ |Il server non deve accettare che documenti dichiarati in encoding ''iso8859-1'' contengano, in realtà, caratteri appartenenti all'enciding ''windows-1252''.\\ La modifica di recente introduzione che inibisce il salvataggio di simili documenti, pur essendo corretta, causa diversi problemi alle applicazioni esistenti.\\ Per ovviare a questo si può introdurre, nei vecchi archivi, una voce di profilo che rende più lasco il controllo. Il server si limiterà ad indicare che c'è un errore di encoding senza provocare un errore bloccante.<code><profile type="arc.test_encoding" value="false"/></code>|||| | |
| ^ 01/07 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.6 | CE |Esprimendo un range di valori sotto forma di //or list//, il programma ha un comportamento strano se uno di tali valori è il valor vuoto.| | |
| ^ |Ci sono due ordini di problemi.\\ Se il valor vuoto viene espresso con la sequenza <code>&null;</code> la presenza del punto e virgola confonde l'interprete dei ranges in quanto anch'esso è uno dei separatori di range.\\ Se il valor vuoto viene spresso con <code>"&null;"</code> il comportamento è corretto mentre se si indica semplicemente <code>""</code> l'esito non comprende il valor vuoto.\\ Sul primo problema c'è poco da fare, la sintassi rischia la confusione quindi si deve fare attenzione nell'utilizzo, il caso della sequenza "" è stata equiparata a quella del termine "&null;".\\ Ammessa come valida anche la forma <code>[campo]={valore}</code> ovvero <code>[campo]={"valore"}</code> che viene trattata come //or list// anche se l'elenco è composto da un solo valore.\\ Vds eGroupWare #820.|||| | |
| ^ 29/06 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.5 | CE |La ricostruzione integrale di un archivio, in presenza di difetti che ne comportino la rimozione del file .stat.xml, causa la perdita dei seriali.| | |
| ^ |Il server assume che se un archivio esiste i suoi seriali si conservano, se non esiste si butta ogni cosa si trovi lungo la strada, assumendo che siano dati errati. Per sapere se l'archivio esiste ci si basa sul file //nomearchivio//.stat.xml in assenza del quale si assume che ci sia di buono solo il .conf.xml.\\ In questo caso si perde il .ser.xml in quelle occasioni in cui sia stato necessario cancellare alcuni file dell'archivio perché danneggiati o incompatibili con la versione di server che si va ad usare.\\ Visto che il flag di salvaguardia dei seriali esiste dalla notte dei tempi ma mai nessun client ne ha fatto uso, il server ora agisce d'ufficio salvaguardando sempre i seriali ed i thesaurus ed ignorando l'eventuale flag ricevuto.\\ IL server 23 mantiene però la possibilità di gestire la rimozione dei seriali in caso di comando di "drop" d'archivio per gli archivi Lucene, ovvero gli archivi "blind".\\ Vds eGroupWare #788.|||| | |
| ^ 29/06 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.5 | CE |Titoly //lazy// di più archivi si rubano continuamente la scena, rendendo molto più lento del necessario il compito di ricostruzione lazy dei titoli.| | |
| ^ |Il problema dipende dal fatto che mente si sta facendo un'operazione di lungo corso, come ad esempio il rifacimento dei titoli, il server tenta di fare anche altre attività eventualmente prioritarie. Per tale ragione da un po' di tempo a ciascuno dei compiti collocati nella directory ''lazy'' contando che, chi più chi meno, arriveranno tutti a termine senza particolare ritardo.\\ Dalla versione corrente del server i compiti //lazy// sono stati razionalizzati e quindi è stata data priorità <color red>**'A'**</color> alle indicizzazioni //off-line//, priorità <color orange>**'B'**</color> alle indicizzazioni delle modifiche dei documenti e priorità <color green>**'Z'**</color> ai titoli. In questo modo, mente si stanno facendo i titoli di un archivio, altri titoli non distoglieranno il primo dal suo compito mente attività a priorità superiore verranno svolte comunque prima interrompendo il flusso di attività in corso.\\ __Inoltre da adesso i titoli off-line vengono sempre fatti //lazy//, salvo divesa disposizione del chiamante__.\\ Vds eGroupWare #796.|||| | |
| ^ 09/06 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.4 | CE |L'idicizzazione dell'archivio docway di Asolo da crash del server.| | |
| ^ |Il problema è dovuto al fatto che si indicizza in un certo "lotto" una chiave che appare due volte. Ciò significa che è stata inserita due volte nel BTree in memoria considerandole distinte ma che risulta la stessa chiave nel BTree su disco. Questo comporta che la chiave venga scaricata due volte producendo un file .LOT inconsistente (non può essere scandito in modo corretto) che provoca un crash in fase di scarico finale.\\ Corretto l'errore intervenendo sulla funzione di normalizzazione delle chiavi.|||| | |
| ^ 28/05 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.4 | <color green>**NF**</color> |Semplificare la procedura per la realizzazione di archivi per CD.| | |
| ^ |Realizzato un singolo comando in grado di compiere tutti i passi necessari alla realizzazione di un archivio che sia il clone integrale o semplicemente di una parte di un altro archivio. L'archivio così ottenuto può essere già pronto per l'uso su un supporto ottico e con una distribuzione di server in grado agire su archivi così protetti.|||| | |
| ^ 26/05 | xw | <color red>23.0.0.0_hot_wip "EVO"</color>\\ 22.1.3.4 | CE |Non si riesce a compiere un'importazione via //WatchDoc// su alcuni archivi.| | |
| ^ |Se un archivio privo di //file_location rule// la modalità usata dal server per identificare in quale file XML scrivere il documento è quella detta //single//((Che corrisponde ad un singolo file, numerato progressivamente, per ciascun documento)). La procedura che determina il nome di tale file è la stessa usata per gli allegati. In tale frangente, essendo fondamentale l'univocità, un archivio non completamente indicizzato causa errore. Questo è lo scenario che si presenta dopo l'importazione del primo documento via //WatchDoc//.\\ Allentata la stretta del controllo sull'univocità quando la procedura viene utilizzata per scopi legati ai files XML anziché agli allegati.|||| | |
| ^ 10/03 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | CE |L'indicizzazione di alcuni allegati manda in //crash// il server.| | |
| ^ |Il problema va ricercato nel fatto che l'adozione dell'OCR //Tesseract// produce alle volte documenti contenenti una grande quantità di dati errati il cui formato, di fatto, è UTF-8 anche se il file è del tutto testuale. Dal server di classe 22 si introduce un test che fa sì che si proceda alla conversione del contenuto secondo il detto encoding così da compiere un'indicizzazione dei contenuti il più corretto possibile.\\ Malauguratamente quest'attività può condurre ad una crescita anche sensibile della stringa che rappresenta il contenuto dell'allegato in quanto da UTF-8 a WinLatin1((L'encoding usato per //default// nel fare gli indici)) molti caratteri possono risultare non traducibili e vengono quindi traslati in //entity// numeriche. La funzione a ciò preposta allocava //un po' di spazio in più// senza valutare correttamente il dafarsi.\\ Nel server 22 si è provveduto a compiere un'allocazione di memoria più vasta, nel 23 si passa all'uso di ''std::string'' così da aggirare completamente l'ostacolo.\\ Vds eGroupWare #750.|||| | |
| ^ 04/03 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | CE |A seguito di un'azzeramento d'archivio il risultato dello stesso è inutilizzabile.| | |
| ^ |Mancando una reale condizione di test sulla concorrenza tra l'azzeramento di un archivio, considerato abbastanza __definitivo__ per non dover prendere particolari precauzioni, ed eventuali operazioni di inserimento e modifica, è possibile, in linea teorica (ed anche in linea pratica a giudicare dalla segnalazione eGW #747) che un server sovrascriva il file //nomearchivio//.stat.xml e le header degli altri files dopo che un altro server ha provveduto all'azzeramento.\\ L'archivio risultante se tutto va bene, non può più essere aperto((La header del file .idx manda ad una root che non esiste assolutamente)) ne quindi si riesce a ricostruirlo da capo se non rimuovendo a mano i files.\\ Si da il caso, però, che il server che l'ha azzerato, convinto della sua validità sulla base di quello che ha in //cache//, consente operazioni come la costituzione della mappa e dei titoli con risultati drammatici((Lo .stat.xml cita documenti che non ci sono, appare un catalogo che conta il doppio dei documenti e la prima metà non esiste)).\\ Compiuto un intervento che si assicura di bloccare l'archivio esistente prima di rimuoverlo così da assicurarsi che l'archivio risultante sia corretto.|||| | |
| ^ 04/03 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | CE |L'accesso al vocabolario con pattern causa condizioni di //loop//.| | |
| ^ |La verifica della presenza di un pattern comune in caso di ricerca delal chiave greater non teneva conto correttamente, nelle successive letture 'next', che la radice fosse per lo meno comune.\\ Vds. [[https://egroupware.3di.it:6445/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=639|GWT000639]]|||| | |
| ^ 04/03 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | 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]]|||| | |
| ^ 04/03 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | CE |L'esecuzione massiva della ricostruzione titoli produce un file di titoli inutilizzabile e quindi causa sensibili rallentamenti a tutto il sistema.| | |
| ^ |Il problema s'è manifestato da quando, nella costituzione dei titoli, si è deciso di procedere dall'ultimo al primo((In questo modo si privilegiano i titoli dei documenti più recenti che sono maggiormente candidati ad essere consultati)) anziché in ordine numerico naturale. La procedura che provvedeva a sbiancare la parte di file //.tip// non ancora valorizzata compiva un errore banale sovrascrivendo anche la header con risultati disastrosi.\\ Vds. [[https://egroupware.3di.it:6445/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=636|GWT000636]]|||| | |
| ^ 03/03 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | CE |L'applicazione di un filtro nell'accesso al vocabolario che presenti un asterisco come primo carattere produce una stringa vuota.| | |
| ^ |Il confronto sul pattern era corretto ma, malauguratamente, tale confronto non doveva limitarsi ad affermare se la stinga fosse corrispondente o meno, ma anche se si fosse ancora in un //range// utile per evitare che il controllo sul pattern scandisca inutilmente tutto il vocabolario.\\ Per verificare se si rientra nel //range// si controlla la corrispondenza della parte //radice// della chiave che in presenza di //Wild Card// come primo carattere non dava un risultato significativo. In questo caso, ora, si asserisce di essere sempre nel //range//.|||| | |
| ^ 19/02 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | CE |Indici corrotti.| | |
| ^ |Problema dipendente dalla presenza di un carattere 'þ' che veniva maldestramente interpretato dalla funzione di normalizzazione. Il problema è stato arginato mettendo una vera e propria pezza nelle funzioni che inseriscono le chiavi nel BTree/CBtree/BTreeMem ed imponendo un ulteriore filtro nella funzione di indicizzazione incrementale o differenziale che inserisce le chiavi visto che in alcuni casi, meno rari del previsto, si inseriva una chiave vuota.\\ Vds GWT000596.|||| | |
| ^ 28/01 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | CE |Le attività di log impattano sulle performance più di quanto si attenda.| | |
| ^ |Cambiata la politica di logging usando un thread parallelo //lockless// che compie il logging mentre il thread principale procede nelle sue attività.\\ Se lo sviluppo si dimostrerà efficace a simili threads verrà dato il compito di fare altre operazioni, come la registrazione delle attività //lazy// o del //registro//..|||| | |
| ^ 27/01 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | CE |Caccia alle performance.| | |
| ^ |Cambiata la politica di apertura degli archivi per riconoscere i comandi //Archiveless// senza dispendio di tempo.\\ Abolite inutili memset di aree di memoria quando non necessario.\\ Ridotta l'allocazione di memoria che viene fatta per fare //cache// della selezione in corso di esecuzione che era eccessiva e spostata sullo stack.|||| | |
| ^ 22/01 | xw | <color red>23.0.0.0_hot_wip "EVO"</color> | CE |In assenza del file //context.stat.xml// esso viene creato alla prima registrazione ma viene realizzato errato.| | |
| ^ |Corretta la stesura del file nel quale, se assente, un attributo //id// veniva realizzato erroneamente come elemento.|||| | |
| ^ 30/12 | xw | <color red>23.0.0.0_hot_wip</color> | CE |Compiere //BenchMark// non fornisce facilmente indicazioni statistiche utili.| | |
| ^ |Introdotta una modalità di stesura di un log di //BenchMark// che semplifica la vita al tester.\\ Vds GWA001344.|||| | |
| ^ 29/12 | xw | <color red>23.0.0.0_hot_wip</color> | CE |Nel compiere dei //BenchMark// con altre versioni del server verificata una lentezza in modifica documenti.| | |
| ^ |Il problema è stato arginato adottando l'uso della //cache// del BTree anche in modifica, cosa che non era mai stata fatta.\\ Vds GWA001344.|||| | |
| ^ 24/12 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |Nel compiere dei //BenchMark// con altre versioni del server nota che viene compiuto un numero irragionevole di letture, seek, scritture e flush dei files dell'archivio.| | |
| ^ |La gestione delle letture delle header, delle loro scritture e dei flush degli archivi era //sparsa// un po' ovunque e costringeva a rileggere continuamente per esser certi di avere a disposizione una versione affidabile.\\ L'intera gestione degli accessi alle headere è stata riveduta e migrata, per competenza, al più basso livello disponibile, ovvero al livello del singolo file. Ora, quando si blocca un archivio e si provvede al caricamento delle header dei files, gli stessi vengono etichettati in modo da evitare ogni ulteriore reload delle header non necessario.\\ In questo modo viene riveduto anche tutto il comportamento delle librerie dinamiche tornando ad avere un comportamento finalmente coerente.\\ La verifica sul campo dimostra che il numero di letture e scritture è sensibilmente diminuito con evidenti benefici.|||| | |
| ^ 17/12 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |Nello sviluppo della sintassi per Lucene ci sono alcune forme di range non previste.| | |
| ^ |I range mancanti sono quelli che potremmo definire misti. ExtraWay server prevede sia i ranges inclusivi che esclusivi, ovvero i ranges nei quali gli estremi indicati debbano appartenere o meno all'esito finale della selezione.\\ Lucene prevede, oltre ad essi, i ragnes che risultano inclusivi solo per uno dei due estremi.\\ Per integrare questo comportamento sono stati aggiunti i modificatori dei ranges '>' e '<' che si aggiungono a quelli già indicati\\ L'espressione:\\ <code>[campo]={minval>maxval}</code>\\ Indica che il range richiesto dovrà __comprendere__ l'estremo espresso con //minval// ed __escludere__ l'estremo espresso con //maxval//\\ Analogamente l'espressione:\\ <code>[campo]={minval<maxval}</code>\\ Indica che il range richiesto dovrà __escludere__ l'estremo espresso con //minval// ed __includere__ l'estremo espresso con //maxval//.|||| | |
| ^ 03/12 | xw | <color red>23.0.0.0_hot_wip</color>\\ 21.2.1.20 | CE |I timestamp interni, senza il carattere 'T' del formato ISO, non vengono trattati adeguatamente.| | |
| ^ |Esteso il trattamento delle chiavi che rappresentano un timestamp((Vale a dire una stringa che indica anno, mese, giorno, ore, minuti e secondi)) anche in assenza del separatore 'T' che ne qualifica la forma riconosciuta ISO.|||| | |
| ^ 30/11 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |Le selezioni in modalità ''Lucene'' richiedono che il grado di somiglianza sia configurabile per singola ricerca.| | |
| ^ |eXtraWay Server prevedeva esclusivamente l'indicazione della ricerca per somiglianza dei termini applicata all'intera selezione. Dalla versione in esame è stata introdotta la possibilità di indicare invece una somiglianza per singolo termine o, più precisamente, per il singolo campo sul quale si sta compiendo la selezione stessa.\\ Vedasi la [[documentazione_3di:extraway:fuzzy|documentazione relativa]].|||| | |
| ^ 26/11 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |Per compiere diverse tipologie di selezione, tra le quali quelle in stile //Lucene//, sono state implementate le operazioni di ricerca in cascata.| | |
| ^ |Vedasi la [[documentazione_3di:extraway:then|documentazione relativa]].|||| | |
| ^ 25/11 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |Per realizzare archivi da utilizzarsi nello scenario //Lucene// si devono costituire archivio con caratteristiche particolari.| | |
| ^ |Introdotto il concetto di Archivio "Blind" che ciecamente accetta documenti ed alias di ricerca anche in assenza di una specifica configurazione.\\ Vedasi la [[documentazione_3di:extraway:db_create|documentazione relativa]].|||| | |
| ^ 12/11 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |Il compattamento archivio viene fatto anche se inutile.| | |
| ^ |Con l'adozione del B+Tree cambia completamente la filosofia del compattamento. Il compattamento del file ''.idx.bpt'' può risultare molto utile (la procedura che lo genera lo riempie lasciando molto sfrido) e viene eseguita a parte rispetto al resto. Il compattamento di VCB e REF viene ora effettuato solo se nel Ref c'è uno spazio libero superiore ai 256Mb o in generale se lo spazio libero supera il 10% dello spazio totale del file REF. Questo in particolar modo perché a seguito di indicizzazione //Off-Line// il ref è praticamente già compattato. L'unica caratteristica che manca ai 3 files è quella di essere in ordine (l'ordine dei record del VCB corrispondente all'ordine delle chiavi nel B+Tree e conseguentemente corrispondente all'ordine dei blocchi del REF) cosa che aiuterebbe in accesso sequenziale (ricerche per range, accesso ai vocabolari e simili) ed eventualmente per le applicazioni distribuite su supporto ottico.|||| | |
| ^ 11/11 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |Dover affrontare archivi di dimensioni sempre maggiori impone prestazioni più imponenti.| | |
| ^ |Compiuti considerevoli interventi nell'indicizzazione //Off-Line// che portano archivi di dimensioni considerevoli ad essere indicizzati in tempi molto più rapidi.\\ <sub>Per portare un esempio, l'indicizzazione dell'archivio Agi che richiede, per una versione 22.1.2.0 un tempo di <color black/yellow>8h07'</color> viene compiuta dalla versione attuale in <color black/yellow>4h59'</color>. Un archivio campione di Regione Veneto è passato da <color black/yellow>13h05'</color> a <color black/yellow>9h22'</color>((In questo caso, però, si paragona un server compilato //debug// ed uno compilato //release//))</sub>.\\ Il programma fa attualmente un uso maggiore della Ram, utilizzando quindi una cache più //spinta//. A tale scopo è stato modificato il file di configurazione((xw.ini)) nella sezione ''[hs]'' aggiungendo una nuova voce ''CacheSize'' il cui valore identificato come segue:|||| | |
| ^ ^''CacheSize'' presente e diverso da '0'||Rappresenta il numero di **Mb** da usare per la Cache. Ora si utilizzano due distinte forme di Cache quindi metà dello spazio indicato verrà usata per la Cache del B+Tree e l'altra metà per la lavorazione delle catene dei riferimenti.\\ I valori di ''NodiCacheMax'' e ''KRAM'' vengono ignorati.|| | |
| ^ ^''CacheSize'' assente o uguale a '0'||Il valore della Cache viene ottenuto prendendo in considerazione il valore di ''NodiCacheMax''((che rappresenta il numero di nodi di 512 bytes)) e ''KRAM''((che rappresenta un valore espresso in **Kb**)). Entrambe i valori vengono tradotti in **Mb** e ''CacheSize'' assume il doppio((per le ragioni indicate nel punto precedente)) del massimo dei due valori.|| | |
| ^ |Vengono inoltre aboliti i seguenti valori di configurazione((Che quindi vengono ignorati qualora presenti)): ''AreaDiLavoro'', ''AreaDiLavoroMax'', ''FiltroInizio'' e ''FiltroFine'' mentre, come già detto, i valori di ''NodiCacheMax'' e ''KRAM'' vengono presi in esame solo in assenza di ''CacheSize''.\\ Il valore di ''NodiCache'' cambia il proprio valore di default da ''510'' a ''1020''.\\ \\ <sub>**Nota:** Si consideri che con server sino alla classe '22' una configurazione tipo poteva prevedere un valore di ''NodiCacheMax'' pari a 192000 e di ''KRAM'' pari ad 80000. In questo scenario si finiscono con l'utilizzare 96Mb di Ram per la Cache del BTree e poco meno di 80Mb per il trattamento dei lotti. Questi due ammontare di memoria venivano allocati e liberati in momenti diversi quindi l'occupazione effettiva massima corrispondeva a 96Mb.\\ Dal server 23 si sfrutta, in ognuna delle due fasi dell'indicizzazione //Off-Line// il doppo della Ram il che comporta un utilizzo medio di 192Mb di Ram.\\ Le impostazioni suddette equivalgono quindi ad indicare esclusivamente ''CacheSize=192''.</sub>|||| | |
| ^ 30/10 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |La gestione di un archivio richiede, anzi impone in alcuni casi, che per ottenere i risultati voluti in termini di indicizzazione sia necessario modificare il file di configurazione d'archivio per introdurre nuovi tipi di canali.| | |
| ^ |Introdotto il concetto di canali autodefiniti. Rimane sempre vero quanto detto per attributi ed elementi che vengono indicizzati reciprocamente come monovalore e multivalore, alfanumerici e con l'applicazione della StopList((ovviamente in sola ricerca)) solo per gli elementi.\\ Se un elemento((questa soluzione non si applica agli attributi)) è corredato da alcuni attributi appartenenti al //namespace// ''xw:'', essi vengono interpretati come modificatori dell'espressione della chiave e producono una chiave che ha particolari caratteristiche, eventualmente distinte dalle condizioni di default.\\ Sono ammessi alcuni valori noti che derivano diretattamente da quelli già esistenti nel file di configurazione d'archivio ed altri di <color red>**nuova concezione**</color>.|||| | |
| ^ ^Attributo^^Valori Ammessi (in <color green>Verde</color> i valori di default, in <color grey>Grigio</color> i valori supportati ma di più raro utilizzo) || | |
| ^ ^xw:key_style||single, one, <color green>multi</color>, double, skip, <color grey>one-md5, one-md5cs, double-md5, double-md5cs, spatial</color>.|| | |
| ^ ^xw:value_type||date, num, <color green>alfa</color>, <color grey>file</color>, <color grey>alnum</color>.|| | |
| ^ ^xw:instance||Qualsiasi valore positivo o <color green>negativo</color> (es.: true, yes, on, 1 ovvero false, no, off, 0)|| | |
| ^ ^<color red>xw:store</color>||Qualsiasi valore <color green>positivo</color> o negativo (es.: true, yes, on, 1 ovvero false, no, off, 0).\\ Indica se si richiede o meno la conservazione del dato dopo aver provveduto a farne gli indici.\\ <color blue>All'atto della stesura della presente documentazione, quest'opzione viene prevista ma non implementata: il server farà comunque storage del dato.</color>|| | |
| ^ ^<color red>xw:analyzer</color>||Identificatore univoco dell'analizzatore del testo da applicare sul contenuto del canale.\\ <color blue>All'atto della stesura della presente documentazione, quest'opzione viene prevista ma non implementata: il server applicherà comunque l'analizzatore/tokenizzatore di default.</color>|| | |
| ^ 21/10 | xw | <color red>23.0.0.0_hot_wip</color> | CE |Il test di //Wellformedness// dei documenti può essere inibito con conseguenze anche gravi sui contenuti degli archivi.| | |
| ^ |Ignorata l'inibizione introdotta in versioni molto vecchie. Ora il test avviene sempre e comunque nelle fasi di salvataggio di singoli documenti come di serie di documenti((ad esempio via WatchDoc)).\\ Rimane la possibilità di inibire il test in fase di catalogo, assumendo che tutti gli XML dell'archivio, inseriti compiendo il test, siano intrinsecamente validi.|||| | |
| ^ 03/08 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |Le modifiche registrate ne file di registro mostrano il documento com'era e non com'è. Dei documenti meramente inseriti, in sostanza, non v'è traccia alcuna.| | |
| ^ |Si deve compiere un'attività più precisa, registrando i documenti inseriti e, dove presenti, sia l'originale che la modifica se pure con una crescita del registro potenzialmente sensibile.|||| | |
| ^ ??/08 | xw | <color red>23.0.0.0_hot_wip</color> | <color green>NF</color> |Rifacendo il catalogo di un archivio, le date di inserimento e modifica degli stessi evidenziate nella risposta al caricamento ovvero disponibili sotto forma di vocabolari subiscono una trasformazione ed appiattimento.| | |
| ^ |Il vocabolario delle date di inserimento e modifica dei documenti viene ora prodotto sulla base delle //processing instruction// presenti nei documenti stessi divenendo indipendente dalla ricostruzione del catalogo.|||| | |
| |
