Project: talendesb
Issue TESB-4414: Timeout exception in requests to dataservice under small load.
Our load tests shown that even under small load dataservice not able to work smoothly (in comparation to usual cxf provider). From time to time client get next exception: javax.xml.ws.WebServiceException: Could not send Message. ... Caused by: java.net.SocketTimeoutException: SocketTimeoutException invoking http://provider:8040/services/LoadProvider: Read timed out ... Caused by: java.net.SocketTimeoutException: Read timed out All calls were lost on provider's side -- log of provider contains the same amount of log entries about receiving message as amount of messages sent from consumer. Increasing of http timeout up to 10 minutes shown similar picture, so, it means that messages were lost completely. Description of environment used for load tests: 1) Dataservice is generated from wsdl by talend studio. Job contains 5 components - tESBRequest, tXMLMap, tJavaRow, tXMLMap, tESBResponse (see imported items from studio in attachments) 2) Talend runtime is used as osgi container for dataservice 3) To compare results of dataservice we used usual cxf provider generated from the same wsdl by cxf-codegen-plugin. To serve requests cxf provider is started under the same container (using spring) as dataservice. 4) Client is usual cxf client being running by jmeter (which collects all statistics and controls execution flow) 5) wsdl contains service with one method with two parameters -- String clientId, int delay (should be specified in seconds). 6) Both cxf provider and dataservice use Thread.currenThread().sleep(delay * 1000) to emulate work of "real provider". Dataservice implements this logic in tJavaRow component. Scenarios. There are several combination of types of scenarios are executed: 1) single consumer\multi consumer 2) without delay \ with 1 sec delay Mentioned problem appeared when dataservice was used in scenarios 1) single consumer (1 thread), no delay 2) 2 consumers (1 or more threads per every consumer), no delay 4) 2 consumers (4 or more threads per every consumer), delay 1 sec. In comparation to that cxf provider had no timeouts in every executed scenario.
Story points: 3