Newsgroup: it.lavoro.informatica
Titolo: I fatturati si costruiscono anche cosi' (altro anedotto che oggi e' venerdi e nun c'ho voja).

(eppoi domani e domenica me tocca pure ajuta' er socero a ripitta'
casa)
Questa vicenda non l'ho seguita direttamente, se ne e' occupato un mio
socio, ve la racconto per come l'ha riportata a me.
Un nostro cliente (di cui seguiamo la parte di contabilita') ci chiede
di interessarci di alcuni problemi che sta avendo con il suo crm. 
Il crm in questione e' una web-app jee, un prodotto os appositamente
personalizzato per il cliente da una softwarehouse locale.
L'application server/servlet container utilizzato e' pure un prodotto
os (abbastanza noto, cmq per puntualizzare non ha nulla a che fare con
gli indiani d'america ;-)). Ora capita di quando in quando che il crm
smetta di funzionare, mi spiego l'app e' apparentemente funzionante
(come anche il pannello di admin dell'as sembra mostrare) ma ogni
richiesta degli utenti o invocazione di qualsiasi tipo produce
inevitabilmente una pagina del tipo "file not found" o risorsa non
disponibile, per superare il problema occorre rebootare la macchina.
La sh che ha fornito il prodotto brancola nel buio, l'unica cosa che
sembrano accertare e' che quando il processo java supera una certa
soglia (non bassa cme si parla di qualche miliardo) di bytes in I/O
l'app o l'as "impazzisce", dopo un po' dichiarano che per loro l'app
funziona perfettamente ed il problema risiede nell'application server
(per il quale, per inciso, non forniscono assistenza) e se la cavano
raccomandando l'adozione di altro as stavolta proprietario il cui
costo di licenza e' cmq pari a € tanti. Il socio, peraltro valente
javista, inizia ad analizzare il problema ed effettivamente sembra
concordare con la sh il problema sembra risiedere nell'as, solo che
tramite  i comuni canali di supporto (forum,  blog, ml) sembra che sia
la prima volta che il problema si presente non ve ne' traccia altrove.
Il socio allora pensa di contattare qualcuno che faccia assistenza a
pagamento su tale prodotto, il cliente acconsente. Il problema a
questo punto non e' tanto (o non solo) di trovare chi conosca il
prodotto in un ambito geografico teoricamente limitato ai confini
nazionali, quanto trovare qualcuno in gamba ed affidabile in grado di
risolvere veramente il problema. Dopo una ricerca di mercato ed aver
chiesto info in giro ci viene indicata una societa' del nord, li
contattiamo, mandano un tizio ad analizzare il problema. Risultato:
per affrontare la cosa vogliono si firmi loro un contratto
d'assistenza per 300 gg uomo (ovviamente pagamento "a consumo" salvo
conguaglio), il cliente giustamente s'incazza, il socio decide di
mandarli a fanculo (contestualmente alla sh) e propone al cliente di
rifargli il crm che  accetta la nostra proposta.

 propone al cliente di rifargli il crm che accetta la nostra proposta.
quando si dice
ne uccide piu' la lingua che la spada :)
felice_pago
il mio commerciale e' indifferente
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 rifargli il crm che  accetta la nostra proposta.
Riflessione: se avessero fatto fare alla swh un applicativo specifico,
senza appiccicare assieme l'a.s. (chissà se lo usano al 100%?), il
software
opensource (chissà se lo usano al 100%?), ecc., allora
avrebbero avuto sicuramente un'assistenza efficace e forse avrebbero
pure speso
meno.

 [...] il problema sembra risiedere nell'as, solo che


 avrebbero pure speso meno.
quegli sono chiari sintomi di un problema applicativo, ovvero la web
application che (evidentemente scritta troppo bene) esaurisce la heap
mandando in palla la jvm. il fornitore da la colpa all'application
server sempicemente perchè non ci leva le gambe. non avessi mai
trovato una situazione del genere...
l'assistenza dell'application server cosa pensi ti avrebbe risolto?

 rifargli il crm che  accetta la nostra proposta.
ok, guardate però di fargli un lavoro migliore di quelli prima :)

Dopo dura riflessione, Suarez (dall'ufficio) ha scritto :
Se parli di Compiere e JBoss il tutto mi sembra molto strano...
Ciao,
Alessio (a.k.a. Kinglion Il Meticcio)
-- 
11:15, restate my assumptions: 1. Mathematics is the language of 
nature. 2. Everything around us can be represented and understood 
through numbers. 3. If you graph these numbers, patterns emerge. 
Therefore: There are patterns everywhere in nature.
(Maximilian Cohen, Pi)

 l'assistenza dell'application server cosa pensi ti avrebbe risolto?
Nel caso di un software tutto "fatto in casa" da lei, la s.h.non
avrebbe
avuto scuse. Invece l'a.s. è "figlio di nessuno"...

 che rimane pendente e quindi non raccattata dal GC).
ma certo che è un bug dell'applicazione :)
oltretutto quando vedo fare queste valutazioni empiriche mi viene da 
sorridere. a parte la bizzarria della diagnosi ma per risolvere questi 
problemi non è che si tira a caso... ci sono ovviamente i log (quando si 
schianta un processo si vede), ci sono gli strumenti di monitoraggio 
(memoria, thread, traffico, etc...) anche free e semplicissimi da 
mettere su necessari se uno vuol capire di che tipo di sovraccarico 
stiamo parlando.
chiaramente una volta scoperto la causa bisogna risalire al rimedio e se 
l'applicazione è scritta con i piedi il rimedio a parte la riscrittura 
totale non esiste. per questo in questi casi la software house riempie 
il cliente di supercazzole.

 avuto scuse. Invece l'a.s. è "figlio di nessuno"...
quindi secondo te un potenziale capro espiatorio per inventare scuse 
fregnacce come quelle descritte? tanto è figlio di nessuno, diamo la 
colpa a lui...
attenzione che questi prodotti hanno milioni di utilizzatori in tutto il 
mondo pronti a sputtanarti. poi solo sperare che quello dopo sia più 
incompetente di te...

 raccomandando l'adozione di altro as stavolta proprietario
Scusa la domanda idiota... ma perche' non testare se si verifica lo
stesso
problema con il servlet container degli indiani d'america? Se avesse
funzionato
sarebbero stati a posto, altrimenti sarebbe stato dimostrato che e' un
problema
dell' applicazione e non dell'application server. E gia' che ne staimo
parlando quale
sarebbe questo Application server OS che usano? Per una semplice
webapp mi riesce difficile
immaginare perche', se si sceglie una soluzione OS, non si scelga
tomcat.

 sarebbe questo Application server OS che usano? 
sarà quello di bernardo provenzano con la j davanti, che fra l'altro 
contiene l'indiano d'america come servlet container.
a proposito, non ho capito perchè ci si debba riguardare a fare nomi... mah.

 avrebbe  avuto scuse. Invece l'a.s. č "figlio di nessuno"...
Beh ma in quel caso ci sarebbe il sempre gettonato "e' un problema
di rete"...(grrrr)

 costo di licenza e' cmq pari a ? tanti. Il socio, peraltro valente


stiamo parlando.
su questi sarei molto interessato ad approfondire (java non e' la mia
cup of team, ma per ragioni contingenti la debbo approfondire sempre
di più) qualche nome/indicazione/url da cui cominciare ?
TIA

 di più) qualche nome/indicazione/url da cui cominciare ?
Io comincerei qui..
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html


http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
Grazie.

 di più) qualche nome/indicazione/url da cui cominciare ?
Questa webapp ad esempio è strettamente legata a tomcat:
http://www.lambdaprobe.org/d/latest.shtml
snmp-based:
http://www.nagios.org/
http://cacti.net/
in generale però l'amministratore di una infrastruttura java deve
prendere confidenza con jmx, jboss ha la sua jmx-console spartana ma
efficace.

 grande dimensione.
si tratta di un crm.
non è di grande dimensione? beh, parliamone.
tu proporresti la scrittura di un crm da zero? e magari sceglieresti 
pure una architettura client-server?


Supponiamo (come mi è parso di capire) che l'applicazione non è di
grande dimensione.
 Ti piace sparare alla zanzara con il cannone trinato da 406 (ovvero:
a.s., grande
sistema crm o.s. con mille funzioni ampiamente personalizzato) ?
Tutti i gusti sono gusti! :-) A me non piace.

 team?
Anche il tuo "not my CUM of tea" non e' proprio il massimo come
inglesismo, anzi, potrebbe essere frainteso :)