We also have this problem, where searching through the content of
tickets causes the session to lock up. If it is a lengthy search, the
browser needs to be closed and the cookies deleted. If it a short
search, it returns results and has no problems. I have found that
specify more search parameters speeds up the search (obviously), and
that avoids this problem most of the time. But there are times when you
need a more general search, and then you gamble with locking up the
session.
We also have this problem, where searching through the content of tickets
causes the session to lock up. If it is a lengthy search, the browser needs
to be closed and the cookies deleted. If it a short search, it returns
results and has no problems. I have found that specify more search
parameters speeds up the search (obviously), and that avoids this problem
most of the time. But there are times when you need a more general search,
and then you gamble with locking up the session.
The difference I see however is that in our case, either querying
‘Content LIKE “test”’ or ‘Subject LIKE “test”’ works fine seperately
and is generally very fast (a few seconds). However, when combined,
they never complete. Even after clearing the cookie or restarting the
browser, mysql will sit and chew on that query for as long as I’ve
ever waited (up to 10 minutes) and never complete. I would expect the
query to perhaps take twice as long as querying each item seperately,
but when a full content search takes 5 seconds I can’t understand why
additionally searching the subject would increase that to over 10
minutes.
Aaron
We also have this problem, where searching through the content of tickets
causes the session to lock up. If it is a lengthy search, the browser needs
to be closed and the cookies deleted. If it a short search, it returns
results and has no problems. I have found that specify more search
parameters speeds up the search (obviously), and that avoids this problem
most of the time. But there are times when you need a more general search,
and then you gamble with locking up the session.
It does very much look like the query engine is generating an incorrect
query (sticking the join inside an OR).
Jesse is right.
Below is the sql to search for content test or subject test in queue bla
and Status != rejected;
SELECT COUNT(DISTINCT main.id) FROM Tickets main , Transactions
Transactions_1, Attachments Attachments_2 WHERE
((Transactions_1.ObjectType = ‘RT::Ticket’)) AND ((main.EffectiveId =
main.id)) AND ((main.Status != ‘deleted’)) AND ((main.Type = ‘ticket’))
AND ( ( (main.Subject LIKE ‘%test%’)or ( (Attachments_2.Content LIKE
‘%test%’)AND(Attachments_2.TransactionId = Transactions_1.id)AND(main.id
= Transactions_1.ObjectId) ) ) AND(main.Queue = ‘37’)AND(main.Status !=
‘rejected’));
an explain gives:
id | select_type | table | type |
possible_keys | key | key_len | ref |
rows | Extra |
| 1 | SIMPLE | main | range |
PRIMARY,Tickets1,Tickets4,Tickets5 | Tickets1 | 15 | NULL
| 1545 | Using where |
| 1 | SIMPLE | Transactions_1 | ref |
PRIMARY,Transactions1 | Transactions1 | 64 | const |
504953 | Using where; Using index |
| 1 | SIMPLE | Attachments_2 | ALL |
Attachments2 | NULL | NULL | NULL |
1049069 | Using where |
what I found puzzling its not using any of the indexes on Attachamnet ,
these are there :
show index in Attachments;
| Table | Non_unique | Key_name | Seq_in_index | Column_name
| Collation | Cardinality | Sub_part | Packed | Null | Index_type |
Comment |
| Attachments | 0 | PRIMARY | 1 | id
| A | 1396546 | NULL | NULL | | BTREE
| |
| Attachments | 1 | Attachments2 | 1 | TransactionId
| A | 1396546 | NULL | NULL | | BTREE
| |
| Attachments | 1 | Attachments3 | 1 | Parent
| A | 33 | NULL | NULL | | BTREE
| |
| Attachments | 1 | Attachments3 | 2 | TransactionId
| A | 1396546 | NULL | NULL | | BTREE
| |
Any ideas ??
(rt-3.4.4 and mysql 4.1.14 and dbix: 1.33)
Roy
Jesse Vincent wrote:
We also have this problem, where searching through the content of tickets
causes the session to lock up. If it is a lengthy search, the browser needs
to be closed and the cookies deleted. If it a short search, it returns
results and has no problems. I have found that specify more search
parameters speeds up the search (obviously), and that avoids this problem
most of the time. But there are times when you need a more general search,
and then you gamble with locking up the session.
The difference I see however is that in our case, either querying
‘Content LIKE “test”’ or ‘Subject LIKE “test”’ works fine seperately
and is generally very fast (a few seconds). However, when combined,
they never complete. Even after clearing the cookie or restarting the
browser, mysql will sit and chew on that query for as long as I’ve
ever waited (up to 10 minutes) and never complete. I would expect the
query to perhaps take twice as long as querying each item seperately,
but when a full content search takes 5 seconds I can’t understand why
additionally searching the subject would increase that to over 10
minutes.
This is still biting us too. Mysql 4.1.18 + RT 3.4.5 + fastcgi
Has anyone found a workaround? Has it been fixed in the 3.6 release?
Thanks,
Brian
We also have this problem, where searching through the content of tickets
causes the session to lock up. If it is a lengthy search, the browser needs
to be closed and the cookies deleted. If it a short search, it returns
results and has no problems. I have found that specify more search
parameters speeds up the search (obviously), and that avoids this problem
most of the time. But there are times when you need a more general search,
and then you gamble with locking up the session.
It does very much look like the query engine is generating an incorrect
query (sticking the join inside an OR).
The rt-users Archives
Be sure to check out the RT Wiki at http://wiki.bestpractical.com
Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com
WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html
Has anyone tried this in 3.4.6? Was it fixed?
Thanks,
Brian