Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

//

Timeout ist nicht gleich Timeout

25.1.2010 | 1 Minuten Lesezeit

Letzte Woche mussten ich einen Webservice-Client erweitern, sodass er die Verarbeitung abbricht, wenn die Gegenseite nicht schnell genug ein Ergebnis liefert. Das Ganze ist mit spring-webservices implementiert und verwendet die WebServiceTemplate Klasse. Ein Blick in die Dokumentation sollte hier weiterhelfen. Einen direkten Hinweis darauf, wie ein Timeout konfiguriert wird, habe ich nicht gefunden. Allerdings beschreibt die Dokumentation unter „6.2.1.1. URIs and Transports “ die beiden Klassen HttpUrlConnectionMessageSender und CommonsHttpMessageSender, die für den Datentransport mittels HTTP zuständig sind. In meinem Fall wird CommonsHttpMessageSender eingesetzt. (Wenn nicht anders konfiguriert, verwendet spring-webservices HttpUrlConnectionMessageSender.)
Die Klasse CommonsHttpMessageSender hat die Eigenschaft „readTimeout“. Ich habe sie in der Konfiguration auf den gewünschten Wert gesetzt und das Ganze getestet. Die ersten Tests liefen ohne Probleme – der Client brach mit einer Exception ab, wenn die Verarbeitung zulange gedauert hat. War doch eigentlich ganz einfach… wenn da nicht ein Problem aufgetaucht wäre. Bei einem der weiteren Tests habe ich vergessen, den Server zu starten, auf dem der Webservice lief. Und was passiert? Der soeben konfigurierte Timeout zeigt keine Wirkung.
Ich kürze an dieser Stelle ab und komme gleich zum Punkt. Der HTTP-Client unterscheidet zwischen zwei unterschiedlichen Timeouts. Es handelt sich um http.connection.timeout und http.socket.timeout . Der erste Timeout beschreibt, wie lange der Client wartet, bis eine Verbindung mit der Gegenseite aufgebaut wird. Der zweite Timeout beschreibt, wie lange der Client auf das Ergebnis der Gegenseite wartet. Der
zweite Timeout (http.socket.timeout) zeigt also nur Wirkung, wenn bereits eine Verbindung mit der Gegenseite aufgebaut werden konnte. Wenn man nicht will, dass der Client den aktuellen Thread blockiert, sollte man beide Timeouts konfigurieren.

Die resultierende Konfiguration könnte also wie folgt aussehen:

1<bean id="messageFactory" class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory" />
2 
3<bean id="httpSender" class="org.springframework.ws.transport.http.CommonsHttpMessageSender">
4<property name="connectionTimeout" value="3000" />
5<property name="readTimeout" value="5000" />
6</bean>
7 
8<bean id="webServiceTemplate" class="org.springframework.ws.client.core.WebServiceTemplate">
9<constructor-arg ref="messageFactory" />
10<property name="messageSender" ref="httpSender" />
11</bean>

Beitrag teilen

Gefällt mir

0

//

Weitere Artikel in diesem Themenbereich

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.