Tags
People
Badges
Help-
CORE FRAMEWORK
FEATURED COMPONENTS
-
RESOURCES
-
LEARN ZK
RESOURCES
ZK 5.01 (in a spring 3 environment) seems very slow, as well as have some major issues (result of some kind of memory leakage?) when utilizing controllers that extend Window and implement AfterCompose in order to make use of auto-wiring of variables and events for components in a underlying zul-page in which annotated data-bindings are used extensively.
In an abstract controller that implements AfterCompose (and extends Window) I've got:
@Override
public void afterCompose() {
Components.wireVariables(this, this);
Components.addForwards(this, this);
}i seem to be running into this problem with zk 5.0.7 now.
any progress or means to avoid it?
most "bean not found"-messages here concern _ignoreXel and zkBindingComposer.
PS: using macro-components seems to make it even worse.
Hi ryanwong00,
Thanks for the above test case. The root cause of why it happens is what Henri already mentioned in the previous response. If VariableResolver implementation does not have a proper hashcode() and equals() method this will cause PageImpl to see them as different instances and they will get added to test.zul PageImpl instance. I have refactored ZK Spring 1.2.0RC and ZK Spring 3.0RC variable resolver mechanism to improve performance and guard against possible memory leak. Please download latest freshly release of it here. Also this necessitated updates to all VariableResolver implementations in zkplus such as Spring DelegatingVariableResolver and JndiVariableResolver etc classes. So you probably want to use the the latest ZK Freshly containing those changes(not uploaded yet). I will notify everyone here once it is uploaded on sf.net
Thanks
- Ashish
Hi Ashish,
Please find followings for reproducing the case.
1. Assuming that all zul will be placed under /test. Then prepare a window with a button. (i.e. test.zul)
<?page title="new page title" contentType="text/html;charset=UTF-8"?>
<zk>
<window title="new page title" border="normal" id="mainwin">
<button label="Open page A" onClick='Executions.createComponents("/test/pageA.zul", mainwin, null);'></button>
</window>
</zk>
2. Prepare a zul page (i.e. pageA.zul) with variable-resolver tag and this page will be loaded when the button of step 1 is clicked
<?variable-resolver class="org.zkoss.zkplus.spring.DelegatingVariableResolver"?> <window title="PageA" border="normal" closable="true" mode="overlapped"> Page A </window>
3. Load the test.zul and click the button several times. You will notice that the no. of "No bean named .." messages increased in every click.
For other variable resolver, since they are not like Spring that will provide trace messages, I believe that the no. of variable-resolver will still be increased every time a variable-resolver tagged page is loaded. For ease of tracking, you may consider including following code
System.out.println(this + ":" + this.hashCode() + ":" + _resolvers.size() + ":" + _resolvers);
Thanks
Ryan :-)
@juwian
>>However looking into the log at TRACE level I still se that ZK seems to attempt to wire Spring-managed controller(?)
fields that are not annotated for Spring Dependency Injection using @Autowired or @Resource, for example:
>>The number of DI attempts don't increase as before but there are still a basic set there.. Is this correct behavior?
Seems a bit odd to me, why attempt DI on obviously private fields that aren't annotated for Spring DI?
This is expected because Components.wireVariables(); is not Spring specific and by spec it will try to wire controller fields by name. At the moment it is not done the way you said above. Unfortunately you will have to write your custom wiring mechanism for your Spring specific needs for now. I'll appreciate if you come up with some implementation for this or throw in some ideas spec wise.
>>When however introducing the same new "zkspring-core.jar" in another real web application project of mine many things appear to fail
Appreciate if you could be more specific about failed cases/msgs. Was that working with the zkspring-security.jar that had memory leak issue?
@ryanwong00
as juwian mentioned I don't see increased number of "No bean named". Can you provide some sample code to reproduce your case?
Thanks
- Ashish
Hi Ashish/Henri,
Thanks for the updated jar. However, there are still minor issues.
All zul pages with <?variable-resolver class="org.zkoss.zkplus.spring.DelegatingVariableResolver"?> defined will trigger the "No bean named ..." messages, which I think is expected.
However, the "No bean named ..." messages will be cumulative within the same desktop.
Assuming I've got zul pages A, B with the above variable-resolver tag defined. When I load page A, I may get, let say, 10 messages. When I then load page B, I will get 10 + 10 messages. When I reload page B again, I will get 10 + 10 + 10,... so on and so forth. The only way to reset the increasing number of messages is to reload the whole desktop.
I think the problem is probably relating to point 2 of my previous investigation. That is, everytime a zul page with that variable-resolver tag is loaded, it will instantiate a new VariableResolver. The instance will be attached to the PageImpl of the desktop. Thus, the list of VariableResolvers will keep growing until user reload the desktop.
The degradation shall still happen but in a much slower pace and smaller scope when comparing to the previous issue.
One more thing, this cumulative variable-resolver behavior does not limit to org.zkoss.zkplus.spring.DelegatingVariableResolver. I tried <?variable-resolver class="org.zkoss.zkplus.jndi.JndiVariableResolver"?> and the JndiVariableResolver also got this behavior too.
Thanks.
Ryan :-)
(I'll publish again - don't know if I'm the only one experiencing this - but the previous entry seems to float out from the frame rendering some parts unreadable..)
Especial thanks to you Ashish, raevel2 and ryanwong00 for your constributions. I'm still experiencing some issues, even though one is gone.
I downloaded "zk-spring-core-bin-3.0RC-FL-2010-05-14.zip" and had "zkspring-core.jar" replaced with new one in the earlier published project "leak".
The earlier mentioned issues with ever increasing load and execution times for the ZUL pages seems to be gone, they're more constant.
However looking into the log at TRACE level I still se that ZK seems to attempt to wire Spring-managed controller(?)
fields that are not annotated for Spring Dependency Injection using @Autowired or @Resource, for example:
[see above]
The number of DI attempts don't increase as before but there are still a basic set there.. Is this correct behavior?
Seems a bit odd to me, why attempt DI on obviously private fields that aren't annotated for Spring DI?
When however introducing the same new "zkspring-core.jar" in another real web application project of mine many things appear to fail.
Some ZUL-pages used for setting up some test entitites and then forwarding user to a another page (using Executions)
render completely white and blank, nothing in the log.
So unfortunately I cannot use the new jar solving the main issue with increating load times as
things earlier working perfect now don't.
As a side note I've tried adding the latest "zkspring-security.jar" from zk-spring-security-bin-3.0RC-FL-2010-05-14.zip",
as well as the latest relase of ZK 5.02, things seem to work fine until the new
mentioned zkspring-core.jar is added (replacing the old) - then some pages render blank.
Any ideas?
Thankful for all input!
Especial thanks to you Ashish, raevel2 and ryanwong00 for your constributions. I'm still experiencing some issues, even though one is gone.
I downloaded "zk-spring-core-bin-3.0RC-FL-2010-05-14.zip" and had "zkspring-core.jar" replaced with new one in the earlier published project "leak".
The earlier mentioned issues with ever increasing load and execution times for the ZUL pages seems to be gone, they're more constant.
However looking into the log at TRACE level I still se that ZK seems to attempt to wire Spring-managed controller(?) fields that are not annotated for Spring Dependency Injection using @Autowired or @Resource, for example:
No bean named 'applicationScope' found in org.springframework.beans.factory.support.DefaultListableBeanFactory@6d65fd: defining beans [afterComposeController,exampleController,genericForwardComposerController,springController,exampleService,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalPersistenceAnnotationProcessor]; root of factory hierarchy
No bean named 'requestScope' found in org.springframework.beans.factory.support.DefaultListableBeanFactory@6d65fd: defining beans [afterComposeController,exampleController,genericForwardComposerController,springController,exampleService,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalPersistenceAnnotationProcessor]; root of factory hierarchy
No bean named 'execution' found in org.springframework.beans.factory.support.DefaultListableBeanFactory@6d65fd: defining beans [afterComposeController,exampleController,genericForwardComposerController,springController,exampleService,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalPersistenceAnnotationProcessor]; root of factory hierarchy
No bean named 'arg' found in org.springframework.beans.factory.support.DefaultListableBeanFactory@6d65fd: defining beans [afterComposeController,exampleController,genericForwardComposerController,springController,exampleService,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalPersistenceAnnotationProcessor]; root of factory hierarchy
No bean named 'param' found in org.springframework.beans.factory.support.DefaultListableBeanFactory@6d65fd: defining beans [afterComposeController,exampleController,genericForwardComposerController,springController,exampleService,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalPersistenceAnnotationProcessor]; root of factory hierarchy
No bean named '_separator' found in org.springframework.beans.factory.support.DefaultListableBeanFactory@6d65fd: defining beans [afterComposeController,exampleController,genericForwardComposerController,springController,exampleService,org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,org.springframework.context.annotation.internalPersistenceAnnotationProcessor]; root of factory hierarchy
The number of DI attempts don't increase as before but there are still a basic set there.. Is this correct behavior? Seems a bit odd to me, why attempt DI on obviously private fields that aren't annotated for Spring DI?
When however introducing the same new "zkspring-core.jar" in another real web application project of mine many things appear to fail. Some ZUL-pages used for setting up some test entitites and then forwarding user to a another page (using Executions) render completely white and blank, nothing in the log.
So unfortunately I cannot use the new jar solving the main issue with increating load times as things earlier working perfect now don't.
As a side note I've tried adding the latest "zkspring-security.jar" from zk-spring-security-bin-3.0RC-FL-2010-05-14.zip", as well as the latest relase of ZK 5.02, things seem to work fine until the new mentioned zkspring-core.jar is added (replacing the old) - then some pages render blank.
Any ideas?
Thankful for all input!
Asked: 2010-04-26 08:14:45 +0800
Seen: 3,347 times
Last updated: Sep 02 '11