Newsgroup: it.comp.java
Titolo: Servlet & Http persistente

Ciao a tutti,
avrei necessita di avere una servlet che tiene la connessione sempre
aperta verso un client.
I miei tenantativi sono infruttosi. Ho cercato di utilizzare Keep-
live, il content-length, come indicato dalla specifiche di protocollo,
ma niente, di niente.
C'è qualcuno che potrebbe darmi qualche lume?
Grazie mille

 C'č qualcuno che potrebbe darmi qualche lume?
mah, finchč la service della servlet rimane in esecuzione e non rilascia
l'output stream la connessione resta aperta. fatto salvo che il client
deve essere daccordo...
chi č il client? il browser?
 

 chi è il client? il browser?
Innazitutto grazie per la tua risposta, sì, il client sarà un browser.
Come potrei fare?
Grazie ancora.

 Come potrei fare?
intanto, cosa vuoi fare e perchè.
come ti ho detto la connessione resta aperta finchè la servlet esegue la
service e non rilascia l'output stream. basta quindi un loop infinito per
tenere bloccati conennessione e browser.
ma non vedo l'utilità, quindi torno a chiedere cosa vuoi fare.


Ciao Marco,
ho necessità in una applicazione web di ricevere un stream http, in
cui vengano aggiornati dei dati quando si verificano certi eventi.
Nello specifico vorrei instaura una connesione verso questa servlet
con una chiamata javascript e via via che ricevo dati aggiornare il
dom della pagina. L'utilizzo è per implementare una chat simile a
GTalk in una mia applicazione web tra alcuni operatorid i questa
applicazione.
Non voglio fare polling sia perché voglia un'altra reattività e per
ridurre il lo stress verso l'application server.
Io ho provato a fare un loop ma non mi arriva niente, rimane la
connessione appesa, ma sull'output del browswe non arriva niente.
Che ne pensi?
Grazie

 Grazie
Mi intrometto :)
Non sono tanto d'accordo sullo "stressare" l'application server: se
lasci in esecuzione all'infinito una servlet, e quindi tieni impegnate
risorse di memoria/socket/ecc., non stressi comunque il povero server?
Comunque ci sono diverse tecniche per fare quello che ti serve(r),
l'ottimo DWR ne implementa alcune chiamandole "Reverse AJAX" (tu pensa
a che perversioni siamo arrivati...)
Ecco un articolo interessante, proprio sul sito di DWR:
http://getahead.org/dwr/reverse-ajax
--
www.megadix.it

risorse di memoria/socket/ecc., non stressi comunque il povero server?
Mi intrometto anche :)
Questa tecnica e' recentemente meglio conosciuta come COMET o reverse AJAX, 
o pushlet (forse un termine piu' vecchio).
Non so molto di tutto cio', ma alcuni application server la implementatno 
piuttosto bene, utilizzando dei connettori particolari se ho ben capito. In 
sostanza viene risolto il problema della scalabilita' per cui i thread e le 
servlet vengono sospesi e riattivati quando necessario, senza tenere la 
connessione bloccata per tempi lunghi.
In sostanza recenti implementazioni superano il problema dei 100 client 
connessi = 100 connessioni in meno disponibili.
Uno di questi AS mi sembra essere Jetty, ma mi pare di aver visto cose 
simili anche per Tomcat e Glassfish.

 ha scritto nel messaggionews:1181996203....@k79g2000hse.googlegroups.com...

Grazie per le gradite intromissioni e per i graditi consigli.
Anch'io sapevo qualcosa di pushlet, cometa, ecc...
Il problema è che non ho molta conoscenza su tali teconologie e allora
stavo cercando di simulare ciò che realtà ben note utilizzano.
Sicuramente tener appesa una connesione provoca un un certo dispendio
di risorse, ma credo che in termini di cpu sia meno oneroso.
La scelta comunque mi pare obbligata la scelta vista la necessità di
avere tempi di reazione pressoche istantanei.
Ci sono molte cose che mi lasciano un po' perplesso, ad esmpio le
specifiche del protocollo HTTP affermano che la persistenza del
cannessione dovrebbe essere garantita dall'invio di alcuni header, ma
non sono mai riuscito a far funzionare niente.
Inoltre, anche se non il metodo miglio, come mai nel mio test in cui
c'è un ciclo non riesco a ricevere niente sul browser, ma rimane la
connessione indefinitamente appesa?
Ovvio che nell'applicazione reale non utilizzerei un ciclo infinito,
ma semplicemente metterei in attesa il thread di determinati eventi.
Quindi mi consigliate di studiare e utilizzare DWR? In sostanza mi
permetterebbe di fare un reale streamming http.
RIngrazio tutti
Mr. Deckard

Mr. Deckard (16/06/2007 13.54.29):

Allora diciamolo chiaramente: il protocollo HTTP (ed i suoi derivati)
consistono in RICHIESTA -> RISPOSTA -> STOP . Niente altro! l'header
keep-alive è stato introdotto soltanto per un minimo di ottimizzazione,
per consentire al browser, a fronte di una pagina piena di risorse
dipendenti (immagini, audio, flash, ecc...) di riutilizzare lo stesso
socket senza doverlo chiudere e riaprire.
HTTP NON è FATTO PER IL REAL-TIME!!!! LO VOLETE CAPIRE O NO????
Per attuare una cosa del genere è _inevitabile_ (secondo me) rivolgersi
a Java puro, al di fuori di Webserver, EJB e quant'altro: all'interno
della pagina servita inserisci un'applet che utilizza Socket
normalissimi per connettersi ad un'applicazione-server sempre sulla
stessa macchina che ha servito la pagina, *ma su un'altra porta TCP*.
Se poi utilizzi il package java.nio.* e i suoi subpackage, sei in grado
di utilizzare anche un solo thread per servire un centinaio di
connessioni.
Riporto lo schema (che attualmente sto utilizzando dove lavoro):
0) Il server sta eseguendo, oltre al webserver, anche un "servizio" (o
demone, o qualsiasi altra cosa) a sè stante, in uno spazio di processo
separato dallo stesso webserver, in ascolto su un'altra porta (es.
4567). Nota bene: in questo modo il "servizio" può comunicare con il
webserver tramite 127.0.0.1
1) Il browser richiede una pagina al server
2) Il server manda la pagina che contiene il riferimento ad un'applet
java (ovviamente il JRE deve essere installato sulla macchina)
3) L'applet è scritta in modo da connettersi al proprio server
originario (vedi parametri nel tag <OBJECT>) sulla porta del servizio
parallelo, e utilizzando un protocollo custom (può bastare lo scambio
di oggetti serializzati)
4) ....vedi tu come proseguire...
Spero di essere stato chiaro e utile a tutti, e scusate lo sfogo.
-- 
Scientology: se la conosci la eviti, se la conosci non ti uccide...
http://xenu.com-it.net
 - 
http://xenu.freewinds.cx
 - 
http://www.xenu.net
(per rispondere personalmente leva IlDitoDalCulo)
---> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 <---

 ---> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 <---
Ciao e grazie per l'intervento,
per quanto riguarda l'utilizzo dell'http, nessuno di noi, credo, stia
pensando all'http come qualcosa per il real-time. Tuttavia a livello
di specifiche si parla di http long-alive.
Comunque quella dell'applet è una soluzione sicuramente che può
andare, anche se per il tipo di applicazone e la sua destinazione
avevo per il momento scartato, in quanto soggetta alle politiche di
sicurezza del browser.
Mr. Deckard

Mr. Deckard (17/06/2007 13.02.02):

Avevo citato appositamente il fatto di connettersi *allo stesso
indirizzo* del server da cui prelevi la pagina web, perchè questo tipo
di connessione non è soggetto a blocco da browser. Vai tranquillo.
La politica di sicurezza di una jvm all'interno di un browser blocca
(per applet non firmate) queste azioni:
- accesso al file system (se non esplicitamente richiesto dall'utente)
- ascolto su socket (e vorrei ben vedere)
- connessione ad altri indirizzi diversi dal server originario
- la creazione di finestre Swing/AWT non è bloccata, ma ogni finestra
creata possiete una nota sul bordo inferiore che cita "Attenzione!
Questa è una finestra dell'applet Java" (o qualcosa di simile)
-- 
Scientology: se la conosci la eviti, se la conosci non ti uccide...
http://xenu.com-it.net
 - 
http://xenu.freewinds.cx
 - 
http://www.xenu.net


 - in due parole reinventarsi l'acqua calda (e tanta...)
Beh dai, non è che ce l'ho con http, solo che http è stato creato con
uno scopo ben preciso, e mi da i nervi vederlo "abusato" in compiti per
cui esistono sistemi ben più prestanti... GET -> RISPOSTA -> STOP, non
c'è niente di più, e sento già parlare di "tenere aperta la
connessione" vita natural durante, ma dai...
per i punti a favore dell'http:
- collegarsi ad una servlet: è http, siamo ancora sul polling (che Mr
Deckard aveva chiesto di evitare)
a proposito, per Mr Deckard: GTalk usa Ajax, che non è altro che
polling http...
- usufruire della stessa connessione: il keep-alive è un suggerimento,
che il server può decidere di ignorare. Insomma, non è garantito lo
stesso comportamento portando l'applicazione su un'altra piattaforma
- rimanere all'interno della sicurezza della webapp: ci rimani comunque
usando socket puri verso lo stesso server che ha servito la pagina
per i punti a sfavore della connessione diretta via applet:
- sviluppare un server (quando ne hai già uno gratis): il server che
hai gratis è già specializzato per una cosa che non ti basta in questo
momento
- progettare per intero la sicurezza, visto che siamo al di fuori del
contesto della web application: l'autenticazione la puoi gestire con
una transazione http (java.net.url ti dice qualcosa?) dal server custom
verso 127.0.0.1, e mantenere un id univoco... dai, non è così
difficile!
Reinventare l'acqua calda? non direi... c'è una certa esigenza che
richiede uno sviluppo specifico, a meno che l'autore originario non
accetti l'idea di dover rimanere con polling http. Che sinceramente
(parere personale, eh!) mi è sempre sembrato una grandissima porcata,
nonostante applicazioni eccezionali come Google Maps, Twitter, ecc...
Tutto questo perchè, dopo la "zampata" di Microsoft,  non è mai stata
più prevista la presenza di una Java Virtual Machine come componente di
sistema.


 - Mostra testo tra virgolette -
Non credevo che la discussione si sarebbe fatta così animata...
Comunque GTalk sicuramaente NON utilizza Ajax puro (probabilmente un
reverse-ajax?) ... Se provate un po' a guardare il codice, certamente
tengono una connessione HTTP sempre aperta....
Anche perché altrimenti non potresti avere tutta una serie di
informazioni in tempo praticamente reale, ad esempio se qualcuno sta
digitando o meno.
Per quanto riguarda la mia scelta di scartare le applet è dovuta al
fatto che l'applicazione che sto srivendo deve avere come requisito
fondamentale quello che l'utilizzatore non si debba preoccupare di
configurare browser ecc... Vedi ActiveX, applet ecc... Ovvero deve
poter essere utilizzato senza alcuna necessità di dover intervenire
sulla configurazione. In quanto gli utilizzatori finali potranno non
avere alcuna cultura informatica (Sigh!!!  questo è quanto chiede il
cliente!)
Mr. Deckard

 difficile!
onestamente non mi sembri affatto nella condizione di fare il maestrino 
che da le bacchettate nelle mani.
e visto che ti permetti queste licenze mi permetto anch'io di non avere 
peli sulla lingua: la tua ipotesi di soluzione è un gran bel troiaio.
trattandosi di questioni basilari mi rifiuto anche di motivare.

 trattandosi di questioni basilari mi rifiuto anche di motivare.
Evidentemente abbiamo pareri e esperienze diverse. Ti chiedo scusa, non
era mia intenzione darti alcun genere di lezione. Probabilmente mi sono
lasciato prendere dalla foga di sostenere a tutti i costi le mie idee.
Forse le cose sono cambiate, probabilmente per me è ora di inizare a
sperimentare qualcosa di diverso dalle abitudini.
Non prenderla a male, quando si arriva ad un litigio non è mai una
bella cosa.


 a Java puro, al di fuori di Webserver, EJB e quant'altro:
Soluzioni fat client. Non si capisce perche' devi escludere EJB che non 
centra proprio una mazza. EJB puo' anche entrare in gioco tra un applet e un 
server o un client qualsiasi e server.
In sostanza se ci offrono la possibilita' di utilizzare HTTP per scambiare 
informazioni tra il client e il server in maniera asincrona e dove anche il 
server puo' decidere quando spedire l'informazione...beh perche' non 
utilizzarle?
Le applet non le vuole piu' nessuno e una soluzione fatta con javascript 
puo' essere  preferibile (sempre che si possa fare).
Tra l'altro queste soluzioni ci sono e si usano da anni... 

 ha scritto nel messaggionews:mn.8ae57d76d...@email.it...

Beh in ultima analisi,
posso dire che il mio lavoro l'ho realizzato utilzzando ajax e dunque
http.
Devo dire che le indicazioni che mi erano state date erano correte.
Come dicevo, analizzando un po' il funzionamento di gtalk si comprende
che sia stata utilizzata una connessione http persistente.
Ringrazio tutti per il dibattito e lo stimolo a prendere in
considerazione ogni possibilità.
Mr. Deckard