21 risposte a questa discussione

[Sgurbat]

Ciao,

 

allora per farla breve ho un'applicazione in cui un paio di Jar vengono lanciati e rimangono in esecuzione come servizi di Windows.

 

Questi Jar sono fondamentalmente dei Consumer in ascolto su una coda, leggono i messaggi e fanno partire delle lavorazioni su FileSystem.

 

Non hanno mai dato problemi salvo che da un po di tempo gli stessi sembrano killare il processo Win in cui sono wrappati.

 

Per farli funzionare in "modalità provvisoria" abbiamo provato a lanciarli da console e lasciare appesa la sessione ma anche qui ci siamo ritrovati con i processi stoppati e le console chiuse.

 

Ora: cosa potrebbe causare questa caduta dei servizi? Ho già provato a guardare nel registro degli eventi sul server ma i log riportano tale accadimento come semplice stop del servizio senza indicarne la causa.

 

Come è possibile inoltre che lanciandoli a mano e non chiudendo la sessione sul server li abbiamo ritrovati stoppati MA SOPRATTUTTO con le console chiuse? Ho chiesto e nessuno ha riavviato il server.

 

Tnx.

Messaggio modificato da Sgurbat il 23 giugno 2013 - 10:39

[Sgurbat]

La cosa strana è che altri Jar (quasi del tutto identici a livello di codice) funzionano senza problemi in altri contesti applicativi ovvero i servizi in cui sono wrappati non vanno giù.

[TigerShark]

Ma non loggate le eccezioni al livello piu' alto su file?
Per me è un'eccezione non catchata che fa morire il servizio..

[toyo]

anche noi come extrema ratio per le eccezioni non catchate nell'appdomain logghiamo, almeno se crasha poi sgami il perché


also per la roba critical parte una mail al reparto

[Sgurbat]

Ma non loggate le eccezioni al livello piu' alto su file?
Per me è un'eccezione non catchata che fa morire il servizio..

 

Certo che logghiamo su file, ma non c'è nulla riconducibile a qualcosa che causi il down del servizio.

 

Ad ogni messaggio scodato parte un task di lavorazione, se per qualunque motivo tale task si interrompe causa eccezione gestita o meno viene comunque catchata in modo da non interrompere lo scodamento dei messaggi successivi e relativi task.

 

Ergo parrebbe impossibile che la causa sia un'eccezione non gestita.

[Sgurbat]

anche noi come extrema ratio per le eccezioni non catchate nell'appdomain logghiamo, almeno se crasha poi sgami il perché


also per la roba critical parte una mail al reparto

 

L'invio della mail in caso di errore l'abbiamo anche noi, solo spiegami quella cosa delle eccezioni non gestite nell'appdomain che mi sfugge.

 

Tnx

[Sgurbat]

Domanda: potrebbe essere qualcosa legato all'uso della memoria?

Messaggio modificato da Sgurbat il 23 giugno 2013 - 13:20

[TigerShark]

Certo che logghiamo su file, ma non c'è nulla riconducibile a qualcosa che causi il down del servizio.
 
Ad ogni messaggio scodato parte un task di lavorazione, se per qualunque motivo tale task si interrompe causa eccezione gestita o meno viene comunque catchata in modo da non interrompere lo scodamento dei messaggi successivi e relativi task.
 
Ergo parrebbe impossibile che la causa sia un'eccezione non gestita.

fai un catch di exception o di throwable?

[TigerShark]

L'invio della mail in caso di errore l'abbiamo anche noi, solo spiegami quella cosa delle eccezioni non gestite nell'appdomain che mi sfugge.
 
Tnx

l'application domain è un concetto di c# per separare varie parti di un'applicazione in una specie di versione leggera dei processi, cosicché un crash dovuto al managed code di un dominio non causi il crash dell'intera applicazione.
Per l'unmanaged code però ovviamente non funziona.
E cmq non esiste in Java.

[TigerShark]

Domanda: potrebbe essere qualcosa legato all'uso della memoria?

potrebbe essere un crash della vm che potrebbe essere anche causato da problemi di memoria se stai già catchando throwable.
Però in quel caso avrai dei log file generati dalla jvm nella stessa dir da dove parte l'eseguibile se non ricordo male.

[toyo]

che è throwable?

[TigerShark]

che è throwable?

la classe base per le eccezioni in Java che comprende anche le unchecked come runtimeexception

[toyo]

ah ok

[Sgurbat]

potrebbe essere un crash della vm che potrebbe essere anche causato da problemi di memoria se stai già catchando throwable.
Però in quel caso avrai dei log file generati dalla jvm nella stessa dir da dove parte l'eseguibile se non ricordo male.

 

Io faccio un catch di Exception nel livello più alto del mio codice

[TigerShark]

Io faccio un catch di Exception nel livello più alto del mio codice

devi catchare throwable perché altrimenti ti perdi tutte le unchecked exception che ti fanno crashare.
E ovviamente rilanciarla dopo che l'hai loggate perché tutte le subclass di error rappresentano errori che non è possibile recuperare.

Messaggio modificato da TigerShark il 23 giugno 2013 - 16:21

[Sgurbat]

Ma possibile che un'eccezione unchecked faccia crashare il servizio?

[ally]

Ma possibile che un'eccezione unchecked faccia crashare il servizio?

 

...assolutamente si...hai i sorgenti?...

[Sgurbat]

...assolutamente si...hai i sorgenti?..

 

Si ... al lavoro. 

[toyo]

si ma basta java dai

[matti157]

si ma basta java dai

C#?