3 ms·
Looking quickly at the code myself: > - The API supports GET/PUT/DELETE (no range queries). There are range query on keys: # list keys starting with "we" cur
by rakoo 6y ago
Looking quickly at the code myself:
> - The API supports GET/PUT/DELETE (no range queries).
There are range query on keys:
# list keys starting with "we"
curl -v -L localhost:3000/we?list
> - There's no handling of errors from the volume servers
If a GET/PUT/DELETE fails it is communicated to the master server, who doesn't write anything in its own database
All in all I believe it does quite a lot for less than 1000 lines already. Knowing its limitations I'm curious to see how well it handles production usage
- codefined 6y ago> There are range query on keys I took it to mean the webserver doesn't support "HTTP range requests"[0], as opposed to ranges of keys. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requ...
- judofyr 6y ago> # list keys starting with "we" curl -v -L localhost:3000/we?list Ah, I missed this! > If a GET/PUT/DELETE fails it is communicated to the master server, who doesn't write anything in its own database Yes, but there's no protocol for cleaning it up. Example: If the second replica fails to store it, then the first replica will still have the data and there doesn't seem to be a way that it will be removed. This might end up "leaking" storage. Also, if you then attempt to do a rebuild it seems to me that the file will be revived. > All in all I believe it does quite a lot for less than 1000 lines already. Oh sure. I wasn't trying to be negative. I think it's great that people play around with these ideas! Distributed systems are complicated beast, and there's only so much you can do in 1000 lines. Another thing I realized: It buffers all received values in-memory in the master server. You might need quite a lot of memory if you intend handle uploads of big files in parallel.