Re: Slow rendering
I'm so sorry but i could not understand the question. If it is in server side than you can instrument it with JProfiler or JxInsight. If it is on client side dynaTrace can help you or even google chrome javascript can help you to detect the problem On Thu, Feb 16, 2012 at 10:42 PM, Jürgen Lind juergen.l...@iteratec.dewrote: Hi, as I was saying in the original post, in rare cases the tree degenerates to a plain list - i.e a tree with one (hidden) root node and up to 5000 children that are rendered at the same time. Please do not ask me, why our customer would want that - it is how it is for the time being ;-) J. On 16.02.2012 21:13, Igor Vaynberg wrote: why is your tree rendering all the nodes ahead of time? shouldnt it render them lazily as they are expanded? -igor On Thu, Feb 16, 2012 at 10:50 AM, Jürgen Lindjuergen.l...@iteratec.de wrote: Hi there, I am currently encountering a problem that I don't know how to attack... We have developed an application that uses the Tree-Component to show hierarchical data to the user. In some cases, the tree degenerates to a plain list that can be quite large. Now, if the list has around 1000 entries, the rendering phase for the tree takes approx. 1 second, which seems to be ok. For 2500 entries, the rendering time goes up to around 11 seconds and with 5000 entries, we're looking at approx. 30 seconds. Now, I would like to find out, which part of the component tree causes these huge numbers, but I have run out of ideas on how to track down these numbers. The last point I was able to measure was between onBeforeRender and onAfterRender of my subclassed LabelTree component. Any suggestions on how to instrument my application without building a custom wicket package? Kind Regards, J. -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org Mit freundlichen Grüßen, Jürgen Lind -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem
Re: Stack Overflow Error
(Unknown Source) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source) at org.apache.wicket.Component.writeObject(Component.java:4439) at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.writeArray(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem
XML Serialization Wicket
Hi. As you know, Wicket uses disk storage to save web pages by serializing them. PageMap and DiskPageStore classes are examples for it. Is there any way to change the serialization type from DOM Serialization to SAX Serialization in these classes ? If serialization of an object seralization tree depth is high what you have to do is just increasing the java argument Xss or changing the serialization method from DOM to SAX Thanks -- Pamir Erdem
Re: XML Serialization Wicket
No, I'm not dealing with PageSizes. I'm dealing to decrea stack tree depth in serialization. One way to achieve this converting changing DomSerializer to SAXSerializer. So is there any way to make it possible in wicket ? 2009/11/13 Uwe Schäfer schae...@thomas-daily.de Pamir Erdem schrieb: As you know, Wicket uses disk storage to save web pages by serializing them. PageMap and DiskPageStore classes are examples for it. Is there any way to change the serialization type from DOM Serialization to SAX Serialization in these classes ? If serialization of an object seralization tree depth is high what you have to do is just increasing the java argument Xss or changing the serialization method from DOM to SAX For debugging purposes in dev environments, once a serialized Page Size exceeds a certain limit, we produce XML via XStream in order to be able to look at it. Is this what you´re looking for? cu uwe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem
Re: XML Serialization Wicket
Sorry for the information that i gave, i tried to explain how wicket stores information. But we really want to know if there is a way to do in SAX way, cause as you know java's default serializer uses DOM Serializer. On Fri, Nov 13, 2009 at 6:07 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: wicket doesnt store pages using xml. we use ObjectOutputStream which uses java's serialization format, not xml. -igor On Fri, Nov 13, 2009 at 6:37 AM, Pamir Erdem pamir.er...@gmail.com wrote: No, I'm not dealing with PageSizes. I'm dealing to decrea stack tree depth in serialization. One way to achieve this converting changing DomSerializer to SAXSerializer. So is there any way to make it possible in wicket ? 2009/11/13 Uwe Schäfer schae...@thomas-daily.de Pamir Erdem schrieb: As you know, Wicket uses disk storage to save web pages by serializing them. PageMap and DiskPageStore classes are examples for it. Is there any way to change the serialization type from DOM Serialization to SAX Serialization in these classes ? If serialization of an object seralization tree depth is high what you have to do is just increasing the java argument Xss or changing the serialization method from DOM to SAX For debugging purposes in dev environments, once a serialized Page Size exceeds a certain limit, we produce XML via XStream in order to be able to look at it. Is this what you´re looking for? cu uwe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem
Re: XML Serialization Wicket
Again sorry i sent it too quickly, BinarySerialization is default, but i want to do it in XMLSerializaion and with SAXParse is it possible ? On Fri, Nov 13, 2009 at 8:27 PM, Pamir Erdem pamir.er...@gmail.com wrote: Sorry for the information that i gave, i tried to explain how wicket stores information. But we really want to know if there is a way to do in SAX way, cause as you know java's default serializer uses DOM Serializer. On Fri, Nov 13, 2009 at 6:07 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: wicket doesnt store pages using xml. we use ObjectOutputStream which uses java's serialization format, not xml. -igor On Fri, Nov 13, 2009 at 6:37 AM, Pamir Erdem pamir.er...@gmail.com wrote: No, I'm not dealing with PageSizes. I'm dealing to decrea stack tree depth in serialization. One way to achieve this converting changing DomSerializer to SAXSerializer. So is there any way to make it possible in wicket ? 2009/11/13 Uwe Schäfer schae...@thomas-daily.de Pamir Erdem schrieb: As you know, Wicket uses disk storage to save web pages by serializing them. PageMap and DiskPageStore classes are examples for it. Is there any way to change the serialization type from DOM Serialization to SAX Serialization in these classes ? If serialization of an object seralization tree depth is high what you have to do is just increasing the java argument Xss or changing the serialization method from DOM to SAX For debugging purposes in dev environments, once a serialized Page Size exceeds a certain limit, we produce XML via XStream in order to be able to look at it. Is this what you´re looking for? cu uwe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem -- Pamir Erdem
Re: XML Serialization Wicket
That's cool thanks On Fri, Nov 13, 2009 at 8:47 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: sure, you can implement your own ipagestore and save pages however you want. -igor On Fri, Nov 13, 2009 at 10:43 AM, Pamir Erdem pamir.er...@gmail.com wrote: Again sorry i sent it too quickly, BinarySerialization is default, but i want to do it in XMLSerializaion and with SAXParse is it possible ? On Fri, Nov 13, 2009 at 8:27 PM, Pamir Erdem pamir.er...@gmail.com wrote: Sorry for the information that i gave, i tried to explain how wicket stores information. But we really want to know if there is a way to do in SAX way, cause as you know java's default serializer uses DOM Serializer. On Fri, Nov 13, 2009 at 6:07 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: wicket doesnt store pages using xml. we use ObjectOutputStream which uses java's serialization format, not xml. -igor On Fri, Nov 13, 2009 at 6:37 AM, Pamir Erdem pamir.er...@gmail.com wrote: No, I'm not dealing with PageSizes. I'm dealing to decrea stack tree depth in serialization. One way to achieve this converting changing DomSerializer to SAXSerializer. So is there any way to make it possible in wicket ? 2009/11/13 Uwe Schäfer schae...@thomas-daily.de Pamir Erdem schrieb: As you know, Wicket uses disk storage to save web pages by serializing them. PageMap and DiskPageStore classes are examples for it. Is there any way to change the serialization type from DOM Serialization to SAX Serialization in these classes ? If serialization of an object seralization tree depth is high what you have to do is just increasing the java argument Xss or changing the serialization method from DOM to SAX For debugging purposes in dev environments, once a serialized Page Size exceeds a certain limit, we produce XML via XStream in order to be able to look at it. Is this what you´re looking for? cu uwe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem -- Pamir Erdem - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem
org.apachewicket.protocol.http.WebRequestCycleProcessor
()
requestCodingStrategy.pathForTarget(target) != null)
{
String msg = Direct access not allowed for mounted targets;
// the target was mounted, but we got here via another path
// : deny the request
log.error(msg + [request= + requestCycle.getRequest() + ,target= +
target +
,session= + Session.get() + ]);
throw new
AbortWithWebErrorCodeException(HttpServletResponse.SC_FORBIDDEN, msg);
}
}
// (WICKET-1356) in case no target was found, return null here.
RequestCycle will deal with it
// possible letting wicket filter to pass the request down the filter
chain
/*
if (target == null)
{
// if we get here, we have no recognized Wicket target, and thus
// regard this as a external (non-wicket) resource request on
// this server
return resolveExternalResource(requestCycle);
}
*/
return target;
}
--
Pamir Erdem
Re: org.apachewicket.protocol.http.WebRequestCycleProcessor
Hi
There are parts in web which make ajax calls. In this situtation on request
blocks the piece of code till it returns a value. Do you recommend anything
about ajax calls in a web page?
Thanks
Pamir
On Tue, Nov 10, 2009 at 9:28 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
can you submit a quickstart that reproduces this?
the lock on session only blocks concurrent requests from the browser,
which is usually not a big deal because most users operate one window
at a time.
also we do not get the same results in our wicket-threadtest project.
-igor
On Tue, Nov 10, 2009 at 10:17 AM, Pamir Erdem pamir.er...@gmail.com
wrote:
From wicket source code WebRequestCycleProcessor has a lock on session.
(Look at the source code below).
From a profiler we can easily observe that %57 of the time is spent on
this
function especially on lock region.
Is there any way to speed it up this source code ?
/**
* @see
org.apache.wicket.request.IRequestCycleProcessor#resolve(org.apache.wicket.RequestCycle,
* org.apache.wicket.request.RequestParameters)
*/
public IRequestTarget resolve(final RequestCycle requestCycle,
final RequestParameters requestParameters)
{
IRequestCodingStrategy requestCodingStrategy =
requestCycle.getProcessor()
.getRequestCodingStrategy();
final String path = requestParameters.getPath();
IRequestTarget target = null;
// See whether this request points to a bookmarkable page
if (requestParameters.getBookmarkablePageClass() != null)
{
target = resolveBookmarkablePage(requestCycle, requestParameters);
}
// See whether this request points to a rendered page
else if (requestParameters.getComponentPath() != null)
{
// marks whether or not we will be processing this request
boolean processRequest = true;
synchronized (requestCycle.getSession())
{
// we need to check if this request has been flagged as
// process-only-if-path-is-active and if so make sure this
// condition is met
if (requestParameters.isOnlyProcessIfPathActive())
{
// this request has indeed been flagged as
// process-only-if-path-is-active
Session session = Session.get();
IPageMap pageMap =
session.pageMapForName(requestParameters.getPageMapName(),
false);
if (pageMap == null)
{
// requested pagemap no longer exists - ignore this
// request
processRequest = false;
}
else if (pageMap instanceof AccessStackPageMap)
{
AccessStackPageMap accessStackPageMap = (AccessStackPageMap)pageMap;
if (accessStackPageMap.getAccessStack().size() 0)
{
final Access access = (Access)accessStackPageMap.getAccessStack()
.peek();
final int pageId = Integer
.parseInt(Strings.firstPathComponent(requestParameters
.getComponentPath(), Component.PATH_SEPARATOR));
if (pageId != access.getId())
{
// the page is no longer the active page
// - ignore this request
processRequest = false;
}
else
{
final int version = requestParameters.getVersionNumber();
if (version != Page.LATEST_VERSION
version != access.getVersion())
{
// version is no longer the active version -
// ignore this request
processRequest = false;
}
}
}
}
else
{
// TODO also this should work..
}
}
}
if (processRequest)
{
try
{
target = resolveRenderedPage(requestCycle, requestParameters);
}
catch (IgnoreAjaxRequestException e)
{
target = EmptyAjaxRequestTarget.getInstance();
}
}
else
{
throw new PageExpiredException(Request cannot be processed);
}
}
// See whether this request points to a shared resource
else if (requestParameters.getResourceKey() != null)
{
target = resolveSharedResource(requestCycle, requestParameters);
}
// See whether this request points to the home page
else if (Strings.isEmpty(path) || (/.equals(path)))
{
target = resolveHomePageTarget(requestCycle, requestParameters);
}
// NOTE we are doing the mount check as the last item, so that it will
// only be executed when everything else fails. This enables URLs like
// /foo/bar/?wicket:bookmarkablePage=my.Page to be resolved, where
// is either a valid mount or a non-valid mount. I (Eelco) am not
// absolutely sure this is a great way to go, but it seems to have been
// established as the default way of doing things. If we ever want to
// tighten the algorithm up, it should be combined by going back to
// unmounted paths so that requests with Wicket parameters like
// 'bookmarkablePage' are always created and resolved in the same
// fashion. There is a test for this in UrlMountingTest.
if (target == null
getPage question
In the attachment you'll see that the regions that intersect with each other indicates that the slowest method execution on stack trace. If you look at Count Delta on getPage method you will see that it equals to 37 which means thatgetPage is executed 37 times in a request. There are too many ajax calls in the web page. Is there anything which we can do to tune that screen ? -- Pamir Erdem - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: org.apachewicket.protocol.http.WebRequestCycleProcessor
Could you please send me a link that how i can achieve this over wicket ?
On Wed, Nov 11, 2009 at 1:18 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
well, its either we lock on the page, or you have to make sure all
your code is threadsafe.
yes, this can be a problem for a lot of concurrent ajax requests, you
just have to make sure your responses are fast. eg if you have a
time-consuming operation do it in a background thread and make ajax
calls poll instead of block.
-igor
On Tue, Nov 10, 2009 at 2:09 PM, Pamir Erdem pamir.er...@gmail.com
wrote:
Hi
There are parts in web which make ajax calls. In this situtation on
request
blocks the piece of code till it returns a value. Do you recommend
anything
about ajax calls in a web page?
Thanks
Pamir
On Tue, Nov 10, 2009 at 9:28 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
can you submit a quickstart that reproduces this?
the lock on session only blocks concurrent requests from the browser,
which is usually not a big deal because most users operate one window
at a time.
also we do not get the same results in our wicket-threadtest project.
-igor
On Tue, Nov 10, 2009 at 10:17 AM, Pamir Erdem pamir.er...@gmail.com
wrote:
From wicket source code WebRequestCycleProcessor has a lock on
session.
(Look at the source code below).
From a profiler we can easily observe that %57 of the time is spent on
this
function especially on lock region.
Is there any way to speed it up this source code ?
/**
* @see
org.apache.wicket.request.IRequestCycleProcessor#resolve(org.apache.wicket.RequestCycle,
* org.apache.wicket.request.RequestParameters)
*/
public IRequestTarget resolve(final RequestCycle requestCycle,
final RequestParameters requestParameters)
{
IRequestCodingStrategy requestCodingStrategy =
requestCycle.getProcessor()
.getRequestCodingStrategy();
final String path = requestParameters.getPath();
IRequestTarget target = null;
// See whether this request points to a bookmarkable page
if (requestParameters.getBookmarkablePageClass() != null)
{
target = resolveBookmarkablePage(requestCycle, requestParameters);
}
// See whether this request points to a rendered page
else if (requestParameters.getComponentPath() != null)
{
// marks whether or not we will be processing this request
boolean processRequest = true;
synchronized (requestCycle.getSession())
{
// we need to check if this request has been flagged as
// process-only-if-path-is-active and if so make sure this
// condition is met
if (requestParameters.isOnlyProcessIfPathActive())
{
// this request has indeed been flagged as
// process-only-if-path-is-active
Session session = Session.get();
IPageMap pageMap =
session.pageMapForName(requestParameters.getPageMapName(),
false);
if (pageMap == null)
{
// requested pagemap no longer exists - ignore this
// request
processRequest = false;
}
else if (pageMap instanceof AccessStackPageMap)
{
AccessStackPageMap accessStackPageMap =
(AccessStackPageMap)pageMap;
if (accessStackPageMap.getAccessStack().size() 0)
{
final Access access =
(Access)accessStackPageMap.getAccessStack()
.peek();
final int pageId = Integer
.parseInt(Strings.firstPathComponent(requestParameters
.getComponentPath(), Component.PATH_SEPARATOR));
if (pageId != access.getId())
{
// the page is no longer the active page
// - ignore this request
processRequest = false;
}
else
{
final int version = requestParameters.getVersionNumber();
if (version != Page.LATEST_VERSION
version != access.getVersion())
{
// version is no longer the active version -
// ignore this request
processRequest = false;
}
}
}
}
else
{
// TODO also this should work..
}
}
}
if (processRequest)
{
try
{
target = resolveRenderedPage(requestCycle, requestParameters);
}
catch (IgnoreAjaxRequestException e)
{
target = EmptyAjaxRequestTarget.getInstance();
}
}
else
{
throw new PageExpiredException(Request cannot be processed);
}
}
// See whether this request points to a shared resource
else if (requestParameters.getResourceKey() != null)
{
target = resolveSharedResource(requestCycle, requestParameters);
}
// See whether this request points to the home page
else if (Strings.isEmpty(path) || (/.equals(path)))
{
target = resolveHomePageTarget(requestCycle, requestParameters
Re: getPage question
Again it's related with ajax calls. It coud solve this issue when implementing ajax polls. Thanks On Wed, Nov 11, 2009 at 1:18 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: your attachment never made it through. -igor On Tue, Nov 10, 2009 at 3:12 PM, Pamir Erdem pamir.er...@gmail.com wrote: In the attachment you'll see that the regions that intersect with each other indicates that the slowest method execution on stack trace. If you look at Count Delta on getPage method you will see that it equals to 37 which means thatgetPage is executed 37 times in a request. There are too many ajax calls in the web page. Is there anything which we can do to tune that screen ? -- Pamir Erdem - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pamir Erdem
