Hi devs,
Right now we recommend this on http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HPrerequis… :
"A minimum of 300MB of heap memory and 96MB of permGen. Recommended values are above 512MB for the heap and 128MB for the permGen (-Xmx512m -XX:MaxPermSize=128m)"
I've discovered on http://ci.xwiki.org/job/xwiki-enterprise-test-extension/org.xwiki.enterpris… that we had an OOM and it seems to happen more and in more in our functional tests on CI. Something we've done must have increased our permgen memory.
I've done some measurements with yourkit and here's what I found:
* After XWiki is started and before any page is called we already use 64MB of permgen
* After calling the home page, the permgen used goes to 101MB
* After calling a page using the code macro, the permgen goes to 132MB
So it seems that your default value of 96MB and recommended value of 128MB are not enough…
BTW forcing garbage collection reduces from 132MB to 130MB (not much).
We need to either find what is taking all our permgen memory or if it's legit increase our recommendations and the default value we use in start_xwiki.sh/bat
Any idea?
My hunch tells me the Extension Manager could be the cause.
Thanks
-Vincent
Hi devs,
With XWiki 4.x cycle coming to an end soon, it's time to prepare the roadmap for XWiki 5.0.
This is a proposal that comes from some internal meetings done with XWiki committers who are working for XWiki SAS.
If you're interesting in participating to this release, don't hesitate to add yourself to the list so that everyone can have some visibility of what's going to be worked on during this timeframe!
If you think some work defined below doesn't go in the interest of the project also feel free to raise issues.
Features:
* Continue SOLR implementation - Edy
* EM upgrade of subwikis + flavor concept (add Flavor type in EM/Repository) + leftover from 4.x for EM/DW - Thomas + Marius for DW UI part for flavors
* AWM work from 4.x to finish (see http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome) - Marius
* scalable import/export - Thomas
* Home page improvements (XE) and usability improvements in general - JV
* Horizontal Menu management (add, remove pages) - JV
* virtual=1 by default - Edy (Edy will need to make a proposal for that since it's an important decision ;))
* l10n speed improvements - Ludovic
Important JIRAs sorted by priority (most important first):
* AWM Add the ability to publish an application as an extension XWIKI-7377 - Marius
* AWM Add the ability to export an application XWIKI-7376 - Marius
* Unable to edit a page using the WYGIWYG editor after adding a dashboard macro to it XWIKI-8495 - Need volunteer
* Improve AWM for it to deal with error messages made by Client when filling the AWM form in using special chars XWIKI-8763 - Marius
* Import of Office file breaks Activity Stream and Recently Modified Panel XRENDERING-261 - Need volunteer
* Cannot change document title from "inline" mode XWIKI-7905 - Not sure if we want it, to be checked with Marius
* When the workspace owner is changed, the new owner is not added as a member nor in the admin group XWIKI-8397 - Edy
* Unable to upload a new attachment using the "All pages" tab in the WYSIWYG editor XWIKI-8465 - Marius
* Workspace owner and initial members not set as members (nor in admin group) when the workspace identifier contains an underscore XWIKI-8394 - Edy
Investigations:
* XEM Homepage / Portal - Caty
* Knowledge base Flavor - Caty/Ludovic
* New Activity Stream Investigation Part 1 - JV (he's agree to become our AS champion :))
* General Flavours Investigation - Caty + input from tech
Regarding dates I'm proposing the following:
* 5.0M1: 4 March 2013
* 5.0M2: 25 March 2013
* 5.0RC1: 8 April 2013
* 5.0Final: 15 April 2013
Thanks
-Vincent
Hi,
in 4.x we introduced UI Extensions (UIX) and "Extension Points", it
allows applications to come and plug their bits of UI where it is
possible [1]. 5.x is a good time to provide a list of useful Extension
Points (UIXP) in our velocity templates, allowing applications to plug
themselves in, for example : the header, before the content, the
footer, etc.
To allow this I can think of 2 strategies:
== 1) Manually add UIXPs ==
Actions:
* Discuss where are the common places where applications would like to
plug (in our opinion)
* Make a lengthy list
* Vote it
* Introduce an API call (services.uix.getExtensions()) for each item in the list
* Commit it
Pros:
* We can carefully build the UI API
Cons:
* We can't think of everything
* Long process
* Overridden templates won't display the extensions
== 2) Instrument our templating mechanism with UIXPs ==
Actions:
* Modify the #template macro so that it create UIXPs before and after
the parseTemplate call. Calling #template.vm would create the
following UIXP:
** platform.template.global.before (or:
platform.template.global.above, platform.template.global.top)
** platform.template.global.after (or: platform.template.global.below,
platform.template.global.bottom)
* Commit it
Pros:
* A lot of available UIXPs
* We've worked on our template architecture for a long time, UIXP
would benefit from that
* Quick process
Cons:
* It'd make our current template architecture an API ... but since
templates can be overridden in skins, it already is one.
* A lot of API calls (but tests with YourKit shows that it doesn't
impact performance)
Note:
2) doesn't exclude 1), we'd probably still need to introduce UIXP
within templates, but we'd have way less UIX API calls with this
method.
WDYT ?
I guess it's quite obvious that my opinion is biased, I've started
playing with 2) and it's quite cool :)
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/UIExtension+Module
Thanks,
JV.