James Moger
2014-09-30 2365822625a0a46b2d25f83b698801cd18e811c0
Merged #201 "Remove git.streamFileThreshold setting"
4 files modified
54 ■■■■■ changed files
src/main/distrib/data/gitblit.properties 48 ●●●●● patch | view | raw | blame | history
src/main/java/com/gitblit/manager/RepositoryManager.java 2 ●●●●● patch | view | raw | blame | history
src/site/setup_go.mkd 1 ●●●● patch | view | raw | blame | history
src/site/setup_war.mkd 3 ●●●● patch | view | raw | blame | history
src/main/distrib/data/gitblit.properties
@@ -425,54 +425,6 @@
# RESTART REQUIRED
git.packedGitOpenFiles = 128
# Largest object size, in bytes, that JGit will allocate as a contiguous byte
# array. Any file revision larger than this threshold will have to be streamed,
# typically requiring the use of temporary files under $GIT_DIR/objects to implement
# psuedo-random access during delta decompression.
#
# Servers with very high traffic should set this to be larger than the size of
# their common big files. For example a server managing the Android platform
# typically has to deal with ~10-12 MiB XML files, so 15 m would be a reasonable
# setting in that environment. Setting this too high may cause the JVM to run out
# of heap space when handling very big binary files, such as device firmware or
# CD-ROM ISO images. Make sure to adjust your JVM heap accordingly.
#
# Default is 50 MiB on all platforms.
#
# Common unit suffixes of k, m, or g are supported.
# Documentation courtesy of the Gerrit project.
#
#
# NOTE: The importance of JGit's streamFileTreshold AND Git's bigFileThreshold
# ISSUE: https://bugs.eclipse.org/bugs/show_bug.cgi?id=394078
#
# "core.bigFileThreshold
#
#    Files larger than this size are stored deflated, without
#    attempting delta compression.  Storing large files without
#    delta compression avoids excessive memory usage, at the
#    slight expense of increased disk usage.
#
#  Default is 512 MiB on all platforms.
#  This should be reasonable for most projects as source code and other
#  text files can still be delta compressed,
#  but larger binary media files won't be."
#  -- Git documentation
#
# If streamFileTreshold < bigFileTreshold you _may_ spend alot of time waiting
# for push and/or fetch to complete.  It may even look hung.
#
# Until the issue is resolved gracefully, a workaround is to configure
# bigFileThreshold < streamFileTreshold AND then repack the repository.
#
# e.g. from the repository folder with Gitblit NOT running:
#     git config core.bigFileTreshold 40m
#     git gc --aggressive
#
# SINCE 1.0.0
# RESTART REQUIRED
git.streamFileThreshold = 50m
# When true, JGit will use mmap() rather than malloc()+read() to load data from
# pack files.  The use of mmap can be problematic on some JVMs as the garbage
# collector must deduce that a memory mapped segment is no longer in use before
src/main/java/com/gitblit/manager/RepositoryManager.java
@@ -1902,7 +1902,6 @@
        cfg.setPackedGitLimit(settings.getFilesize(Keys.git.packedGitLimit, cfg.getPackedGitLimit()));
        cfg.setDeltaBaseCacheLimit(settings.getFilesize(Keys.git.deltaBaseCacheLimit, cfg.getDeltaBaseCacheLimit()));
        cfg.setPackedGitOpenFiles(settings.getFilesize(Keys.git.packedGitOpenFiles, cfg.getPackedGitOpenFiles()));
        cfg.setStreamFileThreshold(settings.getFilesize(Keys.git.streamFileThreshold, cfg.getStreamFileThreshold()));
        cfg.setPackedGitMMAP(settings.getBoolean(Keys.git.packedGitMmap, cfg.isPackedGitMMAP()));
        try {
@@ -1911,7 +1910,6 @@
            logger.debug(MessageFormat.format("{0} = {1,number,0}", Keys.git.packedGitLimit, cfg.getPackedGitLimit()));
            logger.debug(MessageFormat.format("{0} = {1,number,0}", Keys.git.deltaBaseCacheLimit, cfg.getDeltaBaseCacheLimit()));
            logger.debug(MessageFormat.format("{0} = {1,number,0}", Keys.git.packedGitOpenFiles, cfg.getPackedGitOpenFiles()));
            logger.debug(MessageFormat.format("{0} = {1,number,0}", Keys.git.streamFileThreshold, cfg.getStreamFileThreshold()));
            logger.debug(MessageFormat.format("{0} = {1}", Keys.git.packedGitMmap, cfg.isPackedGitMMAP()));
        } catch (IllegalArgumentException e) {
            logger.error("Failed to configure JGit parameters!", e);
src/site/setup_go.mkd
@@ -8,7 +8,6 @@
    - *server.storePassword* (do not enter *#* characters)
    **https** is strongly recommended because passwords are insecurely transmitted form your browser/git client using Basic authentication!
    - *git.packedGitLimit* (set larger than the size of your largest repository)
    - *git.streamFileThreshold* (set larger than the size of your largest committed file)
3. Execute `authority.cmd` or `java -cp gitblit.jar com.gitblit.authority.Launcher --baseFolder data` from a command-line
**NOTE:** The Authority is a Swing GUI application.  Use of this tool is not required as Gitblit GO will startup and create SSL certificates itself, BUT use of this tool allows you to control the identification metadata used in the generated certificates.  Skipping this step will result in certificates with default metadata.
    1. fill out the fields in the *new certificate defaults* dialog
src/site/setup_war.mkd
@@ -4,8 +4,7 @@
2. You may have to manually extract the WAR (zip file) to a folder within your webapps folder.
3. By default, the Gitblit webapp is configured through `WEB-INF/data/gitblit.properties`.
Open `WEB-INF/data/gitblit.properties` in your favorite text editor and make sure to review and set:
    - &lt;context-parameter&gt; *git.packedGitLimit* (set larger than the size of your largest repository)
    - &lt;context-parameter&gt; *git.streamFileThreshold* (set larger than the size of your largest committed file)
    - *git.packedGitLimit* (set larger than the size of your largest repository)
4. You may have to restart your servlet container. 
5. Open your browser to <http://localhost/gitblit> or whatever the url should be.
6. Enter the default administrator credentials: **admin / admin** and click the *Login* button