| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Change revision type from `qint64` to `size_t` for LMDB in a couple of places (LMDB supports `unsigned int` or `size_t` which are `long unsigned int` on my machine)
- Better support for database flags (duplicate, integer keys, integer values for now but is extensible)
- Main databases' keys are now revisions
- Some databases switched to integer keys databases:
- Main databases
- the revision to uid mapping database
- the revision to entity type mapping database
- Refactor the entity type's `typeDatabases` method (if in the future we need to change the main databases' flags again)
- New uid to revision mapping database (`uidsToRevisions`):
- Stores all revisions (not uid to latest revision) because we need it for cleaning old revisions
- Flags are: duplicates + integer values (so findLatest finds the latest revision for the given uid)
~~Problems to fix before merging:~~
All Fixed!
- ~~Sometimes Sink can't read what has just been written to the database (maybe because of transactions race conditions)~~
- ~~Most of the times, this results in Sink not able to find the uid for a given revision by reading the `revisions` database~~
- ~~`pipelinetest`'s `testModifyWithConflict` fails because the local changes are overridden~~
~~The first problem prevents me from running benchmarks~~
Reviewers: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D14974
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was the problematic backtrace (the qsettigns lockfile resulted in a
message that tried to acquire the lock again.
Thread 1 (Thread 0x7f00417aee00 (LWP 530)):
0 0x00007f003eb9cae9 in syscall () from /lib64/libc.so.6
1 0x00007f003f85d22d in QBasicMutex::lockInternal() () from /lib64/libQt5Core.so.5
2 0x00007f0040ebce51 in QMutexLocker::QMutexLocker (this=0x7ffdb83e4678, m=0x7f004175ff40 <(anonymous namespace)::Q_QGS_sDebugAreaCollector::innerFunction()::holder>) at /usr/include/qt5/QtCore/qmutex.h:206
3 0x00007f00410ab681 in DebugAreaCollector::add (this=0x7f004175ff40 <(anonymous namespace)::Q_QGS_sDebugAreaCollector::innerFunction()::holder>, area="caldavresource.default") at /src/sink/common/log.cpp:269
4 0x00007f00410a6f4b in collectDebugArea (debugArea="caldavresource.default") at /src/sink/common/log.cpp:296
5 0x00007f00410a5b44 in Sink::Log::debugStream (debugLevel=Sink::Log::Warning, line=0, file=0x0, function=0x0, debugArea=0x7f003fabdfa0 "default", debugComponent=0x0) at /src/sink/common/log.cpp:379
6 0x0000000000406d8d in qtMessageHandler (type=QtWarningMsg, context=..., msg="Could not remove our own lock file \"/home/developer/.qttest/share/sink/debugAreas.ini.lock\" maybe permissions changed meanwhile?") at /src/sink/synchronizer/main.cpp:162
7 0x00007f003f8509be in qt_message_print(QtMsgType, QMessageLogContext const&, QString const&) () from /lib64/libQt5Core.so.5
8 0x00007f003f8529ec in qt_message_output(QtMsgType, QMessageLogContext const&, QString const&) () from /lib64/libQt5Core.so.5
9 0x00007f003f93eb40 in QDebug::~QDebug() () from /lib64/libQt5Core.so.5
10 0x00007f003f9b55ba in QLockFile::unlock() () from /lib64/libQt5Core.so.5
11 0x00007f003f959ffd in QLockFile::~QLockFile() () from /lib64/libQt5Core.so.5
12 0x00007f003f98f4e3 in QConfFileSettingsPrivate::syncConfFile(QConfFile*) () from /lib64/libQt5Core.so.5
13 0x00007f003f98fcee in QConfFileSettingsPrivate::sync() () from /lib64/libQt5Core.so.5
14 0x00007f003f985df9 in QSettings::~QSettings() () from /lib64/libQt5Core.so.5
15 0x00007f00410a8cd1 in QtSharedPointer::ExternalRefCountWithContiguousData<QSettings>::deleter (self=0x17e2890) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:255
16 0x00007f0040e7092b in QtSharedPointer::ExternalRefCountData::destroy (this=0x17e2890) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:157
17 0x00007f00410a8e2d in QSharedPointer<QSettings>::deref (dd=0x17e2890) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:461
18 0x00007f00410a8de9 in QSharedPointer<QSettings>::deref (this=0x7ffdb83e4ea8) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:456
19 0x00007f00410a8b75 in QSharedPointer<QSettings>::~QSharedPointer (this=0x7ffdb83e4ea8) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:313
20 0x00007f00410a9f23 in DebugAreaCollector::~DebugAreaCollector (this=0x7f004175ff40 <(anonymous namespace)::Q_QGS_sDebugAreaCollector::innerFunction()::holder>) at /src/sink/common/log.cpp:264
21 0x00007f00410a76b9 in (anonymous namespace)::Q_QGS_sDebugAreaCollector::innerFunction()::Holder::~Holder() (this=0x7f004175ff40 <(anonymous namespace)::Q_QGS_sDebugAreaCollector::innerFunction()::holder>) at /src/sink/common/log.cpp:283
22 0x00007f003eae172c in __run_exit_handlers () from /lib64/libc.so.6
23 0x00007f003eae185c in exit () from /lib64/libc.so.6
24 0x00007f003eacb252 in __libc_start_main () from /lib64/libc.so.6
25 0x00000000004064da in _start ()
Closes https://phabricator.kde.org/T9435
|
|
|
|
|
|
|
| |
The reason why we didn't notice was probably:
* we only use this table nowadays when we have no db layout.
* The only flag we ever set is the dupsort flag, and the return from a
failed int conversion of 0 is otherwise correct.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses two problems:
* A potential deadlock.
We had the following code inside a separately protected section:
dbiLocker.unlock();
//Here we could loos the readlock
QWriteLocker dbiWriteLocker(&sDbisLock);
If we lost the lock in between the two lines, the second thread that was
now holding a read-lock on sDbisLock could not enter the protected
section, which was a requirement to release the read-lock, and we'd thus
end up in a deadlock. This is solved using tryLock with intermediate
releases of the read-lock, allowing the original thread to finish.
* When failing to validate a dbi for the current transacation we
simply returned an invalid db (which then in this particular case broke
reading of revision uid's and type's), leading to queries not executing
as they should.
Both problems are unfortunately hard to reproduce, the adjusted test
at leaset allowed me to reproduce the deadlock situation sometimes.
To fix this cleanly we should probably just get rid of dynamic dbi
allocation for good.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This fixes the performance regressions to a state where we are roughly
at the same performance as pre Identifier (but not any better either).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Depends on D14289
- Fixes the `sinksh inspect …` command
- Introduces `isValid`, `isValidInternal` and `isValidDisplay` static functions in Key, Identifier and Revision
I still have to do a more extensive search for induced bugs in other commands
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D14404
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Depends on D14099
Notes:
- Tests pass without many modifications outside of resultset.cpp/.h
- `mGenerator` doesn't seem to be used?
Benchmarks
=========
Run benchmarks:
| Develop | D14099 | This patch |
| ---------------------------------- | ---------------------------------- | ---------------------------------- |
| Current Rss usage [kb]: 40700 | Current Rss usage [kb]: 38564 | Current Rss usage [kb]: 39112 |
| Peak Rss usage [kb]: 40700 | Peak Rss usage [kb]: 38564 | Peak Rss usage [kb]: 39112 |
| Rss growth [kb]: 15920 | Rss growth [kb]: 13352 | Rss growth [kb]: 13432 |
| Rss growth per entity [byte]: 3260 | Rss growth per entity [byte]: 2734 | Rss growth per entity [byte]: 2750 |
| Rss without db [kb]: 29736 | Rss without db [kb]: 29248 | Rss without db [kb]: 30100 |
| Percentage peak rss error: 0 | Percentage peak rss error: 0 | Percentage peak rss error: 0 |
| On disk [kb]: 10788 | On disk [kb]: 9140 | On disk [kb]: 8836 |
| Buffer size total [kb]: 898 | Buffer size total [kb]: 898 | Buffer size total [kb]: 898 |
| Write amplification: 12.0075 | Write amplification: 10.1732 | Write amplification: 9.83485 |
Test Disk Usage:
| Develop | D14099 | This patch |
| ----------------------------------- | ----------------------------------- | ----------------------------------- |
| Free pages: 412 | Free pages: 309 | Free pages: 312 |
| Total pages: 760 | Total pages: 599 | Total pages: 603 |
| Used size: 1425408 | Used size: 1187840 | Used size: 1191936 |
| Calculated key + value size: 856932 | Calculated key + value size: 702866 | Calculated key + value size: 702866 |
| Calculated total db sizes: 970752 | Calculated total db sizes: 954368 | Calculated total db sizes: 933888 |
| Main store on disk: 3112960 | Main store on disk: 2453504 | Main store on disk: 2469888 |
| Total on disk: 3293184 | Total on disk: 2633728 | Total on disk: 2650112 |
| Used size amplification: 1.66339 | Used size amplification: 1.68999 | Used size amplification: 1.69582 |
| Write amplification: 3.63268 | Write amplification: 3.49071 | Write amplification: 3.51402 |
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D14289
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D14099
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Only in TypeIndex, not in Index (since we might want to store something other than identifiers as values)
- We might want to do the same in the `SynchronizerStore` for localId ↔ remoteId indexes
Depends on D13735
Some quick benchmarks (against develop and D13735): {F6022279}
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D13902
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Use object oriented paradigm for Keys / Identifiers /Revisions
- "Compress" keys by using byte representation of Uuids
- Still some cleaning left to do
- Also run some benchmarks
- I'm questioning whether files other than entitystore (tests excluded) are allowed to access this API
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D13735
|
|
|
|
| |
We always run into that when starting a resource.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
resourceaccess.
The problem was (as excercised by the last test in resourcecontroltest),
that in this scenario we would:
* trigger a synchronization that starts the resource, and then goes into
a loop trying to connecting (KAsync::wait -> singleshot timer)
* trigger a shutdown that would probe for the socket, not find it, and
thus do nothing.
* exit the testfunction, which somehow stops qtimer processing, meaning
we are stuck in KAsync::wait.
For now this is fixed by simply not probing for the socket.
|
| |
|
| |
|
|
|
|
| |
Could be triggered by running the composerviewtest in kube.
|
| |
|
|
|
|
|
|
| |
shouldn't be visible yet.
Was reproducible in the initial sync of the caldav resource.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The case we ran into is the following:
* Fetching the full payload and marking all messages of a thread as read
happens simultaneously.
* The local modification to mark as read gets immediately overwritten
when the full payload arrives.
* Eventually the modification gets replayed to the server though (and
the reversal isn't because coming from the source), so on next sync the
situation fixes itself.
To be able to improve this we try to protect local modifications in that
properties that have been modified since baseRevision (which currently
isn't, but should be equal to the last to the server replayed revision)
are not overwritten. This conflict resolution strategy thus always
prefers local modifications. baseRevision is currently set to the
current maximum revision of the store at the time when the resource
creates the modification.
|
|
|
|
|
|
|
| |
If we get a fetchMore right between when the revision was updated and
the incrementalQuery actually running, we ended up loosing the update
because the result provider ended up with a too recent revision after
the additional initial query.
|
|
|
|
|
|
|
|
|
|
|
|
| |
set.
We might miss some updates.
This should not normally ever happen if we assume that we have a
transaction from start to finish of the query (the maxRevision() call
should be equivalent. We do have some cornercases in our lmdb
implementation that breaks transactions when new databases are opened,
so we try to be extra safe this way....
Let's see if it works.
|
| |
|
|
|
|
|
|
|
|
| |
* Modifications could result in index changes because we lost the
threadId due to remove + add. A modify was necessary (although we can
ignore it for the email case).
* The ThreadIndexer would try to lookup and potentially index threads
for empty parent ids, which is clearly wrong.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Notes:
- Introduces the concept of queries on multiple properties (which meant changing query's internals a bit)
- Dates are stored as well as the "reference" in the index to allow quick filtering without fetching the whole entity
- Buckets are weeks starting on Monday (guaranteed by the use of the Julian calendar)
- Some size improvements are definitely possible (dates are padded numbers again, not using integer databases, Julian calendar starts at a very old date, etc.)
Test Plan: Tested in querytest
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D13477
|