Request Info Keys

The request info keys are returned from calling proc_data.request_info. These keys include a variety of details about the executing UDF from the request information map made available to each running UDF.

General Information

Map Key	Description
`proc_name`	The name of the UDF being executed.
`run_id`	The run ID of the UDF being executed. This is also displayed in GAdmin on the UDF page in the Status section as a link you can click on to get more detailed information; note that although this is an integer, it should not be relied upon as such, as its format may change in the future.
`rank_number`	The processing node container number on which the current UDF instance is executing. For distributed UDFs, [1..n]; for non-distributed UDFs, 0.
`tom_number`	The processing node number within the processing node container on which the current UDF instance is executing. For distributed UDFs, [0..n-1], where n is the number of processing nodes per processing node container. For non-distributed UDFs it is not provided, since these do not run on a processing node.
`<option_name>`	Any options passed in the `options` map in the /execute/proc request will also be in the request info map.

CUDA Information

When executing UDFs that utilize CUDA, additional request information is returned.

Map Key	Description
`cuda_devices`	The number of CUDA devices currently in use.
`cuda_free`	The amount of CUDA memory available.

Data Segment Information

Data is passed into UDFs in segments. Each segment consists of the entirety of the data on a single TOM and is processed by the UDF instance executing on that TOM. Thus, there is a 1-to-1 mapping of data segment and executing UDF instance, though this relationship may change in the future. Running the same UDF multiple times should result in the same set of segments, assuming the same environment and system state across runs.

Map Key	Description
`data_segment_id`	A unique identifier for the segment of the currently executing UDF instance. All of the data segment IDs for a given UDF execution are displayed in GAdmin when you click on the run ID; note that although it is possible to identify rank and TOM numbers from this ID, it should not be relied upon, as its format may change in the future.
`data_segment_count`	The total cluster-wide count of data segments for distributed UDFs; for non-distributed UDFs, 1.
`data_segment_number`	The number of the current data segment or executing UDF instance [0..data_segment_count-1].

Kinetica API Connection Parameters

These can be used to connect back to Kinetica using the regular API endpoint calls. Use with caution in distributed UDFs, particularly in large clusters, to avoid overwhelming the head node. Also note, multi-head ingest may not work from a UDF in some cases without overriding the worker URLs to use internal IP addresses.

Map Key	Description
`head_url`	The URL to connect to.
`username`	Randomly generated temporary username used to execute the UDF.
`password`	Randomly generated temporary password used to execute the UDF.

Since username and password are randomly-generated temporary credentials, for security reasons, they should not be printed or output to logs.