Torna indietro   Hardware Upgrade Forum > Software > Programmazione

iPhone 17 Pro: più di uno smartphone. È uno studio di produzione in formato tascabile
iPhone 17 Pro: più di uno smartphone. È uno studio di produzione in formato tascabile
C'è tanta sostanza nel nuovo smartphone della Mela dedicato ai creator digitali. Nuovo telaio in alluminio, sistema di raffreddamento vapor chamber e tre fotocamere da 48 megapixel: non è un semplice smartphone, ma uno studio di produzione digitale on-the-go
Intel Panther Lake: i processori per i notebook del 2026
Intel Panther Lake: i processori per i notebook del 2026
Panther Lake è il nome in codice della prossima generazione di processori Intel Core Ultra, che vedremo al debutto da inizio 2026 nei notebook e nei sistemi desktop più compatti. Nuovi core, nuove GPU e soprattutto una struttura a tile che vede per la prima volta l'utilizzo della tecnologia produttiva Intel 18A: tanta potenza in più, ma senza perdere in efficienza
Intel Xeon 6+: è tempo di Clearwater Forest
Intel Xeon 6+: è tempo di Clearwater Forest
Intel ha annunciato la prossima generazione di processori Xeon dotati di E-Core, quelli per la massima efficienza energetica e densità di elaborazione. Grazie al processo produttivo Intel 18A, i core passano a un massimo di 288 per ogni socket, con aumento della potenza di calcolo e dell'efficienza complessiva.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 21-12-2010, 15:16   #1
clockover
Senior Member
 
L'Avatar di clockover
 
Iscritto dal: Oct 2004
Messaggi: 1945
[JSP] - Perdo il controllo di un thread

Come da titolo!

Ho una pagina jsp molto semplice che nella sua fase di init (jspInit()) chiama un thread, il quale si mette in ascolto di una serversocket! Il thread in questione è un qualcosa del tipo
Codice:
while(true){
    Socket sock = null;
    sock = serversocket.accept();
    exs.submit(unThreadPerLaRicezione(sock));
}
dove exs è un ExecutorService!

nella fase di destroy della Servlet (jspDetroy()) eseguo alcune operazioni quali chiusura del FileWriter del log, ecc... quando voglio chiudere anche il thread che è in ascolto eseguo una cancel(true) dato che il thread è rappresentato da una Future
Codice:
Future ft = exs.submit(threadServer);
....
.....
void jspDestroy(){
    ft.cancel(true);
}
Il problema è che andando a leggere il log di tomcat ho scoperto che il thread che ho cercato di uccidere è ancora li!
Questo è quello che mi dice netbeans
Codice:
GRAVE: The web application [/App] appears to have started a thread named [pool-1-thread-1] but has failed to stop it. This is very likely to create a memory leak.
Ho fatto anche altre prove, ad esempio un altro thread che a scadenza regolare, tipo di un secondo, scrive su un file qualcosa! Quando viene eseguita la destroy questo thread di prova finisce, mentre quello in ascolto sulla ServerSocket è ancora attivo!


Cosa mi sfugge da questa situazione?

edit:
anche quando chiudo Tomcat il thread rimane attivo

Ultima modifica di clockover : 21-12-2010 alle 15:25.
clockover è offline   Rispondi citando il messaggio o parte di esso
Old 21-12-2010, 15:28   #2
banryu79
Senior Member
 
L'Avatar di banryu79
 
Iscritto dal: Oct 2007
Città: Padova
Messaggi: 4131
Quote:
Originariamente inviato da clockover Guarda i messaggi
Cosa mi sfugge da questa situazione?
La chiamata a Future.cancel(true) non termina veramente l'esecuzione del thread, semplicemente segnala al thread in questione di terminare il prima possibile (il fatto di passare true come parametro indica al Future che deve settare a true il flag per l'interrupt del thread, ma pure questo non causa una terminazione immediata del thread).

Bisogna quindi che il thread, nel suo flusso di esecuzione, dia supporto alle eventuali richieste di interrupt/cancellazione che gli arrivano.
Ci sono vari modi per farlo.

A questa vecchia discussione nei miei messaggi (dal #16 in poi) trovi delle info in merito (roba che trovi tranquillamente nella documentazione/tutorial della Sun[ops... Oracle]), non so quale sia il tuo livello di competenze quindi scusa in anticipo se ti indico un thread che contiene roba che già conosci.

Comunque il succo è: controlla cosa fa il tuo thread, e vedi se supporta "correttamente" le richieste di interruzione.
__________________

As long as you are basically literate in programming, you should be able to express any logical relationship you understand.
If you don’t understand a logical relationship, you can use the attempt to program it as a means to learn about it.
(Chris Crawford)

Ultima modifica di banryu79 : 21-12-2010 alle 15:30.
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 21-12-2010, 15:53   #3
clockover
Senior Member
 
L'Avatar di clockover
 
Iscritto dal: Oct 2004
Messaggi: 1945
Anche in rete ho trovato soluzioni simili a quelle che hai scritto nel tuo vecchio post! E in effetti le ho utilizzate e si sono rivelate funzionali! Il fatto è che il thread rimane bloccato in attesa di una connessione con l'esterno! Potrei inserire un timeout, ma non mi sembra una soluzione particolarmente efficiente!

Ho trovato questa discussione! Sembra simile al mio problema!
http://stackoverflow.com/questions/1...rsocket-accept

Faccio un po di tentativi!

ps
le mie competenze sono sicuramente molto poche
clockover è offline   Rispondi citando il messaggio o parte di esso
Old 21-12-2010, 16:08   #4
clockover
Senior Member
 
L'Avatar di clockover
 
Iscritto dal: Oct 2004
Messaggi: 1945
In effetti sembra funzionare adesso! Quindi la chiusura della ServerSocket mi fa scatenare una IOException all'interno del thread e gestendola posso chiudere il thread! Mi mandava in confusione la future.cancel()!
Dunque devo essere capace di gestire per ogni thread un meccanismo di chiusura altrimenti me lo ritrovo sempre in vita!
clockover è offline   Rispondi citando il messaggio o parte di esso
Old 21-12-2010, 16:17   #5
banryu79
Senior Member
 
L'Avatar di banryu79
 
Iscritto dal: Oct 2007
Città: Padova
Messaggi: 4131
Umm... interessante, ho letto il link che hai postato.
Se non vuoi optare per la ServerSocketChannel (che risponde agli interrupt) e vuoi continuare ad usare ServerSocket (che invece oltre a essere bloccante pare pure ignorarli finchè non termina) devi ingegnarti con qualche "barbatrucco".

La prima cosa che mi viene in mente, e forse ci hai già pensato anche tu, è il fatto di incapsulare l'operazione di accept con un timeout in un ciclo.
Il cilco termina "normalmente" solo quando la accept ha esito positivo, e quindi si è stabilita una connessione.
La accept però è vincolata ad un timeout: quando il timeout scade controlli se il flag di interrupt del Thread corrente è stato settato, nel qual caso lanci a tua volta una InterruptedException; altrimenti non fai nulla e il cilco continua allegramente.

@EDIT:
Quote:
In effetti sembra funzionare adesso! Quindi la chiusura della ServerSocket mi fa scatenare una IOException all'interno del thread e gestendola posso chiudere il thread! Mi mandava in confusione la future.cancel()!
Ah ecco, mi pareva strano: allora è decisamente meglio non "barbatruccare" niente e fare così

Quote:
Dunque devo essere capace di gestire per ogni thread un meccanismo di chiusura altrimenti me lo ritrovo sempre in vita!
Esattamente. Bisogna essere vigili
__________________

As long as you are basically literate in programming, you should be able to express any logical relationship you understand.
If you don’t understand a logical relationship, you can use the attempt to program it as a means to learn about it.
(Chris Crawford)

Ultima modifica di banryu79 : 21-12-2010 alle 16:20.
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 21-12-2010, 16:33   #6
clockover
Senior Member
 
L'Avatar di clockover
 
Iscritto dal: Oct 2004
Messaggi: 1945
Comunque avevo già fatto un tentativo del genere, cioè chiudendo la ServerSocket, ma probabilmente mi ero dimenticato di gestire l'eccezione e quindi stavo punto e accapo, anzi era pure peggio perchè dovevo chiudere poi con cattiveria!

Grazie per i suggerimenti banryu
clockover è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


iPhone 17 Pro: più di uno smartphone. È uno studio di produzione in formato tascabile iPhone 17 Pro: più di uno smartphone. &Eg...
Intel Panther Lake: i processori per i notebook del 2026 Intel Panther Lake: i processori per i notebook ...
Intel Xeon 6+: è tempo di Clearwater Forest Intel Xeon 6+: è tempo di Clearwater Fore...
4K a 160Hz o Full HD a 320Hz? Titan Army P2712V, a un prezzo molto basso 4K a 160Hz o Full HD a 320Hz? Titan Army P2712V,...
Recensione Google Pixel Watch 4: basta sollevarlo e si ha Gemini sempre al polso Recensione Google Pixel Watch 4: basta sollevarl...
Cyber Arena Tour: WINDTRE BUSINESS porta...
Addio Microsoft Word: la Cina sceglie WP...
Nano Banana si espande: l’AI di Google p...
Che fare con i Tesla Cybertruck invendut...
Simucube 3 Sport, Pro e Ultimate ufficia...
Facebook rilancia le offerte di lavoro: ...
Hisense PT1: il cinema in casa con la po...
Pixel 10: come risolvere (forse) i crash...
Plenitude lancia la sua Fibra ottica: fi...
Apple TV+ elimina il 'plus' dal nome: or...
Prezzi da outlet in saldo su 23 articoli...
Death 2 Spotify: a Oakland nasce il movi...
Vivo presenta X300 e X300 Pro: due flags...
iPad mini con chip A17 Pro: potenza da M...
Samsung cresce oltre le attese grazie al...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 11:03.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v