HTTP Apache-HttpClient/UNAVAILABLE (java 1.4)

[DefconDev]

Hallo zusammen,

bitte verschieben, sollte der Thread im falschen Sub-Forum erstellt worden sein. Auf unserem Server habe ich in einem Log in /var/log/httpd/ folgenden Eintrag ziemlich oft gefunden

HTTP/1.1" 200 64 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)

Dieser Fehler wird generiert von unseren Clients die ein Android Device verwenden, mit einer App die nicht wirklich aktuell ist.
In der Build.Gradle ist folgende Lib gesetzt: org.apache.http.legacy
Unser Servic(REST) der die Anfragen annimmt, verwendet folgende Version: 'org.apache.httpcomponents:httpclient:4.5.2'. Der Service läuft auf einem alten Tomcat 6.0.x.
Wir sind gerade auf Fehlersuche, weil ca. 10-20% unserer Client-Anfragen, welche zufällig sind, sporadisch nicht von unserem Server verarbeitet werden.

1. Also das was mich irritiert, die Handys/Clients laufen nicht immer in diesen Fehler, sondern erhalten mit etwas Geduld auch alles. Also GET/POST kommen meist auch an. Aber wie beschrieben, wissen wir von Anwendern, dass das meist Zeit kostet für ein paar Clients. Statt im Minutentakt, dauert das Stunden.
2. Die Fehlermeldung, wenn das überhaupt die ist, wonach ich suche, irritiert. Eigentlich wird ein 200 gepostet, was für mich bedeutet, die Anfrage ist angekommen und verarbeitet worden aber das UNAVAILABLE macht mich stutzig.
3. Unsere bisherige Fehlersuche, vermutet unseren Tomcat Server, der permanent mit 114 Threads auf WAITING steht(server.xml), und der maxThread ist auf 200 gesetzt für einen spezifischen Port. Ein ps -o nlwp "PID_desTomcats" liefert ca. 178 Threads, wobei 114 wie gesagt auf WAITING stehen. Neustart des Tomcats hat auch nicht geholfen.

Kann sich jemand generell einen Reim machen auf diesen Fehler? Auf Stackoverflow wurde ich auch nicht schlauer.

Vielen Dank im Voraus.

 

[Robert Zenz]

Dieser Fehler wird generiert von unseren Clients die ein Android Device verwenden, mit einer App die nicht wirklich aktuell ist.

Ist das wirklich ein Fehler, ich meine, ist das Log nicht so strukturiert?

      HTTP
        |  Antwort Status
        |      |                 UserAgent
        |      |                     |
    HTTP/1.1" 200 64 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)

 

[thecain]

Ist das wirklich ein Fehler, ich meine, ist das Log nicht so strukturiert?

      HTTP
        |  Antwort Status
        |      |                 UserAgent
        |      |                     |
    HTTP/1.1" 200 64 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)

Korrekt, das UNAVAILABLE ist vom UserAgent https://stackoverflow.com/questions...ent-as-apache-httpclient-unavailable-java-1-4

 

[DefconDev]

Aber was bedeutet das genau mit dem Agent?

 

[Robert Zenz]

Aber was bedeutet das genau mit dem Agent?

Das der Client irgendwelchen Schwachsinn als UserAgent setzt.

Wir sind gerade auf Fehlersuche, weil ca. 10-20% unserer Client-Anfragen, welche zufällig sind, sporadisch nicht von unserem Server verarbeitet werden.

Verbindungsprobleme? Kommen die ueberhaupt am Server an?

 

[DefconDev]

Das der Client irgendwelchen Schwachsinn als UserAgent setzt.


Verbindungsprobleme? Kommen die ueberhaupt am Server an?

Ok, schade. Dachte das wäre endlich ein Hinweis.

Ich kann es dir nicht sagen. In unseren Logs lässt sich Serverseitig nichts finden. Lediglich auf der Client-Seite finden wir etliche Requests Refused Exceptions. Aber warum die Refused werden , ich habe keine Ahnung.

 

[Robert Zenz]

Requests Refused

Genauer bitte, was genau bekommt ihr da?

 

[Jw456]

Tipp schaue mal hier

org.apache.http.legacy doesn't work on API 28

To begin with, I was using org.apache.http functions for a while now and error came when I tried to launch my app on API 28. It's working on API 26 and API 23, but suddenly something is wrong with ...

stackoverflow.com

 

[DefconDev]

Genauer bitte, was genau bekommt ihr da?

org.apache.http.conn.HttpHostConnectException: Connection to http://unserServerort refused
     at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:193)
     at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:170)
     at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:124)
     at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:366)
     at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:569)
     at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:494)
     at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:472)
     at de.x.mobile.connection.AbstractNetworker.performGet(AbstractNetworker.java:75)
     at de.x.mobile.connection.Networker.loadSingle(Networker.java:266)
     at de.x.mobile.connection.Networker.loadServerTime(Networker.java:385)
     at de.x.mobile.connection.Module.downloadServerTime(Module.java:647)
     at de.x.mobile.connection.Module.access$000(Module.java:95)
     at de.x.mobile.connection.Module$DownloadSchedule.run(Module.java:148)
     at android.os.Handler.handleCallback(Handler.java:873)
     at android.os.Handler.dispatchMessage(Handler.java:99)
     at android.os.Looper.loop(Looper.java:193)
     at android.os.HandlerThread.run(HandlerThread.java:65)
 Caused by: java.net.ConnectException: failed to connect to /x.x.x.x (port x) from /:: (port x): connect failed: ETIMEDOUT (Connection timed out)

 

[DefconDev]

Tipp schaue mal hier

org.apache.http.legacy doesn't work on API 28

To begin with, I was using org.apache.http functions for a while now and error came when I tried to launch my app on API 28. It's working on API 26 and API 23, but suddenly something is wrong with ...

stackoverflow.com

Die App läuft auf der API 23 . Wie gesagt , die App läuft und auch die Verbindung steht auch, nur halt nicht immer

 

[Jw456]

Die App ist also für Target API 23 Kompiliert und läuft auch auf einem API 23 Gerät (Android 6)

 

[DefconDev]

Die App ist also für Target API 23 Kompiliert und läuft auch auf einem API 23 Gerät (Android 6)

Ich kann es dir aus dem Kopf nicht 100% sagen aber ich glaube minapilevel ist 21 und target 23. Die App läuft auf Android 6/7 oder Android 9.

 

[DefconDev]

compileSdkVersion 28
targetSdkVersion 22
minSdkVersion 21

 

[Jw456]

targetSdkVersion 22
Würde ich nicht machen.

Du willst somit die Permission sparen vom User.
Nicht gut.

Ich würde da auch 28 benutzen.
Und im Code auf Änderungen zu vor Versionen eingehen.

 

[DefconDev]

targetSdkVersion 22
Würde ich nicht machen.

Du willst somit die Permission sparen vom User.
Nicht gut.

Ich würde da auch 28 benutzen.
Und im Code auf Änderungen zu vor Versionen eingehen.

Ja, da sind ne Menge Altlasten im Code. Aber die User sind mit unseren Handys unterwegs die nur einen Zweck haben. Es ist auch keine App für den Playstore.

Probiere jetzt die Sachen im Stackoverflow-Threas aus. Was mich wundert, dass es zum größten Teil funktioniert für gefühlt 80 % der Handys desselben Modell.

 

[DefconDev]

Also der Test mit den zusätzlichen XMLs für die legacy apache http lib hat auch nichts gebracht. Beim Testen auf unserer Live-Umgebung ist uns aufgefallen, dass die Verbindung mit schwachem 4G/3G problematisch ist, aber auf einem weniger ausgelasteten Server in unserer Testumgebung konnten die Rest-Call regelmäßig abgesetzt werden, fast unabhängig davon ob 4G oder 3G.

Wir tappen weiter im Dunkeln. Beim Debuggen fühlt es sich so an, als würde die Verbindung nicht gehalten werden können, wenn sie zu schwach ist. Aber da fehlt mir persönlich das KnowHow, welche Faktoren da eine Rolle spielen können. Vielleicht sind die Settings fürs OS beim TCP Protokoll komplett anders auf Live als auf Stage, das kann man noch prüfen aber welche Settings außer der Tomcat Server könnten da einen Einfluss nehmen?

 

[LimDul]

Firewalls? Die war zumindest bei uns für gedroppte Verbindungen mal verantwortlich.

Worst Case wäre, dass man auf TCP/IP Ebene wirklich die Pakete protokolliert und dann schaut, wo sie verloren gehen. Wenn man das nur gegen die Live Umgebung nachstellen kann, wird das natürlich aufwendig. Insbesondere, da man auf dem Client (Handy) vermutlich schwer die ausgehenden Pakete filtern kann.

Da es laut Log ein Timeout ist und du zusätzlich schon es etwas auf schwache Verbindungen eingrenzen kannst, mal ein Traceroute zum live server vom Handy absetzen und schauen ob der anders läuft als bei der Testumgebung. Evtl. geht irgendwo unterwegs was verloren.

 

[DefconDev]

Firewall lassen wir schon bereits prüfen. Betrifft auch nur zwei Ports.

Also ein Timeout ist laut Client Log nicht, sondern ein Refused. Aber beim Debuggen fühlt es sich halt an, wie bereits geschrieben, als wäre die Verbindung nicht stabil genug und der Server deswegen die Verbindung zum Client wieder zurückweist. Aber reines Bauchgefühl was nicht wirklich weiter hilft.

Das mit dem Pakete protokollieren, werde ich unserem Admin Mal fragen. Danke.

 

[mrBrown]

Also ein Timeout ist laut Client Log nicht, sondern ein Refused.

Die Ursache ist ein Timeout:

Caused by: java.net.ConnectException: failed to connect to /x.x.x.x (port x) from /:: (port x): connect failed: ETIMEDOUT (Connection timed out)