Hello!
I had a similar post before. But I feel that it getting worse. In the
example I pressed quickly first “take” and then “resolved” . The result
is the ticket is owned by nobody and resolved?!?!?!
The history:
Fri Nov 05 14:11:50 2004 sternber - Given to Nobody
Fri Nov 05 14:11:48 2004 sternber - Status changed from open to
resolved
Fri Nov 05 14:11:44 2004 sternber - Taken
My config:
Debian sarge/RT 3.0.11
2 XEON proccessor machine
My idea is that because the http protocol is stateles the
RT is not able to serialize the task in the right order, so
while the “take” process is running, the “resolved” task
has already finished. If this is true, RT has a BIG problem!
Or could it be the apache config???
best regards!
Hi,
I have seen the same process and it doesn’t seem to be problem. Go look
at the ticket again. I’ll eat my shirt if both transactions didn’t
actually occur. I find that sometimes if you go “too fast”, the
information isn’t completely up to date in your web browser. The database
has completed the transactions in the correct order. I would suggest you
look at your transaction logs to verify this, but for us on a Debian
system, the serialization exists.
Ramon Kagan
York University, Computing and Network Services
Information Security - Senior Information Security Analyst
(416)736-2100 #20263
rkagan@yorku.ca
I have not failed. I have just I don’t know the secret to success,
found 10,000 ways that don’t work. but the secret to failure is
trying to please everybody.
- Thomas Edison - Bill Cosby
----------------------------------- ------------------------------------On Fri, 5 Nov 2004, Sven Sternberger wrote:
Hello!
I had a similar post before. But I feel that it getting worse. In the
example I pressed quickly first “take” and then “resolved” . The result
is the ticket is owned by nobody and resolved?!?!?!
The history:
Fri Nov 05 14:11:50 2004 sternber - Given to Nobody
Fri Nov 05 14:11:48 2004 sternber - Status changed from open to
resolved
Fri Nov 05 14:11:44 2004 sternber - Taken
My config:
Debian sarge/RT 3.0.11
2 XEON proccessor machine
My idea is that because the http protocol is stateles the
RT is not able to serialize the task in the right order, so
while the “take” process is running, the “resolved” task
has already finished. If this is true, RT has a BIG problem!
Or could it be the apache config???
best regards!
The rt-users Archives
Be sure to check out the RT wiki at http://wiki.bestpractical.com
Sven Sternberger wrote:
Hello!
I had a similar post before. But I feel that it getting worse. In the
example I pressed quickly first “take” and then “resolved” . The result
is the ticket is owned by nobody and resolved?!?!?!
The history:
Fri Nov 05 14:11:50 2004 sternber - Given to Nobody
Fri Nov 05 14:11:48 2004 sternber - Status changed from open to
resolved
Fri Nov 05 14:11:44 2004 sternber - Taken
My config:
Debian sarge/RT 3.0.11
2 XEON proccessor machine
My idea is that because the http protocol is stateles the
RT is not able to serialize the task in the right order, so
while the “take” process is running, the “resolved” task
has already finished. If this is true, RT has a BIG problem!
It’s cache. RT has per apache process records cache(not shared).
Model of your situation:
2 apache processes:
- load ticket, owner is nobody, record cached in first process
- take ticket, record cached in second process
- load resolve page, ticket in cache has owner nobody, in result you
get nobody in owner select box, submit, RT updates ownership.
Solution: turn off cache with DontCacheSearchBuilderRecords option in
the RT config. Very big perfomance pinalties are expected.
Why not just click the resolve button and change the owner drop down? Unless
you have a quick resolve link somewhere. In which case you’ll be activating two
change states from the same state. It’s less a problem with RT than just how
WWW interfaces are.
Sven Sternberger wrote:
Hello!
I had a similar post before. But I feel that it getting worse. In the
example I pressed quickly first “take” and then “resolved” . The result
is the ticket is owned by nobody and resolved?!?!?!
The history:
Fri Nov 05 14:11:50 2004 sternber - Given to Nobody
Fri Nov 05 14:11:48 2004 sternber - Status changed from open to
resolved
Fri Nov 05 14:11:44 2004 sternber - Taken
My config:
Debian sarge/RT 3.0.11
2 XEON proccessor machine
My idea is that because the http protocol is stateles the
RT is not able to serialize the task in the right order, so
while the “take” process is running, the “resolved” task
has already finished. If this is true, RT has a BIG problem!
Or could it be the apache config???
best regards!
The rt-users Archives
Be sure to check out the RT wiki at http://wiki.bestpractical.com
With regards,
Say_Ten
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to postmaster@multiplay.co.uk.
It’s cache. RT has per apache process records cache(not shared).
Solution: turn off cache with DontCacheSearchBuilderRecords option in
the RT config. Very big perfomance pinalties are expected.
Alternatively, a searchbuilder cache class with a shared memory cache.
Jesse Vincent wrote:
It’s cache. RT has per apache process records cache(not shared).
Solution: turn off cache with DontCacheSearchBuilderRecords option in
the RT config. Very big perfomance pinalties are expected.
Alternatively, a searchbuilder cache class with a shared memory cache.
I’ve tried ACL cache on shared memory, tests say that it’s not faster
then MySQL queries.
Test of CPAN modules that implements cache in shared memory say that
there is no good(fast, portable and solid) module.
I was very disappointed.
I see another variant: drop cache after each HTTP request. It wouldn’t
give much penalties and resolve this issue.
Best regards. Ruslan.
ps: I think someone from BestPractical should talk with Perrin Harkins
he had eaten dog on caching in mod_perl evironment.
Jesse Vincent wrote:
It’s cache. RT has per apache process records cache(not shared).
Solution: turn off cache with DontCacheSearchBuilderRecords option
in the RT config. Very big perfomance pinalties are expected.
Alternatively, a searchbuilder cache class with a shared memory cache.
I’ve tried ACL cache on shared memory, tests say that it’s not faster
then MySQL queries.
Test of CPAN modules that implements cache in shared memory say that
there is no good(fast, portable and solid) module.
I was very disappointed.
I see another variant: drop cache after each HTTP request. It wouldn’t
give much penalties and resolve this issue.
nod I’d been meaning to try to implement that one of these days.
Hi!
at the ticket again. I’ll eat my shirt if both transactions didn’t
hmm, yummi shirt 
!
actually occur. I find that sometimes if you go “too fast”, the
information isn’t completely up to date in your web browser. The database
has completed the transactions in the correct order.
no it hasn’t because. because if i surf to the ticket now IT IS owned
by nobody. And I have the “take” button". An other user reported
that he pressed “take” followed by “reply”, and the requestor got an
email from “Nobody”
I would suggest you
look at your transaction logs to verify this, but for us on a Debian
system, the serialization exists.
So I think yopu talk about /var/log/request-tracker3/rt.log
My problem is that we are getting a lot of tickets per day and
I have no clue what is the line to look for. I have debug enabled
but there are no “Take” and “Resolve” lines, Just “create”,“reply”
and “comment”.
Okay it seems to be not a debian thing. But do you also have a
2 Proccessor machine (which ht)? Do you have “KeepAlive” activated
in your httpd.conf?
Another things which worries me are some lines in the log
- Couldn’t prepare Open Tickets
(/usr/share/request-tracker3/lib/RT/Scrip_Overlay.pm:346)
- Encoding errors in I18N
best regards!
Do I understand correctly that “KeepAlive Off” is faster when
not using a proxy?
-ToddOn Fri, Nov 05, 2004 at 07:08:14PM +0300, Ruslan U. Zakirov wrote:
Sven Sternberger wrote:
Okay it seems to be not a debian thing. But do you also have a
2 Proccessor machine (which ht)? Do you have “KeepAlive” activated
in your httpd.conf?
Turn off keep alive. It would be faster unless you are using front-end
proxy.