Recently, xfire is used to develop a large number of WebService services, but it has always encountered a tough problem:
10:43:44 org. Apache. commons. httpclient. httpmethodbase writerequest
Information: 100 (CONTINUE) read timeout. resume sending the request
10:43:45 org. Apache. commons. httpclient. httpmethodbase readresponse
Information: discarding unexpected response: HTTP/1.1 100 continue
10:43:45 org. Apache. commons. httpclient. httpmethodbase readresponse
Information: discarding unexpected response: HTTP/1.1 100 continue
10:43:48 org. Apache. commons. httpclient. httpmethodbase writerequest
Information: 100 (CONTINUE) read timeout. resume sending the request
10:43:48 org. Apache. commons. httpclient. httpmethodbase readresponse
Information: discarding unexpected response: HTTP/1.1 100 continue
10:43:48 org. Apache. commons. httpclient. httpmethodbase readresponse
Information: discarding unexpected response: HTTP/1.1 100 continue
Although, by viewingSource code We can see that this is only an info-level warning. However, frequent throws of such logs are still unpleasant. Passing these logs will also affect the efficiency.
I thought it was a server efficiency problem, but the problem still exists in the case of a very simple service without a large number of concurrency. I thought it was a network problem, that is, deployment.
Local, self-tuning, there is still this problem. In reality, the default xfire mechanism is used to constantly shake hands with the server.
Call the following Code To solve the problem.
Httpclientparams Params = new httpclientparams ();
// Avoid 'Expect CT: 100-contine' handshake
Params. setparameter (httpclientparams. use_expect_continue, Boolean. False );
// Sets the WS connection timeout.
Params. setparameter (httpclientparams. connection_manager_timeout, 100 );
Client. setproperty (commonshttpmessagesender. http_client_params, Params );
Source: http://guojie.blog.51cto.com/59049/86992
Note: In xfire1.2.6, apusic as 6.0, and jdk1.6 environments,
Params. setparameter (httpclientparams. connection_manager_timeout, 100 );
The second parameter "100" in must be changed to "100l", that is, the integer must be changed to a long integer. Otherwise, "Java. lang. integer cannot be cast to Java. lang. long "exception