• Hey Guest, don't forget to VOTE on each RFC topic. Your voting determine Chevereto development! No votes, no development.
  • Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.

B2 Retry

A

ashkir

👽 Chevereto Freak
💡Describe your idea

B2 is weird in their uploads, and when they're "busy" or up to something they will reject said file upload with an internal server error. I'm getting hounded with hundreds of "External storage has failed >> Invalid resource type: resource (closed)" emails a day too that I can't seem to turn off.

👏Where did you saw this?
Backblaze suggests programming a "retry" feature to try again if it fails. I don't know if we can do this for Chevereto, but it'd be nice. https://www.backblaze.com/blog/b2-503-500-server-error/

🔥Interest outside our community
 
Upvote 0 Downvote
Hi,

I remember that we already had issues due to B2 503 code and we already use a SDK that implements the B2 suggested workaround. Basically, B2 should be supported with a job queue system because the current workaround (sleep) can only be triggered for a couple of seconds before the script has to halt execution.
What if, after getting a 503 and asking the dispatch server for a new URL, you try to upload and get ANOTHER 503 from the new vault? To address this unusual case, write your software to pause for a few seconds, then go back to the dispatch server. In this scenario, the user has hit a statistically unusual situation where the user was told to go to a vault with very little space left and somebody else got there and filled up that space. The second 503 is a sign the system is functioning as designed. Your program can elegantly handle it by going back to the dispatch server.
Click to expand...
^ You can't be forever sleeping, at some point you run out of remaining execution time. The only way to address multiple 503 is by implementing a job queue.

For me is very clear that your current usage profile is about to reach B2's bottleneck and I'm afraid that at some point it will became unusable for you.

You should look for alternatives as the alleged queue system won't be available until mid V4. 😕
 
I'm tempted to try and see if I can connect that library myself. However, are we crrently using gliterd or esac? Both of them exist in our current vendor files.

Alternatives are now way out of control cost-wise and this ended up being a better option for me.
 
You must log in or register to reply here.
Back
Top