Hi we are having problems with outofmemory permgen errors, we make heavy use of the attachment feature in our xwiki installation and as the site has become more popular the memory errors have increased. I found the email below as a response to a similar question does anyone know if this has now been resolved.
We are running XWiki Enterprise 2.1.1.25889, on Windows Server 2008 Tomcat 6.0 with Java 1.6.0_18, the database is SQL server 2008.
Thanks for any help.
Cheers
Iola
Subject:
Re: [xwiki-users] Out of memory error<http://markmail.org/message/dctm6ag7j2ci6j42>
[cid:image001.gif@01CB69F1.481DD2E0]<http://markmail.org/message/dctm6ag7j2ci6j42>
From:
Vincent Massol (vinc...(a)massol.net)
Date:
Jul 16, 2009 4:19:39 am
List:
org.xwiki.users
Hi there,
Unfortunately XWiki is still memory intensive when it comes to attachment manipulation. Thus the memory required depends on the size of the attachment you're uploading.
Seen the OOM error you're getting you'd need to increase the memory to make it work.
We really need to look into this and see how we can reduce the memory needs.
Thanks -Vincent
I propose that we deprecate some functions in XWikiAttachment and XWikiAttachmentArchive for 2.5 final.
The theoretical reason is that they are implementation bound and we should not expose the
implementation to the user of the API. The practical reason is that JRCS is very badly suited for
handling large data as it stores everything (including all versions) in a String. Since the content
is base64 encoded (increasing the size by 30%) and java Strings are UTF-16 (doubling the size) the
memory consumption from using JRCS is at least 2.6 times the size of all revisions of the content.
I didn't find these functions used anywhere else in platform.
These are the functions I would like to deprecate:
XWikiAttachment
public void setArchive(Archive archive)
public Archive getArchive()
XWikiAttachmentArchive
public Archive getRCSArchive()
public void setRCSArchive(Archive archive)
WDYT?
Caleb
Hi devs,
The XWiki 2.5 RC1 was scheduled today. Given that M2 was released a
couple of days later, and that we still need to wait for the vote
results, I propose to release XE 2.5 RC1 tomorrow.
Since 2.5 is entering the RC phase, I also propose to move 2.5 to a
branch (core, web, enterprise, manager).
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
I've made some additions to our Forms Standard page:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms
The standard is very similar to what we have for the WYSIWYG editor:
- vertical alignment
- display of labels (we have uppercase text for Colibri style consistency)
- display of hints/error messages
- primary/secondary buttons
I made a proposal to integrate this standards inside the platform:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal
- administration
- object editor
- user profile
- Create Space/Page
- Copy/Rename Page
Any feedback is welcomed,
Caty
fyi
-Vincent
Begin forwarded message:
> From: Brett Porter <brett(a)apache.org>
> Date: October 8, 2010 7:03:48 PM GMT+02:00
> To: announce(a)maven.apache.org, Maven Users List <users(a)maven.apache.org>
> Cc: Maven Developers List <dev(a)maven.apache.org>
> Subject: [ANN] Maven Release Plugin 2.1 Released
> Reply-To: users(a)maven.apache.org
>
> The Maven team is pleased to announce the release of the Maven Release Plugin, version 2.1
>
> This plugin is used to release a project with Maven, saving a lot of repetitive, manual work. Releasing a project is made in two steps: prepare and perform.
>
> http://maven.apache.org/plugins/maven-release-plugin/
>
> You should specify the version in your project's plugin configuration:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-release-plugin</artifactId>
> <version>2.1</version>
> </plugin>
>
> Release Notes - Maven Release Plugin - Version 2.1
>
> ** Bug
> * [MRELEASE-128] - SCM properties being replaced during release:perform
> * [MRELEASE-317] - release:prepare should fail if any pom depends on SNAPSHOT parent
> * [MRELEASE-318] - Release plugin throws NullPointerException when using version range for dependency
> * [MRELEASE-350] - Option '0' for "specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ):" is broken
> * [MRELEASE-370] - release:prepare is not updating inter-modules dependencies to the next version snapshot identifier correctly (-DdryRun=true).
> * [MRELEASE-458] - Branch Does Not Honor updateWorkingCopyVersions Setting
> * [MRELEASE-524] - command line versions don't seem to work on release:branch for specific format
> * [MRELEASE-536] - CommonBasedir Calculation fails on windows
> * [MRELEASE-546] - regression introduced in MRELEASE-261
> * [MRELEASE-551] - Unable to release with maven 3 when having no $HOME/.m2/settings.xml
> * [MRELEASE-563] - help strings need help, they are not helpful out of context
> * [MRELEASE-586] - release:perform - The temporary file "pom.xml.branch" should be ignored as "pom.xml.next" and "pom.xml.tag" are ignored
> * [MRELEASE-589] - Resolved dependencies overwritten when multiple subprojects with SNAPSHOT dependencies are released
>
> ** Improvement
> * [MRELEASE-497] - Don't overwrite SVN auth cache
> * [MRELEASE-530] - Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems (scm 1.4 upgrade)
> * [MRELEASE-554] - Allow custom files to be modified before doing a prepare or branch...
> * [MRELEASE-583] - Better Snapshot Dependency Handling
>
> Enjoy,
> -The Maven team
>
> --
> Brett Porter
> brett(a)apache.org
> http://brettporter.wordpress.com/
>
>
>
>
I have been observing problems with the versioning scheme which we are using.
Because applications are not branched along with core, when a bugfix version of a stable branch is
released, new versions of applications are typically pulled in. This means that `experimental' code
is being introduced into a `stable' branch in a bugfix version. This is not the path I would choose
but more importantly we can't honestly say that our code goes through a milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the release
without major issue, I think the same issue is behind the release of 2 bogus versions (2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own wiki are
faced with a set of version numbers and no way to know what is compatible with what. A user who I
spoke with last night had this very problem. We could publish a compatibility matrix but if we were
to show all the versions a given application is compatible with, that would require testing each
application version against each core version and I think we need to concentrate on testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything was
branched for a release. Relevant questions which come to mind are "do we need the capability to
release applications at separate times?" and "is there no way to do that with synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
Hello Devs !
I built a component to handle unique generation of document names.
The documents must be instantiations of a specified class and the
generation is done taking into consideration the currently existing
documents and all the values used before. It retrieves the maximum value
currently used, increments
It is configurable in xwiki.properties.
More info cand be found here
http://code.xwiki.org/xwiki/bin/view/Plugins/UniqueIdentificationNumberPlug…
.
Thanks,
Stefan Abageru !
Hi, I would like to hard deprecate com.xpn.xwiki.api.Context#getUtil(). It exposes functions to the
user which are not optimized for scripting and some of which are security vulnerabilities. This
class is not in the api package and it appears that it was never intended to be exposed to the user.
+1 @Deprecated.
Caleb