You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Deepal jayasinghe <de...@gmail.com> on 2011/08/04 02:43:13 UTC
Non blocking with two channel is broken
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
<https://issues.apache.org/jira/browse/AXIS2-5111>
Re: Non blocking with two channel is broken
Posted by Deepal Jayasinghe <de...@gmail.com>.
>
> In a special case "replyTo" present and request transport,response
> transport are same shouldn't we send response message only without
> sending a ACK ?
Good question. IIRC, if the replyTo is there (not annon), then we need
to send the reply on the reply to transport regardless of the incoming
transport. But, I will double check before I implement (addressing
spec).
Thanks,
Deepal
>
> Thanks !
>>
>> I sent this email to mailing list to see whether someone has removed
>> the source code as part of some discussion, because I am sure I have
>> missed some long discussion after 2008. Now, it is sure that this
>> feature was not removed intentionally. So I will fix it correctly.
>>
>> With my academic work I hardly find time to go through the mailing
>> list and try to respond as much as I can. So going through commit
>> messages is not a practical solution for me (though I spent two hours
>> doing that). In fact I am not actively looking at Axis2 code base
>> since 2008, so it is hard for me to navigate all those changes.
>>
>> Thanks all of you for the actively participation, I will implement
>> this feature correctly (of course when I find a free time).
>>
>> Thanks,
>> Deepal
>>
>> On Fri, Aug 5, 2011 at 8:25 AM, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>>>
>>>
>>> On Fri, Aug 5, 2011 at 5:21 PM, Deepal jayasinghe <de...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe <de...@gmail.com>
>>>> wrote:
>>>>>
>>>>> >>
>>>>> >> 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.
>>>>
>>>> yes you need to add this parameter DO_ASYNC = "messageReceiver.
>>>> invokeOnSeparateThread" to services.xml.
>>>>
>>>> Do you want to make this by default. Then what about the backward
>>>> compatibility :)
>>>>
>>>> Long running services and two transports non-blocking invocations are two
>>>> different things. So, we do not need to make DO_ASYN the default. However, I
>>>> am talking about the removal of an existing functionalities, so backward
>>>> compatibility is already broken.
>>>
>>> I am not sure about the functionality you talk about. Is it possible you to
>>> find the commit which has removed that functionality you talk about?
>>>
>>> thanks,
>>> Amila.
>>>
>>>>
>>>> Thanks.,
>>>> Deepal
>>>
>>>
>>>
>>> --
>>> Amila Suriarachchi
>>> WSO2 Inc.
>>> blog: http://amilachinthaka.blogspot.com/
>>>
>>
>>
>>
>> --
>> http://blogs.deepal.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
>
> --
> 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-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Non blocking with two channel is broken
Posted by Sagara Gunathunga <sa...@gmail.com>.
On Fri, Aug 5, 2011 at 6:28 PM, Deepal Jayasinghe <de...@gmail.com> wrote:
> Amila, You might not remember the two transport functionality since
> this was done a long time ago, and in fact those days you were
> contributing the ADB and code generation. Actually, the long running
> services idea was initially developed based on the two transport
> semantics.
>
> The correct way to handle two transport or any request with replyTo
> (not anonymous), is to send the ACK on the request transport and send
> the reply through the reply to address. So, we had this feature and I
> have used and demoed this feature a number of times in various
> conferences.
In a special case "replyTo" present and request transport,response
transport are same shouldn't we send response message only without
sending a ACK ?
Thanks !
>
> I sent this email to mailing list to see whether someone has removed
> the source code as part of some discussion, because I am sure I have
> missed some long discussion after 2008. Now, it is sure that this
> feature was not removed intentionally. So I will fix it correctly.
>
> With my academic work I hardly find time to go through the mailing
> list and try to respond as much as I can. So going through commit
> messages is not a practical solution for me (though I spent two hours
> doing that). In fact I am not actively looking at Axis2 code base
> since 2008, so it is hard for me to navigate all those changes.
>
> Thanks all of you for the actively participation, I will implement
> this feature correctly (of course when I find a free time).
>
> Thanks,
> Deepal
>
> On Fri, Aug 5, 2011 at 8:25 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Fri, Aug 5, 2011 at 5:21 PM, Deepal jayasinghe <de...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe <de...@gmail.com>
>>> wrote:
>>>>
>>>> >>
>>>> >> 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.
>>>
>>> yes you need to add this parameter DO_ASYNC = "messageReceiver.
>>> invokeOnSeparateThread" to services.xml.
>>>
>>> Do you want to make this by default. Then what about the backward
>>> compatibility :)
>>>
>>> Long running services and two transports non-blocking invocations are two
>>> different things. So, we do not need to make DO_ASYN the default. However, I
>>> am talking about the removal of an existing functionalities, so backward
>>> compatibility is already broken.
>>
>> I am not sure about the functionality you talk about. Is it possible you to
>> find the commit which has removed that functionality you talk about?
>>
>> thanks,
>> Amila.
>>
>>>
>>> Thanks.,
>>> Deepal
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
>
> --
> http://blogs.deepal.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
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-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Non blocking with two channel is broken
Posted by Deepal Jayasinghe <de...@gmail.com>.
If you read the email thread, you will understand the initial issue I
mentioned, for more information have a look at the JIRA issue.
Thanks,
Deepal
On Fri, Aug 5, 2011 at 11:27 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Sat, Aug 6, 2011 at 8:53 AM, Deepal Jayasinghe <de...@gmail.com> wrote:
>>
>> On Fri, Aug 5, 2011 at 11:11 PM, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Fri, Aug 5, 2011 at 6:28 PM, Deepal Jayasinghe <de...@gmail.com>
>> > wrote:
>> >>
>> >> Amila, You might not remember the two transport functionality since
>> >> this was done a long time ago, and in fact those days you were
>> >> contributing the ADB and code generation. Actually, the long running
>> >> services idea was initially developed based on the two transport
>> >> semantics.
>> >>
>> >> The correct way to handle two transport or any request with replyTo
>> >> (not anonymous), is to send the ACK on the request transport and send
>> >> the reply through the reply to address. So, we had this feature and I
>> >> have used and demoed this feature a number of times in various
>> >> conferences.
>> >
>> > This is exactly what happens when you set that parameter and when the
>> > server
>> > receives an message with replyTo header.
>>
>> I agree, but two different scenario, in the long running case service
>> author knows about it and he sets the parameter. In the two transport
>> case, client does not aware of anything but he need to get the
>> response using different transport.
>
> Do you say that when the client set the replyTo header and send a message,
> he does not get the
> reply to the address given in replyTo header?
>
> thanks,
> Amila.
>
>>
>> Thanks,
>> Deepal
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> I sent this email to mailing list to see whether someone has removed
>> >> the source code as part of some discussion, because I am sure I have
>> >> missed some long discussion after 2008. Now, it is sure that this
>> >> feature was not removed intentionally. So I will fix it correctly.
>> >>
>> >> With my academic work I hardly find time to go through the mailing
>> >> list and try to respond as much as I can. So going through commit
>> >> messages is not a practical solution for me (though I spent two hours
>> >> doing that). In fact I am not actively looking at Axis2 code base
>> >> since 2008, so it is hard for me to navigate all those changes.
>> >>
>> >> Thanks all of you for the actively participation, I will implement
>> >> this feature correctly (of course when I find a free time).
>> >>
>> >> Thanks,
>> >> Deepal
>> >>
>> >> On Fri, Aug 5, 2011 at 8:25 AM, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Aug 5, 2011 at 5:21 PM, Deepal jayasinghe <de...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe
>> >> >> <de...@gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> >>
>> >> >>> >> 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.
>> >> >>
>> >> >> yes you need to add this parameter DO_ASYNC = "messageReceiver.
>> >> >> invokeOnSeparateThread" to services.xml.
>> >> >>
>> >> >> Do you want to make this by default. Then what about the backward
>> >> >> compatibility :)
>> >> >>
>> >> >> Long running services and two transports non-blocking invocations
>> >> >> are
>> >> >> two
>> >> >> different things. So, we do not need to make DO_ASYN the default.
>> >> >> However, I
>> >> >> am talking about the removal of an existing functionalities, so
>> >> >> backward
>> >> >> compatibility is already broken.
>> >> >
>> >> > I am not sure about the functionality you talk about. Is it possible
>> >> > you
>> >> > to
>> >> > find the commit which has removed that functionality you talk about?
>> >> >
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >>
>> >> >> Thanks.,
>> >> >> Deepal
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> http://blogs.deepal.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>>
>>
>> --
>> http://blogs.deepal.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Non blocking with two channel is broken
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sat, Aug 6, 2011 at 8:53 AM, Deepal Jayasinghe <de...@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 11:11 PM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Fri, Aug 5, 2011 at 6:28 PM, Deepal Jayasinghe <de...@gmail.com>
> wrote:
> >>
> >> Amila, You might not remember the two transport functionality since
> >> this was done a long time ago, and in fact those days you were
> >> contributing the ADB and code generation. Actually, the long running
> >> services idea was initially developed based on the two transport
> >> semantics.
> >>
> >> The correct way to handle two transport or any request with replyTo
> >> (not anonymous), is to send the ACK on the request transport and send
> >> the reply through the reply to address. So, we had this feature and I
> >> have used and demoed this feature a number of times in various
> >> conferences.
> >
> > This is exactly what happens when you set that parameter and when the
> server
> > receives an message with replyTo header.
>
> I agree, but two different scenario, in the long running case service
> author knows about it and he sets the parameter. In the two transport
> case, client does not aware of anything but he need to get the
> response using different transport.
>
Do you say that when the client set the replyTo header and send a message,
he does not get the
reply to the address given in replyTo header?
thanks,
Amila.
>
> Thanks,
> Deepal
> >
> > thanks,
> > Amila.
> >
> >>
> >> I sent this email to mailing list to see whether someone has removed
> >> the source code as part of some discussion, because I am sure I have
> >> missed some long discussion after 2008. Now, it is sure that this
> >> feature was not removed intentionally. So I will fix it correctly.
> >>
> >> With my academic work I hardly find time to go through the mailing
> >> list and try to respond as much as I can. So going through commit
> >> messages is not a practical solution for me (though I spent two hours
> >> doing that). In fact I am not actively looking at Axis2 code base
> >> since 2008, so it is hard for me to navigate all those changes.
> >>
> >> Thanks all of you for the actively participation, I will implement
> >> this feature correctly (of course when I find a free time).
> >>
> >> Thanks,
> >> Deepal
> >>
> >> On Fri, Aug 5, 2011 at 8:25 AM, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Fri, Aug 5, 2011 at 5:21 PM, Deepal jayasinghe <de...@gmail.com>
> >> > wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe <deepalk@gmail.com
> >
> >> >> wrote:
> >> >>>
> >> >>> >>
> >> >>> >> 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.
> >> >>
> >> >> yes you need to add this parameter DO_ASYNC = "messageReceiver.
> >> >> invokeOnSeparateThread" to services.xml.
> >> >>
> >> >> Do you want to make this by default. Then what about the backward
> >> >> compatibility :)
> >> >>
> >> >> Long running services and two transports non-blocking invocations are
> >> >> two
> >> >> different things. So, we do not need to make DO_ASYN the default.
> >> >> However, I
> >> >> am talking about the removal of an existing functionalities, so
> >> >> backward
> >> >> compatibility is already broken.
> >> >
> >> > I am not sure about the functionality you talk about. Is it possible
> you
> >> > to
> >> > find the commit which has removed that functionality you talk about?
> >> >
> >> > thanks,
> >> > Amila.
> >> >
> >> >>
> >> >> Thanks.,
> >> >> Deepal
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >>
> >>
> >> --
> >> http://blogs.deepal.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
>
>
> --
> http://blogs.deepal.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Non blocking with two channel is broken
Posted by Deepal Jayasinghe <de...@gmail.com>.
On Fri, Aug 5, 2011 at 11:11 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Fri, Aug 5, 2011 at 6:28 PM, Deepal Jayasinghe <de...@gmail.com> wrote:
>>
>> Amila, You might not remember the two transport functionality since
>> this was done a long time ago, and in fact those days you were
>> contributing the ADB and code generation. Actually, the long running
>> services idea was initially developed based on the two transport
>> semantics.
>>
>> The correct way to handle two transport or any request with replyTo
>> (not anonymous), is to send the ACK on the request transport and send
>> the reply through the reply to address. So, we had this feature and I
>> have used and demoed this feature a number of times in various
>> conferences.
>
> This is exactly what happens when you set that parameter and when the server
> receives an message with replyTo header.
I agree, but two different scenario, in the long running case service
author knows about it and he sets the parameter. In the two transport
case, client does not aware of anything but he need to get the
response using different transport.
Thanks,
Deepal
>
> thanks,
> Amila.
>
>>
>> I sent this email to mailing list to see whether someone has removed
>> the source code as part of some discussion, because I am sure I have
>> missed some long discussion after 2008. Now, it is sure that this
>> feature was not removed intentionally. So I will fix it correctly.
>>
>> With my academic work I hardly find time to go through the mailing
>> list and try to respond as much as I can. So going through commit
>> messages is not a practical solution for me (though I spent two hours
>> doing that). In fact I am not actively looking at Axis2 code base
>> since 2008, so it is hard for me to navigate all those changes.
>>
>> Thanks all of you for the actively participation, I will implement
>> this feature correctly (of course when I find a free time).
>>
>> Thanks,
>> Deepal
>>
>> On Fri, Aug 5, 2011 at 8:25 AM, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Fri, Aug 5, 2011 at 5:21 PM, Deepal jayasinghe <de...@gmail.com>
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe <de...@gmail.com>
>> >> wrote:
>> >>>
>> >>> >>
>> >>> >> 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.
>> >>
>> >> yes you need to add this parameter DO_ASYNC = "messageReceiver.
>> >> invokeOnSeparateThread" to services.xml.
>> >>
>> >> Do you want to make this by default. Then what about the backward
>> >> compatibility :)
>> >>
>> >> Long running services and two transports non-blocking invocations are
>> >> two
>> >> different things. So, we do not need to make DO_ASYN the default.
>> >> However, I
>> >> am talking about the removal of an existing functionalities, so
>> >> backward
>> >> compatibility is already broken.
>> >
>> > I am not sure about the functionality you talk about. Is it possible you
>> > to
>> > find the commit which has removed that functionality you talk about?
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> Thanks.,
>> >> Deepal
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>>
>>
>> --
>> http://blogs.deepal.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Non blocking with two channel is broken
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Aug 5, 2011 at 6:28 PM, Deepal Jayasinghe <de...@gmail.com> wrote:
> Amila, You might not remember the two transport functionality since
> this was done a long time ago, and in fact those days you were
> contributing the ADB and code generation. Actually, the long running
> services idea was initially developed based on the two transport
> semantics.
>
> The correct way to handle two transport or any request with replyTo
> (not anonymous), is to send the ACK on the request transport and send
> the reply through the reply to address. So, we had this feature and I
> have used and demoed this feature a number of times in various
> conferences.
>
This is exactly what happens when you set that parameter and when the server
receives an message with replyTo header.
thanks,
Amila.
>
> I sent this email to mailing list to see whether someone has removed
> the source code as part of some discussion, because I am sure I have
> missed some long discussion after 2008. Now, it is sure that this
> feature was not removed intentionally. So I will fix it correctly.
>
> With my academic work I hardly find time to go through the mailing
> list and try to respond as much as I can. So going through commit
> messages is not a practical solution for me (though I spent two hours
> doing that). In fact I am not actively looking at Axis2 code base
> since 2008, so it is hard for me to navigate all those changes.
>
> Thanks all of you for the actively participation, I will implement
> this feature correctly (of course when I find a free time).
>
> Thanks,
> Deepal
>
> On Fri, Aug 5, 2011 at 8:25 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Fri, Aug 5, 2011 at 5:21 PM, Deepal jayasinghe <de...@gmail.com>
> wrote:
> >>
> >>
> >>
> >> On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe <de...@gmail.com>
> >> wrote:
> >>>
> >>> >>
> >>> >> 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.
> >>
> >> yes you need to add this parameter DO_ASYNC = "messageReceiver.
> >> invokeOnSeparateThread" to services.xml.
> >>
> >> Do you want to make this by default. Then what about the backward
> >> compatibility :)
> >>
> >> Long running services and two transports non-blocking invocations are
> two
> >> different things. So, we do not need to make DO_ASYN the default.
> However, I
> >> am talking about the removal of an existing functionalities, so backward
> >> compatibility is already broken.
> >
> > I am not sure about the functionality you talk about. Is it possible you
> to
> > find the commit which has removed that functionality you talk about?
> >
> > thanks,
> > Amila.
> >
> >>
> >> Thanks.,
> >> Deepal
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
>
>
> --
> http://blogs.deepal.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Non blocking with two channel is broken
Posted by Deepal Jayasinghe <de...@gmail.com>.
Amila, You might not remember the two transport functionality since
this was done a long time ago, and in fact those days you were
contributing the ADB and code generation. Actually, the long running
services idea was initially developed based on the two transport
semantics.
The correct way to handle two transport or any request with replyTo
(not anonymous), is to send the ACK on the request transport and send
the reply through the reply to address. So, we had this feature and I
have used and demoed this feature a number of times in various
conferences.
I sent this email to mailing list to see whether someone has removed
the source code as part of some discussion, because I am sure I have
missed some long discussion after 2008. Now, it is sure that this
feature was not removed intentionally. So I will fix it correctly.
With my academic work I hardly find time to go through the mailing
list and try to respond as much as I can. So going through commit
messages is not a practical solution for me (though I spent two hours
doing that). In fact I am not actively looking at Axis2 code base
since 2008, so it is hard for me to navigate all those changes.
Thanks all of you for the actively participation, I will implement
this feature correctly (of course when I find a free time).
Thanks,
Deepal
On Fri, Aug 5, 2011 at 8:25 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Fri, Aug 5, 2011 at 5:21 PM, Deepal jayasinghe <de...@gmail.com> wrote:
>>
>>
>>
>> On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe <de...@gmail.com>
>> wrote:
>>>
>>> >>
>>> >> 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.
>>
>> yes you need to add this parameter DO_ASYNC = "messageReceiver.
>> invokeOnSeparateThread" to services.xml.
>>
>> Do you want to make this by default. Then what about the backward
>> compatibility :)
>>
>> Long running services and two transports non-blocking invocations are two
>> different things. So, we do not need to make DO_ASYN the default. However, I
>> am talking about the removal of an existing functionalities, so backward
>> compatibility is already broken.
>
> I am not sure about the functionality you talk about. Is it possible you to
> find the commit which has removed that functionality you talk about?
>
> thanks,
> Amila.
>
>>
>> Thanks.,
>> Deepal
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Non blocking with two channel is broken
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Aug 5, 2011 at 5:21 PM, Deepal jayasinghe <de...@gmail.com> wrote:
>
>
>
> On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe <de...@gmail.com>wrote:
>
>> >>
>> >> 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.
>>
>
> yes you need to add this parameter DO_ASYNC = "messageReceiver.
> invokeOnSeparateThread" to services.xml.
>
> Do you want to make this by default. Then what about the backward
> compatibility :)
>
> Long running services and two transports non-blocking invocations are
> two different things. So, we do not need to make DO_ASYN the default.
> However, I am talking about the removal of an existing functionalities, so
> backward compatibility is already broken.
>
I am not sure about the functionality you talk about. Is it possible you to
find the commit which has removed that functionality you talk about?
thanks,
Amila.
>
>
> Thanks.,
> Deepal
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Non blocking with two channel is broken
Posted by Deepal jayasinghe <de...@gmail.com>.
>
>
> On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe <deepalk@gmail.com
> <ma...@gmail.com>> wrote:
>
> >>
> >> 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.
>
>
> yes you need to add this parameter DO_ASYNC = "messageReceiver.
> invokeOnSeparateThread" to services.xml.
>
> Do you want to make this by default. Then what about the backward
> compatibility :)
>
Long running services and two transports non-blocking invocations are
two different things. So, we do not need to make DO_ASYN the default.
However, I am talking about the removal of an existing functionalities,
so backward compatibility is already broken.
Thanks.,
Deepal
Re: Non blocking with two channel is broken
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Aug 4, 2011 at 7:32 PM, Deepal Jayasinghe <de...@gmail.com> wrote:
> >>
> >> 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.
>
yes you need to add this parameter DO_ASYNC = "messageReceiver.
invokeOnSeparateThread" to services.xml.
Do you want to make this by default. Then what about the backward
compatibility :)
thanks,
Amila.
>
> 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 <de...@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-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-user-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Non blocking with two channel is broken
Posted by Deepal Jayasinghe <de...@gmail.com>.
>>
>> 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 <de...@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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
Re: Non blocking with two channel is broken
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Aug 4, 2011 at 5:12 PM, Deepal Jayasinghe <de...@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.
>
This is for processing addressing headers with replyTo header.
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 <de...@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<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/
Re: Non blocking with two channel is broken
Posted by Andreas Veithen <an...@gmail.com>.
On Thu, Aug 4, 2011 at 15:50, Deepal Jayasinghe <de...@gmail.com> wrote:
> On Thu, Aug 4, 2011 at 9:36 AM, Sagara Gunathunga
> <sa...@gmail.com> wrote:
>> On Thu, Aug 4, 2011 at 5:12 PM, Deepal Jayasinghe <de...@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 :).
Good point. This project currently tolerates people who in more than
100 commits have not added a single unit test. That not only has a
negative impact on quality, but in many cases, this also makes it
virtually impossible to review the changes. I think that is something
we need to change.
> 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 <de...@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-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-user-help@axis.apache.org
>>
>>
>
>
>
> --
> http://blogs.deepal.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
Re: Non blocking with two channel is broken
Posted by Deepal Jayasinghe <de...@gmail.com>.
On Thu, Aug 4, 2011 at 9:36 AM, Sagara Gunathunga
<sa...@gmail.com> wrote:
> On Thu, Aug 4, 2011 at 5:12 PM, Deepal Jayasinghe <de...@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 <de...@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-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-user-help@axis.apache.org
>
>
--
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
Re: Non blocking with two channel is broken
Posted by Sagara Gunathunga <sa...@gmail.com>.
On Thu, Aug 4, 2011 at 5:12 PM, Deepal Jayasinghe <de...@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.
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 <de...@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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
Re: Non blocking with two channel is broken
Posted by Deepal Jayasinghe <de...@opensource.lk>.
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.
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 <deepalk@gmail.com
> <ma...@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
> <https://issues.apache.org/jira/browse/AXIS2-5111>
>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
Re: Non blocking with two channel is broken
Posted by Amila Suriarachchi <am...@gmail.com>.
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 <de...@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<https://issues.apache.org/jira/browse/AXIS2-5111>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Non blocking with two channel is broken
Posted by Amila Suriarachchi <am...@gmail.com>.
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 <de...@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<https://issues.apache.org/jira/browse/AXIS2-5111>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Non blocking with two channel is broken
Posted by Deepal Jayasinghe <de...@opensource.lk>.
If the response come before the timeout then it works. I am working on
the trunk.
Thanks.,
Deepal
On 8/4/2011 3:20 AM, Afkham Azeez wrote:
> I ran this scenario last week during a demo and it worked. But that
> was in WSO2 AS 4.1.0, which is based on Axis2 trunk. Perhaps this is
> an issue in the 1.5 branch?
>
>
> On Thu, Aug 4, 2011 at 6:13 AM, Deepal jayasinghe <deepalk@gmail.com
> <ma...@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
> <https://issues.apache.org/jira/browse/AXIS2-5111>
>
>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com,
> /Member; Apache Software Foundation; //http://www.apache.org//
> /
> /
> /email: //azeez@wso2.com/ <ma...@wso2.com>/ cell: +94 77 3320919
> blog: //http://blog.afkham.org//
> twitter: //http://twitter.com/afkham_azeez//
> linked-in: //http://lk.linkedin.com/in/afkhamazeez/
> /
> /
> /Lean . Enterprise . Middleware/
> /
> /
>
Re: Non blocking with two channel is broken
Posted by Afkham Azeez <af...@gmail.com>.
I ran this scenario last week during a demo and it worked. But that was in
WSO2 AS 4.1.0, which is based on Axis2 trunk. Perhaps this is an issue in
the 1.5 branch?
On Thu, Aug 4, 2011 at 6:13 AM, Deepal jayasinghe <de...@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<https://issues.apache.org/jira/browse/AXIS2-5111>
>
--
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com,
*Member; Apache Software Foundation;
**http://www.apache.org/*<http://www.apache.org/>
*
*
*email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
blog: **http://blog.afkham.org* <http://blog.afkham.org>*
twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
*
*
Re: Non blocking with two channel is broken
Posted by Afkham Azeez <af...@gmail.com>.
I ran this scenario last week during a demo and it worked. But that was in
WSO2 AS 4.1.0, which is based on Axis2 trunk. Perhaps this is an issue in
the 1.5 branch?
On Thu, Aug 4, 2011 at 6:13 AM, Deepal jayasinghe <de...@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<https://issues.apache.org/jira/browse/AXIS2-5111>
>
--
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com,
*Member; Apache Software Foundation;
**http://www.apache.org/*<http://www.apache.org/>
*
*
*email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
blog: **http://blog.afkham.org* <http://blog.afkham.org>*
twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
*
*