Hi,
why was Kernel::System::Ticket::Number::Random removed in OTRS6? Can I change the old generator to work with OTRS6?
Thanks
Stefan
Random Ticket Number Generator missing in OTRS 6?
Moderator: crythias
Re: Random Ticket Number Generator missing in OTRS 6?
As the TicketNumber Generator now relies on database the random number generator was removed as it will not work
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master
Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
"Testing": ((OTRS Community Edition)) and git Master
Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
-
- Znuny newbie
- Posts: 9
- Joined: 27 Feb 2017, 12:35
- Znuny Version: 5.0.12
- Real Name: Stefan Seidel
Re: Random Ticket Number Generator missing in OTRS 6?
Interesting, thanks. I what way does it rely on the database?
-
- Znuny newbie
- Posts: 9
- Joined: 27 Feb 2017, 12:35
- Znuny Version: 5.0.12
- Real Name: Stefan Seidel
Re: Random Ticket Number Generator missing in OTRS 6?
Hmm, I added
and changed
Any caveats to look out for?
Stefan
Code: Select all
use parent qw(Kernel::System::Ticket::NumberBase);
- TicketCreateNumber to TicketNumberBuild
- $Self->TicketIDLookup to $Kernel::OM->Get('Kernel::System::Ticket')->TicketIDLookup
Any caveats to look out for?
Stefan
-
- Moderator
- Posts: 10169
- Joined: 04 May 2010, 18:38
- Znuny Version: 5.0.x
- Location: SouthWest Florida, USA
- Contact:
Re: Random Ticket Number Generator missing in OTRS 6?
I think this used to use a standalone file to store the ticket numbers previously, then it decided to query the database.
The idea of a random number generator is allegedly going to cause problems in performance with huge numbers of tickets, both existing and newly generated. There's a slight possibility of a race condition of simultaneously generated identical ticket numbers and the issue when the ticket pool is closer to full being a situation where it takes an increasing amount of time to create a ticket because of generating the number randomly and testing from available numbers. Think of it like throwing large numbers of darts at a dart board and never removing a dart.
For a large number in the pool, (6, 7 digits) 1, 10 million tickets may be plenty. But when it's not, expanding the list is a slight issue, especially if there is a need to explain how 0999999 is a different ticket from 999999. As a string, as a ticket ID internally, this designation doesn't matter. But the ticket number parser needs to be able to distinguish between a 7 digit number and a 6 digit number (this isn't too difficult, just check twice: for old version, then new version).
But there's also the SQL performance hit every time a ticket number gets generated; it has to look up through all available ticket numbers--not just the MAX(id)--and do this again up to 16,000 (your loop limit ... you do have a loop limit, right?) times and fail (ugly) if it can't find an available ticket number.
Like I said, if the dartboard is big enough, this won't likely be a problem.
The idea of a random number generator is allegedly going to cause problems in performance with huge numbers of tickets, both existing and newly generated. There's a slight possibility of a race condition of simultaneously generated identical ticket numbers and the issue when the ticket pool is closer to full being a situation where it takes an increasing amount of time to create a ticket because of generating the number randomly and testing from available numbers. Think of it like throwing large numbers of darts at a dart board and never removing a dart.
For a large number in the pool, (6, 7 digits) 1, 10 million tickets may be plenty. But when it's not, expanding the list is a slight issue, especially if there is a need to explain how 0999999 is a different ticket from 999999. As a string, as a ticket ID internally, this designation doesn't matter. But the ticket number parser needs to be able to distinguish between a 7 digit number and a 6 digit number (this isn't too difficult, just check twice: for old version, then new version).
But there's also the SQL performance hit every time a ticket number gets generated; it has to look up through all available ticket numbers--not just the MAX(id)--and do this again up to 16,000 (your loop limit ... you do have a loop limit, right?) times and fail (ugly) if it can't find an available ticket number.
Like I said, if the dartboard is big enough, this won't likely be a problem.
OTRS 6.0.x (private/testing/public) on Linux with MySQL database.
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask