Viliam Durina
Viliam Durina
In the run from the Oct 23 the logged events were this: ``` 2020-10-23 13:21:19,675 [DEBUG] [hz.boring_hellman.cached.thread-13] [c.h.j.i.MasterJobContext]: [127.0.0.1]:5701 [1ec5ecfd-48b0-4fdf-962a-3e09a8dc53a6] [4.4-SNAPSHOT] Executing job '0529-a68f-6da9-0001', execution 0529-a68f-6daa-0001 2020-10-23 13:21:19,675 [ INFO]...
Fixed one cause in #2722, see description there. But I observed different causes too, I expect more failures in the future.
What's the Jet version?
Maybe you have high allowed lag or very sparse data. Can you share your code or a reproducer? Without them it will be wild guesses.
This is because the `Tuple2` isn't java-serializable. We serialize the processor suppliers using the java serialization. If a java-serialized object (the processor supplier) refers to an object that's not java-serializable,...
The second cause was pretty clear to me, but I spent like 5 hours trying to figure out how it could happen in current code, only to realize (credits @mtopolnik)...
There's no much we can do about it. If the result type is an update count, we can't send the response with queryId to the client earlier before the command...
Nope, and we don't plan it. Could you please describe your use case? Maybe we'll change our mind.
In our model your query always means that it's a streaming query. We could consider these options: - A function that returns currently available offsets from a topic ```sql SELECT...
@neilstevenson As I said, you can't use `NOW()` because it would return a different value for each invocation :). But that's yet to be implemented.