I have continued to research this issue (between local network disruptions).
While I have done many experiments to try and understand a rare download
failure of a 90mb payload cab file, I have focused on Rob's comment about
Burn's use of http being reliable 'with retries' (in contrast to BITS). I
originally used the WixBA as a template for creating my mba. So my
ResolveSource is similar to the WixBA ResolveSource, in regard to the
retries code.
private void ResolveSource(object sender, ResolveSourceEventArgs e)
{
int retries = 0;
this.downloadRetries.TryGetValue(e.PackageOrContainerId, out
retries);
this.downloadRetries[e.PackageOrContainerId] = retries + 1;
e.Result = retries < 3 &&
!String.IsNullOrEmpty(e.DownloadSource) ? Result.Download : Result.Ok;
}
When I review many logs, both successful and with download failures, I do
not see any evidence that there is any retry. I added log messages and
observed that when a package has more than one item the first retry
(retries==0) is the msi, the second retry (retires==1) is the next payload,
the third retry is the next payload, and if there are more payloads the
whole install fails. If any one of these downloads fails, say the msi
download fails while retries==0, then the whole setup fails without any
'retries'. By changing the above two lines in ResolveSource to use
e.PayloadId, I resolved this latter problem, since when the msi package is
downloaded both e.PackageOrContainerId and e.PayloadId are the same value.
(I don't know if this would be the case for a container.)
The problem with the 90 mb cab file failing to download happens rarely but I
do not think that issue is addressed by this change. I did not find a way
to increase the failure rate yet. When I severely restrict bandwidth in the
virtual switch or memory it seems to be less likely to fail. I have been
experimenting with adding retry code in CachePackageComplete, which based on
one experiment seems promising. I also looked at CacheVerifyComplete and
CacheAquireComplete.
Is the use of e.PackageOrContainerId rather than e.PayloadId a bug in WixBA?
(or maybe something that does not matter as long as WixBA does not have any
packages with more than two payloads.)
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Addressing-download-failures-in-Burn-driven-MSI-tp7597272p7597443.html
Sent from the wix-users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
