On Fri, Jun 25, 2010 at 08:21:55AM -0500, Hussam Dawood wrote:
> Hello,
>
> 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
>
I am not certain why a work-flow would first set the owner of a ticket
and then immediately try to get the owner using a query even though
the owner change completed without an error. I think you are running
into a whole host of caching effects that keep the whole application
from being totally DB limited. Caching is a huge win in most cases and
user education may be a better way of handling this issue than turning
off or disabling the caching. Maybe someone else will have some other
ideas.
Cheers,
Ken
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
