1 Reply Latest reply on Apr 17, 2014 12:34 AM by moklingfung

    Resilience when signing up for events with Update Manager


      I am concerned specifically with snapshot events but I suppose the discussion could apply to other kinds of event retrieval that involve signing up with the Update Manager.


      This thread notes that if a network error occurs between application and PI server, the AF SDK can generally recover the signups.  However this does not apply if the PI System is restarted.


      I know that persistent signups (across a restart) were introduced in PI 3.4.375.32, but only for specially designated clients like PI subsystems.  From the release notes:


      "For a certain class of applications, the Update Manager consumer signups are persisted across Update Manager restarts. Information with regard to persistent consumer signups is persisted to the file piupdconsumers.dat. The result is that after a PI Server restart, when the Update Manager starts, the consumer is registered with the Update Manager before the client application is even restarted. The consumer signups are reauthorized with the appropriate producer of updates immediately after the producer re-registers with the Update Manager. The Update Manager will queue updates for these signups even before the client application has been restarted. Persistent consumer signups timeout after a default of 86400 seconds. This timeout may be adjusted using the Update_PersistentConsumerTimeout PI Timeout Table parameter. At this time, the PI Total Subsystem and the PI Alarm Subsystem are the only two applications that use this functionality."


      My questions are:

      • Why are customer-written applications not allowed to use this signup persistence functionality?
      • Given this, how can my application tell (when a connection to PI is re-established) that PI has restarted in the interim, so it needs to re-establish the signups?  (I observe that if I sign up the same tag twice when PI has not restarted, I start getting two copies of every snapshot event for the tag).  Are there general guidelines for user code to handle server disconnects/reconnects?
      • Can PI-SDK recover signups after a network disconnect?  Can PI-API?


        • Re: Resilience when signing up for events with Update Manager

          Hi Jeremy:


          Both PI-SDK and AFSDK should automatically re-signup when they reconnect to the PIServer. Application should not need to resignup. PI-API does not support auto-resignup if the PI server has already remove the signup list (normally happen after 10 minutes of inactivity for the consumer). If the PIAPI reconnect within 10 minutes, the signup and event data are buffered on the server so everything should still work.


          The automatic re-signup for PISDK/AFSDK should work across PI server restart. There maybe some issues with PIdatapipe reconnection in AFSDK 2.5 but they should be fixed in AF2.6. Because PISDK/AFSDK handles reconnection behind the screen, applications actually is not aware than the disconnection occur or there is a need to resignup. Since auto re-signup normally means data loss, to help the applications to recover possible data loss, AFSDK 2.6 introduces the AFDataLossException that gives more information about the time period where possible data loss could occur for datapipe. See the AFSDK documentatoin for the GetUpdateEvent/GetObserverEvents calls.


          Both PISDK and AFSDK do reference counting for signing up of the same tag more than once, meaning the application needs to call removeSignup the same number of times to actually unsignup the tag. But you should only get the snapshot event multiple times even if you signup for the same tag multiple times.


          Signup persistency on the PIServer only help the case of PI server restart. it does not address the much more common scenario of network disconnection between server and client. Also it could be argued that a planned shutdown of the PIserver with short duration should automatically persisting the update manager consumers list so that there is no data loss. Client should not need to tell the server to prevent data loss just because administrator need to reboot the server machine to apply operating system patch.