How to remove a Fisheye configuration from Jira?

[f***@atlassian.com]

Some time ago we evaluated Fisheye. Of course we also tested the Jira/Fisheye integration.
After the evaluation period we decided to not go for Fisheye for various reasons. After the evaluation, i just removed the fisheye plug in from the lib folder again.

Now it seems that Atlassian has added the fisheye plugin to the Jira release. As a side-effect my fisheye configuration from the evaluation is reactivated every time I upgrade Jira. I can of course manually delete the plugin, but thats annoying. The main issue is that the Jira Fisheye plugin is now pointing to a non-existing fisheye server. This is causing all sorts of error messages in my jira log file.

The problem is: I cannot remove the fisheye configuration. The GUI only has add or edit function, but none for removal.
Can I remove this configuration somehow manually?

Regards,
Toni
--
Post by tbirrer - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

Can you just disable the plugin in Admin->Plugins... this will prevent it coming back when you upgrade jira.

BTW, I'm interested in why you decided not to go for Fisheye, if you have time.

cheers, jamie
--
Post by JamieEchlin - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

With Fisheye 1.6 out, I'm giving it another spin.

I would of course like to also test the Jira Fisheye Plugin.
As described earlier in this thread, I disabled it after the last trial.

Problem: I cannot enable it again. The UI does not show any enable function.
The Current Plugins page looks like this: http://screencast.com/t/zbXbjhAAD

In the logs during the startup process it states:

{code}
FishEye Plugin : com.atlassian.jira.ext.fisheye
Version : 2.1
Status : disabled
Vendor : Atlassian Software Systems
Description : JIRA Fisheye Plugin
{code}

Is there a manual way, e.g. in the database to re-enable it?
Also funny: the log and UI still state version 2.1, even though i have version 2.2 installed.
--
Post by tbirrer - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

Hi Toni,

Sorry for the delayed extreme delay in replying, I hope this still helps! Running the following SQL should remove the disabled flag from the plugin in your database:

(please perform a full backup before proceeding)

*delete from propertyentry where property_key like 'jira.plugin.state-.com.atlassian.jira.ext.fish%'*

Hope this helps!

cheers,
Tim
--
Post by ***@atlassian.com - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

Disabling the plugin in JIRA 4.x takes about 16 modules and one of them means that when an Admin clicks on Fisheye Config they get an ugly error screen. But it's the most helpful option yet.

~Matt
--
Post by mdoar - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

Thanks, that is a good solution.

Regarding our Fisheye eval:

We use a subversion repository and at the time we had 30'000 commits. The initial scan of Subversion took almost a week. Then I noticed that I didn't want fisheye to index a sensitive part of our repository, so i changed the setup to instruct Fisheye to not index that folder. This required a full re-index, that took another week....

I'm aware that the fisheye forums are full with people having similar issues, and usually it has to do with some tinkering with the SVN bindings or using the native client, etc etc.... and that its most likely possible to get it to perform faster.

Bottom line is that FishEye with Subversion just was a bad experience for me.
I expect a product like Fisheye to just work fast with Subversion out of the box.

Deliver me this and I will re-evaluate ;-)

Regards,
Toni
--
Post by tbirrer - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

That's interesting. I know this is not the right forum, but I have exactly the same issues, except we have about 240k commits in our perforce repo. Indexes in about 5 days after doing all the go-faster tricks.

Totally agree that the includes and excludes are pretty much useless given that you have to reindex.

Was hoping Atlassian would do whatever they've done to jira and conf on it to make it a bit more scalable, after the acquisition.

cheers, jamie
--
Post by JamieEchlin - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

At various times we've had to disable FishEye in Jira (moving servers, etc.) and if memory serves (it's disabled/removed right now so I can't check) there is no overall 'disable plugin' link. We had to go through and disable each module. Then, go to the Listeners tab near the bottom of the admin menu and delete the FishEye listener.

And continuing the off-topic discussion, we use Perforce also and have about 50,000 commits. I'm sure it's different than Subversion, an not as large as a quarter million commits, but our FishEye instance indexes in well under an hour, closer to half an hour. We have our code spread out over several depots, I'm not sure if that helps.

The machine it runs on is virtual and isn't exceedingly fast, either. I suspect slowness (at least with Perforce) might have to do with disk I/O and network pipes. FishEye, I believe, is very disk intensive as it does not use a 'proper' database.

I'm a big FishEye advocate so I am saddened a little when people give up when it may just be hardware/infrastructure/whatever problems because I want everyone to know the glory of FishEye. :) Atlassian has tools available to evaluate disk I/O and whatnot. If you feel like giving it another go I'd contact them and ask about it.

Fisheye, Jira, Perforce and Bamboo all together is, as we say in California, bitchin'.
--
Post by mattyj2001 - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

Hi Matthew,

It's exactly because I know having the whole caboodle working together will be bitchin', that I've spent so much time on this so far. I haven't given up yet, but even if I do, I don't think anyone can say I haven't given it a fair crack of the whip. I'm a bit disappointed by Atlassian's intransigence on http://jira.atlassian.com/browse/FE-226 as well.

The number of commits is not a great indicator... we have many many changelists that contain around 50 thousand files, branches and integs and so on. These are the ones that cause the delays, from looking at the debug log files. A better indicator is the size of the perforce and fisheye databases, 48G and 19G respectively (with no content indexing). I am surprised by your indexing in an hour, what is the size of your databases, out of curiousity?

cheers, jamie

cheers, jamie
--
Post by JamieEchlin3 - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

The very latest version (1.5.6?) of FishEye coped a lot better than earlier ones with a big repo at one of my clients. However, I still have to give it -Xmx2048m -Xms2048m or such like to get it to work. What a hog! Not sure where the bottleneck is.
--
Post by Matt.Doar - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

Our depots are not extremely huge, and we don't store a lot of binary data in there:

P4 database: 14G (entire server root, including .db files. We are indexing all 5 of our depots.)
FishEye database: much less than 1G (includes full content indexing, entire FishEye directory is 209 MB)

I would categorize our branches/merges as 'moderate'. We do a decent amount of branching and merging, but a majority of it is between three branches/streams, we don't often break out our code into one-off branches, etc. We only have a handful of changelists with thousands of files in them (mainly the first 10 or so changelists when we imported VSS code three years ago, and even then our biggest changelists are probably 10-12K files, max.)

Both our Perforce and FishEye servers are Linux with the XFS filesystem, which is generally understood to be rather quick. We've never had any performance problems with either of them so I haven't had to tweak them. Both installations are pretty much right out of the box and have been running well for us for some time (Perforce 3 years, FishEye about 6 months.)

We are running FishEye 1.5.1 and the latest p4d (2007.3)
--
Post by mattyj2001 - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

I would say (no disrepect) that that's a small repository. Including archive our repo is several hundred Gs.

However, I know of several sites that have databases 4 times the size of ours.

It's really fine if FE only works for smallish repos, I'd just like to know about it so I can give up. I'd happily give our database to Atlassian if they would like to test FE on a decent-size repo.

cheers, jamie
--
Post by JamieEchlin - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

Internally we used to keep a FishEye instance covering all our CVS and SVN repos that we weren't that happy with the performance of. Nobody actually owned the administration of this instance or gave it much love, and all we really did was bitch about it. Once we bought the company it got a bit more admin love and now has become an absolutely key tool internally (the performance now is awesome!).

So, FishEye definitely needs to be be set up right and if it is it'll handle quite massive repositories. Some hints: give it a heap of memory and make sure that your SVN tags and branches are set up correctly. That being said, the JIRA users forum is probably not the best place to handle FishEye configuration questions - post on the FishEye forums and you'll probably get some more useful attention on the specifics.
--
Post by jed - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

No disrespect taken. :)

It still seems a bit out of proportion to me, though. Even with that size of a databes it doesn't seem like the time to index it should be measured in days. Unless maybe FishEye isn't doing garbage collection often enough, etc. Even our large-ish, 10,000+ file changelists only take a minute or so to index (I just watched it.)
--
Post by mattyj2001 - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

As Jed noted, this is more appropriate for the FishEye forum. Jamie, if you want to give us a copy of your repository to test with, we would be interested.
--
Post by conor - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

Hi,

My company has started the evaluation of Jira 4.0 and Fisheye. After we have resigned from Fisheye (no support for pvcs and too high cost of migration to subversion or git), I faced the problem how to disable the Fisheye plugin in Jira.

Because there was no 'disable plugin' option, I have forged the link and it seems that it worked.

http://${JIRA_SERVER}/secure/admin/jira/ViewPlugins.jspa?mode=disable&pluginKey=com.atlassian.jirafisheyeplugin

The funny thing is that after I have disabled the plugin, the 'Enable plugin' option appeared:-)

I hope it helps.

Cheers,
Lukasz
--
Post by lguminski2 - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

That 'fake url' really worked :D

Nice!
--
Post by abelcampiao - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935

[f***@atlassian.com]

The "fake" link really did the job to disable. Was looking ages for a possibility to dosable the Plugin! Thanks a lot!
--
Post by michjosi - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=25935