Donu al la pakaĵa solvilo de spark-shell ĝian prokurilon ĉe lanĉo

spark-shell --driver-java-options "-Dhttp.proxyHost=proxy.example -Dhttp.proxyPort=8080 -Dhttps.proxyHost=proxy.example -Dhttps.proxyPort=8080" --packages group:artifact:version

Ĉe klienta lanĉo de spark-shell tiuj JVM-opcioj de la stirilo alvenas antaŭ la solvo de dependaĵoj. Anstataŭigu la ilustran finpunkton kaj group:artifact:version per la celataj valoroj uzante opciojn subtenatajn de la instalita versio de Spark. La gastnomo kaj pordo de Java estas apartaj propraĵoj. Por permesitaj publikaj elŝutoj de dependaĵoj, la listo de HTTP-prokuriloj proponas kandidatojn por tiuj kampoj.

Uzu tiun lokigon kiam --packages malsukcesas antaŭ ol la ŝelo fariĝas disponebla. Aplikaĵa kodo enigita poste ne povas ripari la pli frue elŝuton. Spark distingas lanĉajn opciojn de programaj agordoj; en klienta reĝimo la JVM de la stirilo jam ekzistas kiam la aplikaĵa kodo ruliĝas.

Ankaŭ la disfanda reĝimo gravas por spark.driver.extraJavaOptions: la stirilo povas ruliĝi sur alia maŝino, kiu bezonas sian propran vojon al la prokurilo. Posta API-peto de plenumilo estas alia procezo kaj alia reta loko; agordi plenumilojn ne nepre agordas la lanĉan solvon.

Kiam lanĉaj opcioj ĉeestas sed la elŝuto malsukcesas

Sekvu la gastnomon de la deponejo, la petan tipon kaj la unuan eraron. Metadatumoj kaj artefaktoj povas veni de pluraj gastigantoj. Maven-kongrua deponeja URL ne pruvas, ke Spark legas la settings.xml uzatan de sukcesa Maven-komando.

La elŝutilo de Java devas subteni la prokurilan mekanismon kaj la postulatan aŭtentikigon. Gastnomo/pordaj propraĵoj ne provizas ĉiun skemon, kaj elpensita http.proxyUsername-propraĵo ne efikas nur ĉar Java akceptas la nomon. Tenu kune la antaŭlanĉan agordon kaj la konkretan malsukcesan elŝuton kiam vi diagnozas ĉi tiun stadion.