Dims,
what do you mean?
Maybe there has been a misunderstanding, I'll try to restate the issue.
You suggested me to cache the operation context, then to get the
message context and thus clean up the resources, right?
When should I call
messageContext.getTransportOut().getSender().cleanup(messageContext);
?,
just after sending the request, i.e.
sender.invokeNonBlocking(request, callback);
// get the msg. context and cleanup, as mentioned above
or
sender.invokeNonBloking(request, callback);
and in callback.onComplete/onError free the resources?
I've tried the second way (i.e. the resources are freed only when the
response is received), without success.
The first way, if NIO sockets are used (but I think it's not the case
of Axis2, at least a present) has the potential problem of closing
the connection before the message is effectively sent (because of the
asynchronous communication). Does it make sense?
I'll try the first method as well, but I guess I won't solve the
problem because after just a few minutes netstat shows a huge number
of connections in CLOSE_WAIT (about 1000).
Michele
On 4 May 2007, at 21:10, Davanum Srinivas wrote:
Do you have a stripped down test?
thanks,
dims
On 5/4/07, Michele Mazzucco <[EMAIL PROTECTED]> wrote:
I've tried it (see my previous post), but with no success :(.
BTW, since I'm using asynchronous invocations (with a separate
channel for responses) I guess the connection should be closes
immediately after sending the request, not after receiving the
response. Am I right?
Michele
On 4 May 2007, at 20:41, Davanum Srinivas wrote:
> Resending email...somehow this did not make it to the list. Can you
> please try this?
>
> -- dims
>
> ---------- Forwarded message ----------
> From: Davanum Srinivas <[EMAIL PROTECTED]>
> Date: May 4, 2007 11:25 AM
> Subject: Re: AbstractHTTPSender not releasing connection
> To: [email protected]
>
>
> Ok then try this tactic. Can you get hold of the
OperationContext for
> each invocation? Typically you can use
> myServiceContext.getLastOperationContext() to get the last
> OperationContext. You will have to start caching them though by
> calling myServiceClient.setCachingOperationContext(true) or you can
> create the OperationContext by calling
> myServiceContext.createOperationContext as well. Either way
after the
> invocation is done you can call the following snippet to cleanup
the
> HttpMethod.
>
> myOperationContext.getMessageContext
> (WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
> _messageContext.getTransportOut().getSender().cleanup
> (_messageContext);
>
> thanks,
> dims
>
> On 5/4/07, Michele Mazzucco <[EMAIL PROTECTED]> wrote:
>> Dims,
>>
>> what do you mean by "calling the complete method"?. In this
>> scenario I'm
>> using simple ServiceClient(s) sharing the same conf. context and
>> attached to custom callbacks (I'm reusing the same
ServiceClients for
>> thousands of asynchronous requests).
>> For my knowledge (see the link below) the cleanup (on the
>> ServiceClient)
>> should be called only at the end which, as I said, is after
receiving
>> thousands of responses.
>> Are you then suggesting me to share an OperationClient for all my
>> requests and to free resources as soon as I receive the response?
>>
>> Thanks,
>> Michele
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
