Grails
  1. Grails
  2. GRAILS-9509

Domain objects not reloaded when changed.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.4, 2.1.1, 2.2-RC1
    • Fix Version/s: 2.2-RC3
    • Component/s: None
    • Labels:
    • Environment:
      Mac Mountain Lion OSX 10.8.2

      Description

      When changing fields in domain class, it recompiles the class but the app does not reflect the updates.

      Thought that domains were supposed to reflect updates in 2.x? Apologies if this is not a feature.

      Detailed steps to reproduce attached.

        Issue Links

          Activity

          Hide
          Scott Eisenberg added a comment -

          Have problem on:
          Mac 10.8.2
          java version "1.6.0_37"
          Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
          Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)

          Show
          Scott Eisenberg added a comment - Have problem on: Mac 10.8.2 java version "1.6.0_37" Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909) Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)
          Hide
          Andy Clement added a comment -

          Ok, the problem here is stale JVM state that isn't quite cleared up properly on reload. I will put the change into springloaded to tidy this state up but the very simplest fix for grails (given that it is already in RC phase) is to add a single line to clear the cache from the reload plugin. The fix is to modify GrailsPluginManagerReloadPlugin.reloadEvent(), remove the sleep and change it to:

          public void reloadEvent(String typename, Class<?> aClass, String encodedTimestamp) {
                  CachedIntrospectionResults.clearClassLoader(aClass.getClassLoader());
                  ClassPropertyFetcher.clearClassPropertyFetcherCache();
                  if (GrailsProjectWatcher.isActive()) {
                      Introspector.flushFromCaches(aClass);
                      GrailsProjectWatcher.firePendingClassChangeEvents(aClass);
                  }
          }
          

          The call to Introspector is the important call. The reason it looks a bit timing related is that weak reference maps are being used - when they are cleared up is a bit 'random' and it looks like the inclusion of a delay waits enough time that the refs will naturally disappear via GC. Calling Introspector flush will more pro-actively clean them up. This mechanism changed in Java7, hence you don't see the problem there.

          Show
          Andy Clement added a comment - Ok, the problem here is stale JVM state that isn't quite cleared up properly on reload. I will put the change into springloaded to tidy this state up but the very simplest fix for grails (given that it is already in RC phase) is to add a single line to clear the cache from the reload plugin. The fix is to modify GrailsPluginManagerReloadPlugin.reloadEvent(), remove the sleep and change it to: public void reloadEvent( String typename, Class <?> aClass, String encodedTimestamp) { CachedIntrospectionResults.clearClassLoader(aClass.getClassLoader()); ClassPropertyFetcher.clearClassPropertyFetcherCache(); if (GrailsProjectWatcher.isActive()) { Introspector.flushFromCaches(aClass); GrailsProjectWatcher.firePendingClassChangeEvents(aClass); } } The call to Introspector is the important call. The reason it looks a bit timing related is that weak reference maps are being used - when they are cleared up is a bit 'random' and it looks like the inclusion of a delay waits enough time that the refs will naturally disappear via GC. Calling Introspector flush will more pro-actively clean them up. This mechanism changed in Java7, hence you don't see the problem there.
          Hide
          Jeff Scott Brown added a comment -

          I have made this change and it looks promising. For all of the scenarios that I have tested, the reloading consistently misbehaves without this change and consistently behaves with this change.

          Andy, thanks a lot for digging into this.

          Show
          Jeff Scott Brown added a comment - I have made this change and it looks promising. For all of the scenarios that I have tested, the reloading consistently misbehaves without this change and consistently behaves with this change. Andy, thanks a lot for digging into this.
          Hide
          Graeme Rocher added a comment -

          Can the issue be closed then?

          Show
          Graeme Rocher added a comment - Can the issue be closed then?
          Hide
          Jeff Scott Brown added a comment -

          As far as I can see, yes. I will go ahead and close it. If anything comes up in testing we can revisit.

          Show
          Jeff Scott Brown added a comment - As far as I can see, yes. I will go ahead and close it. If anything comes up in testing we can revisit.

            People

            • Assignee:
              Graeme Rocher
              Reporter:
              Scott Eisenberg
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development