Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Request Tracker: Users

We found a merged ticket

 

 

Request Tracker users RSS feed   Index | Next | Previous | View Threaded


mario.aeby at dkf

Feb 12, 2008, 5:07 AM

Post #1 of 14 (3782 views)
Permalink
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.
- --

<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
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales[at]bestpractical.com


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


jesse at bestpractical

Feb 12, 2008, 6:21 AM

Post #2 of 14 (3735 views)
Permalink
Re: We found a merged ticket [In reply to]

> 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: sales[at]bestpractical.com


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


mario.aeby at dkf

Feb 12, 2008, 6:38 AM

Post #3 of 14 (3718 views)
Permalink
Re: We found a merged ticket [In reply to]

> 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: sales[at]bestpractical.com


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


jesse at bestpractical

Feb 12, 2008, 6:59 AM

Post #4 of 14 (3739 views)
Permalink
Re: We found a merged ticket [In reply to]

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: sales[at]bestpractical.com


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


jesse at bestpractical

Feb 12, 2008, 8:15 AM

Post #5 of 14 (3732 views)
Permalink
Re: We found a merged ticket [In reply to]

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: sales[at]bestpractical.com


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


mario.aeby at dkf

Feb 12, 2008, 8:35 AM

Post #6 of 14 (3717 views)
Permalink
Re: We found a merged ticket [In reply to]

> 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: sales[at]bestpractical.com


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


jesse at bestpractical

Feb 12, 2008, 8:39 AM

Post #7 of 14 (3728 views)
Permalink
Re: We found a merged ticket [In reply to]

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: sales[at]bestpractical.com


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


mario.aeby at dkf

Feb 12, 2008, 8:43 AM

Post #8 of 14 (3724 views)
Permalink
Re: We found a merged ticket [In reply to]

>> 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?
Attachments: rt.log.zip (27.2 KB)


KFCrocker at lbl

Feb 12, 2008, 4:06 PM

Post #9 of 14 (3715 views)
Permalink
Re: We found a merged ticket [In reply to]

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: sales[at]bestpractical.com
>
>
> 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: sales[at]bestpractical.com


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


jesse at bestpractical

Feb 15, 2008, 11:50 AM

Post #10 of 14 (3699 views)
Permalink
Re: We found a merged ticket [In reply to]

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: sales[at]bestpractical.com


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


mario.aeby at dkf

Feb 15, 2008, 3:47 PM

Post #11 of 14 (3689 views)
Permalink
Re: We found a merged ticket [In reply to]

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: sales[at]bestpractical.com


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


mark at exonetric

Mar 3, 2008, 6:52 AM

Post #12 of 14 (3623 views)
Permalink
Re: We found a merged ticket [In reply to]

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: sales[at]bestpractical.com


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


m.d.chappell at bath

Mar 3, 2008, 7:18 AM

Post #13 of 14 (3627 views)
Permalink
Re: We found a merged ticket [In reply to]

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: sales[at]bestpractical.com


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


mark at exonetric

Mar 3, 2008, 8:10 AM

Post #14 of 14 (3609 views)
Permalink
Re: We found a merged ticket [In reply to]

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: sales[at]bestpractical.com
>
>
> 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: sales[at]bestpractical.com


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

Request Tracker users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.