[
https://issues.apache.org/jira/browse/TUSCANY-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Giorgio Zoppi updated TUSCANY-1674:
---
Attachment: patch-nonblocking.txt
Patch for TUSCANY-1674 against rev576895 (maybe 1.0-RC2)
[
https://issues.apache.org/jira/browse/TUSCANY-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder updated TUSCANY-1674:
---
Fix Version/s: (was: Java-SCA-1.0)
Java-SCA-Next
Deferring all the non-criti
Thanks for the detailed reply. See my comments inline.
Simon
Rashmi Hunt wrote:
Thank you for the response. the proposed implementation will not insert non
blocking
interceptor for every service wire. The proposed logic inserts a
NonBlockingInterceptor
on the service wire only if binding i
Thank you for the response. the proposed implementation will not insert non
blocking
interceptor for every service wire. The proposed logic inserts a
NonBlockingInterceptor
on the service wire only if binding indicates it and the operation is
nonblocking(oeway).
It's up the binding to decide if th
Comments inline.
Thanks,
Raymond
- Original Message -
From: "Simon Nash" <[EMAIL PROTECTED]>
To:
Sent: Friday, September 07, 2007 8:52 AM
Subject: Re: [jira] Updated: (TUSCANY-1674) Missing NonBlockingInterceptor
on service wire
I'm not convinced that this
I'm not convinced that this interceptor should be added on the service side.
If the binding used for the call supports a nonblocking MEP and wire protocol,
then a non-SCA caller can use this MEP to achieve nonblocking semantics.
If the binding only supports two-way blocking MEP, then we get into t
[
https://issues.apache.org/jira/browse/TUSCANY-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rashmi Hunt updated TUSCANY-1674:
-
Attachment: RuntimeWireImpl.java
This patch is applied on top of Tuscany revision r572771
> M
