indication when grails is done auto-reloading

[talldave]

i talked to graeme at lunch during the GR8 conf in minneapolis last week about auto-reloading weirdness we've seen. he said that when that weirdness happens, it's most likely from hitting the app too soon - that the auto-reloading has not yet completed.  however, he also said that currently there's no way to tell when the auto-reloading has completed - "compiling x source files" isn't it.

i'd also be happy to file a jira to include a println on reload completion (and perhaps eventually a resources plugin-esque browser notification), but first wanted to see if anyone could help me determine where in the source auto-reloading is triggered.  i've been looking at the org.codehaus.groovy.grails.compiler package (in grails-core/src/main/groovy), but wonder if reloading is at least partially handled by a lower-level spring package.

i'd like to do as much as i can to submit a solution along with the jira instead of just identifying it as a problem.

thanks!

[Andy Clement]

Hi,

Some info on the process...

Right now the reloading java agent has a thread watching the disk.
Once compilation completes the thread notices the new class files and
they are reloaded (there is no direct communication right now).  The
thread sleep is currently 1100ms between checks, so it can take up to
1100ms after compilation finishes before reloading starts to kick in.

The agent originally did log out as it reloaded classes but we decided
that was too messy in the grails output.

I think there is a crude way you can see the reload messages by
switching the agent into verbose mode. In startGrails you can change
this line:
SPRINGLOADED_PARAMS="$SPRINGLOADED_PARAMS;cacheDir=$GRAILS_AGENT_CACHE_DIR"
to
SPRINGLOADED_PARAMS="$SPRINGLOADED_PARAMS;cacheDir=$GRAILS_AGENT_CACHE_DIR;verbose=true"

but you'll also see a bunch of other messages (I'm only suggesting it
as a way to investigate to see if your problem is to do with not
waiting for reload to finish).

It is also possible to register a reload event processor plugin that
gets called on a reload event, I think grails already does that
somewhere.

cheers,
Andy

On 10 August 2012 10:43, talldave <[hidden email]> wrote:

> i talked to graeme at lunch during the GR8 conf in minneapolis last week
> about auto-reloading weirdness we've seen. he said that when that weirdness
> happens, it's most likely from hitting the app too soon - that the
> auto-reloading has not yet completed.  however, he also said that currently
> there's no way to tell when the auto-reloading has completed - "compiling x
> source files" isn't it.
>
> i'd also be happy to file a jira to include a println on reload completion
> (and perhaps eventually a resources plugin-esque browser notification), but
> first wanted to see if anyone could help me determine where in the source
> auto-reloading is triggered.  i've been looking at the
> org.codehaus.groovy.grails.compiler package (in
> grails-core/src/main/groovy), but wonder if reloading is at least partially
> handled by a lower-level spring package.
>
> i'd like to do as much as i can to submit a solution along with the jira
> instead of just identifying it as a problem.
>
> thanks!
>
>
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/indication-when-grails-is-done-auto-reloading-tp4633048.html
> Sent from the Grails - dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[talldave]

awesome, thanks for the tips!  this will definitely get me started - i'll see what i can figure out and if there's perhaps a good (non-messy) way to indicate that it's safe to resume using the app and weirdness should be minimized.  :)

[Marc Palmer Local]

Hi,

I looked at this in the past. The problem is that there is no "all onChange have completed" notification from Grails.

I have a local dev plugin that shows when Grails is reloading, but it has to use a timer to set the "traffic light" indicator I have to green, after a set time for this reason.

Ideally we'd have an onChangeCompleted event sent to all plugins.

Notice also that Resources plugin suffers this - if you have a slow reload it has to use HTTP refresh to reload the warning page until the processing is complete.



Marc

~ ~ ~
Marc Palmer
Freelancer (Grails/Groovy/Java/UX)

I offer commercial support for Grails plugins from as low as $50/mo.
For details see: http://grailsrocks.com

Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc
Contributor @ http://grails.org |  Founder @ http://noticelocal.com
Developer @ http://weceem.org | Member @ http://spottymushroom.com
Twitter: http://twitter.com/wangjammer5 


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[talldave]

andy and marc -

thanks for your feedback and input.  andy, i found this discussion:

http://forum.springsource.org/showthread.php?107509-java-agent-based-reloading

which gives some background on the springloaded jar.  however, it doesn't look like that package is open source, is it?  especially given that it's com.springsource instead of org.springsource?  without the source it's certainly more difficult to figure out what's going on behind the scenes.  :)  

i haven't yet experimented with trying to register my own reload agent, but based on your explanation of timing and disk watching, i can see why there isn't exactly a "complete" event, just a "i've done everything i need to do until the next check 1100ms from now" status.

given that, marc, if grails did fire a "all onChange have completed" event, would that really help?  we'd still need to wait for the springloaded agent to pick up and reload those changes.  maybe grails and the reload agent are more tightly coupled than i'm thinking, but my impression is they run pretty separately from each other.

i am curious to hear more about your local traffic light plugin, and will take a look at the resources plugin source to see how the timer and warning there works.

i did add "verbose=true" to the startup script per andy's suggestion, and see the additional output.  it looks like all the lines start with "SERIOUS WARNING" or "Reloading:" though, so it should be pretty easy to suppress or minimize that output.  for instance, all the "serious warning" lines are at startup and complaining about grails artefacts that i probably don't care about - i'd be tempted to remove those from the output altogether.  the "reloading" ouput happens post-recompilation - those could be compressed to one line ala "| Compiling 2 source files" and "| Compiling 2 source files...".  

that's not perfect - it would obviously be better to have "wait until reloaded!  ok, now it's ok to go ahead.", but at least some output to indicate this second step is happening would be better than the current "pay no attention to the man behind the curtain" lack of any indicator.  :)