Hi Alexis,
I suppose there is a miscommunication here. We have so many use-cases in our
heads. And this thread is becoming so long :).
I suppose you are talking about the use case when the
"HTTPConstants.REUSE_HTTP_CLIENT" property is *NOT* set to "true", so there
is no HttpClient reuse from one c
please read "So multiple invocations *will not* step on each other in the
default case."
sorry for the poor phrasing. Not enough caffeine yet.
Alexis
On Wed, Mar 25, 2009 at 9:16 AM, Alexis Midon wrote:
> No sure I'm getting what you're saying.
> By default Axis2 creates a new HttpClient insta
No sure I'm getting what you're saying.
By default Axis2 creates a new HttpClient instance and a new
HttpConnectionManager instance on every invocations. So multiple invocations
should have step on each other in the default case. That's why I said
MultiThreadedHttpConnectionManager seems overkill t
Hi everybody,
I am not sure that the default ConnectionManager should be changed from
MultiThreadedHttpConnectionManager to SimpleHttpConnectionManager. What
about asynchronous MEPs? I have not tested this, but I suppose that if a
given async client does several invocations then if *NO*
MultiThread
+1 on this. I'm fine with the current behavior regarding HttpClient
management.
My only request would be to not instanciate a
MultiThreadedHttpConnectionManager in the default case. A
SimpleHttpConnectionManager would be good enough. I agree it's close to be a
detail but still.
Alexis
On Mon, Ma
On Tue, Mar 24, 2009 at 4:16 AM, Alexis Midon wrote:
>
> It's already possible to reuse the HttpClient and with your own
> HttpConnectionManager. What you have to do is create the HttpClient by
> yourself with your connection manager and push it in the MessageContext.
I think this is a good poi
I just want to point out that whatever is put in a thread-local should not
be the default behavior. In my case for instance the HttpState cannot be
reused randomly. An HttpState instance might contain credentials that I
don't want to share from one invocation to another. (meaning that each
invocati
It's already possible to reuse the HttpClient and with your own
HttpConnectionManager. What you have to do is create the HttpClient by
yourself with your connection manager and push it in the MessageContext.
Alexis
On Sun, Mar 22, 2009 at 3:52 AM, Amila Suriarachchi <
amilasuriarach...@gmail.com
Hi Amila,
"I think then it is better to keep the httpClient in a local thread
variable rather than in the axis2Configuration."
This will cause some problems with clients who make bunch of calls, but in
different threads. For example a customer may want to reuse the http
connection in his product
hi Dobri,
Thank you very much for your response.
On Mon, Mar 23, 2009 at 2:50 PM, Dobri Kitipov wrote:
> Hi Amila,
> I want to share some knowledge about this since these days I am doing some
> tests with HttpClient reuse.
> What I want to achieve is to reuse HttpClient among different threads
Hi Amila,
I want to share some knowledge about this since these days I am doing some
tests with HttpClient reuse.
What I want to achieve is to reuse HttpClient among different threads which
in turn could invoke different web services (WSs) deployed at different
hosts.
In fact I think I achieved th
hi all,
recently I came across this link and according to this[1] creating new http
client for every request is not good
in performance wise.
Current get Http client method looks like this
protected HttpClient getHttpClient(MessageContext msgContext) {
HttpClient httpClient;
Obje
I agree that we also need to consider OperationClient and the
non-blocking methods. I think that the first step towards a solid
solution is actually to write a couple of test cases that provide
evidence for these issues and that we can later use for regression
testing, but I will have to review the
Another case where "Options#setCallTransportCleanup for OperationClient" is
obvious is when you call OperationClient#execute in a non-blocking way.
The caller cannot clean up the transport safely, because the execution might
still be in progress. In that case it's OperationClient responsability to
There is still some inconsistencies between how ServiceClient#sendReceive
and Operation#execute use Options#getCallTransportCleanup.
And I think that would help a lot if the related jira issues get cleaned up
a little bit.
Thanks for your time and feedback.
Alexis
On Sun, Mar 1, 2009 at 9:02 P
hi all,
On Fri, Feb 27, 2009 at 6:35 PM, Andreas Veithen
wrote:
> I think that callTransportCleanup should never be turned on by default
> because it would disable deferred parsing of the response. What needs
> to be done urgently is to improve the documentation of the
> ServiceClient class to ma
Hi Andreas,
thanks a lot for your feedback.
I concur with Dobri that options#setCallTransportCleanup solved the problem
when ServiceClient#sendReceive initiates the webservice call. But the issue
remains if you use operationClient#execute. If you go down this code path,
the transport will never ha
I added some Javadoc explaining the role of cleanupTransport (see
revision 748730).
Andreas
On Fri, Feb 27, 2009 at 14:05, Andreas Veithen
wrote:
> I think that callTransportCleanup should never be turned on by default
> because it would disable deferred parsing of the response. What needs
> to
I think that callTransportCleanup should never be turned on by default
because it would disable deferred parsing of the response. What needs
to be done urgently is to improve the documentation of the
ServiceClient class to make it clear that it is mandatory to either
call cleanupTransport explicitl
Hi Andreas,
thank you for the comment. I think you get the question.
Quick test shows that setting the following line of code into the client:
options.setCallTransportCleanup(true);
forces the closure of the http connection. It seems it is not the default
behavior. This is a good and fast solutio
If I understand correctly, Dobri's findings can be summarized as follows:
1. Once the InputStream is consumed, commons-httpclient automatically
releases the connection.
2. SOAPBuilder never completely consumes the InputStream.
The SOAPBuilder behavior is indeed somewhat questionable, but it is
imp
Hi all,
I have observed absolutely the same thing these days. I need some more time
to analyze the whole picture, but here is my current synthesis of the issue.
It seems that http connection release is tightly coupled with the Axis2
builder used to handle and process the response body and the cor
no taker for an easy patch?
Alexis
On Wed, Feb 25, 2009 at 6:45 PM, Alexis Midon wrote:
>
> Hi everyone,
>
> All the issues relatives to AXIS2-935 are really messy, some of them are
> closed but their clones are not. Some are flagged as fixed but are obviously
> not. All these issues are reall
23 matches
Mail list logo
