[
https://issues.apache.org/jira/browse/AXIS2-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Kamyshnikov closed AXIS2-5100.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.6.0
It appears this is not an issue at least since 1.6.0.
AbstractHTTPSender.getHttpClient in 1.6.0 does not call initializeTimeouts for
cached HttpClient
> AbstractHTTPSender.initializeTimeouts changes timeouts for shared HttpClient
> which is not thread safe
> -----------------------------------------------------------------------------------------------------
>
> Key: AXIS2-5100
> URL: https://issues.apache.org/jira/browse/AXIS2-5100
> Project: Axis2
> Issue Type: Bug
> Components: transports
> Reporter: Igor Kamyshnikov
> Priority: Minor
> Fix For: 1.6.0
>
>
> I have tried to set default timeouts for shared HttpClient in shared
> ConfigurationContext but it appears it is not possible to make it work
> because each call of AxisEngine.send(msgContext) (e.g. from
> OutInAxisOperation) overrides timeouts of HttpClient from MessageContext
> (where this timeout might not be even defined causing to use default 30
> seconds timeout).
> More over it appears it a threading issue because HttpClient could be shared
> by a number of threads. That's why I don't understand why configuration of
> HttpClient is changed by each call of AxisEngine.send.
> This makes me not to use shared ConfigurationContext with shared HttpClient
> with MultithreadedHttpConnectionManager. It is required to create
> ConfigurationContext (and HttpClient, and HttpConnectionManager) for each
> stub instance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
