As described under Features, only a subset of functions make use of the buffering process. Other PI-API calls continue to be processed through the program’s connection to the home node. Interfaces usually request a list of tags from the PI Server and may register when starting for exceptions if they support output points from PI. For these requests to succeed, the home node must be available. Once an interface is started, the majority of server communication involves sending data to the home node that is handled with buffering. Occasional requests for home node data will time out if the home node is down, though a well written interface will survive these time-outs and continue to send events.
This limitation is a difference between API nodes with buffering and PINet nodes. PINet nodes store a copy of the point database and snapshots for points that are collected locally (by interfaces on the PINet node). An interface starting on a PINet node can query this local information during startup and succeed even when the home node is down.
Data stored in the PI-API node buffers is not accessible to retrieval calls until it is forwarded to the home node. Calls on the API node as well as other nodes for recent data will return the most current snapshot on the server, not what is currently in the buffers. This situation may be due to the home node being down, slow or a burst of input data on the API node.
The retrieval calls continue to be processed through the calling processes connection to the home node and are ignored by the buffering process. This is similar to the operation on a PINet node when requesting values for points that are not collected locally. This performance is also seen on a home node when input events are being buffered. Until events leave the input queue and go to the snapshot they are not visible to retrieval calls.
Errors generated by bad event data, as discussed earlier, are not detected until the event is forwarded to the home node. Error returns from buffered functions return the success or failure of buffering the events. Errors with the contents of those events (e.g., bad point number, illegal timestamp) are written to the API Node log when encountered. This is why it is recommended to suppress buffering when installing a new interface until data is being collected without problems for the desired points.
Changes to buffering parameters in the piclient.ini file require a restart of the buffering processes to get them to be used by the processes.