TV-Browser-Forum

[quote="ds10"]Ja, aber ich hab's ursprünglich nicht programmiert, also bin ich dafür die falsche Adresse. ;-)
Und da es jetzt laufen sollte, kann ich mir die jetzt auch sparen. :mrgreen:[/quote]
genau das hat sich der ursprüngliche schreiber aber auch gedacht - mit den bekannten folgen :P

Ja, aber ich hab's ursprünglich nicht programmiert, also bin ich dafür die falsche Adresse. ;-)
Und da es jetzt laufen sollte, kann ich mir die jetzt auch sparen. :mrgreen:

(Meistens sind die auch gar nicht nötig, weil so klar ist was passiert, besonders wenn die Variablen und Methoden sprechende Namen haben.)

code-kommentare ftw! :D

Wenn man einmal verstanden hat, warum der Test so programmiert war, wie er es war, dann ist auch klar warum. Es darf in einem Thread immer nur eine URL getestet werden, weil eben die Rückgabe blockieren kann, da kann erst nach 10 Minuten eine Antwort kommen, deshalb in einem eigenen Thread, so dass die Prüfung einer URL nach dem Timeout abgebrochen werden kann.

hab oben noch was parallel rein-editiert. wie auch immer, nachdem das problem identifiziert ist, habe ich ja volles vertrauen, dass du nen fix dafür hinbekommst ;).

Ich habe es jetzt wieder geändert, die Konstruktion hatte vorher schon ihren Sinn. Nur das Zurücksetzen von mResult war das Problem, da dadurch ein Thread einem anderen das Ergebnis verändern konnte. Wenn mResult einmal true ist, muss es das auch bleiben, dann funktioniert der Test.

nicht ausschließlich. der fehlende https-proxy wäre ja kein problem gewesen und gar nicht aufgefallen, wenn der verbindungstest richtig funktioniert hätte ;).

[edit] vom ablauf her würd ich das halt irgendwie anders machen. wenn die urls sowieso nicht parallel, sondern seriell geprüft werden, würd ich die for-schleife, die über besagte urls iteriert auch in den thread packen. dann wird auch gleich viel klarer, dass der thread beendet ist, wenn alle urls geprüft wurden (oder auf eine verbunden werden konnte) und danach weitergearbeitet wird.

Ich bin mir aber nicht sicher, ob das jetzt nicht dem Zweck zuwider läuft. Wenn jetzt duckduckgo blockiert, also erst nach Ende des Timeouts zurückgibt, wird keine andere Seite mehr geprüft. Also so ganz richtig kann das so auch nicht sein.

EDIT: Dein Problem war wohl vor allem der fehlende Proxy-Port für https.

hab ein dutzend mal die daten aktualisiert - gab keine probleme. sieht so aus, als wär der bug geschichte.

Ich habe die Werte für https ergänzt und einfach mal schnell eine neue Nightly gebaut zum Testen:
[url]http://tvbrowser.org:8080/hudson/job/tvbrowser-3-unstable/lastSuccessfulBuild/artifact/tvbrowser/public/tvbrowser_3.4.0.50-SVN_2014-07-01_nightly_bin_transportable.zip[/url]

https.proxyPort muss ich in meinem test-prog auch setzen, sonst gibts die besagte exception. user kann ich nicht testen, mein proxy hier ist ohne anmeldung. aber es steht ja zu vermuten, dass der ebenfalls eingetragen werden muss für https.

    System.setProperty("http.proxyHost",     httpHost);
    System.setProperty("http.proxyPort",     httpPort);
    System.setProperty("http.proxyUser",     httpUser);
    System.setProperty("http.proxyPassword", httpPassword);
    System.setProperty("https.proxyHost",     httpHost);

TV-Browser setzt folgendes:
[code] System.setProperty("http.proxyHost", httpHost);
System.setProperty("http.proxyPort", httpPort);
System.setProperty("http.proxyUser", httpUser);
System.setProperty("http.proxyPassword", httpPassword);
System.setProperty("https.proxyHost", httpHost);[/code]

System.setProperty("http.proxyHost", xxx);
System.setProperty("http.proxyPort", xxx);
System.setProperty("https.proxyHost", xxx);
System.setProperty("https.proxyPort", xxx);

verwirrend. threading halt :D.

wie auch immer, ich habe noch ein wenig wegen der duckduckgo-exception geforscht. kann sein, dass die durch meinen code reingekommen ist. ich habe schlicht keinen proxy für https gesetzt gehabt:

[code]System.setProperty("http.proxyHost", xxx);
System.setProperty("http.proxyPort", xxx);
System.setProperty("https.proxyHost", xxx);
System.setProperty("https.proxyPort", xxx);[/code]

solltest du vielleicht trotzdem auch im tvb-code mal prüfen, ob der proxy für beides gesetzt wird.

[quote="uzi"]...die darauf wartet, dass alles threads fertig sind. ändert nichts an der tatsache, dass jeder der 4 threads sein ergebnis in die gleiche var schreibt und damit der letzte 'recht hat'. wenn der false sagt, ist der check komplett false.[/quote]
Nein, die nächste URL wird ja erst geprüft, wenn entweder die Warteschleife abgelaufen ist oder der Test für die URL beendet ist. Die Methode gibt ja mResult als Ergebnis zurück und nur wenn das falsch ist, wird die nächste URL geprüft. Wäre das nicht so, würde ich nicht nach duckduckgo schon ein OK bekommen haben.

Aber natürlich war das bisher schlecht programmiert, denn die URLs sollten eben alle in einem Thread geprüft werden, denn wenn die Warteschleife beendet ist, konnte das von dir beschriebene Verhalten auftreten.

[quote]Nein, so läuft das nicht ab. Die Methode checkConnection hat eine Warteschleife am Ende.[/quote]
...die darauf wartet, dass alles threads fertig sind. ändert nichts an der tatsache, dass jeder der 4 threads sein ergebnis in die gleiche var schreibt und damit der letzte 'recht hat'. wenn der false sagt, ist der check komplett false.

[quote]Wenn du einfach den Dialog entfernst, bekommst du natürlich völlig falsche Ergebnisse, da der essentiell ist für die Funktion des Checks.[/quote]
der dialog (sprich showDialog und auch hideDialog) greifen auf mResult gar nicht zu. die ändern daran also nichts.

[quote]Die Exceptions des Tests interessieren nicht, da es nur ein Test ist, da wird bewusst in Kauf genommen, dass es Fehler gibt, die müssen nichts ins Log geschrieben werden.[/quote]
die interessieren grundsätzlich schon. schon allein, weil man nicht in die zukunft gucken kann. ein log an- und abzuschalten bzw ein log-lvl zu ändern kann man jedem user zumuten. aber was in den sourcen nicht gelogt wird, kann man nicht auswerten. der tvb loggt imho grundsätzlich in jeder beziehung viel zu wenig, was die fehleranalyse schlicht unnötig kompliziert macht. ich hab nur 3, 4 zusätzliche log-ausschriften hinzugefügt und bin dem problem gleich deutlich näher gekommen.

[quote]Interessanter Punkt, aber kann die Antwort nicht auch vom Proxy oder vom Router kommen. Dann bekommt man eine Antwort, aber die sagt eben nicht aus, dass eine Internetverbindung besteht.[/quote]
hm. weiss ich nicht genau. eigentlich würde ich das nicht vermuten. aber wer weiss...