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);
}It seems as if ZK through Spring(?) upon loading a ZUL-page (referencing a controller using SptingDelegateVariableResolver through the attribute "use" or "apply" in a window component) attempts to wire every field in the controller (fields like _width, _visibility, _height, _zkBindingComposer etc - depends on what type of controller one is using and what ZK-superclass it extends)
ZK/Spring seems to call (SpringDelegatingVariableResolver?) getBean(name) for every protected/private field (which is strange) it finds in the controller (using reflections?) eventhough none of these are annotated as @Resource or @Autowired
It is also evident that more and more fields are attempted to be wired by ZK-Spring and since none of them should be (since they are just regular fields and not annotated for DI by spring) it results in every increasing load-time for any ZUL-page referencing a Spring-managed controller (controler-annotated bean with scope prototype). This is a major issue.
Hmm..really strange..is this a bug in the Spring-ZK integration? Anyone?
@raevel2
@juwian
Interesting. Please can someone of you post the needed lines for enabling the Tracing in the log4j.xml
I remember me that as we update our sample app 3.6.3 to spring3 and go away from the window and afterCompose stuff to GenericForwardComposer that the speed is gone much better.
So, i will have a look early for our new zk5 app.
thanks
Stephan
terrytornado:
log4j trace lines (in the example, pace the lines in the file leak/WebContent/WEB-INF/classes/log4j.properties)
log4j.rootLogger=TRACE, CONSOLE log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender log4j.appender.CONSOLE.Threshold=TRACE log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=- %d [%t] %-5p - %m%n
In order to get log4j working you need to add the following to web.xml under /leak/WEB-INF :
<context-param> <param-name>log4jConfigLocation</param-name> <param-value>/WEB-INF/log4j.properties</param-value> </context-param> <context-param> <param-name>log4jRefreshInterval</param-name> <param-value>1000</param-value> </context-param> <listener> <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class> </listener>
my 2 cents:
Is far as I know, the origin of those autowiring failures, starts at this method
org.zkoss.zk.ui.Components.Wire.wireOthers()
1 - Even that, It seems that "old" composers still alive and trying to be autoproxied (reference/garbage collector ? )
2 - When is executed ZkConfigDefinitionParser? (I could avoid "No bean named 'zkBindingComposer' adding a Spring bean in my app" )
<bean name="zkBindingComposer" class="org.zkoss.spring.config.ZkSpringBeanBindingComposer" />
To me it seems to break down to 2 issues.
1) Old composers still being alive and some kind of DI being performed by ZK/Spring on them.
2) The strange issue that ZK/Spring attempts DI (and fails since no such spring-managed-beans exist) for every field it finds in controller-classes (even though they're not annotated with @Autowire @Resource, most of them even being private to ZK super-classes such as GenericForwardComposer!)
These issues result in ever increasing load-time for any ZUL-page.
Spring-managed controllers not referenced and loaded through a ZK-component referencing them through "use" or "apply" does not seem introduce any of these issues..
I just experience this issue as well.
The worst part of this issue is that the "No bean named .." errors are cumulative amongst all sessions. For example, when user A load it's page at PC A, the server may prompt, let say, 10 such messages. When user B then load it's page at PC B, the server will prompt 10+10 -> 20 such messages.
Assuming that a composer is loaded N times, the server will suffer 10*N error at each loading. Basically, the number of errors will grow exponentially and the server will corrupt within short period of times.
Hopes that the issue will be solved soon, or, is there any workaround to avoid it?
Hi! Is there anyone in the ZK community working on this issue?
A ticket was opened the 28th of April by "ashishd" but I haven't seen any activity on that one since then..
The issue seems to be the most serious bug right now in ZK-Spring project affecting many otherwise happy users so I hope someone is working with it..
Hi juwian,
we use only 3 or 4 pieces from them, because spring should manage our zk app and not zk should manage spring.
So i will have a look on it because it's interesting for us too.
Attached my log4j.xml. Please can you copy the coresponding entries to it for showing 'out of the box' the trace.
thx
Stephan
log4j.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"
debug="false">
<appender name="STDOUT" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.out" />
<param name="Threshold" value="ALL" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{ISO8601} %-6p [%t] %c{1} M[%M] - %m\n" />
</layout>
<filter class="org.apache.log4j.varia.LevelRangeFilter">
<param name="LevelMax" value="WARN" />
</filter>
</appender>
<appender name="STDERR" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.err" />
<param name="Threshold" value="ERROR" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{ISO8601} %-6p [%t] %c{1} M[%M] - %m\n" />
</layout>
</appender>
<appender name="FILE" class="org.apache.log4j.RollingFileAppender">
<param name="File" value="./out.log.txt" />
<param name="MaxFileSize" value="5MB" />
<param name="MaxBackupIndex" value="2" />
<param name="Threshold" value="ALL" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{ISO8601} %-6p [%t] %c{1} M[%M] - %m\n" />
</layout>
</appender>
<category name="org.apache">
<priority value="INFO" />
</category>
<category name="org.hibernate">
<priority value="WARN" />
</category>
<category name="net.sf.ehcache">
<priority value="ERROR" />
</category>
<category name="org.xml">
<priority value="INFO" />
</category>
<category name="org.apache">
<priority value="INFO" />
</category>
<category name="httpclient.wire">
<priority value="INFO" />
</category>
<category name="org.hibernate.proxy">
<priority value="FATAL" />
</category>
<category name="org.springframework.beans.factory">
<priority value="INFO" />
</category>
<category name="org.springframework">
<priority value="INFO" />
</category>
<root>
<level value="ALL" />
<appender-ref ref="STDOUT" />
<appender-ref ref="STDERR" />
<!-- appender-ref ref="FILE" /-->
</root>
</log4j:configuration>
Asked: 2010-04-26 08:14:45 +0800
Seen: 3,347 times
Last updated: Sep 02 '11