On 11/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> 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]
> >
> >
> Doh, I see you just updated JIRA 1863. Scratch my question in my last
post:-) I'll go get the latest patch.

Simon

Reply via email to