gkousiouris

The flow can be used to generate a set rate load towards an endpoint. It has been adapted to Openwhisk endpoint rationale, but it can also be used in generic endpoints with minor modifications. The main requirement is to have a status endpoint, in which the initial call result will be made available after the end of the request processing.

Detailed information for the input and output data specification is included in the flow.

The flow can be utilized directly in Node-RED, generating the traffic from the local flow, or it can be deployed and executed as an Openwhisk action.

For this purpose it has been wrapped around a container available here:

gkousiouris

This helper node aims at performing synchronous calls for polling in case of an async API (calls that return prior to completion, e.g. in the case of non blocking calls in OW, the initial request is returned with a submission success and an activation id in order to follow up on the result).

The main difference from the previous PollTOPushConverter (https://flows.nodered.org/flow/fe8a1ff325abebcf99ffc63744a3c231/in/VOf-0UrN5e2j) is that it supports also function chaining (through a msg.functionChain or UI set boolean parameter). This means that if the activated function can chain itself, to avoid OW maximum runtime timeout, the node can follow-up on the new activation ID and push a notification until all the chain has finished.

The accordin

gkousiouris

The flow inserts a subflow named Poll2PushConverter, in order to simplify the process of polling towards an endpoint that does not support blocking calls up to completion. The initial call returns after a specified period and is then fed to the Poll2PushConverter in order to undertake the polling. Upon successful completion (or reaching of max number of attempts), the subflow triggers a message to one of the respective outputs.

An example flow is also included with relation to how to apply it to an Openwhisk web action invocation that defaults to 65 seconds of waiting time in the initial blocking call, while the action takes longer to complete.

The docker image of the used action can be found here and is a delay action that takes as inputs the iterations and the

gkousiouris

The core flow handles a control loop where delay and iteration numbers are dynamically passed on as input variables during the action invocation. This is needed to enhance experiment automation, so that we can pass through arguments the number of n repetitions of the main delay loop, in order to simulate a flow of n functions, each with the set delay. The respective flow should also be executable as an Openwhisk function, which means it needs to abide by the respective interface of the latter (one POST /init method and one POST /run method. The function node in the middle subflow extracts parameters from the incoming message and passes them through the msg.delay and msg.iterations fields. The follow-up node is a Node-RED built-in delay node that gets the needed delay from the assigned msg.delay field. The whole process is iterated until the number of needed delays are met.

gkousiouris

This is a template subflow for parallelizing the execution of a function or process on the provided input data (Single Program Multiple Data pattern). The subflow gets the initial message and chunks it down based on the msg.payload.value.splitsize value. Each batch of input rows is forwared as input to one of three means of execution (configured in the msg.payload.value.execution as one of "faas","local_multithread","local_multiprocess"):

• an Openwhisk action (whose name is included in the msg.payload.value.action field)
• a local thread or
• a newly spawned local process (name of script to execute in msg.payload.value.shellscript)

Therefore if an array of 1000 rows (included in the msg.payload.value.values) is inserted and the splitsize is set to 10, it will create 100 inner calls of the msg.payload.value.action if the execution is set to "faas". In this cas