13 Replies Latest reply on May 9, 2014 7:55 AM by Roger Palmen

    PI System Explorer\AF SDK tree structure caching

    ChewCheeLim
      Hi there, I believe that AF service does caching for speedy processing.. However, in our client's dev environment, we are noticing PI System Explorer is 'Very' slow in responding to display changes made to an AF model with new elements added through AF SDK calls. For example, Add element made through AF SDK calls doesn't show up after 5-10 minutes. Then we deleted elements (newly created) through PI System Explorer, this time, AF SDK call still seeing the deleted elements. Through this Post:-http://vcampus.osisoft.com/discussion_hall/development_with_osisoft_sdks/f/28/p/1139/6131.aspx#6131 Rhys explained "Copied and quoted from Rhys in the post" "...A service (or incorporated functionality of the AFService) that assists in mapping AF structures to identities that connect to an AF database.  If multiple identites have exact same privileges on a database then they share the same cached structure of Elements/Attributes etc.  When something becomes dirty or checked in then if applicable to the identity's cache then the cached structure is updated.  At any moment an administrator can flush the cache, stop caching or alter timeouts.  When a user disconnects or the connection times out from an af database then the cache is synchronised...." How do I make sure the 2 ids I am using in the Client DEV environment has the same privilege? I want to be able to see the AF structure changes right away, only then we can perform proper testing. And also, below post http://vcampus.osisoft.com/discussion_hall/development_with_osisoft_sdks/f/28/p/1875/9738.aspx#9738 comments on setting cache time = 0 in Code. If this is a preferable way? Default cache or delay if is 120 seconds (2 mins) I am okay. But the DEV environment is really NOT Normal. Should I look at overall server setting ? Could it be something overlooked? Or changes are Queued? Can I look at the queue? Any advice is greatly appreciated!
        • Re: PI System Explorer\AF SDK tree structure caching
          cmanhard

          PI System Explorer does not automatically refresh.   To see updates that have occurred in other applications, you must manually click on the Refresh button in the top toolbar.

            • Re: PI System Explorer\AF SDK tree structure caching
              ChewCheeLim

              Thanks Chris:

               

              Yes, we did multiple times. We even closed out PI System Explorer and re-launched. Still the same problem.

                • Re: PI System Explorer\AF SDK tree structure caching
                  cmanhard

                  If you closed PSE and reopened, this is not related to caching.

                   

                  Are the modifications being made through a custom application?

                   

                  If so, are you checking in your modifications to AF on a regular basis through AFDatabase.CheckIn(AFCheckedOutMode.ObjectsCheckedOutThisSession)

                   

                  Is PSE responsive when you "Refresh"?

                    • Re: PI System Explorer\AF SDK tree structure caching
                      ChewCheeLim

                      Yes, the modification was made through AF SDK. and I have the checkin() in the logic as you indicated.

                       

                      Like So:-

                       

                                     oAf.CheckIn(AFCheckedOutMode.ObjectsCheckedOutThisSession);

                       

                      Yes, we tried refresh so many times. The weird part is similar code tested in another DEV environment and it's been working fine. But this client Dev is acting up 'incorrectly'. And we are baffled as what to look or check..

                       

                      In Rhys post, he mentioned something about User privilege set in AF could contribute to the changes sees by one id but not the others?? Could it be the AD account set up differently = what it means by the user privilege?

                        • Re: PI System Explorer\AF SDK tree structure caching
                          cmanhard

                          While it is possible for different users to have different privileges which cause them to see a smaller set of elements, it is not something that would change over a delay - a user either sees it or not - unless security is being modified over the delay.

                           

                          I only see two possibilities:

                           

                          1) The writing application is not checking in frequently - so the delay is between the application write and the checkin.  

                           

                          2) Your AF System is an HA collective and PSE is connecting to the secondary, and there is an especially slow connection between the primary and secondary SQL Servers.

                           

                          Are either of those possible?

                            • Re: PI System Explorer\AF SDK tree structure caching
                              ChewCheeLim

                              Thanks Chris. Good Points, we will check that out. Yes there are primary & secondary.

                                • Re: PI System Explorer\AF SDK tree structure caching
                                  ChewCheeLim
                                  Chris, We had a debug session with our client today and found out the following:- 1) Client Dev environment has only 1 of AF Server running. There is no primary or secondary HA set up. 2) We were able to produce 2 elements with the same name @ same level. Here are the steps.                (a) Launched PSE & custom app. Both using SAME AF DB - 'TEST01'. left both running.                (b) Custom APP - AF SDK- Created element named '67', did a db checkin in code. Checked-in successfully.                (c) PSE: (without refreshing) created element also named '67' and checked in successfully.                (e) PSE: (Hit refresh button) : 2 elements with same named created. see attachment.                (d) PSE: Deleted both elements and checked in successfully. Both elements deleted okay. 3) Initially step #2 was done with element named 182. Both were created. Didn't capture any images. When we were trying to delete elements, we received some errors in PSE complaining about Key or GUID ids not unique during check-in (sorry, we didn't get a screen on that). We clicked ok  & continued. Both elements with named 182 were gone in PSE. Even we refreshed the screen.      BUT, Custom App- AF SDK calls still seeing this 182. We digged into PIFD SQL DB, we found out there are 3 tables.        AFElement        AFElement_AT        AFElement_SB the 182 element still hanging around _SB table. (see another attachement) So this test #3 gives a data discrepancy problem till now between AF SDK call and PSE. The AF SDK call still seeing 182. Qustions -------- 1) Is this a bug in AF SDK call? Or PSE? 2) I want to use the same code or logic used by PSE so that I won't see this 182 in AF SDK calls even though down the road for whatever reason that we ran into scenario #3 in production? Many thanks!
                                    • Re: PI System Explorer\AF SDK tree structure caching
                                      ChewCheeLim

                                      here is the _SB table image

                                        • Re: PI System Explorer\AF SDK tree structure caching
                                          ChewCheeLim

                                          recopy the above post. For some reason hard to read with missing line feed at each row.

                                           

                                          Chris,

                                           

                                          We had a debug session with our client today and found out the following:-

                                           

                                          1) Client Dev environment has only 1 of AF Server running. There is no primary or secondary HA set up.

                                           

                                          2) We were able to produce 2 elements with the same name @ same level. Here are the steps.

                                           

                                                        (a) Launched PSE & custom app. Both using SAME AF DB - 'TEST01'. left both running.

                                           

                                                        (b) Custom APP - AF SDK- Created element named '67', did a db checkin in code. Checked-in successfully.

                                           

                                                        (c) PSE: (without refreshing) created element also named '67' and checked in successfully.

                                           

                                                        (e) PSE: (Hit refresh button) : 2 elements with same named created. see attachment.

                                           

                                                        (d) PSE: Deleted both elements and checked in successfully. Both elements deleted okay.

                                           

                                          3) Initially step #2 was done with element named 182. Both were created. Didn't capture any images. When we were trying to delete elements, we received some errors in PSE complaining about Key or GUID ids not unique during check-in (sorry, we didn't get a screen on that). We clicked ok  & continued. Both elements with named 182 were gone in PSE. Even we refreshed the screen.

                                           

                                              BUT, Custom App- AF SDK calls still seeing this 182. We digged into PIFD SQL DB, we found out there are 3 tables.

                                           

                                                AFElement

                                           

                                                AFElement_AT

                                           

                                                AFElement_SB

                                           

                                          the 182 element still hanging around _SB table. (see another attachement)

                                           

                                          So this test #3 gives a data discrepancy problem till now between AF SDK call and PSE. The AF SDK call still seeing 182.

                                           

                                          Qustions

                                           

                                          --------

                                           

                                          1) Is this a bug in AF SDK call? Or PSE?

                                           

                                          2) I want to use the same code or logic used by PSE so that I won't see this 182 in AF SDK calls even though down the road for whatever reason that we ran into scenario #3 in production?

                                           

                                          Many thanks!