Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable proxy for HttpClient #12

Merged
merged 1 commit into from
May 27, 2020

Conversation

jsteltze
Copy link

Den HttpClient ermöglichen einen Proxy zu nutzen, wenn das Programm in einem geschützten Netzwerk ausgeführt wird. Der Proxy wird aus den Java-Parametern ausgelesen (-DhttpsProxyHost=... -DhttpsProxyPort=...)

@FriedrichFroebel
Copy link
Owner

FriedrichFroebel commented May 27, 2020

Danke für den Fix - sieht erst einmal sinnvoll aus, auch wenn ich es nicht getestet habe. Den fehlerhaften Travis-Build schaue ich mir dann noch an, das hat zunächst nichts mit diesem PR zu tun.

@FriedrichFroebel FriedrichFroebel merged commit 3f17999 into FriedrichFroebel:master May 27, 2020
@jsteltze
Copy link
Author

jsteltze commented May 28, 2020 via email

@FriedrichFroebel
Copy link
Owner

Zu den Ideen:

  • Für das Aussehen habe ich einen Issue erstellt. Ich selbst habe keine Probleme mit dem Standard-Java-Stil, da ich eh verschiedene Betriebssysteme verwende, aber es schadet auch nicht, das zu ändern.

  • Soweit ich das überblicke, sind mehrere Kandidaten möglich (wenn auch in den meisten Fällen eher unwahrscheinlich).

  • Die Massenübertragung wurde bereits im Opencaching-Forum diskutiert und wird es höchstwahrscheinlich nicht geben. Dem Benutzer soll bewusst sein, welche Caches er gerade loggt und dabei auch sicherstellen, dass es wirklich das richtige Doppellisting ist - eine automatisierte Übertragung kann dies nicht sicherstellen. Zudem sollte jenes Vorgehen die allgemeine Last auf die OKAPI besser verteilen.

  • Die beiden letzten Punkte habe ich als Issues angelegt.

Für die Umsetzung gerne entsprechende Pull Requests erstellen.

@jsteltze
Copy link
Author

jsteltze commented Jan 4, 2021 via email

@FriedrichFroebel
Copy link
Owner

FriedrichFroebel commented Jan 4, 2021

Die "Spielerei" mit der Java Heap-Size würde ich entfernen ( ForkUtil.forkWithResizedHeapAndExit(arguments); )

Ich glaube das verursacht manchmal Probleme (Anwendung friert ein) und aus meiner Sicht gibt es auf modernen Rechnern keinen Grund für so eine Mini-Anwendung an der Java-Heapsize rum zu spielen.

Ich habe, wenn nicht unbedingt notwendig, keine größeren Umstellungen des Altcodes des Original-Upstreams von Samsung1 vorgenommen - abgesehen von Codestyle und Modulstruktur. Ob das wirklich Grund für die Freezes ist, kann ich nicht beurteilen - genauso wenig, inwieweit das in der Realität tatsächlich verwendet wird.

Dann habe ich für meine aktuelle GC-Cache-Liste mal wieder eine Synchronisation durchgeführt.

Es gibt ein paar komische Effekte (s. Screenshot). Er findet unplausible Kandidaten und auf der anderen Seite findet er plausible Kandidaten NICHT :-/

Oder vielleicht ist einfach die Zuordnung durcheinander geraten, denn in Summe sind alle Kandiaten vorhanden...

GitHub mag E-Mail-Bilder leider nicht, sodass das Bild fehlt. Es ist durchaus bekannt, dass plausible Kandidaten bei zu starker Abweichung der Daten weggefiltert werden. Ich habe schon ein paar kleinere Anpassungen vorgenommen, aber es wird immer Fehler geben - sowohl auf Benutzerseite als auch durch die verwendeten allgemeinen Heuristiken. Permutationen der Zuordnung sind mir nicht bekannt - und falls es an dem ist, dürfte das auf jeden Fall ein Bug sein.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants