voyent
Messages posted by: dkohl  XML
Profile for dkohl -> Messages posted by dkohl [13]
Author Message

greg.dick wrote:
Hi,
...
I see that you are using synchronous connections (ie. no blocking connections, no AJAX interaction at all)
...
 

it's independent of this setting. i checked also the concurrentDOMview-setting true or false (as suggested in other postings). doesn't solve the problem, too.

greetings

daniel

schroederw wrote:
Is it possible, that the problem is (partly) related to http://www.icefaces.org/JForum/posts/list/8482.page ?
 

i've never seen this exception. my sessions are never invalidated manually.
and the memory leak is much bigger than you would expect.
with 256MB reserved under Tomcat 6 the memory will run down to about 50MB after 2000 sessions and will never be freed by the GC using 1.7 and the conditions mentioned above.

greetings

daniel

greg.dick wrote:
Ok, can you give us a bit more information about your application? Such as:

Asynchronous or synchronous.
 

i checked both modes as desrcibed in other comparable postings. the mode doesn't matter in my case. Concurrent DOMs didn't solve it too. it's only version dependend (1.6.2 or 1.7)

greg.dick wrote:

Are you using any server push rendering groups.
 

no server initiated rendering.


greg.dick wrote:

Request or sessions scoped beans.
 

ONLY session beans. i never use request beans.
two application-scoped beans used.

greg.dick wrote:

Standard or extended request scope.
 

i've not changed the standard settings. so, beans are being killed after session timeout (i also tried different times from 1min - 5min).


greg.dick wrote:

Any other extensions or third party frameworks.
 

Hibernate 3.2 and its dependencies and mysql, thats it (i can you send my lib-dir in detail if you want). java version doesnt matter.

greg.dick wrote:

Have you updated the regular expressions in JMeter to extract the ice.view and ice.session parameters because they've changed between 1.6 and 1.7?
 

i only use the standards. i added a endless-thread group, a constant timer (from 20ms up to 2000ms), and an unspectacular standard-HTTP-sampler :-)


greg.dick wrote:

And perhaps some info on the nature of your Jmeter scripts. Do they operate in a loop with a fixed set of Sessions, or continuously allocate and discard them, etc.
 

sure , i can send it to you tomorrow. but it's just created with a normal JMeter described the way above. nothing more. simple calls! nothing special.


greg.dick wrote:
This info would be helpful.
 

i can also give some more details about your source from JProfiler, but i need a bit time to set it up.


greetings

hi greg,

thanks for your really detailed answer!

i checked my site with 1.6.2 and exactly the same source, and there wasn't a memory leak at all, running 60.000 (in words sixty-thousand) sessions called by a simple JMeter script over the weekend. no leaks at all! no "out of memory"-exceptions! it runs really fine! and my app is a really big one! :-)

changing the build path to 1.7 libs, running under exactly the same conditions and infrastructure, results in "out-of-memory" error after a few hundred sessions.

i think this is a little bit strange an has the flavour of a bug :-)

the "call"-conditions outside should not be responsible for memory-leaks inside.


greetings

daniel

jtchira wrote:
Thanks........ I had change a param in my web xml........ thanks thans 

i've the same problem sometimes and i don't know the cause of it.
however ....it would be really interesting to know WHAT PARAMETER you chenged in your web.xml. :-)
Unfortunately 1.7 has an potential memory leak who makes it nearly unusable for production, even with higher memory settings.

Running the following page that only shows static text (and doesn't refer to beans) the memory decreases constantly.

Code:
 <?xml version="1.0" encoding="ISO-8859-1" ?>
 <jsp:root version="1.2" xmlns:jsp="http://java.sun.com/JSP/Page"
 	xmlns:f="http://java.sun.com/jsf/core"
 	xmlns:h="http://java.sun.com/jsf/html"
 	xmlns:ice="http://www.icesoft.com/icefaces/component">
 	<jsp:directive.page contentType="text/html;charset=ISO-8859-1"
 		pageEncoding="ISO-8859-1" />
 	<f:view>
 		<ice:outputDeclaration doctypeRoot="HTML"
 			doctypePublic="-//W3C//DTD HTML 4.01 Transitional//EN"
 			doctypeSystem="http://www.w3.org/TR/html4/loose.dtd" />
 		<html>
 			<head>
 				<title><ice:outputText value="ICEfaces, Ajax for Java EE" />
 				</title>
 				<ice:outputStyle href="./xmlhttp/css/royale/royale.css" />
 				
 				<ice:outputStyle href="style.css" />
 			</head>
 			<body>
 
 				<ice:form>
 					<ice:outputText value="Dummy"/>
 				</ice:form>
 
 			</body>
 		</html>
 	</f:view>
 </jsp:root>
 


i've profiled this session with (JProfiler 5.1.3) and called it with JMeter. Session timeout 5 minutes. garbage collection doesn't free memory too.

any ideas?
i solved this by setting the size in px for each component:

Code:
 <ice:column  style="width:410px;">
 	<f:facet name="header">
            <ice:outputText value="Name" style="width:410px;"/>
          </f:facet>
          <ice:commandLink value="....." />
 </ice:column>							
 


works fine for scrollable und unscrollable tables, but it's still a workaround. i would really prefer the columnWidths-attribute-solution.

Greetings
Unfortunately columns and headers doesn't match on scrollable datatables, even if i set the columns manually (using xp.css or rime.css).

Code:
 columnWidths="400px,200px,100px,100px"
 


Using IceFaces 1.7.0, Linux, Firefox 2.0
Hi all,

i found a solution to safely invalidate a session in a safe an correct way.

What do you need:

- An application bean
- A little javasrcipt-fragment


In the application bean you should register the session-object you want to invalidate. I do this by simply call an method of my application bean with the session reference. The application bean holds this ref in an own variable.

The application bean itself has a thread. This can be startet from anywhere. I start this thread after registering the session. This thread releases the currently registered session delayed (> 100ms). This gives the framework the time to end the current phase.

An auto-update after the session has been released is easily done by this short javascript-fragment placed in the onclick-method (in my case).

Code:
 <ice:commandButton  action="#mybean.invalidate"  onclick="setTimeout('location.reload();', 1500);"
 


In short:

mybean.invalidate registers the session object in an application-bean and starts the invalidation-thread for the delay. the javascript-code forces the reload of the page.


greetings
Here the solution:

a) Create a new class for the surrounding UISeries (datatable, panelseries...). The field we've to reset is protected.
b) Create a "forceRefresh"-method with the following code:

Code:
 	public void forceRefresh() {
 		savedChildren.clear();
 	}
 


c) Create binding for this UISeries.
d) Call this method before the new page is rendered (e.g. when a button is pressed).

For me it works really fine and seems to be an elegant workaround for this problem.

Greetings

Daniel
Here the solution:

a) Create a new class for the surrounding UISeries (datatable, panelseries...). The field we've to reset is protected.
b) Create a "forceRefresh"-method with the following code:

Code:
 	public void forceRefresh() {
 		savedChildren.clear();
 	}
 


c) Create binding for this UISeries.
d) Call this method before the new page is rendered (e.g. when a button is pressed).

For me it works really fine and seems to be an elegant workaround for this problem.

Greetings

Daniel
Here the solution:

a) Create a new class for the surrounding UISeries (datatable, panelseries...). The field we've to reset is protected.
b) Create a "forceRefresh"-method with the following code:

Code:
 	public void forceRefresh() {
 		savedChildren.clear();
 	}
 


c) Create binding for this UISeries.
d) Call this method before the new page is rendered (e.g. when a button is pressed).

For me it works really fine and seems to be an elegant workaround for this problem.

Greetings

Daniel
hi all,

did one of you solve this problem? i'm running on Liferay 4.2 and ran also in this problem. Changing to 4.3 doesn't solve it too.....

greetings


 
Profile for dkohl -> Messages posted by dkohl [13]
Go to:   
Powered by JForum 2.1.7ice © JForum Team