I have solved my problem of increased number of pcount  after JIRA was unable to remove remove an email with Polish characters from a POP3 account. This was due to JIRA tables being in Latin1 encoding and not UTF-8. After changing to tables to UTF-8 it finally manage to download the stuck email form my inbox then remove thus stopped increasing pcount with each failed attempt to remove it. The below steps worked fine and reset the counter of our tickets although it DID NOT change any references to tickets in their messages (would be good if JIRA allowed to automatically search and replace all matching references as an option).

"Unfortunately, there's no simple way to fix this from the UI. Also, manipulating the database directly may be too tedious and risky.

The safest way to fix this (especially if the issue affected only one project) may be to perform a bulk move operation of all the issues in the affected project, into a new temporary project, reset the issue number counter for the original project from the database, and then move back the issues into the original project. This should cause all this issues to be re-issued new issue keys in a sequential order after migration.

Basically the steps to perform could be as follows:

1. Backup the entire JIRA database before you start (very important) - so you can roll back to the previous state if you make a mistake or have any issues with any of the steps. Also, ensure there are no users making changes to JIRA till the end of the operation.
2. Create a temporary project as similar to the affected project as possible, basically re-using the same schemes as the previous project.
3. Perform a bulk move operation of all the issues in the affected project, into this temporary project. You may notice that all the moved issues are re-numbered sequentially after this move in the new temporary project.
4. Before we move the issues back to their original project, we need to follow the steps in the following KB article to reset the original project: https://confluence.atlassian.com/display/JIRAKB/How+to+reset+the+project+counter+after+moving+issues. (ensure to use the original project key in the SQL update and delete queries)
5. Restart the JIRA database to make sure this changes take effect and all caches are refreshed. Then perform another bulk move operation to return the issues from the temporary project back to the Original project.

"

Hi all,

I have just come to this issue again and have examined all the available data here including the stack trace provided by the reporter and currently there's not enough information here for this be actionable by the development team.

The code around the stacktrace provided has changed significantly so that doesn't really help.

If you are still seeing problems with emails being reprocessed by JIRA in a loop, etc... Please do reach out to us at https://support.atlassian.com so one of our engineers can do troubleshooting and determine the root cause of the bug you are observing.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

I've been affected by this as well. We didn't know why our tickets suddenly increased from 280 to over 20000! Fortunately, support pinpointed the root cause - it was an email with international characters that caused it. It was sitting in our designated for issues mailbox and JIRA couldn't remove it hence so many tickets. We're are now working on switching the DB from latin1 to utf-8 (why wasn't utf-8 set as default in the first place!?).

This issue has affected us, to the tune of a 13000 increase in the 'pcounter' value. Alarmingly, when we restored the DataBase (for unrelated reasons) last week, therer were 13000 additional/erroneous tickets in the system, related directly to the above issue. This required manual intervention/deletion, and raised data integrity/reliability concerns for our users.

It's hard for us to pinpoint the exact scenario that led to this, but needless to say it's far from ideal and was directly caused by the 'pcounter' issue outlines above.

It's also frustrating that the issues you have that relate to this issue are generally marked as 'won't fix', for what is an obvious and overt oversight.

If issue creation fails, DO NOT increase the 'pcounter'/write to the database.