-
Bug
-
Resolution: Unresolved
-
Low (View bug fix roadmap)
-
None
-
7.0.9, 7.0.10
-
7
-
14
-
Severity 3 - Minor
-
0
-
Summary
JIRA appears to upgrade correctly but fails when accessing Administrator functions such as the Applications and add-ons screens.
Environment
- JIRA 7.0.9 or 7.0.10
- Previously migrated from a JIRA Cloud instance
- MySQL database
Expected Results
JIRA will navigate to these pages without error
Actual Results
The below exception is thrown in the atlassian-jira.log file:
Caused by: com.atlassian.cache.CacheException: com.atlassian.jira.exception.DataAccessException: org.ofbiz.core.entity.GenericDataSourceExce
ption: SQL Exception while executing the following:SELECT lower_parent_name FROM cwd_membership WHERE (directory_id = ? ) AND (lower_child_
name = ? ) AND (membership_type = ? ) (Streaming result set com.mysql.jdbc.RowDataDynamic@695f5925 is still active. No statements may be i
ssued when any streaming result sets are open and in use on a given connection. Ensure that you have called .close() on any active streaming
result sets before attempting more queries.)
at com.atlassian.cache.memory.DelegatingCache$DelegatingLoadingCache.get(DelegatingCache.java:330)
at com.atlassian.jira.crowd.embedded.ofbiz.OfBizInternalMembershipDao.getParentsForMemberFromCache(OfBizInternalMembershipDao.java:3
70)
at com.atlassian.jira.crowd.embedded.ofbiz.OfBizInternalMembershipDao.searchCache(OfBizInternalMembershipDao.java:355)
at com.atlassian.jira.crowd.embedded.ofbiz.OfBizInternalMembershipDao.search(OfBizInternalMembershipDao.java:309)...
Workaround
Run the following SQL and see if this applies to your situation
select * from cwd_user where user_name like 'addon%'
If users are returned from the SQL query:
- Go to User Management and find any users whose username begins with "addon_".
- Delete these users.
- relates to
-
-
- Closed
-
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page"){kind=icon}
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRASERVER-59505] JIRA 7.0.9 fails with SQL error when using MySQL Server
Oswaldo, seems a bit more than minor to me since every instance moved from Cloud to Server that uses MySQL will run into this.
Removing the users solved the issue.
Thank you very much for your help.
We have migrated from OD to server, and cant access the above.
Hi khn1205384961, thanks for the bug report.
I have been investigating your stacktrace, and I think I have found the problem.
The good news is that I think it is caused because you were using at least one Cloud Add On while you were in Cloud, and now this is causing JIRA to go down a code path that makes MySQL get angry.
We will want to fix the root cause, but in the meantime I think we have a workaround for you.
The Problem
When we add Connect Addons to JIRA Cloud, we create a "Service account" for each.
A service account is like a user account, but it doesn't use up any license seats, and you can't actually log in to JIRA using it - only remote add ons can use the account to authenticate with JIRA.
Now, when you migrated to JIRA Server it looks like at least one service account was left in the data, and this in turn is causing JIRA to go into a code-path that is normally only hit in JIRA Cloud (we don't use MySQL in Cloud, so the code works there AFAICT).
The Workaround
So it looks like there should be a simple workaround.
You need to go to User Management and find any users whose username begins with "addon_".
You will want to delete such users.
I have not reproduced your problem myself, so I cannot guarantee 100% this will work, but from investigating your stacktrace and the JIRA code it seems it should.
If for some reason you cannot delete these users, or the problem persists after deleting them, then please raise a Support ticket on https://support.atlassian.com where we can give you personal support.
If you do raise a ticket, please add a link to this bug report so the support engineer can see the investigation we have done to date.
Hi khn1205384961,
It would be helpful to see the support zip file that you generated.
It contains some data that can be considered sensitive, so best to create a support ticket on https://support.atlassian.com and attach the file to that ticket.
Regards,
Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].
Hi Matt,
I set the priority field based on the severity of the issue.
The criteria we use indicates that if the issue has a feasible, simple workaround it is classified as Minor and this is the case for this issue.
Having said that, it is something we would like to fix, the Priority field is only one of the many factors we take into account to organize the short-term backlog.
Regards,
Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].