On Thu, Aug 4, 2011 at 9:36 AM, Sagara Gunathunga
<sagara.gunathu...@gmail.com> wrote:
> On Thu, Aug 4, 2011 at 5:12 PM, Deepal Jayasinghe <dee...@opensource.lk>
> wrote:
>> Amila,
>>
>> 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.
>
> If you are going to fix this it would be nice to add some unit tests
> too so that someone will not break it again.
Yes, I already made a test case from Todd's code. So will definitely
add one, I remember sometime ago we decided that if we fix an issue we
should at a test case to make sure that no one breaks it again :).
Downside is we will keep adding test cases :)
Thanks,
Deepal
>
> Thanks !
>
>>
>> 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/
>>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - http://ssagara.blogspot.com
> Web - http://people.apache.org/~sagara/
> LinkedIn - http://www.linkedin.com/in/ssagara
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
> For additional commands, e-mail: java-user-h...@axis.apache.org
>
>
--
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
