Mi piacerebbe aggiungere groovy-shell-server alla nostra applicazione. Recentemente abbiamo riscontrato un paio di problemi di produzione in cui una chiamata a un'API interna avrebbe potuto velocizzare la diagnosi o addirittura fornito una correzione a breve termine. Groovy-shell-server fornisce un buon modo per raggiungere questo obiettivo.È troppo rischioso chiamare Thread.stop su un thread di server GroovyShell in esecuzione?
Ma in realtà l'utilizzo di questo in produzione introduce una potenziale complicazione. Diciamo che, nonostante un'attenta peer review, eseguiamo uno script che impegna la CPU, o si blocca in un loop infinito. Ho bisogno di un modo per uccidere quel filo, pronto! Quindi stavo pensando di migliorare groovy-shell-server per supportare un hard stop() opzionale di un thread client Groovy in esecuzione.
So che Thread.stop() is inherently unsafe; è stato discussed on StackOverflow before. La mia domanda è, pensi che i benefici potrebbero superare i rischi in questo caso? Sta usando Thread.stop() una scelta pragmatica come una sorta di "freno di emergenza" per un thread di server GroovyShell in fuga? O la probabilità di lasciare oggetti in uno stato incoerente è troppo alta?
(In alternativa, se qualcuno ha un modo migliore per fornire programmatica, interrompibile l'accesso a un'applicazione Java in esecuzione, sono tutto orecchi.)
In realtà non sto contestando se Thread.stop() fermerà davvero il thread - lo farà sicuramente. La domanda è se sia troppo rischioso interrompere il thread a causa della possibilità di lasciare vari oggetti in cattivo stato. In generale, tuttavia, ritengo di essere d'accordo con te sul fatto che questo è probabilmente un caso in cui i benefici sovrastimano i rischi. – greghmerrill
@greghmerrill * Thread.stop() interromperà veramente il thread - sicuramente lo farà. *, Non necessariamente i thread in attesa su un monitor potrebbero non essere fermati (cioè devi uccidere il thread che tiene il lock 1). 'Thread.stop()' è * quasi * ok nel caso in cui si sappia se è possibile utilizzarlo, esaminare la traccia dello stack e contrassegnare alcuni momenti pericolosi. In alternativa, usa un codice enhancer che pepa il codice e controlla 'Thread.interrupt()' o chiama qualsiasi altro punto * safe * statico per lanciare un errore simile a ThreadDeath. – bestsss
@bestsss _non necessariamente i thread in attesa su un monitor non possono essere fermati (cioè devi uccidere il thread che tiene il blocco 1) _ - questa era una novità per me, grazie per il suggerimento! Io [ho provato] (https://gist.github.com/1183567) e hai sicuramente ragione, l'interruzione di una discussione che sta acquisendo un blocco non fermerà immediatamente quel thread, anche se si fermerà non appena il blocco sarà acquisita. – greghmerrill