It has come to my attention that Installer is acting up, and I suspect the 3.1 update is to blame for this. Here's a brief of what I've observed...
As you may know, if you launch Installer from shell, you can see the debug outputs.
As of 3.1, we (myself, and a few other geeks that are working on Cydia and new Repo Source crawler) noticed that Installer now attempts to reload 4 sources at a time instead of 1 at a time. In theory, this is a good move, and it should drastically help the reload time. However, further reviews have shown that this change in their code have actually cause Installer to, in fact, slow down.
This forking process, if designed properly, will be able to help Installer to reload MUCH MUCH more quickly, and you may not even need Repo Source any more. However, we noticed a very odd bug with this process NullRiver have added... Here's a brief of what IS suppose to happen, versus what is ACTUALLY happening.
As you may know, if you launch Installer from shell, you can see the debug outputs.
As of 3.1, we (myself, and a few other geeks that are working on Cydia and new Repo Source crawler) noticed that Installer now attempts to reload 4 sources at a time instead of 1 at a time. In theory, this is a good move, and it should drastically help the reload time. However, further reviews have shown that this change in their code have actually cause Installer to, in fact, slow down.
This forking process, if designed properly, will be able to help Installer to reload MUCH MUCH more quickly, and you may not even need Repo Source any more. However, we noticed a very odd bug with this process NullRiver have added... Here's a brief of what IS suppose to happen, versus what is ACTUALLY happening.
What is suppose to happen:
1) Installer is suppose to check first 4 (in its internal ordering) of your sources
2) Installer opens 4 threads to request them sources
3) When each returns, it should parse that XML, and update its local database, and when completed, seek out the next source
4) When no data have been received for a certain time window (30 seconds typically), thread should assume the source is down, unavailable, or extremely slow, and move on to the next source.
5) Repeat process until all sources have been processed.
What is acrually happening right now:
1) Installer attempts to check the first 4 of your sources
2) Installer opens 4 threads to request them sources ... HOWEVER, for reasons beyond any of us can figure out, it appears that some of these threads dies, or halts.
3) When one of the source is completed, it parses it, BUT it does not move on to the next one in database... instead, it waits until all 4 sources are "complete" (or time out) before continuing.
4) Repeat process until all sources have been processed.
Two major flaws in this design:
1) Threads shouldn't die and not make the request at all... They should really check what's causing the threads to die, or not make the request.
2) Threads should be smart enough to move on to the next few, instead of waiting on the entire batch to complete, and then move on to the next four.
Seeing that it took them well over 8 months (September til now) to implement this design, I wouldn't recommend holding your breath for them to fix this issue, at all.
So, as the end line user, what can you do to prevent this kind of issue from ruining your Installer experience? Unfortunately, not a whole lot. You can... well, in fact, you SHOULD use meta repositories such as Repo Source to reduce the amount of sources and amount of packages you have in your Installer, to help the overall loading process. However, it won't be of too much help if Repo Source's thread randomly gets killed by Installer. And until NullRiver fixes this bug, there is no work around for this problem, too.
1) Installer is suppose to check first 4 (in its internal ordering) of your sources
2) Installer opens 4 threads to request them sources
3) When each returns, it should parse that XML, and update its local database, and when completed, seek out the next source
4) When no data have been received for a certain time window (30 seconds typically), thread should assume the source is down, unavailable, or extremely slow, and move on to the next source.
5) Repeat process until all sources have been processed.
What is acrually happening right now:
1) Installer attempts to check the first 4 of your sources
2) Installer opens 4 threads to request them sources ... HOWEVER, for reasons beyond any of us can figure out, it appears that some of these threads dies, or halts.
3) When one of the source is completed, it parses it, BUT it does not move on to the next one in database... instead, it waits until all 4 sources are "complete" (or time out) before continuing.
4) Repeat process until all sources have been processed.
Two major flaws in this design:
1) Threads shouldn't die and not make the request at all... They should really check what's causing the threads to die, or not make the request.
2) Threads should be smart enough to move on to the next few, instead of waiting on the entire batch to complete, and then move on to the next four.
Seeing that it took them well over 8 months (September til now) to implement this design, I wouldn't recommend holding your breath for them to fix this issue, at all.
So, as the end line user, what can you do to prevent this kind of issue from ruining your Installer experience? Unfortunately, not a whole lot. You can... well, in fact, you SHOULD use meta repositories such as Repo Source to reduce the amount of sources and amount of packages you have in your Installer, to help the overall loading process. However, it won't be of too much help if Repo Source's thread randomly gets killed by Installer. And until NullRiver fixes this bug, there is no work around for this problem, too.
Leave a comment