cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Can LocalConduit use Direct Dispatch by default ?
Date Thu, 01 Aug 2013 20:58:47 GMT
Hi Dan
On 31/07/13 23:42, Daniel Kulp wrote:
>
> On Jul 30, 2013, at 12:07 PM, Sergey Beryozkin <sberyozkin@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

>


Mime
View raw message