30 Apr, 2015

1 commit


17 Apr, 2015

1 commit


06 Feb, 2015

2 commits

  • git-svn-id: https://svn.forgerock.org/opendj/trunk@11693 41b1ffd8-f28e-4786-ab96-9950f0a78031
    mark
     
  • This patch sets up an OpenDJ Reference,
    and moves all the reference content out of the OpenDJ Admin Guide. 
    
    This is preparation to move to using generated content
    as much as possible for the reference.
    This has the side effect of slimming down the OpenDJ Admin Guide,
    hopefully making it less imposing.
    
    This is part of OPENDJ-386 Move to single reference document.
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@11692 41b1ffd8-f28e-4786-ab96-9950f0a78031
    mark
     

04 Feb, 2015

2 commits


29 Jan, 2015

3 commits


27 Jan, 2015

3 commits


22 Jan, 2015

2 commits


20 Jan, 2015

1 commit


19 Jan, 2015

2 commits


12 Jan, 2015

1 commit


05 Jan, 2015

1 commit


03 Dec, 2014

1 commit


02 Dec, 2014

1 commit


01 Dec, 2014

1 commit


28 Nov, 2014

2 commits


26 Nov, 2014

1 commit


13 Nov, 2014

1 commit


12 Nov, 2014

1 commit


10 Nov, 2014

1 commit


05 Nov, 2014

1 commit

  • The ChangelogDBPurger is smart: when changes exist in the DB, it sleeps until the oldest change can be purged.
    The problem is that when admin changes the purge delay, the ChangelogDBPurger is not woken up to verify if the oldest change can be purged with the purge delay.
    This fix wakes up the ChangelogDBPurger when the purge delay changes.
    
    
    FileChangelogDB.java, JEChangelogDB.java:
    In setPurgeDelay(), ensured an existing ChangelogDBPurger is woken up by a change to the purge delay.
    Made purgeDelayInMillis volatile + In ChangelogDBPurger.run(), inlined jeFriendlySleep() to ensure the wait time is computed from the very latest purgeDelayInMillis.
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@11253 41b1ffd8-f28e-4786-ab96-9950f0a78031
    JnRouvignac
     

30 Oct, 2014

1 commit

  • The problem happens when doing a search in the change number changelog.
    It only appears when there are two replicas under the same domain.
    When creating the domain cursor, it is initialized from the content of the change number index DB. A replica cursor is created for each replica. The first replica cursor is initialized from the CSN coming from the change number index DB while the second replica cursor is initialized from the null CSN.
    Under this circumstance, the second replica cursor is immediately added to the exhausted cursors of the domain cursor, and never gets out of it despite its replica DB being not empty.
    The reason is because next() is never called on the the underlying ReplServerDBCursor.
    
    
    JEReplicaDBCursor.java:
    In next(), test whether the cursor has already been initialized (rather than verifying if a previous record exists) in order to verify if this is the first time next() is called.
    Removed currentChange field which duplicates the content of ReplServerDBCursor.currentRecord .
    Better handled the cursor closed state in all the methods.
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@11222 41b1ffd8-f28e-4786-ab96-9950f0a78031
    JnRouvignac
     

29 Oct, 2014

2 commits

  • git-svn-id: https://svn.forgerock.org/opendj/trunk@11218 41b1ffd8-f28e-4786-ab96-9950f0a78031
    JnRouvignac
     
  • 
    As pointed out by Ludo, problem is due to an API change in InternalClientConnection.processSearch() where LinkedHashSets parameters have been replaced with Set.
    Reverted revision r9082 which introduced the problem.
    
    Changed all client code to use LinkedHashSets instead of Sets.
    
    
    CollectionUtils.java:
    Added missing methods implemented in TestCaseUtils.
    
    TestCaseUtils.java, LDAPReplicationDomain.java:
    Removed generic methods creating collections.
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@11216 41b1ffd8-f28e-4786-ab96-9950f0a78031
    JnRouvignac
     

28 Oct, 2014

3 commits


23 Oct, 2014

1 commit


22 Oct, 2014

1 commit


21 Oct, 2014

2 commits

  • …eration against two replicated DS
    
    
    Fixed ConcurrentModificationException.
    I suspect the NoSuchElementException is thrown by the desugared foreach loop on an ArrayList.
    
    JEChangelogDB.java, FileChangelogDB.java:
    FOr the fields registeredDomainCursors and replicaCursors, replaced the use of ArrayList + synchronized keywords with using ConcurrentSkipListMap + CopyOnWriteArrayList to ensure thread safe access/modifications of these MultiMaps.
    Created putInMultiMap().
    Aligned code between the 2 implementations.
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@11167 41b1ffd8-f28e-4786-ab96-9950f0a78031
    JnRouvignac
     
  • git-svn-id: https://svn.forgerock.org/opendj/trunk@11165 41b1ffd8-f28e-4786-ab96-9950f0a78031
    JnRouvignac
     

15 Oct, 2014

1 commit