axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Whitlock <mark_whitl...@uk.ibm.com>
Subject Fw: Memory for headerblocks
Date Wed, 18 Aug 2004 11:17:51 GMT




Hi,
Another way of solving this problem would be to have the class that issues
the new also issue the delete. So as
HeaderBlock::createChild new's the child, ~HeaderBlock should also delete
its children. It is really SoapSerializer
that new's the HeaderBlock, so ~SoapSerializer would delete it. This
simplifies user-written handlers having to
delete their HeaderBlocks (and probably forgetting to do so).

Clients would have to clone any HeaderBlock they wanted to reuse. There is
already a clone() method on
HeaderBlock which doesn't look too expensive.

Underlying all this, there is another problem that I've being trying to
understand. I wanted to find out the lifetime
of the HeaderBlock since if the SoapSerializer lived across many web
service invocations, the client application
could simply reuse the HeaderBlock without having to clone it.

The SerializerPool is a global referenced from g_pSerializerPool and is
new'ed during the Call constructor. It seems
that a client application that creates stubs up front and then uses them
later would fail because the 2nd time
the Call constructor is invoked it would overwrite the globals the 1st Call
constructor set up. An application that
invokes web services from multiple threads at the same time would fail for
the same reason.

g_pSerializerPool gets deleted in ModuleUnInitialize() which is only called
from the SimpleAxisServer. So a client
application that creates, uses and deletes Stubs would leak memory since
these globals never get deleted.

The solution to the original HeaderBlock memory problem (which would also
fix all these other problems as well)
could be for ModuleInitialize to be aware that the globals may have already
been initialised by a previous Call and
to share and keep a count on how many Call's are using these globals. Then
the last Call to be deleted really deletes
all the globals and sets them to null. That way a SerializerPool and a
SoapSerializer could live across many web
service invocations and ~SoapSerializer could delete its HeaderBlocks when
the client application deletes its
last Stub.

Whichever solution is adopted, the sharing and deleting of globals appears
to be a bug which I'll raise on jira.

Mark Whitlock

====================================================================================


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.
>
>
>
>
>
>
>








Mime
View raw message