<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/source/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in rebuild-index</title>
    <link>http://src.iws.cs.ovgu.de/source/rss/forgerock/opendj2/resource/bin/rebuild-index</link>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2005</copyright>
    <generator>Java</generator>
    <item>
        <title>Fix for OPENDJ-222 : Renamed environment variables to OPENDJ_...
    Updated scripts so that if OPENDJ_JAVA_HOME and OPENDJ_JAVA_ARGS are not defined, we look at the legacy OPENDS_... ones.</title>
        <description>/forgerock/opendj2/resource/bin/rebuild-index - 0f8553e2af5fc49a510ecfcfc93e66d06713f631</description>
        <pubDate></pubDate>
        <dc:creator>ludo</dc:creator>
    </item>

    <item>
        <title>Updated the copyright statement to reflect that Sun owns the full copyright on the project files.</title>
        <description>/forgerock/opendj2/resource/bin/rebuild-index - a3d3ab94806056d2355afea6fe8daac41059b9fb</description>
        <pubDate></pubDate>
        <dc:creator>ludovicp</dc:creator>
    </item>

    <item>
        <title>2730: New - The setup command should perform some basic memory tuning
    Note: this issue is not fully covered by the proposed modifications but
    all that is missing in order to fix it is to figure out which are the
    default memory values that we want to propose in the setup.
    
    2620: Server should be started as server JRE and clients should be
    started as client JREs
    
    The proposed solution goes beyond fixing the two issues and proposes a
    manner for the user to set specific java arguments (and use a specific
    JVM) for every command-line.
    
    Today the user can specify the JVM to be used using the OPENDS_JAVA_HOME
    environment variable and the java arguments by using the
    OPENDS_JAVA_ARGS environment variable.  In the case of the JVM this
    covers most of the use cases (in general we will use the same JVM for
    all the command-lines).  However this is quite limiting in the case of
    the java arguments we pass.  For instance in general we want to run the
    server (start-ds command-line) using the server mode of the JVM but
    other command-lines using the -client mode of the JVM.  In the same
    manner we might want to have a bigger heap when running the server than
    when we are running a "lightweight" utility as dsconfig.
    
    The proposed solution is to have a properties file called
    java.properties where the user specifies the different JVM and java
    arguments to be used for every command-line.  Once the user has edited
    this properties file, (s)he must run a command-line called
    dsjavaproperties that will update all the scripts to use the arguments
    specified in that properties file.
    
    NOTE: there are a number of command-lines (import-ldif, export-ldif,
    backup, restore) where the user will be able to specify different java
    arguments (and different JVM) to use depending on whether the
    command-line is run in online or offline modes.  You can see the
    comments on java.properties to get more information about this and in
    general about the different properties that can be set.
    
    The modification in the setup basically try to check if the JVM that is
    being used to run the setup (the one that will be used by default)
    supports the -client and -server options.  Depending on the results of
    these checks the setup will update the java.properties file and then run
    dsjavaproperties to update the scripts.</title>
        <description>/forgerock/opendj2/resource/bin/rebuild-index - 27f8adec83293fb8bd3bfa37175322b0ee3bb933</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Complete fix for 1252 restrict installed bin files to relevant platform.
    
    The bat files are only under 'bat' directory and some function scripts that are not targetted to be used by the user (_server-script, _client-script, etc.) have been moved now to lib.</title>
        <description>/forgerock/opendj2/resource/bin/rebuild-index - 9da44d3de0a7180285a77b7e8d2426a72aca249e</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Added the following capabilities to OpenDS:
    - Index rebuilding capabilities. All indexes including system and attribute indexes can
    be rebuilt. Each index will be rebuilt by a seperate thread to increase performance. A
    max number of rebuild threads could be set to limit the resources used by large rebuild
    jobs. Partial rebuilds of attribute indexes could also be done by specifying the
    attribute index type after the attribute type (ie. sn.approximate).
    - Index rebuilding standalone tool. Rebuilding of attribute indexes could be done with
    the backend online. However, rebuilds including system indexes must be done with the
    backend offline.
    - Index rebuilding task. Rebuilding of attribute indexes are done with the backend
    online. Rebuilds that include system indexes will be performed after bring the backend
    offline. The user must have index-rebuild privilages to rebuild indexes.
    - Approxitae indexing capability. The value of the attribute will be normalized using
    the approximate maching rule of that attribute type. This is used as the key for the
    index. Approximate indexes are fully supported by the index verify, rebuild, and import
    jobs.
    - Fixed bug in build.xml where weave is enabled even if a test.* property is set.
    - Consolidated some common tool messages.
    - Consolidated some JE backend methods common to all tools.
    - Added unit tests for rebuild job and approximate indexes.
    
    Fix for issues 35, 39, 40, 41</title>
        <description>/forgerock/opendj2/resource/bin/rebuild-index - 8d5d64c1542b43ea015b687d48b0d122d2a61e03</description>
        <pubDate></pubDate>
        <dc:creator>boli</dc:creator>
    </item>

</channel>
</rss>

