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
[
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 resolut
[
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 d
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: M
[ 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
> ---
[
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 Ca
[
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
[
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
[
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 en
[
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
[
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
> ---
[ 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
> ---
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?
re
[ 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
> -
[ 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://issue
[ 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
> ---
>
>
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,
[ 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
>
[
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 m
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
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' Shou
[
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 n
[
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
23 matches
Mail list logo
