Skip to main content
VinayVaidya12-Amethyst
12-Amethyst
October 5, 2015
Solved

How do extensions know about Thingworx webapp unload?

So that they can initiate necessary cleanup, e.g. shutdown an executor

      JesseR.DockenAnswer
      1-Visitor
      December 2, 2015

      The platform doesn't provide any way for extensions to hook into the servlet unload event directly.

      That being said, what you should do is have your cleanup code tied into the logic for stopThing() if defined in a thing template, or stopSubsystem() if defined in a subsystem (the cleanup methods work as well).  When Thingworx is shut down it will attempt to stop all things and subsystems using those methods.  This also supports the scenarios where the thing or subsystem are stopped individually by the user.

      View in thread

      5 replies

      posipova20-Turquoise
      20-Turquoise
      October 5, 2015

      By the inheritance structure, running extensions are dependent on the platform rather  than the other way around. So, unless you have an external service to check for the platform unload, you cannot control the shutdown of an executor (through the extension reliability).

      Translate
      VinayVaidya12-AmethystAuthor
      12-Amethyst
      October 6, 2015

      Very well. What is the advise to handle queues within extensions in that case? Does the platform provide for them? Alternately, could the platform register a ServletContextListener that can discover implementations of an interface and execute them?

      Translate
      JesseR.Docken1-VisitorAnswer
      1-Visitor
      December 2, 2015

      The platform doesn't provide any way for extensions to hook into the servlet unload event directly.

      That being said, what you should do is have your cleanup code tied into the logic for stopThing() if defined in a thing template, or stopSubsystem() if defined in a subsystem (the cleanup methods work as well).  When Thingworx is shut down it will attempt to stop all things and subsystems using those methods.  This also supports the scenarios where the thing or subsystem are stopped individually by the user.

      Translate
      VinayVaidya12-AmethystAuthor
      12-Amethyst
      December 3, 2015

      Thanks, Jesse. That is what we did actually, it involved some reference counting but it worked. We also considered cleanUp, How does one make a decision vis-a-vis what goes into cleanUp vs StopThing, Looks like cleanUp checks isEnabled, So we thought stopThing to be safer, advice?

      Translate
      JesseR.Docken1-Visitor
      1-Visitor
      December 3, 2015

      If your thing isn't enabled, then startThing() hasn't been called yet, so you probably haven't spun up your executor thread or thread pools yet.  So either method should be safe in that respect.

      In terms of which is more correct, it really depends on the architecture of your extension.  If the threads are lightweight and can be spun up and down with little overhead (e.g., don't need to do any network handshakes), then having your logic in startThing and stopThing is fine.  If there is a lot of overhead in the startup process, then you'll want to split things out a bit.  You could create the executor thread and thread pool in initializeThing and have them begin processing in startThing, for example, then have the executor thread finish up processing and empty out the thread pool at stopThing and tear down the threads in cleanupThing.

      Translate
      Terms & ConditionsAccessibility statement