axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Preston <PREST...@uk.ibm.com>
Subject Re: Memory for headerblocks
Date Thu, 12 Aug 2004 10:55:09 GMT




Hi Roshan,
      Have you been able to make any more progress on this problem?

Regards,

Fred Preston.
Software Engineer
Business Integration

Mail Point 188,  IBM Hursley Park
Winchester, Hampshire, SO21 2JN, UK
Notes id:    Fred Preston/UK/IBM @ IBMGB
Internet:      prestonf@uk.ibm.com
Tel:             +44 1962 817180
Internal:      247180



                                                                                         
                                             
                      Roshan                                                             
                                             
                      Weerasuriya              To:       Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
                     
                      <roshan@opensourc        cc:                                    
                                                
                      e.lk>                    Subject:  Re: Memory for headerblocks  
                                                
                                                                                         
                                             
                      11/08/04 14:30                                                     
                                             
                      Please respond to                                                  
                                             
                      "Apache AXIS C                                                     
                                             
                      Developers List"                                                   
                                             
                                                                                         
                                             
                                                                                         
                                             



hi John,

>              hdrBlock.addChild(pChildNode);
>              delete pChildNode;    // ************************ //
>

You can't delete this "pChildNode" at this point since the child node is
not yet being serialized and need to be available for the same.

>SoapHeader::~SoapHeader()
> {
>     /*
>      * header blocks are not deleted here any more. Its the
responsibility
> of
>      * either a handler or stub etc to delete any header block created by
> them
>      */
>     /*
>     list<IHeaderBlock*>::iterator itCurrHeaderBlock=
> m_headerBlocks.begin();
>
>     while(itCurrHeaderBlock != m_headerBlocks.end())
>     {
>         delete *itCurrHeaderBlock;
>         itCurrHeaderBlock++;
>     }
>     */

This is done due to the fact that the client stub might need to reuse
the same HeaderBlock for multiple service requests (Actualy the reson
for removing the code (actualy it is still commented) from the Destrctor
of the SoapHeader is this). At the client if you create the HeaderBlock
using the Stub, this works fine (this is not a problme) since at the
Destructor of the Stub base class it takes care of releasing the
allocated memory for the HeaderBlocks.

But as you point the issue is if you create a the SOAP Headers using a
Handler. But I think the "fini()" method of a Handler can be used to
release the memory allocated by the Handler for the HeaderBolocks.
(Actualy here if you delete the relavent HeaderBlock then it deletes all
its childrens which are Complex and Character Elements). I just had a
quick look at the engine code to see whether the "fini()" method is
called when the handler is pooled but I don't see as if it is done. I
will have to check a litte abt this and come back to you. But my feeling
is that this releasing of memory has to be done at the "fini()" method.
I will have to check this and come back to you.

rgds,
Roshan

On Wed, 2004-08-11 at 01:27, John Hawkins wrote:
>
>
> 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
>
>
>
>
>

>              John

>              Hawkins/UK/IBM@IB

>              MGB
To
>                                        axis-c-dev@ws.apache.org

>              10/08/2004 13:29
cc
>

>
Subject
>              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);
>              pChildNode->setLocalName("accountId");
>              pChildNode->setPrefix("myprefix");
>
>              pChildNodeValue = hdrBlock.createChild(CHARACTER_NODE);
>              pChildNodeValue->setValue("12349999");
>              pChildNode->addChild(pChildNodeValue);
>
>              hdrBlock.addChild(pChildNode);
>              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
> not
> 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 ->
> SoapHeader::~SoapHeader()
> {
>     /*
>      * header blocks are not deleted here any more. Its the
responsibility
> of
>      * either a handler or stub etc to delete any header block created by
> them
>      */
>     /*
>     list<IHeaderBlock*>::iterator itCurrHeaderBlock=
> m_headerBlocks.begin();
>
>     while(itCurrHeaderBlock != m_headerBlocks.end())
>     {
>         delete *itCurrHeaderBlock;
>         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?
>
> thankyou,
> John.
>
>
>
>
>
>
>





Mime
View raw message