Re: Azure Cloud IP Finder
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 ignite-azure to libs works for me.
>
> Please see and let me know your thoughts.
>
> Regards,
>
> Atri
>
> On Mon, Apr 5, 2021 at 9:24 PM Ilya Kasnacheev
> wrote:
> >
> > Hello again!
> >
> > I re-checked our cloud discovery options by moving ignite-aws, ignite-gce,
> > ignite-cloud directories from lib/optional to lib/ and trying to run Ignite
> > with simple config taken from examples.
> >
> > The results are the following:
> > ignite-aws seems to work (complains about unknown key)
> > ignite-gce seems to work too (complains about zero length key, this is
> > before it tries any network access so maybe there are other issues down the
> > path)
> > ignite-cloud (jclouds) DOES NOT work. Filed
> > https://issues.apache.org/jira/browse/IGNITE-14481 . I guess this discovery
> > finder is not widely used.
> > ignite-azure, presently, will not work too. Please use ignite-aws as an
> > example since it sees the most usage.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 5 апр. 2021 г. в 16:05, Ilya Kasnacheev :
> >
> > > Hello!
> > >
> > > I'm not sure that I can see any attachment to your e-mail. Can you please
> > > re-send?
> > >
> > > We could have broken some of those, I guess, since we seem to not run
> > > integration tests for them.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пт, 2 апр. 2021 г. в 12:59, Atri Sharma :
> > >
> > >> Hello,
> > >>
> > >> Thank you for sharing.
> > >>
> > >> I was finally able to replicate the issue. However, I tried with other
> > >> IPFinders and ran into the same problem (attached are the logs).
> > >>
> > >> Not sure what is causing this?
> > >>
> > >> Atri
> > >>
> > >> On Fri, Apr 2, 2021 at 2:29 PM Ilya Kasnacheev
> > >> wrote:
> > >> >
> > >> > Hello!
> > >> >
> > >> > Please find attached the log file of errors. This is yesterday's (Apr
> > >> 1) build.
> > >> >
> > >> > Regards,
> > >> > --
> > >> > Ilya Kasnacheev
> > >> >
> > >> >
> > >> > пт, 2 апр. 2021 г. в 11:52, Atri Sharma :
> > >> >>
> > >> >> I was able to, but then, it might be that something is cached locally.
> > >> >>
> > >> >> What errors did you run into? (I am assuming you are trying with a
> > >> >> build from the latest iteration of the PR).
> > >> >>
> > >> >> Atri
> > >> >>
> > >> >> On Fri, Apr 2, 2021 at 2:19 PM Ilya Kasnacheev
> > >> >> wrote:
> > >> >> >
> > >> >> > Hello!
> > >> >> >
> > >> >> > But are you successful in running a node with Azure IP finder
> > >> enabled in
> > >> >> > configuration, starting from that release directory?
> > >> >> >
> > >> >> > I amn't.
> > >> >> >
> > >> >> > Regards,
> > >> >> > --
> > >> >> > Ilya Kasnacheev
> > >> >> >
> > >> >> >
> > >> >> > пт, 2 апр. 2021 г. в 07:42, Atri Sharma :
> > >> >> >
> > >> >> > > Hello,
> > >> >> > >
> > >> >> > > Thank you for taking a look.
> > >> >> > >
> > >> >> > > I am not sure what the confusion is. On the current iteration of
> > >> PR, I
> > >> >> > > am able to build and release and looking in the location you
> > >> >> > > mentioned, I see:
> > >> >> > >
> > >> >> > > Atris-MacBook-Pro-15:libs atrisharma$ cd optional/
> > >> >> > >
> > >> >> > > Atris-MacBook-Pro-15:optional atrisharma$ cd ignite-azure/
> > >> >> > >
> > >> >> > > Atris-MacBook-Pro-15:ignite-azure atrisharma$ ls
> > >> >> > >
> > >> >> > > README.txt azure-storage-blob-12.0.0.jar
> > >> ignite-azure-2.11.0-SNAPSHOT.jar
> > >> >> > >
> > >> >> > >
> > >> >> > > Attached is the screenshot.
> > >> >> > >
> > >> >> > > I have fixed the comments on the PR, please see and let me know.
> > >> >> > >
> > >> >> > > Atri
> > >> >> > >
> > >> >> > > On Thu, Apr 1, 2021 at 8:21 PM Ilya Kasnacheev
> > >> >> > > wrote:
> > >> >> > > >
> > >> >> > > > Hello!
> > >> >> > > >
> > >> >> > > > Were you successful with using it from the deliverable of mvn
> > >> initialize
> > >> >> > > > -Prelease?
> > >> >> > > >
> > >> >> > > > Please refer for example to aws module dependencies section:
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > com.amazonaws
> > >> >> > > > aws-java-sdk-core
> > >> >> > > > ${aws.sdk.version}
> > >> >> > > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > com.amazonaws
> > >> >> > > > aws-java-sdk-s3
> > >> >> > > > ${aws.sdk.version}
> > >> >> > > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > com.amazonaws
> > >> >> > > > aws-java-sdk-ec2
> > >> >> > > > ${aws.sdk.version}
> > >> >> > > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > com.amazonaws
> > >> >> > > > aws-java-sdk-elasticloadbalancing
> > >> >> > > > ${aws.sdk.version}
> > >> >> > > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > com.amazonaws
> > >> >> > > >
[MTCGA]: new failures in builds [5950981] needs to be handled
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 https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5525392503365591188=%3Cdefault%3E=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 01:55:19 09-04-2021
[MTCGA]: new failures in builds [5957331] needs to be handled
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 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 01:25:19 09-04-2021
Re: Model of permissions for Ignite 3
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 authentication from authorization,
so that GridSecurityProcessor implementation is fully responsible for
obtaining permissions for SecuritySubject given on authorization. In
particular, implementation can choose an existing behavior of bundling
permissions with SecuritySubject.
Makes sense?
чт, 8 апр. 2021 г. в 17:52, Denis Garus :
> 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.
> > The main drawback, IMHO: if you need to add a new permission,
> > you should change the core module by extended the 'SecurityPermission'
> > enum.
> > An approach like this becomes more challenged if new permission is
> created
> > for an extension.
> >
> > The existing permission model is overcomplicated.
> > The SecurityPermission enum is divided into four groups,
> > and to determine whether a security subject has been given permission,
> > a plugin developer has to know what the permission group is.
> > But 'CACHE_CREATE' and 'CACHE_DESTROY' are included in two groups (system
> > operations and cache operations).
> > When 'CACHE_CREATE' ('CACHE_DESTROY') is treated as system permission,
> > it applies to all caches. In other cases, when 'CACHE_CREATE'
> > ('CACHE_DESTROY') is treated as cache permission,
> > permission checking is executed with the account of the cache name.
> > IMHO, this logic is hard to understand.
> > There is no ability to represent compound operation as single permission
> > and so on.
> >
> >
> > So I would like to suggest using a permission model that is based on
> > 'java.security.Permission'.
> > I prepared the concept [1] of how this model could look in Ignite.
> > Classes 'CachePermission', 'ComputePermission', and 'ServicePermission'
> > represent cache, compute,
> > and service permissions accordingly, allow wildcards, for example,
> > "org.apache.ignite.internal.*".
> > Class 'IgniteClusterPermission' represents permission without actions.
> > Interface 'GridSecurityProcessor' has a default implementation of the
> > 'authorize' method.
> > 'SecurityTestSuite' is green.
> >
> >
> > This representation of permission, IMHO, has the following advantages:
> > - A developer can easily add new permission without needing to touch the
> > core module.
> > - There is no need to implement complicated logic to authorize an
> > operation inside a security plugin.
> >But a developer has the opportunity to add custom logic.
> > - Wildcards for permission's name from a box, for example, 'new
> > CachePermission("x.y.z.*", "get,put")'.
> > - There is no need to implement 'SecurityPermissionSet' and a set of
> > methods from 'SecurityContex' ('xxxAllowed(String, SecurityPermission))'.
> > - We can define a security policy in a file as java does. It could
> > simplify work for administrators.
> >
> > WDYT?
> >
>
--
Best regards,
Andrey Kuznetsov.
[jira] [Created] (IGNITE-14508) Calcite integration: introduce SQL logical test runner
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 Issue Type: Improvement Components: sql Reporter: Taras Ledkov Assignee: Taras Ledkov New SQL engine functions must be tested a lot. We have to create suite / toolkit to run test SQL script that describes test statements. expected behavior and results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Model of permissions for Ignite 3
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.
> The main drawback, IMHO: if you need to add a new permission,
> you should change the core module by extended the 'SecurityPermission'
> enum.
> An approach like this becomes more challenged if new permission is created
> for an extension.
>
> The existing permission model is overcomplicated.
> The SecurityPermission enum is divided into four groups,
> and to determine whether a security subject has been given permission,
> a plugin developer has to know what the permission group is.
> But 'CACHE_CREATE' and 'CACHE_DESTROY' are included in two groups (system
> operations and cache operations).
> When 'CACHE_CREATE' ('CACHE_DESTROY') is treated as system permission,
> it applies to all caches. In other cases, when 'CACHE_CREATE'
> ('CACHE_DESTROY') is treated as cache permission,
> permission checking is executed with the account of the cache name.
> IMHO, this logic is hard to understand.
> There is no ability to represent compound operation as single permission
> and so on.
>
>
> So I would like to suggest using a permission model that is based on
> 'java.security.Permission'.
> I prepared the concept [1] of how this model could look in Ignite.
> Classes 'CachePermission', 'ComputePermission', and 'ServicePermission'
> represent cache, compute,
> and service permissions accordingly, allow wildcards, for example,
> "org.apache.ignite.internal.*".
> Class 'IgniteClusterPermission' represents permission without actions.
> Interface 'GridSecurityProcessor' has a default implementation of the
> 'authorize' method.
> 'SecurityTestSuite' is green.
>
>
> This representation of permission, IMHO, has the following advantages:
> - A developer can easily add new permission without needing to touch the
> core module.
> - There is no need to implement complicated logic to authorize an
> operation inside a security plugin.
>But a developer has the opportunity to add custom logic.
> - Wildcards for permission's name from a box, for example, 'new
> CachePermission("x.y.z.*", "get,put")'.
> - There is no need to implement 'SecurityPermissionSet' and a set of
> methods from 'SecurityContex' ('xxxAllowed(String, SecurityPermission))'.
> - We can define a security policy in a file as java does. It could
> simplify work for administrators.
>
> WDYT?
>
Model of permissions for Ignite 3
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'
enum.
An approach like this becomes more challenged if new permission is created
for an extension.
The existing permission model is overcomplicated.
The SecurityPermission enum is divided into four groups,
and to determine whether a security subject has been given permission,
a plugin developer has to know what the permission group is.
But 'CACHE_CREATE' and 'CACHE_DESTROY' are included in two groups (system
operations and cache operations).
When 'CACHE_CREATE' ('CACHE_DESTROY') is treated as system permission,
it applies to all caches. In other cases, when 'CACHE_CREATE'
('CACHE_DESTROY') is treated as cache permission,
permission checking is executed with the account of the cache name.
IMHO, this logic is hard to understand.
There is no ability to represent compound operation as single permission
and so on.
So I would like to suggest using a permission model that is based on
'java.security.Permission'.
I prepared the concept [1] of how this model could look in Ignite.
Classes 'CachePermission', 'ComputePermission', and 'ServicePermission'
represent cache, compute,
and service permissions accordingly, allow wildcards, for example,
"org.apache.ignite.internal.*".
Class 'IgniteClusterPermission' represents permission without actions.
Interface 'GridSecurityProcessor' has a default implementation of the
'authorize' method.
'SecurityTestSuite' is green.
This representation of permission, IMHO, has the following advantages:
- A developer can easily add new permission without needing to touch the
core module.
- There is no need to implement complicated logic to authorize an operation
inside a security plugin.
But a developer has the opportunity to add custom logic.
- Wildcards for permission's name from a box, for example, 'new
CachePermission("x.y.z.*", "get,put")'.
- There is no need to implement 'SecurityPermissionSet' and a set of
methods from 'SecurityContex' ('xxxAllowed(String, SecurityPermission))'.
- We can define a security policy in a file as java does. It could simplify
work for administrators.
WDYT?
[jira] [Created] (IGNITE-14507) Un-deprecate IGNITE_BINARY_SORT_OBJECT_FIELDS
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 Issue Type: Improvement Components: binary Reporter: Stanislav Lukyanov IGNITE_BINARY_SORT_OBJECT_FIELDS should not be deprecated - on the contrary, every new environment better have this option. We need to advertise it more, so we need to remove the deprecation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
welcome letter
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
Re: Terms clarification and modules splitting logic
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 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 that the module exports package > org.apache.ignite.internal.network. Now, even if we have a public class in > package org.apache.ignite.internal.network.scalecube (the class may be > public for many reasons, including a need for access in other > implementation packages), other modules will not be able to directly work > with this public class - the code will not compile. > > Another important feature of Jigsaw is the qualified export statement that > limits the exported API to specific modules. Let's say for some reason we > want to limit Raft client usage only to metastorage and partition > components. Then we can specify in the raft module descriptor that raft API > is only exported to metastorage and partition modules. Other modules will > not compile if they will try to work with raft API. > > To me, this looks like a very powerful mechanism allowing to strictly > define modules structure and hierarchy. > > As for the utility classes, @Internal looks less obvious for me because a > user cannot directly see it without looking at the class itself. When > 'internal' is imprinted in the package, you can see the violation directly > at the usage site because there will be an import statement with an > 'internal' package. You can check this as simple as an obvious grep > command, which will not work with the annotation. > > --AG > > ср, 31 мар. 2021 г. в 21:04, Alexei Scherbakov < > alexey.scherbak...@gmail.com > >: > > > Alexey, > > > > Can you provide us some details on jygsaw adoption to better understand > > the benefits ? > > > > "We should be free to change them without any compatibility contract" - > > let's mark such classes with a special annotation like @Internal, will it > > work for you ? > > > > > > > > ср, 31 мар. 2021 г. в 15:10, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > This won't work with the Java Jigsaw module system because it prohibits > > > having two identical packages in different modules. I really hope that > we > > > will adopt Jigsaw in the near future. Unless you are suggesting moving > > all > > > utility classes under org.apache.ignite.api.util package, bit this > looks > > > really odd to me - why would IgniteUuid be in api.util package? > > > > > > As for the public and private utilities, I think there may be some > > classes > > > that may be common for all modules, but should not be treated as public > > API > > > because we should be free to change them without any compatibility > > > contract. An example of such a class is GridFunc. Arguably, many of its > > > methods should be removed for good, but I am sure there will be a few > > > really useful ones. Nevertheless, we should not encourage or allow > users > > to > > > use GridFunc. > > > > > > --AG > > > > > > ср, 31 мар. 2021 г. в 14:27, Alexei Scherbakov < > > > alexey.scherbak...@gmail.com > > > >: > > > > > > > Alexey, > > > > > > > > I would instead suggest moving the public utility classes to > > > > org.apache.ignite.api. package in the util module to separate them > from > > > > internal classes, if we really need this. > > > > > > > > Actually, I don't think there is a point in separating > public/internal > > > > classes in the util module. What are the benefits of this ? > > > > > > > > ср, 31 мар. 2021 г. в 12:16, Alexey Goncharuk < > > > alexey.goncha...@gmail.com > > > > >: > > > > > > > > > Alexei, > > > > > > > > > > I had the same opinion regarding the internal package, but we still > > > need > > > > to > > > > > somehow distinguish between public and internal classes in the > > > > ignite-util > > > > > module. If we introduce the internal package in the util, we should > > > > follow > > > > > the same structure in other modules. > > > > > > > > > > Thoughts? > > > > > > > > > > вт, 30 мар. 2021 г. в 18:37, Alexei Scherbakov < > > > > > alexey.scherbak...@gmail.com > > > > > >: > > > > > > > > > > > +1 to package and module naming. > > > > > > +1 to service definition as "component providing a high-level API > > to > > > > > > user/other components/services" > > > > > > > > > > > > I would avoid defining strict rules for Manager and Processor. > > > > > > For me it just adds confusion without real value. > > > > > > A component can be a Manager if it manages something, a Processor > > if > > > it > > > > > > processes something, and so on. > > > > > > I think having Component and Service (which is also a
[jira] [Created] (IGNITE-14506) Use internal package for all Ignite's code.
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 Issue Type: Task Reporter: Alexey Scherbakov Being _internal_ means the code can change at any time without any compatibility guarantees, so it's external usage should be avoided. Devlist discussion [1] [1] http://apache-ignite-developers.2346864.n4.nabble.com/Terms-clarification-and-modules-splitting-logic-td52026.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] IEP-71 Public API for secondary index search
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 functionality exists, so I hope we can use that. I'm not absolutely confident now that it will work fine, but I'm going to start there. Thanks for pointing me this direction! >> I don't like the idea a user code will be executed inside BTree operation On the confluence page I've shown that a predicate passes as TreeRowClosure. In this case you're right, any exception in a predicate will lead to a CorruptedTreeException. But I see another legal way to implement the predicate operation. BPlusTree.find accepts the X param that passed to IO.getRow(). As I understand this param helps to control how much returned row is filled. Then we can use it to return an object that contains only basic info - link, pageAddr, offset. Then predicate operation will be applied on the higher level on a cursor returned by a tree (like H2TreeIndex does). It's safe to run user code there, we can handle exceptions there. On Wed, Apr 7, 2021 at 4:46 PM Andrey Mashenkov wrote: > Maksim, > > The ScanQuery API provides a filter as > > param that for case of index query should be splitted on such conditions. > > It looks like a non-trivial task. > > > ScanQuery, TextQuery and partially SQL query share the same infrastructure. > I've thought we could extend, improve and reuse some ScanQuery code that > already works fine: map query on topology, IO, batching. > Add IndexCondition alongside the Filter, and abstract query executor from > source (primary and secondary Indexes). > Add a sorted merge algorithm to the query merge stage. It can be very > useful also for TextQueries that suffers from the absence of sorted merge > and a "limit' condition work incorrectly. > > If you think it will be too hard than creating from scratch, I'm ok. > > 3. Ignite creates a proxy object that is filled with objects that are > > inlined. If a user tries to access a field that isn't inlined or not > > indexed, then deserialization will start and Ignite will log.warn() about > > that. > > > Agree, this can be faster. > I don't like the idea a user code will be executed inside BTree operation, > any exception can cause FailureHandler triggering and stop the node. > > There is one more thing that could be improved. > ScanQuery now iterates over per-partition PK Hash index trees and has > performance issues on a small grid with a large number of partitions. > So, there are many partitions on every node and many trees should be > scanned. > In this case scan over a secondary index gives significant boots even if > every row is materialized, because we need to traverse over a single tree > per-node. > Having the ability to run a ScanQuery over a secondary index (if one > exists) instead of PK Hash will be great. > > > On Wed, Apr 7, 2021 at 11:18 AM Maksim Timonin > wrote: > > > Hi, Andrey! > > > > Thanks for the review and your comments! > > > > >> Is it possible to extend ScanQuery functionality to pass index > condition > > I investigated this way and see some issues: > > 1. Querying of indexes is not a scan actually. It's > > a tree traverse (predicate operation is an exclusion, other operations > like > > gt, lt, min, max have explicit boundaries). An index query consists of > > conditions that match an index structure. In general for a multi-key > index > > there can be multiple conditions. The ScanQuery API provides a filter as > > param that for case of index query should be splitted on such conditions. > > It looks like a non-trivial task. > > 2. Querying of an index requires a sorted result, while The ScanQuery > > doesn't matter about that. So there will be a different behavior of the > > iterator for scanning a cache and querying indexes. It's not much to > > implement I think, but it can make ScanQuery unclear for a user. > > > > Maybe it's a point to separate traverse (gt, lt, in, etc...) and scan > > (predicate) index operations to different API. So there still will be a > new > > query type for the traversing. > > > > But we will introduce some inheritors for ScanQuery, like TableScanQuery > > and IndexScanQuery, for scan and filter. Then the question is about > > ordering, Cache and Table scans aren't ordered, but Index is. Then we can > > introduce an optional param "order" for ScanQuery too. > > > > WDYT? > > > > >> Functional indices > > >> This task looks like a huge one because the lifecycle of such classes > > should be described first > > I agree with you. That this part should be investigated deeper than I > did. > > So let's postpone discussion about functional indexes for a while. IEP-71 > > declares some phases, functional indexes are part of the 2nd phase, but > > users will get new functionality already from the 1st phase. Then I'll > dig > >
[jira] [Created] (IGNITE-14505) Print information about striped pool in metrics for local node
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: Ignite Issue Type: Improvement Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Currently only information about public and system thread pools are printed in metrics for a local node. It would be good to have the same information about striped pool as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Terms clarification and modules splitting logic
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 that the module exports package org.apache.ignite.internal.network. Now, even if we have a public class in package org.apache.ignite.internal.network.scalecube (the class may be public for many reasons, including a need for access in other implementation packages), other modules will not be able to directly work with this public class - the code will not compile. Another important feature of Jigsaw is the qualified export statement that limits the exported API to specific modules. Let's say for some reason we want to limit Raft client usage only to metastorage and partition components. Then we can specify in the raft module descriptor that raft API is only exported to metastorage and partition modules. Other modules will not compile if they will try to work with raft API. To me, this looks like a very powerful mechanism allowing to strictly define modules structure and hierarchy. As for the utility classes, @Internal looks less obvious for me because a user cannot directly see it without looking at the class itself. When 'internal' is imprinted in the package, you can see the violation directly at the usage site because there will be an import statement with an 'internal' package. You can check this as simple as an obvious grep command, which will not work with the annotation. --AG ср, 31 мар. 2021 г. в 21:04, Alexei Scherbakov : > Alexey, > > Can you provide us some details on jygsaw adoption to better understand > the benefits ? > > "We should be free to change them without any compatibility contract" - > let's mark such classes with a special annotation like @Internal, will it > work for you ? > > > > ср, 31 мар. 2021 г. в 15:10, Alexey Goncharuk >: > > > This won't work with the Java Jigsaw module system because it prohibits > > having two identical packages in different modules. I really hope that we > > will adopt Jigsaw in the near future. Unless you are suggesting moving > all > > utility classes under org.apache.ignite.api.util package, bit this looks > > really odd to me - why would IgniteUuid be in api.util package? > > > > As for the public and private utilities, I think there may be some > classes > > that may be common for all modules, but should not be treated as public > API > > because we should be free to change them without any compatibility > > contract. An example of such a class is GridFunc. Arguably, many of its > > methods should be removed for good, but I am sure there will be a few > > really useful ones. Nevertheless, we should not encourage or allow users > to > > use GridFunc. > > > > --AG > > > > ср, 31 мар. 2021 г. в 14:27, Alexei Scherbakov < > > alexey.scherbak...@gmail.com > > >: > > > > > Alexey, > > > > > > I would instead suggest moving the public utility classes to > > > org.apache.ignite.api. package in the util module to separate them from > > > internal classes, if we really need this. > > > > > > Actually, I don't think there is a point in separating public/internal > > > classes in the util module. What are the benefits of this ? > > > > > > ср, 31 мар. 2021 г. в 12:16, Alexey Goncharuk < > > alexey.goncha...@gmail.com > > > >: > > > > > > > Alexei, > > > > > > > > I had the same opinion regarding the internal package, but we still > > need > > > to > > > > somehow distinguish between public and internal classes in the > > > ignite-util > > > > module. If we introduce the internal package in the util, we should > > > follow > > > > the same structure in other modules. > > > > > > > > Thoughts? > > > > > > > > вт, 30 мар. 2021 г. в 18:37, Alexei Scherbakov < > > > > alexey.scherbak...@gmail.com > > > > >: > > > > > > > > > +1 to package and module naming. > > > > > +1 to service definition as "component providing a high-level API > to > > > > > user/other components/services" > > > > > > > > > > I would avoid defining strict rules for Manager and Processor. > > > > > For me it just adds confusion without real value. > > > > > A component can be a Manager if it manages something, a Processor > if > > it > > > > > processes something, and so on. > > > > > I think having Component and Service (which is also a Component) is > > > > enough. > > > > > Any component can be singleton or not - it's defined by its > > lifecycle. > > > > > > > > > > +1 to renaming core to something more meaningful, but the name lang > > > > doesn't > > > > > fit for a collection of utility classes for me, I would prefer > > > > ignite-util. > > > > > Apache Tomcat has the same jar, for reference. I'm also fine to > leave > > > it > > > > as > > > > > is. > > > > > -1 to have an "internal" package. All modules are known to be > > internal > > > > > except api and (partially) util, so why
[DISCUSSION] Release 0.4.0 version of ignite python thin client (pyignite)
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 BinaryObjects and large data chunks. Full list of issues are here [1] I suppose that scope is already fixed and done, so it's time to test and release. Unfortunately, there is no ready infrastructure and TC jobs, so we probably should build artifacts on personal computers. Igor Sapego and me can prepare release artifacts on our own. Documentation is ready and is here [2]. Documentation for release will be built automatically after cutting the release branch. After finishing of voting procedure, signed artifacts will be uploaded to pypi.org by me or Igor Sapego. Please, share your opinions about subj. [1] -- https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.4.0 [2] https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/ -- Sincerely yours, Ivan Daschinskiy
Re: [DISSCUSSION] Common logger interface.
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 everywhere, out code should not be executed in user thread чт, 8 апр. 2021 г. в 13:37, Andrey Mashenkov : > 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 < > andrey.mashen...@gmail.com> > wrote: > > > 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 when possible. > > Maybe we can wrap all internal threads into IgniteThread and keep the > > logger in an IgniteThread field to avoid lookups into thread-local-map. > > > > For user threads, only ThreadLocals can be used. > > Is it really need to use thread-locals for user threads? > > Will it be always obvious which node exception was thrown on? Any kind of > > embedded mode? > > > > [1] https://github.com/apache/ignite-3/pull/87 > > > > On Thu, Apr 8, 2021 at 12:32 PM Alexei Scherbakov < > > alexey.scherbak...@gmail.com> wrote: > > > >> 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. > >> For user threads the context can be set while entering ignite context > (for > >> example, by calling public API method) > >> * Factory method is not necessary, because we already have a proxy > object > >> - > >> LogWrapper, hiding internal implementation. > >> > >> > >> > >> > >> > >> > >> > >> ср, 7 апр. 2021 г. в 18:39, Andrey Mashenkov < > andrey.mashen...@gmail.com > >> >: > >> > >> > Alexei, > >> > > >> > I see you've merged LoggerWrapper into main and use it in Raft module. > >> > I can't figure out what manner you suggest to use LoggerWrapper in. > >> > In the example above 'LOG' field is static, non-final and you create a > >> > wrapper explicitly. > >> > > >> > I see 2 ways: > >> > * Use a factory method to create a logger and set it into 'static > final' > >> > field. > >> > In this case, a user will not be able to split logs from different > nodes > >> > running in the same JVM. > >> > * Set logger into non-static field (with dependency injection future). > >> > In this case, we need to pass the logger to every class instance where > >> it > >> > can be used. > >> > > >> > > >> > On Fri, Mar 26, 2021 at 6:48 PM Вячеслав Коптилин < > >> > slava.kopti...@gmail.com> > >> > wrote: > >> > > >> > > Hello Alexei, > >> > > > >> > > It would be nice to add something like as follows: > >> > > boolean isInfoEnabled(); > >> > > boolean isDebugEnabled(); > >> > > or > >> > > boolean isLoggable(Level) - the same way which System.Logger > >> suggests > >> > > > >> > > Thanks, > >> > > S. > >> > > > >> > > пт, 26 мар. 2021 г. в 17:41, Alexei Scherbakov < > >> > > alexey.scherbak...@gmail.com > >> > > >: > >> > > > >> > > > Andrey, > >> > > > > >> > > > I've introduced a new class LogWrapper to fix usability issues [1] > >> > > > > >> > > > The suggested usage is something like: > >> > > > > >> > > > private static LogWrapper LOG = new LogWrapper(MyClass.class); > >> > > > > >> > > > [1] > >> > > > > >> > > > > >> > > > >> > > >> > https://github.com/gridgain/apache-ignite-3/blob/9acb050a6a6a601ead849797293a1d0ad48ab9e0/modules/core/src/main/java/org/apache/ignite/lang/LogWrapper.java > >> > > > > >> > > > пт, 26 мар. 2021 г. в 16:05, Andrey Mashenkov < > >> > > andrey.mashen...@gmail.com > >> > > > >: > >> > > > > >> > > > > Forgot to attach a link to the PR with an example [1]. > >> > > > > > >> > > > > [1] https://github.com/apache/ignite-3/pull/59 > >> > > > > > >> > > > > On Fri, Mar 26, 2021 at 4:03 PM Andrey Mashenkov < > >> > > > > andrey.mashen...@gmail.com> > >> > > > > wrote: > >> > > > > > >> > > > > > Hi Igniters, > >> > > > > > > >> > > > > > In almost every new task we faced the problem of what logger > >> has to > >> > > be > >> > > > > > used: JUL. log4J or any else. > >> > > > > > > >> > > > > > Since JDK 9 there is a System.Logger which interface looks > >> > acceptable > >> > > > for > >> > > > > > use, > >> > > > > > excepts maybe some usability issues like method signatures. > >> > > > > > LogLevel is passed as a mandatory argument, and no shortcut > >> methods > >> > > are > >> > > > > > provided (like 'warn', 'error'
[jira] [Created] (IGNITE-14504) ClusterGroupEmptyException: Cluster group is empty error after client reconnect
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 Project: Ignite Issue Type: Bug Components: messaging Affects Versions: 2.10 Reporter: Andrey Aleksandrov Assignee: Andrey Aleksandrov Fix For: 2.11 Attachments: SendMessageAfterClientReconnect.java Please run the attached test. It will produce the following exception: Exception in thread "main" class org.apache.ignite.cluster.ClusterGroupEmptyException: Cluster group is empty. at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:927) at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:925) at org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1083) at org.apache.ignite.internal.IgniteMessagingImpl.send0(IgniteMessagingImpl.java:105) at org.apache.ignite.internal.IgniteMessagingImpl.send(IgniteMessagingImpl.java:81) at npe.IgnitePartitioningTest.main(IgnitePartitioningTest.java:110) Caused by: class org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster group is empty. at org.apache.ignite.internal.util.IgniteUtils.emptyTopologyException(IgniteUtils.java:5106) at org.apache.ignite.internal.IgniteMessagingImpl.send0(IgniteMessagingImpl.java:100) ... 2 more Fix: change return new ClusterGroupAdapter(ctx, null, Collections.singleton(cfg.getNodeId())); -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISSCUSSION] Common logger interface.
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 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 when possible. > Maybe we can wrap all internal threads into IgniteThread and keep the > logger in an IgniteThread field to avoid lookups into thread-local-map. > > For user threads, only ThreadLocals can be used. > Is it really need to use thread-locals for user threads? > Will it be always obvious which node exception was thrown on? Any kind of > embedded mode? > > [1] https://github.com/apache/ignite-3/pull/87 > > On Thu, Apr 8, 2021 at 12:32 PM Alexei Scherbakov < > alexey.scherbak...@gmail.com> wrote: > >> 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. >> For user threads the context can be set while entering ignite context (for >> example, by calling public API method) >> * Factory method is not necessary, because we already have a proxy object >> - >> LogWrapper, hiding internal implementation. >> >> >> >> >> >> >> >> ср, 7 апр. 2021 г. в 18:39, Andrey Mashenkov > >: >> >> > Alexei, >> > >> > I see you've merged LoggerWrapper into main and use it in Raft module. >> > I can't figure out what manner you suggest to use LoggerWrapper in. >> > In the example above 'LOG' field is static, non-final and you create a >> > wrapper explicitly. >> > >> > I see 2 ways: >> > * Use a factory method to create a logger and set it into 'static final' >> > field. >> > In this case, a user will not be able to split logs from different nodes >> > running in the same JVM. >> > * Set logger into non-static field (with dependency injection future). >> > In this case, we need to pass the logger to every class instance where >> it >> > can be used. >> > >> > >> > On Fri, Mar 26, 2021 at 6:48 PM Вячеслав Коптилин < >> > slava.kopti...@gmail.com> >> > wrote: >> > >> > > Hello Alexei, >> > > >> > > It would be nice to add something like as follows: >> > > boolean isInfoEnabled(); >> > > boolean isDebugEnabled(); >> > > or >> > > boolean isLoggable(Level) - the same way which System.Logger >> suggests >> > > >> > > Thanks, >> > > S. >> > > >> > > пт, 26 мар. 2021 г. в 17:41, Alexei Scherbakov < >> > > alexey.scherbak...@gmail.com >> > > >: >> > > >> > > > Andrey, >> > > > >> > > > I've introduced a new class LogWrapper to fix usability issues [1] >> > > > >> > > > The suggested usage is something like: >> > > > >> > > > private static LogWrapper LOG = new LogWrapper(MyClass.class); >> > > > >> > > > [1] >> > > > >> > > > >> > > >> > >> https://github.com/gridgain/apache-ignite-3/blob/9acb050a6a6a601ead849797293a1d0ad48ab9e0/modules/core/src/main/java/org/apache/ignite/lang/LogWrapper.java >> > > > >> > > > пт, 26 мар. 2021 г. в 16:05, Andrey Mashenkov < >> > > andrey.mashen...@gmail.com >> > > > >: >> > > > >> > > > > Forgot to attach a link to the PR with an example [1]. >> > > > > >> > > > > [1] https://github.com/apache/ignite-3/pull/59 >> > > > > >> > > > > On Fri, Mar 26, 2021 at 4:03 PM Andrey Mashenkov < >> > > > > andrey.mashen...@gmail.com> >> > > > > wrote: >> > > > > >> > > > > > Hi Igniters, >> > > > > > >> > > > > > In almost every new task we faced the problem of what logger >> has to >> > > be >> > > > > > used: JUL. log4J or any else. >> > > > > > >> > > > > > Since JDK 9 there is a System.Logger which interface looks >> > acceptable >> > > > for >> > > > > > use, >> > > > > > excepts maybe some usability issues like method signatures. >> > > > > > LogLevel is passed as a mandatory argument, and no shortcut >> methods >> > > are >> > > > > > provided (like 'warn', 'error' or 'info'). >> > > > > > >> > > > > > I like Alex Scherbakov idea [1] to use a brand new JDK system >> > logger >> > > by >> > > > > > default and >> > > > > > extend it with shortcut methods. >> > > > > > >> > > > > > I've created a ticket to unify logger usage in Ignite-3.0 >> project >> > to >> > > > fix >> > > > > > already existed code. >> > > > > > >> > > > > > Any thoughts or objections? >> > > > > > >> > > > > > -- >> > > > > > Best regards, >> > > > > > Andrey V. Mashenkov >> > > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Best regards, >> > > > > Andrey V. Mashenkov >> > > > > >> > > > >> > > > >> > > > -- >> > > > >> > > > Best regards, >> > > > Alexei Scherbakov >> > > > >> > > >> > >> > >> > -- >> > Best regards,
Re: [DISSCUSSION] Common logger interface.
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 when possible. Maybe we can wrap all internal threads into IgniteThread and keep the logger in an IgniteThread field to avoid lookups into thread-local-map. For user threads, only ThreadLocals can be used. Is it really need to use thread-locals for user threads? Will it be always obvious which node exception was thrown on? Any kind of embedded mode? [1] https://github.com/apache/ignite-3/pull/87 On Thu, Apr 8, 2021 at 12:32 PM Alexei Scherbakov < alexey.scherbak...@gmail.com> wrote: > 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. > For user threads the context can be set while entering ignite context (for > example, by calling public API method) > * Factory method is not necessary, because we already have a proxy object - > LogWrapper, hiding internal implementation. > > > > > > > > ср, 7 апр. 2021 г. в 18:39, Andrey Mashenkov : > > > Alexei, > > > > I see you've merged LoggerWrapper into main and use it in Raft module. > > I can't figure out what manner you suggest to use LoggerWrapper in. > > In the example above 'LOG' field is static, non-final and you create a > > wrapper explicitly. > > > > I see 2 ways: > > * Use a factory method to create a logger and set it into 'static final' > > field. > > In this case, a user will not be able to split logs from different nodes > > running in the same JVM. > > * Set logger into non-static field (with dependency injection future). > > In this case, we need to pass the logger to every class instance where it > > can be used. > > > > > > On Fri, Mar 26, 2021 at 6:48 PM Вячеслав Коптилин < > > slava.kopti...@gmail.com> > > wrote: > > > > > Hello Alexei, > > > > > > It would be nice to add something like as follows: > > > boolean isInfoEnabled(); > > > boolean isDebugEnabled(); > > > or > > > boolean isLoggable(Level) - the same way which System.Logger > suggests > > > > > > Thanks, > > > S. > > > > > > пт, 26 мар. 2021 г. в 17:41, Alexei Scherbakov < > > > alexey.scherbak...@gmail.com > > > >: > > > > > > > Andrey, > > > > > > > > I've introduced a new class LogWrapper to fix usability issues [1] > > > > > > > > The suggested usage is something like: > > > > > > > > private static LogWrapper LOG = new LogWrapper(MyClass.class); > > > > > > > > [1] > > > > > > > > > > > > > > https://github.com/gridgain/apache-ignite-3/blob/9acb050a6a6a601ead849797293a1d0ad48ab9e0/modules/core/src/main/java/org/apache/ignite/lang/LogWrapper.java > > > > > > > > пт, 26 мар. 2021 г. в 16:05, Andrey Mashenkov < > > > andrey.mashen...@gmail.com > > > > >: > > > > > > > > > Forgot to attach a link to the PR with an example [1]. > > > > > > > > > > [1] https://github.com/apache/ignite-3/pull/59 > > > > > > > > > > On Fri, Mar 26, 2021 at 4:03 PM Andrey Mashenkov < > > > > > andrey.mashen...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > In almost every new task we faced the problem of what logger has > to > > > be > > > > > > used: JUL. log4J or any else. > > > > > > > > > > > > Since JDK 9 there is a System.Logger which interface looks > > acceptable > > > > for > > > > > > use, > > > > > > excepts maybe some usability issues like method signatures. > > > > > > LogLevel is passed as a mandatory argument, and no shortcut > methods > > > are > > > > > > provided (like 'warn', 'error' or 'info'). > > > > > > > > > > > > I like Alex Scherbakov idea [1] to use a brand new JDK system > > logger > > > by > > > > > > default and > > > > > > extend it with shortcut methods. > > > > > > > > > > > > I've created a ticket to unify logger usage in Ignite-3.0 project > > to > > > > fix > > > > > > already existed code. > > > > > > > > > > > > Any thoughts or objections? > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Andrey V. Mashenkov > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best regards, > > > > > Andrey V. Mashenkov > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > Alexei Scherbakov > > > > > > > > > > > > > -- > > Best regards, > > Andrey V. Mashenkov > > > > > -- > > Best regards, > Alexei Scherbakov > -- Best regards, Andrey V. Mashenkov
Re: [DISSCUSSION] Common logger interface.
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. For user threads the context can be set while entering ignite context (for example, by calling public API method) * Factory method is not necessary, because we already have a proxy object - LogWrapper, hiding internal implementation. ср, 7 апр. 2021 г. в 18:39, Andrey Mashenkov : > Alexei, > > I see you've merged LoggerWrapper into main and use it in Raft module. > I can't figure out what manner you suggest to use LoggerWrapper in. > In the example above 'LOG' field is static, non-final and you create a > wrapper explicitly. > > I see 2 ways: > * Use a factory method to create a logger and set it into 'static final' > field. > In this case, a user will not be able to split logs from different nodes > running in the same JVM. > * Set logger into non-static field (with dependency injection future). > In this case, we need to pass the logger to every class instance where it > can be used. > > > On Fri, Mar 26, 2021 at 6:48 PM Вячеслав Коптилин < > slava.kopti...@gmail.com> > wrote: > > > Hello Alexei, > > > > It would be nice to add something like as follows: > > boolean isInfoEnabled(); > > boolean isDebugEnabled(); > > or > > boolean isLoggable(Level) - the same way which System.Logger suggests > > > > Thanks, > > S. > > > > пт, 26 мар. 2021 г. в 17:41, Alexei Scherbakov < > > alexey.scherbak...@gmail.com > > >: > > > > > Andrey, > > > > > > I've introduced a new class LogWrapper to fix usability issues [1] > > > > > > The suggested usage is something like: > > > > > > private static LogWrapper LOG = new LogWrapper(MyClass.class); > > > > > > [1] > > > > > > > > > https://github.com/gridgain/apache-ignite-3/blob/9acb050a6a6a601ead849797293a1d0ad48ab9e0/modules/core/src/main/java/org/apache/ignite/lang/LogWrapper.java > > > > > > пт, 26 мар. 2021 г. в 16:05, Andrey Mashenkov < > > andrey.mashen...@gmail.com > > > >: > > > > > > > Forgot to attach a link to the PR with an example [1]. > > > > > > > > [1] https://github.com/apache/ignite-3/pull/59 > > > > > > > > On Fri, Mar 26, 2021 at 4:03 PM Andrey Mashenkov < > > > > andrey.mashen...@gmail.com> > > > > wrote: > > > > > > > > > Hi Igniters, > > > > > > > > > > In almost every new task we faced the problem of what logger has to > > be > > > > > used: JUL. log4J or any else. > > > > > > > > > > Since JDK 9 there is a System.Logger which interface looks > acceptable > > > for > > > > > use, > > > > > excepts maybe some usability issues like method signatures. > > > > > LogLevel is passed as a mandatory argument, and no shortcut methods > > are > > > > > provided (like 'warn', 'error' or 'info'). > > > > > > > > > > I like Alex Scherbakov idea [1] to use a brand new JDK system > logger > > by > > > > > default and > > > > > extend it with shortcut methods. > > > > > > > > > > I've created a ticket to unify logger usage in Ignite-3.0 project > to > > > fix > > > > > already existed code. > > > > > > > > > > Any thoughts or objections? > > > > > > > > > > -- > > > > > Best regards, > > > > > Andrey V. Mashenkov > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Andrey V. Mashenkov > > > > > > > > > > > > > -- > > > > > > Best regards, > > > Alexei Scherbakov > > > > > > > > -- > Best regards, > Andrey V. Mashenkov > -- Best regards, Alexei Scherbakov
[jira] [Created] (IGNITE-14503) Ability to specify project (fork) via the Version
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
Issue Type: Improvement
Reporter: Anton Vinogradov
Assignee: Anton Vinogradov
Currently we able to define fork name via globals
{{"project": "fork", "ignite_versions": "dev"}}
This should be also possible to define a project by version
{{ "ignite_versions": "[dev, ignite-2.8.1, fork-dev, superfork-9.999]"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
