Hi devs
http://jira.xwiki.org/browse/XWIKI-13623
I would like to discuss the suggested solution, before I start implementing
it:
*I suggest the following solution:*
Introducing a nested DocumentLoader class which loads the document calling
the basestore loadXWikiDoc in a synchronized getDocOrLoad method. The
DocumentLoader objects gets instantiated in the cacheStore on a cache miss.
It then gets stored in a ConcurrentHashMap using the same key which is used
for the document cache (DocumentReference including language). Using
putIfAbsent to insert the DocumentLoader and calling the synchronized load
method on the object in the map solves the memory visibility issue and
moreover ensures that the same XWikiDocument is not loaded multiple times
concurrently from the database. It is still possible to load different
documents in parallel. A DocumentLoader will load the XWikiDocument only
once and the returns the identical document object on any following call of
the synchronized getDocOrLoad method.
WDYT?
Kind Regards,
Fabian
Hi, Fitz,
As you probably know (from Google's mail), the final evaluation is coming
up.
We`d like you to start getting ready for it and let us know what you have
been up to in the last period.
As Google suggests, it would also be a good idea to ask for some feedback
before submitting the final evaluation and URL to the work done (from your
part), just to make sure everything is in order.
It would also be a good idea to resume communication, since it`s been a bit
low lately and we are not getting enough feedback from you recently.
Hope to hear from you soon!
-Eduard
Hi Thomas and all,
Back from holidays! :)
I’ve noticed that the new feature of counting installed extensions on e.x.o is having a drawback: it saturates the activity stream, making it very hard to see real edits by users. Every day the scheduler modifies lots of wiki pages to set the new install count. See for example: http://www.xwiki.org/xwiki/bin/view/Main/News
I think a simple change would be for the scheduler to make modifications as minor edits. This should prevent the edits from being visible in the AS.
WDYT?
Now this is going to cause another real issue very soon: pages will soon start to have a lot of revisions and we know this is currently a performance issue. It’s also hiding real edits in the history making the history a bit less clean.
I guess an option would be for the scheduler to delete the last revision after it updates a page. Although not very nice, it could work for now. WDYT?
Thanks
-Vincent
Hello XWiki devs,
I was wondering if there is an Event which gets published when an
XWikiDocument first gets loaded, or a good way of adding such an event? I
have been looking for such an event, but one does not appear to exist and
to add one looks like it would require making changes to the
XWikiHibernateStore to have it fire events on load.
I am looking for a way to intercept documents when they are first being
loaded so I can populate some of their objects from an external source and
avoid the issue of having many joins when working with documents with a
large number of objects. My other thought is to use a custom hibernate
mapping to get this data for a custom table I can populate in other ways,
but I would prefer the event driven approach.
Thanks!
~Vincent
I just released an extension to easily add support for Let's Encrypt
in your wiki.
The extension automatically register Let's Encrypt root certificate in
the trust store at runtime to allow you to request Let's Encrypt
signed HTTP servers.
See http://extensions.xwiki.org/xwiki/bin/view/Extension/Let%27s+Encrypt+suppor…
--
Thomas Mortagne
Hi devs,
I finally started the long waiting refactoring to deal with
conflicting ScriptContext and VelocityContext.
* they are now fully in sync (at least that's the goal when you use
them properly :))
* VelocityContext moved to a more internal thing or at least very
specific (use case where you execute yourself some Velocity code). In
general if you want to set or access script bindings, do it trough
ScriptContext.
* new ScriptContextManager#getCurrentScriptContext which directly
return a not updated ScriptContext. To be used when you want to set
binding mostly and you don't care if it's up to date or not. If there
is any chance you access anything in the script context it's safer to
use #getScriptContext
So if you have weird behavior with Velocity variable you know who to
blame. Please report me anything that looks wrong on this area.
--
Thomas Mortagne