Alexei Scherbakov,
> After activation (in read-only mode or not) rebalancing is possible to
begin and the grid will not be free of updates until it's finished. So the
grid will not be in truly read-only mode even if cache updates are
prohibited. Probably it would be enough just wait until rebalanc
Kirill Tkalenko created IGNITE-12392:
Summary: Faster transaction rolled back when one of backup node
failed
Key: IGNITE-12392
URL: https://issues.apache.org/jira/browse/IGNITE-12392
Project:
Nikolay Izhikov created IGNITE-12393:
Summary: Thread pool queue system view
Key: IGNITE-12393
URL: https://issues.apache.org/jira/browse/IGNITE-12393
Project: Ignite
Issue Type: Sub-task
Mirza Aliev created IGNITE-12394:
Summary: Confusing message and thread dumps about ignored failures
Key: IGNITE-12394
URL: https://issues.apache.org/jira/browse/IGNITE-12394
Project: Ignite
Hello, Alexey.
Can we somehow highlight changes in Spark-2.4 module comparing to 2.3 one?
For now the changes look too huge for me (+11,681 −1).
Are we sure we want to add those huge piece of code to support two versions?
Can we extract unchanged parts(based on spark public API) and keep them in
Yes, as I mentioned above, you could observe the real changes after copying
of spark 2.3 module here, in special commit
The last commit
https://github.com/apache/ignite/pull/7058/commits/60386802299deedc6ed60bf4736e922201a67fb8
contains
real changes from Spark 2.3
пн, 25 нояб. 2019 г. в 17:28, Ни
Pavel, we need to inform the client when the task is completed, we need the
ability to cancel the task. I see several ways to implement this:
1. Сlient sends a request to the server to start a task, server return task
id in response. Server notifies client when task is completed with a new
request
Alex,
I have a simpler idea. We already do request id handling in the protocol,
so:
- Client sends a normal request to execute compute task. Request ID is
generated as usual.
- As soon as task is completed, a response is received.
As for cancellation - client can send a new request (with new requ
Hello, Igniters!
Alex Plehanov did the review, and I've reworked the implementation of the
issue [1] that is part of the IEP-38 [2].
Could somebody else do a review of the PR [3]?
Alex, thank you for the review!
1. https://issues.apache.org/jira/browse/IGNITE-11410
2. https://cwiki.ap
Pavel, in this case, we will mix entities from different layers (transport
layer and request body), it's not very good. The same behavior we can
achieve with generated on client-side task id, but there will be no
inter-layer data intersection and I think it will be easier to implement on
both clien
Alex,
> we will mix entities from different layers (transport layer and request
body)
I would not call our message header (which includes the id) "transport
layer".
TCP is our transport layer. And it is fine to use request ID to identify
compute tasks (as we do with query cursors).
> we still can
> And it is fine to use request ID to identify compute tasks (as we do with
query cursors).
I can't see any usage of request id in query cursors. We send query request
and get cursor id in response. After that, we only use cursor id (to get
next pages and to close the resource). Did I miss somethin
12 matches
Mail list logo
