Provided by: libpcp3-dev_4.0.1-1_amd64 bug

NAME

       pmReconnectContext - reconnect to a PMAPI context

C SYNOPSIS

       #include <pcp/pmapi.h>

       int pmReconnectContext(int handle);

       cc ... -lpcp

DESCRIPTION

       As a consequence of network, host or Performance Metrics Collector Daemon (PMCD) failures,
       an application's connection to a PMCD may be established and then subsequently lost.

       The  routine  pmReconnectContext  allows  an  application  to  request  that  the  context
       identified  by  handle should be re-established, provided the associated metrics source is
       accessible.

       When the source of metrics associated with the context handle is pmcd(1),  then  to  avoid
       flooding  the  system  with  reconnect  requests,  pmReconnectContext  will only attempt a
       reconnection after a suitable delay from the previous unsuccessful  attempt  to  reconnect
       this  context.  This  imposed  restriction  on  the reconnect re-try time interval uses an
       exponential back-off so that the initial delay is 5 seconds after the  first  unsuccessful
       attempt, then 10 seconds, then 20 seconds, then 40 seconds and then 80 seconds thereafter.

       The  environment  variable  PMCD_RECONNECT_TIMEOUT  may  be  used to redefine the back-off
       intervals, see PMAPI(3).

       Calling pmReconnectContext with a handle identifying a currently connected pmcd(1) context
       will cause the connection to be broken before any reconnection is attempted.

       If   handle   identifies   a  context  associated  with  an  archive  source  of  metrics,
       pmReconnectContext returns without delay.

       If the reconnection succeeds, pmReconnectContext returns handle.

       As a side-effect of reconnecting, any derived metrics that have  previously  been  defined
       using  pmRegisterDerived(3),  pmRegisterDerivedMetric(3) or pmLoadDerivedConfig(3) will be
       re-processed and re-bound to the available  metrics  from  the  reconnected  source.   The
       support   of   dynamic  definition  for  derived  metrics  provides  one  use  case  where
       pmReconnectContext may be called even if the connection to the metrics source has not been
       lost.

       Note  that  even  in  the  case  of a successful reconnection, pmReconnectContext does not
       change the current Performance Metrics Application Programming Interface (PMAPI)  context,
       so handle remains valid.

       When   attempting  to  connect  to  a  remote  pmcd(1)  on  a  machine  that  is  booting,
       pmReconnectContext could potentially block for  a  long  time  until  the  remote  machine
       finishes  its  initialization.   pmReconnectContext  will abort and return an error if the
       connection has not been established  after  some  specified  interval  has  elapsed.   The
       default  interval  is  5 seconds.  This may be modified by setting PMCD_CONNECT_TIMEOUT in
       the environment to a real number of seconds for the desired timeout.  This is most  useful
       in cases where the remote host is at the end of a slow network, requiring longer latencies
       to establish the connection correctly.

ENVIRONMENT

       PMCD_CONNECT_TIMEOUT
              Timeout period (in seconds) for pmcd(1) connection attempts.

       PMCD_RECONNECT_TIMEOUT
              Redefines the back-off intervals - refer to PMAPI(3).

SEE ALSO

       pmcd(1),   PMAPI(3),   pmLoadDerivedConfig(3),   pmNewContext(3),    pmRegisterDerived(3),
       pmRegisterDerivedMetric(3) and pmUseContext(3).

DIAGNOSTICS

       PM_ERR_NOCONTEXT

              handle does not identify a valid PMAPI context

       -ETIMEDOUT

              The re-try time has not elapsed, or the reconnection is attempted and fails.

CAVEAT

       Applications  that  use gethostbyname(3) should exercise caution because the static fields
       in struct hostent may not  be  preserved  across  some  PMAPI(3)  calls.   In  particular,
       pmNewContext(3) and pmReconnectContext(3) both may call gethostbyname(3) internally.