A temporary workaround to mitigate risk is detailed below. Please remember to backup your instance prior to making any changes to your system.

      There were somehow two issues with the issue key JSP-93880 created on SAC. The issue key could not be accessed through the web interface, the error was understandably about expecting one value and getting multiples:

      @400000004e92f2300f44b2f4 2011-10-10 08:24:54,255 http-172.16.3.44-8080-52 ERROR      [500ErrorPage.jsp] Exception caught in 5
      00 page Passed List had more than one value.
      @400000004e92f2300f44bac4 java.lang.IllegalArgumentException: Passed List had more than one value.
      @400000004e92f2300f44beac       at org.ofbiz.core.entity.EntityUtil.getOnly(EntityUtil.java:62)
      @400000004e92f2300f44beac       at com.atlassian.jira.issue.managers.DefaultIssueManager.getIssue(De
      

      One of the two issues was a duplicate of JSP-93382. I removed the database entry for that issue, which restored access to the issue through the web interface.

      Searching for the deleted issue's description, as in "convert internal directory to LDAP" still returns two issues, JSP-93382 and JSP-93380. The entry in that search for JSP-93380 has the wrong summary, but clicking the link goes to the sole remaining issue. I suspect a full reindex will be required to make that bogus entry go away.

      To track this down further, I would propose adding a constraint to disallow duplicate pkey values, as in:

      alter table jiraissue add constraint pkey_unique unique (pkey);
      

      Once that's in place, a database error will thrown whenever an attempt is made to create a second record with the same pkey. Looking at previous examples of other problems, I'd expect something like org.postgresql.util.PSQLException in our case.

      The issues were not created from support requests, nor were they created from mail messages. I suspect that someone it's possible for two threads to end up with the same new pkey.

      This is happening about once a week at this point, so it's not an isolated incident. I don't see anything telling in the logs immediately before the original error, any ideas about tracking this down would be appreciated.

            [JRASERVER-25914] Two issues created with the same pkey value...

            @Nancy - Thanks for bringing this to our attention. I believe you've been in contact with support and they've helped you with the workaround described earlier in this issue.

            What you experienced with JIRA 4.4.3 is actually a slightly different issue, but has the same effect as this original issue so it appears to be the same): JRA-26172.

            For everyone else's benefit, this occurs when creating issues inside of a transition or an issue update. This would only occur in custom plugins which are creating issues inside of JIRA post-functions, listeners, etc., so it's much more rare than the original issue (where the issue could occur with any high load of issues created in parallel)

            We're investigating a fix for a future JIRA bug fix release.

            One of our developers will also be posting a workaround for plugin developers, so plugin developers can avoid the possibility of this conflict occurring in the meantime.

            Bryan Rollins added a comment - @Nancy - Thanks for bringing this to our attention. I believe you've been in contact with support and they've helped you with the workaround described earlier in this issue. What you experienced with JIRA 4.4.3 is actually a slightly different issue, but has the same effect as this original issue so it appears to be the same): JRA-26172 . For everyone else's benefit, this occurs when creating issues inside of a transition or an issue update. This would only occur in custom plugins which are creating issues inside of JIRA post-functions, listeners, etc., so it's much more rare than the original issue (where the issue could occur with any high load of issues created in parallel) We're investigating a fix for a future JIRA bug fix release. One of our developers will also be posting a workaround for plugin developers, so plugin developers can avoid the possibility of this conflict occurring in the meantime.

            I just hit this error in Jira 4.4.3.

            Nancy Belser added a comment - I just hit this error in Jira 4.4.3.

            Bob Swift added a comment -

            My tests now work with 4.4.3. Thanks for fixing.

            Bob Swift added a comment - My tests now work with 4.4.3. Thanks for fixing.

            SheraliA added a comment -

            Glad to hear that all went well so far. Should you have any questions or concerns - please reach out. Glad to help.

            sherali

            SheraliA added a comment - Glad to hear that all went well so far. Should you have any questions or concerns - please reach out. Glad to help. sherali

            Hi Sherali:

            Thanks for the concern.

            The fix and adding the constraint went well. I manually corrected two issues without any problem. I received no complaints after this was applied, and obviously no new conflicts were introduced.

            I have deployed 4.4.3 to our 4.4.x instance, and no problems were experienced with the upgrade process either in test or production.

            So far, things seem well.

            Mark Mielke added a comment - Hi Sherali: Thanks for the concern. The fix and adding the constraint went well. I manually corrected two issues without any problem. I received no complaints after this was applied, and obviously no new conflicts were introduced. I have deployed 4.4.3 to our 4.4.x instance, and no problems were experienced with the upgrade process either in test or production. So far, things seem well.

            SheraliA added a comment - - edited

            Hi Mark,

            I was wondering how did you go with the fix and adding the constraint on your instance? I hope all is well.

            As you can see we have released a version 4.4.3 now. You can download it from the JIRA download center. It provides a fix for the possible duplicates and will perform a reindexing after the migration.

            I would strongly recommend upgrading your instance to this version.

            Please let me know if I can help in any way.

            Kind regards,
            sherali

            SheraliA added a comment - - edited Hi Mark, I was wondering how did you go with the fix and adding the constraint on your instance? I hope all is well. As you can see we have released a version 4.4.3 now. You can download it from the JIRA download center . It provides a fix for the possible duplicates and will perform a reindexing after the migration. I would strongly recommend upgrading your instance to this version. Please let me know if I can help in any way. Kind regards, sherali

            If you upgraded to JIRA 4.4.2, please upgrade to JIRA 4.4.3 as soon as possible. JIRA 4.4.3 includes an upgrade task that will fix any data corruption resulting from this issue in JIRA 4.4.2. See the JIRA 4.4.3 Upgrade Notes for more information.

            Giles Gaskell [Atlassian] added a comment - - edited If you upgraded to JIRA 4.4.2, please upgrade to JIRA 4.4.3 as soon as possible. JIRA 4.4.3 includes an upgrade task that will fix any data corruption resulting from this issue in JIRA 4.4.2. See the JIRA 4.4.3 Upgrade Notes for more information.

            Is there any chance that we could have an upgrade task taking care of duplicates caused by this bug on upgrade to 4.4.3?

            Bogdan Dziedzic [Atlassian] added a comment - Is there any chance that we could have an upgrade task taking care of duplicates caused by this bug on upgrade to 4.4.3?

            We have a fair amount of comfort working in the database. The steps look complete and our two occurrences of the problem (one more occurred since I first reported it) appear corrected. So a bit troubling, but so far no real harm done.

            Unless there is a really strong reason to back out... I think we're going to wait it out to JIRA 4.4.3. The unique key constraint should protect against future re-occurrence for the time being with only mild inconvenience to users.

            Thanks for your attention to this issue.

            Mark Mielke added a comment - We have a fair amount of comfort working in the database. The steps look complete and our two occurrences of the problem (one more occurred since I first reported it) appear corrected. So a bit troubling, but so far no real harm done. Unless there is a really strong reason to back out... I think we're going to wait it out to JIRA 4.4.3. The unique key constraint should protect against future re-occurrence for the time being with only mild inconvenience to users. Thanks for your attention to this issue.

            Hi Mark,

            I'm not sure if you have access to a staging environment locally or not? Please let us know if you would like to use one of our 4.4.2 instances in our lab to test the steps outlined below? We can provision one instantly for your testing. Thanks!

            Randall Ward {Appfire} added a comment - Hi Mark, I'm not sure if you have access to a staging environment locally or not? Please let us know if you would like to use one of our 4.4.2 instances in our lab to test the steps outlined below? We can provision one instantly for your testing. Thanks!

              brollins Bryan Rollins
              aatkins TonyA
              Affected customers:
              23 This affects my team
              Watchers:
              65 Start watching this issue

                Created:
                Updated:
                Resolved: