Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Subject: Re: Memory for headerblocks
From: Roshan Weerasuriya <roshan@opensource.lk>
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
In-Reply-To: 
 <OF9127F908.09EFCCAD-ON80256EF3.00434426-80256EF3.00439885@uk.ibm.com>
References: 
	 <OF9127F908.09EFCCAD-ON80256EF3.00434426-80256EF3.00439885@uk.ibm.com>
Content-Type: text/plain
Organization: 
Message-Id: <1092834124.1187.12.camel@localhost.localdomain>
Mime-Version: 1.0
Date: 18 Aug 2004 19:02:04 +0600
Content-Transfer-Encoding: 7bit

hi John,

In first place the "fini" method is intended to be used for this purpose
of memory clean up.

I went into the code and figured out that the Handlers "fini()" method
is called when the Handlers are pooled back to the Handler pool. (i.e
after using it Handlers are pooled back and then the fini method is
called just before pooling). This code is fully implemented at
ServerAxisEngine. So it is sure that if is is a server side Handler then
the fini is caled.

The same method is also available at ClientAixsEngine but is removed
(actualy commented) for some reson. I will have to figure this out (i.e
why it is removed at the Client engine), and come back to you.

But my feeling is that the "fini" method is used for this purpose.

Roshan

On Tue, 2004-08-17 at 18:18, John Hawkins wrote: 
> 
> Hi Folks,
> 
> Based on no body having a conclusive answer to this issue we are going to
> implement a memory management model such that the handlers "fini" method
> gets called just after they have been invoked in
> AxisClientEngine::Invoke().
> 
> Whether fini is or is not the correct method to use is not obvious but
> we'll try it and see what happens ! The alternative is to add another
> method to the handlers which we would prefer not to do.
> 
> If anyone knows better then please shout now :-)
> 
> 
> thanks,
> John.
> 
> 
> 
> 
> 
> 
> 
>                                                                            
>              Fred                                                          
>              Preston/UK/IBM@IB                                             
>              MGB                                                        To 
>                                        "Apache AXIS C Developers List"     
>              12/08/2004 11:55          <axis-c-dev@ws.apache.org>          
>                                                                         cc 
>                                                                            
>              Please respond to                                     Subject 
>               "Apache AXIS C           Re: Memory for headerblocks         
>              Developers List"                                              
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
> 
> 
> 
> 
> 
> 
> 
> 
> 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.
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
>