Re: [jr3 Microkernel] compiler settings in pom.xml

Hi,

>There *is* such things as immutable collections.

Actually, there are two kinds of immutable collections:

(a) read-only
(b) copy-on-write

For (a) Java has built-in support, while for (b) there is only
java.util.concurrent.CopyOnWrite*. For copy-on-write collections, usually
add and remove methods return a new collection. If we need more (b), such
as maps, we might want to add an external library or write our own (where
performance and memory usage is critical). But even then, we don't really
need a new programming language. Actually, there is a bit of (b) in the
Jackrabbit 3 sandbox already (org.apache.jackrabbit.mk.mem.NodeImpl,
methods createClone and cloneAnd*).

Regards,
Thomas

Versioning causing serious performance issues

Re: Versioning causing serious performance issues

On 2012-02-01 13:15, Peri Subrahmanya wrote:
> Dev,
>
> I have noticed versioning of nodes significantly reduces the
> performance. Please advise.
>
> Time taken to save 50k files (~5MB) using the *file datastore and
> OracleDBPersistenceManager was 30 minutes with versioning and 5 minutes
> without.*
> *
> *
> Thanks
> -PerIS

If these are all new nodes that are all put under version control this 
is hardly surprising; the actual number of nodes created is at least 
four times more.

Best regards, Julian

Re: Versioning causing serious performance issues

Thanks for the response. Makes sense.

On Feb 1, 2012, at 7:33 AM, Julian Reschke wrote:

> On 2012-02-01 13:15, Peri Subrahmanya wrote:
>> Dev,
>> 
>> I have noticed versioning of nodes significantly reduces the
>> performance. Please advise.
>> 
>> Time taken to save 50k files (~5MB) using the *file datastore and
>> OracleDBPersistenceManager was 30 minutes with versioning and 5 minutes
>> without.*
>> *
>> *
>> Thanks
>> -PerIS
> 
> If these are all new nodes that are all put under version control this is hardly surprising; the actual
number of nodes created is at least four times more.
> 
> Best regards, Julian

[Created] (JCR-3225) ConcurrentModificationException in QueryStatImpl

ConcurrentModificationException in QueryStatImpl
------------------------------------------------

                 Key: JCR-3225
                 URL: https://issues.apache.org/jira/browse/JCR-3225
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-core
    Affects Versions: 2.3.7, 2.3.6
            Reporter: Christan Keller

Running with qurystats enabled the Query#execute can throw ConcurrentModificationException

caused by the iterator which backing collection is changed from another thread

see logQuery method
        Iterator<QueryStatDtoImpl> iterator = popularQueries.iterator();
        while (iterator.hasNext()) {
-->            QueryStatDtoImpl qsdi = iterator.next();
            if (qsdi.equals(qs)) {
                qs.setOccurrenceCount(qsdi.getOccurrenceCount() + 1);
                iterator.remove();
                break;
            }
        }
        popularQueries.offer(qs);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Resolved] (JCR-3225) ConcurrentModificationException in QueryStatImpl

     [
https://issues.apache.org/jira/browse/JCR-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Parvulescu resolved JCR-3225.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 2.4

I wasn't able to see the ConcurrentModificationException, but I saw another one on #getPopularQueries: ArrayIndexOutOfBoundsException.
I added some synchronization code to the 2 methods.

Fixed in rev: 1240053.

                
> ConcurrentModificationException in QueryStatImpl
> ------------------------------------------------
>
>                 Key: JCR-3225
>                 URL: https://issues.apache.org/jira/browse/JCR-3225
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.3.6, 2.3.7
>            Reporter: Christan Keller
>             Fix For: 2.4
>
>
> Running with qurystats enabled the Query#execute can throw ConcurrentModificationException
> caused by the iterator which backing collection is changed from another thread
> see logQuery method
>         Iterator<QueryStatDtoImpl> iterator = popularQueries.iterator();
>         while (iterator.hasNext()) {
> -->            QueryStatDtoImpl qsdi = iterator.next();
>             if (qsdi.equals(qs)) {
>                 qs.setOccurrenceCount(qsdi.getOccurrenceCount() + 1);
>                 iterator.remove();
>                 break;
>             }
>         }
>         popularQueries.offer(qs);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Commented] (JCR-3225) ConcurrentModificationException in QueryStatImpl

    [
https://issues.apache.org/jira/browse/JCR-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199632#comment-13199632
] 

Jukka Zitting commented on JCR-3225:
------------------------------------

Merged to the 2.4 branch in revision 1240068.

> ConcurrentModificationException in QueryStatImpl
> ------------------------------------------------
>
>                 Key: JCR-3225
>                 URL: https://issues.apache.org/jira/browse/JCR-3225
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.3.6, 2.3.7
>            Reporter: Christan Keller
>             Fix For: 2.4
>
>
> Running with qurystats enabled the Query#execute can throw ConcurrentModificationException
> caused by the iterator which backing collection is changed from another thread
> see logQuery method
>         Iterator<QueryStatDtoImpl> iterator = popularQueries.iterator();
>         while (iterator.hasNext()) {
> -->            QueryStatDtoImpl qsdi = iterator.next();
>             if (qsdi.equals(qs)) {
>                 qs.setOccurrenceCount(qsdi.getOccurrenceCount() + 1);
>                 iterator.remove();
>                 break;
>             }
>         }
>         popularQueries.offer(qs);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Resolved] (JCR-3203) GroupImp#getMembers and #getDeclaredMembers should return RangeIterator

     [
https://issues.apache.org/jira/browse/JCR-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting resolved JCR-3203.
--------------------------------

    Resolution: Fixed

Resolving for 2.4 to get the change that was already made reflected in the release notes. Let's use followup
issues for further improvements.

> GroupImp#getMembers and #getDeclaredMembers should return RangeIterator
> -----------------------------------------------------------------------
>
>                 Key: JCR-3203
>                 URL: https://issues.apache.org/jira/browse/JCR-3203
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core, security
>            Reporter: angela
>            Priority: Minor
>             Fix For: 2.4
>
>
> for those cases where the total amount of members can easily be detected/calculated the
> implementations of Group#getMembers() and #getDeclaredMembersOf() should return a RangeIterator.
> so far i found that Group#declaredMembers() can be easily adjusted for those cases where
> the group members are stored in a multivalued property.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[VOTE] Release Apache Jackrabbit 2.4.0

Hi,

A candidate for the Jackrabbit 2.4.0 release is available at:

    http://people.apache.org/~jukka/jackrabbit/2.4.0/

The release candidate is a zip archive of the sources in:

    http://svn.apache.org/repos/asf/jackrabbit/tags/2.4.0/

The SHA1 checksum of the archive is ff9332ffb571ebd3b22717a8f30e4aa2c5e6d759.

A staged Maven repository is available for review at:

    https://repository.apache.org/content/repositories/orgapachejackrabbit-183/

The command for running automated checks against this release candidate is:

    $ sh check-release.sh jukka 2.4.0 ff9332ffb571ebd3b22717a8f30e4aa2c5e6d759

Please vote on releasing this package as Apache Jackrabbit 2.4.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

    [ ] +1 Release this package as Apache Jackrabbit 2.4.0
    [ ] -1 Do not release this package because...

My vote is +1.

BR,

Jukka Zitting

Re: [VOTE] Release Apache Jackrabbit 2.4.0

using check-release.sh:

+1

On 3.2.12 12:53, Jukka Zitting wrote:
> Hi,
>
> A candidate for the Jackrabbit 2.4.0 release is available at:
>
>      http://people.apache.org/~jukka/jackrabbit/2.4.0/
>
> The release candidate is a zip archive of the sources in:
>
>      http://svn.apache.org/repos/asf/jackrabbit/tags/2.4.0/
>
> The SHA1 checksum of the archive is ff9332ffb571ebd3b22717a8f30e4aa2c5e6d759.
>
> A staged Maven repository is available for review at:
>
>      https://repository.apache.org/content/repositories/orgapachejackrabbit-183/
>
> The command for running automated checks against this release candidate is:
>
>      $ sh check-release.sh jukka 2.4.0 ff9332ffb571ebd3b22717a8f30e4aa2c5e6d759
>
> Please vote on releasing this package as Apache Jackrabbit 2.4.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>      [ ] +1 Release this package as Apache Jackrabbit 2.4.0
>      [ ] -1 Do not release this package because...
>
> My vote is +1.
>
> BR,
>
> Jukka Zitting