Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding
2007/11/7, Simon Laws [EMAIL PROTECTED]:
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 lineif (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: [EMAIL
Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding
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 lineif (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]
Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding
On 11/7/07, Giorgio Zoppi [EMAIL PROTECTED] wrote:
2007/11/7, Simon Laws [EMAIL PROTECTED]:
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 lineif (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.
Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding
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 lineif (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
Re: Axis client settings was: Re: [jira] Assigned: (TUSCANY-1804) @OneWay repeted invocations doesn't work in web service binding
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 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 lineif (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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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) tuscany-dev@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_:param03.0/_ns_:param0_ns_:p
aram12.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: [EMAIL PROTECTED]
For additional commands,
[jira] Assigned: (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: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_:param03.0/_ns_:param0_ns_:p
aram12.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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
