>>
>> I looked and the code segment you mentioned, but that is to process long
>> running services. We had somewhat similar code to process request comes with
>> replyTo header. If no one has removed then, we can fix the issue in AMR.
>
> This is for processing addressing headers with replyTo header.
I agree, but that is inside isAsync, so we need to have the parameter
to come to this logic.
Thanks,
Deepal
>
> if ((!WSDLUtil.
>
> isOutputPresentForMEP(mep))
> || (replyTo != null && !replyTo.hasAnonymousAddress()))
> {
> AsyncMessageReceiverWorker worker = new
> AsyncMessageReceiverWorker(
> messageCtx);
> messageCtx.getEnvelope().build();
>
> messageCtx.getConfigurationContext().getThreadPool().execute(
> worker);
> return;
> }
>
> Can you please show the code you talk about in a previous release code any
> revision?
>
> thanks,
> Amila.
>
>>
>> Thanks,
>> Deepal
>>
>> Do you mean this code
>>
>> if (messageCtx.isPropertyTrue(DO_ASYNC)
>> || ((messageCtx.getParameter(DO_ASYNC) != null) &&
>>
>> JavaUtils.isTrueExplicitly(messageCtx.getParameter(DO_ASYNC).getValue()))) {
>>
>> String mep = messageCtx.getAxisOperation()
>> .getMessageExchangePattern();
>> EndpointReference replyTo = messageCtx.getReplyTo();
>> // In order to invoke the service in the ASYNC mode, the
>> request
>> // should contain ReplyTo header if the MEP of the service is
>> not
>> // InOnly type
>> if ((!WSDLUtil.isOutputPresentForMEP(mep))
>> || (replyTo != null &&
>> !replyTo.hasAnonymousAddress())) {
>> AsyncMessageReceiverWorker worker = new
>> AsyncMessageReceiverWorker(
>> messageCtx);
>> messageCtx.getEnvelope().build();
>>
>> messageCtx.getConfigurationContext().getThreadPool().execute(
>> worker);
>> return;
>> }
>> }
>>
>> It is there in the trunk.
>>
>> you need to use the public static final String DO_ASYNC =
>> "messageReceiver.invokeOnSeparateThread"; at the server side.
>>
>> thanks,
>> Amila.
>>
>> On Thu, Aug 4, 2011 at 6:13 AM, Deepal jayasinghe <deep...@gmail.com>
>> wrote:
>>>
>>> Guys,
>>> A user called "Todd" recently observed [1] that we have issues with
>>> non-blocking invocation with two channels. I went and tested it and I was
>>> able to re-create the issue. While debugging the code I realized that
>>> something has gone wrong. IIRC for the server side we had a check for
>>> replyTo header and if the replyTo is not Anonymous then we send the ACK
>>> through the back channel. And once the invocation is complete we send the
>>> reply through the replyTo address. However, while debugging the code I
>>> realized that someone has removed those code, so now the logic does not
>>> work.
>>>
>>> Since I went through the code after long time and not fully updated with
>>> the source code, I could not able to find the exact location of the code.
>>> So, if anyone of you have removed the code please let us know, then we can
>>> fix it correctly. Else I have to fix it on the AbstractMessageReceiver.
>>>
>>> Thanks,
>>> Deepal
>>>
>>> [1] https://issues.apache.org/jira/browse/AXIS2-5111
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
For additional commands, e-mail: java-user-h...@axis.apache.org
