Index
stasher::manager->manage_subscriptionstasher::manager->manage_objectstasher::manager->manage_hierarchymonitorstasher::manager->manage_serverstatusupdates
As mentioned in the section called “stasher::client->subscribe
A manager object implements enhanced object and hierarchy subscriptions, then sets a timer when they get cancelled (one minute, by default). After the timer expires, the manager tries to reestablish the subscription (which makes another connection attempt to the server, if necessary).
stasher::manager manager=stasher::manager::create();
This creates a
stasher::manager,
an x::ref. The retry interval gets set by
the property “objrepo::manager”, with the
default value of one minute.
The entire application can use a single manager object, or different manager objects, there is no particular advantage, except that each manager instance can use a different timeout interval.
stasher::manager manager=stasher::manager::create(L"retry", "10 seconds");
This example creates a manager that uses the
“objrepo::manager” property, with a
ten second default value. The first parameter is the property name,
as a wide string. The second parameter is an x::hms,
which can be initialized from a literal string.
A manager can manage objects and subscriptions from the same or different client connections.
If a manager object goes out of scope and gets destroyed, all managed objects and subscriptions no longer get managed. They're all LIBCXX's reference counted objects, and as long as a strong reference to them remains in scope, somewhere, they'll still exist, but won't be of much use. It's expected that a manager object will “live nearby” everything that it manages.
It doesn't matter whether the manager or its managed object goes out of scope and get destroyed first. Note, though, that managed objects maintain a strong reference to their client connection object, as a necessity, so they must go out of scope and get destroyed before the application's client connection handle.