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 John Hawkins <HA...@uk.ibm.com> on 2004/08/10 14:29:28 UTC
Memory for headerblocks
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.
Re: Memory for headerblocks
Posted by Roshan Weerasuriya <ro...@opensource.lk>.
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.
>
>
>
>
>
>
>
Re: Memory for headerblocks
Posted by John Hawkins <HA...@uk.ibm.com>.
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.