Project

General

Profile

Actions

bug #9851

open

Problems during search for updates when network delay is too big

Added by Katja Luther over 2 years ago. Updated over 2 years ago.

Status:
In Progress
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Severity:
normal
Found in Version:
Tags:

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

Related to EDIT - bug #5967: Adapt default update site to production update site.ClosedAndreas Müller

Actions
Actions #1

Updated by Katja Luther over 2 years 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

Actions #2

Updated by Andreas Kohlbecker over 2 years ago

  • Tags set to mexico
Actions #3

Updated by Andreas Kohlbecker over 2 years 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:

Actions #4

Updated by Andreas Müller over 2 years 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?

Actions #5

Updated by Katja Luther over 2 years 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

Actions #6

Updated by Katja Luther over 2 years 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)

Actions #7

Updated by Andreas Kohlbecker over 2 years 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/

Actions #9

Updated by Katja Luther over 2 years 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

Actions #10

Updated by Andreas Kohlbecker over 2 years 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

Actions #11

Updated by Andreas Kohlbecker over 2 years ago

NOTE: "Nur die Connect Versuche zum cdm-server gehen über den Proxy, die Update-Request gehen einen anderen Weg."

Actions #12

Updated by Katja Luther over 2 years 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.

Actions #13

Updated by Andreas Müller about 2 years ago

  • Related to bug #5967: Adapt default update site to production update site. added
Actions

Also available in: Atom PDF