2012-09-10 11 views
8

Il nostro metodo di distribuzione di una nuova versione di un'app per weblogic (11g) consiste nel copiare sopra il file ear esistente e quindi arrestare e riavviare il server weblogic. Facciamo uno start/stop di weblogic piuttosto che una ridistribuzione, a causa del noto problema di permgen (dove alla fine avremo finito il perm gen e dovremo rimbalzare il server weblogic).Come faccio a ricaricare weblogic JSP nella cache al riavvio

Tuttavia, questo metodo di distribuzione presenta uno svantaggio: le nuove versioni JSP non sono visualizzate da weblogic. Per risolvere questo problema, abbiamo dovuto eliminare i contenuti della directory tmp che conserva una cache dei JSP compilati prima di riavviare il server. Esiste un'impostazione che dovrebbe dire a weblogic di cancellare la cache/ricaricare/ricompilare JSP quando viene avviato il backup?

risposta

1

Per evitare questo, è necessario innanzitutto aggiornare il modulo e riavviare il server. Questo dovrebbe risolvere il problema.

Anche se il processo indicato da è sempre dare la correttezza al 100%. Ma puoi provare i passaggi sopra indicati.

4

Cambiare il timer di aggiornamento JSP

Una soluzione standard è di dire Weblogic per controllare JSP freschezza più frequentemente da una impostando il valore nel vostro web.xml o nel vostro weblogic.xml.

In modalità di produzione, Weblogic non verificherà nuove versioni JSP (valore predefinito: -1) mentre fa ogni secondo in modalità di sviluppo (valore predefinito : 1).

La scelta tra la modifica di web.xml o weblogic.xml dipende da voi, per quanto riguarda i server delle applicazioni target, solo WebLogic o meno.

Se si preferisce modificare web.xml, quindi impostare un valore per il parametro di contesto weblogic.jsp.pageCheckSeconds come segue:

<context-param> 
    <param-name>weblogic.jsp.pageCheckSeconds</param-name> 
    <param-value>0</param-value> 
</context-param> 

Se si preferisce modificare weblogic.xml, quindi impostare un valore per il parametro page-check-seconds nella sezione jsp-descriptor. Ecco l'estratto pertinente dalla documentazione:

Imposta l'intervallo, in secondi, in cui WebLogic Server verifica se i file JSP sono stati modificati e devono essere ricompilati. Le dipendenze vengono anche controllate e ricaricate in modo ricorsivo se modificate. Il valore -1 significa mai controllare le pagine. Questo è il valore predefinito in un ambiente di produzione. Il valore 0 significa sempre controllare le pagine. Il valore 1 significa controllare le pagine ogni secondo. Questo è il valore predefinito in un ambiente di sviluppo. In un ambiente di produzione in cui le modifiche a un JSP sono rare, è consigliabile modificare il valore di pageCheckSeconds su 60 o maggiore, in base ai requisiti di ottimizzazione.

Fonte

: http://docs.oracle.com/cd/E21764_01/web.1111/e13712/weblogic_xml.htm#i1038490

Forzare ridistribuzione

server di riavvio Weblogic non costringerlo a ridistribuire un'applicazione Web (in particolare in modalità di produzione).

Soluzione trigger in modo esplicito il "ridistribuire" il funzionamento del ciclo di vita utilizzando riga di comando in questo modo:

java -cp weblogic.jar weblogic.Deployer -redeploy [-remote -adminurl t3://hostname:hostport] -username login -password password -name webapp.name [-upload -source webapp.war] 
  • noti che -redeploy è MODI molto più sicuro che -update, esp. con Weblogic < = 10.x

  • Mantieni il primo blocco tra [], solo se il server non è locale. Rimuovi [] in quel caso.

  • Mantieni il secondo blocco tra [], se desideri combinare il file di WAR nel file WAR nello stesso passaggio, che è molto più semplice. Rimuovi [] in quel caso.

+1

Ho lo stesso problema. Il page-check-seconds funziona bene quando si modificano direttamente i file JSP distribuiti. Nello scenario descritto da @BestPractices, dove il server è spento e quindi i file vengono distribuiti, weblogic non sembra notare che tutti/alcuni dei file sono stati modificati e utilizza invece le classi generate. –

Problemi correlati