10 Replies Latest reply on Mar 18, 2011 2:14 PM by spilon

    TagSearch Dialog Freeze

    jeffjamesmcmahon

      We are using the PI.SDK for an application that uses the TagSearch Dlg to allow the user to configure which tags are included in the application.  We use the follow code (C#) to instantiate the dlg and get the points from it...

       

      TagSearch tagSearch = new TagSearchClass ();

       

      var nv = new NamedValuesClass ();
      string defaultServer = _piServerName;
      object defaultServerObj = defaultServer;
      nv.Add (defaultServer, ref defaultServerObj);

       

      _PointList points = tagSearch.Show (nv, TagSearchOptions.tsoptDisableServerPickList);

       

      ....

       

      Pretty simple stuff.  We have noticed a "pattern" in our QA cycle and wonder if anyone has seen this ?

       

      Run this code (by clicking our menu item), within the resulting TagSearch Dlg use all the defaults click search to return all tags. (Our demo server has ~6000 tags).  Pick a small subset of tags (a dozen or so) and hit ok on TagSearch.  Then run it again right away.  Try the same default search.

       

      We see the TagSearch dlg freeze.  Only the "Abort" button is enabled and the status bar shows 1% complete.  The only way we have found to exit from this state is to kill the process.

       

      I should also add that if you narrow your search ("foo*" on tag description or whatever) on your first search, then everything works as expected.  It only freezes on us when we use defaults ("*") for all fields.

       

      Are we missing some cleanup code ?  Any ideas ?

       

       

       

      Tech Details :

       

      latest released version of PI SDK, hitting PI Server 3.4.380.36

       

      1.3.8.387 for PISDK, PISDKCommon, PITimeServer, PISDK.Controls.PISDKCtrlDlg

       

      1.6.0.361 for PISDKCtl, PISDKDlg

       

       

       

       

       

      Thanks

       

      Jeff

        • Re: TagSearch Dialog Freeze

          If you hit the Abort button, do you get any results back?

           

          Is your application launching this dialog in an STA thread or MTA thread?

            • Re: TagSearch Dialog Freeze
              wenqian

              Charles Henze

              If you hit the Abort button, do you get any results back?
              No. The dialog is still freeze with Abort button disabled too. No results are returned.

               

              Charles Henze

              Is your application launching this dialog in an STA thread or MTA thread?
              STA thread.

                • Re: TagSearch Dialog Freeze
                  wenqian

                  Any idea and help on this issue? Thanks.

                    • Re: TagSearch Dialog Freeze

                      I'll attempt to reproduce this behavior today and let you know.  If you use DbgView and turn on PISDK tracing (from the AboutPI-SDK menus, verbose level; depth 50), we can hopefully see what GetPoints is doing on the second and subsequent calls.

                        • Re: TagSearch Dialog Freeze
                          wenqian

                          Thanks, Charlie. I tried your suggestions but seems there is no information from PI-SDK when  I run the app around the tag search dialog. Here is the output:

                           

                           

                           

                          7563.DbgView.jpg

                            • Re: TagSearch Dialog Freeze

                              Could you please export the output to a text file for completeness?  The snapshot you show indicates two different processID's, each of which does not make a GetPoints query.  If you attache the log file and indicate the wall clock time when the dialog first gets into the state you mention at the top, I can better see the sequence.

                                • Re: TagSearch Dialog Freeze
                                  wenqian

                                  Thanks, Charles. I started the application and re-collected the logs from scratch. I did two tag searches. The first one successed (usually, the first one always successes). it started at around 4:01:31 pm (the 231th entry in the log). The second one failed (the dialog freeze). It starts around 4:02:16 pm (the 2072th entry in the log).

                                   

                                  At 4:03:06pm (the 2084 entry in the log), I clicked the About button and then the Close button to dismiss the dialog.

                                   

                                  The log file:[View:http://vcampus.osisoft.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/8/4061.dbgview.log:550:0]

                                    • Re: TagSearch Dialog Freeze

                                      I suspected it was a PISDK bug that has been encountered, and your trace log confirms that this problem is occuring: "22196OSI8: Background thread queues locked after PISDK wind down and restart."  If these messages show up in the trace log, then you will not be able to do additional asynchronous calls:

                                       

                                      OBJ:ENTRY (7412)[mSTA] Level(001) ReleaseSessionMgr refcnt 0, stopping threads

                                       

                                       GEN:ENTRY (7412)[mSTA] Level(001) Deleting PISessionMgr

                                       

                                       GEN:EXIT  (7412)[mSTA] Level(001) Deleting PISessionMgr 2684

                                       

                                      OBJ:EXIT  (7412)[mSTA] Level(001) ReleaseSessionMgr refcnt 0, stopping threads

                                       

                                      The workaround, until a fix is released, is to keep at least one PISDK object reference for the duration of your program.  This has the advantage of eliminating the creation and deletion of background threads and other internal resources used in the PISDK library.

                                       

                                      Here is the full release note description:

                                       

                                      "The SDKQueueThread, used for asynchronous calls, windows events using  cross thread connection points and reconnections, was changed in 1.3.8.387 to clear the queue of work for the thread when the threads were stopped as the last instance of a PISDK was winding down.  The clear call locked the queue before clearing but never released the lock.  Subsequent PISDK hierarchies built in the same application instance could not add items to the queue.  For example starting a PISDK hierarchy and making an asynchronous call, then completely letting go of all PISDK objects, then creating another PISDK hierarchy and attempting an asynchronous call would fail.  The result of the second asynchronous call would never be posted to the queue to be processed.  A caller waiting for the PIAsynchStatus object in this example would never see the status move to completion or error. "