org.forgerock / org.forgerock.opendj

30 Jul, 2009

2 commits

29 Jul, 2009

6 commits

  • fc05a196   Fix for issue 4156. ... Browse Dir » 
    - Disconnect notifications are no longer sent when IO errors or client disconnects are encountered. 
- TLSByteChannel now  throws SSLException if SSLEngine.wrap did not produce any bytes.

git-svn-id: https://svn.forgerock.org/opendj/trunk@5617 41b1ffd8-f28e-4786-ab96-9950f0a78031
    boli
     
  • 3f87e9c7   Fix for issue 4155 (UI keystore does not handle properly certificates from the same host) ... Browse Dir » 
    If the provided certificate to be accepted in the key store is not already there, use a unique alias for the certificate.


git-svn-id: https://svn.forgerock.org/opendj/trunk@5616 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • ab853a3f   Fix typo. ... Browse Dir » 
    
git-svn-id: https://svn.forgerock.org/opendj/trunk@5615 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • 8c8d2b99   Fix for issue 4151 (Default java heap not enough to launch import) ... Browse Dir » 
    The idea is to improve what we currently have, which is relying on java ergonomics and only setting the '-client' and '-server' arguments as default java arguments.  As far as I can see with the new import code, the java ergonomics (this has been reproduced in Solaris and Mac OS X) are not enough to guarantee that the server will be able to make a small import (around 2000 entries) out of the box.

The proposed fix tries to set the following arguments to the server command-lines (start-ds and import-ldif in particular):

-Xms128m -Xmx256m

These arguments will be set if and only if:

They can be used while the setup is being run (and so the JVM supports them and the system where we are running is able to launch a JVM using them).

The ergonomics of the JVM where the setup is being run does not allocate a maximum heap that is higher than those values.  With this check we guarantee that we are not going to allocate less memory than what the JVM already does by default. 


git-svn-id: https://svn.forgerock.org/opendj/trunk@5614 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • 408bf0ac   Revert to previous version (committed inadvertently). ... Browse Dir » 
    
git-svn-id: https://svn.forgerock.org/opendj/trunk@5612 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • c3902e4c   Fix for issue 4152 (Graphical utilities should be consistent with command-line (… ... Browse Dir » 
    …admin connector certificate)
Load the admin-truststore when creating the keystore to be used by the graphical utilities.


git-svn-id: https://svn.forgerock.org/opendj/trunk@5611 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

28 Jul, 2009

1 commit

  • b930340d   Fix for issue 4148 (setup fails : The import LDIF tool returned error code 1) ... Browse Dir » 
    Since the import-ldif utility does not support any more (temporarily) the append option the setup (and the control-panel) were broken.

Temporarily the following modifications have been made in the control panel:
If the user decides to create data in the new base DN and there was already data in the backend, a confirmation dialog will be displayed informing that all the data will be overwritten.
The appending options in the Import LDIF panel have been hidden.

Concerning the setup, the modifications made are permanent.  What basically has been done is:
Use a single template LDIF file when the user decides to import automatically generated data.  Before this, one file per base DN was generated, which required the option 'append' to be used.  With a single file, no append is required.  This is a clearer solution, since I think that appending data affects to performance.
I have found some memory issues with the default ergonomics of the new import (see issue 4151).  Since some ergonomics issues may occur, the import is now launched in a separate process.  If we manage to improve the code that determines the default java arguments to be used for the import, this will help avoiding problems with the import.


git-svn-id: https://svn.forgerock.org/opendj/trunk@5610 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

27 Jul, 2009

5 commits

26 Jul, 2009

2 commits

25 Jul, 2009

1 commit

24 Jul, 2009

3 commits

23 Jul, 2009

3 commits

22 Jul, 2009

7 commits

21 Jul, 2009

1 commit

20 Jul, 2009

1 commit

17 Jul, 2009

1 commit

15 Jul, 2009

3 commits

14 Jul, 2009

2 commits

  • 3270c04f   Store the exception when reading replication monitoring information at the serve… ... Browse Dir » 
    …r descriptor level and not at the TopologyCache object level.


git-svn-id: https://svn.forgerock.org/opendj/trunk@5548 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • 56e9a98d   Follow up to fix for issue 4092 (dsreplication should allow to configure servers… ... Browse Dir » 
    … with no replication server and servers with only a replication server)

With the fix of 4092, the replication monitoring information for a given replication domain may not be anymore under cn=monitor of the server where the domain is configured.  The replication monitoring information is only under cn=monitor of the replication servers.

The following changes wait till all the configuration has been loaded and after that tries to find the replication monitoring information by only searching on the replication servers.  If the server does not calculate the whole cn=monitoring tree when a request is made to cn=monitor, the new code should be more efficient than the previous one (since only searching in one replication server should be enough).  If it is not the case and the whole cn=monitor is recalculated when a search is made on it, then the new code only adds a new search in most of the cases (the worst case is the one when there are disjoint replication topologies under the same ADS with different replication servers, which is pretty rare).


git-svn-id: https://svn.forgerock.org/opendj/trunk@5547 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

13 Jul, 2009

2 commits