You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2013/08/01 00:42:25 UTC
Re: Can LocalConduit use Direct Dispatch by default ?
On Jul 30, 2013, at 12:07 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Dan, others
>
> Do you remember why LocalConduit uses a piped-style communication by default ? The problem with that it causes calls with empty payloads hang (plenty of cases with RS but also possible with SOAP GET for ex), unless users go and enable a direct dispatch style.
If I remember correctly, the main reason is that using the Pipe enables ALL the interceptors and such to work exactly like they would if you used HTTP. Thus, you get a more accurate and similar path if you are trying to do a more complete test. With DIRECT_DISPATCH, a ton of things would be bypassed and thus stream based interceptors and such that you may expect to trigger wouldn't.
> I'd rather go and enable the direct dispatch style by default, will make things a bit simpler for users (no need to know about LocalConduit.DIRECT_DISPATCH unless really needed, and if they will need a piped style then they'd disable it by setting LocalConduit.DIRECT_DISPATCH to false)
I'm OK flipping it, but I'd also want to try and actually fix the problem. Can you create a small test case and @Ignore it and point me at it? Then I can try and update the Local transport to actually work properly for that case.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Can LocalConduit use Direct Dispatch by default ?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Dan
On 01/08/13 22:51, Daniel Kulp wrote:
>
> On Aug 1, 2013, at 4:58 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>
>> Hi Dan
>> On 31/07/13 23:42, Daniel Kulp wrote:
>>>
>>> On Jul 30, 2013, at 12:07 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>
>>>> I'd rather go and enable the direct dispatch style by default, will make things a bit simpler for users (no need to know about LocalConduit.DIRECT_DISPATCH unless really needed, and if they will need a piped style then they'd disable it by setting LocalConduit.DIRECT_DISPATCH to false)
>>>
>>> I'm OK flipping it, but I'd also want to try and actually fix the problem. Can you create a small test case and @Ignore it and point me at it? Then I can try and update the Local transport to actually work properly for that case.
>>>
>> As I mentioned on IRC, I made a GET test work in Pipe mode, for that to work I needed to update the client runtime to add writer interceptors even for cases when no output body is available and additionally write an empty string into the OS.
>>
>> I'm not really sure I'd like to do it only for a LocalConduit to work in a Pipe mode :-). May be a neater fix can be found. Have a look please when you have a chance, see JAXRSLocalTransportTest#testProxyDirectDispatchGet and comment out the line where a direct dispatch property is set.
>>
>> Enabling Direct Dispatch by default is not of high priority per se, but what appeals to me there is that the same code which works in the production can be parameterized on the address and reused with the local scheme, which is quite cool - though of course it works for WS even with Pipe.
>>
>> Though I can imagine that at Spring/Blueprint level there could be multiple jaxrs clients, some bound to HTTP, some to Local, etc - that can be done too if Pipe by default is important for Local.
>
>
> Now fixed on trunk… I'll merge to the other branches tomorrow or later tonight.
>
>
Great stuff, thanks
Sergey
Re: Can LocalConduit use Direct Dispatch by default ?
Posted by Daniel Kulp <dk...@apache.org>.
On Aug 1, 2013, at 4:58 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Dan
> On 31/07/13 23:42, Daniel Kulp wrote:
>>
>> On Jul 30, 2013, at 12:07 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>>
>>> I'd rather go and enable the direct dispatch style by default, will make things a bit simpler for users (no need to know about LocalConduit.DIRECT_DISPATCH unless really needed, and if they will need a piped style then they'd disable it by setting LocalConduit.DIRECT_DISPATCH to false)
>>
>> I'm OK flipping it, but I'd also want to try and actually fix the problem. Can you create a small test case and @Ignore it and point me at it? Then I can try and update the Local transport to actually work properly for that case.
>>
> As I mentioned on IRC, I made a GET test work in Pipe mode, for that to work I needed to update the client runtime to add writer interceptors even for cases when no output body is available and additionally write an empty string into the OS.
>
> I'm not really sure I'd like to do it only for a LocalConduit to work in a Pipe mode :-). May be a neater fix can be found. Have a look please when you have a chance, see JAXRSLocalTransportTest#testProxyDirectDispatchGet and comment out the line where a direct dispatch property is set.
>
> Enabling Direct Dispatch by default is not of high priority per se, but what appeals to me there is that the same code which works in the production can be parameterized on the address and reused with the local scheme, which is quite cool - though of course it works for WS even with Pipe.
>
> Though I can imagine that at Spring/Blueprint level there could be multiple jaxrs clients, some bound to HTTP, some to Local, etc - that can be done too if Pipe by default is important for Local.
Now fixed on trunk… I'll merge to the other branches tomorrow or later tonight.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Can LocalConduit use Direct Dispatch by default ?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Dan
On 31/07/13 23:42, Daniel Kulp wrote:
>
> On Jul 30, 2013, at 12:07 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>
>> Hi Dan, others
>>
>> Do you remember why LocalConduit uses a piped-style communication by default ? The problem with that it causes calls with empty payloads hang (plenty of cases with RS but also possible with SOAP GET for ex), unless users go and enable a direct dispatch style.
>
> If I remember correctly, the main reason is that using the Pipe enables ALL the interceptors and such to work exactly like they would if you used HTTP. Thus, you get a more accurate and similar path if you are trying to do a more complete test. With DIRECT_DISPATCH, a ton of things would be bypassed and thus stream based interceptors and such that you may expect to trigger wouldn't.
OK, that is useful to know, why is Pipe support there
>
>> I'd rather go and enable the direct dispatch style by default, will make things a bit simpler for users (no need to know about LocalConduit.DIRECT_DISPATCH unless really needed, and if they will need a piped style then they'd disable it by setting LocalConduit.DIRECT_DISPATCH to false)
>
> I'm OK flipping it, but I'd also want to try and actually fix the problem. Can you create a small test case and @Ignore it and point me at it? Then I can try and update the Local transport to actually work properly for that case.
>
As I mentioned on IRC, I made a GET test work in Pipe mode, for that to
work I needed to update the client runtime to add writer interceptors
even for cases when no output body is available and additionally write
an empty string into the OS.
I'm not really sure I'd like to do it only for a LocalConduit to work in
a Pipe mode :-). May be a neater fix can be found. Have a look please
when you have a chance, see
JAXRSLocalTransportTest#testProxyDirectDispatchGet and comment out the
line where a direct dispatch property is set.
Enabling Direct Dispatch by default is not of high priority per se, but
what appeals to me there is that the same code which works in the
production can be parameterized on the address and reused with the local
scheme, which is quite cool - though of course it works for WS even with
Pipe.
Though I can imagine that at Spring/Blueprint level there could be
multiple jaxrs clients, some bound to HTTP, some to Local, etc - that
can be done too if Pipe by default is important for Local.
Thanks, Sergey
>