FishEye upgrade guide

This page describes how to upgrade to a new version of FishEye. We strongly recommend that you update FishEye by performing the steps below.

Note that:

  • This update process does not perform an in-place upgrade, but installs the new version of FishEye into a fresh installation directory. The new FishEye uses your existing FishEye install directory and external database.
  • For production environments we recommend that you test the FishEye update on a QA server before deploying to production.

If you want to migrate FishEye, as well as upgrade, see Migrating and Upgrading FishEye/Crucible.

1. Review the upgrade notes

There are specific upgrade notes further down this page for each version of FishEye. 

You should read the relevant sections for each version between your current version of FishEye and the version you are upgrading to.

2. Backup your FishEye data

Back up your entire FishEye instance (see Backing up and restoring FishEye data):

  • If you are backing up your FishEye instance using the Admin interface, tick all of the 'Include' checkboxes (e.g. repository and application caches, plugins and their configuration data, SQL database, etc).
  • If you are backing up your FishEye instance using the command-line interface, do not use any exclusion options.

3. Stop FishEye

In a terminal, change directory to the <FishEye install directory> and run this:

4. Install FishEye

This update process does not perform an in-place upgrade, but installs the new version of FishEye into a fresh install directory. The new FishEye uses your existing FishEye data (FISHEYE_INST) directory and external database.

Download the FishEye zip file. On Windows, download the installer. See Installing FishEye on Linux and Mac or Installing FishEye on Windows for detailed installation instructions.

Your upgrade procedure depends on whether you are using a FISHEYE_INST directory (i.e. "FishEye instance" directory).

  • The FISHEYE_INST directory is the FishEye data directory (not the installation directory) and has a location defined by the FISHEYE_INST environment variable. It is used to keep the FishEye data completely separate from the FishEye/Crucible application files. We recommend that you configure FishEye/Crucible to use a FISHEYE_INST directory for production instances. Read more about FISHEYE_INST in Installing FishEye on Windows or Installing FishEye on Linux and Mac.
  • The <FishEye home directory> is the location of the FishEye/Crucible application files.
Method 1: Using a FISHEYE_INST directory
  Click here to expand...

If you have FishEye/Crucible configured to use a FISHEYE_INST directory, then follow the instructions below. This is the recommended scenario for production installations.

  1. Shut down your existing FishEye/Crucible server, using bin\stop.bat or bin\stop.sh from the <FishEye home directory>.
  2. Make a backup of your FISHEYE_INST directory.
  3. Download FishEye or Crucible.
  4. Extract the new FishEye/Crucible version to a new directory.
  5. Leave your FISHEYE_INST environment variable set to its existing location. Both FishEye and Crucible use this variable.
    • Please be aware that jar files in the FISHEYE_INST/lib directory may conflict with those required for FishEye's normal operation. Jar files in this directory should be limited to those which provide functionality not provided by FishEye (e.g. database drivers).
  6. Start FishEye/Crucible from the new installation directory by running bin/run.sh. (Use run.bat on Windows.)
  7. Follow any version-specific instructions found in the FishEye upgrade guide or Crucible upgrade guide.
Method 2: Without a FISHEYE_INST directory
  Click here to expand...

If you do not have FishEye/Crucible configured to use a FISHEYE_INST directory and do not want to set one up, then follow the instructions below. The <FishEye home directory> is the location of the existing FishEye/Crucible installation. Note that this is the typical scenario for evaluation installations, and is not recommended for production installations.

You will need to copy some files from your old FishEye/Crucible installation to your new one.

  1. Download FishEye or Crucible.
  2. Extract the new FishEye/Crucible archive into a directory such as <New FishEye home directory>.
  3. Shut down the old FishEye/Crucible server, using bin\stop.bat or bin\stop.sh from the <FishEye home directory>.
  4. Copy <FishEye home directory>/config.xml to <New FishEye home directory>.
  5. Delete the following directories from the <New FishEye home directory>/var directory:
    • <New FishEye home directory>/var/cache
    • <New FishEye home directory>/var/data
    • <New FishEye home directory>/var/log
  6. Copy (or move) the following directories from <FishEye home directory>/var to <New FishEye home directory>/var:
    • <FishEye home directory>/var/cache
    • <FishEye home directory>/var/data
    • <FishEye home directory>/var/log
    DO NOT include the following directories when you do that:
    • <FishEye home directory>/var/osgi-cache
    • <FishEye home directory>/var/plugins
    • <FishEye home directory>/var/tmp
  7. Delete the <New FishEye home directory>/cache directory.
  8. Copy (or move) the <FishEye home directory>/cache directory to <New FishEye home directory>/cache.
  9. Start FishEye/Crucible from the new installation by running <New FishEye home directory>/bin/run.sh. (Use run.bat on Windows.)
  10. Follow any version-specific instructions found in the FishEye upgrade guide  or Crucible upgrade guide.
Method 3: Without a FISHEYE_INST directory, but would like to set one up
  Click here to expand...

If you do not have FishEye/Crucible configured to use a FISHEYE_INST directory but would like to set one up, then follow the instructions below. You may wish to do this when reconfiguring an existing installation for a production environment.

The FISHEYE_INST directory is the FishEye data directory, which has a location defined by the FISHEYE_INST environment variable, and which should be completely separate from the <FishEye home directory>. The <FishEye home directory> is the location of the existing FishEye/Crucible installation.

  1. Download FishEye or Crucible.
  2. Shut down the existing FishEye/Crucible server, using bin\stop.bat or bin\stop.sh from the <FishEye home directory>.
  3. Set up the FISHEYE_INST environment variable, then create the FISHEYE_INST directory on your file system.
  4. Copy <FishEye home directory>/config.xml to the FISHEYE_INST directory.
  5. Copy the <FishEye home directory>/var directory to the FISHEYE_INST directory.
  6. Copy the <FishEye home directory>/cache directory to the FISHEYE_INST directory.
  7. If it exists, copy the <FishEye home directory>/data directory to the FISHEYE_INST directory.
  8. Extract the new FishEye/Crucible archive into a directory such as <New FishEye home directory>.
  9. Start FishEye/Crucible from the new installation by running <New FishEye home directory>/bin/run.sh. (Use run.bat on Windows.)
    • If your configuration is not automatically picked up and you cannot see your existing repositories, check your Administration > Sys-Info page, where you will see information about the <FishEye home directory> and FISHEYE_INST. Check that your FISHEYE_INST is pointing to the right directory.
  10. Follow any version-specific instructions found in the FishEye upgrade guide  or Crucible upgrade guide.
Method 4: Using the FishEye Installer for Windows
  Click here to expand...

Using a FISHEYE_INST directory (including when previously running as a Windows Service using the wrapper)

  Click here to expand...

If you have FishEye/Crucible configured to use a FISHEYE_INST directory, then follow the instructions below. This is the recommended scenario for production installations. This also applies when previously running FishEye as a Windows Service and the FISHEYE_INST location is defined within the wrapper.

  1. Shut down your existing FishEye/Crucible server, using bin\stop.bat or bin\stop.sh from the <FishEye home directory>.
    If you currently run FishEye or Crucible as a Windows service, see Upgrading FishEye on Windows for instructions on uninstalling the service.
  2. Make a backup of your FISHEYE_INST directory.
  3. Download FishEye or Crucible.
  4. Run the installer.
  5. Select the option to use the Custom Install. Proceed with the install.
  6. Select the folder where FishEye will be installed. In this step you can leave the default value selected. Proceed with the install.
  7. Select the folder where your data will be stored, which in this case is the folder pointed by your FISHEYE_INST. Ensure to select the correct folder in order to have all your data being read by FishEye. For example, if your FISHEYE_INST is currently set to C:\Atlassian\fish_inst, this is the folder you have to select. Proceed with the install until the end.
    • Please be aware that jar files in the FISHEYE_INST/lib directory may conflict with those required for FishEye's normal operation. Jar files in this directory should be limited to those which provide functionality not provided by FishEye (e.g. database drivers).
  8. FishEye will be installed and running as a service by the end of the install process.
  9. Follow any version-specific instructions found in the FishEye upgrade guide or Crucible upgrade guide.

Without a FISHEYE_INST directory (including when previously running as a Windows Service using the wrapper)

  Click here to expand...

If you do not have FishEye/Crucible configured to use a FISHEYE_INST directory, the installer will create a directory for you and will create a FISHEYE_INST environment variable pointing to it. In the following instructions, <FishEye home directory> refers to the location of the previous FishEye/Crucible installation. This also applies when previously running FishEye as a Windows Service and there is no FISHEYE_INST defined.

  1. Shut down your existing FishEye/Crucible server, using bin\stop.bat or bin\stop.sh from the <FishEye home directory>.
    If you currently run FishEye or Crucible as a Windows service, see Upgrading FishEye on Windows for instructions on uninstalling the service. 
  2. Download FishEye or Crucible.
  3. Run the installer.
  4. Select the option to use the Default Install. You may also use Custom Install if you want to select the directories where FishEye will be installed and where your data will be stored. Proceed with the install.
  5. FishEye will be installed and running as a service by the end of the install process.
  6. Stop FishEye service (names as Atlassian FishEye).
  7. Copy <FishEye home directory>/config.xml to <FISHEYE_INST>.
  8. Delete the following directories from the <FISHEYE_INST>/var directory:
    • <FISHEYE_INST>/var/cache
    • <FISHEYE_INST>/var/data
    • <FISHEYE_INST>/var/log
  9. Copy (or move) the following directories from <FishEye home directory>/var to <FISHEYE_INST>/var: 
    • <FishEye home directory>/var/cache
    • <FishEye home directory>/var/data
    • <FishEye home directory>/var/log
      DO NOT include the following directories when you do that:
    • <FishEye home directory>/var/osgi-cache
    • <FishEye home directory>/var/plugins
    • <FishEye home directory>/var/tmp
  10. Delete the <FISHEYE_INST>/cache directory.
  11. Copy (or move) the <FishEye home directory>/cache directory to <FISHEYE_INST>/cache.
  12. Start the Atlassian FishEye service.
  13. Follow any version-specific instructions found in the FishEye upgrade guide or Crucible upgrade guide.

5. Update any custom configurations

Once the new vesion of FishEye is installed, remember to update any custom configurations in the new version of FishEye, for example your SQL driver and your wrapper.config file.

If you are using MySQL, read about the JDBC driver.

If you currently run FishEye as a Windows service and are installing the new version of FishEye in a new location, you need to uninstall and then reinstall FishEye as a Windows service. Please see Upgrading FishEye on Windows for instructions.

For FishEye 3.4 and later, on Windows, you can edit the Java VM properties using the tool included in the download. See JVM system properties.

6. Start FishEye

In a terminal, change directory to the <FishEye install directory> and run this:

After a few moments, in a web browser on the same machine, go to http://localhost:8060/ (or, from another machine, type  http://hostname:8060/ , where hostname is the name of the machine where you installed FishEye).

Note that the first time you run a new version of FishEye, it will automatically upgrade its data. This may involve a complete re-index of your repository. Read about how to reduce downtime when a repository re-index is required.

If you are interested in suggestions for improving FishEye performance see Best Practices for FishEye configuration and Tuning FishEye performance.

Version-specific update notes

This section provides specific update notes for each version of FishEye. These notes supplement the primary update guide above.

You should read the relevant sections for each version between your current version of FishEye and the version you are upgrading to.

FishEye 3.9 upgrade notes

Please also see:

Smart Commits now use the JIRA REST API

As of version 3.9.0, FishEye uses the JIRA REST API instead of the JIRA FishEye Plugin for JIRA Smart Commits. This change ensures that you will be able to use Smart Commits with future versions of JIRA. Note that using Smart Commits with previous versions of FishEye (earlier than 3.9.0) and JIRA 7 will cause an error notification via email. 

Git clone changes

As of version 3.9.0, FishEye turns Git garbage collection off when cloning a repository (by adding the gc.pruneExpire=never option) to prevent unreferenced objects being removed from local clones. Also, when cloning a repository, git config is run on each repository during instance startup. This change bumps the Git cache version ( CACHE_VERSION ) to 22.

Supported platform upgrades

  • Oracle 12c is now supported.
  • Git 2.4.6 and Mercurial 3.4.2 are now supported.
  • Support for Java 7 has been removed from FishEye 3.9, as previously announced.
  • Support for Internet Explorer 9 has been removed from FishEye 3.9, as previously announced.

Known issues for FishEye 3.9

Loading

FishEye 3.8 upgrade notes

Please also see:

Improved Git indexing time for newly created branches

In order to allow faster Git indexing, a new field was added to the internal repository caches. The cache for each Git repository is automatically upgraded when the repository is started for the first time after upgrading. It is expected to take  under a minute per repository , but may take slightly longer if repositories have thousands of branches.

Supported platform upgrades

Known issues for FishEye 3.8

Loading

FishEye 3.7 upgrade notes

Please also see:

Supported platform upgrades

Known issues for FishEye 3.7

Loading
T Key Summary Status
Bug FE-5765 SVN symbolic rules ignored when prepended with slashes Open
Bug FE-5531 Missing file delete in commit (FE-git) Open
Bug FE-4063 Document how the REST API "expand" parameter can be used Open
Bug FE-3914 Review Coverage report error when folder in repository contains spaces in its name Open
Bug FE-5767 SVN excluded paths are loaded into memory when indexing what can cause OutOfMemoryError Open
Bug FE-5728 Performing a git mv causes the file to lose its commit history Open
Bug FE-5717 Linker regex matching single digit causes bad render for comments and commit messages Open
Bug FE-5712 perl syntax highlighting bug Open
Bug FE-5596 Mercurial: error indexing content of file with unicode name on Windows Open
Bug FE-5594 git main branch name unknown until first change detected in remote repository Open
Bug FE-5569 Searching Removed Text from a Perforce Repository Yields No Results Open
Bug FE-5562 SVN repo custom SVN Symbolic Rules - 'Add' link disappears Open
Bug FE-5561 Freetext searches don't allow partial operator matching Open
Bug FE-5557 Crowd with SSO authenticates user without password Open
Bug FE-5554 Clone button does not display for Git repository unless a custom URL is specified in the Repository configuration Open
Bug FE-5548 Misspelling in reindexing message Open
Bug FE-5532 Installer does not set memory pools in Windows Service Open
Bug FE-5528 Trying to approve OAuth token when logged in via the admin password causes an error Open
Bug FE-5524 Git branch containing a + sign in its name is not properly indexed Open
Bug FE-5490 GIT scanner: analysing changed paths for several commits can cause OOM. Open
Showing 20 out of 23 issues Refresh

FishEye 3.6 upgrade notes

Please also see:

Supported platform upgrades

SSLv3 support is disabled by default

As of FishEye 3.6, SSLv3 support is disabled by default. This shouldn't affect normal operations in supported browsers. If you need to re-enable SSLv3 support, please consult Configuring SSL cipher suites for Jetty.

Known issues for FishEye 3.6

Loading

FishEye 3.5 upgrade notes

An upgrade from an earlier version of FishEye/Crucible to 3.5.0 may cause problems if you have upgraded the Universal Plugin Manager Plugin to a newer version than is shipped with FishEye/Crucible 3.5.0.

The workaround for this is to remove the custom installed version of the Universal Plugin Manager Plugin.

After upgrading from 3.4.5 to 3.5.0, this error is printed in the web browser when you try to access some pages:

javax.servlet.jsp.JspException: javax.el.ELException: java.lang.NullPointerException: couldn't locate WebResourceIntegration service

Workaround:

  • Stop the new FishEye instance;
  • Remove your newer version of the Universal Plugin Manager Plugin at $FISHEYE_INST/var/plugins/user/plugin.xxxxxx.atlassian-universal-plugin-manager-plugin*.jar;
  • Start the new FishEye instance again.

Please also see:

Known issues for FishEye 3.5

Loading

FishEye 3.4 upgrade notes

Please also see the Upgrade steps section above.

Please read the End of Support Announcements for FishEye. See Supported platforms.

Windows installer

We've produced 32-bit and 64-bit installers for FishEye on Windows. Each installer adds FishEye as a Windows service, and starts the service, automatically. The express install creates, by default, a Data directory and a separate install directory  in C:\Atlassian. The custom install mode allows you to choose different locations for the install and Data directories, with the restriction that the Data directory must not be contained in the install directory. The installer creates the FISHEYE_INST system environment variable.

See Installing FishEye on Windows for detailed installation instructions.

Download the FishEye installer here.

Git manifest upgrade task

The Git manifest upgrade affects Git repositories. The rationale for the Git manifest change is described in Git manifest. There are two options that may be selected to control how the upgrade is performed. For medium to small sized Git repositories, we expect this upgrade process to be quite fast, in the order of minutes. For very large Git repositories, this could take up to a few hours.

Pre-indexing upgrade

By default, prior to indexing, each Git repository will be upgraded to add the manifest information for all changesets currently in the repository. Whilst this upgrade is in progress, the repository may be browsed normally and any existing reviews will be available for normal review workflow operations. New changesets will not be indexed, and will not be available for review until after the upgrade is complete.

Background upgrade

A background upgrade is performed during the normal repository indexing process. If there is time available within the polling interval, manifest upgrades are performed during the remaining time of the polling interval. The objective is that the next indexing poll should not be delayed unduly so new changesets continue to be indexed normally. The fisheye.manifest.upgradebatch system property is provided to control the minimum number of changesets that should be upgraded in each indexing poll. This is to ensure the background upgrade makes significant progress and may mean the indexing poll interval is longer than configured.

If repositories are configured to not poll, or they have a long polling period, FishEye will use the default Git polling period for the duration of the upgrade to ensure sufficient indexing occurs. 

Whilst the upgrade is in progress, new changesets will be processed using the existing pre-3.4.0 approach, using Git ls-tree. Only once the upgrade is complete, will the new 3.4.0+ manifest approach be used. This means that the improved performance of the 3.4.0+ manifest upgrade will only be realized once the process is complete.

Choosing an upgrade approach

The upgrade approach that is used by FishEye is controlled by the fisheye.manifest.forceupgrade  system property – see JVM system properties for information about how to use system properties. The upgrade approach selected applies to the whole FishEye instance and affects all Git repositories in the instance. It is not possible to choose different upgrade approaches for different repositories.

The default setting of the property is to perform the upgrade prior to resuming normal indexing and this is the approach that we recommend. This realizes the benefits of the new manifest code as soon as possible but it does impact indexing of new changesets. To minimize the impact of such an upgrade, the upgrade could be undertaken during a low traffic period or the upgrade could be performed off-line on a separate server.

If it not feasible to have indexing of new changesets delayed at all, then the background upgrade approach can be used. The fisheye.manifest.upgradebatch system property can be tuned to reduce the amount of time spent upgrading to further reduce new changeset indexing impact.

It also possible to change from one approach to the other until the upgrade is complete. FishEye records the upgrade progress so that if FishEye is stopped during an upgrade, the upgrade will resume at the next opportunity. So, if you have started the upgrade using the pre-indexing approach, you can stop the FishEye server, change the system property, restart and the upgrade will continue using the background upgrade approach. Changing from background upgrade to pre-indexing upgrade is also supported.

FishEye may now bind to a different IP address on Windows

Prior to FishEye 3.4, a bug in FishEye ( FE-4909 Closed ) meant that FishEye may not have correctly bound to the IP address you configured. This may have happened if you configured FishEye to bind to a single IP address on a network interface that has several IP addresses; FishEye may in fact have bound to a different IP address. For example, if you have an interface with the IP addresses 1.2.3.4 and 1.2.3.5, and you configured FishEye to use 1.2.3.5, it may have incorrectly bound to 1.2.3.4.

Now that the bug is fixed, FishEye 3.4, and later versions, will now correctly bind to the configured IP address, although this may now be different from the previously bound address.

v1 REST API resources deprecated

Note that the 'v1' REST API resources are deprecated and will be removed in a future release. See the FishEye Crucible REST API.

Known issues for FishEye 3.4

Loading

FishEye 3.3 upgrade notes

Please also see the Upgrade steps section above.

As previously announced, the following platforms are no longer supported by FishEye 3.3:

  • Internet Explorer 8
  • MySQL 5.0
  • PostgreSQL 8.2
  • SQL Server 2005

Please read the End of Support Announcements for FishEye.

Supported platform upgrades

  • SVN 1.8 is supported by FishEye 3.3.
  • Microsoft Internet Explorer 11 is supported by FishEye 3.3.

See Supported platforms.

Known issues for FishEye 3.3

Loading

FishEye 3.2 upgrade notes

Please also see the Upgrade steps section above, and read the End of Support Announcements for FishEye page.

Please note the following changes in FishEye 3.2:

Internally managed Git repositories no longer supported

As previously announced, internally managed Git repositories are no longer supported by FishEye 3.2.

Please read the migration guide for information about options and procedures for migrating your internally managed Git repositories – note that we recommend that you upgrade to FishEye 3.2 before migrating any internally managed repositories.

Supported platform upgrades

See Supported platforms.

User data is moved from data0.bin to the SQL database

An upgrade task is run on startup that moves user data to the SQL database. We are doing this to mitigate the risk of data corruption or loss.

Known issues for FishEye 3.2

Loading


FishEye 3.1 upgrade notes

Please also see the Upgrade steps section above, and read the End of Support Announcements for FishEye page.

Please note the following changes in FishEye 3.1:

Native SVN access via JavaHL requires JavaHL 1.7

You do not need to upgrade your subversion repositories to 1.7. SVN 1.6 is still supported.

If you are using native JavaHL to connect to your SVN repositories you may need to upgrade the SVN JavaHL client on your FishEye server. Please read Native support for SVN for more information.

If you are using SVNKit (the default) you do not need to upgrade SVN.

FishEye 3.1 Merge some per-repository Lucene indices into a global cross-repository Lucene index

FishEye 3.1 has greatly improved performance and scalability for QuickSearch and QuickNav. To achieve this, the per-repository 'METADATA' Lucene indices will be moved into a single global cross-repository Lucene index. This means FishEye is able to search across more repositories in less time because now only a single search index needs to be queried instead of the previous N. Merging these indices into the single cross-repository index can be refreshed in two ways:

  1. Recommended: As an upgrade task that is run automatically when FishEye 3.1 is run for the first time.
  2. As an offline process on a separate staging server.

During the automatic upgrade task, FishEye is fully usable and functional, although search results for files, commits and committers may be incomplete.

In our testing we have found that the automatic upgrade task took 4 hours to complete on a FishEye instance with 144 repositories of different kinds, with 58 GB of data in the FISHEYE_INST folder (excluding logs). We are confident that the automatic upgrade task is suitable for the majority of production FishEye installations. It is worth repeating that the instance was fully functional (reviews, JIRA Integration, Activity Streams, Charts etc) apart from Quick Nav and Quick Search during this time.

Nevertheless, where required, we provide instructions for performing the reindex as an offline process on a separate staging server.

Plugin Settings will be moved from the config.xml to the SQL database

As of FishEye 3.1.0, plugin settings which were previously stored in the <properties> element inside config.xml will be stored in the SQL database. This includes settings for any bundled plugins such as ApplicationLinks, the UniversalPluginManager etc, and any 3rd party plugins. 

An upgrade task is run on startup which will first insert all the properties found in config.xml into a new table in the SQL database. Once successful, the properties are removed from config.xml. 

As part of this change, the RepositoryOptions.setProperties (Map<String, String>properties) and RepositoryOptions.getProperties() methods have been removed from our API. If you are using a plugin which uses either of these methods, you will need to update the plugin to a version which uses the Spring component PluginSettingsFactory. Plugins can use this to access the migrated global and per-repository properties that were previously available via the old RepositoryOptions API. 

Known issues for FishEye 3.1

Loading

FishEye 3.0 upgrade notes

Please also see the Upgrade steps section above.

Please note the following changes in FishEye 3.0:

Jetty 8

FishEye 3.0 now uses Jetty 8 as its web server and Java servelet container. This change should be completely transparent when you upgrade to FishEye 3.0. However, if you have customised either your jetty-web.xml file, or the maxFormContentSize system property, you will need to update those in the new version. See Enabling Access Logging in FishEye and this FishEye KB page for more information.

Infinity DB

FishEye 3.0 now uses the InfinityDB 3.0 database internally to provide improved performance for concurrent access to FIshEye. This change is transparent to users in all respects.

Pipelined indexing

FIshEye 3.0 introduces a new indexing approach that splits the repository indexing process into separate tasks that can be performed in a phased and concurrent way. Users will benefit from the way in which FishEye functionality, such as repository browsing, now becomes available as indexing progresses. This change is transparent to users in all other respects. See Pipelined indexing.

Improved handling of user preferences with session cookies 

Upgrading may result in some users losing their preferences.

SQL Server transaction isolation configuration

We recommend a configuration change for SQL Server to use snapshot mode for the transaction isolation level – see Migrating to SQL Server. This change avoids occasional database deadlocks, and prevents performance warning messages in the FishEye logs and admin screens.

Known issues for FishEye 3.0

Loading
T Key Summary Status
Bug FE-5652 getReviewsForChangeset() can be very slow for large changesets Open
Bug FE-5531 Missing file delete in commit (FE-git) Open
Bug FE-5133 Config.xml get/set/save is not synchronized Open
Bug FE-4674 Repository list empty until indexing completes and throws exception Open
Bug FE-4506 Fisheye can break quite badly if you create a repository with a long name (longer than 100 chars) and then try to add a committer mapping Open
Bug FE-5753 Problems rendering four-byte UTF8 characters in some contexts Open
Bug FE-5711 [JFP] Chart Type in FishEye Charts Gadget is not working Open
Bug FE-5578 Release report shows duplicate JIRA assignees Open
Bug FE-5534 Blame fallback should persist the fetched blame Open
Bug FE-5479 CommiterMappingManager.getAllCommittersForUser tries to acquire() all repositories, which might lead to memory starvation Open
Bug FE-5472 Setting a short poll period, and having repositories that take a long time to check for changes, might cause other repositories never to be scheduled Open
Bug FE-5466 Avatar (possibly other) ETag headers seem to be improperly processed, leading to re-requesting unchanged resources Open
Bug FE-5091 svn: Files added in revision 1 can have wrong added/removed linecounts Open
Bug FE-5057 Git merge commits can show wrong diffs Open
Bug FE-4879 Problems authenticating against NTLM challenge with VisualSVN server Open
Bug FE-4862 Commit chart rendering might affect performance Open
Bug FE-4841 Fisheye can get into a state where it is requesting files from SVN that do not exist (and will 404) Open
Bug FE-4791 Could not find the attribute 'mail' in LDAP Open
Bug FE-4779 Switching from simple to eyeQL search can create a broken eyeQL query Open
Bug FE-4715 Git changelog out of order with git revert Open
Showing 20 out of 23 issues Refresh

Checking for known issues and troubleshooting the FishEye upgrade

If something is not working correctly after you have completed the steps above to upgrade your FishEye installation, please check for known FishEye issues and try troubleshooting your upgrade as described below:

  • Check for known issues. Sometimes we find out about a problem with the latest version of FishEye after we have released the software. In such cases we publish information about the known issues in the FishEye Knowledge Base. Please check the FishEye and Crucible Known Issues in the FishEye Knowledge Base and follow the instructions to apply any necessary patches if necessary.
  • Did you encounter a problem during the FishEye upgrade? Please refer to the guide to troubleshooting upgrades in the FishEye Knowledge Base.
  • If you encounter a problem during the upgrade and cannot solve it, please create a support ticket and one of our support engineers will help you.

Was this helpful?

Thanks for your feedback!

9 Archived comments

  1. User avatar

    Andy Fraley

    If you're using mysql you'll have to copy the mysql connector from your old fisheye directory to the new one.  It's in FISHEYE_HOME/lib/

    19 Apr 2013
    1. User avatar

      David Mittman (JPL)

      I've placed my MySQL connector in FISHEYE_INST/lib, so there's no need for an extra step when upgrading FishEye.

      17 May 2013
  2. User avatar

    David Chou [Intuit]

    While doing some dry run migration testing.  Found out this and thought it's probably good to share.

    After you upgrade from 2.x to 3.x by starting the server in 3.x, you cannot turn back.  Once the database is updated, you can't go back and start 2.x server.  

    Backup and make sure you do your testing folks.  

    04 Jun 2013
  3. User avatar

    shabbaranks

    Hi,

    Currently trying to update from Fisheye v2.7.8 (its a copy of our environment to make sure the upgrade goes ok) when I launch the start.bat (windows server) a command box flashes up and disappears - Fisheye doesn't start. If I use the --debug command exactly the same happens - any ideas why please? Thanks 

    ***EDIT*** I hadn't added the command to the end of the environment variable stating that the its ok to update the repositories which are internally managed - seems to be working now. Thanks (smile)

    06 Jan 2014
    1. User avatar

      Tom Davies [Atlassian]

      Please open a support request at http://support.atlassian.com and attach the files from the FISHEYE_INST/var/log directory.

      06 Jan 2014
  4. User avatar

    Shantanu

    It would be great if documentation uses consistent terminology for home and installation directory. For example, in 'Method 1 ' of upgrade instructions the stop script refers to  <Fisheye home directory>, whereas, the start script uses term Fisheye installation directory (which is already confusing because of FISHEYE_INST variable name). 

     

    13 Jan 2014
  5. User avatar

    Michał Wieczorek

    Selection of which approach to use is controlled by the FishEye fisheye.manifest.forceupgrade system property.

    Can you please provide more details how to set this property?

    23 Apr 2014
  6. User avatar

    Torben Rydiander

    I've two issues regarding upgrade from 3.4.0 to 3.4.4 using Windows installer:

    1. I can't install on top of the old installation folder. I'm told that it's not empty.
    2. When I install to a new folder everything seems to work fine, but when I look at the service it's still running the old version.

    3.4.0 was also installed using Windows installer.

    11 Jun 2014
Powered by Confluence and Scroll Viewport