xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Performance of synchronization in XWiki.

by Caleb James DeLisle

I ran some testing by injecting printline statements after the beginning of each synchronization block in all of the xwiki codebase and then ran some tests. xwiki webstandards test: pages loaded: 925 synchronization blocks entered: 2,512,524 synchronizations per page: 2,716 Excluding the first page load on start-up, these are the total synchronizations from running the webstandards tests. Note that they don't add up to exactly 2,512,524 because some were spoiled when 2 threads tried to write to stdout simultaneously. Total Percent Location 1651401 65.73% XWikiCacheStore.java:115 316411 12.59% EmbeddableComponentManager.java:352 142094 5.66% XWikiContext.java:260 103028 4.10% XWiki.java:5380 58151 2.31% XWikiContext.java:282 54891 2.18% XWiki.java:5455 46324 1.84% DefaultVelocityFactory.java:72 46320 1.84% DefaultVelocityFactory.java:82 29447 1.17% EmbeddableComponentManager.java:138 15010 0.60% DefaultBeanManager.java:204 14595 0.58% DefaultXWikiRenderingEngine.java:239 10933 0.44% URIClassLoader.java:438 3812 0.15% XWiki.java:5406 3262 0.13% DefaultVelocityEngine.java:227 3262 0.13% DefaultVelocityEngine.java:245 2867 0.11% XWikiNotificationManager.java:130 1941 0.08% XWikiGroupServiceImpl.java:798 958 0.04% XWikiConfigurationService.java:50 958 0.04% XWikiNotificationManager.java:254 958 0.04% XWikiNotificationManager.java:265 957 0.04% XWikiCacheStore.java:704 951 0.04% XWikiNotificationManager.java:230 949 0.04% XWikiNotificationManager.java:241 917 0.04% XWikiNotificationManager.java:219 852 0.03% XWikiStatsServiceImpl.java:182 371 0.01% XWikiDocumentQueue.java:88 351 0.01% XWikiDocumentQueue.java:55 142 0.01% XWikiDocumentQueue.java:69 112 0.00% XWikiDocumentQueue.java:98 66 0.00% AdminAction.java:57 24 0.00% RightsManager.java:164 15 0.00% EditAction.java:59 UI tests were also run to give a more well rounded view of what real traffic might look like: 1666727 57.98% XWikiCacheStore.java:115 463369 16.12% EmbeddableComponentManager.java:352 234027 8.14% XWiki.java:5380 175972 6.12% XWikiContext.java:260 70156 2.44% XWikiContext.java:282 65952 2.29% XWiki.java:5455 43553 1.52% DefaultVelocityFactory.java:72 43552 1.52% DefaultVelocityFactory.java:82 33512 1.17% EmbeddableComponentManager.java:138 13451 0.47% DefaultBeanManager.java:204 9650 0.34% DefaultXWikiRenderingEngine.java:239 9450 0.33% XWikiNotificationManager.java:130 5176 0.18% XWikiGroupServiceImpl.java:798 5019 0.17% URIClassLoader.java:438 3965 0.14% XWiki.java:5406 2850 0.10% DefaultVelocityEngine.java:227 2850 0.10% DefaultVelocityEngine.java:245 2717 0.09% XWikiConfigurationService.java:50 2694 0.09% XWikiCacheStore.java:704 2624 0.09% XWikiNotificationManager.java:219 2624 0.09% XWikiNotificationManager.java:230 2624 0.09% XWikiNotificationManager.java:241 2590 0.09% XWikiNotificationManager.java:254 2590 0.09% XWikiNotificationManager.java:265 749 0.03% XWikiDocumentQueue.java:69 718 0.02% XWikiStatsServiceImpl.java:182 554 0.02% XWikiDocumentQueue.java:88 550 0.02% EmbeddableComponentManager.java:201 476 0.02% XWikiDocumentQueue.java:55 406 0.01% XWikiHibernateVersioningStore.java:142 403 0.01% XWikiNotificationManager.java:140 403 0.01% XWikiNotificationManager.java:155 403 0.01% XWikiNotificationManager.java:167 403 0.01% XWikiNotificationManager.java:181 403 0.01% XWikiNotificationManager.java:194 403 0.01% XWikiNotificationManager.java:206 282 0.01% XWikiDocumentQueue.java:98 209 0.01% EditAction.java:59 101 0.00% RightsManager.java:164 81 0.00% AdminAction.java:57 61 0.00% EmbeddableComponentManager.java:289 52 0.00% EmbeddableComponentManager.java:256 44 0.00% LucenePlugin.java:656 35 0.00% InlineAction.java:39 23 0.00% DefaultCSRFToken.java:130 19 0.00% MutableHttpServletRequestFactory.java:43 15 0.00% AbstractGenericComponentManager.java:93 13 0.00% LucenePlugin.java:450 5 0.00% XWikiNotificationManager.java:56 2 0.00% MacroRepository.java:65 2 0.00% XWiki.java:408 1 0.00% ActivityStreamCleaner.java:89 1 0.00% EmbeddableComponentManager.java:163 1 0.00% EmbeddableComponentManager.java:269 1 0.00% RightsManagerListener.java:85 1 0.00% SchedulerPlugin.java:561 1 0.00% StackingComponentEventManager.java:69 1 0.00% XWikiGroupServiceImpl.java:150 1 0.00% XWikiGroupServiceImpl.java:162 1 0.00% XWikiGroupServiceImpl.java:180 1 0.00% XWikiHibernateBaseStore.java:142 1 0.00% XWikiHibernateBaseStore.java:265 1 0.00% XWikiHibernateBaseStore.java:557 1 0.00% XWiki.java:5493 1 0.00% XWiki.java:5515 These numbers seem to be quite conclusive that XWikiCacheStore.java:115 is the lowest hanging fruit in the synchronization field. An examination of XWikiCacheStore reveals that the "per load" synchronization should be avoidable if it is not lazy initialized and is flushed differently. Is synchronization the best place to attack for performance gains? Synchronization cost is difficult to measure because it varies based on number of processor cores and processor sockets. In the worst case, the caches in multiple cores on multiple processor sockets all need to be flushed and this would be the case with high contention mutexes. As a matter of good practice, I think we should reduce the amount of synchronization as much as is reasonable. Caleb

13 years, 4 months

[xwiki-devs] [Discussion] Generate and publish sources for snapshot builds in the CI

by Eduard Moraru

Hi devs, I was wondering why we don`t generate source artefacts for snapshots, just like we do for final versions? While I do agree that final versions are the important ones, it's often very annoying to have to manually add sources from the filesystem (assuming you have cloned locally the git repo) for all the maven modules that you want to see the code or even the javadoc or method parameter names. For final releases we don`t have that problem because Eclipse and the Maven plugin (for example) can automatically download the sources in the background providing an effortless process. However, while working with snapshots, you are nagged continuously that the sources can not be found automatically and you experience a bit of unneeded frustration :). Not only that Would it be that much of a storage penalty for the extra sources jars to accompany the snapshot builds? Would it be that much of a build time penalty for actually generating source builds for each artefact? WDYT? Thanks, Eduard

13 years, 4 months

[xwiki-devs] Small widget possibly of interest : ajaxify forms in popups

by Jerome Velociter

Hi all, I've written a small Ajax widget for XWiki that magically ajaxifies a form in a modal popup. Right now I have no use for it directly in XWiki, but I though it would worth advertising it here as this might come handy at some point for the platform. It even works with multipart forms. The widget is here : https://gist.github.com/1184560 Regards, -- Jérôme Velociter Winesquare http://www.winesquare.net/

13 years, 4 months

[xwiki-devs] Sheets and programming rights

by Marius Dumitru Florea

Hi devs, I need your feedback regarding two use cases: (A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR Drop permissions when rendering the sheet, right? (B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR How often did you write class/document sheets requiring programming rights? I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights. WDYT? Thanks, Marius

13 years, 4 months

[xwiki-devs] How to check if a specific document has programming rights?

by Marius Dumitru Florea

Hi devs, I tried to use: $someDoc.hasProgrammingRights() but unfortunately this method checks the current/context document, not the one on which it is called. The code is in com.xpn.xwiki.api.Api: /** * Check if the current document has programming rights, meaning that it was last saved by a user with the * programming right globally granted. * * @return <tt>true</tt> if the current document has the Programming right or <tt>false</tt> otherwise. */ public boolean hasProgrammingRights() { com.xpn.xwiki.XWiki xwiki = this.context.getWiki(); return xwiki.getRightService().hasProgrammingRights(this.context); } So how do you check if a specific document has programming rights? AFAICS I need to either access the rights service or change the context document, but both require programming rights.. How can I check programming rights without needing them? Thanks, Marius

13 years, 4 months

[xwiki-devs] [VOTE] New bridge APIs

by Jerome Velociter

Hello devs, I've been working on the support of pretty thumbnails picture for XE (other mail coming on later). I've had the need for a couple of new bridge APIs, namely in DocumentAccessBridge : int getObjectNumber(DocumentReference documentReference, DocumentReference classReference, String parameterName, String valueToMatch); to get the number of the first object that has a property with a certain value in a document. Sort of similar to com.xpn.xwiki.api.Document#getObject(String, String, String) Object getProperty(DocumentReference documentReference, DocumentReference classReference, int objectNumber, String propertyName); to get the value of a property for the Nth object of a class in a document (to be used in combination with the previous one for example). and finally : Object getProperty(ObjectReference objectReference, String propertyName); Object getProperty(ObjectPropertyReference objectPropertyReference); two new APIs to get properties value based both on object reference + property name, or just property reference Let me know what you think My +1 -- Jerome Velociter Winesquare http://www.winesquare.net/

13 years, 4 months

[xwiki-devs] [VOTE] New model script service APIs

by Jerome Velociter

Hello, For my work on the pretty thumbnails I also had the need to add some service API to the Model module script service. Basically the same kind of APIs that did already exist to resolve documents and attachments from a string representation, but this time to resolve object references and object properties references. Here they are : public ObjectReference resolveObject(String stringRepresentation) public ObjectReference resolveObject(String stringRepresentation, String hint, Object... parameters) public ObjectPropertyReference resolveObjectProperty(String stringRepresentation) public ObjectPropertyReference resolveObjectProperty(String stringRepresentation, String hint, Object... parameters) WDYT ? My +1 -- Jerome Velociter Winesquare http://www.winesquare.net/

13 years, 4 months

[xwiki-devs] About the merits of private static functions.

by Caleb James DeLisle

I have found that I like static private functions because they allow me to make promises about my code, making it more self explanatory and I was interested in opinions from others about it. It's not something I would want to force on other people but I would use it myself if people don't think it's too messy. Reasoning: A private method which does not touch any state of the is easy to review, it has no side channels to modify or access information so: #1 with the same inputs it will always give the same output. #2 it will not affect the world around it aside from it's inputs and output (no surprise side effects). By declaring the private method static, you make that promise and the compiler will hold you to it. As a reviewer I can let my guard down when looking at the code because it doesn't affect object state so it can't be the source of some types of bugs. The code is sandboxed so to speak. These assumptions do not hold true if static variables are used but I believe those should never be used unless absolutely necessary and when they are, code should be reviewed more closely anyway. Example: https://github.com/xwiki/xwiki-rendering/blob/master/xwiki-rendering-transf… If I were writing this now, I would be tempted to make these into static functions: private Block convertToDeepTree(Block sourceTree, String iconName) private void mergeTree(Block targetTree, Block sourceTree) private int indexOf(List<Block> targetBlocks, Block block) private boolean blockEquals(Block target, Block source) Anyone have any thoughts on this pattern? Caleb

13 years, 4 months

[xwiki-devs] [VOTE] Remove unnecessary javadoc for overriding methods

by Vincent Massol

Hi devs, I've just realized that using @override is enough to generate a proper javadoc copied from the overriden method and that checkstyle doesn't complain either. Basically instead of writing: /** * {@inheritDoc} * * @see org.xwiki.logging.LoggerManager#popLogListener() */ @Override public EventListener popLogListener() We can simply write: @Override public EventListener popLogListener() Advantages: 1) Less text to type and smaller class files 2) Less duplicated text I thus propose to use this from now and to progressively remove unnecessary javadoc in our legacy code. BTW this is also explained in the javadoc tool: See section "Automatic Reuse of Method Comments" in http://download.oracle.com/javase/1.3/docs/tooldocs/win32/javadoc.html WDYT? Here's my +1 Thanks -Vincent

13 years, 4 months

[xwiki-devs] [Proposal] New JIRA module in platform

by Vincent Massol

Guys, I should have sent this mail before pushing my changes but here it's just after the fact… Basically I've replaced xwiki-platform-swizzle with xwiki-platform-jira The details are on http://jira.xwiki.org/jira/browse/XWIKI-6879 I hope it's fine. My next step is to make it work with the extension manager (thomas M is on it) and to document it on extensions.xwiki.org. Thanks -Vincent

13 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs