| Table of Contents |
|---|
Enabling the logs
...
- Package Name: com.kintosoft.jira, com.kintosoft.svnwebclient and, orgorg.polarion.svnwebclient (three svnwebclient and org.tmatesoft (four packages)
- Logging Level: DEBUG
...
Keep in mind that the configuration above is automatically reset if JIRA is re-started so you have to grant the plugin to write in the JIRA logs again.
...
The
...
- Remove the SQL+JQL Driver app
- Install it again from the Marketplace
- Enable Subversion ALM app
The hard way (manual)
Sometimes an app cand get stuck forever in Jira avoiding upgrades in a proper way. Under some circumstances removing the app in a manual way might be required.
Steps:
Figure out the OSGi Id assigned to the app during the installation process. The OSGi console must be opened in Jira (administrator privileges are required)
${JIRA_BASE_URL}/plugins/servlet/upm/osgi
and search for the app:
In the example above, SUbversion ALM was installed as the 223 OSGi plugin.
Open the
${JIRA_HOME}/plugins/installed-plugins
directory and delete the app file from there:
Open the
${JIRA_HOME}/plugins/.osgi-plugins/transformed-plugins
and search for the app plugin jar and delete all of them:
You will be able to delete all of them.. except one. This is the library being used by Jira:
It can be deleted only by shutting down Jira!. Then remove the app jar.
Open the
${JIRA_HOME}/plugins/.osgi-plugins/.osgi-plugins/felix/felix-cache
folder, search for the bundle with the OSGi ide figured out from the console and delete the entire folder.
Your app has been removed. Please keep in mind that the app's data remains unmodified elsewhere the app stored them (file system, database, etc), so any previous configuration will still be there until those data are explicitly removed. This is not required by this process as we want to delete the app binary files and not its data.
Startup Jira again and install the latest version of the app from the Marketplace:
The 404 Error
...
404 Error (or other unexpected errors on pages)
The Atlassian's JIRA Subversion plugin must be uninstalled and Subversion ALM re-installed again.
A lot of warnings in the logs: Dangerous use of multiple connections
| Info |
|---|
Fixed in the 9.0.1 version |
Subversion ALM reuses one Jira database connection pool to run several queries and this is logging a warning, perhaps the overall execution took a while reducing the number of available free connections at the pool. However, none has reported this causes performance issues on any Jira instance.
From Jira 9.0,1 only one query is performed per connection. This takes the connection from the pool for a shorter time.
2020-06-14 13:01:33,619+0200 http-nio-2990-exec-5 WARN admin 781x2920x1 psmhc7 0:0:0:0:0:0:0:1 /projects/DEMO [c.a.jira.ofbiz.ConnectionPoolHealthSqlInterceptor] Dangerous use of multiple connections: taken => count=3; marks=[2-3]; pool=3/8
java.lang.AssertionError: Explicit stack trace requestedat com.atlassian.jira.util.log.RateLimitingLogger.warnWithTrace(RateLimitingLogger.java:124)
at com.atlassian.jira.ofbiz.ConnectionPoolHealthSqlInterceptor$CountHolder.logWarn(ConnectionPoolHealthSqlInterceptor.java:236)
at com.atlassian.jira.ofbiz.ConnectionPoolHealthSqlInterceptor$CountHolder.taken(ConnectionPoolHealthSqlInterceptor.java:252)
at com.atlassian.jira.ofbiz.ConnectionPoolHealthSqlInterceptor.onConnectionTaken(ConnectionPoolHealthSqlInterceptor.java:89)
at com.atlassian.jira.ofbiz.ChainedSQLInterceptor.lambda$onConnectionTaken$0(ChainedSQLInterceptor.java:64)
at com.atlassian.jira.ofbiz.ChainedSQLInterceptor.forEach(ChainedSQLInterceptor.java:93)
,,,,
A lot of errors in the Jira logs (caused by a service)
Subversion ALM does not use Jira services.
This error is caused by the discontinued Atlassian's plugin Subversion for Jira. It has a bug and the service is not removed along with the app and it remains active causing errors. It must be manually removed from the Jira administration services section and reboot Jira.
Example of an error traces (among other possibilities):
java.lang.UnsupportedOperationException: This method is not supported in an UnloadableJiraServiceContainer
Negotiate authentication failed (on Windows)
Try by configuring the order to negotiate authentication by adding the following property to the JVM configuration and re-starting Jira:
-Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM
Please, read this Atlassian's documentation for how to add the property above to your Jira instance configuration startup:
After Jira has been rebooted, verify that the change has been taken effect. Go to
Jira > Administration > System Info > JVM Input Arguments
and verify that the required configuration is present there.
Error: svn: E215000: Credential data unavailable
- Add an URL as svn-ssh://my.server.addr/foo/bar (no username in the URL)
- Add the username you want to connect with in the Basic Authentication section.
- Copy the rsa_id file to the /var/atlassian/application-data/jira and then specified /var/atlassian/application-data/jira/rsa_id in the field for the key
ERROR: relation "ao_2b6364_svn_app_conf" does not exist Position: 19
Under some circumstances the app is unable to detect the database vendor and the configuration page shows a massive failure:
This has been reported for some PostgreSQL database instances.
Please follow these instructions to resolve it:
- Upgrade Subversion ALM for the 9.3.3 version or above
- Execute this sentence: INSERT INTO "AO_2B6364_SVN_APP_CONF"("KEY_NAME", "VALUE") VALUES('DATABASE_VENDOR', 'POSTGRESQL');
- Re-enable the app in order the changes to take effect.
