The name and sockdir option values together determine the name of a directory created by the input stage for its general use. This directory is simply named [sockdir]/[name]; it is removed by the application on exit, but could be orphaned by the application under unusual circumstances. In this directory are created the following named Unix domain sockets: ctlsock, the application control socket (may not be present, see the section called “Control interface”); issink, used as the destination socket by the lag processing stage applications to send messages to the input stage; and lagsets, the lag set source socket name. I might be able to do away with this last one, but it does no harm, so I'm in no rush.

Under the directory created for the input stage instance, a directory is created for each existing configuration, named according to the configuration name. This directory only contains the named Unix domain sockets from which the lag set processing stage pipelines receive their lag sets. Each process in the lag set processing stage will be associated with exactly one socket in the sub-directory associated with the configuration to which it belongs. These “lag set sockets” are named according to their “id” value in the configuration.

Configurations are generally handled by the input stage as described in the section called “Configuration handling”, but to do so requires the input stage to manage the processes in the lag processing stage. This section provides more detailed information on the design of this aspect of the input stage.

When a configuration is created, the input stage determines the number of lag processing stage pipelines in the configuration, and spawns one lagset_pipeline process for each pipeline. Each of these processes is monitored at the operating system level by the input stage application to determine whether the process is running or not.

When a configuration is destroyed, a GST_MESSAGE_EOS message is first sent by the input stage application to each lag processing stage pipeline in the configuration to request the pipelines to shut down normally. Process monitoring by the input stage allows the input stage to determine whether the pipeline processes have exited as requested; if any process has not exited after some period (approximately five seconds, currently), it is sent a kill signal to force it to exit.

In the event that a lag processing stage pipeline process in an existing configuration exits prematurely, the input stage will be notified of that event and will attempt to restart the failed process. An attempt to start a pipeline process may be repeated up to a small number of times (three, currently) before no further attempts are made. A failed pipeline process should have no impact on any part of the system aside from the loss of the lag sets that are destined for the faulty pipeline.

In addition to the process monitoring by the input stage at the operating system level, the input stage expects to receive certain messages from each of the pipelines reporting on its state. Currently, a created configuration is not ready for use until all its pipelines have reported their readiness to the input stage. If for some pipeline a readiness message is not received by the input stage before a timeout occurs (five seconds, again, currently), the pipeline process is sent a kill signal. Another attempt may be made to start the pipeline depending on the number of attempts that have already been made to start the process, as described previously.

Note

I think this behavior should be changed. Although one configuration may contain several nominally independent lag processing stage pipelines, the current behavior improperly ties together the operation of these various pipelines. There is no problem in waiting for the state message from each pipeline, but the fate of an entire configuration should not be determined by any single pipeline process. My mistake.