Re: [rt-users] I am not content with the name StealTicket
On Aug 2, 2010, at 9:26 AM, Jim Tambling wrote: Sorry if I appear to be dismissive of you remarks, but WTF!!?? People like you who try to change established methods/semantics/ways of life/etc to make them comply with their narrow-minded set of moral practices are making the world we live in one of pathetic situations where for example, my son can not take out Little Red Riding Hood out of the school library because it might upset him due to its violent content. If you don't like the term steal, change it on your particular instance of RT but leave the rest of the world alone! I for one am happy with stealing tickets of my colleagues to work on them. And regarding the ConfiscateTicket right, it just goes to show what sort of bigoted individual you are. Trying to enter in to a dialog about religious beliefs and what is right and wrong on a technical forum is pathetic, and I feel deeply saddened by having to stoop to your level, but at the same time I was not going to let the above go unsaid. Good day to you. He/she is a troll, or attempting Monday humor. Cheers-- Chahles -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Quite outside of the speed of RT, what database are you using as a back-end? How long has it been since you did some care and feeding of your database? How big are your tables? If you are using mysql or postgres have you used their tools to examine your database, especially the indexes and statistics? This may be an issue with indexes needing to be rebuilt, or asking the database to gather new statistics for the queries your are running. Cheers-- Charles On Jun 29, 2010, at 8:09 AM, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 charles.john...@accre.vanderbilt.edu Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Justin, thank you for the kindness of your reply. I didn't intend to send you chasing rabbits, so to speak. Just offering something to add to the checklist of items to be crossed off before digging too deeply into the perl code. If you are convinced that mysql is performing at its best then please ignore my noise! :) Cheers-- Charles On Jun 29, 2010, at 9:18 AM, Justin Hayes wrote: Hi Charles, But as far as we can tell from our profiling the time is spent in the perl rendering the ticket, not in the query used to retrieve the ticket and attachments in the first place (which happens once at the start I believe). The loop that renders the ticket history and each attachment takes anything up to 20+ seconds. So I'm not sure how the DB can be an issue here? Unless I'm wrong about it doing 1 big query at the start and there are loads of little queries inside the loop. Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:14, Charles Johnson wrote: Quite outside of the speed of RT, what database are you using as a back-end? How long has it been since you did some care and feeding of your database? How big are your tables? If you are using mysql or postgres have you used their tools to examine your database, especially the indexes and statistics? This may be an issue with indexes needing to be rebuilt, or asking the database to gather new statistics for the queries your are running. Cheers-- Charles On Jun 29, 2010, at 8:09 AM, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 charles.john...@accre.vanderbilt.edu -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] RESOLVED: Re: Custom scrip: Ticket created, but commit fails.
Pardon the top posting, but I feel that I have worked around the
problem we had with failing commits on ticket creation. Here is what I
did.
We first upgraded to the latest stable version of mod_perl for CentOS
5.2.
Second, we changed to custom cleanup code to use IPC::System::Simple
and usied a systemx() call, rather than system(). The advantage is
that systemx() does not invoke a new shell and swallows all stdout/
stderr and return values from the invoked binary. This seems to keep
mod_perl happy as well as RT. Here is the new custom cleanup code:
{
use IPC::System::Simple qw(system systemx);
my $myId = $self-TicketObj-EffectiveId;
my $mySubject = $self-TicketObj-Subject;
my $binret = '';
my $binary = '/home/alarmpoint/alarmpointsystems/integrationagent/
bin/APClient.bin';
$binret = systemx($binary, '--map-data', 'vanderbilt', 'Cluster
Group', $mySubject, 'RT', RT $myId);
1;
}
I hope this helps someone else. It works for us.
Cheers--
Charles
On Jun 24, 2010, at 2:38 PM, Kevin Falcone wrote:
On Thu, Jun 24, 2010 at 11:19:00AM -0500, Charles Johnson wrote:
Badly needing help. This is a script to call a binary that sends
data to a webservice. The binary simply accepts the data and
returns.
rt version: 3.8.1
OS version CentOS 5.2
If you're using mod_perl, Ruslan found some really excellent bugs with
running system commands under it. If you can come up to 3.8.8, that
may fix it for you
-kevin
First, here is the error message:
Jun 24 10:51:32 helpdesk RT: Ticket 9261 created in queue
'ClusterSupport' by johns276
(/opt/rt3/bin/../lib/RT/Ticket_Overlay.pm:659)
Jun 24 10:51:32 helpdesk RT: Attempted to commit a transaction with
none in progress at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 747
DBIx
::SearchBuilder::Handle::EndTransaction('RT::Handle=HASH(0xba695a0)',
'Action', 'commit', 'Force', 'undef') called at /usr/lib/perl5/
site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 780
DBIx::SearchBuilder::Handle::Commit('RT::Handle=HASH(0xba695a0)')
called at /opt/rt3/bin/../lib/RT/Ticket_Overlay.pm line 675
RT::Ticket::Create('RT::Ticket=HASH(0xc8b8798)', 'Requestor',
'ARRAY(0xc8a4df4)', 'DependsOn', 'ARRAY(0xc8bb6b8)', 'Cc',
'ARRAY(0xc8c1034)', 'RefersTo', 'ARRAY(0xc8bb7f0)', ...) called at /
opt/rt3/bin/../local/lib/RT/Interface/Email/Filter/TakeAction.pm
line 501
RT::Interface::Email::Filter::TakeAction::GetCurrentUser('Message',
'MIME::Entity=HASH(0xc8af7fc)', 'RawMessageRef',
'SCALAR(0xc8afdc0)', 'CurrentUser',
'RT::CurrentUser=HASH(0xc862d80)', 'AuthLevel', 1, 'Action', ...)
called at /opt/rt3/bin/../lib/RT/Interface/Email.pm line 1274 RT::
The ticket is created but the commit fails. An attempt to view the
ticket produces this error message: Could not load ticket 9261
Here is the scrip. It is attached to a particular queue
(CustomerSupport).
# Condition: User defined
if ($self-TransactionObj-Type eq 'Create') {
return (1);
}
# Action: User Defined
# Custom action preparation code: Do nothing with the ticket
1;
# Custom action cleanup code:
{
my $myId = $self-TicketObj-EffectiveId;
my $mySubject = $self-TicketObj-Subject;
my $binary =
'/home/alarmpoint/alarmpointsystems/integrationagent/
bin/APClient.bin';
system($binary, '--map-data', 'vanderbilt', 'Cluster Group',
$mySubject, 'RT', RT $myId);
1;
}
#Template: Global Template: Blank
Any suggestions would be appreciated. The message is actually send
to the webservice, since we can log in to the remote server and see
that the data was sent appropriately. However, RT balks.
Thanks.
~Charles~
--
Charles Johnson, Vanderbilt University
Advanced Computing Center for Research and Education
Office: 615-343-4134
Cell: 615-478-5743
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
--
Charles Johnson, Vanderbilt University
Advanced Computing Center for Research Education
Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203
Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143,
Nashville, TN 37212
Office: 615-343-4134
Cell: 615-478-5743
Fax: 615-343-7216
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] Custom scrip: Ticket created, but commit fails.
Badly needing help. This is a script to call a binary that sends data
to a webservice. The binary simply accepts the data and returns.
rt version: 3.8.1
OS version CentOS 5.2
First, here is the error message:
Jun 24 10:51:32 helpdesk RT: Ticket 9261 created in queue
'ClusterSupport' by johns276 (/opt/rt3/bin/../lib/RT/Ticket_Overlay.pm:
659)
Jun 24 10:51:32 helpdesk RT: Attempted to commit a transaction with
none in progress at /usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/
Handle.pm line 747
DBIx
::SearchBuilder::Handle::EndTransaction('RT::Handle=HASH(0xba695a0)',
'Action', 'commit', 'Force', 'undef') called at /usr/lib/perl5/
site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 780
DBIx::SearchBuilder::Handle::Commit('RT::Handle=HASH(0xba695a0)')
called at /opt/rt3/bin/../lib/RT/Ticket_Overlay.pm line 675
RT::Ticket::Create('RT::Ticket=HASH(0xc8b8798)', 'Requestor',
'ARRAY(0xc8a4df4)', 'DependsOn', 'ARRAY(0xc8bb6b8)', 'Cc',
'ARRAY(0xc8c1034)', 'RefersTo', 'ARRAY(0xc8bb7f0)', ...) called at /
opt/rt3/bin/../local/lib/RT/Interface/Email/Filter/TakeAction.pm line
501
RT::Interface::Email::Filter::TakeAction::GetCurrentUser('Message',
'MIME::Entity=HASH(0xc8af7fc)', 'RawMessageRef', 'SCALAR(0xc8afdc0)',
'CurrentUser', 'RT::CurrentUser=HASH(0xc862d80)', 'AuthLevel', 1,
'Action', ...) called at /opt/rt3/bin/../lib/RT/Interface/Email.pm
line 1274 RT::
The ticket is created but the commit fails. An attempt to view the
ticket produces this error message: Could not load ticket 9261
Here is the scrip. It is attached to a particular queue
(CustomerSupport).
# Condition: User defined
if ($self-TransactionObj-Type eq 'Create') {
return (1);
}
# Action: User Defined
# Custom action preparation code: Do nothing with the ticket
1;
# Custom action cleanup code:
{
my $myId = $self-TicketObj-EffectiveId;
my $mySubject = $self-TicketObj-Subject;
my $binary = '/home/alarmpoint/alarmpointsystems/integrationagent/
bin/APClient.bin';
system($binary, '--map-data', 'vanderbilt', 'Cluster Group',
$mySubject, 'RT', RT $myId);
1;
}
#Template: Global Template: Blank
Any suggestions would be appreciated. The message is actually send to
the webservice, since we can log in to the remote server and see that
the data was sent appropriately. However, RT balks.
Thanks.
~Charles~
--
Charles Johnson, Vanderbilt University
Advanced Computing Center for Research and Education
Office: 615-343-4134
Cell: 615-478-5743
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] scrip best practice
As a newbie to RT scrip development, I have a question about best
practice. We are dropping our pager system in favor of AlarmPoint (now
XMatters). I have developed a simple script which identifies the RT
queue in which a ticket is created, and then calls the AlarmPoint
message daemon (running on the same linux box as RT) with parameters
extracted from the TicketObj. Everything works as expected. My
question is about where in the web-interface presented by RT for
building scrips is the best place for my action. Does it belong in
the Custom Action Preparation section, or the Custom Action
Cleanup section?
Here is the very simple code:
Custom Condition:
if ($self-TransactionObj-Type eq 'Create'
($self-TicketObj-QueueObj-Name eq ClusterSupport ||
$self-TicketObj-QueueObj-Name eq StorageSupport))
{
return(1);
} else {
return(undef);
}
Custom Action preparation:
1;
Custom Cleanup:
{
my $myQueueName = '';
my $myQueue = $self-TicketObj-QueueObj-Name;
my $myId = $self-TicketObj-EffectiveId;
my $mySubject = $self-TicketObj-Subject;
if ($myQueue eq ClusterSupport)
{
$myQueueName = Cluster Group;
} else {
$myQueueName = Storage Group;
}
my $binary = '/home/alarmpoint/alarmpointsystems/integrationagent/
bin/APClient.bin';
system($binary, '--map-data', 'vanderbilt', $myQueueName,
$mySubject, 'RT', RT $myId);
1;
}
So, given that this works just fine, does the code in cleanup
actually belong in preparation?
TIA
Charles
--
Charles Johnson, Vanderbilt University
Advanced Computing Center for Research and Education
Office: 615-343-2776
Cell: 615-478-5743
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
