The message browser needs added scalability... Server side toggle for loading of data will help with the initial load time. Smaller queries could be used to fill out the browser only as data is requested. We should also avoid grabbing transmission data before the popup xslt needs it.
Logged In: YES
user_id=1831833
Originator: YES
"Enabled server side toggle for tree2 in messageTree.jsp. Added private variable to store tree data in SSTPTreeBean to reduce queries to load data from DB. Changed scope to session to keep tree data stored for login." in r636
Still needs work on sorting of messages (possibly divide into groups by time/number etc), still looking into incremental queries for partial data.
Logged In: YES
user_id=1831833
Originator: YES
Implemented message sorting by timestamp (r657)... Evaluated runtime of methods and found that sort and queries execute without almost any lag. It seems that the code to sort messages into an organized tree is the issue. It seems to have caused about 70-80% of the slowdown involved in loading the message browser. This might have to be remedied with a rewrite or some new methods in the SSTPTreeBean implementing lazy loading, there is some brief mention of it here: http://wiki.apache.org/myfaces/Tree2
Logged In: YES
user_id=1831833
Originator: YES
A possible alternative to lazy loading would be to rewrite getTreeData in SSTPTreeBean so that it would be able to check for changes to locale or particular message counts for one transmitter. This would allow the tree to rebuild only *portions* of itself when data changed, versus rebuilding the whole structure even when a single transmitter's pending ack becomes an ack. Variables pointing to specific root nodes for each transmitter and message type could probably be obtained from the tree data to make this easier/faster... This may be a more attractive solution as it would reduce/eliminate the need for the jsp to be modified.
Logged In: YES
user_id=186471
Originator: NO
Revert to unassigned.