Quanto hot deployment funziona internamente?

Question

Utilizzo la funzionalità del server Eclipse per la distribuzione di hot code. Usando tomcat come server web. Ma non sono sicuro di come funzioni. Ho la mia comprensione di come deve funzionare internamente.

mia comprensione: -. Quando sviluppatore apportare le modifiche nel codice (dicono classe Employee), Eclipse piazzerà/pubblicherà la classe compilata modificato nella posizione a destra (deve essere specifico del server web/app consente di chiamare directory deploy caldo (HDD)) sotto webserver. Ora il caricatore di classe specifico per il server Web arriverà per la visualizzazione. Trova la nuova voce in HDD. Ora, trova se la classe è già stata caricata dal classloader nello spazio perm gen, il server web lo scaricherà dallo spazio permgen e caricherà quello nuovo internamente senza il riavvio del server in modo che le nuove modifiche (codice byte) si riflettano. Come parte del ricaricamento, il server web collegherà anche gli oggetti Epmloyee esistenti con la nuova definizione di classe nello spazio genovideo cosicché le nuove modifiche vengano riflesse.

La mia comprensione è corretta?

Alcuni collegamenti come this indicano che la distribuzione di Eclipse è solo l'automazione della ridistribuzione. quello che credo significhi che eclipse fermi automaticamente il server, lo ripubblici e lo riavvii senza l'intervento dello sviluppatore. Buti penso che non sia vero in quanto questo processo è molto veloce rispetto all'avvio/pubblicazione/riavvio. Anche se sarebbe stato vero, in che modo la sessione e gli altri oggetti live rimarranno in diretta dopo il riavvio? Potrebbe essere che questo collegamento fosse vero in passato ma non ora perché trovo che l'implementazione a caldo funziona anche per le classi in jar

Answer 1

La distribuzione di codice caldo dipende dalle funzionalità di runtime. La risposta a linked to non significa che l'automazione arresta il server distribuisce il nuovo codice e avvia nuovamente il server. Questo sarebbe stato dispendioso.

Al contrario, la maggior parte dei server di applicazioni Java è in grado di reimplementare l'applicazione . Significa che il server creerebbe un nuovo caricatore di classi di applicazioni Web, caricherà la nuova versione dell'applicazione con questo nuovo caricatore di classi, in alcuni casi migrerà lo stato (serializzi/deserializza la sessione HTTP) e rilascia la vecchia versione dell'applicazione .

Ora la velocità di ridistribuzione dipende molto dall'applicazione stessa - come viene inizializzata l'applicazione. Ha bisogno di scaldare le cache? Deve soddisfare le dipendenze (a-las Spring, CDI)? Deve inizializzare Hibernate SessionFactory? Sono coinvolti molti fattori.

Ciò che Eclipse WTP fa in modo naturale è che può attivare il processo di ridistribuzione per il contenitore di applicazioni, il gioco è fatto. Una piccola applicazione non richiederà molto tempo per la ridistribuzione, ovviamente.

A meno che non ci sia una speciale tecnologia/contenitore/framework runtime e per Eclipse sia stato sviluppato un connettore speciale per sfruttare un hook che attiva il codice hot aggiornato per quella specifica tecnologia. Un buon esempio è bndtools per il runtime OSGi.

E proprio per rimuovere una certa confusione:

Spesso le persone confondono HotSwap e calda distribuzione. Il primo, HotSwap, è la capacità di JVM di aggiornare la definizione della classe in fase di esecuzione.Quest'ultimo, la distribuzione a caldo, è la capacità del server delle applicazioni di distribuire automaticamente l'applicazione, in modo incrementale o meno, senza riavviare il processo JVM.

Quindi la mia risposta riguarda l'implementazione a caldo e non quella su HotSwap. Quindi mi riferisco alla distribuzione a caldo come a una "automazione" piuttosto che a un meccanismo fondamentale della piattaforma.