We found a merged ticket

RT Users
1

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.

<http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/branches/
3.6-RELEASE/lib/RT/Ticket_Overlay.pm>

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

2

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

3

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

4

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)

5

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;

6

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 ) );

}

7

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 :wink: 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

8

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?

rt.log.zip (27.2 KB)

9

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
LBNLOn 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?

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

10

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.

11

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

12

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
13

Jesse Vincent 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

14

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