Error+reading+uploaded+data:+ClientAbortException(:+Tag+mismatch!) - 32Įrror+reading+uploaded+data:+ClientAbortException() - 6 Error+reading+uploaded+data:+ClientAbortException(java.io.EOFException:+Unexpected+EOF+read+on+the+s - 1 (filters:!(),refreshInterval:(pause:!t:histogram))&indexPattern=phx1_ecs&type=histogramĬlientAbortException typically means we stopped getting data from the client. Error+reading+uploaded+data:+ClientAbortException( - 4648Įrror+reading+uploaded+data:+ClientAbortException(java.io.IOException:+Unable+to+unwrap+data%2C+invalid+status+%5BCLOSED%5D) - 960 (filters:!(),time:(from:'T02:histogram))&indexPattern=phx1_ecs&type=histogramī2 had a few 408 statuses (39).
Hi u/Celestial_User - I had engineering look at the logs on our side. Feels like even this single improvement is a strong recommendation of using B2 over S3 if you have the manpower bandwidth to use the less widely available code. I've read the work with the load balancer they had to implement to get s3 compatibility, which would possibly make it inherently less powerful, but official (modern) guidance from B2, and also mentioned several times in this sub to prioritize using S3 API over B2 API unless you are specifically using B2 specific functions. Aside from SHA1 now being verified correctly, there wasn't a single error during my reupload of my 28k files. I wanted to add in SHA1 to verify my files were uploaded correctly, but the library I wasn't using doesn't seem to be compatible with B2's required SHA1 api, so I decided to try using the code for B2 api instead. I originally wrote it using the S3 compatible API, and with around 28k files to upload, I would get around 200~500 connection errors when uploading.
I've been using B2 to serve as the backup for my home server, with custom wrote code that runs alongside my other stuff. Don't know if anyone else has had this experience.
0 kommentar(er)
