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.
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.
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.
This did not help and I can confirm the issue is there on two different Macs.
Op woensdag 31 oktober 2012 00:06:42 UTC+1 schreef Eric Jain het volgende:
> 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.
<dirk.louw...@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.
On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
> 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.
> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
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?
On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
> Ok, looking forward to your findings.
> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper het > volgende:
>> 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.
>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
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:
> 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
> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>> Ok, looking forward to your findings.
>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper het >> volgende:
>>> 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.
>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
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:
> 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
> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>> Ok, looking forward to your findings.
>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper het >> volgende:
>>> 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.
>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
<dirk.louw...@stormlantern.nl> wrote:
> 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:
>> 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
>> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>> Ok, looking forward to your findings.
>>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper het
>>> volgende:
>>>> 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.
>>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
> To post to this group, send email to play-framework@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framework+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers > <dirk.l...@stormlantern.nl <javascript:>> wrote: > > 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:
> >> 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
> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
> >>> Ok, looking forward to your findings.
> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper het > >>> volgende:
> >>>> 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.
> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
- 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?
> Op vrijdag 2 november 2012 12:43:53 UTC+1 schreef Manuel Bernhardt het
> volgende:
>> Hi,
>> Which version of OS X do you have?
>> Manuel
>> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers
>> <dirk.l...@stormlantern.nl> wrote:
>> > 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:
>> >> 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
>> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>> >>> Ok, looking forward to your findings.
>> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper het
>> >>> volgende:
>> >>>> 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.
>> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>> > 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.
> To post to this group, send email to play-framework@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framework+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
> - 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
> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers > <dirk.l...@stormlantern.nl <javascript:>> wrote: > > 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:
> >> Hi,
> >> Which version of OS X do you have?
> >> Manuel
> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers > >> <dirk.l...@stormlantern.nl> wrote: > >> > 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:
> >> >> 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
> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
> >> >>> Ok, looking forward to your findings.
> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper het > >> >>> volgende:
> >> >>>> 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.
> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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
> >> > -- > >> > 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.
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/....
> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het
> volgende:
>> 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
>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers
>> <dirk.l...@stormlantern.nl> wrote:
>> > 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:
>> >> Hi,
>> >> Which version of OS X do you have?
>> >> Manuel
>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers
>> >> <dirk.l...@stormlantern.nl> wrote:
>> >> > 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:
>> >> >> 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
>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>> >> >>> Ok, looking forward to your findings.
>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper
>> het
>> >> >>> volgende:
>> >> >>>> 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.
>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
> To post to this group, send email to play-framework@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framework+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
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:
> 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:
>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het >> volgende:
>>> 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
>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers >>> <dirk.l...@stormlantern.nl> wrote: >>> > 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:
>>> >> Hi,
>>> >> Which version of OS X do you have?
>>> >> Manuel
>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers >>> >> <dirk.l...@stormlantern.nl> wrote: >>> >> > 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:
>>> >> >> 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
>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>> >> >>> Ok, looking forward to your findings.
>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper >>> het >>> >> >>> volgende:
>>> >> >>>> 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.
>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>> To post to this group, send email to play-fr...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> play-framewor...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/play-framework?hl=en.
> 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:
>> 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:
>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het
>>> volgende:
>>>> 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
>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers
>>>> <dirk.l...@stormlantern.nl> wrote:
>>>> > 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:
>>>> >> Hi,
>>>> >> Which version of OS X do you have?
>>>> >> Manuel
>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers
>>>> >> <dirk.l...@stormlantern.nl> wrote:
>>>> >> > 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:
>>>> >> >> 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
>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>> >> >>> Ok, looking forward to your findings.
>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper
>>>> het
>>>> >> >>> volgende:
>>>> >> >>>> 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.
>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>> 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<http://groups.google.com/group/play-framework?hl=en>
>>> .
> To post to this group, send email to play-framework@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framework+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
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.
On Fri, Nov 2, 2012 at 3:52 PM, Guillaume Bort <guillaume.b...@gmail.com>wrote:
> On Fri, Nov 2, 2012 at 2:49 PM, Dirk Louwers <dirk.louw...@stormlantern.nl
> > wrote:
>> 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:
>>> 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:
>>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het
>>>> volgende:
>>>>> 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
>>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers
>>>>> <dirk.l...@stormlantern.nl> wrote:
>>>>> > 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:
>>>>> >> Hi,
>>>>> >> Which version of OS X do you have?
>>>>> >> Manuel
>>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers
>>>>> >> <dirk.l...@stormlantern.nl> wrote:
>>>>> >> > 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:
>>>>> >> >> 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
>>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>>> >> >>> Ok, looking forward to your findings.
>>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper
>>>>> het
>>>>> >> >>> volgende:
>>>>> >> >>>> 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.
>>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>>> 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<http://groups.google.com/group/play-framework?hl=en>
>>>> .
>> To post to this group, send email to play-framework@googlegroups.com.
>> To unsubscribe from this group, send email to
>> play-framework+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/play-framework?hl=en.
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.
> On Fri, Nov 2, 2012 at 2:49 PM, Dirk Louwers <dirk.l...@stormlantern.nl<javascript:> > > wrote:
>> 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:
>>> 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:
>>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het >>>> volgende:
>>>>> 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
>>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers >>>>> <dirk.l...@stormlantern.nl> wrote: >>>>> > 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:
>>>>> >> Hi,
>>>>> >> Which version of OS X do you have?
>>>>> >> Manuel
>>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers >>>>> >> <dirk.l...@stormlantern.nl> wrote: >>>>> >> > 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:
>>>>> >> >> 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
>>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>>> >> >>> Ok, looking forward to your findings.
>>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper >>>>> het >>>>> >> >>> volgende:
>>>>> >> >>>> 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.
>>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>>> 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<http://groups.google.com/group/play-framework?hl=en> >>>> .
>> To post to this group, send email to play-fr...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> play-framewor...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/play-framework?hl=en.
> 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.
> On Friday, November 2, 2012 7:52:49 AM UTC-7, Guillaume Bort wrote:
>> Could you try to debug or add a few traces here:
>> On Fri, Nov 2, 2012 at 2:49 PM, Dirk Louwers <dirk.l...@stormlantern.nl>wrote:
>>> 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:
>>>> 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:
>>>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het >>>>> volgende:
>>>>>> 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
>>>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers >>>>>> <dirk.l...@stormlantern.nl> wrote: >>>>>> > 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:
>>>>>> >> Hi,
>>>>>> >> Which version of OS X do you have?
>>>>>> >> Manuel
>>>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers >>>>>> >> <dirk.l...@stormlantern.nl> wrote: >>>>>> >> > 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:
>>>>>> >> >> 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
>>>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>>>> >> >>> Ok, looking forward to your findings.
>>>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James >>>>>> Roper het >>>>>> >> >>> volgende:
>>>>>> >> >>>> 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.
>>>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>>>> 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<http://groups.google.com/group/play-framework?hl=en> >>>>> .
>>> 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.
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:
> On Fri, Nov 2, 2012 at 2:49 PM, Dirk Louwers <dirk.l...@stormlantern.nl<javascript:> > > wrote:
>> 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:
>>> 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:
>>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het >>>> volgende:
>>>>> 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
>>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers >>>>> <dirk.l...@stormlantern.nl> wrote: >>>>> > 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:
>>>>> >> Hi,
>>>>> >> Which version of OS X do you have?
>>>>> >> Manuel
>>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers >>>>> >> <dirk.l...@stormlantern.nl> wrote: >>>>> >> > 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:
>>>>> >> >> 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
>>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>>> >> >>> Ok, looking forward to your findings.
>>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James Roper >>>>> het >>>>> >> >>> volgende:
>>>>> >> >>>> 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.
>>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>>> 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<http://groups.google.com/group/play-framework?hl=en> >>>> .
>> To post to this group, send email to play-fr...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> play-framewor...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/play-framework?hl=en.
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:
> 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.
> On Fri, Nov 2, 2012 at 3:52 PM, Guillaume Bort <guillau...@gmail.com<javascript:> > > wrote:
>> Could you try to debug or add a few traces here:
>> On Fri, Nov 2, 2012 at 2:49 PM, Dirk Louwers <dirk.l...@stormlantern.nl<javascript:> >> > wrote:
>>> 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:
>>>> 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:
>>>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het >>>>> volgende:
>>>>>> 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
>>>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers >>>>>> <dirk.l...@stormlantern.nl> wrote: >>>>>> > 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:
>>>>>> >> Hi,
>>>>>> >> Which version of OS X do you have?
>>>>>> >> Manuel
>>>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers >>>>>> >> <dirk.l...@stormlantern.nl> wrote: >>>>>> >> > 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:
>>>>>> >> >> 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
>>>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>>>> >> >>> Ok, looking forward to your findings.
>>>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James >>>>>> Roper het >>>>>> >> >>> volgende:
>>>>>> >> >>>> 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.
>>>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>>>> 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<http://groups.google.com/group/play-framework?hl=en> >>>>> .
>>> To post to this group, send email to play-fr...@googlegroups.com<javascript:> >>> . >>> To unsubscribe from this group, send email to >>> play-framewor...@googlegroups.com <javascript:>. >>> For more options, visit this group at >>> http://groups.google.com/group/play-framework?hl=en.
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:
> 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.
> On Fri, Nov 2, 2012 at 3:52 PM, Guillaume Bort <guillau...@gmail.com<javascript:> > > wrote:
>> Could you try to debug or add a few traces here:
>> On Fri, Nov 2, 2012 at 2:49 PM, Dirk Louwers <dirk.l...@stormlantern.nl<javascript:> >> > wrote:
>>> 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:
>>>> 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:
>>>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het >>>>> volgende:
>>>>>> 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
>>>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers >>>>>> <dirk.l...@stormlantern.nl> wrote: >>>>>> > 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:
>>>>>> >> Hi,
>>>>>> >> Which version of OS X do you have?
>>>>>> >> Manuel
>>>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers >>>>>> >> <dirk.l...@stormlantern.nl> wrote: >>>>>> >> > 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:
>>>>>> >> >> 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
>>>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>>>> >> >>> Ok, looking forward to your findings.
>>>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James >>>>>> Roper het >>>>>> >> >>> volgende:
>>>>>> >> >>>> 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.
>>>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>>>> 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<http://groups.google.com/group/play-framework?hl=en> >>>>> .
>>> To post to this group, send email to play-fr...@googlegroups.com<javascript:> >>> . >>> To unsubscribe from this group, send email to >>> play-framewor...@googlegroups.com <javascript:>. >>> For more options, visit this group at >>> http://groups.google.com/group/play-framework?hl=en.
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:
> 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.
> On Fri, Nov 2, 2012 at 3:52 PM, Guillaume Bort <guillau...@gmail.com<javascript:> > > wrote:
>> Could you try to debug or add a few traces here:
>> On Fri, Nov 2, 2012 at 2:49 PM, Dirk Louwers <dirk.l...@stormlantern.nl<javascript:> >> > wrote:
>>> 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:
>>>> 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:
>>>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het >>>>> volgende:
>>>>>> 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
>>>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers >>>>>> <dirk.l...@stormlantern.nl> wrote: >>>>>> > 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:
>>>>>> >> Hi,
>>>>>> >> Which version of OS X do you have?
>>>>>> >> Manuel
>>>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers >>>>>> >> <dirk.l...@stormlantern.nl> wrote: >>>>>> >> > 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:
>>>>>> >> >> 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
>>>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>>>> >> >>> Ok, looking forward to your findings.
>>>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James >>>>>> Roper het >>>>>> >> >>> volgende:
>>>>>> >> >>>> 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.
>>>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>>>> 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<http://groups.google.com/group/play-framework?hl=en> >>>>> .
>>> To post to this group, send email to play-fr...@googlegroups.com<javascript:> >>> . >>> To unsubscribe from this group, send email to >>> play-framewor...@googlegroups.com <javascript:>. >>> For more options, visit this group at >>> http://groups.google.com/group/play-framework?hl=en.
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:
> 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.
> On Fri, Nov 2, 2012 at 3:52 PM, Guillaume Bort <guillau...@gmail.com<javascript:> > > wrote:
>> Could you try to debug or add a few traces here:
>> On Fri, Nov 2, 2012 at 2:49 PM, Dirk Louwers <dirk.l...@stormlantern.nl<javascript:> >> > wrote:
>>> 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:
>>>> 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:
>>>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het >>>>> volgende:
>>>>>> 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
>>>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers >>>>>> <dirk.l...@stormlantern.nl> wrote: >>>>>> > 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:
>>>>>> >> Hi,
>>>>>> >> Which version of OS X do you have?
>>>>>> >> Manuel
>>>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers >>>>>> >> <dirk.l...@stormlantern.nl> wrote: >>>>>> >> > 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:
>>>>>> >> >> 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
>>>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>>>> >> >>> Ok, looking forward to your findings.
>>>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James >>>>>> Roper het >>>>>> >> >>> volgende:
>>>>>> >> >>>> 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.
>>>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>>>> 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<http://groups.google.com/group/play-framework?hl=en> >>>>> .
>>> To post to this group, send email to play-fr...@googlegroups.com<javascript:> >>> . >>> To unsubscribe from this group, send email to >>> play-framewor...@googlegroups.com <javascript:>. >>> For more options, visit this group at >>> http://groups.google.com/group/play-framework?hl=en.
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:
> 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.
> On Fri, Nov 2, 2012 at 3:52 PM, Guillaume Bort <guillau...@gmail.com<javascript:> > > wrote:
>> Could you try to debug or add a few traces here:
>> On Fri, Nov 2, 2012 at 2:49 PM, Dirk Louwers <dirk.l...@stormlantern.nl<javascript:> >> > wrote:
>>> 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:
>>>> 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:
>>>>> Op vrijdag 2 november 2012 13:17:29 UTC+1 schreef Manuel Bernhardt het >>>>> volgende:
>>>>>> 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
>>>>>> On Fri, Nov 2, 2012 at 12:54 PM, Dirk Louwers >>>>>> <dirk.l...@stormlantern.nl> wrote: >>>>>> > 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:
>>>>>> >> Hi,
>>>>>> >> Which version of OS X do you have?
>>>>>> >> Manuel
>>>>>> >> On Fri, Nov 2, 2012 at 11:47 AM, Dirk Louwers >>>>>> >> <dirk.l...@stormlantern.nl> wrote: >>>>>> >> > 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:
>>>>>> >> >> 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
>>>>>> >> >> On Friday, 2 November 2012 00:33:36 UTC+11, Dirk Louwers wrote:
>>>>>> >> >>> Ok, looking forward to your findings.
>>>>>> >> >>> Op donderdag 1 november 2012 04:41:57 UTC+1 schreef James >>>>>> Roper het >>>>>> >> >>> volgende:
>>>>>> >> >>>> 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.
>>>>>> >> >>>> On Tuesday, 30 October 2012 21:56:22 UTC+11, 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.
>>>>> 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<http://groups.google.com/group/play-framework?hl=en> >>>>> .
>>> To post to this group, send email to play-fr...@googlegroups.com<javascript:> >>> . >>> To unsubscribe from this group, send email to >>> play-framewor...@googlegroups.com <javascript:>. >>> For more options, visit this group at >>> http://groups.google.com/group/play-framework?hl=en.
