24 Feb
2010
24 Feb
'10
12:36 a.m.
Hello devs,
When we are using XWiki for public web sites, most of the time we want
to hide some elements in the UI for guest users (and sometimes for
authenticated users as well).
Currently, it's not elegant to do so : either we have to create a custom
skin, override a couple of templates (with all the merging nightmare it
bringd when upgrading the wiki) - either we create a SSX to "hide"
visually elements.
None of those solutions are really satisfactory. The first one is
painful, the second one is only a workaround and can be a pain too
(there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I
propose to make couple of light changes to some templates to make our
life easier :
1) Add 4 variables in layoutvars.vm :
* $displayContentMenu // display or not the content menu (view, edit
links, etc.) true by default
* $displayMainMenu // display or not the main menu (wiki and space
links, user profile) true by default
* $displayDocExtra // display or not the tabs with doc extra links
(comments, attachments, etc.) true by default
* $displayShortcuts // display or not the document shortcuts (those are
in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by
setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This
will allow to override values from xwikivars/layoutvars without the need
to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from
xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with
this during 2.3
Thanks,
Jerome.
24 Feb
24 Feb
2:36 a.m.
New subject: [xwiki-devs] [Proposal] Making it easier to customize XWiki for public web sites
On 02/24/2010 12:36 AM, Jerome Velociter wrote:
Hello devs,
When we are using XWiki for public web sites, most of the time we want
to hide some elements in the UI for guest users (and sometimes for
authenticated users as well).
Currently, it's not elegant to do so : either we have to create a custom
skin, override a couple of templates (with all the merging nightmare it
bringd when upgrading the wiki) - either we create a SSX to "hide"
visually elements.
None of those solutions are really satisfactory. The first one is
painful, the second one is only a workaround and can be a pain too
(there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I
propose to make couple of light changes to some templates to make our
life easier :
1) Add 4 variables in layoutvars.vm :
* $displayContentMenu // display or not the content menu (view, edit
links, etc.) true by default
* $displayMainMenu // display or not the main menu (wiki and space
links, user profile) true by default
* $displayDocExtra // display or not the tabs with doc extra links
(comments, attachments, etc.) true by default
* $displayShortcuts // display or not the document shortcuts (those are
in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by
setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This
will allow to override values from xwikivars/layoutvars without the need
to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from
xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with
this during 2.3
+1 for all.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
8:02 a.m.
New subject: [xwiki-devs] [Proposal] Making it easier to customize XWiki for public web sites
+1
Thanks,
Marius
Jerome Velociter wrote:
Hello devs,
When we are using XWiki for public web sites, most of the time we want
to hide some elements in the UI for guest users (and sometimes for
authenticated users as well).
Currently, it's not elegant to do so : either we have to create a custom
skin, override a couple of templates (with all the merging nightmare it
bringd when upgrading the wiki) - either we create a SSX to "hide"
visually elements.
None of those solutions are really satisfactory. The first one is
painful, the second one is only a workaround and can be a pain too
(there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I
propose to make couple of light changes to some templates to make our
life easier :
1) Add 4 variables in layoutvars.vm :
* $displayContentMenu // display or not the content menu (view, edit
links, etc.) true by default
* $displayMainMenu // display or not the main menu (wiki and space
links, user profile) true by default
* $displayDocExtra // display or not the tabs with doc extra links
(comments, attachments, etc.) true by default
* $displayShortcuts // display or not the document shortcuts (those are
in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by
setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This
will allow to override values from xwikivars/layoutvars without the need
to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from
xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with
this during 2.3
Thanks,
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:35 a.m.
On Feb 24, 2010, at 12:36 AM, Jerome Velociter wrote:
Hello devs,
When we are using XWiki for public web sites, most of the time we want
to hide some elements in the UI for guest users (and sometimes for
authenticated users as well).
Currently, it's not elegant to do so : either we have to create a custom
skin, override a couple of templates (with all the merging nightmare it
bringd when upgrading the wiki) - either we create a SSX to "hide"
visually elements.
None of those solutions are really satisfactory. The first one is
painful, the second one is only a workaround and can be a pain too
(there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I
propose to make couple of light changes to some templates to make our
life easier :
1) Add 4 variables in layoutvars.vm :
* $displayContentMenu // display or not the content menu (view, edit
links, etc.) true by default
* $displayMainMenu // display or not the main menu (wiki and space
links, user profile) true by default
Is this notion not specific to colibri only? Do we want to make it a generic feature for
all skins or do we want to add an empty skinlayoutvars.vm in templates/ that are there so
that skins fill it with skin-specific vars?
* $displayDocExtra // display or not the tabs with doc
extra links
(comments, attachments, etc.) true by default
Don't we already have a variable for hiding the doc extra tabs? We need to make sure
we use the same one.
* $displayShortcuts // display or not the document
shortcuts (those are
in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by
setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This
will allow to override values from xwikivars/layoutvars without the need
to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from
xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with
this during 2.3
+1
Thanks
-Vincent
11:11 a.m.
New subject: [xwiki-devs] [Proposal] Making it easier to customize XWiki for public web sites
On 2/24/10 8:35 AM, Vincent Massol wrote:
I will check that, yes.
Jerome.
On Feb 24, 2010, at 12:36 AM, Jerome Velociter wrote:
I tend to think we don't want to introduce skin-specific variables.
I would say we have all four variables in templates/ and
displayContentMenu is ignored for older skins as they had no content
menu (i.e. everything was in the "main menu"). My description of the
main menu above was colibri specific indeed
Hello devs,
When we are using XWiki for public web sites, most of the time we want
to hide some elements in the UI for guest users (and sometimes for
authenticated users as well).
Currently, it's not elegant to do so : either we have to create a custom
skin, override a couple of templates (with all the merging nightmare it
bringd when upgrading the wiki) - either we create a SSX to "hide"
visually elements.
None of those solutions are really satisfactory. The first one is
painful, the second one is only a workaround and can be a pain too
(there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I
propose to make couple of light changes to some templates to make our
life easier :
1) Add 4 variables in layoutvars.vm :
* $displayContentMenu // display or not the content menu (view, edit
links, etc.) true by default
* $displayMainMenu // display or not the main menu (wiki and space
links, user profile) true by default
Is this notion not specific to colibri only? Do we want to make it a generic feature for
all skins or do we want to add an empty skinlayoutvars.vm in templates/ that are there so
that skins fill it with skin-specific vars? * $displayDocExtra // display or not the tabs
with doc extra links
(comments, attachments, etc.) true by default
Don't we already have a variable for hiding the doc extra tabs? We need to make sure
we use the same one. * $displayShortcuts // display or not the
document shortcuts (those are
in the line written under the document title)
(this is XWIKI-4394 "Allow some UI elements not to be displayed by
setting a variable")
2) Add a "extravars.vm" template that remains empty by default. This
will allow to override values from xwikivars/layoutvars without the need
to override them (and introducing the merging pain upon upgrade).
(this is XWIKI-4927 "We need a way to be able to override variables from
xwikivars.vm / layoutvars.vm without overriding these templates")
Please let me know what you think, I would like to move forward with
this during 2.3
+1
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:21 a.m.
On Feb 24, 2010, at 11:11 AM, Jerome Velociter wrote:
I will check that, yes.
Jerome.
>
>> * $displayShortcuts // display or not the document shortcuts (those are
>> in the line written under the document title)
>>
>> (this is XWIKI-4394 "Allow some UI elements not to be displayed by
>> setting a variable")
>>
>> 2) Add a "extravars.vm" template that remains empty by default. This
>> will allow to override values from xwikivars/layoutvars without the need
>> to override them (and introducing the merging pain upon upgrade).
>>
>> (this is XWIKI-4927 "We need a way to be able to override variables from
>> xwikivars.vm / layoutvars.vm without overriding these templates")
>>
>> Please let me know what you think, I would like to move forward with
>> this during 2.3
>
> +1
>
> Thanks
> -Vincent
On 2/24/10 8:35 AM, Vincent Massol wrote:
I would agree only if the concept are supposed to be generic for all possible skins.
Otherwise if each skin introduces its own concepts, it's going to be a mess after a
while.
On Feb 24, 2010, at 12:36 AM, Jerome Velociter wrote:
I tend to think we don't want to introduce skin-specific variables. Hello devs,
When we are using XWiki for public web sites, most of the time we want
to hide some elements in the UI for guest users (and sometimes for
authenticated users as well).
Currently, it's not elegant to do so : either we have to create a custom
skin, override a couple of templates (with all the merging nightmare it
bringd when upgrading the wiki) - either we create a SSX to "hide"
visually elements.
None of those solutions are really satisfactory. The first one is
painful, the second one is only a workaround and can be a pain too
(there is no way currently to use a SSX "under certain conditions")
Before we can handle all this nicely using Interface eXtensions, I
propose to make couple of light changes to some templates to make our
life easier :
1) Add 4 variables in layoutvars.vm :
* $displayContentMenu // display or not the content menu (view, edit
links, etc.) true by default
* $displayMainMenu // display or not the main menu (wiki and space
links, user profile) true by default
Is this notion not specific to colibri only? Do we want to make it a generic feature for
all skins or do we want to add an empty skinlayoutvars.vm in templates/ that are there so
that skins fill it with skin-specific vars? I would say we have all four variables in templates/
and
displayContentMenu is ignored for older skins as they had no content
menu (i.e. everything was in the "main menu"). My description of the
main menu above was colibri specific indeed
Let's see what others think. It's not obvious that the number of menus is generic
to all skins. Having at least one menu is probably generic. Having 2 I'm not sure.
Some skins would work fine with only 1 menu.
Imagine a future skin adds 2 more menus (making it 4 in total). I'm not sure if it
would mean that the Colibri skin didn't use 2 menus. It could also mean that that new
skin has the concepts of 4 menus that other skins don't have.
I'm personally +0 on either choice.
Thanks
-Vincent
* $displayDocExtra // display or not the tabs with doc
extra links
(comments, attachments, etc.) true by default
Don't we already have a variable for hiding the doc extra tabs? We need to make sure
we use the same one. 
25 Feb
25 Feb
12:21 p.m.
On Wed, Feb 24, 2010 at 11:21, Vincent Massol <vincent(a)massol.net> wrote:
On Feb 24, 2010, at 11:11 AM, Jerome Velociter wrote:
Hello devs,
As you may know, we build web sites since a while with XWiki and we have had
to face the issues describe by Jerome. Modified VMs was really a pain for us
when we need to upgrade to a newer XWiki version. This is why during our
move from 1.4 to 1.9, we have mostly stopped using VM in our own skins, and
we now apply the needed changes directly into the .vm on the server using
patches, which are a more maintainable (I have move them to 2.2 in less then
an hour). So there is not only the issue regarding hidding interface for
which we need to do so (we had advanced google analytics, accessibility
markup, company logo, additionnal docextras (rigths), ...).
Since we host a farm, with many different XWiki requiring different
behaviors, these patches should also be customizable from the preferences of
each wikis.
In particular, we have a patch for hiding interface elements, not only menus
but also tags, authors, docextras globally and separately (also taking care
of removing related menu options), copyrights, version,... , that extends
the capacity initially available through the old hidden preferences named
showcomments, showattachements,...
To allow easy customization directly from XWikiPreferences without
cluttering the XWikiPreference class (like the several show... does IMO), we
have only added a single multi-valued static list, that list what we want
hidden. We have also categorized several kind of users: guest, users,
editors, managers, admin and all, based on some predefined group
(XWikiAllGroup, XWikiEditGroup, XWikiManagerGroup,...) and we provide a
leveled hiding of each interface element in a manner that guest do not see
what users can't see, guest and users do not see what editors can't see, and
so on... This has reveal to be really easy and practical, since we have a
consistent and uncluttered interface for each kind of users, and the
behavior is customizable for each spaces. Since this is a more featured
extension, the trade of, compare to Jerome proposal, is that it is a less
flexible approach, the velocity code being already written with some
predefined behavior.
Anyway, I hope you were interested by my story. If you want more, I am open
to share any of these patches... but to be really useful in a general case,
additional tuning is probably required.
Thanks for reading me.
Denis
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On 2/24/10 8:35 AM, Vincent Massol wrote:
>
> On Feb 24, 2010, at 12:36 AM, Jerome Velociter wrote:
>
>> Hello devs,
>>
>> When we are using XWiki for public web sites, most of the time we want
>> to hide some elements in the UI for guest users (and sometimes for
>> authenticated users as well).
>> Currently, it's not elegant to do so : either we have to create a
custom
>> skin, override a couple of templates
(with all the merging nightmare it
>> bringd when upgrading the wiki) - either we create a SSX to "hide"
>> visually elements.
>> None of those solutions are really satisfactory. The first one is
>> painful, the second one is only a workaround and can be a pain too
>> (there is no way currently to use a SSX "under certain conditions")
>>
>> Before we can handle all this nicely using Interface eXtensions, I
>> propose to make couple of light changes to some templates to make our
>> life easier :
>>
>> 1) Add 4 variables in layoutvars.vm :
>> * $displayContentMenu // display or not the content menu (view, edit
>> links, etc.) true by default
>> * $displayMainMenu // display or not the main menu (wiki and space
>> links, user profile) true by default
>
> Is this notion not specific to colibri only? Do we want to make it a
generic
feature for all skins or do we want to add an empty
skinlayoutvars.vm in templates/ that are there so that skins fill it with
skin-specific vars?
I tend to think we don't want to introduce skin-specific variables.
I would agree only if the concept are supposed to be generic for all
possible skins. Otherwise if each skin introduces its own concepts, it's
going to be a mess after a while.
I would say we have all four variables in
templates/ and
displayContentMenu is ignored for older skins as they had no content
menu (i.e. everything was in the "main menu"). My description of the
main menu above was colibri specific indeed
Let's see what others think. It's not obvious that the number of menus is
generic to all skins. Having at least one menu is probably generic. Having 2
I'm not sure. Some skins would work fine with only 1 menu.
Imagine a future skin adds 2 more menus (making it 4 in total). I'm not
sure if it would mean that the Colibri skin didn't use 2 menus. It could
also mean that that new skin has the concepts of 4 menus that other skins
don't have.
I'm personally +0 on either choice.
Thanks
-Vincent
>> * $displayDocExtra // display or not the
tabs with doc extra links
>> (comments, attachments, etc.) true by default
>
> Don't we already have a variable for hiding the doc extra tabs? We need
to
make sure we use the same one.
I will check that, yes.
Jerome.
>
>> * $displayShortcuts // display or not the document shortcuts (those are
>> in the line written under the document title)
>>
>> (this is XWIKI-4394 "Allow some UI elements not to be displayed by
>> setting a variable")
>>
>> 2) Add a "extravars.vm" template that remains empty by default. This
>> will allow to override values from xwikivars/layoutvars without the
need
>> to override them (and introducing the
merging pain upon upgrade).
>>
>> (this is XWIKI-4927 "We need a way to be able to override variables
from
>> xwikivars.vm / layoutvars.vm without
overriding these templates")
>>
>> Please let me know what you think, I would like to move forward with
>> this during 2.3
>
> +1
>
> Thanks
> -Vincent
24 Feb
24 Feb
11:38 a.m.
New subject: [xwiki-devs] Question on JBossCache configuration and EvictionPolicyConfig...
Hi everyone,
Could you tell me if it's normal or if it's a bug; in fact i'm not sure.
I'm using jbosscache in local mode but attributes "timeToLiveSeconds" and
"maxNodes" in default-local.xml are not taken into account. It's
default.xml which is use.
Here are my configurations files :
xwiki.properties :
[...]
cache.cacheHint=jbosscache
cache.localCacheHint=jbosscache/local
[...]
default-local.xml :
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.cache.jmx.CacheJmxWrapper"
name="jboss.cache:service=Cache">
<!-- Specific eviction policy configurations. This is LRU -->
<attribute name="EvictionPolicyConfig">
<config>
<attribute
name="wakeUpIntervalSeconds">5</attribute>
<attribute
name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default -->
<region name="/xwiki">
<!-- NOT TAKEN INTO ACCOUNT, BUG ? -->
<attribute name="maxNodes">5002</attribute>
<attribute
name="timeToLiveSeconds">21602</attribute>
</region>
</config>
</attribute>
</mbean>
</server>
default.xml :
<?xml version="1.0" encoding="UTF-8"?>
<server>
<!--
==================================================================== -->
<!-- Defines JBoss Cache configuration
-->
<!--
==================================================================== -->
<!-- Note the value of the 'code' attribute has changed since JBC 1.x
-->
<mbean code="org.jboss.cache.jmx.CacheJmxWrapper"
name="jboss.cache:service=Cache">
<!-- Specific eviction policy configurations. This is LRU -->
<attribute name="EvictionPolicyConfig">
<config>
<attribute
name="wakeUpIntervalSeconds">5</attribute>
<attribute
name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default -->
<region name="/xwiki">
<attribute name="maxNodes">5001</attribute>
<attribute
name="timeToLiveSeconds">21601</attribute>
</region>
</config>
</attribute>
</mbean>
</server>
In fact, the 'maxNodes' and 'timeToLiveSeconds' which are used are 5001
and
21601.
Is it normal ?
I would like adding that I'm trying to optimise my cache configuration
because we have error "java.lang.OutOfMemoryError: Java heap space" one or
twice a week and we are suspecting a cache problem.
( Tomcat parameters used are : -Xms1024m -Xmx1048m -XX:MaxPermSize=128m
[...] )
We have many errors look like arround the OutofMemory :
08:47:45,880
[http://wiki-soa.airfrance.fr/xwiki/bin/view/XWiki/MyTestClass] ERROR
aseEvictionAlgorithm Eviction
of /xwiki/wikidict:BlogToolbar.WebPreferences failed
java.lang.NullPointerException
at org.apache.log4j.Category.log(Category.java:849)
at org.apache.commons.logging.impl.Log4JLogger.trace
(Log4JLogger.java:152)
at
org.jboss.cache.factories.ComponentRegistry.invocationsAllowed
(ComponentRegistry.java:816)
at
org.jboss.cache.invocation.CacheInvocationDelegate.cacheStatusCheck
(CacheInvocationDelegate.java:582)
at org.jboss.cache.invocation.CacheInvocationDelegate.evict
(CacheInvocationDelegate.java:355)
at org.jboss.cache.eviction.BaseEvictionPolicy.evict
(BaseEvictionPolicy.java:27)
at org.jboss.cache.eviction.BaseEvictionAlgorithm.evictCacheNode
(BaseEvictionAlgorithm.java:231)
at org.jboss.cache.eviction.LRUAlgorithm.evict
(LRUAlgorithm.java:92)
at org.jboss.cache.eviction.LRUAlgorithm.prune
(LRUAlgorithm.java:172)
at org.jboss.cache.eviction.BaseEvictionAlgorithm.process
(BaseEvictionAlgorithm.java:116)
at org.jboss.cache.eviction.EvictionTimerTask.handleRegion
(EvictionTimerTask.java:133)
at org.jboss.cache.eviction.EvictionTimerTask.processRegions
(EvictionTimerTask.java:118)
at org.jboss.cache.eviction.EvictionTimerTask.access$000
(EvictionTimerTask.java:28)
at org.jboss.cache.eviction.EvictionTimerTask$1.run
(EvictionTimerTask.java:106)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
But in fact I don't know if this error is a cause or a consequence of this
OutOfMemoryError.
Thanks,
Julien
Accédez aux meilleurs tarifs Air France, gérez vos réservations et enregistrez-vous en
ligne sur http://www.airfrance.com
Find best Air France fares, manage your reservations and check in online at
http://www.airfrance.com Les données et renseignements contenus dans ce message peuvent
être de nature confidentielle et soumis au secret professionnel et sont destinés à
l'usage exclusif du destinataire dont les coordonnées figurent ci-dessus. Si vous
recevez cette communication par erreur, nous vous demandons de ne pas la copier,
l'utiliser ou la divulguer. Nous vous prions de notifier cette erreur à
l'expéditeur et d'effacer immédiatement cette communication de votre système.
Société Air France - Société anonyme au capital de 1 901 231 625 euros - RCS Bobigny
(France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX
The data and information contained in this message may be confidential and subject to
professionnal secrecy and is intended for the exclusive use of the recipient at the
address shown above. If you receive this message by mistake, we ask you not to copy, use
or disclose it. Please notify this error to the sender immediately and delete this message
from your system. Société Air France - Limited company with capital of 1,901,231,625 euros
- Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG
CEDEX Pensez à l'environnement avant d'imprimer ce message.
Think of the environment before printing this mail.
2:28 p.m.
New subject: [xwiki-devs] Question on JBossCache configuration and EvictionPolicyConfig...
On Wed, Feb 24, 2010 at 11:38, Julien Revert <jurevert(a)airfrance.fr> wrote:
Hi everyone,
Could you tell me if it's normal or if it's a bug; in fact i'm not sure.
I'm using jbosscache in local mode but attributes "timeToLiveSeconds" and
"maxNodes" in default-local.xml are not taken into account. It's
default.xml which is use.
It depends of the cache actually. Some caches are using "default" and
some others are using "default-local". Most of the caches are using
default.xml as default configuration. See
http://code.xwiki.org/xwiki/bin/view/Modules/CacheModule for more.
This goal was to separate caches we could want to synchronize between
several XWiki instances (default) and caches for which it's not useful
(default-local). But this distinction is not useful anymore since
clustering is not done using cache configuration anymore (as you
already know it ;)). We should probably remove the default-local
things and make all caches use default.xml as default configuration
file.
Now about maxNodes, if you are trying to set the document cache size
specifically, the best is probably to set the
xwiki.store.cache.capacity property in xwiki.cfg file.
Here are my configurations files :
xwiki.properties :
[...]
cache.cacheHint=jbosscache
cache.localCacheHint=jbosscache/local
[...]
default-local.xml :
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.cache.jmx.CacheJmxWrapper"
name="jboss.cache:service=Cache">
<!-- Specific eviction policy configurations. This is LRU -->
<attribute name="EvictionPolicyConfig">
<config>
<attribute
name="wakeUpIntervalSeconds">5</attribute>
<attribute
name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default -->
<region name="/xwiki">
<!-- NOT TAKEN INTO ACCOUNT, BUG ? -->
<attribute name="maxNodes">5002</attribute>
<attribute
name="timeToLiveSeconds">21602</attribute>
</region>
</config>
</attribute>
</mbean>
</server>
default.xml :
<?xml version="1.0" encoding="UTF-8"?>
<server>
<!--
==================================================================== -->
<!-- Defines JBoss Cache configuration
-->
<!--
==================================================================== -->
<!-- Note the value of the 'code' attribute has changed since JBC 1.x
-->
<mbean code="org.jboss.cache.jmx.CacheJmxWrapper"
name="jboss.cache:service=Cache">
<!-- Specific eviction policy configurations. This is LRU -->
<attribute name="EvictionPolicyConfig">
<config>
<attribute
name="wakeUpIntervalSeconds">5</attribute>
<attribute
name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default -->
<region name="/xwiki">
<attribute name="maxNodes">5001</attribute>
<attribute
name="timeToLiveSeconds">21601</attribute>
</region>
</config>
</attribute>
</mbean>
</server>
In fact, the 'maxNodes' and 'timeToLiveSeconds' which are used are 5001
and
21601.
Is it normal ?
I would like adding that I'm trying to optimise my cache configuration
because we have error "java.lang.OutOfMemoryError: Java heap space" one or
twice a week and we are suspecting a cache problem.
( Tomcat parameters used are : -Xms1024m -Xmx1048m -XX:MaxPermSize=128m
[...] )
We have many errors look like arround the OutofMemory :
08:47:45,880
[http://wiki-soa.airfrance.fr/xwiki/bin/view/XWiki/MyTestClass] ERROR
aseEvictionAlgorithm Eviction
of /xwiki/wikidict:BlogToolbar.WebPreferences failed
java.lang.NullPointerException
at org.apache.log4j.Category.log(Category.java:849)
at org.apache.commons.logging.impl.Log4JLogger.trace
(Log4JLogger.java:152)
at
org.jboss.cache.factories.ComponentRegistry.invocationsAllowed
(ComponentRegistry.java:816)
at
org.jboss.cache.invocation.CacheInvocationDelegate.cacheStatusCheck
(CacheInvocationDelegate.java:582)
at org.jboss.cache.invocation.CacheInvocationDelegate.evict
(CacheInvocationDelegate.java:355)
at org.jboss.cache.eviction.BaseEvictionPolicy.evict
(BaseEvictionPolicy.java:27)
at org.jboss.cache.eviction.BaseEvictionAlgorithm.evictCacheNode
(BaseEvictionAlgorithm.java:231)
at org.jboss.cache.eviction.LRUAlgorithm.evict
(LRUAlgorithm.java:92)
at org.jboss.cache.eviction.LRUAlgorithm.prune
(LRUAlgorithm.java:172)
at org.jboss.cache.eviction.BaseEvictionAlgorithm.process
(BaseEvictionAlgorithm.java:116)
at org.jboss.cache.eviction.EvictionTimerTask.handleRegion
(EvictionTimerTask.java:133)
at org.jboss.cache.eviction.EvictionTimerTask.processRegions
(EvictionTimerTask.java:118)
at org.jboss.cache.eviction.EvictionTimerTask.access$000
(EvictionTimerTask.java:28)
at org.jboss.cache.eviction.EvictionTimerTask$1.run
(EvictionTimerTask.java:106)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
But in fact I don't know if this error is a cause or a consequence of this
OutOfMemoryError.
Thanks,
Julien
Accédez aux meilleurs tarifs Air France, gérez vos réservations et enregistrez-vous en
ligne sur http://www.airfrance.com
Find best Air France fares, manage your reservations and check in online at
http://www.airfrance.com Les données et renseignements contenus dans ce message peuvent
être de nature confidentielle et soumis au secret professionnel et sont destinés à
l'usage exclusif du destinataire dont les coordonnées figurent ci-dessus. Si vous
recevez cette communication par erreur, nous vous demandons de ne pas la copier,
l'utiliser ou la divulguer. Nous vous prions de notifier cette erreur à
l'expéditeur et d'effacer immédiatement cette communication de votre système.
Société Air France - Société anonyme au capital de 1 901 231 625 euros - RCS Bobigny
(France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX
The data and information contained in this message may be confidential and subject to
professionnal secrecy and is intended for the exclusive use of the recipient at the
address shown above. If you receive this message by mistake, we ask you not to copy, use
or disclose it. Please notify this error to the sender immediately and delete this message
from your system. Société Air France - Limited company with capital of 1,901,231,625 euros
- Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG
CEDEX Pensez à l'environnement avant d'imprimer ce message.
Think of the environment before printing this mail.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
25 Feb
25 Feb
11:51 a.m.
New subject: [xwiki-devs] Question on JBossCache configuration and EvictionPolicyConfig...
Ok, thanks for your answer.
In fact i had also change the other parameter (I haven't found any
information about this parameter on your website, maybe it will be good to
add something on it ?) :
xwiki.store.cache.pageexistcapacity (Which is in fact the maxNode for cache
xwiki.store.pageexistcache)
in xwiki.cfg.
I'm agree, maybe it will be easier to understanding if you remove
default-local.xml in fact.
Julien
Thomas Mortagne
<thomas.mortagne@
xwiki.com> A
Envoyé par : XWiki Developers <devs(a)xwiki.org>
devs-bounces@xwik cc
i.org
Objet
Re: [xwiki-devs] Question on
24/02/2010 14:28 JBossCache configuration and
EvictionPolicyConfig...
Veuillez répondre
à
XWiki Developers
<devs(a)xwiki.org>
On Wed, Feb 24, 2010 at 11:38, Julien Revert <jurevert(a)airfrance.fr> wrote:
Hi everyone,
Could you tell me if it's normal or if it's a bug; in fact i'm not sure.
I'm using jbosscache in local mode but attributes "timeToLiveSeconds" and
"maxNodes" in default-local.xml are not taken into account. It's
default.xml which is use.
It depends of the cache actually. Some caches are using "default" and
some others are using "default-local". Most of the caches are using
default.xml as default configuration. See
http://code.xwiki.org/xwiki/bin/view/Modules/CacheModule for more.
This goal was to separate caches we could want to synchronize between
several XWiki instances (default) and caches for which it's not useful
(default-local). But this distinction is not useful anymore since
clustering is not done using cache configuration anymore (as you
already know it ;)). We should probably remove the default-local
things and make all caches use default.xml as default configuration
file.
Now about maxNodes, if you are trying to set the document cache size
specifically, the best is probably to set the
xwiki.store.cache.capacity property in xwiki.cfg file.
Here are my configurations files :
xwiki.properties :
[...]
cache.cacheHint=jbosscache
cache.localCacheHint=jbosscache/local
[...]
default-local.xml :
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.cache.jmx.CacheJmxWrapper"
name="jboss.cache:service=Cache">
<!-- Specific eviction policy configurations. This is LRU -->
<attribute name="EvictionPolicyConfig">
<config>
<attribute
name="wakeUpIntervalSeconds">5</attribute>
<attribute
name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default -->
<region name="/xwiki">
<!-- NOT TAKEN INTO ACCOUNT, BUG ? -->
<attribute name="maxNodes">5002</attribute>
<attribute
name="timeToLiveSeconds">21602</attribute>
</region>
</config>
</attribute>
</mbean>
</server>
default.xml :
<?xml version="1.0" encoding="UTF-8"?>
<server>
<!--
>
==================================================================== -->
<!-- Defines JBoss Cache configuration
> -->
<!--
>
==================================================================== -->
<!-- Note the value of the 'code'
attribute has changed since JBC
1.x
> -->
<mbean
code="org.jboss.cache.jmx.CacheJmxWrapper"
name="jboss.cache:service=Cache">
<!-- Specific eviction policy configurations. This is LRU -->
<attribute name="EvictionPolicyConfig">
<config>
<attribute
name="wakeUpIntervalSeconds">5</attribute>
<attribute
name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<!-- Cache wide default -->
<region name="/xwiki">
<attribute name="maxNodes">5001</attribute>
<attribute
name="timeToLiveSeconds">21601</attribute>
</region>
</config>
</attribute>
</mbean>
</server>
In fact, the 'maxNodes' and 'timeToLiveSeconds' which are used are 5001
and
21601.
Is it normal ?
I would like adding that I'm trying to optimise my cache configuration
because we have error "java.lang.OutOfMemoryError: Java heap space" one
or
twice a week and we are suspecting a cache problem.
( Tomcat parameters used are : -Xms1024m -Xmx1048m -XX:MaxPermSize=128m
[...] )
We have many errors look like arround the OutofMemory :
08:47:45,880
[http://wiki-soa.airfrance.fr/xwiki/bin/view/XWiki/MyTestClass] ERROR
aseEvictionAlgorithm Eviction
of /xwiki/wikidict:BlogToolbar.WebPreferences failed
java.lang.NullPointerException
at org.apache.log4j.Category.log(Category.java:849)
at org.apache.commons.logging.impl.Log4JLogger.trace
(Log4JLogger.java:152)
at
org.jboss.cache.factories.ComponentRegistry.invocationsAllowed
(ComponentRegistry.java:816)
at
org.jboss.cache.invocation.CacheInvocationDelegate.cacheStatusCheck
(CacheInvocationDelegate.java:582)
at org.jboss.cache.invocation.CacheInvocationDelegate.evict
(CacheInvocationDelegate.java:355)
at org.jboss.cache.eviction.BaseEvictionPolicy.evict
(BaseEvictionPolicy.java:27)
at
org.jboss.cache.eviction.BaseEvictionAlgorithm.evictCacheNode
(BaseEvictionAlgorithm.java:231)
at org.jboss.cache.eviction.LRUAlgorithm.evict
(LRUAlgorithm.java:92)
at org.jboss.cache.eviction.LRUAlgorithm.prune
(LRUAlgorithm.java:172)
at org.jboss.cache.eviction.BaseEvictionAlgorithm.process
(BaseEvictionAlgorithm.java:116)
at org.jboss.cache.eviction.EvictionTimerTask.handleRegion
(EvictionTimerTask.java:133)
at org.jboss.cache.eviction.EvictionTimerTask.processRegions
(EvictionTimerTask.java:118)
at org.jboss.cache.eviction.EvictionTimerTask.access$000
(EvictionTimerTask.java:28)
at org.jboss.cache.eviction.EvictionTimerTask$1.run
(EvictionTimerTask.java:106)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
But in fact I don't know if this error is a cause or a consequence of
this
OutOfMemoryError.
Thanks,
Julien
Accédez aux meilleurs tarifs Air France, gérez vos réservations et
enregistrez-vous en ligne sur http://www.airfrance.com
Find best Air France fares, manage your reservations
and check in online
at http://www.airfrance.com Les données et renseignements contenus dans
ce message peuvent être de nature confidentielle et soumis au secret
professionnel et sont destinés à l'usage exclusif du destinataire dont les
coordonnées figurent ci-dessus. Si vous recevez cette communication par
erreur, nous vous demandons de ne pas la copier, l'utiliser ou la
divulguer. Nous vous prions de notifier cette erreur à l'expéditeur et
d'effacer immédiatement cette communication de votre système. Société Air
France - Société anonyme au capital de 1 901 231 625 euros - RCS Bobigny
(France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX
The data and information contained in this message may
be confidential
and subject to professionnal secrecy and is intended for the exclusive use
of the recipient at the address shown above. If you receive this message by
mistake, we ask you not to copy, use or disclose it. Please notify this
error to the sender immediately and delete this message from your system.
Société Air France - Limited company with capital of 1,901,231,625 euros -
Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, 95
747 Roissy CDG CEDEX Pensez à l'environnement avant d'imprimer ce message.
Think of the environment before printing this mail.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Accédez aux meilleurs tarifs Air France, gérez vos réservations et enregistrez-vous en
ligne sur http://www.airfrance.com
Find best Air France fares, manage your reservations and check in online at
http://www.airfrance.com Les données et renseignements contenus dans ce message peuvent
être de nature confidentielle et soumis au secret professionnel et sont destinés à
l'usage exclusif du destinataire dont les coordonnées figurent ci-dessus. Si vous
recevez cette communication par erreur, nous vous demandons de ne pas la copier,
l'utiliser ou la divulguer. Nous vous prions de notifier cette erreur à
l'expéditeur et d'effacer immédiatement cette communication de votre système.
Société Air France - Société anonyme au capital de 1 901 231 625 euros - RCS Bobigny
(France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG CEDEX
The data and information contained in this message may be confidential and subject to
professionnal secrecy and is intended for the exclusive use of the recipient at the
address shown above. If you receive this message by mistake, we ask you not to copy, use
or disclose it. Please notify this error to the sender immediately and delete this message
from your system. Société Air France - Limited company with capital of 1,901,231,625 euros
- Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, 95 747 Roissy CDG
CEDEX Pensez à l'environnement avant d'imprimer ce message.
Think of the environment before printing this mail.
5379
days inactive
5381
days old
9 comments
7 participants
participants (7)
-
Denis Gervalle -
Jerome Velociter -
Julien Revert -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol