Re: null lastPage at restoreAfterSerialization
I'm not sure I can provide any additional information as we just started
looking into it (though we've been seeing it for a while). For the time
being, I'm just going to set up a cron job to remove old pagemap files.
Perhaps we could make the restore block allow a null lastPage? Btw - what
happens if the only request a client ever makes is for a resource? Will
lastPage ever be set?
Thanks!
Meetesh
On Thu, Mar 5, 2009 at 1:51 PM, Matej Knopp wrote:
> Unfortunately I wasn't able to reproduce this so I don't think this
> got resolved.
>
> -Matej
>
> On Thu, Mar 5, 2009 at 8:47 PM, Meetesh Karia
> wrote:
> > I know this has been a while, but was this ever resolved? We're seeing
> the
> > same problem. And, because of this problem, Wicket is never cleaning up
> old
> > session pagemap files which leads to oodles of files in our tomcat work
> > directory.
> > Thanks,
> > Meetesh
> >
> > On Sat, Nov 22, 2008 at 5:55 AM, Carlos Pita >wrote:
> >
> >> Matej,
> >>
> >> forget what I said yesterday about session lastAccessedDate, I've
> >> debugged it in detail and tomcat is doing its part fine, I was
> >> confused by a sequence of logs that implied that the session was
> >> swapped out before a page was added to its pagemap. But later I found
> >> out that this wasn't the usual pattern so I included more log output
> >> here and there. And now it seems as if the pagemap instance that is
> >> swapped out isn't the same one where the page was first put. Below I
> >> copied the pertinent fragments of code and one example of output
> >> showing the anomaly:
> >>
> >> 1) What follows is in order to identify each pagemap instance (with
> >> thisNum):
> >>
> >> private static final class SecondLevelCachePageMap extends PageMap
> >> {
> >>
> >>
> >> private static int pageMapNum = 0;
> >> private int thisNum;
> >>
> >> private SecondLevelCachePageMap(String sessionId, Application
> >> application, String name)
> >> {
> >>
> >> synchronized (SecondLevelCachePageMap.class)
> >> {
> >> thisNum = pageMapNum++;
> >> }
> >>
> >> }
> >>
> >> 2) Now for the logging part
> >>
> >> a) First when a page is put into the pagemap
> >>
> >> public void put(Page page)
> >> {
> >> if (!page.isPageStateless())
> >> {
> >> Session session = getSession();
> >> String sessionId = session.getId();
> >> if (sessionId != null && !session.isSessionInvalidated())
> >> {
> >> // the id could have changed from null during request
> >> this.sessionId = sessionId;
> >> > log.error("put " + sessionId + " " + thisNum); <
> >> getStore().storePage(sessionId, page);
> >> setLastPage(page);
> >> dirty();
> >> }
> >> }
> >> }
> >>
> >> b) Then when a pagemap is swapped out (writeObject):
> >>
> >> private void writeObject(java.io.ObjectOutputStream s) throws
> IOException
> >> {
> >> s.defaultWriteObject();
> >> IPageStore store = getPageStore();
> >> if (sessionId != null && store instanceof IClusteredPageStore == false)
> >> {
> >> --> if (lastPage == null) log.error("writeObject1 " + sessionId + " "
> >> + thisNum); <--
> >> Object page = lastPage;
> >> if (store instanceof ISerializationAwarePageStore)
> >> {
> >> page =
> (ISerializationAwarePageStore)store).prepareForSerialization(...
> >> --> if (page == null) log.error("writeObject2 " + sessionId + " " +
> >> thisNum); <--
> >> }
> >> }
> >> .
> >> }
> >>
> >> Finally, the output looks like:
> >>
> >> 2008-11-22 04:43:58,841 PAGE 19ACC6B64E22346D494E742A0E859B52 29
> >>
> >>
> >> other pages in other sessions follows
> >>
> >> 2008-11-22 04:44:00,486 put 33932E31AE77206B5E556266170B4827 33
> >> 2008-11-22 04:44:00,201 put C6423FDD58C4B31C080700E4455F158C
> >>
> >>
> >> and about 120 secs later:
> >>
> >> 2008-11-22 04:46:36,432 writeObject1 19ACC6B64E22346D494E742A0E859B52 30
> >> 2008-11-22 04:46:36,432 writeObject2 19ACC6B64E22346D494E742A0E859B52 30
> >>
> >>
> >
Re: null lastPage at restoreAfterSerialization
I know this has been a while, but was this ever resolved? We're seeing the
same problem. And, because of this problem, Wicket is never cleaning up old
session pagemap files which leads to oodles of files in our tomcat work
directory.
Thanks,
Meetesh
On Sat, Nov 22, 2008 at 5:55 AM, Carlos Pita wrote:
> Matej,
>
> forget what I said yesterday about session lastAccessedDate, I've
> debugged it in detail and tomcat is doing its part fine, I was
> confused by a sequence of logs that implied that the session was
> swapped out before a page was added to its pagemap. But later I found
> out that this wasn't the usual pattern so I included more log output
> here and there. And now it seems as if the pagemap instance that is
> swapped out isn't the same one where the page was first put. Below I
> copied the pertinent fragments of code and one example of output
> showing the anomaly:
>
> 1) What follows is in order to identify each pagemap instance (with
> thisNum):
>
> private static final class SecondLevelCachePageMap extends PageMap
> {
>
>
> private static int pageMapNum = 0;
> private int thisNum;
>
> private SecondLevelCachePageMap(String sessionId, Application
> application, String name)
> {
>
> synchronized (SecondLevelCachePageMap.class)
> {
> thisNum = pageMapNum++;
> }
>
> }
>
> 2) Now for the logging part
>
> a) First when a page is put into the pagemap
>
> public void put(Page page)
> {
> if (!page.isPageStateless())
> {
> Session session = getSession();
> String sessionId = session.getId();
> if (sessionId != null && !session.isSessionInvalidated())
> {
> // the id could have changed from null during request
> this.sessionId = sessionId;
> > log.error("put " + sessionId + " " + thisNum); <
> getStore().storePage(sessionId, page);
> setLastPage(page);
> dirty();
> }
> }
> }
>
> b) Then when a pagemap is swapped out (writeObject):
>
> private void writeObject(java.io.ObjectOutputStream s) throws IOException
> {
> s.defaultWriteObject();
> IPageStore store = getPageStore();
> if (sessionId != null && store instanceof IClusteredPageStore == false)
> {
> --> if (lastPage == null) log.error("writeObject1 " + sessionId + " "
> + thisNum); <--
> Object page = lastPage;
> if (store instanceof ISerializationAwarePageStore)
> {
> page = (ISerializationAwarePageStore)store).prepareForSerialization(...
> --> if (page == null) log.error("writeObject2 " + sessionId + " " +
> thisNum); <--
> }
> }
> .
> }
>
> Finally, the output looks like:
>
> 2008-11-22 04:43:58,841 PAGE 19ACC6B64E22346D494E742A0E859B52 29
>
>
> other pages in other sessions follows
>
> 2008-11-22 04:44:00,486 put 33932E31AE77206B5E556266170B4827 33
> 2008-11-22 04:44:00,201 put C6423FDD58C4B31C080700E4455F158C
>
>
> and about 120 secs later:
>
> 2008-11-22 04:46:36,432 writeObject1 19ACC6B64E22346D494E742A0E859B52 30
> 2008-11-22 04:46:36,432 writeObject2 19ACC6B64E22346D494E742A0E859B52 30
>
>
> In every case I've seen the instance num for the writeObject1/2 logs
> was one plus the num for the put log in the same session. I think that
> here the second pagemap (30) is created with a default lastPage = null
> that never is assigned a non null page, because put is being called on
> the first pagemap (29) instead.
>
> I still don't know where the second pagemap is created, but I'm getting
> closer.
>
> HIH
> -Carlos
>
> On Thu, Nov 20, 2008 at 3:05 AM, Carlos Pita
> wrote:
> > Hi Matej,
> >
> > I'm browsing your changes. Please notice that according to my own
> > debugging it's lastPage itself that is null and not only the result of
> > prepareForSerialization. So I don't think the warning "PageStore
> > prepared non-null page as null for serialization" will ever be
> > reached. Anyway, I will add other warnings and keep you informed of
> > the output as soon as I can. This is really tricky to debug because up
> > til today I'm only able to reproduce it at full scale in a production
> > environment.
> >
> > Do you have any idea why a lastPage would be null after 120 secs of
> > the request that created the session? Specially for sessions that
> > don't survive that first request. An exception that could avoid
> > request cycle to detach the session maybe?
> >
> > Thanks!
> > -Carlos
> >
> >
> > On Wed, Nov 19, 2008 at 7:18 PM, Matej Knopp
> wrote:
> >> This really is weird. I added couple of warnings and null check to 1.4
> >> trunk. I wonder if that helps it though.
> >>
> >> -Matej
> >>
> >> On Wed, Nov 19, 2008 at 12:44 PM, Carlos Pita
> wrote:
> >>> The last one of the saga for now, I badly need to sleep.
> >>>
> >>> I've been sampling tomcat work dir every second:
> >>>
> >>> i=0; while [[ i -le 300 ]]; do echo $i; ls -lt /u01/tomcatWork/_ >
> >>> /tmp/work$i; sleep 1; i=$((i + 1)); done
> >>>
> >>> Then I greped a number of session ids corresponding to
> >>> restoreAfterSerialization errors and every one of them appears in zero
> >>> or one samples at most. With maxIdle
Language selector component available anywhere?
Hi all, I was just wondering if there's a language selector component (ie, flags, language names in a dropdown, etc) out there that someone's built. A google search didn't yield any results. Thanks, Meetesh
Re: Ajax and isTransparentResolver
Thanks for the information ... I'll change our code.
Meetesh
Igor Vaynberg wrote:
i dont think we can support transparent resolvers as ajax targets
-igor
On Fri, Apr 11, 2008 at 10:00 AM, Meetesh Karia <[EMAIL PROTECTED]> wrote:
Hi all,
We're seeing an issue with ajax and isTransparentResolver set to return
true and I'm wondering if this is something we're doing wrong or if it's an
oversight. Here's an example:
add(new WebMarkupContainer("toUpdate") {
@Override
public boolean isTransparentResolver() {
return true;
}
});
add(new WebMarkupContainer("myChild"));
with html like this:
...
When a user clicks on an ajax link (which is a "child" of toUpdate and
added in the same manner as myChild), toUpdate is added to the target to be
rendered.
Now, because toUpdate doesn't have any real children, it doesn't mark any
of them as rendering in MarkupContainer.internalMarkRendering(). However,
Component.render(MarkupStream) does mark all of the children as rendering
because it calls markRendering() itself. When the rendering is finished,
MarkupContainer.onAfterRenderChildren() is called but only the toUpdate
container has it's rendering flag set to false and the child rendering flags
remain set to true. If there's now another ajax click within that same
container which modifies the visibility of a component, an exception will be
thrown indicating that a hierarchy change can't occur while rendering.
Are we using isTransparentResolver() incorrectly?
Thanks,
Meetesh
Ajax and isTransparentResolver
Hi all,
We're seeing an issue with ajax and isTransparentResolver set to return
true and I'm wondering if this is something we're doing wrong or if it's
an oversight. Here's an example:
add(new WebMarkupContainer("toUpdate") {
@Override
public boolean isTransparentResolver() {
return true;
}
});
add(new WebMarkupContainer("myChild"));
with html like this:
...
When a user clicks on an ajax link (which is a "child" of toUpdate and
added in the same manner as myChild), toUpdate is added to the target to
be rendered.
Now, because toUpdate doesn't have any real children, it doesn't mark
any of them as rendering in MarkupContainer.internalMarkRendering().
However, Component.render(MarkupStream) does mark all of the children as
rendering because it calls markRendering() itself. When the rendering
is finished, MarkupContainer.onAfterRenderChildren() is called but only
the toUpdate container has it's rendering flag set to false and the
child rendering flags remain set to true. If there's now another ajax
click within that same container which modifies the visibility of a
component, an exception will be thrown indicating that a hierarchy
change can't occur while rendering.
Are we using isTransparentResolver() incorrectly?
Thanks,
Meetesh
Re: MarkupCache change in 1.3.2 breaks style/variation/locale markup support
What about adding the style and variation into the location string when
it's used as a cache key. That will prevent the problem with the
locales, but will address the issue below too ...
Johan Compagner wrote:
hmm this is now a tricky one..
i need to figure out how it should work now..
On Wed, Apr 9, 2008 at 8:04 PM, Meetesh Karia <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
We're running into a problem with the change made for this issue:
http://issues.apache.org/jira/browse/WICKET-1370
Basically, if you have a situation like this where the Login page
extends DefaultPage and uses :
Login.html
DefaultPage.html
DefaultPage_style1.html
DefaultPage_style2.html
The markup for DefaultPage will always be based on the first style
the site is hit with. This is because the location string
("Login.html") hasn't changed with the style change.
Can anyone think of a simple way to work around this or a simple
patch we can apply for now?
I've entered this issue for this as well:
https://issues.apache.org/jira/browse/WICKET-1507
Thanks,
Meetesh
MarkupCache change in 1.3.2 breaks style/variation/locale markup support
We're running into a problem with the change made for this issue:
http://issues.apache.org/jira/browse/WICKET-1370
Basically, if you have a situation like this where the Login page
extends DefaultPage and uses :
Login.html
DefaultPage.html
DefaultPage_style1.html
DefaultPage_style2.html
The markup for DefaultPage will always be based on the first style the
site is hit with. This is because the location string ("Login.html")
hasn't changed with the style change.
Can anyone think of a simple way to work around this or a simple patch
we can apply for now?
I've entered this issue for this as well:
https://issues.apache.org/jira/browse/WICKET-1507
Thanks,
Meetesh
Re: Bug in wicket-ajax.js introduced in Wicket 1.3.2?
Unfortunately that patch doesn't solve the problem. I've added a comment to the issue with a different patch which addresses our problem and the problem mentioned in the issue (I hope :) ). Thanks, Meetesh Thijs wrote: See https://issues.apache.org/jira/browse/WICKET-1426 Meetesh Karia schreef: Hi all, We recently upgraded to Wicket 1.3.2 from Wicket 1.3.1 and we're seeing a bug with ajax behavior in Firefox (2.0.0.13 on Windows Vista). Basically, the following header is returned from an ajax call: encoding="UTF-8"?>encoding="wicket1" > The page this is called from has a URL that looks like this http://host/2008/foo/bar In Wicket 1.3.1, the script /templates/mediaplayer/swfobject.js gets correctly loaded from http://host/templates/mediaplayer/swfobject.js However, in Wicket 1.3.2, it is incorrectly loaded from http://host/2008/foo//templates/mediaplayer/swfobject.js This appears to be related to one of these two changes: http://fisheye6.cenqua.com/browse/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?r1=614229&r2=619539 http://fisheye6.cenqua.com/browse/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?r1=627225&r2=628015 I haven't narrowed it down but replacing wicket-ajax.js with the version from 1.3.1 makes it work again. Should I file a bug for this? Or is this going to be the new behavior going forward for Firefox? Also, I'm guessing that the safest way to work around this problem is to remove those two changes and temporarily use a local build of wicket, right? Thanks, Meetesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug in wicket-ajax.js introduced in Wicket 1.3.2?
Hi all, We recently upgraded to Wicket 1.3.2 from Wicket 1.3.1 and we're seeing a bug with ajax behavior in Firefox (2.0.0.13 on Windows Vista). Basically, the following header is returned from an ajax call: The page this is called from has a URL that looks like this http://host/2008/foo/bar In Wicket 1.3.1, the script /templates/mediaplayer/swfobject.js gets correctly loaded from http://host/templates/mediaplayer/swfobject.js However, in Wicket 1.3.2, it is incorrectly loaded from http://host/2008/foo//templates/mediaplayer/swfobject.js This appears to be related to one of these two changes: http://fisheye6.cenqua.com/browse/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?r1=614229&r2=619539 http://fisheye6.cenqua.com/browse/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?r1=627225&r2=628015 I haven't narrowed it down but replacing wicket-ajax.js with the version from 1.3.1 makes it work again. Should I file a bug for this? Or is this going to be the new behavior going forward for Firefox? Also, I'm guessing that the safest way to work around this problem is to remove those two changes and temporarily use a local build of wicket, right? Thanks, Meetesh
Re: Sporadic exponential explosion of session size
Will do and I will respond with any other information we find as we're looking into this as well. Meetesh Igor Vaynberg wrote: please file a bug report so this doesnt fall through the cracks. reference this email thread in this issue report through nabble or whatever... -igor On Fri, Feb 29, 2008 at 8:59 AM, Meetesh Karia <[EMAIL PROTECTED]> wrote: There's nothing obvious and we don't hold references between pages intentionally. Additionally, when we use the site normally (ie, without opening new tabs), we don't run into this problem (and I would expect us to if we were holding references to Pages). Is it possible that the automatic multi-window javascript is executing before the response is completely written (don't know if wicket flushes the response buffer in parts for large pages) which causes the redirect to happen before the response completes? Perhaps that keeps a threadlocal variable from being cleaned up somewhere? I'm just speculating here ... Meetesh Matej Knopp wrote: > Wicket shouldn't implicitely hold any page references. Are you sure > you don't have references between your pages? > > -Matej > > On Fri, Feb 29, 2008 at 3:29 PM, Meetesh Karia <[EMAIL PROTECTED]> wrote: > >> Hi all, >> >> We're running into a problem that we've seen happen many times though >> unfortunately we can't consistently reproduce it. We're using Wicket >> 1.3.1 with automatic multi-window support enabled and the default >> SecondLevelCacheSessionStore. >> >> During normal use of our site, no Pages reference other Pages and the >> session size changes as it should. However, occasionally when we open >> pages in a new tab (often when multiple pages are opened in a new tab in >> rapid succession), we get the following situation: >> >> 1 tab >> >> pagemap-null size = x >> >> 2 tabs >> >> pagemap-null size = 2x >> pagemap-0 size = x >> >> 3 tabs >> >> pagemap-null size = 4x >> pagemap-0 size = 2x >> pagemap-1 size = x >> >> 4 tabs >> >> pagemap-null size = 8x >> pagemap-0 size = 4x >> pagemap-1 size = 2x >> pagemap-2 size = x >> >> >> The only explanation that I could come up with for this explosion is >> that somehow, behind the scenes, a Page is holding onto a reference to >> another Page in this situation. Because 8x is beyond our max pagemap >> size, it means that there can only be 1-2 Pages in it taking up this space. >> >> Has anyone come across a problem like this? Any thoughts on what this >> could be? >> >> Thanks, >> Meetesh >> >> > > > >
Re: Sporadic exponential explosion of session size
There's nothing obvious and we don't hold references between pages intentionally. Additionally, when we use the site normally (ie, without opening new tabs), we don't run into this problem (and I would expect us to if we were holding references to Pages). Is it possible that the automatic multi-window javascript is executing before the response is completely written (don't know if wicket flushes the response buffer in parts for large pages) which causes the redirect to happen before the response completes? Perhaps that keeps a threadlocal variable from being cleaned up somewhere? I'm just speculating here ... Meetesh Matej Knopp wrote: Wicket shouldn't implicitely hold any page references. Are you sure you don't have references between your pages? -Matej On Fri, Feb 29, 2008 at 3:29 PM, Meetesh Karia <[EMAIL PROTECTED]> wrote: Hi all, We're running into a problem that we've seen happen many times though unfortunately we can't consistently reproduce it. We're using Wicket 1.3.1 with automatic multi-window support enabled and the default SecondLevelCacheSessionStore. During normal use of our site, no Pages reference other Pages and the session size changes as it should. However, occasionally when we open pages in a new tab (often when multiple pages are opened in a new tab in rapid succession), we get the following situation: 1 tab pagemap-null size = x 2 tabs pagemap-null size = 2x pagemap-0 size = x 3 tabs pagemap-null size = 4x pagemap-0 size = 2x pagemap-1 size = x 4 tabs pagemap-null size = 8x pagemap-0 size = 4x pagemap-1 size = 2x pagemap-2 size = x The only explanation that I could come up with for this explosion is that somehow, behind the scenes, a Page is holding onto a reference to another Page in this situation. Because 8x is beyond our max pagemap size, it means that there can only be 1-2 Pages in it taking up this space. Has anyone come across a problem like this? Any thoughts on what this could be? Thanks, Meetesh
Sporadic exponential explosion of session size
Hi all, We're running into a problem that we've seen happen many times though unfortunately we can't consistently reproduce it. We're using Wicket 1.3.1 with automatic multi-window support enabled and the default SecondLevelCacheSessionStore. During normal use of our site, no Pages reference other Pages and the session size changes as it should. However, occasionally when we open pages in a new tab (often when multiple pages are opened in a new tab in rapid succession), we get the following situation: 1 tab pagemap-null size = x 2 tabs pagemap-null size = 2x pagemap-0 size = x 3 tabs pagemap-null size = 4x pagemap-0 size = 2x pagemap-1 size = x 4 tabs pagemap-null size = 8x pagemap-0 size = 4x pagemap-1 size = 2x pagemap-2 size = x The only explanation that I could come up with for this explosion is that somehow, behind the scenes, a Page is holding onto a reference to another Page in this situation. Because 8x is beyond our max pagemap size, it means that there can only be 1-2 Pages in it taking up this space. Has anyone come across a problem like this? Any thoughts on what this could be? Thanks, Meetesh
Re: OutOfMemoryError (not PermGen) in PageSavingThread
Thanks Henrik, We don't store Page references (we use getPage()) except in one case but that's a reference to the current page. I did come across this information about a JVM bug: http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=414ae2ad0e65bfabc12f25012527?bug_id=4879883 It looks like there's a property we can try but that it's not necessarily and ideal (or even acceptable?) solution? Sun devs say this was fixed in 1.4 but people have been complaining about it in 1.5 and 1.6. Some more information on this: http://osdir.com/ml/java.bdbje.general/2005-05/msg00027.html So, we'll give it a shot and report back to the list (in case others come across this problem). Though ... it does concern me some that we would have used up 64mb of direct memory writing out pages. It appears as though the memory is deallocated using a separate thread (in java.nio.DirectByteBuffer) so it's possible that wicket is writing out pages and using up the direct memory before it can be cleaned up. Meetesh Henrik Lundahl wrote: Hi One thing you can check is if you have any references (instance variables, possibly implicit) to pages from your component hierarchy. That seems to cause memory leaks in the serialization. I reported a Jira issue about this yesterday (https://issues.apache.org/jira/browse/WICKET-1365). Another thing could of course be that there isn't enough memory to store all the concurrent sessions. If you still run out of memory after increasing the limit with the same load, this shouldn't be it, though. BR, Henrik 2008/2/22, Meetesh Karia <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: Hi all, We're getting an OutOfMemoryError (Wicket 1.3.1 on Tomcat 5.5.17 with Sun JVM 1.5.0_06-b05) in the PageSavingThread occasionally and I was just wondering if anyone had seen this before. Is it likely just a side-effect of some other problem in our application? Or is this an issue with how the pages are written out in wicket. Exception in thread "PageSavingThread-wicketFilter" java.lang.OutOfMemoryError at sun.misc.Unsafe.allocateMemory(Native Method) at java.nio.DirectByteBuffer.(DirectByteBuffer.java:99) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288) at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:56) at sun.nio.ch.IOUtil.write(IOUtil.java:69) at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:651) at org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage(DiskPageStore.java:246) at org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList(DiskPageStore.java:885) at org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run(DiskPageStore.java:948) Thanks in advance, Meetesh
OutOfMemoryError (not PermGen) in PageSavingThread
Hi all, We're getting an OutOfMemoryError (Wicket 1.3.1 on Tomcat 5.5.17 with Sun JVM 1.5.0_06-b05) in the PageSavingThread occasionally and I was just wondering if anyone had seen this before. Is it likely just a side-effect of some other problem in our application? Or is this an issue with how the pages are written out in wicket. Exception in thread "PageSavingThread-wicketFilter" java.lang.OutOfMemoryError at sun.misc.Unsafe.allocateMemory(Native Method) at java.nio.DirectByteBuffer.(DirectByteBuffer.java:99) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288) at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:56) at sun.nio.ch.IOUtil.write(IOUtil.java:69) at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:651) at org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage(DiskPageStore.java:246) at org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList(DiskPageStore.java:885) at org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run(DiskPageStore.java:948) Thanks in advance, Meetesh
Localizer backwards incompatibility bug in 1.3?
Hi all, In Wicket 1.2.6, we created some properties files like: Foo.properties Foo_style1.properties Foo_style2.properties and used StringResourceModel to look up property values. This worked correctly as in 1.2.6, Localizer didn't cache the property lookups and respected the style. However, in 1.3, Localizer now caches the lookups but doesn't respect the style when creating the cache key (though it does append the locale to the end of the cache key). Is this a bug? Or is this now the expected behavior? If it's the latter, is the approach we used above no longer supported? The side-effects of this are that whatever style is in use when a property is first looked up, that property value will be returned for all subsequent lookups regardless of style. Thanks, Meetesh
Re: n^2 loop in MarkupContainer?
I wanted to follow up on this now that I had a chance to put a profiler to this. It turns out that the problem was actually coming from calls to TextTemplateHeaderContributor.forJavaScript which has TODOs for the implementation of caching. I worked around the problem by creating the PackagedTextTemplate once and reusing it. Thanks and sorry for the thread of emails, Meetesh Timo Rantalaiho wrote: Hello all, Such optimisation should be preceeded by getting hard profiling data, right? We have some repeaters that get hundreds of Items and the part of adding child components has not shown up as a bottleneck when profiling. It has made us think, though, whether it makes sense to output hundreds of rows of data on the screen anyway :) Best wishes, Timo
Re: n^2 loop in MarkupContainer?
It appeared to be that way after stepping through the code many times in a debugger but that's definitely not conclusive evidence. I'll try and come up with a better measure of what's going on. Thanks, Meetesh Matej Knopp wrote: Indeed, the reason for it is to reduce memory consumption. Right now, I don't see any easy way around, are you absolutely sure that it causes you performance problems? -Matej On Feb 11, 2008 2:15 PM, Meetesh Karia <[EMAIL PROTECTED]> wrote: Hi all, I'm using DataView in wicket 1.3 and we have ~400 items that are returned by a data provider. I'd expect the adding of the items to be rather quick but it turns out that it's not and it looks like the culprit might be MarkupContainer.put. That method expands the children array 1 entry at a time which makes the loop of adding the items n^2. Is there a good reason for this loop to be n^2 (memory conservation perhaps)? Is there any easy way around it? Thanks, Meetesh
n^2 loop in MarkupContainer?
Hi all, I'm using DataView in wicket 1.3 and we have ~400 items that are returned by a data provider. I'd expect the adding of the items to be rather quick but it turns out that it's not and it looks like the culprit might be MarkupContainer.put. That method expands the children array 1 entry at a time which makes the loop of adding the items n^2. Is there a good reason for this loop to be n^2 (memory conservation perhaps)? Is there any easy way around it? Thanks, Meetesh
Redirecting to bookmarkable url after change in DropDownChoice
Hi all, I'm looking for the best way (within wicket) to end up at a bookmarkable url after a change in a DropDownChoice. For example: 1. I'm at the url '/category/foo' 2. I change the category DropDownChoice to 'bar' 3. I want the user (without a manual submit) to end up at '/category/bar' I looked through the mailing list and examples but I couldn't find a good example (or I missed it). Should I use onSelectionChanged and then redirect from within that handler? Will wicket handle that correctly? Thanks, Meetesh
Problems with new tab/window support and RestartResponseAtInterceptPageException
Hi all, I haven't heard back on an older email post or this bug I entered: https://issues.apache.org/jira/browse/WICKET-1255 I'm just wondering if this is a real bug or if it's something that I'm doing wrong. If it's a bug with 1.2.6, has this been fixed in 1.3? Thanks, Meetesh
Intercept pages and support for pages opened in new windows/tabs
Happy New Year all. I'm running into a problem with the use of intercept pages together with wicket 1.2.x's support for opening pages in new tabs/windows. Basically, if someone has a tab open to our site and then opens a link in another tab which causes the user to be redirected to an intercept page, it will redirect one extra time to create a new page map (that redirect happening through javascript). Unfortunately, this causes wicket to lose track of the original destination of the intercept, thus the intercept no longer works. Has anyone run into this? Any solutions? A bug perhaps? Or just a nuance? Thanks in advance, Meetesh
