Uploaded image for project: 'Trapperkeeper'
  1. Trapperkeeper
  2. TK-380

jruby-utils: Add a stop lifecycle function



    • Type: Task
    • Status: Closed
    • Priority: Normal
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Template:
    • Sub-team:


      From Chris Price, https://github.com/puppetlabs/jruby-utils/pull/10/files#r65642349:

      When the pool falls out of scope without being shut down, and without having all of its instances returned to it, what happens? I feel like we had some tests in the past where not cleaning up the pool properly before letting the test exit meant that there were still threads doing things in the background after the test ran, and that could cause problems with subsequent tests. I don't think that's the case here, but thought it was worth mentioning. I'd probably consider it 'best practice' to do a blocking shutdown of any pool that you create in a test before exiting from the test block, but if there are a ton of tests that would need to be updated for that, I don't know that I'd block the PR on it.

      I think we got away with this a little more easily with the old service because it had a stop lifecycle function that would automatically get called by TK when we exited the with-app-with-config block of the test, and that would shut the pool down.

      Raises the question of whether or not the new pool manager service should have a stop lifecycle that tries to clean up pools that haven't been cleaned up by the time it runs... but that definitely seems like a separate chunk of work.

      This ticket is to determine whether the pool manager service should a stop lifecycle that cleans up non-cleaned-up pools by the time it runs, and if so, to implement it.


          Issue Links



              ruth Ruth Linehan
              0 Vote for this issue
              1 Start watching this issue



                  Zendesk Support