4.2 KiB
0.9.8
- Adding the functionality to expose the running tasks of a dispatcher. Therefore the Layers use a different event ``.
- The user can specify if he wants to defaultly force emitting services or not.
0.9.7
-
Adding a
selector
-function to select a specific executor on service-calls. This is only performed if there are multipe providers for a service-
creating an instance is althoug a service
-
To provide a specific
selector
use the following options at theperformCall
-method of thedispatcher
:const instance = await dispatcher.generateInstance( { identifier: "instance01", type: package_01.providedClasses[0].description.name, params: [], }, // Now we are able to provide a specific selector: { selector: "dispatcher", // <= This is new } );
Instead of providing a function, the selector can be assigned to the following values. These values insert a default functionality:
Value Description dispatcher
Tries to execute the service on the requesting dispatcher first
Tries to execute the service on the first dispatcher which replied to the request host
Tries to execute the service on a random dispatcher found on the same host cpu-usage
Tries to execute the service on the dispatcher with the minimal used cpu. To compare the elements the selection considers the available Cores as well free-ram
Tries to execute the service on the dispatcher which has free ram To define a custom policy, provide the function as follows:
(dispatcherId: string, options?: { last?: boolean, initalTest?: boolean }) => Promise<boolean>
The first parameter receives the
responding
dispatcher-id the second contains additional flags, which might be used during the selection process:Position Parameter Description 0 dispatcherId
Tries to execute the service on the requesting dispatcher 1 options
optional : additional parameter with options The Parameter options contains the following parameters:
Parameter Description last
shows that the last dispatcher is being checked. initalTest
shows a flag, that the function is just tested. This is important if you want to check all dispatchers and compare them later etc.
-
-
Adapting Dispatcher:
-
Adding/Adapted the Functions
unregisterCallback
. This callback allows to unregister callbacks that are given in arpc-call
. See the Example below:// Add the Example Here
Therefore the
communication-layers
andmirros
have to implement additional events (). -
Adding/Adapted the Functions
instanceExists
,publisherExists
andsubscriptionExists
. These functions allows to check whether the instance / publisher / subscriber exists for the givenidentifier
ortopic
-
Added
getInstanceInfo
, a function, which will return the instance description and the corresponding dispatcher. -
Added
getDispatcherForInstance
, a function, which will return the matching dispatcher of the instance. -
Creating Instances: Now the Dispatcher tests, if there is allready an instance with this name and type. If the type miss matches, an error is thrown. Otherwise the dispatcher tries to adapt the selector-function.
-
Adapted the
IDispatcherInfo
message:export interface IDispatcherInfo { id: string; timestamp: number; status: ENopeDispatcherStatus; env: string; version: string; host: { cores: number; cpu: { // Name of the CPU as String model: string; // Speed of the CPU in MHz speed: number; // Usage of the CPU in %. If not present ==> -1 usage: number; }; os: string; ram: { // Amount of free RAM in MByte free: number; // Amount of free RAM in MByte total: number; // Used RAM in % usedPerc: number; }; }; pid: number | string; }
-
0.9.6
- Adding MQTT as Communication-Layer.
- Fixing
getIdentifierOf
atBaseModule
.