You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Samisa Abeysinghe <sa...@yahoo.com> on 2004/05/25 10:49:03 UTC
Extending the current code and copy constructors
Hi All,
As I mentioned earlier, I am in the process of developing a Stub class on top of which I could
set transport properties and SOAP headers.
Unfortunately I have run into unexpected difficulties due to the fact that some classes do not
have copy constructors.
As an example, if I try to crate a set of Header Blocks and try to reapply the same set of
headers to subsequent calls, only the first call succeds and the client segfaults after that. The
reason is that when I pass the pointer of HeaderBlock to SoapSerializer, it owns the pointer and
deletes it. But I do want to keep my copy as I want to apply the same header to all calls.
If I were to have copy constructors that does a deep copy of the objects, I could have solved
the problem by passing a copy.
Please make sure you write copy constructors for the classes that you create in the future,
so that the code could be made extensible with minimal effort in the future.
Thaka,
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Re: Extending the current code and copy constructors
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- susantha@opensource.lk wrote:
> Why dont you pass those header blocks as constant objects ?.
Well I am working with the existing API. The current API only supports passing pointers. If I am
to change the existing API, it will take more than two weeks, as there are many class couplings.
What I am tryng to do is to get the stub going with whatever class stucture that is there already.
> delegate implicit object creation to copy constructors of the stub class,
> in order to do a deep copy all the header blocks and objects inside it too
> should have copy constructors.
It is not the Stub class, but the HeaderBlock class that should have copy constructor. Yes, all
classes that are members too should have copy constructors. They are not there in the current
code, and that is problamatic when it comes to using Call class which is the entry point to client
side stub management.
> But I dont think I have a good understanding of you client application. I
> would prefer adding the header block explicitly to every stub object. and
> deleting them at the stub level it self explicitly.
Well that is the the correct design. However, the SoapSerializer does delete the pointer that I
pass. It is good that the serializer does its own cleanup. I can live with it if there were copy
constructors.
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Re: Extending the current code and copy constructors
Posted by su...@opensource.lk.
Why dont you pass those header blocks as constant objects ?. If you
delegate implicit object creation to copy constructors of the stub class,
in order to do a deep copy all the header blocks and objects inside it too
should have copy constructors.
But I dont think I have a good understanding of you client application. I
would prefer adding the header block explicitly to every stub object. and
deleting them at the stub level it self explicitly.
---
Susantha.
> Hi All,
> As I mentioned earlier, I am in the process of developing a Stub class
> on top of which I could
> set transport properties and SOAP headers.
> Unfortunately I have run into unexpected difficulties due to the fact
> that some classes do not
> have copy constructors.
>
> As an example, if I try to crate a set of Header Blocks and try to
> reapply the same set of
> headers to subsequent calls, only the first call succeds and the client
> segfaults after that. The
> reason is that when I pass the pointer of HeaderBlock to SoapSerializer,
> it owns the pointer and
> deletes it. But I do want to keep my copy as I want to apply the same
> header to all calls.
> If I were to have copy constructors that does a deep copy of the
> objects, I could have solved
> the problem by passing a copy.
>
> Please make sure you write copy constructors for the classes that you
> create in the future,
> so that the code could be made extensible with minimal effort in the
> future.
> Thaka,
> Samisa...
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
>
>
Re: Latest cvs code server side fails
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
BTW the client crashes on Linux with the output:
execution break
m_pMsg==NULL
Segmentation fault
When invoked with Axis C++ service as end point. This crash is nothing to do with the client, but
the service does not respond.
We got to make client not to segfault when the error is at server side. Otherwise users get
confused thinking that the client is crashing.
(I am sure that client side works because I tested with Axis Java service)
Samisa...
--- Samisa Abeysinghe <sa...@yahoo.com> wrote:
> I tested the latest cvs code and there is somethig wrong on server side with Apache 2 and Xerces
>
> Client works (I tested client with Axis Java services)
>
> Has the new configuration file been intorduced?
>
> Samisa...
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Latest cvs code server side fails
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
I tested the latest cvs code and there is somethig wrong on server side with Apache 2 and Xerces
Client works (I tested client with Axis Java services)
Has the new configuration file been intorduced?
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
RE: Call initilize and uninitialize
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
> We have to change the code to store these stub specific information in
> the stub itself (or inside its Call class object). These information
> that we should keep in the Call class instance are,
>
> - Stub's style (CPP_RPC_PROVIDER etc)
> - Communication protocols (HTTP, SMTP etc)
> - Web Service Endpoint URI
> - SOAP Version to Use
> - And any other stub specific information that are in the original WSDL
Are they stub specific? I do not think so. What about the state of the client engine. If I am to
tell the client engine evrything for each method invocation, client engine becomes just a dummy
unit. I expect it to handle the state for me.
> > If the client stub is to set this for each method invocation, isnt it
> > inefficient?
>
> Yes, Only the method specific information should be set/get within the
> stub's generated method.
What I am saying is while the things you have mentioned above(transport protocol, SOAP version)
can change between method calls they are not method specific. Logically only parametes and return
values are method specific. Others are options which may or may not change per method invocation.
Hence the engine should hold then in its state.
> > Allocation/deallocation should not be based on big or samll.
>
> Why not ?. Bigger the object is the bigger memory allocation overhead in
> system call. And if there are any initializations to be done we have to
> do them for each object that we create.
>
> > Rather on the
> > life time of objects.
>
> Life time of an object is an important design decision. Are you saying
> that every stub object should have its own Serializer / Deserializer /
> Transport / Parser objects ?.
Yes they should, as there are state information that need to be held with referance to a stub.
> Consider a single threaded client application with several stub
> instances talking to several web services (or same web service). In such
> a case if each stub has its own set of Axis objects it's a waste. If
> this is a multi-threaded application the object pools make sure that you
> maintain a minimum number of Axis objects.
If the same client connects to multiple web services (or to same web service) using several stubs,
with threads, logically each stub should have its own state. If you have 5 threads and 5 stubs in
each thread, there is a chance that each stub will be using serializer concurrently. So the fact
that there is a pool does not mean that you can do the job with 3 serializers. They need 5; one
each. While pooling could make it efficient so that you do not have to face the creation time
overhead when you need one, the pool does not provide means of maintaining minimum no of objects.
That is not the purpose of a pool.
> At the server side this pooling of Axis object is a must for
> performance.
Client side too will benefit from pooling. However do not mix up pooling with state management.
> No they cannot be considered as functions. Also they do not have state
> variables. All variables in them are used to accomplish its task when it
> is used by a stub. Please see the purpose of following variable in
> SoapSerializer class,
>
> volatile SerializeBuffers* m_pSZBuffers;
> BasicTypeSerializer m_BTSZ;
Well these two are not sufficint to handle the state of the serializer.
e.g. Do they reflect the SOAP version currently in use?
Theoritically speaking BasicTypeSerializer do tell you how to do the stuff. It is a utility class,
it does not hold any state.
> > > This implies that if there is any persistent data that you want to
> keep
> > > across several method invocations, you have to keep them in,
> > > 1. A handler
> > > 2. The client application (stub)
> > > 3. Web service.
> >
> > If they are to hold evryting and pass everyting to te engine, the
> engine
> > is just like a functional
> > unit.
>
> Yes my opinion is that it has to be a functional unit.
:-) Its like a huge function.
> My opinion is that either your stub object or your application should
> hold the state data. Not the Axis Engine. Axis Engine should be a set of
> objects that serves any stub/web service at runtime.
When I talk about state, what I mean is the state in OO terms.
> What if you need to change/remove/add the SOAP headers in between
> several method calls of the same stub. Ex: you have Headers H1, H2, H3,
> H4 and you have methods M1, M2, M3 and you need to call methods in
> following order with the headers
>
> M1 with H1, H2, H3
> M2 with H4 only
> M3 with H1, H2
> .....
> .....
In a SOA, where where the service requests are atomic units, I could reorder this and call
M1
M3
M2
Now you see why I want state.
Also practically speaking, most of the time I will not switch headers, rather the header content.
> Keeping the created and populated header structures/properties with the
> stub and passing them as needed to the engine for each method call is
> far more efficient than you everytime creating+populating (or cloning),
> passing to axis engine and letting axis engine to delete them everytime.
Well now do not grab my throat for cloning :-)
I know that it is inefficient. (I never said it is efficient; did I?)
What I did was to live with what I have. I wanted to get the stub level soap header setting
working with existing engine. I did add an external layer with whatever I had inside the engine.
Why I brought this whole argument up is to hihlight that there are some issues.
Cloning can be removed (just comment the line :-) )
Thanks,
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
RE: Call initilize and uninitialize
Posted by Susantha Kumara <su...@opensource.lk>.
Hi Samisa,
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Thursday, May 27, 2004 9:06 AM
> To: Apache AXIS C Developers List
> Subject: RE: Call initilize and uninitialize
>
> > No not any big objects are allocated and deallocated per each method
> > invocation. Only the request/response specific objects like
> > SoapEnvelope, SoapBody, SoapMethod are allocated and deallocated. We
> > cannot avoid that.
>
> Say I have 10 method calls in my stub. And I want to use SOAP 1.1 for
all
> method invocations.
> Why sould I set it in each method invocation unless othervise I decide
to
> change the SOAP version?
> Where am I supposed to hold this data regarding SOAP version?
We have to change the code to store these stub specific information in
the stub itself (or inside its Call class object). These information
that we should keep in the Call class instance are,
- Stub's style (CPP_RPC_PROVIDER etc)
- Communication protocols (HTTP, SMTP etc)
- Web Service Endpoint URI
- SOAP Version to Use
- And any other stub specific information that are in the original WSDL
> If the client stub is to set this for each method invocation, isnt it
> inefficient?
Yes, Only the method specific information should be set/get within the
stub's generated method.
>
> Allocation/deallocation should not be based on big or samll.
Why not ?. Bigger the object is the bigger memory allocation overhead in
system call. And if there are any initializations to be done we have to
do them for each object that we create.
> Rather on the
> life time of objects.
Life time of an object is an important design decision. Are you saying
that every stub object should have its own Serializer / Deserializer /
Transport / Parser objects ?.
Consider a single threaded client application with several stub
instances talking to several web services (or same web service). In such
a case if each stub has its own set of Axis objects it's a waste. If
this is a multi-threaded application the object pools make sure that you
maintain a minimum number of Axis objects.
At the server side this pooling of Axis object is a must for
performance.
>
> >
> > The concept that we have is that a Deserializer or Serializer
objects
> > are never bound to a request. That is they do not keep any
persistent
> > data inside them. This applies to both client side and server side.
> Serializer and Deserializer are not bound to request, but they are
used by
> method invocations.
Yes
> If you consider them as functions, you have to pass all the data they
> require.
> However if they are objets, they can have state and their memeber
> variables should reflest the
> state. It is not about persistant data, but about state.
No they cannot be considered as functions. Also they do not have state
variables. All variables in them are used to accomplish its task when it
is used by a stub. Please see the purpose of following variable in
SoapSerializer class,
volatile SerializeBuffers* m_pSZBuffers;
BasicTypeSerializer m_BTSZ;
>
> > This implies that if there is any persistent data that you want to
keep
> > across several method invocations, you have to keep them in,
> > 1. A handler
> > 2. The client application (stub)
> > 3. Web service.
>
> If they are to hold evryting and pass everyting to te engine, the
engine
> is just like a functional
> unit.
Yes my opinion is that it has to be a functional unit.
> However, I expect the engine to hold the state data in an OO design.
My opinion is that either your stub object or your application should
hold the state data. Not the Axis Engine. Axis Engine should be a set of
objects that serves any stub/web service at runtime.
>
> As an example, once I instruct the engine to set a SOAP header to
outgoing
> calls, the expectation
> is that the engine will do so for all my calls, until I explicitly
tell
> the engine not to do so.
What if you need to change/remove/add the SOAP headers in between
several method calls of the same stub. Ex: you have Headers H1, H2, H3,
H4 and you have methods M1, M2, M3 and you need to call methods in
following order with the headers
M1 with H1, H2, H3
M2 with H4 only
M3 with H1, H2
.....
.....
In this case you anyway have to tell AxisEngine what headers you need to
send and what not to.
> If the client stub has to repetedly tell the samething over and over
> againg, it is far more
> inefficient.
Keeping the created and populated header structures/properties with the
stub and passing them as needed to the engine for each method call is
far more efficient than you everytime creating+populating (or cloning),
passing to axis engine and letting axis engine to delete them everytime.
>
> Samisa...
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
RE: Call initilize and uninitialize
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
> No not any big objects are allocated and deallocated per each method
> invocation. Only the request/response specific objects like
> SoapEnvelope, SoapBody, SoapMethod are allocated and deallocated. We
> cannot avoid that.
Say I have 10 method calls in my stub. And I want to use SOAP 1.1 for all method invocations.
Why sould I set it in each method invocation unless othervise I decide to change the SOAP version?
Where am I supposed to hold this data regarding SOAP version?
If the client stub is to set this for each method invocation, isnt it inefficient?
Allocation/deallocation should not be based on big or samll. Rather on the life time of objects.
>
> The concept that we have is that a Deserializer or Serializer objects
> are never bound to a request. That is they do not keep any persistent
> data inside them. This applies to both client side and server side.
Serializer and Deserializer are not bound to request, but they are used by method invocations.
If you consider them as functions, you have to pass all the data they require.
However if they are objets, they can have state and their memeber variables should reflest the
state. It is not about persistant data, but about state.
> This implies that if there is any persistent data that you want to keep
> across several method invocations, you have to keep them in,
> 1. A handler
> 2. The client application (stub)
> 3. Web service.
If they are to hold evryting and pass everyting to te engine, the engine is just like a functional
unit.
However, I expect the engine to hold the state data in an OO design.
As an example, once I instruct the engine to set a SOAP header to outgoing calls, the expectation
is that the engine will do so for all my calls, until I explicitly tell the engine not to do so.
If the client stub has to repetedly tell the samething over and over againg, it is far more
inefficient.
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
RE: Call initilize and uninitialize
Posted by Susantha Kumara <su...@opensource.lk>.
Hi Samisa,
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Wednesday, May 26, 2004 4:29 PM
> To: Apache AXIS C Developers List
> Subject: RE: Call initilize and uninitialize
>
> --- Susantha Kumara <su...@opensource.lk> wrote:
> > Of course we re-use Serializer and Deserializer objects. But we get
them
> > initialized. There are pools to hold them.
>
> Why are they pooled? What makes them worth pooling?
It is inefficient to allocate/deallocate those objects for each method
invocaton. Because they are big objects that can be re-used after
initialing.
> Also, allocation/deallocation happens per each method invocation at
stub
> level.
No not any big objects are allocated and deallocated per each method
invocation. Only the request/response specific objects like
SoapEnvelope, SoapBody, SoapMethod are allocated and deallocated. We
cannot avoid that.
The concept that we have is that a Deserializer or Serializer objects
are never bound to a request. That is they do not keep any persistent
data inside them. This applies to both client side and server side.
This implies that if there is any persistent data that you want to keep
across several method invocations, you have to keep them in,
1. A handler
2. The client application (stub)
3. Web service.
---
Susantha.
(The same makes
> header blocks to reset) Is this efficient?
>
> Samisa...
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
RE: Call initilize and uninitialize
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- Susantha Kumara <su...@opensource.lk> wrote:
> Of course we re-use Serializer and Deserializer objects. But we get them
> initialized. There are pools to hold them.
Why are they pooled? What makes them worth pooling?
Also, allocation/deallocation happens per each method invocation at stub level. (The same makes
header blocks to reset) Is this efficient?
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
RE: Call initilize and uninitialize
Posted by Susantha Kumara <su...@opensource.lk>.
Of course we re-use Serializer and Deserializer objects. But we get them
initialized. There are pools to hold them.
But MessageData basically contain data corresponding to one request.
Also the is a small object. So we don't mind creating a new one for each
request.
ClientEngine too is a small object.
---
Susantha
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Wednesday, May 26, 2004 8:54 AM
> To: Apache AXIS C Developers List
> Subject: Re: Call initilize and uninitialize
>
> --- susantha@opensource.lk wrote:
> > Each remote method invocation need to do following,
> >
> > 1. Create a new MessageData object.
> > 2. Use initialized Serializer/Deserializer objects.
> > 3. Create a new ClientEngine object which holds all above.
>
> Why cant we reuse these, without receating for each method invocation?
> Is there a perticular reason?
>
> Samisa...
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
Re: Call initilize and uninitialize
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- susantha@opensource.lk wrote:
> Each remote method invocation need to do following,
>
> 1. Create a new MessageData object.
> 2. Use initialized Serializer/Deserializer objects.
> 3. Create a new ClientEngine object which holds all above.
Why cant we reuse these, without receating for each method invocation?
Is there a perticular reason?
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Re: Call initilize and uninitialize
Posted by su...@opensource.lk.
Each remote method invocation need to do following,
1. Create a new MessageData object.
2. Use initialized Serializer/Deserializer objects.
3. Create a new ClientEngine object which holds all above.
I think we should avoid connecting to the server whenever possible. For an
example if the transport provides the facilities like "HTTP KEEP ALIVE"
> Hi All,
> In the generated client stubs, I see that the Call object is
> initialized and uninitilized for
> every call.
> I think this is too much for every call (there can be performace issues
> as well). Also initing
> and uniniting per metod call causes stub wide info to be erased between
> calls. We should only
> create and close the connection per each method call.
>
> Why not we initialize the Call once the stub class is created and
> ininitialize it in the stub
> destructor and call connect and disconnect for evry call?
>
> Thanks,
> Samisa...
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
>
>
Call initilize and uninitialize
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi All,
In the generated client stubs, I see that the Call object is initialized and uninitilized for
every call.
I think this is too much for every call (there can be performace issues as well). Also initing
and uniniting per metod call causes stub wide info to be erased between calls. We should only
create and close the connection per each method call.
Why not we initialize the Call once the stub class is created and ininitialize it in the stub
destructor and call connect and disconnect for evry call?
Thanks,
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/