Date: Thu, 28 Mar 2024 16:35:43 +0000 (UTC) Message-ID: <188221141.24573.1711643743801@ae5f4610bf64> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_24572_1427197027.1711643743801" ------=_Part_24572_1427197027.1711643743801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The main entry point to the Ice run time is represented by the l=
ocal interface Ice::Communicator
. An instance of Ice::Co=
mmunicator
is associated with a number of run-time resources:
Ice::Logger
interface and determines how log messages that=
are produced by the Ice run time are handled.Ice::Router
interface. Routers are us=
ed by Glacier2 to implement the fir=
ewall functionality of Ice.Ice::PluginManage=
r
interface and provides access to the set of plug-ins for a communi=
cator.Object adapters and objects that use different communicators are complet= ely independent from each other. Specifically:
Typically, servers use only a single communicator but, occasionally, mul= tiple communicators can be useful. For example, IceBox, uses a separate communicator for each Ice service it loa= ds to ensure that different services cannot interfere with each other. Mult= iple communicators are also useful to avoid thread starvation: if one servi= ce runs out of threads, this leaves the remaining services unaffected.
<= br> The communicator's interface is defined in Slice. Part of this interface l= ooks as follows:
module Ice { local interface Communicator { string proxyToString(O= bject* obj); Object* stringToProxy(= string str); PropertyDict proxyToPr= operty(Object* proxy, string property); Object* propertyToProx= y(string property); Identity stringToIdent= ity(string str); string identityToStrin= g(Identity id); ObjectAdapter createOb= jectAdapter(string name); ObjectAdapter createOb= jectAdapterWithEndpoints(string name, string endpoints); ObjectAdapter createOb= jectAdapterWithRouter(string name, Router* rtr); void shutdown(); void waitForShutdown()= ; bool isShutdown(); void destroy(); // ... }; // ... };
The communicator offers a number of operations:
proxyToString
stringToProxy
proxyToString
on th=
e communicator, you can also use the ice_toString
proxy method to stringify it. However, you=
can only stringify non-null proxies that way =E2=80=94 to stringify a null=
proxy, you must use proxyToString
. (The stringified represent=
ation of a null proxy is the empty string.)proxyToProperty
propertyToProxy
proxyToPrope=
rty
returns the set of =
proxy properties for the supplied proxy. The property
para=
meter specifies the base name for the properties in the returned set. propertyToProxy
retrie=
ves the configuration property with the given name and converts its val=
ue into a proxy. A null proxy is returned if no property is found with the =
specified name.identityToString
stringToIdentity
createObjectAdapter
createObjectAdapterWithEndpoi=
nts
createObjectAdapterWithRouter
createObjectAdapter
determines its transport endpoint=
s from configuration information, createObjectAdapterWithEndpoints allows you to supply the transport endpoints for the new adapter. Typi=
cally, you should use createObjectAdapter
in preference to createObjectAdapterWithEndpoints
. Doing so keeps transport-specif=
ic information, such as host names and port numbers, out of the source code=
and allows you to reconfigure the application by changing a property (and =
so avoid recompilation when a transport endpoint needs to be changed). createO=
bjectAdapterWithRouter
creates a routed object adapter that allows c=
lients to receive callbacks from servers that are behind a router. Ice.Warn.Unkn=
ownProperties
.shutdown
shutdown=
code> is called are allowed to complete normally. shutdown
doe=
s not wait for these operations to complete; when shutdown=
code> returns, you know that no new incoming requests will be dispatched, b=
ut operations that were already in progress at the time you called sh=
utdown
may still be running. You can wait for still-executing operat=
ions to complete by calling waitForShutdown
.
shu=
tdown
either fail with a ConnectFailedException
or are =
transparently redirected to a new instance of the server (via IceGrid).shutdown
initiates deactivation of all object ad=
apters associated with the communicator, so attempts to use an adapter once=
shutdown
has completed raise an ObjectAdapterDeactivate=
dException
.waitForShutdown
waitForShutdown
simply waits until anothe=
r thread has called shutdown
or destroy
.isShutdown
shutdown
has been invoked on t=
he communicator. A return value of true does not necessarily indicate that =
the shutdown process has completed, only that it has been initiated. An app=
lication that needs to know whether shutdown is complete can call wai=
tForShutdown
. If the blocking nature of waitForShutdown
=
is undesirable, the application can invoke it from a separate thread.destroy
destroy
before you leave the <=
code>main function of your program. Failure to do so results in unde=
fined behavior. destroy
before leaving main
is necessary=
because destroy
waits for all running threads to terminate be=
fore it returns. If you leave main
without calling destr=
oy
, you will leave main
with other threads still runnin=
g; many threading packages do not allow you to do this and end up crashing =
your program. destroy
without calling shutdown
, th=
e call waits for all executing operation invocations to complete before it =
returns (that is, the implementation of destroy
implicitly cal=
ls shutdown
followed by waitForShutdown
). s=
hutdown
(and, therefore, destroy
) deactivates all objec=
t adapters that are associated with the communicator. Since destroy=
code> blocks until all operation invocations complete, a servant will deadl=
ock if it invokes destroy
on its own communicator while execut=
ing a dispatched operation.
On the client side, calling destroy
while operations are stil=
l executing causes those operations to terminate with a CommunicatorD=
estroyedException
.=20