Re: RE : Memory management process unclear

2010-01-20 Thread Brody Lodmell
thank you, that helps a lot.
I dont know how I didn't find this before.

On 1/20/10, Olivier Mengué  wrote:
> It looks like you should use AXIS2_FREE().
>
> From samples/client/google/google_client.c:
>
> buffer = axiom_node_to_string(google_om_node, env);
> printf("%s\n", buffer);
> AXIS2_FREE (env->allocator, buffer);
>
>
>
>  Message d'origine
> De: Brody Lodmell [mailto:brodylodm...@gmail.com]
> Date: mar. 19/01/2010 21 h 21
> À: axis-c-user@ws.apache.org
> Objet : Memory management process unclear
>
> we're using axis2 to consume soap services.
>
> this function
> axiom_node_to_string
>   AXIS2_EXTERN axis2_char_t *AXIS2_CALL
>   axiom_node_to_string(
>   axiom_node_t * om_node,
>   const axutil_env_t * env);
> declared in \axiom\include\axiom_node.h and defined in
> \axiom\src\om\om_node.h
>
> returns a different address each time I call it, indicating it might
> be dynamically allocated memory.  but when I try to free it, I get
> errors.
> I can't find any documentation on how this memory might be freed.
>
> is it the job of axiom_node_free_tree()?
>
> any insight anyone can provide would be helpful.
>
>


RE : Memory management process unclear

2010-01-20 Thread Olivier Mengué
It looks like you should use AXIS2_FREE().

>From samples/client/google/google_client.c:

buffer = axiom_node_to_string(google_om_node, env);
printf("%s\n", buffer);
AXIS2_FREE (env->allocator, buffer);



 Message d'origine
De: Brody Lodmell [mailto:brodylodm...@gmail.com]
Date: mar. 19/01/2010 21 h 21
À: axis-c-user@ws.apache.org
Objet : Memory management process unclear
 
we're using axis2 to consume soap services.

this function
axiom_node_to_string
  AXIS2_EXTERN axis2_char_t *AXIS2_CALL
  axiom_node_to_string(
  axiom_node_t * om_node,
  const axutil_env_t * env);
declared in \axiom\include\axiom_node.h and defined in \axiom\src\om\om_node.h

returns a different address each time I call it, indicating it might
be dynamically allocated memory.  but when I try to free it, I get
errors.
I can't find any documentation on how this memory might be freed.

is it the job of axiom_node_free_tree()?

any insight anyone can provide would be helpful.

<>

Re: Memory management process unclear

2010-01-20 Thread Samisa Abeysinghe
The samples are good source of reference in this case. For e.g. the echo
sample.

Can you share the client code that you are using?

Samisa...

On Wed, Jan 20, 2010 at 1:51 AM, Brody Lodmell wrote:

> we're using axis2 to consume soap services.
>
> this function
> axiom_node_to_string
>  AXIS2_EXTERN axis2_char_t *AXIS2_CALL
>  axiom_node_to_string(
>  axiom_node_t * om_node,
>  const axutil_env_t * env);
> declared in \axiom\include\axiom_node.h and defined in
> \axiom\src\om\om_node.h
>
> returns a different address each time I call it, indicating it might
> be dynamically allocated memory.  but when I try to free it, I get
> errors.
> I can't find any documentation on how this memory might be freed.
>
> is it the job of axiom_node_free_tree()?
>
> any insight anyone can provide would be helpful.
>



-- 
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.

http://www.wso2.com/ - "lean . enterprise . middleware"


Memory management process unclear

2010-01-19 Thread Brody Lodmell
we're using axis2 to consume soap services.

this function
axiom_node_to_string
  AXIS2_EXTERN axis2_char_t *AXIS2_CALL
  axiom_node_to_string(
  axiom_node_t * om_node,
  const axutil_env_t * env);
declared in \axiom\include\axiom_node.h and defined in \axiom\src\om\om_node.h

returns a different address each time I call it, indicating it might
be dynamically allocated memory.  but when I try to free it, I get
errors.
I can't find any documentation on how this memory might be freed.

is it the job of axiom_node_free_tree()?

any insight anyone can provide would be helpful.


Re: Axis2 simple http server memory management

2010-01-13 Thread Nandika Jayawardana
Usually, production deployment using axis2_http_server.exe is not
encouraged. We recommend using either Apache2 module or IIS module that
comes with axis2c for production deployment.

axis2_http_server.exe and axis2_tcp_server.exe manage memory by cleaning up
the allocated memory at the end of processing each request. There could be
some memory leaks which accumulate with the number of requests handled and
cause the growing memory usage issue.

You should be able to track the memory leaks using valgrind. On Windows
platform , you can use a tool like purify to check for memory leaks.

Regards
Nandika

On Wed, Jan 13, 2010 at 1:07 PM, Martin Benedix wrote:

> Patrick Duflot schrieb:
>
>  Hi list,
>>
>> I did a long-run test with the axis2 simple http server and the echo
>> sample client invoking the echo service every 3 seconds.
>> I saw the memory usage going from 4MB to 30MB then back to 10MB and then
>> again to 40MB. Now that I stopped the client from polling the service,
>> memory usage is as low as 80KB.
>>
>> NB : I am running Windows XP SP2
>>
>> What is axis2 http server memory management policy ?
>> Can we have some control over it ?
>>
>> A couple of related question :
>> How does it behaves with memory fragmentation ?
>> And the most importatnt one : Is Axis2 simple http server production ready
>> ?
>>
>> Thank you
>>
>> Patrick
>>
>>  Hi Patrick, Hi list.
>
> This are very important questions and I am also interested in the answers.
> So I wrote this reply to bring the topic up again.
> We are using the simple tcp server under linux and I experienced a growing
> memory consumption using the echo service and a saturation on a level
> at approximately 40 mb. I think that this is a result of the high watermark
> memory usage strategy of linux.
> I wanted to use valgrind on the simple tcp server and did not manage to get
> any output from the tool.
> What would be a good way to examine the memory usage behaviour of the
> tcp server? Has anyone succeeded in using valgrind on the tcp server?
> Any suggestion is highly welcome :)
>
> Thanks in advance,
>
> Martin Benedix
>



-- 
http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com


Re: Axis2 simple http server memory management

2010-01-12 Thread Martin Benedix

Patrick Duflot schrieb:

Hi list,

I did a long-run test with the axis2 simple http server and the echo 
sample client invoking the echo service every 3 seconds.
I saw the memory usage going from 4MB to 30MB then back to 10MB and 
then again to 40MB. Now that I stopped the client from polling the 
service, memory usage is as low as 80KB.


NB : I am running Windows XP SP2

What is axis2 http server memory management policy ?
Can we have some control over it ?

A couple of related question :
How does it behaves with memory fragmentation ?
And the most importatnt one : Is Axis2 simple http server production 
ready ?


Thank you

Patrick


Hi Patrick, Hi list.

This are very important questions and I am also interested in the answers.
So I wrote this reply to bring the topic up again.
We are using the simple tcp server under linux and I experienced a growing
memory consumption using the echo service and a saturation on a level
at approximately 40 mb. I think that this is a result of the high watermark
memory usage strategy of linux.
I wanted to use valgrind on the simple tcp server and did not manage to get
any output from the tool.
What would be a good way to examine the memory usage behaviour of the
tcp server? Has anyone succeeded in using valgrind on the tcp server?
Any suggestion is highly welcome :)

Thanks in advance,

Martin Benedix


Axis2 simple http server memory management

2010-01-08 Thread Patrick Duflot
Hi list,

I did a long-run test with the axis2 simple http server and the echo sample
client invoking the echo service every 3 seconds.
I saw the memory usage going from 4MB to 30MB then back to 10MB and then
again to 40MB. Now that I stopped the client from polling the service,
memory usage is as low as 80KB.

NB : I am running Windows XP SP2

What is axis2 http server memory management policy ?
Can we have some control over it ?

A couple of related question :
How does it behaves with memory fragmentation ?
And the most importatnt one : Is Axis2 simple http server production ready ?

Thank you

Patrick


Re: client side memory management

2009-12-13 Thread Damitha Kumarage

Sam Carleton wrote:
I am looking at the hello.c sample and seeing a lot of things that are 
never freed.  I am also not seeing any rules stated on who is 
responsible for freeing memory on things. 

See whether this would help [1]

Thanks,
Damitha
[1] 
http://damithakumarage.wordpress.com/2009/03/07/memory-handling-conventions-in-axis2c/


For example, in the hello.c code an axis2_options_t *options is 
created but at no point is it freed.  Is it automatically freed 
when axutil_env_free() is called or is that an oversight in the example?  

Another example is in the build_om_request method, it looks like 
axiom_element_create() creates both the axiom_node_t* greet_om_node 
and axiom_element_t * greet_om_ele, but at no point do I see either 
being freed.  Does the axis2_svc_client_send_receive() free them or is 
this also an oversight in the example?


Sam



--
__

Damitha Kumarage
Technical Lead; WSO2 Inc.
"Oxygenating the Web Service Platform; " http://www.wso2.com/

blog: " http://damithakumarage.wordpress.com/
__


client side memory management

2009-12-13 Thread Sam Carleton
I am looking at the hello.c sample and seeing a lot of things that are never
freed.  I am also not seeing any rules stated on who is responsible for
freeing memory on things.

For example, in the hello.c code an axis2_options_t *options is created but
at no point is it freed.  Is it automatically freed when axutil_env_free()
is called or is that an oversight in the example?

Another example is in the build_om_request method, it looks like
axiom_element_create() creates both the axiom_node_t* greet_om_node
and axiom_element_t * greet_om_ele, but at no point do I see either being
freed.  Does the axis2_svc_client_send_receive() free them or is this also
an oversight in the example?

Sam


Re: Memory management in Axis2/C

2007-08-19 Thread Manjula Peiris
Hi Subra,

Please see my comments inline.

On Sun, 2007-08-19 at 20:11 -0400, Subra A Narayanan wrote:
> Hello everyone,
> 
> I had some very basic questions about memory management in Axis2/C and
> hope I can clarify my doubts with your help. I did go through the
> article on memory management => http://wso2.org/library/237 but still
> have some questions.
> 
> 1. I am working on a new webservice for which I just copied the 'math'
> service from the samples and have been just modifying it. In the 'add'
> operation of the 'math' service, there are some calls to
> axiom_element_get_text function which returns a const axis2_char_t* to
> retrieve the parameters from the soap xml document. Who is responsible
> for freeing up this memory? I assume since its const pointer and I
> didnt explicitly allocate memory, it will be clened up by the
> framework. But when does this happen? I looked at the math_free
> function in math_skeleton.c file but it doesn't tell me much. Is this
> when the clean up happens?
> 
> int AXIS2_CALL
> math_free(axis2_svc_skeleton_t *svc_skeleton,
> const axutil_env_t *env)
> 
> {
> if (svc_skeleton)
> {
> AXIS2_FREE(env->allocator, svc_skeleton);
> svc_skeleton = NULL;
> }
> return AXIS2_SUCCESS;
> }
Those will be freed from the framework when the corresponding om_tree is
freed for the soap xml document. But if you duplicate the text value
using axutil_strdup you need to free it by your own.


> 
> 
> 2. Is there any advantage in using the AXIS2_MALLOC over jus malloc?
> From my understanding, AXIS2_MALLOC just hides the env specific
> implementation of memory allocation. So if I am using 'C' either
> malloc or AXIS2_MALLOC are one and the same. Am I correct? On a
> similar note, is there any advantage in using axis2_char_t* over just
> char*? 
Yes there are advantages.  when using AXIS2_MALLOC you can plug
different mempry allocation mechanisms to Axis2/C. For example when
Axis2/C is used with Apache2 (httpd module) it uses httpd memory pools.
If you use malloc you can't get these advantages.

Using axis2_char also has the same advantage. You can plug different
charactor encoding systems using axis2_char.

-Manjula.


> 
> 
> I thank all of you for ur help and patience as I try to understand the
> Axis2 framework.
> 
> Subra


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Memory management in Axis2/C

2007-08-19 Thread Subra A Narayanan
Hello everyone,

I had some very basic questions about memory management in Axis2/C and hope
I can clarify my doubts with your help. I did go through the article on
memory management => http://wso2.org/library/237 but still have some
questions.

1. I am working on a new webservice for which I just copied the 'math'
service from the samples and have been just modifying it. In the 'add'
operation of the 'math' service, there are some calls to
axiom_element_get_text function which returns a const axis2_char_t* to
retrieve the parameters from the soap xml document. Who is responsible for
freeing up this memory? I assume since its const pointer and I didnt
explicitly allocate memory, it will be clened up by the framework. But when
does this happen? I looked at the math_free function in math_skeleton.c file
but it doesn't tell me much. Is this when the clean up happens?

 int AXIS2_CALL
math_free(axis2_svc_skeleton_t *svc_skeleton,
const axutil_env_t *env)
{
if (svc_skeleton)
{
AXIS2_FREE(env->allocator, svc_skeleton);
svc_skeleton = NULL;
}
return AXIS2_SUCCESS;
}



2. Is there any advantage in using the AXIS2_MALLOC over jus malloc? From my
understanding, AXIS2_MALLOC just hides the env specific implementation of
memory allocation. So if I am using 'C' either malloc or AXIS2_MALLOC are
one and the same. Am I correct? On a similar note, is there any advantage in
using axis2_char_t* over just char*?


I thank all of you for ur help and patience as I try to understand the Axis2
framework.

Subra


Re: [AXIS2C] memory management

2007-06-19 Thread Dr. Florian Steinborn

Hi Samisa,




3. Do I understand correctly, nobody else frees the memory if not the  
user does it? Cannot imagine that - all the generated services would be  
giantic memory holes...
The model is that the user got to free it. The notion of "user got to  
free it" makes sense, as the user has control over the lifetime of the  
struct instance.


I think we had a misunderstanding. Of course the user has to free the  
memory that he allocates.
I had a deeper look into the generated free-functions and see that the  
axis2_skel__getString method is called in the "invoke" part  
and the memory is freed by the automatic call of  axis2_getString_free().  
If there is additional memory allocated by the user he has to free it  
himself.

I see.
Thanks,

Flori


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [AXIS2C] memory management

2007-06-19 Thread Samisa Abeysinghe

Dr. Florian Steinborn wrote:

Thanks for the answers - unfortunately it raises more questions...

1. "deep copy" - should this mean to really copy something (by 
allocating new memory) and not just let a pointer to point to a 
certain piece of memory?

Yes.


2. The function axis2_getStringResponse_set_return() is generated. The 
generated function can be seen here.


/**
  * setter for return
*/
axis2_status_t AXIS2_CALL
axis2_getStringResponse_set_return(
   axis2_getStringResponse_t* getStringResponse,
   const axutil_env_t *env,
   axis2_char_t*  param_return)
{

  AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
  if(!getStringResponse)
  {
  return AXIS2_FAILURE;
  }
  getStringResponse-> attrib_return = param_return;
  return AXIS2_SUCCESS;
}

The assignment of param_return does not look like a "deep copy", right? 

Yes it is a shallow copy.
As far as I understood, the only files that have to be touched after 
generation are the axis2_skel_.c files for the business logic...


3. Do I understand correctly, nobody else frees the memory if not the 
user does it? Cannot imagine that - all the generated services would 
be giantic memory holes...
The model is that the user got to free it. The notion of "user got to 
free it" makes sense, as the user has control over the lifetime of the 
struct instance.



4. Does someone have a reference implementation of a "deep copy" to 
look at?
The generated code is correct. What you have to do is to manage the 
memory in the business logic implementation.
In case of code generation, what can be done is to have a free method 
for axis2_getStringResponse_t struct. Then once you call 
axis2_skel__getString method, get the 
axis2_getStringResponse_t instance and use it, free the 
axis2_getStringResponse_t instance, which would free the members of the 
axis2_getStringResponse_t struct.


Samisa...



Thanks,
Flori


On Tue, 19 Jun 2007 07:51:31 +0200, Samisa Abeysinghe 
<[EMAIL PROTECTED]> wrote:



Shailesh Srivastava wrote:

Once the response string is formed, you need to free the local memory
allocated to "retVal".

If axis2_getStringResponse_set_return method does a deep copy you can 
free retVal. This should ideally be freed by 
axis2_getStringResponse_free method, that is to be called by user.


Samisa...


[...]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services 
Developers' Portal)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [AXIS2C] memory management

2007-06-19 Thread Dr. Florian Steinborn

Thanks for the answers - unfortunately it raises more questions...

1. "deep copy" - should this mean to really copy something (by allocating  
new memory) and not just let a pointer to point to a certain piece of  
memory?


2. The function axis2_getStringResponse_set_return() is generated. The  
generated function can be seen here.


/**
  * setter for return
*/
axis2_status_t AXIS2_CALL
axis2_getStringResponse_set_return(
   axis2_getStringResponse_t* getStringResponse,
   const axutil_env_t *env,
   axis2_char_t*  param_return)
{

  AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
  if(!getStringResponse)
  {
  return AXIS2_FAILURE;
  }
  getStringResponse-> attrib_return = param_return;
  return AXIS2_SUCCESS;
}

The assignment of param_return does not look like a "deep copy", right? As  
far as I understood, the only files that have to be touched after  
generation are the axis2_skel_.c files for the business logic...


3. Do I understand correctly, nobody else frees the memory if not the user  
does it? Cannot imagine that - all the generated services would be giantic  
memory holes...



4. Does someone have a reference implementation of a "deep copy" to look  
at?


Thanks,
Flori


On Tue, 19 Jun 2007 07:51:31 +0200, Samisa Abeysinghe <[EMAIL PROTECTED]>  
wrote:



Shailesh Srivastava wrote:

Once the response string is formed, you need to free the local memory
allocated to "retVal".

If axis2_getStringResponse_set_return method does a deep copy you can  
free retVal. This should ideally be freed by  
axis2_getStringResponse_free method, that is to be called by user.


Samisa...


[...]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [AXIS2C] memory management

2007-06-18 Thread Samisa Abeysinghe

Shailesh Srivastava wrote:

Once the response string is formed, you need to free the local memory
allocated to "retVal".
  
If axis2_getStringResponse_set_return method does a deep copy you can 
free retVal. This should ideally be freed by 
axis2_getStringResponse_free method, that is to be called by user.


Samisa...

-Original Message-
From: Dr. Florian Steinborn [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 18, 2007 6:47 PM

To: axis-c-user@ws.apache.org
Subject: [AXIS2C] memory management

Hi friends,

just a "simple" question...
When you define a webservice that has an operation that returns a
string,  
you probably will get a generated function similiar to this:


/* starts here */

axis2_getStringResponse_t*
axis2_skel__getString ( const axutil_env_t *env  ,
 axis2_getString_t* getString )
{
 axis2_getStringResponse_t*  getStringRes = NULL;
 axis2_char_t*   retVal = NULL ;

 retVal = (axis2_char_t*) malloc( sizeof(char) * 20);
 strncpy( retVal, "NONSENS", 20);



 getStringRes = axis2_getStringResponse_create( env);
 axis2_getStringResponse_set_return( getStringRes, env, retVal) ;

 return getStringRes;

}

/* ends here */

The big question is: who cares for the memory allocated in "retVal" ? Do
I  
have to free it or is it freed automatically by the Axis2 machine after


serializing the answer? A small string may not be interesting but when
you  
have to fill structs or arrays of structs... ?


Thanks,

Flori

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



--
Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services 
Developers' Portal)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [AXIS2C] memory management

2007-06-18 Thread Shailesh Srivastava
Once the response string is formed, you need to free the local memory
allocated to "retVal".

-Original Message-
From: Dr. Florian Steinborn [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 18, 2007 6:47 PM
To: axis-c-user@ws.apache.org
Subject: [AXIS2C] memory management

Hi friends,

just a "simple" question...
When you define a webservice that has an operation that returns a
string,  
you probably will get a generated function similiar to this:

/* starts here */

axis2_getStringResponse_t*
axis2_skel__getString ( const axutil_env_t *env  ,
 axis2_getString_t* getString )
{
 axis2_getStringResponse_t*  getStringRes = NULL;
 axis2_char_t*   retVal = NULL ;

 retVal = (axis2_char_t*) malloc( sizeof(char) * 20);
 strncpy( retVal, "NONSENS", 20);



 getStringRes = axis2_getStringResponse_create( env);
 axis2_getStringResponse_set_return( getStringRes, env, retVal) ;

 return getStringRes;

}

/* ends here */

The big question is: who cares for the memory allocated in "retVal" ? Do
I  
have to free it or is it freed automatically by the Axis2 machine after

serializing the answer? A small string may not be interesting but when
you  
have to fill structs or arrays of structs... ?

Thanks,

Flori

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[AXIS2C] memory management

2007-06-18 Thread Dr. Florian Steinborn

Hi friends,

just a "simple" question...
When you define a webservice that has an operation that returns a string,  
you probably will get a generated function similiar to this:


/* starts here */

axis2_getStringResponse_t*
axis2_skel__getString ( const axutil_env_t *env  ,
axis2_getString_t* getString )
{
axis2_getStringResponse_t*  getStringRes = NULL;
axis2_char_t*   retVal = NULL ;

retVal = (axis2_char_t*) malloc( sizeof(char) * 20);
strncpy( retVal, "NONSENS", 20);



getStringRes = axis2_getStringResponse_create( env);
axis2_getStringResponse_set_return( getStringRes, env, retVal) ;

return getStringRes;

}

/* ends here */

The big question is: who cares for the memory allocated in "retVal" ? Do I  
have to free it or is it freed automatically by the Axis2 machine after  
serializing the answer? A small string may not be interesting but when you  
have to fill structs or arrays of structs... ?


Thanks,

Flori

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Memory management

2005-12-11 Thread Duane Murphy
I'll just toss in my two cents. Maybe it will help in the future.

As you can see, dealing with value types makes things easy. You can
still deal in value types for complex types by using either smart
pointers or some other kind of managed class.

One of the most common problems with programs today is memory
management. Fortunately this is pretty easily fixed by using smart
pointers or other value type wrapper classes (e.g. std::string).

Maybe this will help in the future.

 ...Duane

--- At Mon, 12 Dec 2005 07:35:13 +0600, Samisa Abeysinghe wrote:

>John Hawkins wrote:
>
>>
>> I'm going to put this onto the web-site in the next few days but sneak 
>> preview ->
>>
>> Many Web Services Client for C++ methods either expect or create 
>> memory objects.
>> Below is a list of rules that you must follow when developing web 
>> service client applications:
>> v Any memory object that is passed to Web Services Client for C++ does 
>> not need to persist past the method for which it was required and 
>> should be deleted at the earliest opportunity.
>> v Any memory object created and returned by Web Services Client for 
>> C++ should be deleted by the client application before the deletion of 
>> the web service that created it. Note that Windows requires that the 
>> memory object be deleted from within the thread that created it, 
>> otherwise you may get an out of bounds exception type error from the 
>> core C++ libraries.
>> v Any object passed by reference (rather than value) that is used by 
>> Web Services Client for C++ must be created using new, and destroyed 
>> using delete.
>> v Once an object has been deleted, its pointer must be set to NULL 
>> (this is to ensure that the pointer is not used elsewhere).
>
>Hi John,
>Would it be useful to have some information included into this list 
>on what types of return values returned by clients are expected to be 
>deleted?
>e.g. All complex types returned are allocated by the client stub and 
>should be deleted by the user program. The destructor of the complex 
>type would take care of its members. All basic types are returned by 
>value and thus need no memory cleaning.
>  All nillable values are returned as pointers, and thus should 
>be cleaned by calling program.
>  Also, what happens with arrays, I think you have changed the 
>memory model for this by now.
>Would the above make sense?
>
>Thanks,
>Samisa..
>
>>
>>
>>
>>
>> *"Stettler, Robert" <[EMAIL PROTECTED]>*
>>
>> 08/12/2005 20:17
>> Please respond to
>> "Apache AXIS C User List"
>>
>>
>>  
>> To
>>  
>> cc
>>  
>> Subject
>>  Memory management
>>
>>
>>
>>  
>>
>>
>>
>>
>>
>> Does the client need to delete the memory associated with the return 
>> objects returned by the generated webservice methods?  Or is the 
>> memory managed by the axis?
>>  
>>  
>>
>>
>>
>>
>> The information contained in this e-mail is confidential and/or 
>> proprietary
>> to Capital One and/or its affiliates. The information transmitted herewith
>> is intended only for use by the individual or entity to which it is
>> addressed.  If the reader of this message is not the intended recipient,
>> you are hereby notified that any review, retransmission, dissemination,
>> distribution, copying or other use of, or taking of any action in 
>> reliance
>> upon this information is strictly prohibited. If you have received this
>> communication in error, please contact the sender and delete the material
>> from your computer.
>>
>

 ...Duane



Re: Memory management

2005-12-11 Thread Samisa Abeysinghe

John Hawkins wrote:



I'm going to put this onto the web-site in the next few days but sneak 
preview ->


Many Web Services Client for C++ methods either expect or create 
memory objects.
Below is a list of rules that you must follow when developing web 
service client applications:
v Any memory object that is passed to Web Services Client for C++ does 
not need to persist past the method for which it was required and 
should be deleted at the earliest opportunity.
v Any memory object created and returned by Web Services Client for 
C++ should be deleted by the client application before the deletion of 
the web service that created it. Note that Windows requires that the 
memory object be deleted from within the thread that created it, 
otherwise you may get an out of bounds exception type error from the 
core C++ libraries.
v Any object passed by reference (rather than value) that is used by 
Web Services Client for C++ must be created using new, and destroyed 
using delete.
v Once an object has been deleted, its pointer must be set to NULL 
(this is to ensure that the pointer is not used elsewhere).


Hi John,
   Would it be useful to have some information included into this list 
on what types of return values returned by clients are expected to be 
deleted?
   e.g. All complex types returned are allocated by the client stub and 
should be deleted by the user program. The destructor of the complex 
type would take care of its members. All basic types are returned by 
value and thus need no memory cleaning.
 All nillable values are returned as pointers, and thus should 
be cleaned by calling program.
 Also, what happens with arrays, I think you have changed the 
memory model for this by now.

   Would the above make sense?

Thanks,
Samisa..






*"Stettler, Robert" <[EMAIL PROTECTED]>*

08/12/2005 20:17
Please respond to
"Apache AXIS C User List"



To
    
cc

Subject
Memory management









Does the client need to delete the memory associated with the return 
objects returned by the generated webservice methods?  Or is the 
memory managed by the axis?
 
 





The information contained in this e-mail is confidential and/or 
proprietary

to Capital One and/or its affiliates. The information transmitted herewith
is intended only for use by the individual or entity to which it is
addressed.  If the reader of this message is not the intended recipient,
you are hereby notified that any review, retransmission, dissemination,
distribution, copying or other use of, or taking of any action in 
reliance

upon this information is strictly prohibited. If you have received this
communication in error, please contact the sender and delete the material
from your computer.





Re: Memory management

2005-12-09 Thread John Hawkins

I'm going to put this onto the web-site
in the next few days but sneak preview ->

Many Web Services Client for C++ methods
either expect or create memory objects. 
Below is a list of rules that you must
follow when developing web service client applications: 
v Any memory object that is passed to
Web Services Client for C++ does not need to persist past the method for
which it was required and should be deleted at the earliest opportunity.

v Any memory object created and returned
by Web Services Client for C++ should be deleted by the client application
before the deletion of the web service that created it. Note that Windows
requires that the memory object be deleted from within the thread that
created it, otherwise you may get an out of bounds exception type error
from the core C++ libraries. 
v Any object passed by reference (rather
than value) that is used by Web Services Client for C++ must be created
using new, and destroyed using delete. 
v Once an object has been deleted, its
pointer must be set to NULL (this is to ensure that the pointer is not
used elsewhere).







"Stettler, Robert"
<[EMAIL PROTECTED]> 
08/12/2005 20:17



Please respond to
"Apache AXIS C User List"





To



cc



Subject
Memory management








Does the client need to delete the memory
associated with the return objects returned by the generated webservice
methods?  Or is the memory managed by the axis?
 
 



The information contained in this e-mail is confidential and/or proprietary
to Capital One and/or its affiliates. The information transmitted herewith
is intended only for use by the individual or entity to which it is 
addressed.  If the reader of this message is not the intended recipient,

you are hereby notified that any review, retransmission, dissemination,

distribution, copying or other use of, or taking of any action in reliance

upon this information is strictly prohibited. If you have received this

communication in error, please contact the sender and delete the material

from your computer.




Memory management

2005-12-08 Thread Stettler, Robert








Does the client need to delete the memory associated with
the return objects returned by the generated webservice methods?  Or is the
memory managed by the axis?

 

 






The information contained in this e-mail is confidential and/or proprietary
to Capital One and/or its affiliates. The information transmitted herewith
is intended only for use by the individual or entity to which it is 
addressed.  If the reader of this message is not the intended recipient, 
you are hereby notified that any review, retransmission, dissemination, 
distribution, copying or other use of, or taking of any action in reliance 
upon this information is strictly prohibited. If you have received this 
communication in error, please contact the sender and delete the material 
from your computer.