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 <si...@googlemail.com> on 2007/11/06 16:55:25 UTC

Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding

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
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.. Did you specifically observe what was going on under the covers
to cause the problem?

Regards

Simon

On 11/1/07, Simon Laws (JIRA) <tu...@ws.apache.org> wrote:
>
>
>      [
> https://issues.apache.org/jira/browse/TUSCANY-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Simon Laws reassigned TUSCANY-1804:
> -----------------------------------
>
>     Assignee: Simon Laws
>
> > @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
>
>

Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding

Posted by Simon Laws <si...@googlemail.com>.
On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
>
> Hi Giorgio
>
> Thanks for the info, some comments below.
>
> Regards
>
> Simon
>
> On 11/7/07, Giorgio Zoppi < giorgio.zoppi@gmail.com> wrote:
> >
> > 2007/11/6, Simon Laws < simonslaws@googlemail.com>:
> > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> Doh, I see you just updated JIRA 1863. Scratch my question in my last
post:-) I'll go get the latest patch.

Simon

Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding

Posted by Simon Laws <si...@googlemail.com>.
On 11/7/07, Giorgio Zoppi <gi...@gmail.com> wrote:
>
> 2007/11/7, Simon Laws <si...@googlemail.com>:
> > Hi Giorgio
> >
> > Thanks for the info, some comments below.
> >
> > Regards
> >
> > Simon
> >
> > On 11/7/07, Giorgio Zoppi <gi...@gmail.com> wrote:
> > >
> > > 2007/11/6, Simon Laws <si...@googlemail.com>:
> > > > 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.
>
> Ok. I found a problem with Tomcat servlet mapping. If you see my
> example you have four references in the workpool, do you know the
> binding creates for times the same servlet mapping..This works with
> Jetty, but if you try inside eclipse and Tomcat hangs.
> I figure out, that there're scalabilty issue (i.e. connection is
> closed), i saw ant's post( and relative JIRA) about AsyncWeb Servlet,
> and when i'll finished my management work..I'll try to something in
> these sense.  My next step it will be to adapt the workers to the
> workload.
> I hope to have something working for tomorrow morning.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org


I would expect a mapping to be added for each distinct service. You're
starting four worker components and each component exposes a service over
the default sca binding which is web services in the remote case. Are these
the mappings you are having problems with (I don't have it running just
yet)?

Simon

Simon

Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding

Posted by Giorgio Zoppi <gi...@gmail.com>.
2007/11/7, Simon Laws <si...@googlemail.com>:
> Hi Giorgio
>
> Thanks for the info, some comments below.
>
> Regards
>
> Simon
>
> On 11/7/07, Giorgio Zoppi <gi...@gmail.com> wrote:
> >
> > 2007/11/6, Simon Laws <si...@googlemail.com>:
> > > 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.

Ok. I found a problem with Tomcat servlet mapping. If you see my
example you have four references in the workpool, do you know the
binding creates for times the same servlet mapping..This works with
Jetty, but if you try inside eclipse and Tomcat hangs.
I figure out, that there're scalabilty issue (i.e. connection is
closed), i saw ant's post( and relative JIRA) about AsyncWeb Servlet,
and when i'll finished my management work..I'll try to something in
these sense.  My next step it will be to adapt the workers to the
workload.
I hope to have something working for tomorrow morning.

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


Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding

Posted by Simon Laws <si...@googlemail.com>.
Hi Giorgio

Thanks for the info, some comments below.

Regards

Simon

On 11/7/07, Giorgio Zoppi <gi...@gmail.com> wrote:
>
> 2007/11/6, Simon Laws <si...@googlemail.com>:
> > 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding

Posted by Giorgio Zoppi <gi...@gmail.com>.
2007/11/6, Simon Laws <si...@googlemail.com>:
> 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.

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