You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Jon McCarty (JIRA)" <de...@tapestry.apache.org> on 2007/04/20 20:58:15 UTC
[jira] Created: (TAPESTRY-1422) Thread safety bug when creating
pages with @Asset annotations
Thread safety bug when creating pages with @Asset annotations
-------------------------------------------------------------
Key: TAPESTRY-1422
URL: https://issues.apache.org/jira/browse/TAPESTRY-1422
Project: Tapestry
Issue Type: Bug
Components: Annotations
Affects Versions: 4.1.1
Environment: Windows, JDK 1.5, Tomcat 6.0.x
Reporter: Jon McCarty
I have a thread safety bug in Tapestry when using the Annotations.
PageSpecificationResolverImpl is a threaded service, but its Namespace objects are not; they're provided by the singleton tapestry.parse.SpecificationSource.
A problem arises when two threads are building the same page at the same time. They create two ComponentSpecification objects for the page, but only ONE Of those is changed (due to processing the annotations) when the ComponentConstructor is being created by ComponentConstructorFactoryImpl. The two PageSpecificationResolverImpl's attempt to install() both of them, and sometimes, the wrong one pushes the good one out of the Namespace's page map.
I have a sleazy partial fix that works for our application for now, but it's not a true fix. I currently let the two PageSpecificationResolvers build up two parallel copies of the Page's specification, but down in the install() method, make a thread-safe decision not to add one if there's one already in there, and moreso, to grab that first one back out of the Namespace.
It's a poor solution, but it gets me past my jMeter tests. In reality, The second thread should just wait for the first thread to finish constructing the page, or Tapestry needs a different way of managing the side-effects of processing annotations that have to add stuff to ComponentSpecifications.
Here's what I did in PageSpecificationResolverImpl.install(), but it's not a real fix (order of thread execution could still cause the broken behavior, though this is currently working for me):
private void install()
{
INamespace namespace = getNamespace();
IComponentSpecification specification = getSpecification();
if (_log.isDebugEnabled())
_log.debug(ResolverMessages.installingPage(_simpleName, namespace,
specification));
synchronized(namespace)
{
if( !namespace.containsPage(_simpleName) )
{
namespace.installPageSpecification(_simpleName, specification);
}
else
{
setSpecification(namespace.getPageSpecification(_simpleName));
}
}
}
--
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] Commented: (TAPESTRY-1422) Thread safety bug when creating
pages with @Asset annotations
Posted by "Patrick Moore (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638918#action_12638918 ]
Patrick Moore commented on TAPESTRY-1422:
-----------------------------------------
seems like a better solution would be:
private void install()
{
INamespace namespace = getNamespace();
if( !namespace.containsPage(_simpleName) )
{
IComponentSpecification specification = getSpecification();
if (_log.isDebugEnabled())
_log.debug(ResolverMessages.installingPage(_simpleName, namespace,
specification));
namespace.installPageSpecification(_simpleName, specification);
}
setSpecification(namespace.getPageSpecification(_simpleName));
}
idea being that namespace,installPageSpecification() could be altered so that if the page is already specified that the new specification could be discarded (may cause issues when trying to replace a page spec)
Or
the Namespace could compare the old and new specifications and discard the new if it is the same as the old.
???
> Thread safety bug when creating pages with @Asset annotations
> -------------------------------------------------------------
>
> Key: TAPESTRY-1422
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1422
> Project: Tapestry
> Issue Type: Bug
> Components: Annotations
> Affects Versions: 4.1.1
> Environment: Windows, JDK 1.5, Tomcat 6.0.x
> Reporter: Jon McCarty
> Fix For: 4.1.7
>
>
> I have a thread safety bug in Tapestry when using the Annotations.
> PageSpecificationResolverImpl is a threaded service, but its Namespace objects are not; they're provided by the singleton tapestry.parse.SpecificationSource.
> A problem arises when two threads are building the same page at the same time. They create two ComponentSpecification objects for the page, but only ONE Of those is changed (due to processing the annotations) when the ComponentConstructor is being created by ComponentConstructorFactoryImpl. The two PageSpecificationResolverImpl's attempt to install() both of them, and sometimes, the wrong one pushes the good one out of the Namespace's page map.
> I have a sleazy partial fix that works for our application for now, but it's not a true fix. I currently let the two PageSpecificationResolvers build up two parallel copies of the Page's specification, but down in the install() method, make a thread-safe decision not to add one if there's one already in there, and moreso, to grab that first one back out of the Namespace.
> It's a poor solution, but it gets me past my jMeter tests. In reality, The second thread should just wait for the first thread to finish constructing the page, or Tapestry needs a different way of managing the side-effects of processing annotations that have to add stuff to ComponentSpecifications.
> Here's what I did in PageSpecificationResolverImpl.install(), but it's not a real fix (order of thread execution could still cause the broken behavior, though this is currently working for me):
> private void install()
> {
> INamespace namespace = getNamespace();
> IComponentSpecification specification = getSpecification();
>
> if (_log.isDebugEnabled())
> _log.debug(ResolverMessages.installingPage(_simpleName, namespace,
> specification));
>
> synchronized(namespace)
> {
> if( !namespace.containsPage(_simpleName) )
> {
> namespace.installPageSpecification(_simpleName, specification);
> }
> else
> {
> setSpecification(namespace.getPageSpecification(_simpleName));
> }
> }
> }
--
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] Updated: (TAPESTRY-1422) Thread safety bug when creating
pages with @Asset annotations
Posted by "Jesse Kuhnert (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jesse Kuhnert updated TAPESTRY-1422:
------------------------------------
Fix Version/s: (was: 4.1.5)
4.1.6
> Thread safety bug when creating pages with @Asset annotations
> -------------------------------------------------------------
>
> Key: TAPESTRY-1422
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1422
> Project: Tapestry
> Issue Type: Bug
> Components: Annotations
> Affects Versions: 4.1.1
> Environment: Windows, JDK 1.5, Tomcat 6.0.x
> Reporter: Jon McCarty
> Fix For: 4.1.6
>
>
> I have a thread safety bug in Tapestry when using the Annotations.
> PageSpecificationResolverImpl is a threaded service, but its Namespace objects are not; they're provided by the singleton tapestry.parse.SpecificationSource.
> A problem arises when two threads are building the same page at the same time. They create two ComponentSpecification objects for the page, but only ONE Of those is changed (due to processing the annotations) when the ComponentConstructor is being created by ComponentConstructorFactoryImpl. The two PageSpecificationResolverImpl's attempt to install() both of them, and sometimes, the wrong one pushes the good one out of the Namespace's page map.
> I have a sleazy partial fix that works for our application for now, but it's not a true fix. I currently let the two PageSpecificationResolvers build up two parallel copies of the Page's specification, but down in the install() method, make a thread-safe decision not to add one if there's one already in there, and moreso, to grab that first one back out of the Namespace.
> It's a poor solution, but it gets me past my jMeter tests. In reality, The second thread should just wait for the first thread to finish constructing the page, or Tapestry needs a different way of managing the side-effects of processing annotations that have to add stuff to ComponentSpecifications.
> Here's what I did in PageSpecificationResolverImpl.install(), but it's not a real fix (order of thread execution could still cause the broken behavior, though this is currently working for me):
> private void install()
> {
> INamespace namespace = getNamespace();
> IComponentSpecification specification = getSpecification();
>
> if (_log.isDebugEnabled())
> _log.debug(ResolverMessages.installingPage(_simpleName, namespace,
> specification));
>
> synchronized(namespace)
> {
> if( !namespace.containsPage(_simpleName) )
> {
> namespace.installPageSpecification(_simpleName, specification);
> }
> else
> {
> setSpecification(namespace.getPageSpecification(_simpleName));
> }
> }
> }
--
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] Updated: (TAPESTRY-1422) Thread safety bug when creating
pages with @Asset annotations
Posted by "Marcus Schulte (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcus Schulte updated TAPESTRY-1422:
-------------------------------------
Fix Version/s: (was: 4.1.6)
4.1.7
> Thread safety bug when creating pages with @Asset annotations
> -------------------------------------------------------------
>
> Key: TAPESTRY-1422
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1422
> Project: Tapestry
> Issue Type: Bug
> Components: Annotations
> Affects Versions: 4.1.1
> Environment: Windows, JDK 1.5, Tomcat 6.0.x
> Reporter: Jon McCarty
> Fix For: 4.1.7
>
>
> I have a thread safety bug in Tapestry when using the Annotations.
> PageSpecificationResolverImpl is a threaded service, but its Namespace objects are not; they're provided by the singleton tapestry.parse.SpecificationSource.
> A problem arises when two threads are building the same page at the same time. They create two ComponentSpecification objects for the page, but only ONE Of those is changed (due to processing the annotations) when the ComponentConstructor is being created by ComponentConstructorFactoryImpl. The two PageSpecificationResolverImpl's attempt to install() both of them, and sometimes, the wrong one pushes the good one out of the Namespace's page map.
> I have a sleazy partial fix that works for our application for now, but it's not a true fix. I currently let the two PageSpecificationResolvers build up two parallel copies of the Page's specification, but down in the install() method, make a thread-safe decision not to add one if there's one already in there, and moreso, to grab that first one back out of the Namespace.
> It's a poor solution, but it gets me past my jMeter tests. In reality, The second thread should just wait for the first thread to finish constructing the page, or Tapestry needs a different way of managing the side-effects of processing annotations that have to add stuff to ComponentSpecifications.
> Here's what I did in PageSpecificationResolverImpl.install(), but it's not a real fix (order of thread execution could still cause the broken behavior, though this is currently working for me):
> private void install()
> {
> INamespace namespace = getNamespace();
> IComponentSpecification specification = getSpecification();
>
> if (_log.isDebugEnabled())
> _log.debug(ResolverMessages.installingPage(_simpleName, namespace,
> specification));
>
> synchronized(namespace)
> {
> if( !namespace.containsPage(_simpleName) )
> {
> namespace.installPageSpecification(_simpleName, specification);
> }
> else
> {
> setSpecification(namespace.getPageSpecification(_simpleName));
> }
> }
> }
--
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] Updated: (TAPESTRY-1422) Thread safety bug when creating
pages with @Asset annotations
Posted by "Jesse Kuhnert (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jesse Kuhnert updated TAPESTRY-1422:
------------------------------------
Fix Version/s: 4.1.2
> Thread safety bug when creating pages with @Asset annotations
> -------------------------------------------------------------
>
> Key: TAPESTRY-1422
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1422
> Project: Tapestry
> Issue Type: Bug
> Components: Annotations
> Affects Versions: 4.1.1
> Environment: Windows, JDK 1.5, Tomcat 6.0.x
> Reporter: Jon McCarty
> Fix For: 4.1.2
>
>
> I have a thread safety bug in Tapestry when using the Annotations.
> PageSpecificationResolverImpl is a threaded service, but its Namespace objects are not; they're provided by the singleton tapestry.parse.SpecificationSource.
> A problem arises when two threads are building the same page at the same time. They create two ComponentSpecification objects for the page, but only ONE Of those is changed (due to processing the annotations) when the ComponentConstructor is being created by ComponentConstructorFactoryImpl. The two PageSpecificationResolverImpl's attempt to install() both of them, and sometimes, the wrong one pushes the good one out of the Namespace's page map.
> I have a sleazy partial fix that works for our application for now, but it's not a true fix. I currently let the two PageSpecificationResolvers build up two parallel copies of the Page's specification, but down in the install() method, make a thread-safe decision not to add one if there's one already in there, and moreso, to grab that first one back out of the Namespace.
> It's a poor solution, but it gets me past my jMeter tests. In reality, The second thread should just wait for the first thread to finish constructing the page, or Tapestry needs a different way of managing the side-effects of processing annotations that have to add stuff to ComponentSpecifications.
> Here's what I did in PageSpecificationResolverImpl.install(), but it's not a real fix (order of thread execution could still cause the broken behavior, though this is currently working for me):
> private void install()
> {
> INamespace namespace = getNamespace();
> IComponentSpecification specification = getSpecification();
>
> if (_log.isDebugEnabled())
> _log.debug(ResolverMessages.installingPage(_simpleName, namespace,
> specification));
>
> synchronized(namespace)
> {
> if( !namespace.containsPage(_simpleName) )
> {
> namespace.installPageSpecification(_simpleName, specification);
> }
> else
> {
> setSpecification(namespace.getPageSpecification(_simpleName));
> }
> }
> }
--
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] Updated: (TAPESTRY-1422) Thread safety bug when creating
pages with @Asset annotations
Posted by "Jesse Kuhnert (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jesse Kuhnert updated TAPESTRY-1422:
------------------------------------
Fix Version/s: (was: 4.1.2)
4.1.3
> Thread safety bug when creating pages with @Asset annotations
> -------------------------------------------------------------
>
> Key: TAPESTRY-1422
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1422
> Project: Tapestry
> Issue Type: Bug
> Components: Annotations
> Affects Versions: 4.1.1
> Environment: Windows, JDK 1.5, Tomcat 6.0.x
> Reporter: Jon McCarty
> Fix For: 4.1.3
>
>
> I have a thread safety bug in Tapestry when using the Annotations.
> PageSpecificationResolverImpl is a threaded service, but its Namespace objects are not; they're provided by the singleton tapestry.parse.SpecificationSource.
> A problem arises when two threads are building the same page at the same time. They create two ComponentSpecification objects for the page, but only ONE Of those is changed (due to processing the annotations) when the ComponentConstructor is being created by ComponentConstructorFactoryImpl. The two PageSpecificationResolverImpl's attempt to install() both of them, and sometimes, the wrong one pushes the good one out of the Namespace's page map.
> I have a sleazy partial fix that works for our application for now, but it's not a true fix. I currently let the two PageSpecificationResolvers build up two parallel copies of the Page's specification, but down in the install() method, make a thread-safe decision not to add one if there's one already in there, and moreso, to grab that first one back out of the Namespace.
> It's a poor solution, but it gets me past my jMeter tests. In reality, The second thread should just wait for the first thread to finish constructing the page, or Tapestry needs a different way of managing the side-effects of processing annotations that have to add stuff to ComponentSpecifications.
> Here's what I did in PageSpecificationResolverImpl.install(), but it's not a real fix (order of thread execution could still cause the broken behavior, though this is currently working for me):
> private void install()
> {
> INamespace namespace = getNamespace();
> IComponentSpecification specification = getSpecification();
>
> if (_log.isDebugEnabled())
> _log.debug(ResolverMessages.installingPage(_simpleName, namespace,
> specification));
>
> synchronized(namespace)
> {
> if( !namespace.containsPage(_simpleName) )
> {
> namespace.installPageSpecification(_simpleName, specification);
> }
> else
> {
> setSpecification(namespace.getPageSpecification(_simpleName));
> }
> }
> }
--
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] Updated: (TAPESTRY-1422) Thread safety bug when creating
pages with @Asset annotations
Posted by "Jesse Kuhnert (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jesse Kuhnert updated TAPESTRY-1422:
------------------------------------
Fix Version/s: (was: 4.1.3)
4.1.4
> Thread safety bug when creating pages with @Asset annotations
> -------------------------------------------------------------
>
> Key: TAPESTRY-1422
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1422
> Project: Tapestry
> Issue Type: Bug
> Components: Annotations
> Affects Versions: 4.1.1
> Environment: Windows, JDK 1.5, Tomcat 6.0.x
> Reporter: Jon McCarty
> Fix For: 4.1.4
>
>
> I have a thread safety bug in Tapestry when using the Annotations.
> PageSpecificationResolverImpl is a threaded service, but its Namespace objects are not; they're provided by the singleton tapestry.parse.SpecificationSource.
> A problem arises when two threads are building the same page at the same time. They create two ComponentSpecification objects for the page, but only ONE Of those is changed (due to processing the annotations) when the ComponentConstructor is being created by ComponentConstructorFactoryImpl. The two PageSpecificationResolverImpl's attempt to install() both of them, and sometimes, the wrong one pushes the good one out of the Namespace's page map.
> I have a sleazy partial fix that works for our application for now, but it's not a true fix. I currently let the two PageSpecificationResolvers build up two parallel copies of the Page's specification, but down in the install() method, make a thread-safe decision not to add one if there's one already in there, and moreso, to grab that first one back out of the Namespace.
> It's a poor solution, but it gets me past my jMeter tests. In reality, The second thread should just wait for the first thread to finish constructing the page, or Tapestry needs a different way of managing the side-effects of processing annotations that have to add stuff to ComponentSpecifications.
> Here's what I did in PageSpecificationResolverImpl.install(), but it's not a real fix (order of thread execution could still cause the broken behavior, though this is currently working for me):
> private void install()
> {
> INamespace namespace = getNamespace();
> IComponentSpecification specification = getSpecification();
>
> if (_log.isDebugEnabled())
> _log.debug(ResolverMessages.installingPage(_simpleName, namespace,
> specification));
>
> synchronized(namespace)
> {
> if( !namespace.containsPage(_simpleName) )
> {
> namespace.installPageSpecification(_simpleName, specification);
> }
> else
> {
> setSpecification(namespace.getPageSpecification(_simpleName));
> }
> }
> }
--
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