Torque
  1. Torque
  2. TORQUE-163

Map builders are emptied on Torque.shutdown() and not rebuilt on subsequent init()

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.3
    • Fix Version/s: 4.0-beta1
    • Component/s: None
    • Labels:
      None

      Description

      Problem: After a shutdown() and init() of Torque, the Map Builder cache entries which have been present before shutdown are not present anymore after a new init.

      Analysis: If a Peer class is loaded, it registers its map builder and the MapBuilder is built immediately or on Torque initialisation, depending on whether Torque is initialized or not.
      On Torque.shutdown(), all known map builders are removed.
      On a new init(), these Map builders will not be rebuilt anew because the Peer class will not be loaded a second time.

      Solution: The Map Builder cache entries should not be removed on Torque.shutdown()

        Activity

        Hide
        Thomas Vandahl added a comment -

        Actually, the code in TorqueInstance.java (line 164ff) was supposed to handle (or rather work around) a similar case. Obviously, the removal of the cache entry in line 691 breaks this intention. Torque has no means of knowing which peers actually exist right now. Do we want to change that? It would probably have lots of implications.

        Bye, Thomas.

        Show
        Thomas Vandahl added a comment - Actually, the code in TorqueInstance.java (line 164ff) was supposed to handle (or rather work around) a similar case. Obviously, the removal of the cache entry in line 691 breaks this intention. Torque has no means of knowing which peers actually exist right now. Do we want to change that? It would probably have lots of implications. Bye, Thomas.
        Hide
        Thomas Fox added a comment -

        This is not a problem as the Database maps are not emptied on shutdown either.
        The only purpose of the map builders is to populate the database map, so if they remain it is ok if the map builder cache is emptied.

        Show
        Thomas Fox added a comment - This is not a problem as the Database maps are not emptied on shutdown either. The only purpose of the map builders is to populate the database map, so if they remain it is ok if the map builder cache is emptied.
        Hide
        Thomas Fox added a comment -

        I'll add a test case anyway

        Show
        Thomas Fox added a comment - I'll add a test case anyway
        Hide
        Thomas Fox added a comment -

        In an exotic use case the problem exists.
        I have a normal TorqueInstance and init() and shutdown() it. Then I start a Avalon TorqueComponent. This component copies all registered Map builders from the normal TorqueInstance and rebuilds them. However, the previous shutdown on the TorqueInstance has emptied the map builder cache so the avalon component has no map builder components to build. Also the peer classes are all already loaded from previous usages so they will not register again to the avalon component. So the avalon component has an empty database map and will not work correctly.

        This exotic case happens when running the torque test project in eclipse.
        As a solution, I propose to not empty the map builder cache on shutdown. This will have no implication on normal init/shutdown cycles as the cached map builders know that they are built and will not build again, but will fix the above use case.

        Show
        Thomas Fox added a comment - In an exotic use case the problem exists. I have a normal TorqueInstance and init() and shutdown() it. Then I start a Avalon TorqueComponent. This component copies all registered Map builders from the normal TorqueInstance and rebuilds them. However, the previous shutdown on the TorqueInstance has emptied the map builder cache so the avalon component has no map builder components to build. Also the peer classes are all already loaded from previous usages so they will not register again to the avalon component. So the avalon component has an empty database map and will not work correctly. This exotic case happens when running the torque test project in eclipse. As a solution, I propose to not empty the map builder cache on shutdown. This will have no implication on normal init/shutdown cycles as the cached map builders know that they are built and will not build again, but will fix the above use case.
        Hide
        Thomas Vandahl added a comment -

        Agreed. The general idea of the Avalon lifecycle contract is the symmetry of initialize/dispose, start/stop etc. So the requirement would be that dispose() or shutdown() left the component or instance in the same state as it was before the first initialize() or init(). Clearly this doesn't work the way Torque is designed right now. Nevertheless, my humble opinion is that we should strive to remove as much static stuff as possible from Torque to reach that goal one day. A clean lifecycle is a Good Thing(TM), be it Avalon or not.

        Show
        Thomas Vandahl added a comment - Agreed. The general idea of the Avalon lifecycle contract is the symmetry of initialize/dispose, start/stop etc. So the requirement would be that dispose() or shutdown() left the component or instance in the same state as it was before the first initialize() or init(). Clearly this doesn't work the way Torque is designed right now. Nevertheless, my humble opinion is that we should strive to remove as much static stuff as possible from Torque to reach that goal one day. A clean lifecycle is a Good Thing(TM), be it Avalon or not.
        Hide
        Thomas Fox added a comment -

        I agree. But changing the peer registration process means a lot of concept-thinking and testing.
        For now I'm content to just make the eclipse test work.

        Show
        Thomas Fox added a comment - I agree. But changing the peer registration process means a lot of concept-thinking and testing. For now I'm content to just make the eclipse test work.

          People

          • Assignee:
            Thomas Fox
            Reporter:
            Thomas Fox
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development