Andrea, non abbiamo ancora esaminato insieme i risultato dell'approfondimento. Visto che l'ho commissionato io devo precisare:
- il comportamento multithread è parte dell'incarico non per le implicazioni geoserver ma perchè volendo usare l'accoppiata geotools-spatialite in ambito web servlet siamo a tutti gli effetti in una casistica multithread a prescindere da geoserver - se da questo lavoro potesse venire un buon supporto di spatialite per geoserver è un valore aggiunto per la comunità, quindi questo aspetto era sicuramente da indagare e quindi parte dello studio. Poi si sarebbe in seguito deciso in funzione delle complicazioni/costi se perseguirlo o meno - ho ricevuto da qualche mese il risultato dello studio, che evidenzia problemi e possibili soluzioni. Non immediate ma nemmeno impossibili. Devo ancora approfondirlo per poi parlarne con gli altri soggetti interessati, tra cui Andrea, per decidere se e come muovermi. Quindi non siamo andati avanti dipende dalle priorità (non si fa a tempo a seguire tutto..) nostre ma anche tue Andrea... Il 23/03/2014 20:39, aperi2007 ha scritto: > Ciao Simone. > > Interessante questo tuo dettaglio per cui te lasci l'italia per questo > mio intervento. > Ove, oltre tutto un aspetto non secondario era l'apprezzamento per il > tuo prodotto. > > Per il resto mi pare che il tuo intervento sia esso stesso la migliore > risposta che io potrei darti. > Visto l'attegiamento che hai anche nei confronti dei tuoi collaboratori. > > Ionon ci vedo niente di male nel recriminare visto che veod un > prodotto valido fare uso di spatialite su una piattaforma di per se' > abbastanza ostica (dalvik) e non avere niente di analogo su una > piattaforma che non è piu' complessa (java) > > >Andando sul lato tecnico, innanzitutto, il supporto a spatialite di > >cui si parla si limita alla versione Android che non ha > >niente a che >fare con il java standard come sicuramente saprai in > quanto il codice >non è (quasi) mai portabile tra una > >JVM standard e Dalvik. > > Quindi se capisco la tua spiega, secondo te è stato piu' facile > portare spatialite su dalvik piuttosto che su una piattaforma > Java Standard. > > il porting di spatialite su Dalvik lo avete finanziato voi di > Geosolutions di vostra iniziativa ? > >> Visto che ci hai citato spiego l'antefatto. Spatialite si puo' usare >> abb tranquillamente in applicativi desktop basati su Java, ma su >> applicativi lato server come GeoServer, perlomeno al momento in cui >> abbiamo fatto il famoso studio di ben 9 ore (o giu' di li non ricordo >> nel dubbio posso anche condividerei timesheet giornalieri e le >> relative fatture) aveva grossi (enormi?) problemi di gestione di >> thread multipli e di scalabilità (questo a livello dei driver JDBC). > > > Non ho dubbi che su geoserver non sia facile da usare, ma strnaamente > a me non risulta che mai ci si sia sognati di commissionare ad alcuna > persona di supportare spatialite su geoserver. > > Se proprio devo dirla tutta, a me risulta che ci fossimo interessati > per la realizzazione di un driver spatialite per Geotools. > > Evidentemente certe persone immaginano geotools e geoserver come due > faccie della stessa medaglia e non si puo' agire sull'uno senza agire > contestualmente anche sull'altro. > Questo pero' aumenta i costi a carico di chi finanzierebbe non credi ? > > Comunque non sapevo di questo dualismo obbligato geotools-geoserver, > lo scopro ora. > > >> Senza voler criticare Furieri, mi ricordo una sua email girata anche >> in questa lista dove evidenziava (su suggerimento di Even Roualt btw) >> che spatialite inizializzava male GEOS (in modo non thread-safe) e >> questo poteva portare a dei crash, cosa non accettabile in una >> applicazione Java e che sicuramente era una delle sorgenti dei crash >> che vedevamo. > > > A suo tempo , quando mi giunse questa tua notizia, mi informai e > emerse che la geos non è thread-safe > (lo sapevi ?) > Alcune parti in realta' lo sono , ma solo la parte dei messaggi, il > resto non lo è. > Per cui la parte rilevante, quella della elaborazione non lo è. > Io non sono un programmatore di geos, ma se chi lo è mi dice che non è > thread-safe io gli credo. > Queste notizie a te erano state fatte pervenire. > > Con la ovvia conclusione che se la geos non e' thread-safe non ha > senso parlare di inizializzarla in modalit'a thread-safe. > e comunque spatialite per questo ha implementato dei meccanismi di > lock che se non sono thread-safe almeno impediscono le collisioni. > > Credevo che queste cose le avessi contemplate. > Invece capisco da questo tuo intervento che ti eri fermato ben prima. > > Termino qui perche' vedo che fai un gran mescolone di tante cose. > > In ogni caso io facevo un apprezzamento del tuo prodotto recriminando > sulla mancata occasione su spatialite con le geotools. E non potendo > non notare che pero' nel tuo prodotto alla fine spatialite ci è entrato. > bello o brutto che fosse. > Non credo che ci fosse niente di cosi' male in tale intervento. > > Forse cercavi solo la scusa buona e io non sapendolo te la ho fornita ? > > almeno dimmi grazie. > :) > > A. > > On 23/03/2014 18:27, Simone Giannecchini wrote: >> Salve Andrea, >> trovi le mie risposte inline sotto. >> >>> Interessante questo mapstore 1.5.1 >>> >>> Veod che gestisce pure un db spatialite. >>> >>> Come RT abbiamo finanziato anche uno studio per vedere se si >>> riusciva a far >>> funzionare spatialite con l'ambiente java. >>> Ma la ditta a cui per vie traverse era stato dato l'incarico, una ditta >>> esperta su geotools, non ci risulta che alla fine avesse concluso >>> alcunche' >>> di significativo. >>> >> Onestamente, essendo GeoSolutions un' azienda con sede legale e >> operativa in Toscana che da lavoro a 15 persone di cui almeno 10 >> residenti in Toscana facendo il 70% del fatturato all'estero e pagando >> circa 14k di IRAP l'anno, ci dispiace (a me e al management di >> GeoSolutions) dover constatare questo ormai ovvio risentimento nei >> confronti di GeoSolutions da parte della nostra regione con cui >> peraltro non abbiamo MAI lavorato direttamente. >> >> In qualità di rappresentante di GeoSolutions mi sento in dovere di >> rispondere ancora una volta puntualizzando alcuni aspetti non solo dal >> punto di vista tecnico e se questo comporterà di non lavorare piu' con >> enti vicini o legati a RT lo prenderò come uno stimolo in piu' per >> decidermi finalmente a spostare l'azienda all'estero. Fatto questo, >> GeoSolutions e tutti i suoi collaboratori dovranno necessariamente >> smettere di intervenire su questa lista per evitare che l'immagine >> aziendale venga deliberatamente danneggiata senza apparenti motivi e, >> a mio parere, spesso con critiche fuori luogo e scarsamente >> documentate tecnicamente. >> >> Aggiungo anche che vedendo come altre regioni e province italiane ma >> anche altri paesi (tutti) proteggano le loro aziende (spesso dobbiamo >> fare forzatamente da subcontractor per lavorare all'estero pagando >> pesante dazio) questa situazione è quantomeno assurda. >> >> >> Andando sul lato tecnico, innanzitutto, il supporto a spatialite di >> cui si parla si limita alla versione Android che non ha niente a che >> fare con il java standard come sicuramente saprai in quanto il codice >> non è (quasi) mai portabile tra una JVM standard e Dalvik. >> >> Oltretutto si basa su una versione non aggiornata di spatialite e NON >> usa driver JDBC ma istanzia la libreria e parla con essa direttamente >> via JNI, ergo mi sfugge il parallelo e sarei portato a pensare che sia >> solo un modo, come spesso è accaduto anche in passato, per criticare >> trasversalmente visto che la azienda che citi siamo noi. >> >> Visto che ci hai citato spiego l'antefatto. Spatialite si puo' usare >> abb tranquillamente in applicativi desktop basati su Java, ma su >> applicativi lato server come GeoServer, perlomeno al momento in cui >> abbiamo fatto il famoso studio di ben 9 ore (o giu' di li non ricordo >> nel dubbio posso anche condividerei timesheet giornalieri e le >> relative fatture) aveva grossi (enormi?) problemi di gestione di >> thread multipli e di scalabilità (questo a livello dei driver JDBC). >> >> Noi, nella persona di Andrea Aime non l'ultimo arrivato, abbiamo >> evidenziato con test di scalabilità (che possiamo fornire a tutti) che >> questi problemi esistevano ed abbiamo testato tutti i diver JDBC >> esistenti. Abbiamo quindi chiesto di coinvolgere Furieri per validare >> i nostri risultati visto che chi meglio di lui poteva commentare e non >> mi risulta che qualcuno abbia detto che ci siamo sbagliati. >> >> Senza voler criticare Furieri, mi ricordo una sua email girata anche >> in questa lista dove evidenziava (su suggerimento di Even Roualt btw) >> che spatialite inizializzava male GEOS (in modo non thread-safe) e >> questo poteva portare a dei crash, cosa non accettabile in una >> applicazione Java e che sicuramente era una delle sorgenti dei crash >> che vedevamo. >> >> In 9 ore di studio spero che sia ovvio per tutti che non si sarebbero >> potuti risolvere tutti i problemi del supporto java verso spatialite e >> noi abbiamo correttamente suggerito i tempi ed i modi per intervenire >> nel caso ci fosse stato richiesto (dopo allego scambio email). >> >> >> >>> Tante' che l'unico reale aiuto viene fornito dall'intervento dalle >>> istruzioni di Furieri. >>> Alla fien dei slmi, esperti, ingegneri, informatici, tante chiacchere, >> >> Si in effetti siamo d'accordo, non è che gli ingegneri informatici >> servano a molto per la programmazione informatica. Credo che saranno >> d'accordo su questa osservazione anche tutti gli altri ingegneri >> informatici che leggono la lista. Però in qualità di ingegneri >> informatici laureati in meno di 6 anni con lode almeno la >> documentazione la archiviamo bene, per cui per chi fosse interessato >> alcuni degli scambi, perlomeno la nostra parte è reperibile qui: >> >> https://docs.google.com/document/d/1YzTeCyo6q1Lj5Kj3C3dsSOzBXs_2hne-f1wyBcqgWrQ/edit?usp=sharing >> >> >> >> Diro' di piu', se qualcuno vuole posso anche passare le classi di test >> che abbiamo scritto. >> >> >> Dall'interazione con Furieri abbiamo poi appreso che in effetti l'uso >> di Spatialite da Java in applicazione thread safe non è cosa >> immediata, soprattutto con i binari già disponibili nei pacchetti >> binari a disposizione nelle distribuzioni (la ricompilazione dai >> sorgenti è spesso un tabù, una libreria che la imponga diventa in >> questi casi inutilizzabile), cito un pezzo di mail dello stesso ( di >> nuovo non me ne verrà, visto che sa che lo stimo): >> >> "se mi passate la facile battuta, non parrebbe che quella di fare >> sviluppo thread safe sia stata una priorita' elevata per tutti quanti >> i principali team che curano le librerie di base C/C++ perlomeno non >> prima degli ultimi due anni o giu' di li quando poi ci e' premuniti di >> inserire qualche patch appiccicata un po' in qualche modo e spesso >> tenendole ben nascoste dentro a documentazioni un po' criptiche e con >> pochissima visibilita'. >> >> ... >> >> riassuntino ultra-short: >> >> - tutte le versioni di spatialite rilasciate fino ad oggi (Aprile >> 2013, ndr) sono sicuramente thread unsafe >> " >> >> Ora, lo studio lo si è fatto in autunno 2013, quindi i problemi di >> thread safety erano risolti nelle versioni sorgente, ma non nelle >> versioni binarie disponibili nelle varie distribuzioni. >> >> Come problema ulteriore, spatialite stesso al momento dei test andava >> in crash a causa di problemi nel caricamento dinamico della libreria, >> cosa risolta dopo la fine del nostro studio e non so se già rilasciata >> in forma stabile e ufficiale (mi pare di no, l'ultima versione è di >> Giugno 2013, noi abbiamo fatto i test durante l'autunno). >> >> In buona sostanza, il nostro breve lavoro ha messo in luce una serie >> di criticità che richiedono lavoro per essere risolte. La cosa non è >> oltrettuto banale perchè non si lavora su campo libero, GeoTools ha >> già un modulo Spatialite vecchio di qualche anno che punta alla >> semplicità facendo embedding delle librerie native necessarie, >> staticamente compilate dentro alcune lib java (pagando però il prezzo >> di scalabilità pressochè nulla), proporre una versione che funzioni >> solo se sono installate librerie native di recente aggiornamento >> (anche visto il problema che spesso aggiornare le librerie sui server >> non è permesso) non è immediato, una nuova soluzione deve tener conto >> delle problematiche di semplicità d'uso, e evitare di cozzare contro >> il lavoro di supporto a GeoPackage, che per quanto non usi Spatialite, >> usa lo stesso driver JDBC Xerial usato dal modulo Spatialite: il >> driver JDBC in uso deve rimanere allineato, visto che non si possono >> agganciare due volte le librerie native di sqlite con versioni diverse >> dallo stesso processo, ne conseguen che qualunque passo venga fatto >> non si può limitare alla sola revisione del modulo Spatialite, ma >> necessariamente coinvolge anche un aggiornamento dei moduli >> GeoPackage. >> >> Vista l'ampiezza dello sforzo necessario e le inevitabili discussioni >> in comunità una operazione come quella sopra descritta richiede un >> significativo sforzo in termini di tempo, cosa che noi abbiamo >> sottolineato nelle nostre comunicazioni scritte con il committente. > > _______________________________________________ > Gfoss@lists.gfoss.it > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le > posizioni dell'Associazione GFOSS.it. > 666 iscritti al 22.7.2013 _______________________________________________ Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013