Hi Ilya,
Please let me know if I can help with any further iterations on the PR.
Regards,
Atri
On Wed, Apr 7, 2021 at 5:04 PM Atri Sharma wrote:
>
> Hi Ilya,
>
> Thanks for taking a look. I was able to resolve dependencies (Thanks,
> Sam!) and have updated the PR.
>
> Copying the jars from
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*Test with high flaky rate in master
LongDestroyDurableBackgroundTaskTest.testLongIndexDeletionWithRebalance
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*New Critical Failure in master Control Utility
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility?branch=%3Cdefault%3E
No changes in the build
Hi Denis!
The idea and prototype look great.
I'd like to highlight one arguable point. Default authorization
implementation still assumes there are permissions provided in
SecuritySubject. In turn, authentication is still responsible for filling
these permissions. I suggest decoupling
Taras Ledkov created IGNITE-14508:
-
Summary: Calcite integration: introduce SQL logical test runner
Key: IGNITE-14508
URL: https://issues.apache.org/jira/browse/IGNITE-14508
Project: Ignite
Sorry, I forgot to point the link
1. https://github.com/apache/ignite/pull/8989
чт, 8 апр. 2021 г. в 17:50, Denis Garus :
> Hello, Igniters!
>
> I want to propose to improve the way which we use
> to present permissions in Ignite 3.
>
> The model of permission in Ignite has a set of drawbacks.
Hello, Igniters!
I want to propose to improve the way which we use
to present permissions in Ignite 3.
The model of permission in Ignite has a set of drawbacks.
The main drawback, IMHO: if you need to add a new permission,
you should change the core module by extended the 'SecurityPermission'
Stanislav Lukyanov created IGNITE-14507:
---
Summary: Un-deprecate IGNITE_BINARY_SORT_OBJECT_FIELDS
Key: IGNITE-14507
URL: https://issues.apache.org/jira/browse/IGNITE-14507
Project: Ignite
Hello Ignite Community!
My name is Rodion. I want to contribute to Apache Ignite and want to start
with this issue - IGNITE-14474, my JIRA username Smolnikov. Any help on
this will be appreciated.
Thanks!
--
Спасибо,
Родион Смольников
Best regard,
Rodion Smolnikov
Alexey,
Thanks for the detailed explanation.
Ok, let's agree on having the internal package. I've created the ticket [1]
to unify it's usage within the project.
[1] https://issues.apache.org/jira/browse/IGNITE-14506
чт, 8 апр. 2021 г. в 15:34, Alexey Goncharuk :
> Alexei,
>
> The main benefit
Alexey Scherbakov created IGNITE-14506:
--
Summary: Use internal package for all Ignite's code.
Key: IGNITE-14506
URL: https://issues.apache.org/jira/browse/IGNITE-14506
Project: Ignite
Hi, Andrey!
>> ScanQuery, TextQuery and partially SQL query share the same
infrastructure
I think I understand what you mean. I debug query processing and now agree
that it's a nice idea to try to reuse the infrastructure of scan and text
queries. Also as I can see there already Reducer
Denis Mekhanikov created IGNITE-14505:
-
Summary: Print information about striped pool in metrics for local
node
Key: IGNITE-14505
URL: https://issues.apache.org/jira/browse/IGNITE-14505
Project:
Alexei,
The main benefit from Jigsaw that I see for the project structure is
controllable module interaction.
Let's take our networking module as an example first. We may want to make
sure that module implementation specifics do not leak to outside modules,
so we define in the module definition
Igniters!
I suppose it is time to finally release new version of python thin client
Recently, multiple bug fixes, features and other goodies have been
implemented.
For example:
1. Partition awareness.
2. Asyncio support.
3. Cluster API support.
4. Multiple performance improvements, especially for
Andrey,
The PR looks good to me.
Maybe we can wrap all internal threads into IgniteThread - I'm almost sure
this will work in this way.
Is it really need to use thread-locals for user threads? - probably not.
I'm not sure if there is any problem at all. As soon as we want to have
async API
Andrey Aleksandrov created IGNITE-14504:
---
Summary: ClusterGroupEmptyException: Cluster group is empty error
after client reconnect
Key: IGNITE-14504
URL: https://issues.apache.org/jira/browse/IGNITE-14504
Also, with the suggested approach,
we should avoid indirectly usage of ForkJoinPool internally or set our own
pool instance explicitly when using reactive things.
On Thu, Apr 8, 2021 at 1:33 PM Andrey Mashenkov
wrote:
> Alexey,
>
> I've made a PR for logger [1].
> Seems, we will need 2 logger
Alexey,
I've made a PR for logger [1].
Seems, we will need 2 logger classes.
1. Node-aware logger adapter, that will add node prefix to messages and
delegate calls to System.Logger or whatever.
2. Logger wrapper that will get logger from a thread-local.
I don't like to use ThreadLocal directly
Andrey,
*final* word in the example is missing, my bad.
I like the static logger approach.
Regarding your comments:
* The static logger can easily be used by multiple nodes in a single JVM,
it's a matter of implementation. It can be achieved by setting thread local
logger context for the node.
Anton Vinogradov created IGNITE-14503:
-
Summary: Ability to specify project (fork) via the Version
Key: IGNITE-14503
URL: https://issues.apache.org/jira/browse/IGNITE-14503
Project: Ignite
21 matches
Mail list logo
