An Actor that wraps around converted NumberPools and synchronizes a portion of the number registration process.
The ultimate goal is to manage a coherent group of unique identifiers for a given "region" (Zone).
Both parts of the UID system sit atop the Zone for easy external access.
The plain part - the NumberPoolHub here - is used for low-priority requests such as checking for existing associations.
This Actor is the involved portion that paces registration and unregistration.
A four part process is used for object registration tasks.
First, the requested NumberPool is located among the list of known NumberPools.
Second, an asynchronous request is sent to that pool to retrieve a number.
(Only any number. Only a failing case allows for selection of a specific number.)
Third, the asynchronous request returns and the original information about the request is recovered.
Fourth, both sides of the contract are completed by the object being assigned the number and
the underlying "number source" is made to remember an association between the object and the number.
Short circuits and recoveries as available on all steps though reporting is split between logging and callbacks.
The process of removing the association between a number and object (unregistering) is a similar four part process.
The important relationship between this Actor and the Map of NumberPoolActors is an "gate."
A single Map is constructed and shared between multiple entry points to the UID system where requests are messaged.
Multiple entry points send messages to the same NumberPool.
That NumberPool deals with the messages one at a time and sends reply to each entry point that communicated with it.
This process is almost as fast as the process of the NumberPool selecting a number.
(At least, both should be fast.)
the NumberPoolHub that is partially manipulated by this Actor
poolActors
a common mapping created from the NumberPools in guid;
there is currently no check for this condition save for requests failing
Type Members
typeReceive = PartialFunction[Any, Unit]
Definition Classes
Actor
Value Members
final def!=(arg0: Any): Boolean
Definition Classes
AnyRef → Any
final def##(): Int
Definition Classes
AnyRef → Any
def+(other: String): String
Implicit information
This member is added by an implicit conversion from UniqueNumberSystem to
any2stringadd[UniqueNumberSystem] performed by method any2stringadd in scala.Predef.
This member is added by an implicit conversion from UniqueNumberSystem to
ArrowAssoc[UniqueNumberSystem] performed by method ArrowAssoc in scala.Predef.
This member is added by an implicit conversion from UniqueNumberSystem to
StringFormat[UniqueNumberSystem] performed by method StringFormat in scala.Predef.
Definition Classes
StringFormat
Annotations
@inline()
final defgetClass(): Class[_]
Definition Classes
AnyRef → Any
defhashCode(): Int
Definition Classes
AnyRef → Any
final defisInstanceOf[T0]: Boolean
Definition Classes
Any
final defne(arg0: AnyRef): Boolean
Definition Classes
AnyRef
final defnotify(): Unit
Definition Classes
AnyRef
final defnotifyAll(): Unit
Definition Classes
AnyRef
defpostRestart(reason: Throwable): Unit
Definition Classes
Actor
Annotations
@throws(classOf[java.lang.Exception])
defpostStop(): Unit
Definition Classes
Actor
Annotations
@throws(classOf[java.lang.Exception])
defpreRestart(reason: Throwable, message: Option[Any]): Unit
This member is added by an implicit conversion from UniqueNumberSystem to
ArrowAssoc[UniqueNumberSystem] performed by method ArrowAssoc in scala.Predef.
An
Actor
that wraps around convertedNumberPool
s and synchronizes a portion of the number registration process. The ultimate goal is to manage a coherent group of unique identifiers for a given "region" (Zone
). Both parts of the UID system sit atop theZone
for easy external access. The plain part - theNumberPoolHub
here - is used for low-priority requests such as checking for existing associations. ThisActor
is the involved portion that paces registration and unregistration.A four part process is used for object registration tasks. First, the requested
NumberPool
is located among the list of knownNumberPool
s. Second, an asynchronous request is sent to that pool to retrieve a number. (Only any number. Only a failing case allows for selection of a specific number.) Third, the asynchronous request returns and the original information about the request is recovered. Fourth, both sides of the contract are completed by the object being assigned the number and the underlying "number source" is made to remember an association between the object and the number. Short circuits and recoveries as available on all steps though reporting is split between logging and callbacks. The process of removing the association between a number and object (unregistering) is a similar four part process.The important relationship between this
Actor
and theMap
ofNumberPoolActors
is an "gate." A singleMap
is constructed and shared between multiple entry points to the UID system where requests are messaged. Multiple entry points send messages to the sameNumberPool
. ThatNumberPool
deals with the messages one at a time and sends reply to each entry point that communicated with it. This process is almost as fast as the process of theNumberPool
selecting a number. (At least, both should be fast.)