[rt-users] Understanding behavior of Ticket->SetOwner()

Hussam Dawood hdawood at peer1.com
Fri Jun 25 09:21:55 EDT 2010


We are running a mod_perl2 (2.0.4) REST application (using apache 2.2.9) 
that handles various ticket operations for us using RT (rt-3.6.7 backed 
by MySQL 5.0.51a). These operations include creating tickets, setting 
owners, setting states, changing queues etc. The front-end to all of 
this is a simple web-form that allows for the above actions to take 
place as well as injecting some custom fields when creating the tickets.

We are having an issue with the SetOwner() portion of the ticket object, 
where sometimes if someone changes the ticket owner to someone else or 
'Nobody' and immediately queries the ticket again, the old owner is 
returned.  We are sure the SetOwner() action is not failing since 
querying the database immediately after the action shows the new OwnerId 
and no error code is returned from SetOwner() as well.

We are trying to track down where this issue is coming from. So far one 
thing we have figured out is that the more random the apache thread that 
is serving the 'GET' request is, the better our chances of getting fresh 
data (i.e. the newly set Owner). This is a little problematic since we 
have noticed that some user agents (say Firefox or Chrome) keep their 
connections open to the server (assuming this is due to KeepAlive) and 
get served by the same apache process for quite some time. This causes 
them to keep getting stale data for some time after the SetOwner() 
process has taken place.

We thought at first that our SearchBuilder package (SearchBuilder 1.54) 
may be the culprit here, however, setting the 'cache_for_sec' key under 
sub _CacheConfig {} from the default '5' seconds to '0' or '1' did not 
prove useful. We also tried the following settings under 
RT_SiteConfig.pm which did not resolve our issue either:

Set($UseTransactionBatch, 1); - both 0 and 1 - thinking that batching 
transactions was causing SetOwner() to take not take effect immediately

Set($WebFlushDbCacheEveryRequest, 0); - couldn't find much documentation 
on this but thought it might be relevant to our endeavors.

I am eager to find out if someone has run into this issue before or has 
suggestions for things we can try to eliminate this issue.

Thank you,
H. Dawood

More information about the rt-users mailing list