JIRA 5.2.10 - Inplace Upgrade

[mehala n]

Iam trying to do JIRA in-place upgrade from 4.24 to 5.2.10.Created a empty database and all worked well. After copying the data of 4.24 to the empty database,now the database has the 4.24 prod version data.Brought up the Tomcat server and JIRA.It asked for Confirm the old license and restart the server again.But the page got haged.So restarted the tomcat server again.It didnt get proceed after the below line

*********************************************************************************
JIRA 5.2.10 build: 853 started. You can now access JIRA through your web browser.
*********************************************************************************

2013-06-13 02:54:02,832 main INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Detected that an
upgrade is needed; existing data at build 591
2013-06-13 02:54:02,848 main INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Exporting the exi
sting data..
2013-06-13 02:55:28,759 Modification Check:thread-1 INFO [atlassian.jira.startup.JiraStartupLog
ger]
___ Modifications ___________________________

Modified Files : jira-application.properties, seraph-config.xml,
WEB-INF/web.xml, images/icons/favicon.png, images/jira111x30.png, favicon.ico
Removed Files : WEB-INF/lib/slf4j-api-1.6.4.jar, WEB-INF/lib/sl
f4j-log4j12-1.6.4.jar, WEB-INF/lib/jcl-over-slf4j-1.6.4.jar, WEB-INF/lib/jul-to-slf4j-1.6.4.jar

Kindly let me know if this is due to any problem or should I wait until the server gets up completely

[mehala n · Accepted solution]

Hi Nic,

I have few more queries,

1.I used the same osuser.xml(for LDAP server config) while deploying the war connecting to empty database ,there was no issues.Kinldy let me know if still settings would be the issue.

2.In export directory, autoexport_xxxxxxxxxxx.zip with different timestamp is getting created everytime and it taking more than 5 hours everytime (As I mentioned earlier I work in a Virtual Machine..).Is there any way I can disable the autoexport...

Kindly help to resolve these issues

Thanks

Mehala

[Nic Brough -Adaptavist-]

The settings should not really have changed, assuming your LDAP server has not changed. Your log is telling you that it can't actually connect, so your settings are probably actually fine, and the issue is with your network - the Jira server cannot reach the LDAP one (connection timeout, rather than "connected ok, but details were wrong")

For the export, two quick points.

1. 5 hours to export 45,000 issues is far far far too long. The test system here exports 400,000 issues in around 25 minutes. This is also a VM, and it's not a particularly powerful one. I really think you need to look into why your VM is so slow.

2. Try adding jira.autoexport = false to your <jira home>jira-config.properties file (if you don't have one, then just create it, with that one line in it)

[mehala n]

Can you please let me know in which DB table the userid and password are stored when LDAP is not used?

[Nic Brough -Adaptavist-]

It's not that simple - it really does sound like you were using LDAP before, and even if you weren't, you could have been using something else.

If you really were using internal authentication on the old system, then the table you need is cwd_user

But you won't find passwords there - they are NOT stored (it's really bad to store passwords, don't do it).

see https://confluence.atlassian.com/display/JIRA/Retrieving+the+JIRA+Administrator

[mehala n]

LDAP issue is solved by removing osuser.xml.

Now the tomcat server comes up and the UI takes me to the Login window instead of Set Up Wizard.

Can you help me to either create a user or is there any default userid /password which I can use for the first time.

[Nic Brough -Adaptavist-]

You should be using one of the users from your original installation - these will have been imported as part of your data.

If you haven't got any, then you were using LDAP...

[mehala n]

ok.Is there anyway that I can disable LDAP configuration.I see the data is being read from

cwd_directory_attribute table from the database even after I removed the LDAP config from osuser.xml.

Kindly provide some inputs.

Thanks

Mehala

[Nic Brough -Adaptavist-]

Well, um, yes. Don't put the LDAP stuff into the config file.

If you aren't using it, then you shouldn't have enabled it in the first place.

[mehala n]

Hi Nic,

Still facing the same exception in LDAP connectivity.I was told that we dont use LDAP and to disable it. But I could see the LDAP config in osuer.xml in my previous 4.24 version.

<!-- osuser.xml autogenerated by user 'wb247459' on 22/Feb/11 for JIRA 4.2.4-b591 -->
-<opensymphony-user> <authenticator class="com.opensymphony.user.authenticator.SmartAuthenticator"/> -<provider class="com.opensymphony.user.provider.ldap.LDAPCredentialsProvider"> <property name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</property> <property name="java.naming.provider.url">ldap://xxxxxx:389</property> <property name="searchBase">ou=People,dc=xxxx,dc=org</property> <property name="uidSearchName">uid</property>
<!-- Initial search is anonymous <property name="java.naming.security.principal"></property> <property name="java.naming.security.credentials"></property> -->
<property name="exclusive-access">true</property> </provider> -<provider class="com.atlassian.core.ofbiz.osuser.CoreOFBizCredentialsProvider"> <property name="exclusive-access">true</property> </provider> -<provider class="com.atlassian.jira.user.osuser.JiraOFBizProfileProvider"> <property name="exclusive-access">true</property> </provider> -<provider class="com.atlassian.jira.user.osuser.JiraOFBizAccessProvider"> <property name="exclusive-access">true</property> </provider> </opensymphony-user>

Iam confused to see this.So should I conclude that my old 4.24 version is connecting to LDAP.. or simply JIRA would not take this osuser.xml at all..

Please advise.

[Nic Brough -Adaptavist-]

I'm confused as well - you really should have known whether your system is using LDAP or not. We can't tell you from that because we don't know your configuration.

So, a bit of guess work here. If it seems to have been used that way in your old configuration, then the short answer is that whoever told you that you don't use LDAP was wrong, because it was. If they are correct, then the config file is wrong and the old Jira would not have been usable (or the file is being ignored for some reason)

I'd look in the old system - there's a setting in "general settings" for "use external user management". If that is set, then it was almost certainly using LDAP. If not, then it was almost certainly using internal management.

But, whatever has been done here, I'm afraid you need to work it out.

[mehala n]

Thanks a lot Nic.autoexport =false works perfeclty without exporting repeatedly.

[mehala n]

Hi Nic,

Now tomcat is up and getting the below error.The same osuser.xml was used when I connected with empty database,didnt get any LDAP config error.

JIRA Access Constraints You cannot access JIRA at present.Description Time Level ExceptionAn error occurred performing JIRA upgrade The data before the upgrade has been exported to C:\Mehala\jira_home\export\jira_autoexport_20130614_060300.zip 2013-06-14 10:35:30 error JIRA failed to connect to the LDAP server using the configuration in the osuser.xml file. LDAP error: org.springframework.ldap.CommunicationException: xxx.xxxxxx.org:389; nested exception is javax.naming.CommunicationException: xxx.xxxxxx.org:389 [Root exception is java.net.ConnectException: Connection timed out: connect]

Could you please provide some input on this.

Thanks

Mehala

[Nic Brough -Adaptavist-]

Um, the error is pretty clear. You've configured it to connect to LDAP to provide user information. The settings are incorrect, or it cannot reach the LDAP server.

[mehala n]

Thank Nic.

That means the upgrade is going positively!! Actually Iam trying this upgrade in a Virtual Machine.Once this is sucessful we would do the same steps in dev server which would not have this sort of issue .

So Hope I can wait until this gets completed .Will check the status on my nest working day and update you.

Thanks agin for your continuous support

Mehala

[mehala n]

Nic,

I noticed something in export directoty.

the time stamp and size of jira_autoexport_20130614_060300.zip keeps changing ..with latest timestamp and increased size

Is this something we need to wait ?

Thanks

Mehala

[Nic Brough -Adaptavist-]

That's what I was looking for - if that file is growing, then it's running an export.

3 hours is a very very slow export for only 42,000 issues though. What sort of system is your server? Memory, processor etc? Could you increase the size of the memory for the process?

[mehala n]

UI Just keeps processing.. Nothing comes up

Export directory under jira_home has the follwing zip files

jira_autoexport_20130614_052835.zip

jira_autoexport_20130614_060300.zip

Thanks

Mehala

[mehala n]

Nic,

I have pasted my entire log .This is after updating the license successfully.Kindly look into it and help me to sort out this issue

Thanks

[Nic Brough -Adaptavist-]

Hmm. There are no errors there, and nothing I'd worry about in the list of plugins or the settings you have.

What does the UI do when you visit it?

Can you check the "export" directory to see if anything is created in there?

[mehala n]

Nic,

Thanks a lot for your responses.

Steps I followed,

1.Stop the Tomcat

2.Removed atlassian-jira-subversion-plugin-0.10.11.1.jar from WEB-INF/lib

3.Deleted the content of plugins folder except dbconfig.xml

3.Start the Tomcat

Got hanged at the same place.No improvement :(

[Nic Brough -Adaptavist-]

Then we need to go look at the full logs I'm afraid.

[mehala n]

1.Issues are totally 42945 (Found this by doing selct (count(*) from jiraissue table..Pls correct me if it not correct).

2.I dont see anything related to 3 version.verified in the server ,it has 4.24 version only

3.Yes Iam using subversion plugin (included while creating the war)

Please advice.

[Nic Brough -Adaptavist-]

1. Spot on. The basic number you need when judging Jira's speed when it's doing an upgrade or full re-index is "number of issues in the jiraissue table". It's not a simple flat number because it is compounded by related data (e.g. a Jira with lots of custom fields will take longer than the same number of issues but no custom fields), but the number of issues is always the starting point.

42,000 issues should take minutes to export, upgrade and re-index. 3 hours is FAR too long

2. That is NOT what your earlier logs are saying. But we'll come back to that if it's still a problem

3. Ah, this is well worth ruling out. To do this:

1. Remove the jira-subversion.jar from WEB-INF/lib.
2. You don't need to remove any of the supporting jar files (svnkit, trilead, etc), or any configuration around it. Just that one plugin.jar needs to go
3. Run the upgrade again
4. Stop Jira,
5. Delete the contents of the directory {jira home}/caches/indexes/plugins/atlassian-subversion-revisions (note - I cannot remember if you need to delete the directory as well, but I don't think you do)
6. Put the plugin jar file back in WEB-INF/lib
7. Restart Jira

[mehala n]

Waited for more than 3 hours.. Tomcat Server just shows the below lines and not proceeding further.

___ Modifications ___________________________

Modified Files : jira-application.properties, seraph-config.xml,
WEB-INF/web.xml, images/icons/favicon.png, images/jira111x30.png, favicon.ico
Removed Files : WEB-INF/lib/slf4j-api-1.6.4.jar, WEB-INF/lib/sl
f4j-log4j12-1.6.4.jar, WEB-INF/lib/jcl-over-slf4j-1.6.4.jar, WEB-INF/lib/jul-to-slf4j-1.6.4.jar

Could you please clarify Is it worthy to wait still? Is there any way to track that it is progressing.. I see no logs gets grow .

Thanks

[Nic Brough -Adaptavist-]

Technically, we probably need to know the size of your data and what your server speed is before we can tell you how long it should take to do any upgrade.

However, three hours is probably too long.

On a big fast server, I've recently done an upgrade from 4.0 to 5.1. It took 8 hours to do 420,000 issues. But, that time includes backups, two full re-indexes, greenhopper, installations of changed plugins, pizza, reconfiguration to take advantage of new features, testing (both automated and human) and beer.

Also, while it is upgrading or indexing, it writes to the log. Not a huge amount, but enough to reassure you that it is doing something. It does NOT write during the initial export, but that's the bit we can't tell you about without knowing how many issues you have. That said, if it's a few thousand, I can guarantee you the upgrade is dead. If you've got half a million, then 3 hours might be valid.

There's three things to look at here:

1. The size of your data - how many issues?

2. The stuff about appearing to be using a version 3 data set as discussed above

3. Are you using the "subversion plugin"? I've run into this on every upgrade - the plugin can stall an upgrade for hours, without warning or reason...

[Jobin Kuruvilla [Adaptavist]]

2013-06-13 02:54:02,832 main INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Detected that an
upgrade is needed; existing data at build 591
2013-06-13 02:54:02,848 main INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Exporting the exi
sting data..

This can take a lot of time depending on how much data you have in the system. So you better wait and see if it errors out or not!

[Nic Brough -Adaptavist-]

These changed files should not be a problem.

I assume you've changed jira-application.properties to meet your users needs, seraph-config.xml to talk to your user-authentication system, and web.xml for some network related onfig you need (if in doubt, then tell us what you've done to those three files). The missing files are supposed to be removed in certain cases, and I'd say you've followed the instructions on them to the letter.

Your upgrade may take some time, depending on how much data you've got, and your start up looks healthy. Leave it to run and see how it goes!

[mehala n]

Thanks Nic.

In those 3 files ( jira-application.properties ,seraph-config.xml and web.xml) I configured for user A,pwd B and DB jira_db - The database was empty.The only change that I am doing now is same DB with user A,pwd B and DB jira_db.But the data exists.Therefore I dont see any modification that would be required

But I noticed in the Tomcat log few errors,

2013-06-13 05:32:03,648 main ERROR [atlassian.mail.incoming.DefaultMessageHandlerFactory] Handl
er 'cern.jira.emailhandler.AdvancedCreateOrCommentHandler' cannot be instantiated because there is n
o corresponding enabled module defining message-handler of such class
2013-06-13 05:32:03,650 main ERROR [atlassian.mail.incoming.mailfetcherservice] null[null]: Can
not instantiate message handler 'cern.jira.emailhandler.AdvancedCreateOrCommentHandler. This service
will not work until this problem is fixed.
2013-06-13 05:32:14,549 main INFO [atlassian.jira.upgrade.ConsistencyCheckImpl] Checking JIRA c
onsistency The current version of your license (v1) is incompatible with JIRA 5.2.10. you will need to upgrade your license or generate an evaluation license.To upgrade your license visit : http://www.atlassian.com/ex/upgradelicense?product=JIRA&version=5.2.10&build=853&edition=enterprise&sid=B1BP-HVDA-QOFI-19X&ref=prod&licenseversion=1&totalUserCount=0&activeUserCount=0To generate an evaluation license visit : https://my.atlassian.com/license/evaluation?product=JIRA&licensefieldname=license&version=5.2.10&build=853&edition=enterprise&sid=B1BP-HVDA-QOFI-P19X&callback={4}&ref=prodPlease follow the instructions that JIRA is presenting in your web browser. So tried to update the licenese key..It is in progerss for about 30 mins..Does does license key also depends on volume of data?

[Nic Brough -Adaptavist-]

Ok. Your Jira is showing distinct signs of being version 3.x, not 4.2.

The format of the licences changed between version 3 and version 4. (v1 licences work for Jira 2 and Jira 3. v2 licences work for 4, 5 and 6). The licence error you're getting is because your data holds a version 3 licence.

The cern email error you are getting happens because your version 3 system has a plugin installed to provide some mail functions. That plugin is not valid for Jira 4 and above.

I think you need to take a step back - go back to the version 3 system you've got this data from and have a closer look at it. Ideally, you should go into its configuration and remove the mail-handler plugin configuration, then export it, import it into 4.4 and make sure that works before jumping to version 5.

[mehala n]

Could you also kindly clarify how you could comment v3.X is currently used by us.?

We are using 4.24 only as clarified in the previous post.

[mehala n]

Thanks Nic,

Actually Iam trying to do the in place upgrade from 4.24 version to 5.2.10.

The same license I used and it worked well when I deployed the JIRA war(5.2.10) on empty database.

Now I just copied the 4.24 data to my DB and restarted the Tomcat.I dint do any change in JIRA later.

It said the current license is too old.So i went thru the JIRA UI and updated the 5.x license.

It said "Update is successful and restart the server".I restarted the server..but was not succesful.

IS this problem could be due to license key stored in propertytext table.?

Conflicts between different versions of license key in propertytext table.?

Please suggest

Thanks

Mehala

[Nic Brough -Adaptavist-]

Um, then I'm stuck.

Your data REALLY looks like it's from version 3 and has not been upgraded to version 4. The licence in it is a version 3 licence. It refers to version 3 plugins. The errors you are seeing would not be reported if you were upgrading from 4.2 to 5.2, you would only get them if you are trying to upgrade from 3 to 4 or above.

Could you go back to the 4.2 system you think you are upgrading and make sure it is working? If it is, then could you check the licence screen to see what that says, the "services" screen to check what the incoming email handlers say, and the "system information" screen to check the exact reported version

[Nic Brough -Adaptavist-]

Because the data you are working from seems to be from version 3. That's what the log file implies. It does not say it explicitly, but the licence in your data is a version 3 licence, which will not work with version 4 or 5, and will not allow a version 4 service to run.

You may well have a version 4.2.4 Jira running in front of you. But the data you have in your test/upgrade database does not seem to be 4.2. Your next test is probably to install 4.2 and point it at your test database.

[mehala n]

Thanks Nic.Will keep your points in mind and check the database side .