[rt-users] We found a merged ticket
Hi there
(Yes, I looked through the mailing list, found some similar issues,
used google - other people seem to have noticed the error, but no
final solution was mentioned yet)
We're running RT 3.6.5 on Debian GNU/Linux 2.6.18-6-686 with Apache
2.2.3-4+etch3, MySQL 5.0.51-3 and Perl 5.8.8-7etch1. In the recent
weeks RT got slower and slower from day to day. We're handling around
1000 Tickets right now.
After turning on debug messages while requesting the details of one
single ticket, the log got filled with tons of such messages:
- --
[Tue Feb 12 00:23:55 2008] [debug]: We found a merged ticket.935/903
(/home/rt3/lib/RT/Ticket_Overlay.pm:273)
... 283 lines with similar meaning ...
[Tue Feb 12 00:25:34 2008] [debug]: We found a merged ticket.1008/903
(/home/rt3/lib/RT/Ticket_Overlay.pm:273)
- --
It took the page more than one and a half minute to load.
I had a look at "Ticket_Overlay.pm" and found the following code
structure:
- --
sub Load {
...
#If we're merged, resolve the merge.
if ( ( $self->EffectiveId ) and ( $self->EffectiveId != $self-
>Id ) ) {
$RT::Logger->debug ("We found a merged ticket.". $self-
>id ."/".$self->EffectiveId);
return ( $self->Load( $self->EffectiveId ) );
}
...
}
- --
In my opinion $self->Load( $self->EffectiveId ) causes an infinite
loop when there are tickets merged into the current one. Indeed, the
programmer seems to have noticed this loop already when reading a
comment at the beginning of the method:
- --
#TODO modify this routine to look at EffectiveId and do the recursive
load
# thing. be careful to cache all the interim tickets we try so we
don't loop forever.
- --
Is there anything we can do to make RT fast again? (Please don't
suggest throwing CPU, RAM etc. at it - IMHO it looks like a classic
software bug which cannot resolved with better hardware).
Thank you!
Best regards
Mario
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] "We found a merged ticket."
I've switched logging up to maximum (debug) on 3.5.6 and I'm now getting up to 50 such messages per second, all with the same ticket number. The messages continue for about 3 seconds and then ease off for a while. Has anyone else noticed this behaviour? It looks to me like something is getting stuck in a loop, but it is fortunately sorting itself out. It doesn't seem to be doing any harm, except for filling the log file with garbage. Boldra ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html
Re: [rt-users] We found a merged ticket
Mario, Isn't that why you ASKED for help? It seems to me that when ASKING for help, then one should be considerate of those being asked and should do "whatever" to help THEM help oneself. A little courtesy is NOT too much to ask. Kenn LBNL On 2/12/2008 8:43 AM, Mario Aeby wrote: >>> Without the output of Carp::cluck, it's not so useful, unfortunately. > > > Seems way too much information for me ... I hope you can figure it out? > > > > > ___ > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > Community help: http://wiki.bestpractical.com > Commercial support: [EMAIL PROTECTED] > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
On Feb 12, 2008, at 11:13 AM, Mario Aeby wrote: >> Can you add another debugging statement to show what ticket #s are >> being >> loaded? > > Here you are: > Without the output of Carp::cluck, it's not so useful, unfortunately. perldoc Carp; ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
On Tue, Feb 12, 2008 at 03:38:06PM +0100, Mario Aeby wrote: > >How is that an infinite loop? It's recursion, yes. But I don't > >believe > >it's infinite > > > Sorry for my wording - more accurately, we should call it "a > recursion going mad". I hope my vocabulary isn't hindering anyone > from diving into the actual issue ... Can you add another debugging statement to show what ticket #s are being loaded? (Possibly with Carp::cluck for backtraces to see where they're coming from) > Ciao > Mario > -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
> How is that an infinite loop? It's recursion, yes. But I don't > believe > it's infinite Sorry for my wording - more accurately, we should call it "a recursion going mad". I hope my vocabulary isn't hindering anyone from diving into the actual issue ... Ciao Mario ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
> sub Load {
> ...
> #If we're merged, resolve the merge.
> if ( ( $self->EffectiveId ) and ( $self->EffectiveId != $self-
> >Id ) ) {
> $RT::Logger->debug ("We found a merged ticket.". $self-
> >id ."/".$self->EffectiveId);
> return ( $self->Load( $self->EffectiveId ) );
> }
> ...
> }
> - --
>
> In my opinion $self->Load( $self->EffectiveId ) causes an infinite
> loop when there are tickets merged into the current one.
How is that an infinite loop? It's recursion, yes. But I don't believe
it's infinite
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
> Without the output of Carp::cluck, it's not so useful, unfortunately.
>
> perldoc Carp;
For all the poor souls out there requesting support and getting
nothing more than perldoc thrown at them:
- --
if ( ( $self->EffectiveId ) and ( $self->EffectiveId != $self->Id ) ) {
$RT::Logger->debug ("We found a merged ticket.". $self-
>id ."/".$self->EffectiveId);
use Carp qw(cluck);
cluck "Test";
return ( $self->Load( $self->EffectiveId ) );
}
- --
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
On Feb 12, 2008, at 11:35 AM, Mario Aeby wrote:
>> Without the output of Carp::cluck, it's not so useful, unfortunately.
>>
>> perldoc Carp;
>
>
> For all the poor souls out there requesting support and getting
> nothing more than perldoc thrown at them:
Cut me a bit of slack ;) I do all the digging for support requests for
customers all day. Generally it's not considered wrong to ask an end-
user of an opensource project to help with the debugging. Of course,
if you want me to do all the work
Best,
Jesse
>
> - --
> if ( ( $self->EffectiveId ) and ( $self->EffectiveId != $self-
> >Id ) ) {
>$RT::Logger->debug ("We found a merged ticket.". $self-
> >id ."/".$self->EffectiveId);
>
> use Carp qw(cluck);
> cluck "Test";
>
>return ( $self->Load( $self->EffectiveId ) );
> }
> - --
>
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
On Tue, Feb 12, 2008 at 05:43:24PM +0100, Mario Aeby wrote: > >>Without the output of Carp::cluck, it's not so useful, unfortunately. > > > Seems way too much information for me ... I hope you can figure it out? Yep. it's not recursion. It's RT::Transaction::TicketObj which should be made smarter. Rather than loading a ticket by id, it should be loading by id _and_ effective id. I'd love a patch. -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
Dear Jesse > Yep. it's not recursion. It's RT::Transaction::TicketObj which > should be > made smarter. Rather than loading a ticket by id, it should be loading > by id _and_ effective id. I'd love a patch. Thank you for your time investigating this. I'll see what I can do. Usually I do program PHP ... Best regards Mario -- Mario Aeby PC-Support Departement Klinische Forschung MEM D814 Murtenstrasse 35 CH-3010 Bern Fon +41 31 632 96 81 ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
On Feb 15, 2008, 11:50 AM, Jesse wrote: > Yep. it's not recursion. It's RT::Transaction::TicketObj which > should be > made smarter. Rather than loading a ticket by id, it should be loading > by id _and_ effective id. I'd love a patch. I'm seeing this issue as well (very long delays, 261 seconds to load a merged ticket). Any clues where I would fiddle with this? We're running the debian package, stable, so it's RT 3.6.1. Considering the original poster wrote in with RT 3.6.5, is an upgrade likely to help? - Mark ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
Jesse Vincent wrote: > > > On Tue, Feb 12, 2008 at 05:43:24PM +0100, Mario Aeby wrote: Without the output of Carp::cluck, it's not so useful, unfortunately. >> >> Seems way too much information for me ... I hope you can figure it out? > > Yep. it's not recursion. It's RT::Transaction::TicketObj which should be > made smarter. Rather than loading a ticket by id, it should be loading > by id _and_ effective id. I'd love a patch. On a similar vein, what's your feeling on EffectiveId becoming null if it's equal to Id? PostgreSQL really doesn't like the "AND (EffectiveId != Id)" it gets it's cost estimates very wrong, resulting in severely suboptimal queries... (Takes 5 or 6 second instead of 1) Mark -- Mark Chappell Unix Systems Administrator ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] We found a merged ticket
On 3 Mar 2008, at 14:52, Mark Blackman wrote: > > On Feb 15, 2008, 11:50 AM, Jesse wrote: >> Yep. it's not recursion. It's RT::Transaction::TicketObj which >> should be >> made smarter. Rather than loading a ticket by id, it should be > loading >> by id _and_ effective id. I'd love a patch. > > I'm seeing this issue as well (very long delays, 261 seconds to load > a merged ticket). > > Any clues where I would fiddle with this? We're running the > debian package, stable, so it's RT 3.6.1. > > Considering the original poster wrote in with RT 3.6.5, is an upgrade > likely to help? Hmm, seems that adding @LogToSyslogConf = ( socket => 'native' ) unless (@LogToSyslogConf); to RT_SiteConfig.pm sped up the merged ticket display from 260 seconds to about 6 seconds. probably still too many log messages being written for the reason above I suppose. - Mark > > - Mark > > > > > > > ___ > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > Community help: http://wiki.bestpractical.com > Commercial support: [EMAIL PROTECTED] > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] "We found a merged ticket."
You don't want to use debug log in production. Even info could be noisy. RT logs "We found a merged ticket" when people open merged tickets. On 5/9/06, Boldra <[EMAIL PROTECTED]> wrote: I've switched logging up to maximum (debug) on 3.5.6 and I'm now getting up to 50 such messages per second, all with the same ticket number. The messages continue for about 3 seconds and then ease off for a while. Has anyone else noticed this behaviour? It looks to me like something is getting stuck in a loop, but it is fortunately sorting itself out. It doesn't seem to be doing any harm, except for filling the log file with garbage. Boldra ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html -- Best regards, Ruslan. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html
