[omniORB] Memory leak related to Proxy Object Factories

[Tuyen Chau]

Duncan Grisby wrote:
> Most likely, you were unlucky and the 1 second timeout expired before
> omniORB tried to call a method on the object. That would explain the
> pure virtual method called error you see. I don't think your approach is
> at all safe.
>
> Why are you returning cached object references?  I was assuming that it
> was to avoid the overhead of constructing new ones, but if you consider
> it acceptable to create a new one then immediately delete it again, that
> can't be the reason. So you must be doing it to share some state between
> them. Rather than trying to fight omniORB's desire to create new
> objrefs, why don't you put whatever shared state you have into a
> sub-object that is shared between all the objrefs that omniORB creates.
> That way you can do whatever it is you need without having to subvert
> what omniORB tries to do.
>
> Cheers,
>
> Duncan.
>
>   
Thanks for your clarification, Duncan.  You are right that we are not 
concerned about the overhead of constructing new objrefs.  We are 
caching non-dynamic data in the proxies and don't want to go and fetch 
it from the server every time we need to create an objref.  In addition, 
we are also storing our own client data in the proxies that can't be 
easily recreated.

We can cache data in a different way without storing it in the proxies 
as you suggested, but we couldn't afford the work at this time.  We are 
porting our code from Orbix, and did not want to change more code than 
necessary to avoid introducing defects into the product.  In general, we 
are happy with omniORB but there's always surprises that we need to sort 
out on how to deal with them.

We ended up changing omniORB to properly fix the memory leak.  Our code 
in omniInternal.cc now looks like this:

  {
    omni_optional_lock sync(*internalLock, locked, locked);

    // If the objref already has a different identity, release the
    // new one.  This can happen if a custom pof wants to reuse
    // an objref. (Verano patch for memory leak)
    //
    if (objref->pd_id == id) {
      id->gainRef(objref);
    } else {
      ior->release();
      id->loseRef(NULL);
    }
  }

We figured the mutex call in here is what killed the 1 second timeout, 
and gave up on that work-around.

Does this look like code that you can incorporate into future releases 
of omniORB?  We would be happy if you could do that so we don't need to 
maintain a separate version for it. We think that people who come from a 
different implementation of CORBA like Orbix, would probably require the 
unique objref feature like we do.  This would make it easier for them to 
migrate to omniORB.  If you can think of a better way to rewrite the 
code above, please let us know too.

Best regards,
Tuyen