Bug #1265
closedStatistics server should process error trace in locking
0%
Description
Briefly, before passing to error trace visualizer, stats server stores a processed error trace and all needed sources to disc to files original and src correspondingly. Then read html representation from file processed. Note that these files are placed into data/trace directory inside stats server virtual host directory and they aren't unique.
So we need to check lock and lock something before error trace processing and unlock it after. Bug isn't critical since error traces aren't likely to be processed in parallel.
Updated by Pavel Shved over 13 years ago
How about just assigning different names to them?
And about "unlikely" and "locking"... well, first you think that it's unlikely, and then it strikes you from the back when you're making a quick-fix of something else...
Updated by Evgeny Novikov over 13 years ago
Pavel Shved wrote:
How about just assigning different names to them?
Any solution is appropriate :)
Updated by Evgeny Novikov over 13 years ago
I see that sizes of these files are rather large (may be about 10Mb) so we should not keep them by assigning different names - instead we can just lock those files that are required at appropriate moments.
Interesting fact that different tabs of one browser are executed consequently in error trace processing and there isn't such the problem. Just in case of artificial delay I have noticed the problem in opening error traces from different browsers.
Updated by Evgeny Novikov over 13 years ago
- Status changed from Open to Resolved
Fix is available in cdcea07 of gsoc-stats-server branch. Test in different cases and it seems to work.
Updated by Evgeny Novikov about 13 years ago
- Status changed from Resolved to Closed
- Published in build set to 6fd6348
It's in master now.
Updated by Evgeny Novikov about 13 years ago
- Published in build changed from 6fd6348 to cdcea07