In RetryStrategy.ExponentialBackoff, when “request.status !== 0” return -1, and then stop retry. Maybe should be “request.status == 0”?
I think “== 0” means error; but “!== 0” dosen’t means no error(still 100、200、300、400…) ,right?
Actually not, !== 0 means no error:
Before the request completes, the value of status is 0. Browsers also report
a status of 0 in case of XMLHttpRequest errors.
from:
1 Like
Is conflict？ For example， if status is 500， conform to “!== 0”， means no error?
I think ==0 means error,but !==0 doesn’t mean no error.
the thing is
In babylon， whether there is timeout mechanism when load mesh? For example, if I load a gltf mesh, maybe I will wait 1 minute（or 1 year） but cant listen the onSuccess callback and cant listen the onError callback too?
For example , I get a 500 status , I can`t start retry because 500!==0. You mean is I should get a 0 status before 500 status?
A status of 0 often means there is some kind of network error that occurred (i.e., something went wrong with the router or the internet is flaky, etc.), and retrying would benefit. If you have an actual client/server error, retrying probably won’t fix it. The default just checks for 0 and retries that. If you want it to do something different, you can simply set BABYLON.Tools.DefaultRetryStrategy to do something else.
Thank you very much.
Ablout timeout and retry mechanism , gltf loader has it? Sometimes, I load a gltf, but I can’t listen onError callback and wait forever.
glTF loader uses BABYLON.Tools.LoadFile which uses the retry strategy. All loading goes through this mechanism.
Has timeout mechanism？ How long ？If time out， will retry or call onError？ I don’t find the code in LoadFile.
Return the wait time in the retry strategy. If you want to stop retrying, return -1 and it will error out. I added some better description to the comments.
1 Like
I see the fileTool uses XMLHttpRequest to request file, but the XMLHttpRequest
object doesn`t set timeout value （default value means no time out ）. In other world, I may wait forever if network trouble instead of listen onError or retry, because onReadyStateChange dosen’t be call. Right?
Right, we don’t set the timeout property. It can be added if you think it will be useful. I would guess that the network environment doesn’t wait forever, so somewhere along the way, something will timeout even if XHR doesn’t set a timeout.
Thank you very much.
This is helpful for me. 
1 Like