If true, force the agent to be restarted even if the agent
is already on the destination node.
If false then a move of an agent already at the destination
will reply with a trivial success. In practice one would
tyically set this to false for performance reasons.
The "force reload" capability is primarily designed to test
the agent-side mobility requirements without actually
relocating the agent.
If the agent and its components (plugins, services, etc)
correctly implement the suspend and persistence APIs then
the restart of an agent on the same node should have
no permanent side effects. A hundred restarts
should have no side effect other than a temporary
performance penalty.
On the other hand, a failure to support a restart might
result in an agent:
- memory leak (garbage-collection)
- thread leak (didn't stop/pool all theads)
- serialization/deserialization error
- state loss (some state not captured)
- internal deadlock (synchronization bug)
- persistence error
- naming-service mess
- crypto-key loss (unable to re-obtain identity)
- conflict with other services (health-check, etc)
or some other error that (ideally) should be easier to
debug than the full relocation of the agent on another
node.
|