[jira] Commented: (JCR-688) Improve name resolution
[ http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12460349 ] Jukka Zitting commented on JCR-688: --- > The following test case executes 5 times faster with name caching Good point. :-) Digging deeper in the performance figures I noticed that most of this performance hit is caused by the heavy use of regexp matching in NameFormat. I was able to get a major performance gain simply by replacing the regexp's with custom parsing code (I'll clean it up attach as an example patch). The performance is still clearly worse than with caching, but not nearly as bad as before. Some other observations: * The performance requirements and expected data sets for the QName->String and String->QName conversions seem quite different. For example the above test case is almost entirely governed by the String->QName conversion speed. It would probably make sense to consider using separate mechanisms for the two types of conversions. * Moving the name cache from the global namespace registry to the session level would probably make sense. That would avoid the synchronization requirements at the expense of extra memory use. An extra benefit would be that the name cache could also be used when session-local namespace remappings are in effect. * The individual resolution operations are very fast in any case, so the performance is only relevant when doing a large number of operations. Thus the cost of occasional heavier optimization operations (if available) could probably be easily amortized. > Improve name resolution > --- > > Key: JCR-688 > URL: http://issues.apache.org/jira/browse/JCR-688 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.3 > > > As discussed in JCR-685, the current CachingNamespaceResolver class contains > excessive synchronization causing monitor contention that reduces performance. > In JCR-685 there's a proposed patch that replaces synchronization with a > read-write lock that would allow concurrent read access to the name cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-674) String properties with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-674?page=comments#action_12460345 ] Jukka Zitting commented on JCR-674: --- Agreed, the encoding of names is a separate issue. Actually a pretty tricky one... Please open a separate issue for property names and let's keep this issue focused on property values. > String properties with invalid XML characters export as invalid XML > --- > > Key: JCR-674 > URL: http://issues.apache.org/jira/browse/JCR-674 > Project: Jackrabbit > Issue Type: Bug > Components: xml >Affects Versions: 1.1.1 >Reporter: Joshua Levy > > As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1, > 6.4.2.6, XML export of string properties that contain invalid XML > characters isn't well-defined currently, since those characters are > not permissible in XML. The proposed fix is to use base64 > encoding for such values in System View. > Most characters below #x20 are examples of this. Currently, these > are escaped numerically in output (such as (amp)#0; ) but > such escape sequences can't be parsed by the XML > import methods. > The current behavior is particularly problematic, because the user > doesn't know the output is corrupt until later, when they try to import it > and get InvalidSerializedDataException. > If for some reason the base64 option is delayed, it might > make sense, as an interim solution, to fail on export > or to somehow patch import to relax its parsing and allow > these escape codes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release Management
Hi, On 12/21/06, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: do we have a development/release management paper that describes the usual dev tasks? See my recent messages along those lines, "Jira guidelines" from Nov 29th and "Future versions in Jira" from Dec 18th. Q: What 'Fix Version' Should i choose when solving a bug? See the emails I referred to above. Q: When i fix an issue, should i 'resolve' or 'close' it? "Resolve" it. There are two reasons not to "Close" it directly, one practical and one theoretical: practical: When preparing a release I try to fix issue metadata to make the Jira reports better. The metadata of a "Closed" issue can't be edited, so I need to explicitly reopen and then re-resolve it to make the metadata changes. theoretical: When you fix an issue, you've "resolved" it for yourself, but someone else might still have some problems with the fix. Only when the fix goes out in an official release should it be considered "closed". I'd even like to go as far as to mandate that "closed" issues should never be reopened as the released code can no longer be changed. Q: During Codefreeze, do i need to commit changes to trunk and frozen branch? Committing to trunk is always OK. Committing to a release branch is OK either if the release manager has explicitly OK'd it or if the issue implicitly qualifies for the branch as described in the "Fix Version" guidelines. It's also always OK *not* to commit changes to a release branch, as the release manager needs to in any case check for any pending changes in trunk that should go to a release. BR, Jukka Zitting
Re: svn commit: r489376 - in /jackrabbit/branches/1.2/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cluster: ClusterNode.java FileJournal.java FileRevision.java Journal.java RecordProcessor
Hi, On 12/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: dpfister Date: Thu Dec 21 06:42:28 2006 New Revision: 489376 URL: http://svn.apache.org/viewvc?view=rev&rev=489376 Log: JCR-623 - Clustering + Release write mutex when error occurs + Catch unexpected errors in synchronization listener + Add close() method to journal Modified: jackrabbit/branches/1.2/[...] Please do not commit stuff to the 1.2 branch unless there's a specific *new* issue that I've OK'd for the release. I'm trying to prepare the first release candidate and need to be aware of changes in the branch. More generally I'd suggest to open new issues and tag commits accordingly instead of reusing JCR-623 for additional fixes. Each of the three mentioned changes would IMHO warrant individual issues; two bug reports and one improvent request. Doing that would make the clustering work much more transparent as the rationale for the changes would be more explicit and the complete list of open and closed issues would be readily available. I'm going to let this one go as the changes only affect the new cluster classes, but please avoid similar commits in future. BR, Jukka Zitting
[jira] Commented: (JCR-689) Minimize calls to PersistenceManager
[ http://issues.apache.org/jira/browse/JCR-689?page=comments#action_12460286 ] Stefan Guggisberg commented on JCR-689: --- > With the patch applied the time to transiently create 1000 nodes with 4 > properties each drops from 1485 ms to 422 ms. excellent! :) +1 for the patch > Minimize calls to PersistenceManager > > > Key: JCR-689 > URL: http://issues.apache.org/jira/browse/JCR-689 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Affects Versions: 1.0, 1.0.1, 1.1, 0.9, 1.1.1 >Reporter: Marcel Reutegger >Priority: Minor > Attachments: NodeImpl-485720.patch > > > In some situations the PersistenceManager is called even though it is not > necessary. > E.g. when new items are created the method NodeImpl.getOrCreateProperty() > will always check if there is an already existing property state. If the node > is new the call will always go down the full item state stack and ask the > PersistenceManager if it knows the property id. This is unnessessary because > there will never exist properties in the persistence manager for a new node > that has not been saved yet. > I propose to add a check to the method to see if the node is new and does > not yet have a property with the given name. In that case the property can be > created without further checks. > With the patch applied the time to transiently create 1000 nodes with 4 > properties each drops from 1485 ms to 422 ms. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-689) Minimize calls to PersistenceManager
[ http://issues.apache.org/jira/browse/JCR-689?page=all ] Marcel Reutegger updated JCR-689: - Attachment: NodeImpl-485720.patch > Minimize calls to PersistenceManager > > > Key: JCR-689 > URL: http://issues.apache.org/jira/browse/JCR-689 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Affects Versions: 1.0, 1.0.1, 1.1, 0.9, 1.1.1 >Reporter: Marcel Reutegger >Priority: Minor > Attachments: NodeImpl-485720.patch > > > In some situations the PersistenceManager is called even though it is not > necessary. > E.g. when new items are created the method NodeImpl.getOrCreateProperty() > will always check if there is an already existing property state. If the node > is new the call will always go down the full item state stack and ask the > PersistenceManager if it knows the property id. This is unnessessary because > there will never exist properties in the persistence manager for a new node > that has not been saved yet. > I propose to add a check to the method to see if the node is new and does > not yet have a property with the given name. In that case the property can be > created without further checks. > With the patch applied the time to transiently create 1000 nodes with 4 > properties each drops from 1485 ms to 422 ms. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-689) Minimize calls to PersistenceManager
Minimize calls to PersistenceManager Key: JCR-689 URL: http://issues.apache.org/jira/browse/JCR-689 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.1.1, 1.1, 1.0.1, 1.0, 0.9 Reporter: Marcel Reutegger Priority: Minor Attachments: NodeImpl-485720.patch In some situations the PersistenceManager is called even though it is not necessary. E.g. when new items are created the method NodeImpl.getOrCreateProperty() will always check if there is an already existing property state. If the node is new the call will always go down the full item state stack and ask the PersistenceManager if it knows the property id. This is unnessessary because there will never exist properties in the persistence manager for a new node that has not been saved yet. I propose to add a check to the method to see if the node is new and does not yet have a property with the given name. In that case the property can be created without further checks. With the patch applied the time to transiently create 1000 nodes with 4 properties each drops from 1485 ms to 422 ms. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-687) UUID compareTo and hashCode
[ http://issues.apache.org/jira/browse/JCR-687?page=all ] Tobias Bocanegra resolved JCR-687. -- Fix Version/s: 1.2 Resolution: Fixed Committed revision 489369 to trunk > UUID compareTo and hashCode > --- > > Key: JCR-687 > URL: http://issues.apache.org/jira/browse/JCR-687 > Project: Jackrabbit > Issue Type: Bug > Components: core >Reporter: Thomas Mueller > Assigned To: Tobias Bocanegra >Priority: Minor > Fix For: 1.2 > > Attachments: uuid.txt > > > The current UUID.compareTo implementation is not correct. Usually, 'equals' > is used so this is not a big problem, but I need to create an ordered list of > UUIDs and for this I need compareTo. The current implementation is based on > subtraction, but this doesn't always work. Example: > //long a = 10, b = 20, c = 0; > long a = Long.MAX_VALUE, b = Long.MIN_VALUE, c = 0; > System.out.println((a - b) < 0 ? "a < b" : "a >= b"); > System.out.println((c - a) < 0 ? "c < a" : "c >= a"); > System.out.println((b - c) < 0 ? "b < c" : "b >= c"); > The hashCode implementation is OK, but the multiplication is not required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-687) UUID compareTo and hashCode
[ http://issues.apache.org/jira/browse/JCR-687?page=all ] Tobias Bocanegra reassigned JCR-687: Assignee: Tobias Bocanegra > UUID compareTo and hashCode > --- > > Key: JCR-687 > URL: http://issues.apache.org/jira/browse/JCR-687 > Project: Jackrabbit > Issue Type: Bug > Components: core >Reporter: Thomas Mueller > Assigned To: Tobias Bocanegra >Priority: Minor > Attachments: uuid.txt > > > The current UUID.compareTo implementation is not correct. Usually, 'equals' > is used so this is not a big problem, but I need to create an ordered list of > UUIDs and for this I need compareTo. The current implementation is based on > subtraction, but this doesn't always work. Example: > //long a = 10, b = 20, c = 0; > long a = Long.MAX_VALUE, b = Long.MIN_VALUE, c = 0; > System.out.println((a - b) < 0 ? "a < b" : "a >= b"); > System.out.println((c - a) < 0 ? "c < a" : "c >= a"); > System.out.println((b - c) < 0 ? "b < c" : "b >= c"); > The hashCode implementation is OK, but the multiplication is not required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-686) change some access-level modifiers to allow for better subclassing
[ http://issues.apache.org/jira/browse/JCR-686?page=all ] Tobias Bocanegra resolved JCR-686. -- Resolution: Fixed Committed revision 489363 to trunk. > change some access-level modifiers to allow for better subclassing > -- > > Key: JCR-686 > URL: http://issues.apache.org/jira/browse/JCR-686 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Affects Versions: 0.9, 1.2 >Reporter: Tobias Bocanegra > Assigned To: Tobias Bocanegra >Priority: Minor > Fix For: 1.2 > > Attachments: JCR-686.488670.patch > > > Some of the methods in the core parts of jackrabbit are package protected and > do not allow easy subclassing. suggest to make some of the methods > 'protected'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Release Management
Hi jukka, do we have a development/release management paper that describes the usual dev tasks? eg: Q: What 'Fix Version' Should i choose when solving a bug? Q: When i fix an issue, should i 'resolve' or 'close' it? Q: During Codefreeze, do i need to commit changes to trunk and frozen branch? regards, toby -- -< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 ---< http://www.day.com >---
[jira] Updated: (JCR-686) change some access-level modifiers to allow for better subclassing
[ http://issues.apache.org/jira/browse/JCR-686?page=all ] Tobias Bocanegra updated JCR-686: - Fix Version/s: 1.2 (was: 1.2.1) > change some access-level modifiers to allow for better subclassing > -- > > Key: JCR-686 > URL: http://issues.apache.org/jira/browse/JCR-686 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Affects Versions: 0.9, 1.2 >Reporter: Tobias Bocanegra > Assigned To: Tobias Bocanegra >Priority: Minor > Fix For: 1.2 > > Attachments: JCR-686.488670.patch > > > Some of the methods in the core parts of jackrabbit are package protected and > do not allow easy subclassing. suggest to make some of the methods > 'protected'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-686) change some access-level modifiers to allow for better subclassing
[ http://issues.apache.org/jira/browse/JCR-686?page=comments#action_12460273 ] Tobias Bocanegra commented on JCR-686: -- the sooner the better :-) so 1.2 then. > change some access-level modifiers to allow for better subclassing > -- > > Key: JCR-686 > URL: http://issues.apache.org/jira/browse/JCR-686 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Affects Versions: 0.9, 1.2 >Reporter: Tobias Bocanegra > Assigned To: Tobias Bocanegra >Priority: Minor > Fix For: 1.2 > > Attachments: JCR-686.488670.patch > > > Some of the methods in the core parts of jackrabbit are package protected and > do not allow easy subclassing. suggest to make some of the methods > 'protected'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-688) Improve name resolution
[
http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12460272 ]
Marcel Reutegger commented on JCR-688:
--
One example is regularly accessing properties with the same name. In an
application you will usually have a fixed set of property names (unless you use
residual properties).
The following test case executes 5 times faster with name caching:
public void testPropertyAccess() throws RepositoryException {
for (int i = 0; i < 100; i++) {
testRootNode.addNode("node" + i);
}
testRootNode.save();
long time = System.currentTimeMillis();
// loop 1000 times over child nodes and access two properties
for (int i = 0; i < 1000; i++) {
for (NodeIterator it = testRootNode.getNodes(); it.hasNext(); ) {
Node n = it.nextNode();
n.getProperty(jcrPrimaryType);
n.hasProperty(jcrMixinTypes);
}
}
time = System.currentTimeMillis() - time;
System.out.println("test took: " + time + " ms.");
}
> Improve name resolution
> ---
>
> Key: JCR-688
> URL: http://issues.apache.org/jira/browse/JCR-688
> Project: Jackrabbit
> Issue Type: Improvement
> Components: core
>Reporter: Jukka Zitting
>Priority: Minor
> Fix For: 1.3
>
>
> As discussed in JCR-685, the current CachingNamespaceResolver class contains
> excessive synchronization causing monitor contention that reduces performance.
> In JCR-685 there's a proposed patch that replaces synchronization with a
> read-write lock that would allow concurrent read access to the name cache.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-674) String properties with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-674?page=comments#action_12460262 ] Jan Kuzniak commented on JCR-674: - One more thought: maybe we should split this issue into 2: - leave values encoding (to base64) here, - create new issue for names encoding in Session.exportSystemView. What do you think about it? > String properties with invalid XML characters export as invalid XML > --- > > Key: JCR-674 > URL: http://issues.apache.org/jira/browse/JCR-674 > Project: Jackrabbit > Issue Type: Bug > Components: xml >Affects Versions: 1.1.1 >Reporter: Joshua Levy > > As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1, > 6.4.2.6, XML export of string properties that contain invalid XML > characters isn't well-defined currently, since those characters are > not permissible in XML. The proposed fix is to use base64 > encoding for such values in System View. > Most characters below #x20 are examples of this. Currently, these > are escaped numerically in output (such as (amp)#0; ) but > such escape sequences can't be parsed by the XML > import methods. > The current behavior is particularly problematic, because the user > doesn't know the output is corrupt until later, when they try to import it > and get InvalidSerializedDataException. > If for some reason the base64 option is delayed, it might > make sense, as an interim solution, to fail on export > or to somehow patch import to relax its parsing and allow > these escape codes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-688) Improve name resolution
[ http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12460243 ] Jukka Zitting commented on JCR-688: --- Is the cache even required? It seems to me that the operations that we try to speed up using the cache are very small and fast in any case, i.e. simple string parsing and concatenation. Sure, it adds up to a large number of short-lived object allocations, but a generational garbage collector shouldn't have much trouble handling that. Do we have some performance numbers to validate the need for caching in this case? > Improve name resolution > --- > > Key: JCR-688 > URL: http://issues.apache.org/jira/browse/JCR-688 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.3 > > > As discussed in JCR-685, the current CachingNamespaceResolver class contains > excessive synchronization causing monitor contention that reduces performance. > In JCR-685 there's a proposed patch that replaces synchronization with a > read-write lock that would allow concurrent read access to the name cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-674) String properties with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-674?page=comments#action_12460227 ] Jan Kuzniak commented on JCR-674: - Hello there! After short investigation we at Cognifide think that we know what the problem is :-) Not only values that should be base64 are not exported, but also node and property names that have invalid characters in it (e.g. most characters below 0x0020) are exported using entities (that is still invalid). We are currently implementing patch for the first issue (base64). And a little more about invalid node/property names: it seems like the difference lies between Session.exportDocumentView and Session.exportSystemView. The first one seems to be doing it correctly. However the second does not use ISO9075 class that is responsible for encoding. Simply connecting exportSystemView to ISO9075 should make it (we are also going to implement this). Any comments on this approach? Patch is coming soon (we hope). -- Regards, Liliana and Jan > String properties with invalid XML characters export as invalid XML > --- > > Key: JCR-674 > URL: http://issues.apache.org/jira/browse/JCR-674 > Project: Jackrabbit > Issue Type: Bug > Components: xml >Affects Versions: 1.1.1 >Reporter: Joshua Levy > > As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1, > 6.4.2.6, XML export of string properties that contain invalid XML > characters isn't well-defined currently, since those characters are > not permissible in XML. The proposed fix is to use base64 > encoding for such values in System View. > Most characters below #x20 are examples of this. Currently, these > are escaped numerically in output (such as (amp)#0; ) but > such escape sequences can't be parsed by the XML > import methods. > The current behavior is particularly problematic, because the user > doesn't know the output is corrupt until later, when they try to import it > and get InvalidSerializedDataException. > If for some reason the base64 option is delayed, it might > make sense, as an interim solution, to fail on export > or to somehow patch import to relax its parsing and allow > these escape codes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-688) Improve name resolution
[ http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12460221 ] Marcel Reutegger commented on JCR-688: -- I have to apologize, my post in JCR-685 was not precise enough. What acutally happens when multiple threads access the CachingNamespaceResolver is the following: because even a get() call on the LRUMap modifies the internal data structures those calls must be synchronized. This basically serializes access on the LRUMap even though only a small critical section should be synchronized: the method moveToMRU(). Calculating the hash code, doing the lookup in the hashtable and checking whether the keys are equal does not require synchronization and multiple threads can do this concurrently. I agree that this does not necessarily have to go into the 1.2 release, but it certainly is a problem, because the CachingNamespaceResolver in the NamespaceRegistry is a single instance repository wide and used by all threads that access the repository. Since name resolution is involved in nearly every operation I think it should allow maximum concurrent threads. It is correct that the proposed change will not lower the number of synchronized sections but the sections will be significantly smaller. So to be precise this improvement is not really to avoid monitor contention but to allow more concurrent access to the CachingNamespaceResolver. > Improve name resolution > --- > > Key: JCR-688 > URL: http://issues.apache.org/jira/browse/JCR-688 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.3 > > > As discussed in JCR-685, the current CachingNamespaceResolver class contains > excessive synchronization causing monitor contention that reduces performance. > In JCR-685 there's a proposed patch that replaces synchronization with a > read-write lock that would allow concurrent read access to the name cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-685) Remove some synchronization on CachingNamespaceResolver
[ http://issues.apache.org/jira/browse/JCR-685?page=all ]
Jukka Zitting resolved JCR-685.
---
Resolution: Fixed
Resolved. Please continue discussion on the core issue in JCR-688.
> Remove some synchronization on CachingNamespaceResolver
> ---
>
> Key: JCR-685
> URL: http://issues.apache.org/jira/browse/JCR-685
> Project: Jackrabbit
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.1, 1.1.1
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.2
>
> Attachments: CachingNamespaceResolver.patch
>
>
> The methods getQName() and getJCRName() are unnecessarily synchronized and
> cause monitor contention with concurrent calls to the methods of the
> NameCache interface (those are also synchronized).
> I propose the following change:
> Index: CachingNamespaceResolver.java
> ===
> --- CachingNamespaceResolver.java (revision 488245)
> +++ CachingNamespaceResolver.java (working copy)
> @@ -84,7 +84,7 @@
> /**
> * @deprecated use [EMAIL PROTECTED] NameFormat#parse(String,
> NamespaceResolver)}
> */
> -public synchronized QName getQName(String name)
> +public QName getQName(String name)
> throws IllegalNameException, UnknownPrefixException {
> return NameFormat.parse(name, this);
> }
> @@ -92,7 +92,7 @@
> /**
> * @deprecated use [EMAIL PROTECTED] NameFormat#format(QName,
> NamespaceResolver)}
> */
> -public synchronized String getJCRName(QName name)
> +public String getJCRName(QName name)
> throws NoPrefixDeclaredException {
> return NameFormat.format(name, this);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-688) Improve name resolution
Improve name resolution --- Key: JCR-688 URL: http://issues.apache.org/jira/browse/JCR-688 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Jukka Zitting Priority: Minor Fix For: 1.3 As discussed in JCR-685, the current CachingNamespaceResolver class contains excessive synchronization causing monitor contention that reduces performance. In JCR-685 there's a proposed patch that replaces synchronization with a read-write lock that would allow concurrent read access to the name cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-685) Remove some synchronization on CachingNamespaceResolver
[
http://issues.apache.org/jira/browse/JCR-685?page=comments#action_12460195 ]
Jukka Zitting commented on JCR-685:
---
> i'd rather leave this issue open, the core issue (monitor contention with
> concurrent read access)
> still exists a thread dumps show.
>
> the committed fix affected deprecated methods only and doesn't solve the core
> issue.
The issue title and description only mention the deprecated methods. I'd rather
open a separate issue with a better description of the core problem.
Additionally, from the release and Jira management perspective it's troublesome
to have issues that are "partially fixed" in a release.
> Remove some synchronization on CachingNamespaceResolver
> ---
>
> Key: JCR-685
> URL: http://issues.apache.org/jira/browse/JCR-685
> Project: Jackrabbit
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.1, 1.1.1
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.2
>
> Attachments: CachingNamespaceResolver.patch
>
>
> The methods getQName() and getJCRName() are unnecessarily synchronized and
> cause monitor contention with concurrent calls to the methods of the
> NameCache interface (those are also synchronized).
> I propose the following change:
> Index: CachingNamespaceResolver.java
> ===
> --- CachingNamespaceResolver.java (revision 488245)
> +++ CachingNamespaceResolver.java (working copy)
> @@ -84,7 +84,7 @@
> /**
> * @deprecated use [EMAIL PROTECTED] NameFormat#parse(String,
> NamespaceResolver)}
> */
> -public synchronized QName getQName(String name)
> +public QName getQName(String name)
> throws IllegalNameException, UnknownPrefixException {
> return NameFormat.parse(name, this);
> }
> @@ -92,7 +92,7 @@
> /**
> * @deprecated use [EMAIL PROTECTED] NameFormat#format(QName,
> NamespaceResolver)}
> */
> -public synchronized String getJCRName(QName name)
> +public String getJCRName(QName name)
> throws NoPrefixDeclaredException {
> return NameFormat.format(name, this);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-685) Remove some synchronization on CachingNamespaceResolver
[
http://issues.apache.org/jira/browse/JCR-685?page=comments#action_12460192 ]
Stefan Guggisberg commented on JCR-685:
---
> I suggest to resolve this issue as currently committed, and to open a
> separate issue for improving the name resolution performance for Jackrabbit
> 1.3.
i'd rather leave this issue open, the core issue (monitor contention with
concurrent read access) still exists a thread dumps show.
the committed fix affected deprecated methods only and doesn't solve the core
issue.
> Remove some synchronization on CachingNamespaceResolver
> ---
>
> Key: JCR-685
> URL: http://issues.apache.org/jira/browse/JCR-685
> Project: Jackrabbit
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.1, 1.1.1
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.2
>
> Attachments: CachingNamespaceResolver.patch
>
>
> The methods getQName() and getJCRName() are unnecessarily synchronized and
> cause monitor contention with concurrent calls to the methods of the
> NameCache interface (those are also synchronized).
> I propose the following change:
> Index: CachingNamespaceResolver.java
> ===
> --- CachingNamespaceResolver.java (revision 488245)
> +++ CachingNamespaceResolver.java (working copy)
> @@ -84,7 +84,7 @@
> /**
> * @deprecated use [EMAIL PROTECTED] NameFormat#parse(String,
> NamespaceResolver)}
> */
> -public synchronized QName getQName(String name)
> +public QName getQName(String name)
> throws IllegalNameException, UnknownPrefixException {
> return NameFormat.parse(name, this);
> }
> @@ -92,7 +92,7 @@
> /**
> * @deprecated use [EMAIL PROTECTED] NameFormat#format(QName,
> NamespaceResolver)}
> */
> -public synchronized String getJCRName(QName name)
> +public String getJCRName(QName name)
> throws NoPrefixDeclaredException {
> return NameFormat.format(name, this);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Balancing Jackrabbit
Hi Javier, On 12/20/06, Javier Aparicio Conesa <[EMAIL PROTECTED]> wrote: Hi guys! Both jackrabbit_server instances (there are really jlibrary instances) are sharing a clusterized mysql database (NDB mode). If your instances share the same backend, one instance will overwrite the changes made by the other instance, which is probably not what you want. I've read something about one closed Jira which may solve my problem (https://issues.apache.org/jira/browse/JCR-623), It's fixed in jackrabbit 1.2 Yes, this will solve your problem. Writes to the backend are synchronized, and all participating instances are notified about changes made by some instance. Is planned some date for that jackrabbit release? It should be quite soon! Kind regards Dominique
