Comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
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 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 the
following situation:
1. An SCA client inserts a nonblocking interceptor in case it's talking
to a
non-SCA service
+1.
2. An SCA service inserts a nonblocking interceptor in case it's being
called
from a non-SCA client
This would be ideal if the the service is very time-consuming.
3. When an SCA client talks to an SCA service, both the client and the
service
will have nonblocking interceptors and we will do a thread switch at
both ends.
If the SCA to SCA calls is over a remote protocol such as SOAP/HTTP, isn't
case 3 the same as case 1+ case2?
I don't much like case 3. For this case, the best place for the thread
switch
is on the client side, because this does not block the client while the
wire
protocol messages (two-way MEP) are being exchanged. This allows cases 1
and
3 to be supported. For case 2, it would be necessary for the non-SCA
client
to be able to spin off a thread if it wants to achieve nonblocking
semantics.
In case 2, thread switching on the client side will not help the resource
allocation on the server side. For example, there are only a limited number
threads in the pool to serve SOAP/HTTP requests.
Note that it is not an error or a violation of the SCA spec if the call
executes
in a blocking manner in case 2. Specifying the @OneWay annotation allows
the
method to be invoked in a nonblocking manner, but does not require this.
If we agree that the interceptor should always go on the client side, then
we should remove the supportsAsyncOneWayInvocation() method from the
service
provider SPI.
What do others think?
Simon
Rashmi Hunt (JIRA) wrote:
[
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
Missing NonBlockingInterceptor on service wire
----------------------------------------------
Key: TUSCANY-1674
URL: https://issues.apache.org/jira/browse/TUSCANY-1674
Project: Tuscany
Issue Type: Bug
Reporter: Rashmi Hunt
Attachments: RuntimeWireImpl.java
The reason why NonBlockingInterceptor is needed on the service wire as
well is, if there is no nonBlockingInterceptor at service wire and if the
service is invoked not from a reference then there is no asynch support
even if the call is non blocking. For e.g if a pure webservice client
(or any pure client) is sending a request to a non blocking service call,
since Tuscany code is currently missing a nonBlockingInterceptor on the
service wire, there is no async support for this case, even though the
service operation is marked as non-blocking. Solution is straightforward.
Add NonBlockingInterCeptor on service wire in
RuntimeWireImpl.initInvocationChains() for the service wire clause
Binding serviceBinding = wireTarget.getBinding();
if (operation.isNonBlocking()) {
addNonBlockingInterceptor(service, serviceBinding,
chain);
}
And add a new addNonBlockingInterceptor() function which takes params
service, serviceBinding, chain
/**
* Add a non-blocking interceptor if the service binding needs it
*
* @param service
* @param binding
* @param chain
*/
private void addNonBlockingInterceptor(ComponentService service,
Binding binding, InvocationChain chain) {
ServiceBindingProvider provider =
((RuntimeComponentService)service).getBindingProvider(binding);
if (provider != null) {
boolean supportsAsyncOneWayInvocation = false;
if (provider instanceof ServiceBindingProvider2) {
supportsAsyncOneWayInvocation =
((ServiceBindingProvider2)provider).supportsAsyncOneWayInvocation();
} else {
// Must be an old provider that doesn't have this method.
If this is a old provider keep the behavior
// as is where there is no nonBlockingInterceptor on the
service wire. If a binding provider needs a
// nonBlocking interceptor, it would have been
implemented ServiceBindingProvider2 and indicated
// supportsAsyncOneWayInvocation accordingly
supportsAsyncOneWayInvocation = true;
}
if (!supportsAsyncOneWayInvocation) {
chain.addInterceptor(new
NonBlockingInterceptor(workScheduler));
}
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
