You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Fernando (JIRA)" <ji...@apache.org> on 2008/10/31 19:21:44 UTC
[jira] Created: (TAP5-320) Flash Persist Variables might be cleared
too aggressively
Flash Persist Variables might be cleared too aggressively
---------------------------------------------------------
Key: TAP5-320
URL: https://issues.apache.org/jira/browse/TAP5-320
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.0.16
Reporter: Fernando
So yes it looks like the Flash variables of a Page are scrubbed when the page is removed from the cache, no matter if it's rendered or not. The stack trace is below.
I know that my example might be a bit extreme, but here are some other usecases that should be affected as well:
-- Page Rendering
1) render PageA (set flash variable).
2) render PageB
a) while rendering, it loads PageA for some reason
(RequestPageCache.get, PageLink, ActionLink, etc)
b) while loading PageA, its flash variables are cleared
3) render PageA (flash variable is null)
-- Ajax
1) render PageA (set flash variable).
2) Ajax callback to app
a) either hitting PageA directly, or hitting PageB that
refers to PageA in some way
( PageLink, ActionLink, RequestPageCache.get )
b) while loading PageA, its flash variables are cleared
3) render PageA (flash variable is null)
STACK TRACE:
showing that flash variables are cleared from pages once they are loaded, not once they are rendered, so it can be cleared way before we have a change to render it.
setAttribute( flash:core/Start:status.cheerform:defaultTracker, null )
at org.apache.tapestry5.internal.services.SessionImpl.setAttribute(SessionImpl.java:50)
at org.apache.tapestry5.internal.services.FlashPersistentFieldStrategy.didReadChange(FlashPersistentFieldStrategy.java:41)
at org.apache.tapestry5.internal.services.AbstractSessionPersistentFieldStrategy.gatherFieldChanges(AbstractSessionPersistentFieldStrategy.java:65)
at org.apache.tapestry5.internal.services.PersistentFieldManagerImpl.gatherChanges(PersistentFieldManagerImpl.java:65)
at $PersistentFieldManager_11d5412d051.gatherChanges($PersistentFieldManager_11d5412d051.java)
at org.apache.tapestry5.internal.structure.PageImpl.getFieldChange(PageImpl.java:185)
at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getFieldChange(InternalComponentResourcesImpl.java:111)
at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.hasFieldChange(InternalComponentResourcesImpl.java:121)
at com.protrade.fanwars.base.pages.Start.containingPageDidAttach(Start.java)
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl$2.run(ComponentPageElementImpl.java:80)
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:912)
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.containingPageDidAttach(ComponentPageElementImpl.java:726)
at org.apache.tapestry5.internal.structure.PageImpl.attached(PageImpl.java:151)
at org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:55)
at $RequestPageCache_11d5412d04b.get($RequestPageCache_11d5412d04b.java)
at $RequestPageCache_11d5412d046.get($RequestPageCache_11d5412d046.java)
at com.protrade.facebook.base.services.FbForceModeFilter.handle(FbForceModeFilter.java:57)
(this is my PageRenderRequestFilter which cuts off page rendering)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Resolved: (TAP5-320) Flash Persist Variables might be
cleared too aggressively
Posted by "Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fernando resolved TAP5-320.
---------------------------
Resolution: Won't Fix
I'll back down on this one for now..
The changed my code to use PagePool instead of RequestPageCache, so that when I picked up a page it would not go through an attach/detach cycle, thus clearing all of the flash variables prematurely.
Like you said, though it isn't exactly doing what it says it does ( clear variables on next RENDER ), it does behave very close to that with minimal code.. :) :) ( it clears variables on next ATTACH )
thank you for tapestry!!
> Flash Persist Variables might be cleared too aggressively
> ---------------------------------------------------------
>
> Key: TAP5-320
> URL: https://issues.apache.org/jira/browse/TAP5-320
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.0.16
> Reporter: Fernando
>
> So yes it looks like the Flash variables of a Page are scrubbed when the page is removed from the cache, no matter if it's rendered or not. The stack trace is below.
> I know that my example might be a bit extreme, but here are some other usecases that should be affected as well:
> -- Page Rendering
> 1) render PageA (set flash variable).
> 2) render PageB
> a) while rendering, it loads PageA for some reason
> (RequestPageCache.get, PageLink, ActionLink, etc)
> b) while loading PageA, its flash variables are cleared
> 3) render PageA (flash variable is null)
> -- Ajax
> 1) render PageA (set flash variable).
> 2) Ajax callback to app
> a) either hitting PageA directly, or hitting PageB that
> refers to PageA in some way
> ( PageLink, ActionLink, RequestPageCache.get )
> b) while loading PageA, its flash variables are cleared
> 3) render PageA (flash variable is null)
> STACK TRACE:
> showing that flash variables are cleared from pages once they are loaded, not once they are rendered, so it can be cleared way before we have a change to render it.
> setAttribute( flash:core/Start:status.cheerform:defaultTracker, null )
> at org.apache.tapestry5.internal.services.SessionImpl.setAttribute(SessionImpl.java:50)
> at org.apache.tapestry5.internal.services.FlashPersistentFieldStrategy.didReadChange(FlashPersistentFieldStrategy.java:41)
> at org.apache.tapestry5.internal.services.AbstractSessionPersistentFieldStrategy.gatherFieldChanges(AbstractSessionPersistentFieldStrategy.java:65)
> at org.apache.tapestry5.internal.services.PersistentFieldManagerImpl.gatherChanges(PersistentFieldManagerImpl.java:65)
> at $PersistentFieldManager_11d5412d051.gatherChanges($PersistentFieldManager_11d5412d051.java)
> at org.apache.tapestry5.internal.structure.PageImpl.getFieldChange(PageImpl.java:185)
> at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getFieldChange(InternalComponentResourcesImpl.java:111)
> at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.hasFieldChange(InternalComponentResourcesImpl.java:121)
> at com.protrade.fanwars.base.pages.Start.containingPageDidAttach(Start.java)
> at org.apache.tapestry5.internal.structure.ComponentPageElementImpl$2.run(ComponentPageElementImpl.java:80)
> at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:912)
> at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.containingPageDidAttach(ComponentPageElementImpl.java:726)
> at org.apache.tapestry5.internal.structure.PageImpl.attached(PageImpl.java:151)
> at org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:55)
> at $RequestPageCache_11d5412d04b.get($RequestPageCache_11d5412d04b.java)
> at $RequestPageCache_11d5412d046.get($RequestPageCache_11d5412d046.java)
> at com.protrade.facebook.base.services.FbForceModeFilter.handle(FbForceModeFilter.java:57)
> (this is my PageRenderRequestFilter which cuts off page rendering)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-320) Flash Persist Variables might be cleared too aggressively
Posted by Howard Lewis Ship <hl...@gmail.com>.
Use session persistence and clear the fields inside afterRender().
On Thu, Nov 6, 2008 at 1:19 PM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> I'll say that it addresses the intended usecase, but not "correctly". :)
>
> Intended to survive until the page is "rendered". And as long as you
> require that the page is the next one rendered without any intervening
> requests then yes, it fulfills the requirement. I'm just saying that as the
> pages get more complicated and have more ajaxy requests, the lifespan of
> these variables will be much shorter than expected. And I'm getting bit by
> it at the moment.
>
> I know that it might be too big for you to actively change this now, but do
> you have any ideas? I don't mind putting in some sweat to fix this since
> this is affecting us right now! :)
>
> For us making the Form use session persist instead of flash persist will fix
> it except for minor side effects. Do you have any other ideas?
>
>
>
> Howard M. Lewis Ship (JIRA) wrote:
>>
>> [
>> https://issues.apache.org/jira/browse/TAP5-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645584#action_12645584
>> ]
>> Howard M. Lewis Ship commented on TAP5-320:
>> -------------------------------------------
>>
>> The intent of flash is to store a value long enough for it to be rendered
>> on the same page in the next (render) request.
>>
>> So, I understand that it's not doing what you want, and there is some
>> ambiguity in how it operates ... but it does correctly address the use case
>> it was created for.
>>
>>> Flash Persist Variables might be cleared too aggressively
>>> ---------------------------------------------------------
>>>
>>> Key: TAP5-320
>>> URL: https://issues.apache.org/jira/browse/TAP5-320
>>> Project: Tapestry 5
>>> Issue Type: Bug
>>> Components: tapestry-core
>>> Affects Versions: 5.0.16
>>> Reporter: Fernando
>>>
>>> So yes it looks like the Flash variables of a Page are scrubbed when the
>>> page is removed from the cache, no matter if it's rendered or not. The
>>> stack trace is below.
>>> I know that my example might be a bit extreme, but here are some other
>>> usecases that should be affected as well:
>>> -- Page Rendering
>>> 1) render PageA (set flash variable).
>>> 2) render PageB
>>> a) while rendering, it loads PageA for some reason
>>> (RequestPageCache.get, PageLink, ActionLink, etc)
>>> b) while loading PageA, its flash variables are cleared
>>> 3) render PageA (flash variable is null)
>>> -- Ajax
>>> 1) render PageA (set flash variable).
>>> 2) Ajax callback to app
>>> a) either hitting PageA directly, or hitting PageB that
>>> refers to PageA in some way
>>> ( PageLink, ActionLink, RequestPageCache.get )
>>> b) while loading PageA, its flash variables are cleared
>>> 3) render PageA (flash variable is null)
>>> STACK TRACE:
>>> showing that flash variables are cleared from pages once they are loaded,
>>> not once they are rendered, so it can be cleared way before we have a change
>>> to render it.
>>> setAttribute( flash:core/Start:status.cheerform:defaultTracker, null )
>>> at
>>> org.apache.tapestry5.internal.services.SessionImpl.setAttribute(SessionImpl.java:50)
>>> at
>>> org.apache.tapestry5.internal.services.FlashPersistentFieldStrategy.didReadChange(FlashPersistentFieldStrategy.java:41)
>>> at
>>> org.apache.tapestry5.internal.services.AbstractSessionPersistentFieldStrategy.gatherFieldChanges(AbstractSessionPersistentFieldStrategy.java:65)
>>> at
>>> org.apache.tapestry5.internal.services.PersistentFieldManagerImpl.gatherChanges(PersistentFieldManagerImpl.java:65)
>>> at
>>> $PersistentFieldManager_11d5412d051.gatherChanges($PersistentFieldManager_11d5412d051.java)
>>> at
>>> org.apache.tapestry5.internal.structure.PageImpl.getFieldChange(PageImpl.java:185)
>>> at
>>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getFieldChange(InternalComponentResourcesImpl.java:111)
>>> at
>>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.hasFieldChange(InternalComponentResourcesImpl.java:121)
>>> at
>>> com.protrade.fanwars.base.pages.Start.containingPageDidAttach(Start.java)
>>> at
>>> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$2.run(ComponentPageElementImpl.java:80)
>>> at
>>> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:912)
>>> at
>>> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.containingPageDidAttach(ComponentPageElementImpl.java:726)
>>> at
>>> org.apache.tapestry5.internal.structure.PageImpl.attached(PageImpl.java:151)
>>> at
>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:55)
>>> at
>>> $RequestPageCache_11d5412d04b.get($RequestPageCache_11d5412d04b.java)
>>> at
>>> $RequestPageCache_11d5412d046.get($RequestPageCache_11d5412d046.java)
>>> at
>>> com.protrade.facebook.base.services.FbForceModeFilter.handle(FbForceModeFilter.java:57)
>>> (this is my PageRenderRequestFilter which cuts off page rendering)
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-320) Flash Persist Variables might be
cleared too aggressively
Posted by Fernando Padilla <fe...@alum.mit.edu>.
I'll say that it addresses the intended usecase, but not "correctly". :)
Intended to survive until the page is "rendered". And as long as you
require that the page is the next one rendered without any intervening
requests then yes, it fulfills the requirement. I'm just saying that as
the pages get more complicated and have more ajaxy requests, the
lifespan of these variables will be much shorter than expected. And I'm
getting bit by it at the moment.
I know that it might be too big for you to actively change this now, but
do you have any ideas? I don't mind putting in some sweat to fix this
since this is affecting us right now! :)
For us making the Form use session persist instead of flash persist will
fix it except for minor side effects. Do you have any other ideas?
Howard M. Lewis Ship (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/TAP5-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645584#action_12645584 ]
>
> Howard M. Lewis Ship commented on TAP5-320:
> -------------------------------------------
>
> The intent of flash is to store a value long enough for it to be rendered on the same page in the next (render) request.
>
> So, I understand that it's not doing what you want, and there is some ambiguity in how it operates ... but it does correctly address the use case it was created for.
>
>> Flash Persist Variables might be cleared too aggressively
>> ---------------------------------------------------------
>>
>> Key: TAP5-320
>> URL: https://issues.apache.org/jira/browse/TAP5-320
>> Project: Tapestry 5
>> Issue Type: Bug
>> Components: tapestry-core
>> Affects Versions: 5.0.16
>> Reporter: Fernando
>>
>> So yes it looks like the Flash variables of a Page are scrubbed when the page is removed from the cache, no matter if it's rendered or not. The stack trace is below.
>> I know that my example might be a bit extreme, but here are some other usecases that should be affected as well:
>> -- Page Rendering
>> 1) render PageA (set flash variable).
>> 2) render PageB
>> a) while rendering, it loads PageA for some reason
>> (RequestPageCache.get, PageLink, ActionLink, etc)
>> b) while loading PageA, its flash variables are cleared
>> 3) render PageA (flash variable is null)
>> -- Ajax
>> 1) render PageA (set flash variable).
>> 2) Ajax callback to app
>> a) either hitting PageA directly, or hitting PageB that
>> refers to PageA in some way
>> ( PageLink, ActionLink, RequestPageCache.get )
>> b) while loading PageA, its flash variables are cleared
>> 3) render PageA (flash variable is null)
>> STACK TRACE:
>> showing that flash variables are cleared from pages once they are loaded, not once they are rendered, so it can be cleared way before we have a change to render it.
>> setAttribute( flash:core/Start:status.cheerform:defaultTracker, null )
>> at org.apache.tapestry5.internal.services.SessionImpl.setAttribute(SessionImpl.java:50)
>> at org.apache.tapestry5.internal.services.FlashPersistentFieldStrategy.didReadChange(FlashPersistentFieldStrategy.java:41)
>> at org.apache.tapestry5.internal.services.AbstractSessionPersistentFieldStrategy.gatherFieldChanges(AbstractSessionPersistentFieldStrategy.java:65)
>> at org.apache.tapestry5.internal.services.PersistentFieldManagerImpl.gatherChanges(PersistentFieldManagerImpl.java:65)
>> at $PersistentFieldManager_11d5412d051.gatherChanges($PersistentFieldManager_11d5412d051.java)
>> at org.apache.tapestry5.internal.structure.PageImpl.getFieldChange(PageImpl.java:185)
>> at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getFieldChange(InternalComponentResourcesImpl.java:111)
>> at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.hasFieldChange(InternalComponentResourcesImpl.java:121)
>> at com.protrade.fanwars.base.pages.Start.containingPageDidAttach(Start.java)
>> at org.apache.tapestry5.internal.structure.ComponentPageElementImpl$2.run(ComponentPageElementImpl.java:80)
>> at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:912)
>> at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.containingPageDidAttach(ComponentPageElementImpl.java:726)
>> at org.apache.tapestry5.internal.structure.PageImpl.attached(PageImpl.java:151)
>> at org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:55)
>> at $RequestPageCache_11d5412d04b.get($RequestPageCache_11d5412d04b.java)
>> at $RequestPageCache_11d5412d046.get($RequestPageCache_11d5412d046.java)
>> at com.protrade.facebook.base.services.FbForceModeFilter.handle(FbForceModeFilter.java:57)
>> (this is my PageRenderRequestFilter which cuts off page rendering)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-320) Flash Persist Variables might be
cleared too aggressively
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645584#action_12645584 ]
Howard M. Lewis Ship commented on TAP5-320:
-------------------------------------------
The intent of flash is to store a value long enough for it to be rendered on the same page in the next (render) request.
So, I understand that it's not doing what you want, and there is some ambiguity in how it operates ... but it does correctly address the use case it was created for.
> Flash Persist Variables might be cleared too aggressively
> ---------------------------------------------------------
>
> Key: TAP5-320
> URL: https://issues.apache.org/jira/browse/TAP5-320
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.0.16
> Reporter: Fernando
>
> So yes it looks like the Flash variables of a Page are scrubbed when the page is removed from the cache, no matter if it's rendered or not. The stack trace is below.
> I know that my example might be a bit extreme, but here are some other usecases that should be affected as well:
> -- Page Rendering
> 1) render PageA (set flash variable).
> 2) render PageB
> a) while rendering, it loads PageA for some reason
> (RequestPageCache.get, PageLink, ActionLink, etc)
> b) while loading PageA, its flash variables are cleared
> 3) render PageA (flash variable is null)
> -- Ajax
> 1) render PageA (set flash variable).
> 2) Ajax callback to app
> a) either hitting PageA directly, or hitting PageB that
> refers to PageA in some way
> ( PageLink, ActionLink, RequestPageCache.get )
> b) while loading PageA, its flash variables are cleared
> 3) render PageA (flash variable is null)
> STACK TRACE:
> showing that flash variables are cleared from pages once they are loaded, not once they are rendered, so it can be cleared way before we have a change to render it.
> setAttribute( flash:core/Start:status.cheerform:defaultTracker, null )
> at org.apache.tapestry5.internal.services.SessionImpl.setAttribute(SessionImpl.java:50)
> at org.apache.tapestry5.internal.services.FlashPersistentFieldStrategy.didReadChange(FlashPersistentFieldStrategy.java:41)
> at org.apache.tapestry5.internal.services.AbstractSessionPersistentFieldStrategy.gatherFieldChanges(AbstractSessionPersistentFieldStrategy.java:65)
> at org.apache.tapestry5.internal.services.PersistentFieldManagerImpl.gatherChanges(PersistentFieldManagerImpl.java:65)
> at $PersistentFieldManager_11d5412d051.gatherChanges($PersistentFieldManager_11d5412d051.java)
> at org.apache.tapestry5.internal.structure.PageImpl.getFieldChange(PageImpl.java:185)
> at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getFieldChange(InternalComponentResourcesImpl.java:111)
> at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.hasFieldChange(InternalComponentResourcesImpl.java:121)
> at com.protrade.fanwars.base.pages.Start.containingPageDidAttach(Start.java)
> at org.apache.tapestry5.internal.structure.ComponentPageElementImpl$2.run(ComponentPageElementImpl.java:80)
> at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:912)
> at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.containingPageDidAttach(ComponentPageElementImpl.java:726)
> at org.apache.tapestry5.internal.structure.PageImpl.attached(PageImpl.java:151)
> at org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:55)
> at $RequestPageCache_11d5412d04b.get($RequestPageCache_11d5412d04b.java)
> at $RequestPageCache_11d5412d046.get($RequestPageCache_11d5412d046.java)
> at com.protrade.facebook.base.services.FbForceModeFilter.handle(FbForceModeFilter.java:57)
> (this is my PageRenderRequestFilter which cuts off page rendering)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org