Re: [play-2.1-10112012] Each request triggers reload

[Eric Jain]

Does this problem persist after doing a `play clean-all`?


On Tuesday, October 30, 2012 3:56:22 AM UTC-7, Dirk Louwers wrote:

Hi,

I am toying around with Play 2.1 and noticed that all requests (including every single asset request) trigger a recompile on my Mac, even when nothing has changed. Interestingly a colleague used the same project on his Ubuntu machine and didn't have this issue. Hope anyone has a clue as to what could be causing this.

Best,

Dirk 

[Eric Jain]

On Wed, Oct 31, 2012 at 6:23 AM, Dirk Louwers
<dirk.l...@stormlantern.nl> wrote:
> I have run sbt clean and clean-files and deleted the directories that the clean command should. I guess it's worth noting that I am using Play from sbt.

`clean-all` might delete more files than `clean` or `clean-files`? In
any case, if you managed to reproduce the problem on a second machine
from a fresh checkout, this isn't likely to be the problem.

[James Roper]

Actually we've just started noticing a similar issue on an internal project at Typesafe, I'm about to take a deeper look into it, stay tuned.

[Dirk Louwers]

Ok, looking forward to your findings.

Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper het volgende:

[James Roper]

Hi Dirk,

What is the result of the reload each time?  Is it a compilation failure?  Or does it successfully reload the app?  I think the issue we were seeing was actually due to a polling script, when compilation failed, each subsequent request would trigger a recompile, but that's by design, so there's no issue there.  If that's different to your issue, then could you paste the logs of a full reload loop?

Cheers,

James

[Dirk Louwers]

Hi James,

There is no compilation failure. It successfully reloads the app. It just does that for every single request. I have set all log-levels to DEBUG and get the following:

2012-11-02 11:23:20,178 - [DEBUG] - from play in play-akka.actor.default-dispatcher-5 

Plugin [play.api.db.BoneCPPlugin] is disabled

2012-11-02 11:23:20,179 - [DEBUG] - from play in play-akka.actor.default-dispatcher-5 

Plugin [play.api.db.evolutions.EvolutionsPlugin] is disabled

2012-11-02 11:23:20,195 - [INFO] - from play in play-akka.actor.default-dispatcher-5 

Application started (Dev)

2012-11-02 11:23:22,366 - [DEBUG] - from play in play-akka.actor.default-dispatcher-5 

Plugin [play.api.db.BoneCPPlugin] is disabled

2012-11-02 11:23:22,367 - [DEBUG] - from play in play-akka.actor.default-dispatcher-5 

Plugin [play.api.db.evolutions.EvolutionsPlugin] is disabled

2012-11-02 11:23:22,395 - [INFO] - from play in play-akka.actor.default-dispatcher-5 

Application started (Dev)

2012-11-02 11:23:24,951 - [DEBUG] - from play in play-akka.actor.default-dispatcher-5 

Plugin [play.api.db.BoneCPPlugin] is disabled

2012-11-02 11:23:24,951 - [DEBUG] - from play in play-akka.actor.default-dispatcher-5 

Plugin [play.api.db.evolutions.EvolutionsPlugin] is disabled

2012-11-02 11:23:24,975 - [INFO] - from play in play-akka.actor.default-dispatcher-5 

Application started (Dev)

etc. for each separate request

Best,

Dirk

Op vrijdag 2 november 2012 06:34:29 UTC+1 schreef James Roper het volgende:

[Dirk Louwers]

Further research has shown that on every request a single specific template gets recompiled, even when it hasn't been changed. If we delete said template the website doesn't reload every time. If we re-add it the problem pops-up again. There are no outside processes changing the template file but changes are detected none the less.

Setting logging to TRACE does not expose the reason why it is constantly recompiling this template. 

Op vrijdag 2 november 2012 06:34:29 UTC+1 schreef James Roper het volgende:

[Manuel Bernhardt]

Hi,

Which version of OS X do you have?

Manuel

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/Tmvsl1Y4zNcJ.
>
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.

[Dirk Louwers]

Hi,

10.7.5 and 10.6.8 both have this issue.

Best,

Dirk

Op vrijdag 2 november 2012 12:43:53 UTC+1 schreef Manuel Bernhardt het volgende:

[Manuel Bernhardt]

Hi Dirk,

- do you have anything special set-up in regards to your drives? Do
you perhaps use some kind of encryption?
- what are the file permissions on that template file?

Manuel

> https://groups.google.com/d/msg/play-framework/-/_nYlJtLSZTsJ.

[Dirk Louwers]

Hi,

Nothing special set up.

Permissions are: 

-rw-r--r--  1 dirk  staff  13958 31 okt 16:16 template.scala.html

Same as all the other templates.

Dirk

Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het volgende:

[Guillaume Bort]

Can you check if there is any special/hidden char in this file that could corrupt the HASH computation in some way? The template are recompiled if the template compiler decide that the content changed. To know that it uses a content HASH that is stored into the generated scala source file.

Check into target/scala-2.x.x/src_managed/main/views/html/....

The generated file should contain something like:

/*

    -- GENERATED --

    DATE: Fri Nov 02 10:38:00 CET 2012

    SOURCE: /private/tmp/doc-review/app/views/index.scala.html

    HASH: a9468e14516db88237e3431e8b54cf7780705202

    MATRIX: 505->1|599->18|636->21|671->48|710->50|755->61|769->67|807->84

    LINES: 19->1|22->1|24->3|24->3|24->3|26->5|26->5|26->5

    -- GENERATED --

*/ 

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/mEWsAVAlERMJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
Guillaume Bort, http://guillaume.bort.fr

[Dirk Louwers]

The hash in the generated code does not vary. So unless it uses two different hash methods it should not detect the file as changed. Visual scan of the template shows no special characters. All characters are ASCII. The only situation I can think of where a different hash value is produced is when MessageDigest#digest is accessed asynchronously...

Op vrijdag 2 november 2012 13:32:38 UTC+1 schreef Guillaume Bort het volgende:

[Guillaume Bort]

Could you try to debug or add a few traces here:

https://github.com/playframework/Play20/blob/master/framework/src/templates-compiler/src/main/scala/play/templates/ScalaTemplateCompiler.scala#L108

There is probably something wrong with that.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/unC8rBrK_7wJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[Guillaume Bort]

Well looking at the code, it could have something to do with encoding. The `byteArray` call don't specify the encoding to use. Perhaps for any reasons this encoding change during the generation and the check phases.

[Gustavo Hexsel]

  Can you check the case of the original and generated files?  

  I had colleagues that had similar issues with SVN clashing because the Mac filesystem was not set to be case-sensitive and some file had its name modified on the server from Somethinga to SomethingA.  Every "svn update" failed.

[Dirk Louwers]

The case is the same. Namely all lowercase.

Op vrijdag 2 november 2012 15:59:44 UTC+1 schreef Gustavo Hexsel het volgende:

[Dirk Louwers]

Well, I am using the 2.1-10112012 sbt plugin. I don't know what version of the libraries it pulls in but it doesn't include the sources. I could clone master and try to reproduce in a unit test though.

Op vrijdag 2 november 2012 15:52:49 UTC+1 schreef Guillaume Bort het volgende:

[Dirk Louwers]

After manually hashing the template using OpenSSL it appears that the HASH value written into the template is incorrect. For other templates it is fine. Looking at the differences, the template compiler writes hash value as Path(source).string while it is being compared to Path(source).byteArray.

Op vrijdag 2 november 2012 15:54:51 UTC+1 schreef Guillaume Bort het volgende:

[Dirk Louwers]

After manually hashing the template using OpenSSL it appears that the HASH value written into the template is incorrect. For other templates it is fine. Looking at the differences, the template compiler writes hash value as Path(source).string while it is being compared to Path(source).byteArray.

Op vrijdag 2 november 2012 15:54:51 UTC+1 schreef Guillaume Bort het volgende:

[Dirk Louwers]

After manually hashing the template using OpenSSL it appears that the HASH value written into the template is incorrect. For other templates it is fine. Looking at the differences, the template compiler writes hash value as Path(source).string while it is being compared to Path(source).byteArray.

Op vrijdag 2 november 2012 15:54:51 UTC+1 schreef Guillaume Bort het volgende:

[Dirk Louwers]

After manually hashing the template using OpenSSL it appears that the HASH value written into the template is incorrect. For other templates it is fine. Looking at the differences, the template compiler writes hash value as Path(source).string while it is being compared to Path(source).byteArray.

Op vrijdag 2 november 2012 15:54:51 UTC+1 schreef Guillaume Bort het volgende:

[Dirk Louwers]

After manually hashing the template using OpenSSL it appears that the HASH value written into the template is incorrect. For other templates it is fine. Looking at the differences, the template compiler writes hash value as Path(source).string while it is being compared to Path(source).byteArray.

Op vrijdag 2 november 2012 15:54:51 UTC+1 schreef Guillaume Bort het volgende:

[Guillaume Bort]

Oh. But then I think this issue is fixed in master since a long time.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/HPwm73NFhwcJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[Dirk Louwers]

Sorry for the multi-post earlier.

Ok, so what is the best way to get a snapshot of the sbt-plugin for my project? Like I stated earlier I am now using:

addSbtPlugin("play" % "sbt-plugin" % "2.1-10112012")

That is the most recent build I could find. Is there a 2.1-SNAPSHOT version of the plugin and if so on what repository?

Op vrijdag 2 november 2012 17:55:23 UTC+1 schreef Guillaume Bort het volgende:

[Guillaume Bort]

We will publish the 2.1-M1 in the next following days. In the meantime you can build it from source.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/i0a1yChmonsJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[Dirk Louwers]

I have gotten the plugin from the snapshot repository like so:

addSbtPlugin("play" % "sbt-plugin" % "2.1-SNAPSHOT")

This exhibits the same problem. If this is indeed that latest the problem is still present.

Op zaterdag 3 november 2012 15:56:17 UTC+1 schreef Guillaume Bort het volgende:

[peter hausel]

I would try 2.1-11022012 instead

[Dirk Louwers]

Ok, tried that, still the same issue.

Op zaterdag 3 november 2012 18:54:52 UTC+1 schreef peter hausel het volgende:

[James Roper]

Any idea which file it's compiling?  Maybe find the file with the most recent modification date in the target directory...  What is its modification date?

On Friday, 16 November 2012 14:11:57 UTC+11, Kevin Bowling wrote:

I'm seeing a (RELOAD) loop on Linux with SNAPSHOT current as of this post's timestamp.

The first big compile after a complete clean has this:
[warn] there were 8 feature warnings; re-run with -feature for details
[warn] one warning found

Then each additional request does
[info] Compiling 1 Scala source to /home/kev009/c/xx/xx/target/scala-2.10/classes...

I use dynamic LESS compilation.  Related to recent incremental switch there?

Regards,
Kevin

[Dirk Louwers]

I have a template file that seems to reliably trigger this behavior that I could mail you off list if you like.

Op vrijdag 16 november 2012 09:44:50 UTC+1 schreef James Roper het volgende:

[James Roper]

You could send that to me at james dot roper at typesafe dot com, but I'm more interested in the modification time of the template.  Does changing the template stop it from happening?

[Dirk Louwers]

No it does not, it looks like there is something else causing the false hash to be stored. Seems it's more something in the line of something specific in the content but I haven't been able to isolate it so far.

2012/11/17 James Roper <jro...@gmail.com>

--
 
 

[James Roper]

This has now been fixed, pending merge of this pull request to master:

https://github.com/playframework/Play20/pull/550

For anyone that is encountering this issue, the root cause is actually non UTF-8 characters in your templates.  Common culprits are ISO8859-1 curly quotes (0x91, 0x92, 0x93, 0x94), and ISO8859-1 en-dash and em-dash (0x96 and 0x97).  Play reads template files as UTF-8, so these characters are going to result in corrupted compiled templates, with strange characters appearing in the rendered page, so more important than getting this fix into Play is for you to remove/replace these characters from your templates.

[Dirk Louwers]

Cool. Great to hear this. 

2012/11/19 James Roper <jro...@gmail.com>

--
 
 

[Dirk Louwers]

Well, I have thoroughly checked and the files with the wrong hashes do indeed have non-ASCII characters, however they are UTF-8, like …, ë and é. If I remove the UTF-8 characters the problem is resolved. However, looking at the pull request this should also be fixed when it's been merged.

Op maandag 19 november 2012 11:00:47 UTC+1 schreef James Roper het volgende:

[James Roper]

Hmmm... I can't reproduce that.  Are you using a custom script to launch Play?  The only way I think this could be an issue is if the default platform encoding was not UTF-8, but the play script specifies -Dfile.encoding=UTF-8 when it launches SBT, so that could never be an issue.

Anyway, like you said, my fix should fix everything, since it only ever hashes the raw bytes from the files.

[Dirk Louwers]

Well, that must be it then. I am running directly from SBT and will likely use Mac-Roman by default on my system. I'll use the file encoding switch in my sbt launcher for now. Am I right to assume that this switch is no longer going to be necessary once this fix has been merged? 

Op dinsdag 20 november 2012 00:13:57 UTC+1 schreef James Roper het volgende:

[James Roper]

On Wednesday, 21 November 2012 00:18:54 UTC+11, Dirk Louwers wrote:

Well, that must be it then. I am running directly from SBT and will likely use Mac-Roman by default on my system. I'll use the file encoding switch in my sbt launcher for now. Am I right to assume that this switch is no longer going to be necessary once this fix has been merged?

Yes and no.  The bug will be fixed, so you won't get the infinite reloading.  But we don't test or run Play without this flag, and the rule in Play is that everything is UTF-8 (which is why we add the flag to the play script), so there could be other existing bugs or bugs introduced in future that will slip through our testing that you may encounter if your platform encoding is not UTF-8.

[Dirk Louwers]

Ok, in that case I would like to suggest to read the set encoding during startup and terminate Play with an error if the set encoding isn't UTF-8 with the advise to supply this option. No harm in doing that if it's a hard requirement anyway. Might prevent issues that are hard to debug.

2012/11/21 James Roper <jro...@gmail.com>

--
 
 

[Pedro De Almeida]

Hello James,

Do you know if your fix has been shipped with play-2.1-RC2? Because I am still experiencing this issue with the RC2: every time I edit a compilable file (*.scala, *.html.scala, *.less), it compiles resources and triggers an application reload on the next request without any kind of information or exception. By the way, is there a ticket for this issue somewhere?

 If helpful, here is more information about my context:
- Windows 8 x64, JDK 1.7.0_09, Play 2.1-RC2
- Running without specific parameters: play ~run
- No non-UTF characters found in compiled templates

Thanks a lot,

Pedro De Almeida

[Pedro De Almeida]

Any news? Seems that this issue still occurs with Play 2.1.1! Please, can someone update on this? Thanks.

Pedro De Almeida

[francis Lavalliere]

My Play  framework suddently started to reload for no reasons... only when i query a call to one of our API which uses a ProcessBuilder command (which creates files in /tmp/ )

Not sure why it reloads...

[francis Lavalliere]

I am actually using Play-2.2. RC1  but somehow it was working fine before... thats what I find strange..

[Shawn Vader]

I have had the same issue and I tracked the problem down to something very stupid on my side. 

I was uploading images and putting them in the play directory so it was obviously compiling as it was getting new directories and files.