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
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
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 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:
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
You were right. Caching did turn out to be the problem. We tried
SearchBuilder 1.56 just out of curiosity and that did not help. Finally,
with the help of a colleague, we went back to modifying _CacheConfig()
and tried setting the cache_for_sec key in
/usr/share/request-tracker3.6/lib/RT/Record.pm to:
cache_for_sec => -1
apparently 0 and -1 have a totally different meaning. I could not find
any documentation on this and we are continuously looking to see what
the difference is. However, testing for at least a couple of hours
constantly taking/untaking tickets and reading the Owner always returns
the correct value.
Hopefully this saves someone else the trouble as well. One previous post
in the RT-Users mailing list that gave us a few hints follows:
Carbon60: Managed Cloud Services
We experimented a bit and decided to not override the Record.pm file
globally (so as to leave RT’s code pristine), and instead chose to
override the _CacheConfig subroutine in our startup.pl file for mod_perl:
BEGIN {
use RT;
use RT::Ticket;
*RT::Ticket::_CacheConfig = sub {
{
cache_p => 1,
cache_for_sec => -1
}
};
}
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
H. Dawood
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 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:
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
You were right. Caching did turn out to be the problem. We tried
SearchBuilder 1.56 just out of curiosity and that did not help. Finally,
with the help of a colleague, we went back to modifying _CacheConfig() and
tried setting the cache_for_sec key in
/usr/share/request-tracker3.6/lib/RT/Record.pm to:
cache_for_sec => -1
apparently 0 and -1 have a totally different meaning. I could not find any
documentation on this and we are continuously looking to see what the
difference is. However, testing for at least a couple of hours constantly
taking/untaking tickets and reading the Owner always returns the correct
value.
Hopefully this saves someone else the trouble as well. One previous post in
the RT-Users mailing list that gave us a few hints follows:
Carbon60: Managed Cloud Services
We experimented a bit and decided to not override the Record.pm file
globally (so as to leave RT’s code pristine), and instead chose to override
the _CacheConfig subroutine in our startup.pl file for mod_perl:
BEGIN {
use RT;
use RT::Ticket;
*RT::Ticket::_CacheConfig = sub {
{
cache_p => 1,
cache_for_sec => -1
}
};
}
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
H. Dawood
Thank you for the follow-up. I took a quick look at the Cacheable
module in SearchBuilder. I had a function called FlushCache() with
the obvious definition. Maybe you could call it after setting the
Owner and avoid the need for disabling the caching completely.
Cheers,
Ken
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
You were right. Caching did turn out to be the problem. We tried
SearchBuilder 1.56 just out of curiosity and that did not help. Finally,
with the help of a colleague, we went back to modifying _CacheConfig() and
tried setting the cache_for_sec key in
/usr/share/request-tracker3.6/lib/RT/Record.pm to:
cache_for_sec => -1
apparently 0 and -1 have a totally different meaning. I could not find any
documentation on this and we are continuously looking to see what the
difference is. However, testing for at least a couple of hours constantly
taking/untaking tickets and reading the Owner always returns the correct
value.
Hopefully this saves someone else the trouble as well. One previous post in
the RT-Users mailing list that gave us a few hints follows:
Carbon60: Managed Cloud Services
We experimented a bit and decided to not override the Record.pm file
globally (so as to leave RT’s code pristine), and instead chose to override
the _CacheConfig subroutine in our startup.pl file for mod_perl:
BEGIN {
use RT;
use RT::Ticket;
*RT::Ticket::_CacheConfig = sub {
{
cache_p => 1,
cache_for_sec => -1
}
};
}
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
H. Dawood
Thank you for the follow-up. I took a quick look at the Cacheable
module in SearchBuilder. I had a function called FlushCache() with
the obvious definition. Maybe you could call it after setting the
Owner and avoid the need for disabling the caching completely.
Cheers,
Ken
I just tried the above on the $ticket object responsible for SetOwner(),
however, within just 2 tries I was able to replicate the issue.
I checked to make sure I’m calling FlushCache() on the right object as
well. It seems like RT::Ticket is extending RT::Record which extends
DBIx::SearchBuilder::Record::Cacheable so I am assuming what I did was
correct, however if not, would you kindly correct me please?
The $ticket object is instantiated as:
my $current_user = RT::CurrentUser->new();
$current_user->LoadByName(‘ticket_user’);
my $ticket = new RT::Ticket( $current_user );
H. Dawood