Startup Scripts

The startup process of DolphinDB is as shown below:

You can specify the init script, startup script, and postStart script with configuration parameters init, startup and postStart, respectively. The configuration file is dolphindb.cfg for standalone mode, and cluster.cfg for a cluster. You can specify an absolute or relative path for each configuration parameter. If a relative path is specified, DolphinDB will search the home directory, working directory and executable directory on the local node in order. For example:

init=dolphindb.dos
startup=/home/streamtest/init/server/startup.dos
postStart=D://dolphindb/server/postStart.dos

Operations that are performed during the system startup normally include defining and sharing in-memory tables and stream tables, subscribing to stream tables, loading plugins, etc.

Example 1: define and share in-memory tables

Define an in-memory table t and share it as st. Users can insert, update, delete or query records in the table st from other sessions.

t=table(1:0,`date`sym`val,[DATE,SYMBOL,INT])
share(t, `st); 

Example 2: share and subscribe to stream tables

• share and persist a stream table

The definitions of stream tables are not persisted in DolphinDB, and you can initialize the stream tables in the startup script. The following example defines and shares the stream table st1.

login("admin","123456")
t1=streamTable(1:0,`date`sym`val,[DATE,SYMBOL,INT])
enableTableShareAndPersistence(table=t1,tableName=`st1,cacheSize=1000)

• subscribe to the stream table

You can also subscribe to a stream table in the startup script. For example, subscribe to stream table st1 and save the data to table tb.

tb=loadTable("dfs://db1","tb")
subscribeTable(tableName="st1",actionName="subst",offset=-1,handler=append!{tb},msgAsTable=true)

Note:

If a shared in-memory table or shared stream table is defined and referenced in the startup script, you need to use a go statement after function share or enableTableShareAndPersisten. Otherwise, the system throws an exception indicating undefined variables when parsing the code.

For example, to write data from a stream table to a shared keyed table, the following code is defined in the startup script:

def saveT(tb,st){tb.append!(st)}
n=1000000
colNames = `time`sym`vwap
colTypes = [DATETIME,SYMBOL,DOUBLE]
share streamTable(n:0, colNames, colTypes) as test_stream
opt=keyedTable(`sym, n:0, colNames, colTypes)
share(opt, `optShared)
go
subscribeTable(tableName="test_stream", actionName="test1", offset=0, handler=saveT{optShared}, msgAsTable=true, batchSize=100000, throttle=60)

A shared variable optShared is dynamically registered during the execution of share(opt, optShared), rather than during the code parsing phase. Since the subsequent subscription handler=saveT` references this variable, a go statement must be used. Otherwise, an exception will be thrown as the system cannot recognize the variable optShared.

Alternatively, to avoid such exception in parsing phase, you can replace the share function above with a share statement like:

share opt as optShared

Example 3: load plugins before loading scheduled jobs

If a scheduled job references a plugin function, the plugin must be preloaded, otherwise the server startup may fail due to deserialization issues.

The scheduled job "jobDemo" calls a function provided by the plugin "odbc".

use odbc
def jobDemo(){
	conn = odbc::connect("dsn=mysql_factorDBURL");
	//...
}
scheduleJob("job demo","example of init",jobDemo,15:48m, 2019.01.01, 2020.12.31, 'D')

If the plugin "odbc" is not loaded when the system loads the scheduled jobs, DolphinDB server will be shut down with the following message output to log:

<ERROR>:Failed to unmarshall the job [job demo]. Failed to deserialize assign statement. Invalid message format.

To start the system, load the plugin in the startup script as follows:

loadPlugin("plugins/odbc/odbc.cfg")