[BLOSSOM-178] Add exposeModelAttributes property on UuidRedirectViewResolver Created: 27/Jun/14  Updated: 08/Dec/14  Resolved: 25/Jul/14

Status: Closed
Project: Blossom
Component/s: None
Affects Version/s: 2.0.3, 3.0
Fix Version/s: 2.0.6, 3.0.3

Type: Improvement Priority: Critical
Reporter: Jean-Charles Robert Assignee: Tobias Mattsson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Magnolia 4.5.11
Blossom 2.0.3
Spring 3.2.4.RELEASE


Attachments: Text File ExtendedUuidRedirectViewResolver.java     Text File threads_report.txt     Text File threads_report_2.txt    
Issue Links:
relation
is related to BLOSSOM-187 Performance problem related to Specia... Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

We have the possibility in the Spring ViewResolver to set the attribute "exposeModelAttributes". When false, this will avoid to pass the model attributes to the request and when redirect have ugly string parameters visible in the url. In blossom, this option solves a big performance problem.

I added this functionality by extending the UuidRedirectViewResolver in order to expose the "exposeModelAttributes" variable. (See java file attached)

blossom-servlet.xml
  <bean class="com.aperto.bos.blossom.BosUuidRedirectViewResolver">
    <property name="order" value="1" />
    <property name="exposeModelAttributes" value="false" />
  </bean>

Reason is: The parameters in url cause a huge performance problem.
We have a page with lot of components (areas, components that contains other components) all are configured with blossom, and it seems that the request parameters will be transferred to every @controller mapping request, the load of the page is then extremely slow. (for example page.html?errors=true)
Without paramters, the page is loaded regulary.
The problem in editMode is not solved, because of the "mgnlPreview", etc..



 Comments   
Comment by Tobias Mattsson [ 04/Jul/14 ]

Hi Jean-Charles,

Do you have any further details on the performance problems? I'd be very interested to find out what's causing this. The parameters should mean no extra processing as they're carried along from controller to controller in the request object.

Comment by Jean-Charles Robert [ 10/Jul/14 ]

Hello Tobias,

I tried to research and it has maybe something to do with the "SpecialAttributeRequestWrapper".
What I did: I have a page with a lot of areas and components in cascade (that means for example one component that containes one area, that area itself contains components that can also contains a list of sub-components.)

  • Calling the page without parameter .html: No problem
  • Calling the page with parameter .html?error=true OR saving a dialog in the page (that means reload of the page with parameter .html?mgnlCK=1405007802225): really slow, about a minute!
    I activated the debug mode and made randomly several pauses during the loading of the page.
    The breakpoint fell always while in the "getAttribute" method called by Blossom class SpecialAttributeRequestWrapper.
    So far I could explore, it seems like it is almost turning in circle because "super.getAttribute" in shouldMasquerade() method is calling againt the requestAttribute Method

See in attachment 2 of the thread reports.
So i'm not sure to about the real cause. I would be glad to have your advice or result of own investigations

Comment by Jean-Charles Robert [ 25/Jul/14 ]

Hi Tobias,
what about the performance problem?
I found this issue http://jira.magnolia-cms.com/browse/BLOSSOM-130 it seems to be the same problem, but it has no solution yet
The loop on getAttributes caused by the shouldMasquerade() method is responsible of a critical performance cost: the page could not be rendered in less than 45 seconds..
Should `we open a new Jira-Issue?

Comment by Tobias Mattsson [ 25/Jul/14 ]

I've created BLOSSOM-187 to track this problem.

Generated at Sun Feb 11 23:30:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.