2 Replies Latest reply on May 22, 2017 8:39 PM by tmcmanus

    Avoid switching to Primary collective member when there is a lot of data in the buffer




      if the Primary member of a Data Collective (SRV01) is down (due to maintenance or any other reason), the Secondary (SRV02) is elected as the (only) active member. At this point, the Interface starts buffering data to SRV01. After a long period of time, when SRV01 is back online, it becomes immediately the new Primary server and all the clients will start using it to read data even if the buffer is still flushing data to SRV01. Sicne this process could take a long period of time, depending on the downtime period, in my opinion it would be nice if SRV01 was elected as the new Primary only if the buffer is empty (or at least if it contains less than an X number of events), oherwise users could be connected to a server with old data.


      Did you have any experience of this behaviour? Have you ever been in this situation?


      Thanks a lot for your help


        • Re: Avoid switching to Primary collective member when there is a lot of data in the buffer
          James Devine

          Hi Francesco:


          We have endured similar issues, such as too many users trying to pull data only from the Primary server across a wide geographic network. I would like to suggest an option to hopefully share the load between collective members. My suggestion is setting the priority of which member they will connect to.


          This is accomplished by opening the 'About PI SDK' (a.k.a. PISDKUtility) application. In the right hand navigation pane click [Connections], which shows the available pi servers and pi collectives. On the collective right click and from the shortcut menu click [Member Setup]. This launches the {Collective Members Setup} dialog. Once there you can reorder the 'Priority' of the servers. In this example the Primary is the third priority server to connect to for applications I run. It is located on another side of the country. The servers with priority 1, and 2 are located close with far less network lag. The following screenshots demonstrate what I am talking about:




          1 of 1 people found this helpful
            • Re: Avoid switching to Primary collective member when there is a lot of data in the buffer

              Thanks for the suggestion James


              There unfortunately is no way to automate this, as the SDK connection has no visibility into possible data bottlenecks heading into that server.


              Adding to James' suggestion, it can often be beneficial in general to have users connect to the Secondary by default. The Primary server is often the most heavily used server from an operational data perspective (one heavy resource would be PI Analytics), and therefore under a higher base-line server load. Because of this, users might often receive better performance for data-read operations when connecting to the Secondary.