You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Simon Laws (JIRA)" <tu...@ws.apache.org> on 2007/11/09 11:19:51 UTC

[jira] Commented: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding

    [ https://issues.apache.org/jira/browse/TUSCANY-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541275 ] 

Simon Laws commented on TUSCANY-1804:
-------------------------------------

Some interesting comments from the mail list...


> Hi Giorgio
>
> Am just applying your patch to make repeated @OneWay invocations work to the
> tunk and it's looking good as I'm getting a clean build and the new onway
> itest now runs. (Am just updating your workpool demo to trunk level as well
> - more in this later) In the mean time I'm interested in understanding what
> was actually going wrong with the axis binding. Looking at the changes you
> made there are two main things.
>
> First, setting UseSeparateListener and AUTO_RELEASE_CONNECTION on the
> operation client
And setting max number operation for host.
I followed Axis Integrations tests:

http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/async/AsyncService2Test.java
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/async/AsyncService2Test.java

because in the Axis2 Ml was debated the use of async call.

> Second, creating an HTTPClient if one doesn't already exist,
>
> So, looking at this, it seems that Axis2 was not cleaning up connections
> properly after a request and that the default HTTP client was not configured
> correctly..
It was long debated on Axis2 ml, that Axis2 and Asynchronous
operations in several operation.
 Did you specifically observe what was going on under the covers
> to cause the problem?
No. I didn't debug well the axis code, because i saw this AXIS JIRA:

http://issues.apache.org/jira/browse/AXIS2-935

In the patch that i provided there's a problem, in SCA 1.0 my node
SCANodeImpl is different from yours...i found that the application
didn't clean up.
I corrected it in SCANodeImpl, when it calls stop I have:

   public void stop() throws ActivationException {

       // stop the components



       // remove contributions



       // Stop the node

       nodeRuntime.stop();

       //managementRuntime.stop();

       // Cleanup the top level composite

       nodeComposite = null;



       // remove the manager objects



       // go out and remove this node from the wider domain

       if (isStandalone == false){

           try {

               domainManager.removeNode(domainUri, nodeUri);

           } catch(Exception ex) {

               logger.log(Level.SEVERE,

                       "Can't connect to domain manager at: " +

                       domainUrl);

               throw new ActivationException(ex);

           }

       }

---> this line        if (managementRuntime!=null)

               managementRuntime.stop();



   }




In this way a node exits correctly. BTW Your transformer graph is
cool: the shortest path and giving weight to edges is nice :).
I still use Tuscany SCA 1.0, because a lot is changed in node
management in SCA 1.0.1.
I have the complete workpool ready and its job module binding now.
Now I have to create an autonomic manager for the workpool :). I issue
the JIRA for contributing.

Cheers,
Giorgio.

> @OneWay repeted invocations doesn't work in web service binding
> ---------------------------------------------------------------
>
>                 Key: TUSCANY-1804
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1804
>             Project: Tuscany
>          Issue Type: Bug
>    Affects Versions: Java-SCA-0.99
>         Environment: Eclipse/JDK 1.5 / Ubuntu Linux 7.04
>            Reporter: Giorgio Zoppi
>            Assignee: Simon Laws
>             Fix For: Java-SCA-1.0.1
>
>         Attachments: patch.diff
>
>
> i've found the bug that it doens't permit myself to use SCA Binding over
> WebService modifying the distributed-calculator. I found it (on Tuscany
> 1.0 rc3) following the chain towards the wire, and i discovered that
> it's an Axis Fault. If you modify in your distributed calculator sample
> the SubtractionService in the following way:
> @Remotable
> public interface SubtractService {
>    @OneWay
>    void subtract(double n1, double n2);
> }
> public class SubtractServiceImpl implements SubtractService {
>    public void subtract(double n1, double n2) {
>        System.out.println("SubtractService - subtract " + n1 + " and "
> + n2);
>        //return n1 - n2;
>    }
> }
> I know that it doesn't nothing...but it's a proof of concept.
> And in the calculator node:
>  for (int k = 0; k < 10; ++k)
>                    calculatorService.subtract(2*k+3, k);
> The nodeC with current Axis2OneWayBindingInvoker, even if it's called 10
> times..the receiver gets two messages..
> So in the nodeC terminal you can see only for example:
> [java] SubtractService - subtract 15.0 and 6.0
> [java] SubtractService - subtract 17.0 and 7.0
> The reason is due to the Axis HTTP REUSE:
> If you change in Axis2OneWayBindingInvoker
>  requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
> Boolean.TRUE);
> to:
>  requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
> Boolean.FALSE);
> It works! I suspect that there's a bug or a queue full in Axis because
> it seems that if you send something too fast it doesn't work (I'll see
> it tomorrow, because I don't know how the http client reuse works in Axis).
> The next test, I'll do it :
> for (int k = 0; k < 50; ++k)
>                    calculatorService.subtract(2*k+3, k);
> It seems to work, but in a strange way.
> During the debugging i discovered your nice structure in order to invoke
> methods over ws.
> Mainly for the Remote SCA over Web Services your structure has the
> following stages (correct me if i'm wrong):
> 1) JDKInvocationHandler, where you proxies the method call, create the
> message, set the source, the target and the operation. Here still you do
> some sort of initialization for handling callback.
> 2) DataTrasformationInterceptor, where you create the soap body of the
> message given the operation and parameters, for example:
> <_ns_:add
> xmlns:_ns_="http://calculator/xsd"><_ns_:param0>3.0</_ns_:param0><_ns_:p
> aram1>2.0</_ns_:param1></_ns_:add>
> 3) NonblockingInterceptor, where Tuscany schedules invocation in a
> workpool (here with jdk 1.5 , you could remove dependency from commonj
> package)
> 4) At time of scheduling, the next invoker is Axis2SCABindingInvoker,
> which it's a wrapper for Axis2BindingInvoker if the invocation is
> Request-response or for the Axis2BindingInvoker's child
> (Axis2OneWayBindingInvoker) if the invocation is OneWay. In
> Axis2*BindingInvoker you create the soap envelope,  the Axis's
> OperationClient, set the axis invocation options and Axis's
> MessageContext and the you send all the stuff on the wire.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org