Debug Java remoto in cross-continente

Quando si collega il debugger in un IDE (IntelliJ o Eclipse) a una JVM in esecuzione in un altro continente (da Londra a New York) il ritardo è insopportabile. Ho aspettato più di 10 minuti per IntelliJ per popolare i miei stackframes e riempire gli oggetti prima di mollare quando si colpisce un breakpoint. (nota: non ho mai visto uno stato di debug completamente popolato quando si fa questo!) Ciò rende impossibile il debug remoto usando un IDE!Debug Java remoto in cross-continente

Sono a conoscenza dello strumento jdb, che non presenta problemi di questo tipo. Immagino perché è più sintonizzato su dati specifici recuperati dalla VM piuttosto che popolando ogni stack frame e tutti i valori accessibili.

Qualcuno sa se esiste un terreno intermedio? Trovo jdb ingombrante da usare - Mi piacerebbe vedere un'interfaccia utente (costruita in cima a jdb) che non ha riscontrato problemi di lag di un IDE. Qualcuno sa se esiste una tale applicazione?

Qualcuno conosce altre tecniche per eseguire il debug di macchine virtuali remote in esecuzione a migliaia di chilometri di distanza?

fonte

2010-02-17 Jack Griffith

La connessione TCP/IP è compressa? Aiuta un bel po '. –

Probabilmente ha più a che fare con la larghezza di banda della connessione di qualsiasi cosa abbia a che fare con il debugger.

fonte

2010-02-17 20:29:47 Goibniu

Non si può fare molto quando la luce può viaggiare solo da lì e tornare a 500 ms – Earlz

Acquista qualcosa come un linodo o un altro VPS in esecuzione su detto continente (o se hai amici con larghezza di banda di riserva che vivono nel continente).

Setup X-Forwarding ed eseguire l'IDE sul VPS che si collega ad esso da casa con ssh.

Speriamo che il ritardo grafico X sia più sopportabile (suggerimento: sì) del ritardo di debug di cui hai parlato.

fonte

2010-02-17 20:33:48 Earlz

Anche la grafica X può essere piuttosto dolorosa (la compressione a volte aiuta, ma soprattutto no). VNC può essere un po 'meglio, ma non è ancora grande. Il Sun SSGD oi protocolli/metodi Microsoft RD sono un drastico miglioramento se è possibile utilizzarli. –

In realtà non ho usato X per lunghe distanze, ma so che VNC non è male quando si collega all'altro lato degli Stati Uniti. Finché si ha una risoluzione ragionevole e così via. – Earlz

Stavo usando IDE IntelliJ 7.0.5 e il debug era orribile. Da allora ho aggiornato a IntelliJ 9 e il ritardo sembra essere sopportabile.

Immagino che IntelliJ 7.0.5 stia facendo qualcosa di "interessante" quando si parla con la VM remota.

fonte

2010-02-25 09:52:08

Il tuo problema non è insolvibile: faccio il contrario (da New York a Londra) usando Eclipse. Non è vivace, ma non è nemmeno lontanamente insopportabile, e niente come quello che descrivi.

avrei chiesto tre domande:
1) sono assolutamente legato alla IntelliJ?
2) Si dispone di copie dei vasi dipendenti in locale?
3) Come è la larghezza di banda complessiva? Come funziona un desktop remoto? Che ne dici di modificare un file su una condivisione di rete?

fonte

2010-02-25 12:46:19 CPerkins

1) Sì 2) Sì 3) Fine. FTP e desktop remoto sono tutti fantastici. Posso solo immaginare il debugger IDE è stupido e chiede alla VM tutti i tipi di domande folli in maniera poco intelligente - vale a dire uno che non prende in considerazione che ogni chiamata può richiedere> 500ms. –

Da molto leggero sperimentazione di una bella grande progetto (quasi 100 sottoprogetti, tempi di ping ~ 200-300ms), Netbeans sembra stia facendo bene in confronto con Eclipse.

È possibile intervenire e sono necessari alcuni secondi per l'aggiornamento e il collegamento in < 1 min.

È ovviamente fastidioso non essere in grado di utilizzare Eclipse, ma è una GUI e in questo modo è migliore del semplice JDB.

fonte

2016-02-15 13:50:12 Anjo

Debug Java remoto in cross-continente

risposta

Problemi correlati