bug #9851
openProblems during search for updates when network delay is too big
0%
Description
Users from mexico does not get the correct informations about new updates, maybe this is because the response needs to long:
mail AM:
kannst du dich darum kümmern nachzuhaken, woran es liegt. Als erstes müssten wir wohl mal sehen, ob es für das nächste Release auch nicht klappt. Und ansonsten mal testen, wie empflich die Update Site Funktionalität auf Delays ist. Hast du so ein Delay Tool eigentlich installiert. Wäre auch gründsätzlich praktisch für die Entwicklung. Da sieht man am besten, wo die Performance wirklich hakt. Wie gesagt, das Editieren auf der Mexico DB war informativ diesbezüglich.
mail AK:
Solche "Delay Tools" können echte Netzwerklatenz nur unvollständig simulieren, besser wäre es entsprechende Logs des RCP Updaters zu auf den Clients zu erfassen und diese uns zur Verfügung zu stellen.
Zwei alternative Möglichkeiten:
Vielleicht lässt sich echte Latenz gut simulieren in dem man
a) das TOR Netzwerk verwendet?
b) einen VPN Service nutzt der in S-Amerika lokalisiert ist
mail AM:
ein VPN in Mexiko (S-Amerika finde ich da nicht so hilfreich) wäre sicherlich eine vielversprechende Idee. Vielleicht könnt ihr ja mal mit UNAM klären, ob die da eine Möglichkeit sehen.
Mit TOR kenne ich mich nicht genügend aus, ob das ausreichend gut „simuliert“.
„Delay Tools“ halte ich trotz gewisser Mängel trotzdem schon mal für einen wichtigen Schritt. Insbesondere weil man sie sehr einfach beim Testen von Funktionen mitlaufen lassen kann und das Ergebnis quasi spürt und nicht erst auswerten muss.
Mitloggen von RCP Updater (und allgemein httpInvoker aufrufen) mit möglichst Ausgabe in einem separaten View steht ja sowieso schon länger auf der Wunschliste. Das würde mir sehr oft helfen um zu verstehen, woran es liegen könnte, wenn der Editor mal wieder unresponsive ist.
Für das jetzige Problem wäre dieses Loggen sicherlich erste Wahl.
ich denke wir sollten hier weitermachen. Und sowohl die Delay-Tools als auch das VPN nach Mexiko mal testen.
Katja, könntest du dich darum kümmern und Andreas K., könntest du ggf. behilflich sein bezüglich Zugang zu den dortigen Rechnern etc.
Vielleicht sollten wir auch ein Ticket anlegen, in dem wir alles sammeln, falls das noch nicht existiert.
Related issues
Updated by Katja Luther over 1 year ago
- Status changed from New to In Progress
The checkForUpdates method shows "No updates available" only if operation.resolveModal(monitor) gives back Status.STATUS_NOTHING_TO_UPDATE
Updated by Andreas Kohlbecker over 1 year ago
another option to simulate the situation would be to establish a ssl SOCKS proxy to a server in mexico and to pipe all TaxEditor HTTP/HTTPS traffic through that proxy:
Updated by Andreas Müller over 1 year ago
Katja Luther wrote:
The checkForUpdates method shows "No updates available" only if operation.resolveModal(monitor) gives back Status.STATUS_NOTHING_TO_UPDATE
Can you leave a not in which classes these methods are provided?
Updated by Katja Luther over 1 year ago
Andreas Müller wrote:
Katja Luther wrote:
The checkForUpdates method shows "No updates available" only if operation.resolveModal(monitor) gives back Status.STATUS_NOTHING_TO_UPDATE
Can you leave a not in which classes these methods are provided?
eu.etaxonomy.taxeditor.handler.update.UpdateHandler.java
Updated by Katja Luther over 1 year ago
Whith no internet connection the message is the same "no updates available", but the log contains an exception.
ENTRY org.eclipse.equinox.p2.transport.ecf 2 0 2021-11-09 11:37:01.929
!MESSAGE Connection to https://cybertaxonomy.eu/download/taxeditor/update/nightly/p2.index failed on cybertaxonomy.eu. Retry attempt 0 started
!STACK 0
java.net.UnknownHostException: cybertaxonomy.eu
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$2.lookupAllHostAddr(Unknown Source)
at java.net.InetAddress.getAddressesFromNameService(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:44)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.resolveHostname(DefaultClientConnectionOperator.java:259)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:159)
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.performConnect(HttpClientRetrieveFileTransfer.java:1084)
at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.access$0(HttpClientRetrieveFileTransfer.java:1075)
at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer$1.performFileTransfer(HttpClientRetrieveFileTransfer.java:1071)
at org.eclipse.ecf.filetransfer.FileTransferJob.run(FileTransferJob.java:74)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Updated by Andreas Kohlbecker over 1 year ago
Andreas Kohlbecker wrote:
another option to simulate the situation would be to establish a ssl SOCKS proxy to a server in mexico and to pipe all TaxEditor HTTP/HTTPS traffic through that proxy:
another good source of information on setting up a SOCKS5 Proxy: https://rubysash.com/penetration-testing/security-tools/use-ssh-tunnel-as-socks-proxy-firefox/
Updated by Katja Luther over 1 year ago
Updated by Katja Luther over 1 year ago
Using socks proxy can defined by adding
proxyData/SOCKS/hasAuth=false
proxyData/SOCKS/host=127.0.0.1
proxyData/SOCKS/port=8090
in org.eclipse.core.net.prefs (see https://stackoverflow.com/questions/18147722/how-to-set-the-proxy-configuration-for-a-headless-eclipse-application-on-windows)
or in TaxonomicEditor.ini
Updated by Andreas Kohlbecker over 1 year ago
with the following settings in {eclipse-installation-folder}/configuration/.settings/org.eclipse.core.net.prefs
eclipse.preferences.version=1 org.eclipse.core.net.hasMigrated=true proxyData/SOCKS/hasAuth=false proxyData/SOCKS/host=localhost proxyData/SOCKS/port=8090 systemProxiesEnabled=false
eclipse and the TaxEditor are using the configured SOCKS proxy
Updated by Andreas Kohlbecker over 1 year ago
NOTE: "Nur die Connect Versuche zum cdm-server gehen über den Proxy, die Update-Request gehen einen anderen Weg."
Updated by Katja Luther over 1 year ago
Found a possibility to increase the timeout for equinox:
https://wiki.eclipse.org/Equinox/p2/TransportDebugging
and https://bugs.eclipse.org/bugs/show_bug.cgi?id=395696
(this is from 2013 but maybe it helps to solve our problems)
Asked Martin Ricker to add parameters in TaxonomicEditor.ini to increase timeout and retries.
Updated by Andreas Müller about 1 year ago
- Related to bug #5967: Adapt default update site to production update site. added