2010-04-25 24 views
21

Per impostazione predefinita WebLogic elimina i thread bloccati dopo 15 minuti (600 s), questo è controllato dal parametro StuckThreadMaxTime. Tuttavia, non riesco a trovare maggiori dettagli su come viene definita esattamente la "stuckness". In particolare:Protezione thread WebLogic bloccato

  • Qual è il punto in cui inizia il conto alla rovescia di 15 min. Inizia l'elaborazione della richiesta? Ultimo metodo wait() -like? Qualcos'altro?
  • Questo si applica solo ai thread di elaborazione delle richieste oa tutti i thread? Cioè un thread di elaborazione richieste può "scappare" questa protezione creando un thread di lavoro per un'attività lunga? Soprattutto, può delegare la risposta scrivendo a un tale lavoratore senza un conto alla rovescia di 15 min?

Il mio caso è il download di file enormi tramite un sistema di autorizzazione. Poiché un utente deve essere autenticato e disporre delle autorizzazioni per visualizzare un file, non posso (o almeno non so come) lasciare questo ad un semplice server HTTP, ad es. Apache. E poiché i file possono essere enormi, il download potrebbe richiedere (almeno in teoria) più di 15 minuti.

risposta

21

Weblogic fa NON kill thread bloccati dopo lo StuckThreadMaxTime. Non è possibile farlo, il messaggio è solo informazioni sullo stato in modo che tu (amministratore) sia consapevole del fatto che il thread ha attraversato 10 minuti (600 sec = 10 min, non 15)

Questo è un valore configurabile.

Il timer inizia quando il thread inizia ad elaborare la richiesta all'interno del server. Il thread non verrà ucciso ma continuerà a essere elaborato fino al termine dell'operazione. quindi nel tuo caso, non devi preoccuparti che il thread venga ucciso, ti ha appena informato del tempo impiegato, di cui sei a conoscenza in questo caso d'uso.

Si applica a tutti i thread AFAIK - qualsiasi thread generato funzionerà anche secondo le stesse regole.

IMHO, Weblogic (o qualsiasi server delle applicazioni) non è il luogo in cui archiviare e pubblicare file di grandi dimensioni. Questo è idealmente pensato per il livello del server Web: utilizziamo SunOne su cui è possibile eseguire il servlet di download dei file. Nel tuo caso, avresti bisogno di Tomcat insieme al tuo Apache per ottimizzarlo.

+0

OK, ma come so può ridistribuire l'intera applicazione se ci sono troppi thread bloccati, no? Potrei aver mescolato le cose con il timeout della sessione - abbiamo avuto qualche problema in passato. Informazioni sui file: l'applicazione è così grande e buggata che non c'è tempo da dedicare all'ottimizzazione in quanto vi sono sempre problemi più urgenti. – doublep

+6

Il server smetterà di rispondere alle nuove richieste se ci sono troppi thread bloccati, ma nel tuo caso non sono realmente "bloccati" ma elaborano richieste lunghe. Un approccio migliore consiste nel fornire a FileDownloadServlet il proprio pool di thread di esecuzione: su WL10 questo sarà un WorkManager dedicato. Ciò garantisce che qualsiasi thread bloccato/interessato nel download non influenzi il resto del server che elabora le richieste normali. vedere qui per ulteriori informazioni - http://download.oracle.com/docs/cd/E11035_01/wls100/config_wls/self_tuned.html#wp1059038. È possibile definire un criterio di invio per tale servlet. – JoseK

+0

Grazie per la risposta e i chiarimenti. – doublep

7

La documentazione di WLS10 WorkManager può causare un vero e proprio headcratching. Vedere http://blogs.oracle.com/jamesbayer/2010/01/work_manager_leash_for_slow_js.html per un esempio dettagliato di come definire un WorkManager per una webapp in weblogic.xml e assegnare un servlet specifico per utilizzarlo.

In aggiunta a questo esempio, è possibile aggiungere <ignore-stuck-threads>true</ignore-stuck-threads> alla definizione <work-manager> che dovrebbe evitare che le discussioni che lavorano per quella WorkManager di essere contati contro uno stato server guasto.

+1

Proprio quello che stavo cercando, grazie! –

Problemi correlati