Issue Details (XML | Word | Printable)

Key: JRA-6209
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Mark Chaimungkalanont [Atlassian]
Reporter: Sri Sankaran
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
JIRA

Ability to change index location without clobbering old location

Created: 15/Mar/05 11:32 PM   Updated: 05/May/05 02:05 AM
Component/s: Filtering & Indexing
Affects Version/s: 3.1
Fix Version/s: 3.2

Time Tracking:
Original Estimate: 4 hours
Original Estimate - 4 hours
Remaining Estimate: 4 hours
Remaining Estimate - 4 hours
Time Spent: Not Specified
Remaining Estimate - 4 hours

Environment: Deployed on WebLogic 8.1 SP2

Participants: Mark Chaimungkalanont [Atlassian] and Sri Sankaran
Since last comment: 3 years, 30 weeks, 1 day ago
Resolution Date: 05/May/05 02:05 AM
Labels:


 Description  « Hide
Consider the following scenario. (This is exactly what happened to us and not a contrived scenario)

JIRA is installed in a production location and everything is just peachy.

A new release of JIRA is available and so it is installed in a sandbox area for test driving purposes. Data for this sandbox instance is obtained from the aforementioned production instance, i.e. you export from production and import into the sandbox.

A big error has crept in!

The data in the JIRA tables includes the location of the backups, attachments and indices. So, unwittingly, the sandbox instance is pointing at the same location as production for backups, attachments and indexes.

You notice this and proceed to update the index location for the sandbox instance to a sandbox location.

Gradually the users are increasingly insistent that JIRA (on production) isn't working. Filters are throwing exceptions and the like.

You start piecing together apparently disconnected information and deduce the cause:
The reason for this is that when you changed the location of the index in the sandbox instance, JIRA-sandbox first blew away the indexes at the old location before creating it at the new location. AAAARRRRGGGHHH!

Now, the title of this issue should make sense.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Mark Chaimungkalanont [Atlassian] added a comment - 16/Mar/05 05:04 PM
This sounds like it coulf affect many people upgrading. We should definitely invetigate this issue for 3.2. At the very least, come up with clear instructions on how to perform the above scenarios without causing problems.