does ice have an internal memory monitoring mechanism similar to a COM reference counter ?

[Fireshtorm1k]

How to delete unused objects on server.

Example:

interface Object
{
  void setInt(int value); //just for example
  int getInt();
};
interface Objects
{
  Object createObject();
};

ObjectPrx ObjectsI::createObject(const Ice::Current& c)
{
	ObjectPrx proxy = ObjectsPrx::uncheckedCast(c.adapter->addWithUUID(new ObjectI));
	return proxy;
}

And after 2 clients used createObject(), one immideatly disconnects, how i can properly destroy Object that client created on server ? Can i do it automatically or maybe on server i can check which objects are occupied by clients and which are not.

UPD:
I know about ConnectionCloseCallback, and can do something like:

class Callback : Ice::CloseCallback
{
    void closed(const ConnectionPtr& con) override
    {
        //destroy object here
    }
}

but there can be this situation:

interface Object
{
  void setInt(int value);
  int getInt();
};
interface Objects
{
  Object createObject();
  Object getItem(int index);
};

Client 1 connects and invokes createObject()
Client 2 use getItem(1);
Client 1 disconnects, and Object 1 destroys.

How i can resolve this situation. The brain is boiling

[pepone]

Hi,

Ice does not provide a built-in mechanism for this. We typically recommend using a per-client session approach. The session can clean up the user resources once it become inactive.

You can find a demo illustrating this technique at Ice session demo.

[Fireshtorm1k]

But what about

Client 1 connects and invokes createObject()
Client 2 use getItem(1);
Client 1 disconnects, and Object 1 destroys.

Client 2 want to use Object that Client 1 created, but session is linked with first client, and will be destroyed when first client disconnects.

I think one solution would be a reference counter in getSession() or something similar

[bernardnormier]

Another common solution is to not create servants (or services with IceRPC's terminology) after start-up. Your server just creates one or more servants at startup and that's it.

Naturally, a server may still want to allocate some resources on behalf of a client (keep some "session data" in memory for each client).

As @pepone commented, the typical solution is to associate this data with a session and clean it up when the session dies. And the simplest form of session is a connection: session lifetime = connection lifetime.

Having just a fixed set of servants doesn't mean the server can't return new proxies from factory operations. For example:

interface WidgetFactory
{
    Widget* createWidget(string forClient);
}

can return thousands of Widget proxies, all implemented by the same (default) servant.