The current model is to process blocks for attached views in sequence.
This is not ideal when the processing time for each view varies, or is
blocking (for example with replicated tables), as processing of next-in-line
view is blocked by wait in it's predecessor.
This commit changes the behavior to process 2 or more attached views concurrently.
The pre-existing optimization in the function
JSONEachRowRowInputStream::readColumnName() (that was extracted
during the refactoring step of PR#3144) imposed a restriction
on its usage - reading from the input stream might invalidate the return
value of that function, and this is what happenned in readJSONObject()
after the call to skipColonDelimiter().
One way of fixing the problem while preserving the original optimization
intact would be to defer the call to skipColonDelimiter() until the
variable name_ref was fully consumed, however that would result in worse
code (skipColonDelimiter() would need to be called in three different
places where it doesn't really belong).
Therefore I preferred to slightly weaken the optimization by always
copying the key name into the current_column_name data member.
This updated contrib/capnproto to a newer version that fixes problems with
unaligned access to message frames.
It also adds support for parsing Struct types as Tuple (named or unnamed),
and Nested array types.
The `struct X { a @0 :UInt64; b @1 :Text }` in Cap'nProto is equivalent to
`x Tuple(a UInt64, b String)` in ClickHouse.
Arrays of Struct types such as `y List(X)` are equivalent to `y Nested(a UInt64, b String)`.
This fixes two deadlocks in Kafka engine found previously:
* When exception is thrown before starting reading, consumer
was never returned to the storage. Now it is claimed only
when actually starting reading.
* Fixed lockup on deinitialization when consumer only unsubscribed,
but didn't close, and the endine then timeouted when waiting for
consumer destruction.
This also moves the stream thread to background worker pool.
The reason for that is that it will compete with other tasks for
time, so it will form a backpressure on insertion when the system
is busy.
