Hi Giorgio

Thanks for the info, some comments below.

Regards

Simon

On 11/7/07, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:
>
> 2007/11/6, Simon Laws <[EMAIL PROTECTED]>:
> > 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 saw that you were setting the default max connections per host. Looking at
the docs it looked like it defaulted to 2 anyhow (but I can't find the
reference again). We should have an axis client per reference/binding so
we'll only hit this in the multi threaded case so I think this is ok for
now.

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


Ah,  I see, there is history here:-)

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 :).


All Raymond's hard work ;-)

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.


Ok, great. I'm all set to help port this over to the trunk code so that we
can get it running against the latest code. Should I wait until you submit
updated code? I assume you will update JIRA 1863.

One of this things I'm thinking about at the moment is load balancing in the
general sense so I was thinking it would be neat if we can use you sample as
is to show how you can do some load balancing using vanilla Tuscany
components themselves as you have it at the moment. Then we could adjust the
sample (make a cope and change it) and show how it could be done using
something like a Tomcat cluster.

Cheers,
> Giorgio.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to