зеркало из https://github.com/microsoft/AMBROSIA.git
Updated cmp files and couple other minor modifications
This commit is contained in:
Родитель
1b4b77336a
Коммит
e4362e7db5
|
@ -52,7 +52,8 @@ export namespace Test
|
|||
export enum Letters { A = 0, B = 3, C = 4, D = 9 }
|
||||
|
||||
/**
|
||||
* Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
* *Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* Example of a [post] method that uses custom types.
|
||||
*/
|
||||
export function makeName_PostFork(callContextData: any, firstName?: string, lastName?: string): void
|
||||
|
@ -63,7 +64,8 @@ export namespace Test
|
|||
}
|
||||
|
||||
/**
|
||||
* Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
* *Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* Example of a [post] method that uses custom types.
|
||||
*/
|
||||
export function makeName_PostImpulse(callContextData: any, firstName?: string, lastName?: string): void
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -192,6 +206,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/ASTTest.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/ASTTest.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -9,22 +9,27 @@ import Utils = Ambrosia.Utils;
|
|||
let DESTINATION_INSTANCE_NAME: string = "server";
|
||||
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
|
||||
|
||||
/**
|
||||
Test File to test all the the ways that the ambrosia tag can be set and still work
|
||||
*/
|
||||
export namespace Test
|
||||
{
|
||||
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
|
||||
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
|
||||
export function OneLineNoComment_PostFork(callContextData: any): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "OneLineNoComment", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
|
||||
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
|
||||
export function OneLineNoComment_PostImpulse(callContextData: any): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "OneLineNoComment", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/** Multi Line with Comment before Tag
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* Multi Line with Comment before Tag
|
||||
* but still before tag
|
||||
*/
|
||||
export function MultiLineCommentBeforeTag_PostFork(callContextData: any): void
|
||||
|
@ -32,8 +37,10 @@ export namespace Test
|
|||
IC.postFork(DESTINATION_INSTANCE_NAME, "MultiLineCommentBeforeTag", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/** Multi Line with Comment before Tag
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* Multi Line with Comment before Tag
|
||||
* but still before tag
|
||||
*/
|
||||
export function MultiLineCommentBeforeTag_PostImpulse(callContextData: any): void
|
||||
|
@ -41,60 +48,72 @@ export namespace Test
|
|||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "MultiLineCommentBeforeTag", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
|
||||
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
|
||||
export function MultiSeparateLinesCommentBeforeTag_PostFork(callContextData: any): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "MultiSeparateLinesCommentBeforeTag", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
|
||||
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
|
||||
export function MultiSeparateLinesCommentBeforeTag_PostImpulse(callContextData: any): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "MultiSeparateLinesCommentBeforeTag", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/************** Have a space after the tag before function declaration
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ************ Have a space after the tag before function declaration
|
||||
*/
|
||||
export function EmptyLineBetweenTagAndFctn_PostFork(callContextData: any): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "EmptyLineBetweenTagAndFctn", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/************** Have a space after the tag before function declaration
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ************ Have a space after the tag before function declaration
|
||||
*/
|
||||
export function EmptyLineBetweenTagAndFctn_PostImpulse(callContextData: any): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "EmptyLineBetweenTagAndFctn", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/****** Spacing around the tag
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* **** Spacing around the tag
|
||||
*/
|
||||
export function SpacingAroundTag_PostFork(callContextData: any): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "SpacingAroundTag", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/****** Spacing around the tag
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* **** Spacing around the tag
|
||||
*/
|
||||
export function SpacingAroundTag_PostImpulse(callContextData: any): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "SpacingAroundTag", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/** JS Doc
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* JS Doc
|
||||
*/
|
||||
export function JSDOcTag_PostFork(callContextData: any): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "JSDOcTag", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/** JS Doc
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* JS Doc
|
||||
*/
|
||||
export function JSDOcTag_PostImpulse(callContextData: any): void
|
||||
{
|
||||
|
@ -102,7 +121,8 @@ export namespace Test
|
|||
}
|
||||
|
||||
/**
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* The ambrosia tag must be on the implementation of an overloaded function
|
||||
*/
|
||||
export function fnOverload_PostFork(callContextData: any, name?: string): void
|
||||
|
@ -111,7 +131,8 @@ export namespace Test
|
|||
}
|
||||
|
||||
/**
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* The ambrosia tag must be on the implementation of an overloaded function
|
||||
*/
|
||||
export function fnOverload_PostImpulse(callContextData: any, name?: string): void
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -212,6 +226,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_AmbrosiaTag.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_AmbrosiaTag.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -9,6 +9,9 @@ import Utils = Ambrosia.Utils;
|
|||
let DESTINATION_INSTANCE_NAME: string = "server";
|
||||
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
|
||||
|
||||
/**
|
||||
Test when missing @param rawParams
|
||||
*/
|
||||
export namespace Test
|
||||
{
|
||||
/**
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -182,6 +196,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_CustomSerialParamNoRawParam.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_CustomSerialParamNoRawParam.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -182,6 +196,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_CustomSerialParam.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_CustomSerialParam.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -9,13 +9,13 @@ import Utils = Ambrosia.Utils;
|
|||
let DESTINATION_INSTANCE_NAME: string = "server";
|
||||
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
|
||||
|
||||
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
|
||||
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
|
||||
export function unused_PostFork(callContextData: any): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "unused", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
|
||||
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
|
||||
export function unused_PostImpulse(callContextData: any): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "unused", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -179,6 +193,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_EventHandlerWarnings.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_EventHandlerWarnings.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -11,16 +11,20 @@ let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
|
|||
|
||||
export namespace Test
|
||||
{
|
||||
/** Fake Event Handler due to case in the name so this will be generated
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* Fake Event Handler due to case in the name so this will be generated
|
||||
*/
|
||||
export function onbecomingprimary_PostFork(callContextData: any): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "onbecomingprimary", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/** Fake Event Handler due to case in the name so this will be generated
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* Fake Event Handler due to case in the name so this will be generated
|
||||
*/
|
||||
export function onbecomingprimary_PostImpulse(callContextData: any): void
|
||||
{
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -180,6 +194,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
PTM.Test.onBecomingPrimary();
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_EventHandlers.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -177,6 +191,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_GenType1.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_GenType1.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -178,6 +192,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_GenType2.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_GenType2.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -177,6 +191,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_LitObjArray.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_LitObjArray.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -9,10 +9,14 @@ import Utils = Ambrosia.Utils;
|
|||
let DESTINATION_INSTANCE_NAME: string = "server";
|
||||
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
|
||||
|
||||
/**
|
||||
Test File of misc tests. If find a theme or grouping then move out of this file into separate file
|
||||
*/
|
||||
export namespace Test
|
||||
{
|
||||
/**
|
||||
* Note: The result ({ r1: string, r2: string }) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
* *Note: The result ({ r1: string, r2: string }) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* Correctly handle line-breaks and comments
|
||||
*/
|
||||
export function myComplexReturnFunction_PostFork(callContextData: any): void
|
||||
|
@ -21,7 +25,8 @@ export namespace Test
|
|||
}
|
||||
|
||||
/**
|
||||
* Note: The result ({ r1: string, r2: string }) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
* *Note: The result ({ r1: string, r2: string }) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* Correctly handle line-breaks and comments
|
||||
*/
|
||||
export function myComplexReturnFunction_PostImpulse(callContextData: any): void
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -179,6 +193,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_MiscTests.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_MiscTests.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -11,13 +11,13 @@ let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
|
|||
|
||||
export namespace StaticStuff
|
||||
{
|
||||
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
|
||||
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
|
||||
export function hello_PostFork(callContextData: any, name: string): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "hello", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("name", name));
|
||||
}
|
||||
|
||||
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
|
||||
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
|
||||
export function hello_PostImpulse(callContextData: any, name: string): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "hello", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("name", name));
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -182,6 +196,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_StaticMethod.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_StaticMethod.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -9,6 +9,10 @@ import Utils = Ambrosia.Utils;
|
|||
let DESTINATION_INSTANCE_NAME: string = "server";
|
||||
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
|
||||
|
||||
/**
|
||||
Test File to test all the Types for typescripts
|
||||
Has the basic types
|
||||
*/
|
||||
export namespace Test
|
||||
{
|
||||
/*********** Enum type (numeric enum - strings as number) as return */
|
||||
|
@ -67,7 +71,11 @@ export namespace Test
|
|||
}
|
||||
}
|
||||
|
||||
/************* Primitives - bool, string, number, array */
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* *********** Primitives - bool, string, number, array
|
||||
*/
|
||||
export function BasicTypes_PostFork(callContextData: any, isFalse: boolean, height: number, mystring?: string, mystring2?: string, my_array?: number[], notSure?: any): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "BasicTypes", 1, POST_TIMEOUT_IN_MS, callContextData,
|
||||
|
@ -79,7 +87,11 @@ export namespace Test
|
|||
IC.arg("notSure?", notSure));
|
||||
}
|
||||
|
||||
/************* Primitives - bool, string, number, array */
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* *********** Primitives - bool, string, number, array
|
||||
*/
|
||||
export function BasicTypes_PostImpulse(callContextData: any, isFalse: boolean, height: number, mystring?: string, mystring2?: string, my_array?: number[], notSure?: any): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "BasicTypes", 1, POST_TIMEOUT_IN_MS, callContextData,
|
||||
|
@ -91,31 +103,51 @@ export namespace Test
|
|||
IC.arg("notSure?", notSure));
|
||||
}
|
||||
|
||||
/********* Function using / returning Numeric Enum */
|
||||
/**
|
||||
* *Note: The result (PrintMedia) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ******* Function using / returning Numeric Enum
|
||||
*/
|
||||
export function getMedia_PostFork(callContextData: any, mediaName: string): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "getMedia", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("mediaName", mediaName));
|
||||
}
|
||||
|
||||
/********* Function using / returning Numeric Enum */
|
||||
/**
|
||||
* *Note: The result (PrintMedia) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ******* Function using / returning Numeric Enum
|
||||
*/
|
||||
export function getMedia_PostImpulse(callContextData: any, mediaName: string): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "getMedia", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("mediaName", mediaName));
|
||||
}
|
||||
|
||||
/************* Void type */
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* *********** Void type
|
||||
*/
|
||||
export function warnUser_PostFork(callContextData: any): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "warnUser", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/************* Void type */
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* *********** Void type
|
||||
*/
|
||||
export function warnUser_PostImpulse(callContextData: any): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "warnUser", 1, POST_TIMEOUT_IN_MS, callContextData);
|
||||
}
|
||||
|
||||
/************** Example of a [post] method that uses custom types. */
|
||||
/**
|
||||
* *Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ************ Example of a [post] method that uses custom types.
|
||||
*/
|
||||
export function makeName_PostFork(callContextData: any, firstName?: string, lastName?: string): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "makeName", 1, POST_TIMEOUT_IN_MS, callContextData,
|
||||
|
@ -123,7 +155,11 @@ export namespace Test
|
|||
IC.arg("lastName?", lastName));
|
||||
}
|
||||
|
||||
/************** Example of a [post] method that uses custom types. */
|
||||
/**
|
||||
* *Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ************ Example of a [post] method that uses custom types.
|
||||
*/
|
||||
export function makeName_PostImpulse(callContextData: any, firstName?: string, lastName?: string): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "makeName", 1, POST_TIMEOUT_IN_MS, callContextData,
|
||||
|
@ -131,32 +167,50 @@ export namespace Test
|
|||
IC.arg("lastName?", lastName));
|
||||
}
|
||||
|
||||
/********* Function returning number */
|
||||
/**
|
||||
* *Note: The result (number) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ******* Function returning number
|
||||
*/
|
||||
export function return_number_PostFork(callContextData: any, strvalue: string): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "return_number", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("strvalue", strvalue));
|
||||
}
|
||||
|
||||
/********* Function returning number */
|
||||
/**
|
||||
* *Note: The result (number) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ******* Function returning number
|
||||
*/
|
||||
export function return_number_PostImpulse(callContextData: any, strvalue: string): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "return_number", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("strvalue", strvalue));
|
||||
}
|
||||
|
||||
/********* Function returning string */
|
||||
/**
|
||||
* *Note: The result (string) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ******* Function returning string
|
||||
*/
|
||||
export function returnstring_PostFork(callContextData: any, numvalue: number): void
|
||||
{
|
||||
IC.postFork(DESTINATION_INSTANCE_NAME, "returnstring", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("numvalue", numvalue));
|
||||
}
|
||||
|
||||
/********* Function returning string */
|
||||
/**
|
||||
* *Note: The result (string) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ******* Function returning string
|
||||
*/
|
||||
export function returnstring_PostImpulse(callContextData: any, numvalue: number): void
|
||||
{
|
||||
IC.postImpulse(DESTINATION_INSTANCE_NAME, "returnstring", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("numvalue", numvalue));
|
||||
}
|
||||
|
||||
/********* Function with missing types ****
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ******* Function with missing types ****
|
||||
* Function with missing type information
|
||||
*/
|
||||
export function fnWithMissingType_PostFork(callContextData: any, p1: any, p2: number): void
|
||||
|
@ -166,8 +220,10 @@ export namespace Test
|
|||
IC.arg("p2", p2));
|
||||
}
|
||||
|
||||
/********* Function with missing types ****
|
||||
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
|
||||
/**
|
||||
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
|
||||
*
|
||||
* ******* Function with missing types ****
|
||||
* Function with missing type information
|
||||
*/
|
||||
export function fnWithMissingType_PostImpulse(callContextData: any, p1: any, p2: number): void
|
||||
|
|
|
@ -16,12 +16,25 @@ export namespace State
|
|||
{
|
||||
// TODO: Define your application state here
|
||||
|
||||
/**
|
||||
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
|
||||
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
|
||||
*/
|
||||
constructor(restoredAppState?: AppState)
|
||||
{
|
||||
super(restoredAppState);
|
||||
|
||||
if (restoredAppState)
|
||||
{
|
||||
// TODO: Re-initialize your application state from restoredAppState here
|
||||
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
|
||||
}
|
||||
else
|
||||
{
|
||||
// TODO: Initialize your application state here
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
|
||||
export let _appState: AppState = null;
|
||||
|
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
|
|||
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
|
||||
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
|
||||
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
|
||||
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
|
||||
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
|
||||
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
|
||||
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
|
||||
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
|
||||
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
|
||||
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
|
||||
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
|
||||
// (by allowing interleaving I/O) while also complying with Rule #1.
|
||||
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
|
||||
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
|
||||
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
|
||||
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
|
||||
|
||||
dispatcher(message);
|
||||
}
|
||||
|
@ -241,6 +255,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
|
|||
case Messages.AppEventType.BecomingPrimary:
|
||||
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_Types.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
|
||||
case Messages.AppEventType.CheckpointLoaded:
|
||||
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_Types.ts, then (after the next code-gen) a call to it will be generated here
|
||||
break;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
|
|
@ -154,7 +154,7 @@ namespace AmbrosiaTest
|
|||
}
|
||||
catch (Exception e)
|
||||
{
|
||||
Assert.Fail("<BuildTSApp> Failure! Exception:" + e.Message);
|
||||
Assert.Fail("<BuildJSTestApp> Failure! " + e.Message);
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
@ -24,8 +24,6 @@ async function main()
|
|||
{
|
||||
await Ambrosia.initializeAsync(Ambrosia.LBInitMode.CodeGen);
|
||||
let sourceFile: string = Utils.getCommandLineArg("sourceFile");
|
||||
let codeGenKind: Meta.GeneratedFileKind = Meta.GeneratedFileKind[Utils.getCommandLineArg("codeGenKind", "All")] ?? Meta.GeneratedFileKind.All;
|
||||
let mergeType: Meta.FileMergeType = Meta.FileMergeType[Utils.getCommandLineArg("mergeType", "None")] ?? Meta.FileMergeType.None;
|
||||
let generatedFileName: string = Utils.getCommandLineArg("generatedFileName", "TestOutput") ?? "TestOutput";
|
||||
|
||||
Meta.emitTypeScriptFileFromSource(sourceFile, { fileKind: Meta.GeneratedFileKind.Consumer, mergeType: Meta.FileMergeType.None, emitGeneratedTime: false, generatedFileName: generatedFileName+"_Consumer" });
|
||||
|
|
|
@ -50,7 +50,7 @@
|
|||
},
|
||||
"debugStartCheckpoint": {
|
||||
"type": "number",
|
||||
"description": "The checkpoint number to start \"time-travel debugging\" from."
|
||||
"description": "The checkpoint number to start \"time-travel debugging\" from. Defaults to 0 (which means don't debug)."
|
||||
},
|
||||
"debugTestUpgrade": {
|
||||
"type": "boolean",
|
||||
|
@ -147,6 +147,12 @@
|
|||
"type": "number",
|
||||
"description": "Set this to a positive integer to generate a warning whenever the number of in-flight post methods reaches this threshold. Defaults to -1 (no limit).",
|
||||
"default": -1
|
||||
},
|
||||
"messageBytePoolSizeInMB":
|
||||
{
|
||||
"type": "number",
|
||||
"description": "The size (in MB) of the message byte pool used for optimizing message construction. Defaults to 2MB.",
|
||||
"default": 2
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
@ -5,9 +5,9 @@
|
|||
"requires": true,
|
||||
"dependencies": {
|
||||
"@types/node": {
|
||||
"version": "14.14.31",
|
||||
"resolved": "https://registry.npmjs.org/@types/node/-/node-14.14.31.tgz",
|
||||
"integrity": "sha512-vFHy/ezP5qI0rFgJ7aQnjDXwAMrG0KqqIH7tQG5PPv3BWBayOPIQNBjVc/P6hhdZfMx51REc6tfDNXHUio893g=="
|
||||
"version": "14.14.33",
|
||||
"resolved": "https://registry.npmjs.org/@types/node/-/node-14.14.33.tgz",
|
||||
"integrity": "sha512-oJqcTrgPUF29oUP8AsUqbXGJNuPutsetaa9kTQAQce5Lx5dTYWV02ScBiT/k1BX/Z7pKeqedmvp39Wu4zR7N7g=="
|
||||
},
|
||||
"ajv": {
|
||||
"version": "6.12.6",
|
||||
|
@ -22,7 +22,7 @@
|
|||
},
|
||||
"ambrosia-node": {
|
||||
"version": "file:ambrosia-node-0.0.77.tgz",
|
||||
"integrity": "sha512-FpR2b2UckCVIrWQj6yKNlhw2xtgSbnStUe+NO+xkvWdp6Aa2ShQsnRXkGWVccsYshTa5gREdDIsMvrXtmEJv9g==",
|
||||
"integrity": "sha512-d2Z3RFTEftbvzVxwjBzpm2gV/eRUK9/qK0CvU8Atx3T/QTP5+0Pit1XbpXW84oyBf+wTcnxYA7wUKuBZhtOkmA==",
|
||||
"requires": {
|
||||
"@types/node": "^14.14.25",
|
||||
"azure-storage": "^2.10.3",
|
||||
|
@ -461,9 +461,9 @@
|
|||
"integrity": "sha1-WuaBd/GS1EViadEIr6k/+HQ/T2Q="
|
||||
},
|
||||
"typescript": {
|
||||
"version": "4.1.5",
|
||||
"resolved": "https://registry.npmjs.org/typescript/-/typescript-4.1.5.tgz",
|
||||
"integrity": "sha512-6OSu9PTIzmn9TCDiovULTnET6BgXtDYL4Gg4szY+cGsc3JP1dQL8qvE8kShTRx1NIw4Q9IBHlwODjkjWEtMUyA=="
|
||||
"version": "4.2.3",
|
||||
"resolved": "https://registry.npmjs.org/typescript/-/typescript-4.2.3.tgz",
|
||||
"integrity": "sha512-qOcYwxaByStAWrBf4x0fibwZvMRG+r4cQoTjbPtUlrWjBHbmCAww1i448U0GJ+3cNNEtebDteo/cHOR3xJ4wEw=="
|
||||
},
|
||||
"underscore": {
|
||||
"version": "1.8.3",
|
||||
|
|
|
@ -8,6 +8,6 @@
|
|||
},
|
||||
"dependencies": {
|
||||
"ambrosia-node": "file:ambrosia-node-0.0.77.tgz",
|
||||
"typescript": "^4.1.5"
|
||||
"typescript": "^4.2.3"
|
||||
}
|
||||
}
|
||||
|
|
Загрузка…
Ссылка в новой задаче