[MAGNOLIA-1667] Updatemech : the whole process should be running in a separate thread Created: 07/Aug/07 Updated: 23/Jan/13 Resolved: 17/Nov/07 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | updatemechanism |
| Affects Version/s: | None |
| Fix Version/s: | 3.5 RC1 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Magnolia International |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Template: |
|
||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Description |
|
Threading: the whole process should happen in a separate thread rather than during the request. This would help avoiding time outs and conflicts. (any access to the page, once the process is started, would just display the current state, i.e the list of tasks which have been executed, for instance) |
| Comments |
| Comment by Magnolia International [ 05/Nov/07 ] |
|
Started on svn. |
| Comment by Magnolia International [ 06/Nov/07 ] |
|
ui : for now, we'll just simply auto reload the page every 3 seconds. |
| Comment by David Smith [ 06/Nov/07 ] |
|
Comment from the peanut gallery – I'd loosen it up to between 10 and 15 seconds between reloads. 3 seconds just seems like busy work when updating all the modules easily takes a few minutes. |
| Comment by Magnolia International [ 06/Nov/07 ] |
|
Actually, out of 90 tasks needed for a complete install (current trunk), only 18 take longer than 100ms to execute, and just 3 are above 1sec (bootstrapping lots of data). These figures are not taking the repository save operations into account, but still make 3sec refresh seem reasonable to me. You should try the latest trunk, which shows a counter of how many tasks have been executed (with the total to be executed)... seems like 10 seconds or more would be too "slow" with regard to the progress that's actually made in 3 seconds. WDYT? |
| Comment by David Smith [ 06/Nov/07 ] |
|
I loaded up a fresh copy this morning – 88 tasks. I like the update page as opposed to the wait and pray method of initializing 3.0.x and previous – very nice. It actually threw me a little – I thought something was wrong when I saw only a 5k debug log after deployment. You're right – it seemed like the vast majority of tasks went quickly with only a few long running tasks (typically bootstrapping). I'll build again tomorrow morning and see how the 3 second thing works if you have it committed in SVN. |
| Comment by Magnolia International [ 06/Nov/07 ] |
|
yep, it's on svn since about the comment to which you replied |
| Comment by David Smith [ 07/Nov/07 ] |
|
Ok... just tested it. It works, but I would still loosen the timing a little. In particular, the IE tick every time the page loads is annoying. Even 5-6 seconds isn't an unreasonable delay in returning an updated page. Longer term, I vote for an AJAX method w/ progress bar. It should eliminate the IE tick and look nicer. |
| Comment by Magnolia International [ 17/Nov/07 ] |
|
David: yeah, we considered an ajax-based solution, but time constraints and the fact that we wanted to stay as independent from anything as possible made us stick to the simple solution. |