Ipage setProperty() method problem in upgrading from tapestry 4.0.1 to 4.1.6
I am trying to upgrade from tapestry 4.0.1 to tapestry 4.1.6. In tapestry 4.0.1, for object Ipage we had a function setProperty(String, Throwable) but it does not exist in Ipage object in tapestry 4.1.6. Please let me know whether the function is deprecated or do we have any alternate function to use.
Re: SoftReferences to PageImpl can cause performance problems
Hi, I now found time to sum up a short report about that topic. I summarized my results in following pdf file: http://www.schmelzer.cc/Downloads/Files/Tapestry-Memory-Performance.pdf The main issue is, that you are able to bring a Tapestry based system into a situation where it gets slower and slower and finally event not responding any more, just be decreasing memory on the JVM and you DO NOT get any error message or OutOfMemory warning or GC overhead warning. And that only because the PageImpl instances are held in SoftReferences. My opinion is still, that this does not work as it is supposed to do and I keep with my example about other infrastructure. You would not expect e.g. Spring beans or a hibernate configuration to get thrown away under memory preasure - you would expect them to fail with OutOfMemory if they are not able to hold their necassary static information in memory. Regards Robert Am 19.03.2015 um 17:55 schrieb Kalle Korhonen: On Thu, Mar 19, 2015 at 12:24 AM, Robert Schmelzer rob...@schmelzer.cc wrote: Sorry, I was unprecise - my example should have referenced to the EntityManagerFactory (SessionFactoryImpl in Hibernate). You would not expect them, to throw away its cached configuration on memory preasure. I do not either expect that from Tapestry. I cannot make our results public because of regulatory issues. I will try to setup a show case for that and will offer a patch. This will take me a few days. I don't think we are going to simply do away with the SoftReferences without any replacements so I wouldn't even attempt at offering such a patch. I just don't agree that a memory cache should be permanent construct. If your object is not in a cache, you'll simply incur a cache miss and re-create the object on the fly. It is not typical that a cache will grow indefinitely. If you are adamant on this approach, you could probably convince us to add a symbol to control the cache behavior (i.e. to never purge objects from it). Guava has excellent, easily configurable cache implementations. Kalle Robert Am 18.03.2015 um 18:19 schrieb Kalle Korhonen: On Wed, Mar 18, 2015 at 12:44 AM, Robert Schmelzer rob...@schmelzer.cc wrote: I do not agree with you on that point. Tapestry is designed to cache the page. When you do not have enough memory to hold your pages cached basically the system does not work as designed so you should fail early. Otherwise you possible defer the problem to production use. Fail early means you should try to see the problem in the early stages on dev, where you try out all your pages. As I mentioned in my other post - you would also not expect the EntityManager to work soft-refereences or spring application context to work soft referenced. That's the definition of a memory cache - it trades memory for better performance. The primary use case for soft refences is for caching so seems to me it works exactly as designed. Your comparison to the EntityManager is flawed since it's created per request. An EntityManager is designed to be inexpensive to create. There are many areas that need improvements in Tapestry but this is not one in my opinion. However, you seem to strongly think otherwise, so you probably have some data to back this up. Do you have a memory dump and trending cpu/memory charts of a sufficiently large system you can share with us to demonstrate the problem? Jvisualvm snapshots should work fine. And furthermore - how would you like this changed? If it's just adding a Page as a threadlocal, perhaps you can just write a patch for it. Kalle Am 18.03.2015 um 04:23 schrieb Kalle Korhonen: In my opinion, soft referencing page objects is highly appropriate usage here. If there's pressure on the available memory, it makes sense to trade performance for memory instead of exiting with OoM. This is simple condition to detect and should be visible with any reasonable monitoring tool. If you are hitting memory limits, you'll need to allocate more memory for the application for optimal performance. Soft references are especially useful here because you can optimize its behavior with the -client/-server setting depending on your preferences. Kalle On Tue, Mar 17, 2015 at 4:26 PM, Howard Lewis Ship hls...@gmail.com wrote: Possibly we need something more advanced; our own reference type that can react to memory pressure by discarding pages that haven't been used in configurable amount of time. Or perhaps we could just assume that any page that has been used once need to be used in the future and get rid of the SoftReference entirely (or otherwise janitorize it in some way). On Tue, Mar 17, 2015 at 1:24 AM, Robert Schmelzer rob...@schmelzer.cc wrote: Hello, I recently came accross the implementation of PageSourceImpl where PageImpl instances are softly refereneced into the pageCache: private final MapCachedPageKey, SoftReferencePage pageCache = CollectionFactory.newConcurrentMap(); This implementation caused
Re: The active page name has not been specified
Kalle, when I switch from
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
to
@RequiresUser
private class TimeSheet {
The issue goes away. Am I do something wrong with my configuration?
Here's my complete config.
public static void
contributeSecurityConfiguration(ConfigurationSecurityFilterChain
configuration,
SecurityFilterChainFactory factory) {
// /authc/** rule covers /authc , /authc?q=name /authc#anchor urls
as well
configuration.add(factory.createChain(/).add(factory.authc()).build());
configuration.add(factory.createChain(/profile/**).add(factory.authc()).build());
//
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
configuration.add(factory.createChain(/timesheets/**).add(factory.authc()).build());
configuration.add(factory.createChain(/admin/**).add(factory.roles(),
appsupport).build());
configuration.add(factory.createChain(/timerecords/**).add(factory.roles(),
timerecords).build());
}
On Tue, Mar 31, 2015 at 5:11 PM, George Christman gchrist...@cardaddy.com
wrote:
Yes, still having the same issue, but only on the my Ajax form. My form is
very complicating, so I'll try breaking it down into something simpler
tomorrow and hopefully pin point the issue. My submit buttons are up top
and I think I'm using defer true, so I'm not sure if that has something to
do with it. I also have some logic in my onActivate method, but I figured
the redirection should have been happening before that method was ever
called.
On Mar 31, 2015 4:35 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to
another
page in my app where I have an ajaxformloop and it appeared to redirect
without issue. I'm going to have to dig deeper tomorrow to find the
cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the tapestry-core
and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which
might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=
department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn btn-default
data-dismiss=modal${message:close-label}/button
/div
/t:form
/t:zone
/t:modal
/t:security.hasPermission
On Tue, Mar 31, 2015 at 11:19 PM, George Christman
gchrist...@cardaddy.com wrote:
And your wrapping your form in a zone too? Sorry, I just want to be
sure
we
are doing everything the same.
On Tue, Mar 31, 2015 at 4:05 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
Fedora 3.19.1-201.fc21.x86_64 #1 SMP Wed Mar 18 04:29:24 UTC 2015
x86_64
x86_64 x86_64 GNU/Linux
Java 1.8.0_40
Google chrome Version 41.0.2272.101 (64-bit)
jetty-distribution-9.2.5.v20141112
Tapestry 5.4-beta28
dependency
groupIdorg.tynamo/groupId
artifactIdtapestry-security/artifactId
version0.6.2/version
exclusions
exclusion
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-core/artifactId
Re: SoftReferences to PageImpl can cause performance problems
Actually Robert, I'd love it if you could patch/override T5 core just enough to disable SoftReferences and re-run your test. The results may surprise you. I could almost guarantee you'd see the same performance pattern for any modern jpa 2.x application. At 1.2GB, it doesn't look like your test setup is just a synthetic, lightweight t5 app with no back end, is it? Kalle On Apr 1, 2015 3:44 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: A configurable cache might be ok but what Robert is showing is a highly typical performance degradation pattern for any sufficiently large Java application. Tapestry's page cache is hardly the only place where soft references are used. When your memory budget is too small, most system engineers would argue that it's far better to slow down the application than OoM, but obviously that depends on the type of application and the traffic patterns you are facing. For the consumer facing application, it's not uncommon to see peak traffic 30-100 times over the averages at least with the applications I've been involved with and I would hate to to budget all resources based on peak consumption only. On the other hand, if the number of pages on the site is small and the site is evenly in use, then sure, it'd make sense to never purge. Kalle On Wed, Apr 1, 2015 at 3:01 PM, Howard Lewis Ship hls...@gmail.com wrote: I'm feeling that Robert is making a very good case here. I could imagine a page-level annotation to either enable or disable evication of a page instance after a period of time ... but that can come later. I do think that hard-caching of pages will leading to more predictable response performance. On Wed, Apr 1, 2015 at 7:31 AM, Robert Schmelzer rob...@schmelzer.cc wrote: Hi, I now found time to sum up a short report about that topic. I summarized my results in following pdf file: http://www.schmelzer.cc/Downloads/Files/Tapestry-Memory-Performance.pdf The main issue is, that you are able to bring a Tapestry based system into a situation where it gets slower and slower and finally event not responding any more, just be decreasing memory on the JVM and you DO NOT get any error message or OutOfMemory warning or GC overhead warning. And that only because the PageImpl instances are held in SoftReferences. My opinion is still, that this does not work as it is supposed to do and I keep with my example about other infrastructure. You would not expect e.g. Spring beans or a hibernate configuration to get thrown away under memory preasure - you would expect them to fail with OutOfMemory if they are not able to hold their necassary static information in memory. Regards Robert Am 19.03.2015 um 17:55 schrieb Kalle Korhonen: On Thu, Mar 19, 2015 at 12:24 AM, Robert Schmelzer rob...@schmelzer.cc wrote: Sorry, I was unprecise - my example should have referenced to the EntityManagerFactory (SessionFactoryImpl in Hibernate). You would not expect them, to throw away its cached configuration on memory preasure. I do not either expect that from Tapestry. I cannot make our results public because of regulatory issues. I will try to setup a show case for that and will offer a patch. This will take me a few days. I don't think we are going to simply do away with the SoftReferences without any replacements so I wouldn't even attempt at offering such a patch. I just don't agree that a memory cache should be permanent construct. If your object is not in a cache, you'll simply incur a cache miss and re-create the object on the fly. It is not typical that a cache will grow indefinitely. If you are adamant on this approach, you could probably convince us to add a symbol to control the cache behavior (i.e. to never purge objects from it). Guava has excellent, easily configurable cache implementations. Kalle Robert Am 18.03.2015 um 18:19 schrieb Kalle Korhonen: On Wed, Mar 18, 2015 at 12:44 AM, Robert Schmelzer rob...@schmelzer.cc wrote: I do not agree with you on that point. Tapestry is designed to cache the page. When you do not have enough memory to hold your pages cached basically the system does not work as designed so you should fail early. Otherwise you possible defer the problem to production use. Fail early means you should try to see the problem in the early stages on dev, where you try out all your pages. As I mentioned in my other post - you would also not expect the EntityManager to work soft-refereences or spring application context to work soft referenced. That's the definition of a memory cache - it trades memory for better performance. The primary use case for soft refences is for caching so seems to me it works exactly as designed. Your comparison to the EntityManager is flawed since it's created per request. An EntityManager is designed to be inexpensive to
Re: The active page name has not been specified
On Wed, Apr 1, 2015 at 9:22 AM, George Christman gchrist...@cardaddy.com
wrote:
Kalle, when I switch from
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
to
@RequiresUser
private class TimeSheet {
The issue goes away. Am I do something wrong with my configuration?
I was going to ask you to try out exactly that. So the reason it works with
one and not the other is that the authorization is enforced at a different
point in the request lifecycle. For page level annotations to work,
naturally Tapestry must have already parsed the request and set the active
page, whereas url-based authorization happens before. There's nothing wrong
in your configuration and I do suspect this is an issue with the security
library. And sorry, I have yet to check the existing test suite regarding
this.
Kalle
Here's my complete config.
public static void
contributeSecurityConfiguration(ConfigurationSecurityFilterChain
configuration,
SecurityFilterChainFactory factory) {
// /authc/** rule covers /authc , /authc?q=name /authc#anchor urls
as well
configuration.add(factory.createChain(/).add(factory.authc()).build());
configuration.add(factory.createChain(/profile/**).add(factory.authc()).build());
//
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
configuration.add(factory.createChain(/timesheets/**).add(factory.authc()).build());
configuration.add(factory.createChain(/admin/**).add(factory.roles(),
appsupport).build());
configuration.add(factory.createChain(/timerecords/**).add(factory.roles(),
timerecords).build());
}
On Tue, Mar 31, 2015 at 5:11 PM, George Christman gchrist...@cardaddy.com
wrote:
Yes, still having the same issue, but only on the my Ajax form. My form
is
very complicating, so I'll try breaking it down into something simpler
tomorrow and hopefully pin point the issue. My submit buttons are up top
and I think I'm using defer true, so I'm not sure if that has something
to
do with it. I also have some logic in my onActivate method, but I figured
the redirection should have been happening before that method was ever
called.
On Mar 31, 2015 4:35 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to
another
page in my app where I have an ajaxformloop and it appeared to
redirect
without issue. I'm going to have to dig deeper tomorrow to find the
cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the
tapestry-core
and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which
might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=
department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn btn-default
data-dismiss=modal${message:close-label}/button
/div
/t:form
/t:zone
/t:modal
/t:security.hasPermission
On Tue, Mar 31, 2015 at 11:19 PM, George Christman
gchrist...@cardaddy.com wrote:
And your wrapping
Re: SoftReferences to PageImpl can cause performance problems
I'm feeling that Robert is making a very good case here. I could imagine a page-level annotation to either enable or disable evication of a page instance after a period of time ... but that can come later. I do think that hard-caching of pages will leading to more predictable response performance. On Wed, Apr 1, 2015 at 7:31 AM, Robert Schmelzer rob...@schmelzer.cc wrote: Hi, I now found time to sum up a short report about that topic. I summarized my results in following pdf file: http://www.schmelzer.cc/Downloads/Files/Tapestry-Memory-Performance.pdf The main issue is, that you are able to bring a Tapestry based system into a situation where it gets slower and slower and finally event not responding any more, just be decreasing memory on the JVM and you DO NOT get any error message or OutOfMemory warning or GC overhead warning. And that only because the PageImpl instances are held in SoftReferences. My opinion is still, that this does not work as it is supposed to do and I keep with my example about other infrastructure. You would not expect e.g. Spring beans or a hibernate configuration to get thrown away under memory preasure - you would expect them to fail with OutOfMemory if they are not able to hold their necassary static information in memory. Regards Robert Am 19.03.2015 um 17:55 schrieb Kalle Korhonen: On Thu, Mar 19, 2015 at 12:24 AM, Robert Schmelzer rob...@schmelzer.cc wrote: Sorry, I was unprecise - my example should have referenced to the EntityManagerFactory (SessionFactoryImpl in Hibernate). You would not expect them, to throw away its cached configuration on memory preasure. I do not either expect that from Tapestry. I cannot make our results public because of regulatory issues. I will try to setup a show case for that and will offer a patch. This will take me a few days. I don't think we are going to simply do away with the SoftReferences without any replacements so I wouldn't even attempt at offering such a patch. I just don't agree that a memory cache should be permanent construct. If your object is not in a cache, you'll simply incur a cache miss and re-create the object on the fly. It is not typical that a cache will grow indefinitely. If you are adamant on this approach, you could probably convince us to add a symbol to control the cache behavior (i.e. to never purge objects from it). Guava has excellent, easily configurable cache implementations. Kalle Robert Am 18.03.2015 um 18:19 schrieb Kalle Korhonen: On Wed, Mar 18, 2015 at 12:44 AM, Robert Schmelzer rob...@schmelzer.cc wrote: I do not agree with you on that point. Tapestry is designed to cache the page. When you do not have enough memory to hold your pages cached basically the system does not work as designed so you should fail early. Otherwise you possible defer the problem to production use. Fail early means you should try to see the problem in the early stages on dev, where you try out all your pages. As I mentioned in my other post - you would also not expect the EntityManager to work soft-refereences or spring application context to work soft referenced. That's the definition of a memory cache - it trades memory for better performance. The primary use case for soft refences is for caching so seems to me it works exactly as designed. Your comparison to the EntityManager is flawed since it's created per request. An EntityManager is designed to be inexpensive to create. There are many areas that need improvements in Tapestry but this is not one in my opinion. However, you seem to strongly think otherwise, so you probably have some data to back this up. Do you have a memory dump and trending cpu/memory charts of a sufficiently large system you can share with us to demonstrate the problem? Jvisualvm snapshots should work fine. And furthermore - how would you like this changed? If it's just adding a Page as a threadlocal, perhaps you can just write a patch for it. Kalle Am 18.03.2015 um 04:23 schrieb Kalle Korhonen: In my opinion, soft referencing page objects is highly appropriate usage here. If there's pressure on the available memory, it makes sense to trade performance for memory instead of exiting with OoM. This is simple condition to detect and should be visible with any reasonable monitoring tool. If you are hitting memory limits, you'll need to allocate more memory for the application for optimal performance. Soft references are especially useful here because you can optimize its behavior with the -client/-server setting depending on your preferences. Kalle On Tue, Mar 17, 2015 at 4:26 PM, Howard Lewis Ship hls...@gmail.com wrote: Possibly we need something more advanced; our own reference type that can react to memory pressure by discarding pages that haven't been used in configurable amount of time. Or perhaps we could just assume that any page that has been used
Re: The active page name has not been specified
Should I file a bug with tynamo jira?
On Apr 1, 2015 3:40 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote:
On Wed, Apr 1, 2015 at 9:22 AM, George Christman gchrist...@cardaddy.com
wrote:
Kalle, when I switch from
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
to
@RequiresUser
private class TimeSheet {
The issue goes away. Am I do something wrong with my configuration?
I was going to ask you to try out exactly that. So the reason it works with
one and not the other is that the authorization is enforced at a different
point in the request lifecycle. For page level annotations to work,
naturally Tapestry must have already parsed the request and set the active
page, whereas url-based authorization happens before. There's nothing wrong
in your configuration and I do suspect this is an issue with the security
library. And sorry, I have yet to check the existing test suite regarding
this.
Kalle
Here's my complete config.
public static void
contributeSecurityConfiguration(ConfigurationSecurityFilterChain
configuration,
SecurityFilterChainFactory factory) {
// /authc/** rule covers /authc , /authc?q=name /authc#anchor
urls
as well
configuration.add(factory.createChain(/).add(factory.authc()).build());
configuration.add(factory.createChain(/profile/**).add(factory.authc()).build());
//
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
configuration.add(factory.createChain(/timesheets/**).add(factory.authc()).build());
configuration.add(factory.createChain(/admin/**).add(factory.roles(),
appsupport).build());
configuration.add(factory.createChain(/timerecords/**).add(factory.roles(),
timerecords).build());
}
On Tue, Mar 31, 2015 at 5:11 PM, George Christman
gchrist...@cardaddy.com
wrote:
Yes, still having the same issue, but only on the my Ajax form. My form
is
very complicating, so I'll try breaking it down into something simpler
tomorrow and hopefully pin point the issue. My submit buttons are up
top
and I think I'm using defer true, so I'm not sure if that has something
to
do with it. I also have some logic in my onActivate method, but I
figured
the redirection should have been happening before that method was ever
called.
On Mar 31, 2015 4:35 PM, Dimitris Zenios dimitris.zen...@gmail.com
wrote:
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to
another
page in my app where I have an ajaxformloop and it appeared to
redirect
without issue. I'm going to have to dig deeper tomorrow to find the
cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the
tapestry-core
and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which
might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone
id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=
department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes
t:mixins=formGroup rows=5/
/div
div class=modal-footer
button type=submit class=btn
btn-success${message:submit-label}/button
button type=button class=btn
btn-default
data-dismiss=modal${message:close-label}/button
Re: The active page name has not been specified
Github https://github.com/tynamo/tapestry-security, might just as well.
Kalle
On Wed, Apr 1, 2015 at 1:29 PM, George Christman gchrist...@cardaddy.com
wrote:
Should I file a bug with tynamo jira?
On Apr 1, 2015 3:40 PM, Kalle Korhonen kalle.o.korho...@gmail.com
wrote:
On Wed, Apr 1, 2015 at 9:22 AM, George Christman
gchrist...@cardaddy.com
wrote:
Kalle, when I switch from
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
to
@RequiresUser
private class TimeSheet {
The issue goes away. Am I do something wrong with my configuration?
I was going to ask you to try out exactly that. So the reason it works
with
one and not the other is that the authorization is enforced at a
different
point in the request lifecycle. For page level annotations to work,
naturally Tapestry must have already parsed the request and set the
active
page, whereas url-based authorization happens before. There's nothing
wrong
in your configuration and I do suspect this is an issue with the security
library. And sorry, I have yet to check the existing test suite regarding
this.
Kalle
Here's my complete config.
public static void
contributeSecurityConfiguration(ConfigurationSecurityFilterChain
configuration,
SecurityFilterChainFactory factory) {
// /authc/** rule covers /authc , /authc?q=name /authc#anchor
urls
as well
configuration.add(factory.createChain(/).add(factory.authc()).build());
configuration.add(factory.createChain(/profile/**).add(factory.authc()).build());
//
configuration.add(factory.createChain(/timesheet/**).add(factory.authc()).build());
configuration.add(factory.createChain(/timesheets/**).add(factory.authc()).build());
configuration.add(factory.createChain(/admin/**).add(factory.roles(),
appsupport).build());
configuration.add(factory.createChain(/timerecords/**).add(factory.roles(),
timerecords).build());
}
On Tue, Mar 31, 2015 at 5:11 PM, George Christman
gchrist...@cardaddy.com
wrote:
Yes, still having the same issue, but only on the my Ajax form. My
form
is
very complicating, so I'll try breaking it down into something
simpler
tomorrow and hopefully pin point the issue. My submit buttons are up
top
and I think I'm using defer true, so I'm not sure if that has
something
to
do with it. I also have some logic in my onActivate method, but I
figured
the redirection should have been happening before that method was
ever
called.
On Mar 31, 2015 4:35 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
Did you try the exclusion i told you about?
On Tue, Mar 31, 2015 at 11:32 PM, George Christman
gchrist...@cardaddy.com
wrote:
Thanks Dimitris, I'm guessing there is a bug in my code. I went to
another
page in my app where I have an ajaxformloop and it appeared to
redirect
without issue. I'm going to have to dig deeper tomorrow to find
the
cause
of this issue.
On Tue, Mar 31, 2015 at 4:25 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
When you include a tynamo dependency do you exclude the
tapestry-core
and
tapestry-ioc like I did? If you don't then you end up having
tapestry-core
5.4-beta22 and tapestry-core 5.4-beta28 in your class path which
might be
the source of your problem
On Tue, Mar 31, 2015 at 11:24 PM, Dimitris Zenios
dimitris.zen...@gmail.com
wrote:
t:security.hasPermission permission=DEPARTMENTS
t:modal t:id=AddDepartmentModal t:skipBody=true
t:title=message:add-department-label
t:zone t:id=departmentFormZone
id=departmentFormZone
t:form t:id=departmentForm t:zone=^
t:validate=department
div class=modal-body
t:errors/
t:textfield t:id=name t:value=
department.name
t:mixins=formGroup/
t:select t:id=parent
t:value=department.parent
t:model=departmentsModelEncoder
t:encoder=departmentsModelEncoder
t:mixins=formGroup/
t:select t:id=manager
t:value=department.manager
t:model=viewDepartment.usersModelEncoder
t:encoder=viewDepartment.usersModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS/
t:select t:id=defaultSchedule
t:value=department.defaultSchedule
t:model=viewDepartment.schedulesModelEncoder
t:encoder=viewDepartment.schedulesModelEncoder
t:mixins=formGroup
t:blankoption=ALWAYS t:validate=required/
t:textarea t:id=notes
t:value=department.notes
t:mixins=formGroup
Re: SoftReferences to PageImpl can cause performance problems
A configurable cache might be ok but what Robert is showing is a highly typical performance degradation pattern for any sufficiently large Java application. Tapestry's page cache is hardly the only place where soft references are used. When your memory budget is too small, most system engineers would argue that it's far better to slow down the application than OoM, but obviously that depends on the type of application and the traffic patterns you are facing. For the consumer facing application, it's not uncommon to see peak traffic 30-100 times over the averages at least with the applications I've been involved with and I would hate to to budget all resources based on peak consumption only. On the other hand, if the number of pages on the site is small and the site is evenly in use, then sure, it'd make sense to never purge. Kalle On Wed, Apr 1, 2015 at 3:01 PM, Howard Lewis Ship hls...@gmail.com wrote: I'm feeling that Robert is making a very good case here. I could imagine a page-level annotation to either enable or disable evication of a page instance after a period of time ... but that can come later. I do think that hard-caching of pages will leading to more predictable response performance. On Wed, Apr 1, 2015 at 7:31 AM, Robert Schmelzer rob...@schmelzer.cc wrote: Hi, I now found time to sum up a short report about that topic. I summarized my results in following pdf file: http://www.schmelzer.cc/Downloads/Files/Tapestry-Memory-Performance.pdf The main issue is, that you are able to bring a Tapestry based system into a situation where it gets slower and slower and finally event not responding any more, just be decreasing memory on the JVM and you DO NOT get any error message or OutOfMemory warning or GC overhead warning. And that only because the PageImpl instances are held in SoftReferences. My opinion is still, that this does not work as it is supposed to do and I keep with my example about other infrastructure. You would not expect e.g. Spring beans or a hibernate configuration to get thrown away under memory preasure - you would expect them to fail with OutOfMemory if they are not able to hold their necassary static information in memory. Regards Robert Am 19.03.2015 um 17:55 schrieb Kalle Korhonen: On Thu, Mar 19, 2015 at 12:24 AM, Robert Schmelzer rob...@schmelzer.cc wrote: Sorry, I was unprecise - my example should have referenced to the EntityManagerFactory (SessionFactoryImpl in Hibernate). You would not expect them, to throw away its cached configuration on memory preasure. I do not either expect that from Tapestry. I cannot make our results public because of regulatory issues. I will try to setup a show case for that and will offer a patch. This will take me a few days. I don't think we are going to simply do away with the SoftReferences without any replacements so I wouldn't even attempt at offering such a patch. I just don't agree that a memory cache should be permanent construct. If your object is not in a cache, you'll simply incur a cache miss and re-create the object on the fly. It is not typical that a cache will grow indefinitely. If you are adamant on this approach, you could probably convince us to add a symbol to control the cache behavior (i.e. to never purge objects from it). Guava has excellent, easily configurable cache implementations. Kalle Robert Am 18.03.2015 um 18:19 schrieb Kalle Korhonen: On Wed, Mar 18, 2015 at 12:44 AM, Robert Schmelzer rob...@schmelzer.cc wrote: I do not agree with you on that point. Tapestry is designed to cache the page. When you do not have enough memory to hold your pages cached basically the system does not work as designed so you should fail early. Otherwise you possible defer the problem to production use. Fail early means you should try to see the problem in the early stages on dev, where you try out all your pages. As I mentioned in my other post - you would also not expect the EntityManager to work soft-refereences or spring application context to work soft referenced. That's the definition of a memory cache - it trades memory for better performance. The primary use case for soft refences is for caching so seems to me it works exactly as designed. Your comparison to the EntityManager is flawed since it's created per request. An EntityManager is designed to be inexpensive to create. There are many areas that need improvements in Tapestry but this is not one in my opinion. However, you seem to strongly think otherwise, so you probably have some data to back this up. Do you have a memory dump and trending cpu/memory charts of a sufficiently large system you can share with us to demonstrate the problem? Jvisualvm snapshots should work fine. And furthermore - how would you like this changed? If it's just adding a Page as a
