Jason Coposky, Chief Technologist
Capturing output from a microservice
All microservices must return an integer error --
capture with the errorcode() or errormsg() operators
Example:
*err = errorcode( msiHelloWorld() );
// or *err = errormsg( msiHelloWorld(), *msg );
if( 0 != *err ) {
// handle error here
}
Rules should communicate errors to clients
Utilize the fail() and failmsg() directives to pass errors back to the client.
*err = errorcode( msiHelloWorld() );
if( 0 != *err ) {
fail(*err);
// or failmsg( *err, "msiHelloWorld failed" );
}
This error will be propagated back to the client when run via irule or a Policy Enforcement Point
Debugging Rules
Still stuck with 'printf' style debugging --
writeLine( "serverLog", "I am Here" );
There is no proper debugger for the Rule Language but:
Rule Engine Plugins can make this better!
Classes of Errors - Syntax
Classes of Errors - Microservice Errors
Performance Considerations
Microservices vs Rules
Rules - orchestration and flexibility
rules can be treated as 'Apps', stored in iRODS
Microservices - performance critical processing,
reach into external libraries
Leverage the Delayed Execution Queue
Rules or Microservices should not block iRODS clients -- asynchronous processing
push anything that will take a while onto the delayed execution queue
with the delay() directive
delay("<PLUSET>1m</PLUSET>) { }
The Hints are an XML style parameter list:
Full description: http://wiki.irods.org/index.php/Rule_Execution_modes
Note: maximum_number_of_conncurrent_rule_engine_server_processes in
server_config.json controls how many delayed exec rules can be in flight
Consider a job scheduler
Volume and Run Time - consider as scheduler
Concerns
Scheduled jobs can trigger subsequent rules within iRODS - chain HPC jobs
Questions?