Re: [rt-users] fcgi read timeout error in 4.2.5
On 06/24/2014 04:03 PM, Shawn Plummer wrote: > [snip] Please keep replies on-list. - Alex >> Sounds like it's indeed related to session locking. You can try >> switching to on-disk sessions and see if it resolves the issue: >> >>Set($WebSessionClass, "Apache::Session::File”); >> > Running this way did indeed prevent the error from occurring. We > switched back to database sessions to perform more testing. > >> However, we'd also be interested to hear what your DBA discovers about >> the deadlocks, as this issue may well bite other Oracle users, and we'd >> like to resolve it. > > Our DBA has been doing some research and believes FOR UPDATE in this > statement is the issue > > SELECT a_session > FROM sessions > WHERE id = :p1 FOR UPDATE > > From Oracle Doc: > How Oracle Database Locks Data > > Locks are mechanisms that prevent destructive interaction between > transactions accessing the same resource—either user objects such as > tables and rows or system objects not visible to users, such as shared > data structures in memory and data dictionary rows. > > In all cases, Oracle Database automatically obtains necessary locks when > executing SQL statements, so users need not be concerned with such > details. Oracle Database automatically uses the lowest applicable level > of restrictiveness to provide the highest degree of data concurrency yet > also provide fail-safe data integrity. Oracle Database also allows the > user to lock data manually. > > More > details: > http://docs.oracle.com/cd/B28359_01/server.111/b28318/consist.htm#CNCPT020 > > There is also a doc showing that SELECT FOR UPDATE behavior is different > from 10g to 11g. Doc ID 858518.1 > > And further information on FOR > UPDATE http://markjbobak.wordpress.com/2010/04/06/unintended-consequences/ > > > -- > Shawn Plummer > Systems Manager | SUNY Geneseo > South Hall 119 | 585-245-5577 | http://www.geneseo.edu/cit > -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Change Management Multiple Owners
On 06/24/2014 08:02 AM, Aaron McCarthy wrote: > I am trying to implement CM solution using Request Tracker. I am > using version 4.0.4. Is there any way I can add multiple owners to > approve tickets instead of just one? > > I know there is an "AdminCC group" option for version 4.0.5 or > later. RT does not allow multiple owners, and never will. However, AdminCcs are in no way new in 4.0.5 (where did you find that misinformation?). If you grant the AdminCc role appropriate rights, they work just fine for letting any one of multiple users approve the ticket. > This is not an option for us at this time. Is there any way to do > this without updating RT? Upgrade. There are multiple disclosed security vulnerabilities against 4.0.4, including SQL injection, arbitrary information disclosure, and cross-site request forgery. Upgrades within a stable series are designed to be as painless as possible. - Alex -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] fcgi read timeout error in 4.2.5
On 06/24/2014 02:21 PM, Shawn Plummer wrote: > Not sure what this really tells me. > > Our DBA is looking into the database side. Apparently It is blocking > itself going against the 11g database. Sessions are blocking other > sessions. We are looking into any possible database parameters new to > 11g that cause this behavior to be different from our production 10g RT > database. Sounds like it's indeed related to session locking. You can try switching to on-disk sessions and see if it resolves the issue: Set($WebSessionClass, "Apache::Session::File"); However, we'd also be interested to hear what your DBA discovers about the deadlocks, as this issue may well bite other Oracle users, and we'd like to resolve it. - Alex -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] fcgi read timeout error in 4.2.5
On Jun 17, 2014, at 3:01 PM, Kevin Falcone wrote:
> Look for slow queries in your database (there are oracle specific
> reports for this) or try turning on MasonX::Profiler in development
> and see what RT is doing when it times out.
I enabled MasonX::Profiler as you suggested. Here is the relevant log entries
RT::Config::__ANON__('RT::Config=HASH(0x14eab98)', undef) called at
/opt/rt4devel/sbin/../lib/RT/Config.pm line 1159
RT::Config::PostLoadCheck('RT::Config=HASH(0x14eab98)') called at
/opt/rt4devel/sbin/../lib/RT.pm line 199
RT::Init('RT', 'Heavy', 1) called at /opt/rt4devel/sbin/rt-server.fcgi line 126
==> /var/log/httpd/error_log <==
=Mason= localhost - /index.html BEGINS {{{
=Mason= localhost - /autohandler {{{
=Mason= localhost - /Elements/SetupSessionCookie {{{
At this point there is a 3 minute (I upped it to see if it would ever finish)
wait until fcgi times out and throws the internal server error.
==> /var/log/httpd/rt4devel_error_log <==
[Tue Jun 24 14:17:06 2014] [warn] [client 137.238.60.9] mod_fcgid: read data
timeout in 180 seconds, referer:
https://rtdevel.geneseo.edu/index.html?HomeRefreshInterval=120
[Tue Jun 24 14:17:06 2014] [error] [client 137.238.60.9] Premature end of
script headers: rt-server.fcgi, referer:
https://rtdevel.geneseo.edu/index.html?HomeRefreshInterval=120
==> /var/log/httpd/error_log <==
=Mason= localhost - /favicon.ico BEGINS {{{
=Mason= localhost - /autohandler {{{
=Mason= localhost - /Elements/SetupSessionCookie }}} 180.1433
TONS more Mason logs
Not sure what this really tells me.
Our DBA is looking into the database side. Apparently It is blocking itself
going against the 11g database. Sessions are blocking other sessions. We are
looking into any possible database parameters new to 11g that cause this
behavior to be different from our production 10g RT database.
--
Shawn Plummer
Systems Manager | SUNY Geneseo
South Hall 119 | 585-245-5577 | http://www.geneseo.edu/cit
--
RT Training - Boston, September 9-10
http://bestpractical.com/training
[rt-users] Change Management Multiple Owners
Hello, I am trying to implement CM solution using Request Tracker. I am using version 4.0.4. Is there any way I can add multiple owners to approve tickets instead of just one? I know there is an "AdminCC group" option for version 4.0.5 or later. This is not an option for us at this time. Is there any way to do this without updating RT? All the best, Aaron -- View this message in context: http://requesttracker.8502.n7.nabble.com/Change-Management-Multiple-Owners-tp57759.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Slow ticket loading....
Michelle Sullivan wrote:
> Michelle Sullivan wrote:
>
>> Alex Vandiver wrote:
>>
>>
>>> On 05/13/2014 05:39 AM, Michelle Sullivan via RT wrote:
>>>
>>>
>>>
[snip]
>>> This message was rejected from rt-users because it was over 1M of
>>> logfiles. Please don't send large messages to the list; you're welcome
>>> to provide a link to complete logs for those interested in them, of course.
>>>
>>>
>>>
>> I actually didn't know the size (though I knew it might be bigger than
>> acceptable by the list software - figured some intelligent person would
>> choose to deal or allow it ;-) )
>>
>>
>>
>>>
>>>
>>>
Here's the result of what RT4 does to the DB (note: RT3.8 does *NOT*
suffer the same problems - as am running that and just trying to
upgrade.. Also note: RT 4.0.19 on Apache 2.2 with ModPerl2 running
against some very fast PostgreSQL 8.4.10 DBs (cluster of 4 servers) -
round trip to them is around 25-50ms)... the query log for a *SINGLE*
ticket follows...
>>> This only occurs on the first request; DBIx::SearchBuilder calls
>>> DBI->column_info to determine the set of columns for each RT table, to
>>> be able to use them in the GROUP BY. It then caches the information;
>>> none of the queries to pg_constraints should happen after the first request.
>>>
>>>
>>>
>> Yeah - i'm seeing this every time a ticket is loaded - so RT/DBIx is not
>> caching it... and that's probably because the IDs are different - so
>> even pgpool/memcached setup can't cache it...
>>
>>
>>
>>> There are two fixes to this; one is to find a way to not call
>>> DBIx::SearchBuilder->Fields, which is what calls DBI->column_info, which
>>> causes the slow queries. RT is currently using the set of columns so
>>> obtained to pass to GROUP BY to perform both a DISTINCT and ORDER BY; Pg
>>> 9.1 is smart enough to know that grouping by the primary key is enough
>>> to imply the remaining columns as well[1]. As such, the attached patch
>>> (which has only been briefly tested) may suffice.
>>>
>>>
>>>
>> I'm on 8.4 will that work as well, or should I not bother? (I can't
>> upgrade to 9.1 yet, as much as I want to - the software on the system is
>> in the hands of the Operations team and controlled by puppet so 8.x ->
>> 9.x is impossible without corrupting everything or Operations input).
>>
>>
>
> FYI it appears every new connection to the DB is causing
> DBI->column_info to be called. On the 'in test' system this happens a
> lot .. page loads when it opens a new connection is +4 minutes...
> regardless of the page.
>
> It's quite usable with and without pgpool (it's faster without) - except
> when a new connection is opened.
>
>
So, I have my individual ticket load times running 4 times faster
(minimum) with the following patch to DBIx::SearchBuilder:
--- DBIx/SearchBuilder/Handle.pm.orig2014-06-24 05:21:54.0 -0500
+++ DBIx/SearchBuilder/Handle.pm2014-06-24 05:21:41.0 -0500
@@ -1429,14 +1429,16 @@
sub Fields {
my $self = shift;
my $table = shift;
+my $lctn = lc $table;
-unless ( keys %FIELDS_IN_TABLE ) {
-my $sth = $self->dbh->column_info( undef, '', '%', '%' )
+unless ( keys %FIELDS_IN_TABLE && exists $FIELDS_IN_TABLE{$lctn} ) {
+my $sth = $self->dbh->column_info( undef, '', $table, '%' )
or return ();
my $info = $sth->fetchall_arrayref({});
foreach my $e ( @$info ) {
-push @{ $FIELDS_IN_TABLE{ lc $e->{'TABLE_NAME'} } ||= [] },
lc $e->{'COLUMN_NAME'};
+push @{ $FIELDS_IN_TABLE{ $lctn } ||= [] }, lc
$e->{'COLUMN_NAME'};
}
+$FIELDS_IN_TABLE{ $lctn } ||= []; # empty list so we don't call
column_info() again.
}
return @{ $FIELDS_IN_TABLE{$lctn } || [] };
I don't know how much this will break (if anything) but the 1000's of
queries is dropped to just a few when calling Fields().
What I know it will break is if you call Fields with a table name not
matching the case of the table in the DB (for the first call) it will
not return the table and it will block returning the table after that -
even if you subsequently call with the correct case... which is because
of using the "lc $table" (in the original: lc $e->{'TABLE_NAME'}) ...
which should not be done as in PostgreSQL you can have Table1, table1,
and taBLE1 as valid tables (though they are probably a bad idea) in the
same DB and schema It should be case sensitive so dropping all the
'lc's would be a good idea in my opinion (if nothing else because having
2 table names the same but different case and definition will result in
Fields being the wrong values for at least one of the tables.)
Jesse, thoughts?
--
Michelle Sullivan
http://www.mhix.org/
--
RT Training - Boston, September 9-10
http://bestpractical.com/training
[rt-users] how to unset a ticket's Due date?
I'm trying to remove a Due date from a ticket. Historically, entering "-" or "0" into the field worked fine for me. When I try this now however (RT v4.2.5), the page just reloads and the date doesn't get removed. Neither "not set" nor just whitespace have any effect when entered either. Nothing amazing is showing up in the logs: [...] [warning]: Couldn't parse date '-' by Time::ParseDate (.../RT/Date.pm:231) [...] [warning]: Couldn't parse date 'not set' by Time::ParseDate (.../RT/Date.pm:231) What's the "official" way to remove a Due date from a ticket now? -- RT Training - Boston, September 9-10 http://bestpractical.com/training
