Hi Denis, Maxim,
I'd like to clarify that I'm pretty sure to complete the tasks below before
the voting date:
https://issues.apache.org/jira/browse/IGNITE-13659
https://issues.apache.org/jira/browse/IGNITE-13796
I'll start to work on them right after the long Russian NY holidays.
But I'm not
Hi!
Ilya thanks for the reply! I agree that it's a valid case when a test is
part of multiple suites in different modules. But it is definitely a bug
that the test is written in a module where it can't be run at all and aimed
to run within different modules (core tests in core that require h2). I
Igniters,
I'm going to create the `ignite-2.10` release branch on Monday 28-th
December. Please, keep this in mind when merging issues to the master
branch.
I'll also exclude all issues with `Open`, `In progress` states from
the release. As for the `Patch Available` issues, we will discuss this
Stanilovsky Evgeny created IGNITE-13915:
---
Summary: Calcite improvements. Extend tests coverage, use both
client and server for starting queries.
Key: IGNITE-13915
URL:
Malchikov Fedor created IGNITE-13914:
Summary: wrong error message for bad selector (config get)
Key: IGNITE-13914
URL: https://issues.apache.org/jira/browse/IGNITE-13914
Project: Ignite
Hi!
>> I'm not sure that we should assume every test is only run from one test
suite. One test may be run from different test suites located in different
modules.
Agree. For example, if we introduce this limitation, zk suites will be
broken.
пт, 25 дек. 2020 г. в 14:48, Ilya Kasnacheev :
>
Kirill Gusakov created IGNITE-13913:
---
Summary: Corrupted poms in cli modules
Key: IGNITE-13913
URL: https://issues.apache.org/jira/browse/IGNITE-13913
Project: Ignite
Issue Type: Sub-task
Hello!
Sorry for the long wait.
I'm not sure that we should assume every test is only run from one test
suite. One test may be run from different test suites located in different
modules.
I wonder if we can drop this requirement, check all the modules
transitively for used/unused tests.
Hello, Ivan.
I’m +1 for your proposal.
> 25 дек. 2020 г., в 13:14, Ivan Daschinsky написал(а):
>
> Hi folks!
>
> Since we already have a separate repo for thin-clients [1], [2]
> I'd like to propose some improvements in development process/
>
> 1. We should simplify and automate unit tests
>> However, sometimes it can create excessive load for cluster in use cases
when there are a lot of thin clients.
Could you please provide some figures? I suppose, that our NIO server can
handle thousands connections easily, and problem
is not in multiple connections.
пт, 25 дек. 2020 г. в 11:33,
Kirill Tkalenko created IGNITE-13912:
Summary: Incorrect calculation of WAL segments that should be
deleted from WAL archive
Key: IGNITE-13912
URL: https://issues.apache.org/jira/browse/IGNITE-13912
Ivan Daschinskiy created IGNITE-13911:
-
Summary: asyncio version of python ignite thin client
Key: IGNITE-13911
URL: https://issues.apache.org/jira/browse/IGNITE-13911
Project: Ignite
Hi folks!
Since we already have a separate repo for thin-clients [1], [2]
I'd like to propose some improvements in development process/
1. We should simplify and automate unit tests run for different versions of
python
2. We should add travis integration per commit and pr. Tests could be run
Guys,
I've implemented Segmented-LRU page replacement algorithm and benchmarked
results, it gives some boost (5-10%) when page replacement is
heavily used, but, unfortunately, when replacement is not used it gives
about 2% drop compared to the current Random-LRU page replacement
implementation.
Igor,
The idea is to keep partition awareness enabled
even when the limit is reached, right?
So it works when the corresponding server is available,
and ignored otherwise.
I think this could be useful, but we should document it thoroughly,
so the negative effect on partition awareness
Rather strange, cause the repository on GitHub is only a mirror of Apache's
GitBox.
Although — I guess Apache applied the same policy to its repositories, if not
was it's author...
> On 22 Dec 2020, at 13:34, Pavel Tupitsyn wrote:
>
> Ivan, it is the new GitHub default
>
> "On Oct. 1, 2020,
16 matches
Mail list logo