Re: [Wicket-user] page map size
Depends on your page, number of components, deployment mode, wicket version, how you bind the models to your components. Do you use the second level cache for storing your pages for back button support? Martijn On 6/8/07, Scott Swank [EMAIL PROTECTED] wrote: Are these typical sizes for page maps? wicket:/app:p:null:267,668 bytes wicket:/app:p:null:155,861 bytes wicket:/app:p:null:052,817 bytes -- Scott Swank reformed mathematician - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] page map size
Scott - what is the trick for getting a report of sizes of page maps like this? I was so far only aware that setting log level DEBUG on say org.apache.wicket.protocol.http.FilePageStore can give you some of this info... Thanks, Peter. On 6/8/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Depends on your page, number of components, deployment mode, wicket version, how you bind the models to your components. Do you use the second level cache for storing your pages for back button support? Martijn On 6/8/07, Scott Swank [EMAIL PROTECTED] wrote: Are these typical sizes for page maps? wicket:/app:p:null:267,668 bytes wicket:/app:p:null:155,861 bytes wicket:/app:p:null:052,817 bytes -- Scott Swank reformed mathematician - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] page map size
It's a JSP one of our developers put together. Here's the relevant bit.
for (Enumeration e = session.getAttributeNames(); e.hasMoreElements();)
{
String key = (String)e.nextElement();
Object obj = session.getAttribute(key);
String outputStr = null;
try
{
ByteArrayOutputStream byteOutput = new
ByteArrayOutputStream();
ObjectOutputStream output = new
ObjectOutputStream(byteOutput);
output.writeObject(obj);
int size = byteOutput.size();
totalSize += size;
outputStr = format.format(size) + bytes;
}
catch (NotSerializableException ex)
{
StringWriter sb = new StringWriter();
sb.write(PRE);
ex.printStackTrace(new PrintWriter(sb));
sb.write(/PRE);
outputStr = sb.toString();
}
}
On 6/8/07, Peter Thomas [EMAIL PROTECTED] wrote:
Scott - what is the trick for getting a report of sizes of page maps like
this? I was so far only aware that setting log level DEBUG on say
org.apache.wicket.protocol.http.FilePageStore can give you
some of this info...
Thanks,
Peter.
On 6/8/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Depends on your page, number of components, deployment mode, wicket
version, how you bind the models to your components.
Do you use the second level cache for storing your pages for back
button support?
Martijn
On 6/8/07, Scott Swank [EMAIL PROTECTED] wrote:
Are these typical sizes for page maps?
wicket:/app:p:null:267,668 bytes
wicket:/app:p:null:155,861 bytes
wicket:/app:p:null:052,817 bytes
--
Scott Swank
reformed mathematician
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Scott Swank
reformed mathematician
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] page map size
Martjin, We're using 1.2.6. Is the 2nd level cache available prior to 1.3? As for page complexity, we commonly have a reasonably robust repeater or list view on each page (though without too many rows) along with a form or two. I'm concerned about models because as I do work on a given page I see the older page maps change in size. I.e. I have p0=30K, p1=33K -- then I do something substantial on p2 and see the size of p0 p1 each increase by 11K. Thank you, Scott On 6/8/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Depends on your page, number of components, deployment mode, wicket version, how you bind the models to your components. Do you use the second level cache for storing your pages for back button support? Martijn On 6/8/07, Scott Swank [EMAIL PROTECTED] wrote: Are these typical sizes for page maps? wicket:/app:p:null:267,668 bytes wicket:/app:p:null:155,861 bytes wicket:/app:p:null:052,817 bytes -- Scott Swank reformed mathematician - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Scott Swank reformed mathematician - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] page map size
do you share something between those pages? On 6/8/07, Scott Swank [EMAIL PROTECTED] wrote: Martjin, We're using 1.2.6. Is the 2nd level cache available prior to 1.3? As for page complexity, we commonly have a reasonably robust repeater or list view on each page (though without too many rows) along with a form or two. I'm concerned about models because as I do work on a given page I see the older page maps change in size. I.e. I have p0=30K, p1=33K -- then I do something substantial on p2 and see the size of p0 p1 each increase by 11K. Thank you, Scott On 6/8/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Depends on your page, number of components, deployment mode, wicket version, how you bind the models to your components. Do you use the second level cache for storing your pages for back button support? Martijn On 6/8/07, Scott Swank [EMAIL PROTECTED] wrote: Are these typical sizes for page maps? wicket:/app:p:null:267,668 bytes wicket:/app:p:null:155,861 bytes wicket:/app:p:null:052,817 bytes -- Scott Swank reformed mathematician - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Scott Swank reformed mathematician - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] page map size
I don't think that is true for page *versions*, which is also used
when you use component replacement, ajax or not.
A quick look reveals that Settings#maxPageVersions is still max int,
and in 1.2, Page has
protected IPageVersionManager newVersionManager()
{
final IPageSettings settings =
getSession().getApplication().getPageSettings();
return new UndoPageVersionManager(this,
settings.getMaxPageVersions());
}
Then, UndoPageVersionManager has
// If stack is overfull, remove oldest entry
if (getVersions() maxVersions)
{
expireOldestVersion();
}
in method endVersion. So unless I miss something in the larger
picture, it looks to me that whenever you do component replacement on
a page, it just keeps building up versions until max int is reached.
And this is exactly what I've been objecting to in the past, and I
still think max int is a crazy (dangerous) default. But please do
enlighten me if I'm wrong. And maybe this time we can either clear
this up or fix it for once and for all.
Eelco
On 6/8/07, Johan Compagner [EMAIL PROTECTED] wrote:
that growing of a page constantly is only a problem when you use one page
and through ajax request you constantly change that single page.
if not then the page versions will be removed because there can only be 7
(pages + page versions) by default
johan
On 6/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
We're using 1.2.6. Is the 2nd level cache available prior to 1.3?
It's only in 1.3 I'm afraid.
As for page complexity, we commonly have a reasonably robust repeater
or list view on each page (though without too many rows) along with a
form or two.
I'm concerned about models because as I do work on a given page I see
the older page maps change in size. I.e. I have p0=30K, p1=33K --
then I do something substantial on p2 and see the size of p0 p1 each
increase by 11K.
One known issue with the old sessionstore is that deltas of a page are
stored in the page itself. This will result in the page keep on
growing. We've had lots of discussion about this, which resulted in
the default session store implementation of 1.3 now storing the whole
page for each version to second level cache (temp dir) instead.
I'm not sure how to fix this for 1.2 tbh. To limit how far those
versions can grow, you can set maxVersions in UndoPageVersionManager,
which in 1.2 is a setting somewhere (sorry don't know from the top of
my head).
Eelco
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] page map size
Our pages are in fact rather Ajax-heavy. We have following settings in our app.init() method. getSessionSettings().setPageMapEvictionStrategy(new LeastRecentlyAccessedEvictionStrategy(1)); getPageSettings().setMaxPageVersions(1); getPageSettings().setVersionPagesByDefault(false); Though I increased the LRU eviction value to a 4 to obtain the numbers I initially posted. -- Scott Swank reformed mathematician - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] page map size
If you still have a growing pagemap with these settings, it looks like there's a memory leak somewhere. Did you guys try to profile? Eelco On 6/8/07, Scott Swank [EMAIL PROTECTED] wrote: Our pages are in fact rather Ajax-heavy. We have following settings in our app.init() method. getSessionSettings().setPageMapEvictionStrategy(new LeastRecentlyAccessedEvictionStrategy(1)); getPageSettings().setMaxPageVersions(1); getPageSettings().setVersionPagesByDefault(false); Though I increased the LRU eviction value to a 4 to obtain the numbers I initially posted. -- Scott Swank reformed mathematician - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] page map size
I suspect that we have model problems somewhere. And yes, we're scheduled to walk through it with JProfiler this afternoon. Thanks again, Scott On 6/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote: If you still have a growing pagemap with these settings, it looks like there's a memory leak somewhere. Did you guys try to profile? Eelco - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] page map size
no it is true for page versions
there will be a Access object created for every page version
that will be pushed on the access stack (in the pagemap)
that access object has 2 variables: pageid and versionnumber
that makes it unique
and you are looking at the wrong thing that Settings.maxPageVersions doesn't
do much
its the:
public LeastRecentlyAccessedEvictionStrategy(int maxVersions)
(IPageMapEvictionStrategy)
that one evicts such a access objects from the pagemap.
and if it events an Access object with pageid 7 and version 2
it will delete that version from the changelist of the versionmanger for
that page
and if that is the last one the complete page is removed. If not then there
is just one version less for that page.
So no in wicket 1.2 we don't build up a page over and over again. There is
really only 5 or 7 (i see 5 is now the default)
page/pageversions alive at one time (5 access objects)
the problem was if i remember correctly pure ajax pages. (and i don't see at
the moment how that did go wrong in 1.2)
johan
On 6/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I don't think that is true for page *versions*, which is also used
when you use component replacement, ajax or not.
A quick look reveals that Settings#maxPageVersions is still max int,
and in 1.2, Page has
protected IPageVersionManager newVersionManager()
{
final IPageSettings settings =
getSession().getApplication().getPageSettings();
return new UndoPageVersionManager(this,
settings.getMaxPageVersions());
}
Then, UndoPageVersionManager has
// If stack is overfull, remove oldest entry
if (getVersions() maxVersions)
{
expireOldestVersion();
}
in method endVersion. So unless I miss something in the larger
picture, it looks to me that whenever you do component replacement on
a page, it just keeps building up versions until max int is reached.
And this is exactly what I've been objecting to in the past, and I
still think max int is a crazy (dangerous) default. But please do
enlighten me if I'm wrong. And maybe this time we can either clear
this up or fix it for once and for all.
Eelco
On 6/8/07, Johan Compagner [EMAIL PROTECTED] wrote:
that growing of a page constantly is only a problem when you use one
page
and through ajax request you constantly change that single page.
if not then the page versions will be removed because there can only be
7
(pages + page versions) by default
johan
On 6/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
We're using 1.2.6. Is the 2nd level cache available prior to 1.3?
It's only in 1.3 I'm afraid.
As for page complexity, we commonly have a reasonably robust
repeater
or list view on each page (though without too many rows) along with
a
form or two.
I'm concerned about models because as I do work on a given page I
see
the older page maps change in size. I.e. I have p0=30K, p1=33K --
then I do something substantial on p2 and see the size of p0 p1
each
increase by 11K.
One known issue with the old sessionstore is that deltas of a page are
stored in the page itself. This will result in the page keep on
growing. We've had lots of discussion about this, which resulted in
the default session store implementation of 1.3 now storing the whole
page for each version to second level cache (temp dir) instead.
I'm not sure how to fix this for 1.2 tbh. To limit how far those
versions can grow, you can set maxVersions in UndoPageVersionManager,
which in 1.2 is a setting somewhere (sorry don't know from the top of
my head).
Eelco
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user
Re: [Wicket-user] page map size
Ok, I'll take a look at whether I can follow this this weekend. That
must be the worst code ever though, if it's so unobvious. And why do
we still have that maxPageVersions application parameter, and the
maxversions member in the pageversion member? The whole way this works
sounds like one big fat hack to me; it probably is to get around the
initial limitations without breaking the API, is that correct?
Eelco
On 6/8/07, Johan Compagner [EMAIL PROTECTED] wrote:
no it is true for page versions
there will be a Access object created for every page version
that will be pushed on the access stack (in the pagemap)
that access object has 2 variables: pageid and versionnumber
that makes it unique
and you are looking at the wrong thing that Settings.maxPageVersions doesn't
do much
its the:
public LeastRecentlyAccessedEvictionStrategy(int
maxVersions) (IPageMapEvictionStrategy)
that one evicts such a access objects from the pagemap.
and if it events an Access object with pageid 7 and version 2
it will delete that version from the changelist of the versionmanger for
that page
and if that is the last one the complete page is removed. If not then there
is just one version less for that page.
So no in wicket 1.2 we don't build up a page over and over again. There is
really only 5 or 7 (i see 5 is now the default)
page/pageversions alive at one time (5 access objects)
the problem was if i remember correctly pure ajax pages. (and i don't see at
the moment how that did go wrong in 1.2)
johan
On 6/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I don't think that is true for page *versions*, which is also used
when you use component replacement, ajax or not.
A quick look reveals that Settings#maxPageVersions is still max int,
and in 1.2, Page has
protected IPageVersionManager newVersionManager()
{
final IPageSettings settings =
getSession().getApplication().getPageSettings();
return new UndoPageVersionManager(this,
settings.getMaxPageVersions());
}
Then, UndoPageVersionManager has
// If stack is overfull, remove oldest entry
if (getVersions() maxVersions)
{
expireOldestVersion();
}
in method endVersion. So unless I miss something in the larger
picture, it looks to me that whenever you do component replacement on
a page, it just keeps building up versions until max int is reached.
And this is exactly what I've been objecting to in the past, and I
still think max int is a crazy (dangerous) default. But please do
enlighten me if I'm wrong. And maybe this time we can either clear
this up or fix it for once and for all.
Eelco
On 6/8/07, Johan Compagner [EMAIL PROTECTED] wrote:
that growing of a page constantly is only a problem when you use one
page
and through ajax request you constantly change that single page.
if not then the page versions will be removed because there can only be
7
(pages + page versions) by default
johan
On 6/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
We're using 1.2.6. Is the 2nd level cache available prior to 1.3?
It's only in 1.3 I'm afraid.
As for page complexity, we commonly have a reasonably robust
repeater
or list view on each page (though without too many rows) along with
a
form or two.
I'm concerned about models because as I do work on a given page I
see
the older page maps change in size. I.e. I have p0=30K, p1=33K --
then I do something substantial on p2 and see the size of p0 p1
each
increase by 11K.
One known issue with the old sessionstore is that deltas of a page are
stored in the page itself. This will result in the page keep on
growing. We've had lots of discussion about this, which resulted in
the default session store implementation of 1.3 now storing the whole
page for each version to second level cache (temp dir) instead.
I'm not sure how to fix this for 1.2 tbh. To limit how far those
versions can grow, you can set maxVersions in UndoPageVersionManager,
which in 1.2 is a setting somewhere (sorry don't know from the top of
my head).
Eelco
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C -
Re: [Wicket-user] page map size
that max page versions thing can be removed
in the access stack it doesn't make any sense. because you don't control one
page because
setting that to 5 still means that there can be 5 pages with each 5 versions
is a back button support of 25
what you want is control that last (25) value. So you want to control the
max number of back buttons over
all the pages, that is what the pagemap evict strategy does.
johan
On 6/9/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Ok, I'll take a look at whether I can follow this this weekend. That
must be the worst code ever though, if it's so unobvious. And why do
we still have that maxPageVersions application parameter, and the
maxversions member in the pageversion member? The whole way this works
sounds like one big fat hack to me; it probably is to get around the
initial limitations without breaking the API, is that correct?
Eelco
On 6/8/07, Johan Compagner [EMAIL PROTECTED] wrote:
no it is true for page versions
there will be a Access object created for every page version
that will be pushed on the access stack (in the pagemap)
that access object has 2 variables: pageid and versionnumber
that makes it unique
and you are looking at the wrong thing that Settings.maxPageVersionsdoesn't
do much
its the:
public LeastRecentlyAccessedEvictionStrategy(int
maxVersions) (IPageMapEvictionStrategy)
that one evicts such a access objects from the pagemap.
and if it events an Access object with pageid 7 and version 2
it will delete that version from the changelist of the versionmanger for
that page
and if that is the last one the complete page is removed. If not then
there
is just one version less for that page.
So no in wicket 1.2 we don't build up a page over and over again. There
is
really only 5 or 7 (i see 5 is now the default)
page/pageversions alive at one time (5 access objects)
the problem was if i remember correctly pure ajax pages. (and i don't
see at
the moment how that did go wrong in 1.2)
johan
On 6/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I don't think that is true for page *versions*, which is also used
when you use component replacement, ajax or not.
A quick look reveals that Settings#maxPageVersions is still max int,
and in 1.2, Page has
protected IPageVersionManager newVersionManager()
{
final IPageSettings settings =
getSession().getApplication().getPageSettings();
return new UndoPageVersionManager(this,
settings.getMaxPageVersions());
}
Then, UndoPageVersionManager has
// If stack is overfull, remove oldest entry
if (getVersions() maxVersions)
{
expireOldestVersion();
}
in method endVersion. So unless I miss something in the larger
picture, it looks to me that whenever you do component replacement on
a page, it just keeps building up versions until max int is reached.
And this is exactly what I've been objecting to in the past, and I
still think max int is a crazy (dangerous) default. But please do
enlighten me if I'm wrong. And maybe this time we can either clear
this up or fix it for once and for all.
Eelco
On 6/8/07, Johan Compagner [EMAIL PROTECTED] wrote:
that growing of a page constantly is only a problem when you use one
page
and through ajax request you constantly change that single page.
if not then the page versions will be removed because there can only
be
7
(pages + page versions) by default
johan
On 6/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
We're using 1.2.6. Is the 2nd level cache available prior to
1.3?
It's only in 1.3 I'm afraid.
As for page complexity, we commonly have a reasonably robust
repeater
or list view on each page (though without too many rows) along
with
a
form or two.
I'm concerned about models because as I do work on a given page
I
see
the older page maps change in size. I.e. I have p0=30K, p1=33K
--
then I do something substantial on p2 and see the size of p0
p1
each
increase by 11K.
One known issue with the old sessionstore is that deltas of a page
are
stored in the page itself. This will result in the page keep on
growing. We've had lots of discussion about this, which resulted
in
the default session store implementation of 1.3 now storing the
whole
page for each version to second level cache (temp dir) instead.
I'm not sure how to fix this for 1.2 tbh. To limit how far those
versions can grow, you can set maxVersions in
UndoPageVersionManager,
which in 1.2 is a setting somewhere (sorry don't know from the top
of
my head).
Eelco
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of
