30 Mar, 2009

1 commit


28 Mar, 2009

2 commits


27 Mar, 2009

2 commits


26 Mar, 2009

10 commits


25 Mar, 2009

5 commits


24 Mar, 2009

4 commits


23 Mar, 2009

7 commits


20 Mar, 2009

4 commits


19 Mar, 2009

2 commits

  • …calhost" and hostname for --host1 and --host2
     
     In such cases the Replication Server were not detecting that they are already connected
    and was keeping trying to open new connection to each other Replication Server.
    
    The trick is simply to handle loopback and localhost addresses as equals. 
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@5113 41b1ffd8-f28e-4786-ab96-9950f0a78031
    gbellato
     
  • When doing a modrate on as DS where assured replication is not enabled, 
    if you enable assured replication (safe-data or safe-read) with dsconfig 
    at the same time, you may get some timeouts for some messages at the 
    beginning. This is due to the fact that new configuration values are set 
    (assured boolean set to true) before reconnection occurs. So messages 
    are fired in assured mode and then just after, the connection is broken 
    to reconnect with new configuration to the topology. This may make the 
    messages fired before reconnection fail in timeout.
    
    Fix: read new conf, disconnect, store new conf, reconnect
    
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@5112 41b1ffd8-f28e-4786-ab96-9950f0a78031
    mrossign
     

18 Mar, 2009

3 commits

  • 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@5111 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • There are a bunch of issues here:
    
    1. The server was not stopped after being started if it contains replicated data.
    2. The log files do not contain enough information.  New debug lines have been added.
    3. One of the problems also found is that one of the remote servers to be updated (to remove the replication references) could not be contacted.  This is the expected behavior if the option forceOnError is NOT specified.  However the error message was not very clear about what was happening.  The new error message is very explicit about this and informs the user of the existence and behavior of the forceOnError option.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@5110 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • git-svn-id: https://svn.forgerock.org/opendj/trunk@5109 41b1ffd8-f28e-4786-ab96-9950f0a78031
    ugaston