axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <>
Subject Re: Memory for headerblocks
Date Tue, 10 Aug 2004 19:27:24 GMT

Hmm, could the fini method on the handler be used ? Can the writer of the
handler use this method to destruct the objects they created? The comments
say that the fini method is used when the handler is to be unloaded but in
what sense is "unloaded" used? From what I can tell it means when there is
an error on use or loading of the handler rather than when a handler is
destructed - but I might be missing a layer of abstraction - anyone know?

What I also need to understand is how the handlerpool works. I think I can
see/guess that it stores handlers for reuse if a service is called multiple
times - yes? In which case fini might not be the right method and maybe I
need to add an extra method to handler e.g. postInvoke() which tells them
that it's safe to go clean up their memory?

So, my ramblings lead me to these questions:

1) can we put back the original memory management we had for handler and
stub created headerblock children?
2) If not then can I tell the user to overwrite the fini method?
3) If not then can I create a new method on Handler called e.g.
postInvoke() which gets called immediately the handler can destruct their
memory e.g. after the call is completed?

thanks folks,
this is a big area - so all the help you can give is appreciated :-)

John Hawkins

             MGB                                                        To 
             10/08/2004 13:29                                           cc 
             Please respond to         Memory for headerblocks             
              "Apache AXIS C                                               
             Developers List"                                              

Hi Folks,

Can some one help me understand the design here please.

Deletion of Soap headerblocks ->

Given this bit of handler code (which is a fairly obvious thing to do in a
handler )

             BasicNode *pChildNode;
             BasicNode *pChildNodeValue;

             pChildNode = hdrBlock.createChild(ELEMENT_NODE);

             pChildNodeValue = hdrBlock.createChild(CHARACTER_NODE);

             delete pChildNode;    // ************************ //

When I put "delete pChildNode" at the end of the code snippet, the
<myprefix:accountId> node did not show up in the TCP/IP trace.  If I did
have it there, the node came out.

So, this is something that I would expect NOT to happen. Why aren't we
deleting the headerblocks is the question? What is a user supposed to do in
this situation. If I'm thinking straight they are going to have to keep a
list of their added headerblocks outside of their handler and then know
when to delete them ? If this is true then its real yucky The code for
SoapHeader destructor reads ->
     * header blocks are not deleted here any more. Its the responsibility
     * either a handler or stub etc to delete any header block created by
    list<IHeaderBlock*>::iterator itCurrHeaderBlock=

    while(itCurrHeaderBlock != m_headerBlocks.end())
        delete *itCurrHeaderBlock;

So, I can see that maybe if you are in a stub and you create the header
block then you might want to reuse the header block? So, perhaps we should
have a smarter SoapHeader destructor? One that looks at a flag which tells
it where it was created? I know this is also yuck but it gets me out of
this handler based memory problem.

Any thoughts?


View raw message