Chunking ng#5102
Conversation
|
@ogoffart, thanks for your PR! By analyzing the annotation information on this pull request, we identified @ckamm, @jturcotte and @dragotin to be potential reviewers |
| void setSharedThis(AccountPtr sharedThis); | ||
| AccountPtr sharedFromThis(); | ||
|
|
||
| /// The user that can be used in dav url |
There was a problem hiding this comment.
please comment how this relates to the shibboleth user or the user name entered in the wizard
There was a problem hiding this comment.
I don't know exactly. the answer from @DeepDiver1975 on #engineering (17:26) was not enough for me to make a better comment.
Current limitations of this WiP - No resuming implemented yet - No parallel chunks - Hackish way to get the webdav paths
| return job; | ||
| } else { | ||
| auto job = new PropagateUploadFile(this, item); | ||
| static const bool isNg = !qgetenv("OWNCLOUD_CHUNK_NG").isEmpty(); // FIXME! use server version |
There was a problem hiding this comment.
I think it should be rather decided by a server capability. @DeepDiver1975 does the new chunking already add something to the capabilities?
There was a problem hiding this comment.
Yes of course, this is debug only right now.
|
Ready to be reviewed |
|
I think this code is not defensive enough, see my comment with regards to dynamic chunk sizes etc. Does the server always check transmission checksums by now? Also: Where are the tests for tx.pl and smashbox? |
This is not implemented yet. |
|
Latests commits added tests, and remove the extra chunks before starting an upload |
|
|
||
| AccountPtr sharedFromThis(); | ||
|
|
||
| /// The user that can be used in dav url |
There was a problem hiding this comment.
Can you add a comment explaining in what situations that would be different from credentials.user()?
There was a problem hiding this comment.
I don't know. I was just told it could be different and that i had to do an API call even when using the HTTPCrendentials.
@DeepDiver1975 Can you clarify?
| * slotComputeTransmissionChecksum() | ||
| * | | ||
| * v | ||
| * slotStartUpload() -> doStartUpload() |
| // (Only used from slotPropfindIterate/slotPropfindFinished because the LsColJob use signals to report data.) | ||
| QMap<int, quint64> _serverChunks; | ||
|
|
||
| quint64 chunkSize() const { return _propagator->chunkSize(); } |
There was a problem hiding this comment.
Well, the idea would be that we could do dynamic chunking, so they would be different.
|
|
||
| /* | ||
| State machine: | ||
|
|
| * If chunk == -1, returns the URL of the parent folder containing the chunks | ||
| */ | ||
| void setDeleteExisting(bool enabled); | ||
| QUrl chunkUrl(int chunk = -1); |
There was a problem hiding this comment.
minor: I'd prefer if there was a chunkFolderUrl() and a chunkUrl(int)
There was a problem hiding this comment.
yeah, that's true. But it's internal function anywaéy
| _propagator->_journal->setUploadInfo(_item->_file, pi); | ||
| _propagator->_journal->commit("Upload info"); | ||
| QMap<QByteArray, QByteArray> headers; | ||
| headers["OC-Total-Length"] = QByteArray::number(_item->_size); |
There was a problem hiding this comment.
When we're resuming - is there a way for us to know that the directory we're resuming with has the same OC-Total-Length?
There was a problem hiding this comment.
Yes, because the _transferId would be different (the size is xor'ed with it)
|
|
||
| quint64 fileSize = _item->_size; | ||
|
|
||
| quint64 currentChunkSize = qMin(chunkSize(), fileSize - _sent); |
There was a problem hiding this comment.
As pointed out above, in bad resumes fileSize might be smaller than _sent.
There was a problem hiding this comment.
No, because the file need to be identical.
|
|
||
| quint64 currentChunkSize = qMin(chunkSize(), fileSize - _sent); | ||
|
|
||
| if (currentChunkSize <= 0) { |
There was a problem hiding this comment.
<= 0 is a bit misleading, since this is a quint64
| Q_ASSERT(_jobs.isEmpty()); // There should be no running job anymore | ||
| _finished = true; | ||
| // Finish with a MOVE | ||
| // QString destination = _propagator->_remoteDir + _item->_file; // FIXME: _remoteDir currently is still using the old webdav path |
| return; | ||
| } | ||
|
|
||
| bool finished = _sent >= _item->_size; |
There was a problem hiding this comment.
Shouldn't sent > _item->_size be a fatal error? How would that happen?
There was a problem hiding this comment.
You are right, this can't happen, i'll replace with a ==
|
@guruz the client send the checksum header (for the whole file) in the MOVE operation. |
|
I'm working on a server patch that does whole file (not chunk) checksum verifying for chunking ng (only). |
|
|
||
| using namespace OCC; | ||
|
|
||
| class TestChunkingNG : public QObject |
There was a problem hiding this comment.
I see the tmp folder being polluted with folders named ChunkingNG-* - is there some cleanup missing?
root@ci:/tmp/ChunkingNgTest-AQJojC/A# ls -lh
total 287M
-rw-r--r-- 1 jenkins jenkins 287M Nov 11 02:34 a0
-rw-r--r-- 1 jenkins jenkins 4 Nov 4 02:35 a1
-rw-r--r-- 1 jenkins jenkins 4 Nov 4 02:35 a2There was a problem hiding this comment.
The cleanup is there if the test does not crash. But it seems that the test is crashing. need to investigate why.
As the file can be some hunreds of megabytes, allocating such big arrays may cause problems. Also make the timeout a bit bigger so the test can rununder valgrind.
|
Checksuming is a server issue and is orthogonal to this problem |
|
@SamuAlfageme This needs to be tested with a server 9.2 (e.g. a quite current master branch of the server), previous servers don't have this chunking ng support. |
|
@guruz noted, will do 😉 |
No description provided.