Re: Azure Cloud IP Finder
Gentle reminder on this -- please help in reviewing this. On Fri, Mar 19, 2021 at 10:23 AM Atri Sharma wrote: > > Thanks Denis. > > I have raised a PR for the same: > > https://github.com/apache/ignite/pull/8897 > > Regards, > > Atri > > On Wed, Mar 10, 2021 at 1:21 AM Denis Magda wrote: > > > > Atri, > > > > Let's discuss the subj together with the community. Ignite already supports > > AWS [1] and GCE [2] IP Finders out of the box, but the Azure one is still > > missing. I can confirm that the demand exists, and rather frequently, I see > > developers asking for an Azure-native IP finder for Ignite. > > > > Atri, could you please research how to implement the IP finder and suggest > > a solution in this discussion thread? See how it was done for AWS and GCE, > > we might go the same route or use a more contemporary and easy-to-configure > > approach for Azure. > > > > [1] > > https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#amazon-s3-ip-finder > > [2] > > https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#google-compute-discovery > > > > - > > Denis > > > > -- > Regards, > > Atri > Apache Concerted -- Regards, Atri Apache Concerted
Re: IGNITE-12951 Update documents for migrated extensions
Hi Denis, Thank you so much for merging the changes, yes I am part of committers list of the ASF org. I will again check my access with another PR. Regards, Saikat On Mon, Mar 22, 2021 at 7:49 PM Denis Magda wrote: > Hey Saikat, > > I merged the PR. As a committer, you should have access to the repo. Are > you on the committers list of the ASF org? https://github.com/apache > > - > Denis > > > On Mon, Mar 22, 2021 at 8:42 PM Saikat Maitra > wrote: > > > Hi Nikita, > > > > I have taken all your suggested changes. It seems I do not have merge > > access for ignite-website repo. Can you please help merge the PR? > > > > https://github.com/apache/ignite-website/pull/85 > > > > Regards, > > Saikat > > > > On Mon, Mar 22, 2021 at 7:22 PM Saikat Maitra > > wrote: > > > > > Hi Nikita, > > > > > > Thank you for the review and suggestions on the changes. I will apply > > them > > > in the PR. > > > > > > Quick question on the merge process, I think we are directly merging PR > > > for ignite-website in github using the UI, is it correct? > > > > > > I still follow apply pull request script for ignite repo as mentioned > > here > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Informationforcommitters > > > > > > Regards, > > > Saikat > > > > > > > > > On Mon, Mar 22, 2021 at 9:59 AM Никита Сафонов < > > vlasovpavel2...@gmail.com> > > > wrote: > > > > > >> Hi Saikat, > > >> > > >> I have reviewed the changes in the PR and left a couple of suggested > > >> changes. > > >> You can apply them directly in the PR: > > >> https://github.com/apache/ignite-website/pull/85 > > >> > > >> The rest looks good to me, thanks for your work! > > >> > > >> Regards, > > >> Nikita > > >> > > >> пн, 22 мар. 2021 г. в 01:02, Saikat Maitra : > > >> > > >> > Hi, > > >> > > > >> > I have raised a PR for the below jira issue. > > >> > > > >> > https://issues.apache.org/jira/browse/IGNITE-12951 - Update > documents > > >> for > > >> > migrated extensions > > >> > > > >> > PR : https://github.com/apache/ignite-website/pull/85 > > >> > > > >> > Please review and share feedback. > > >> > > > >> > Regards, > > >> > Saikat > > >> > > > >> > > > > > >
Re: IGNITE-12951 Update documents for migrated extensions
Hey Saikat, I merged the PR. As a committer, you should have access to the repo. Are you on the committers list of the ASF org? https://github.com/apache - Denis On Mon, Mar 22, 2021 at 8:42 PM Saikat Maitra wrote: > Hi Nikita, > > I have taken all your suggested changes. It seems I do not have merge > access for ignite-website repo. Can you please help merge the PR? > > https://github.com/apache/ignite-website/pull/85 > > Regards, > Saikat > > On Mon, Mar 22, 2021 at 7:22 PM Saikat Maitra > wrote: > > > Hi Nikita, > > > > Thank you for the review and suggestions on the changes. I will apply > them > > in the PR. > > > > Quick question on the merge process, I think we are directly merging PR > > for ignite-website in github using the UI, is it correct? > > > > I still follow apply pull request script for ignite repo as mentioned > here > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Informationforcommitters > > > > Regards, > > Saikat > > > > > > On Mon, Mar 22, 2021 at 9:59 AM Никита Сафонов < > vlasovpavel2...@gmail.com> > > wrote: > > > >> Hi Saikat, > >> > >> I have reviewed the changes in the PR and left a couple of suggested > >> changes. > >> You can apply them directly in the PR: > >> https://github.com/apache/ignite-website/pull/85 > >> > >> The rest looks good to me, thanks for your work! > >> > >> Regards, > >> Nikita > >> > >> пн, 22 мар. 2021 г. в 01:02, Saikat Maitra : > >> > >> > Hi, > >> > > >> > I have raised a PR for the below jira issue. > >> > > >> > https://issues.apache.org/jira/browse/IGNITE-12951 - Update documents > >> for > >> > migrated extensions > >> > > >> > PR : https://github.com/apache/ignite-website/pull/85 > >> > > >> > Please review and share feedback. > >> > > >> > Regards, > >> > Saikat > >> > > >> > > >
Re: IGNITE-12951 Update documents for migrated extensions
Hi Nikita, I have taken all your suggested changes. It seems I do not have merge access for ignite-website repo. Can you please help merge the PR? https://github.com/apache/ignite-website/pull/85 Regards, Saikat On Mon, Mar 22, 2021 at 7:22 PM Saikat Maitra wrote: > Hi Nikita, > > Thank you for the review and suggestions on the changes. I will apply them > in the PR. > > Quick question on the merge process, I think we are directly merging PR > for ignite-website in github using the UI, is it correct? > > I still follow apply pull request script for ignite repo as mentioned here > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Informationforcommitters > > Regards, > Saikat > > > On Mon, Mar 22, 2021 at 9:59 AM Никита Сафонов > wrote: > >> Hi Saikat, >> >> I have reviewed the changes in the PR and left a couple of suggested >> changes. >> You can apply them directly in the PR: >> https://github.com/apache/ignite-website/pull/85 >> >> The rest looks good to me, thanks for your work! >> >> Regards, >> Nikita >> >> пн, 22 мар. 2021 г. в 01:02, Saikat Maitra : >> >> > Hi, >> > >> > I have raised a PR for the below jira issue. >> > >> > https://issues.apache.org/jira/browse/IGNITE-12951 - Update documents >> for >> > migrated extensions >> > >> > PR : https://github.com/apache/ignite-website/pull/85 >> > >> > Please review and share feedback. >> > >> > Regards, >> > Saikat >> > >> >
Re: IGNITE-12951 Update documents for migrated extensions
Hi Nikita, Thank you for the review and suggestions on the changes. I will apply them in the PR. Quick question on the merge process, I think we are directly merging PR for ignite-website in github using the UI, is it correct? I still follow apply pull request script for ignite repo as mentioned here https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Informationforcommitters Regards, Saikat On Mon, Mar 22, 2021 at 9:59 AM Никита Сафонов wrote: > Hi Saikat, > > I have reviewed the changes in the PR and left a couple of suggested > changes. > You can apply them directly in the PR: > https://github.com/apache/ignite-website/pull/85 > > The rest looks good to me, thanks for your work! > > Regards, > Nikita > > пн, 22 мар. 2021 г. в 01:02, Saikat Maitra : > > > Hi, > > > > I have raised a PR for the below jira issue. > > > > https://issues.apache.org/jira/browse/IGNITE-12951 - Update documents > for > > migrated extensions > > > > PR : https://github.com/apache/ignite-website/pull/85 > > > > Please review and share feedback. > > > > Regards, > > Saikat > > >
Re: IEP-70: Async Continuation Executor
Ready for review:
https://github.com/apache/ignite/pull/8870
On Sun, Mar 21, 2021 at 8:09 PM Pavel Tupitsyn wrote:
> Simple benchmark added - see JmhCacheAsyncListenBenchmark in the PR.
> There is a 6-8% drop (1 client, 2 servers, 1 machine, int key/val).
> I expect this difference to become barely observable on real-world
> workloads.
>
> On Thu, Mar 18, 2021 at 12:35 PM Pavel Tupitsyn
> wrote:
>
>> Denis,
>>
>> For a reproducer, please see CacheAsyncContinuationExecutorTest.java in
>> the linked PoC [1]
>>
>> [1]
>> https://github.com/apache/ignite/pull/8870/files#diff-c788c12013622093df07d8f628a6e8c5fb0c15007f0787f2d459dbb3e377fc5aR54
>>
>> On Thu, Mar 18, 2021 at 1:58 AM Raymond Wilson <
>> raymond_wil...@trimble.com> wrote:
>>
>>> We implemented the ContinueWith() suggestion from Pavel, and it works
>>> well
>>> so far in testing, though we do not have data to support if there is or
>>> is
>>> not a performance penalty in our use case..
>>>
>>> To lend another vote to the 'Don't do continuations on the striped thread
>>> pool' line of thinking: Deadlocking is an issue as is starvation. In some
>>> ways starvation is more insidious because by the time things stop working
>>> the cause and effect distance may be large.
>>>
>>> I appreciate the documentation does make statements about not performing
>>> cache operations in a continuation due to deadlock possibilities, but
>>> that
>>> statement does not reveal why this is an issue. It is less a case of a
>>> async cache operation being followed by some other cache operation (an
>>> immediate issue), and more a general case of the continuation of
>>> application logic using a striped pool thread in a way that might mean
>>> that
>>> thread is never given back - it's now just a piece of the application
>>> infrastructure until some other application activity schedules away from
>>> that thread (eg: by ContinueWith or some other async operation in the
>>> application code that releases the thread). To be fair, beyond structures
>>> like ContinueWith(), it is not obvious how that continuation thread
>>> should
>>> be handed back. This will be the same behaviour for dedicated
>>> continuation
>>> pools, but with far less risk in the absence of ContinueWith()
>>> constructs.
>>>
>>> In the .Net world this is becoming more of an issue as fewer .Net use
>>> cases
>>> outside of UI bother with synchronization contexts by default.
>>>
>>> Raymond.
>>>
>>>
>>> On Thu, Mar 18, 2021 at 9:56 AM Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>>
>>> > Hi Denis,
>>> >
>>> > I think Pavel's main point is that behavior is unpredictable. For
>>> example,
>>> > AFAIK, putAsync can be executed in the main thread instead of the
>>> striped
>>> > pool thread if the operation is local. The listener can also be
>>> executed in
>>> > the main thread - this happens if the future is completed prior to
>>> listener
>>> > invocation (this is actually quite possible in the unit test
>>> environment
>>> > causing the test to pass). Finally, I'm pretty sure there are many
>>> cases
>>> > when a deadlock does not occur right away, but instead it will reveal
>>> > itself under high load due to thread starvation. The latter type of
>>> issues
>>> > is the most dangerous because they are often reproduced only in
>>> production.
>>> > Finally, there are performance considerations as well - cache
>>> operations
>>> > and listeners share the same fixed-sized pool which can have negative
>>> > effects.
>>> >
>>> > I'm OK with the change. Although, it might be better to introduce a new
>>> > fixed-sized pool instead of ForkJoinPool for listeners, simply because
>>> this
>>> > is the approach taken throughout the project. But this is up to a
>>> debate.
>>> >
>>> > -Val
>>> >
>>> > On Wed, Mar 17, 2021 at 11:31 AM Denis Garus
>>> wrote:
>>> >
>>> > > Pavel,
>>> > > I tried this:
>>> > >
>>> > > @Test
>>> > > public void test() throws Exception {
>>> > > IgniteCache cache =
>>> > > startGrid().getOrCreateCache("test_cache");
>>> > >
>>> > > cache.putAsync(1, "one").listen(f -> cache.replace(1, "two"));
>>> > >
>>> > > assertEquals("two", cache.get(1));
>>> > > }
>>> > >
>>> > > and this test is green.
>>> > > I believe that an user can make listener that leads to deadlock, but
>>> > > the example in the IEP does not reflect this.
>>> > >
>>> > >
>>> > >
>>> > > ср, 17 мар. 2021 г. в 17:36, Вячеслав Коптилин <
>>> slava.kopti...@gmail.com
>>> > >:
>>> > >
>>> > > > Hi Pavel,
>>> > > >
>>> > > > > Not a good excuse really. We have a usability problem, you have
>>> to
>>> > > admit
>>> > > > it.
>>> > > > Fair enough. I agree that this is a usability issue, but I have
>>> doubts
>>> > > that
>>> > > > the proposed approach to overcome it is the best one.
>>> > > >
>>> > > > > Documentation won't help - no one is going to read the Javadoc
>>> for a
>>> > > > trivial method like putAsync
>>> > > > That is sad... However, I don't think that this is a strong
>>>
[jira] [Created] (IGNITE-14379) Fix vulnerability of commons-codec <1.13
Ilya Kasnacheev created IGNITE-14379: Summary: Fix vulnerability of commons-codec <1.13 Key: IGNITE-14379 URL: https://issues.apache.org/jira/browse/IGNITE-14379 Project: Ignite Issue Type: Bug Components: build Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Fix For: 2.11 https://www.whitesourcesoftware.com/vulnerability-database/WS-2019-0379 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: IGNITE-12951 Update documents for migrated extensions
Hi Saikat, I have reviewed the changes in the PR and left a couple of suggested changes. You can apply them directly in the PR: https://github.com/apache/ignite-website/pull/85 The rest looks good to me, thanks for your work! Regards, Nikita пн, 22 мар. 2021 г. в 01:02, Saikat Maitra : > Hi, > > I have raised a PR for the below jira issue. > > https://issues.apache.org/jira/browse/IGNITE-12951 - Update documents for > migrated extensions > > PR : https://github.com/apache/ignite-website/pull/85 > > Please review and share feedback. > > Regards, > Saikat >
[jira] [Created] (IGNITE-14378) Remove delay from node ping.
Vladimir Steshin created IGNITE-14378: - Summary: Remove delay from node ping. Key: IGNITE-14378 URL: https://issues.apache.org/jira/browse/IGNITE-14378 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin Assignee: Vladimir Steshin Remove U.sleep(200) from the node ping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14377) Enchance log of node ping failure.
Vladimir Steshin created IGNITE-14377: - Summary: Enchance log of node ping failure. Key: IGNITE-14377 URL: https://issues.apache.org/jira/browse/IGNITE-14377 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin Log of unsuccessful ping during the joining is insufficient. No failure reason is logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
Maxim, this issue should be fixed as part of [1]. Note, that the current PR [2] is draft and its description just shows the current state of work. Of course the task i'm working on can't be resolved without fixing this issue. [1] - https://issues.apache.org/jira/browse/IGNITE-13112 [2] - https://github.com/apache/ignite/pull/8892 On 22.03.2021 15:38, Maxim Muzafarov wrote: Mikhail, Note, that the current PR breaks management of the users via REST because the SecurityContext is not propagated properly during REST requests execution. Do we have a JIRA taks to fix this behaviour or do we need such behaviour at all? On Mon, 22 Mar 2021 at 13:34, Nikolay Izhikov wrote: Hello, Mikhail. I'm +1 to follow your suggestion. чт, 18 мар. 2021 г. в 17:53, Mikhail Petrov : Hello, Igniters. As of now, there are two independent APIs related to security: 1. IgniteSecurity - handle node/client authentication and authorize all operations. 2. IgniteAuthenticationProcessor - handle authentication of thin clients only. The main purpose of creating the IgniteAuthenticationProcessor was to bring default security implementation in Ignite (see [1]) because IgniteSecurity has always had a single implementation that delegates authorization and authentication operation to an external security plugin. But two different APIs that are related to the same leads to security checks duplication in code. As of now, it's possible to configure both security approaches at the same time, and that is confusing for the user. E.g., the user can provide a security plugin and execute ALTER / DROP / CREATE commands successfully. In this case, mentioned commands will do nothing because they only work with the authentication processor I propose to merge the two mentioned above security APIs into one based on the IgniteSecurity interface. For this it is proposed: 1. Remove an IgniteAuthenticationProcessor that is now treated as an independent processor. 2. Move the logic of IgniteAuthenticationProcessor into the implementation of the security plugin that will be used if authentication is enabled via configuration. 3. Remove duplication of security checks and leave IgniteSecurity as a single security API. As of now, authentication operations are not delegated to IgniteAuthenticationProcessor if a security plugin is specified. So the overall security behavior from the user side will remain intact. 4. Remove the AuthorizationContext completely as IgniteSecurity provides an API for storing and managing the security contexts. 5. Extend GridSecurityPlugin interface with methods that provide the ability to manage security users to support existing commands available for authentication processor - alter/drop/create through SQL and REST. As a result, we will make the security-related code more consistent and simpler. Proposed signatures of GridSecurityPlugin methods that provide the ability to manage security users: public void createUser(String login, UserOptions opts) throws IgniteCheckedException   public void alterUser(String login, UserOptions opts) throws IgniteCheckedException  public void dropUser(String login) throws IgniteCheckedException The UserOptions class is a wrapper over EnumMap that maps option values to their aliases. This allows the class to be used for both create and alter user operations and doesn't break backward compatibility in case new options are declared.  The proposed changes lead to the following compatibility issues: 1. When a user provides a security plugin and enables authentication - in this case, the user will face exceptions during the node start while now node starts smoothly. This case makes a little sense because now authentication operations are not delegated to IgniteAuthenticationProcessor at all if a security plugin is specified. 2. The current implementation of IgniteAuthenticationProcessor can enable authentication itself if the current node connects to the cluster with authentication enabled - this functionality will not be supported. The user can easily overcome this by explicitly enabling authentication in the configuration on all nodes. The remaining implementation of the IgniteAuthenticationProcessor and its general behavior will remain intact. I also propose to keep the current callbacks for the IgniteAuthenticationProcessor (e.g. IgniteAuthenticationProcessor#cacheProcessorStarted) that are called from other managers intact, just skip these calls if the authentication is disabled. WDYT? Ticket - https://issues.apache.org/jira/browse/IGNITE-14335 Draft PR - https://github.com/apache/ignite/pull/8892 [1] - http://apache-ignite-developers.2346864.n4.nabble.com/Username-password-authentication-for-thin-clients-td26058.html Regards, Mikhail.
Re: [DISCUSSION] Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
Mikhail, > Note, that the current PR breaks management of the users via REST because the > SecurityContext is not propagated properly during REST requests execution. Do we have a JIRA taks to fix this behaviour or do we need such behaviour at all? On Mon, 22 Mar 2021 at 13:34, Nikolay Izhikov wrote: > > Hello, Mikhail. > > I'm +1 to follow your suggestion. > > чт, 18 мар. 2021 г. в 17:53, Mikhail Petrov : > > > Hello, Igniters. > > > > As of now, there are two independent APIs related to security: > > 1. IgniteSecurity - handle node/client authentication and authorize all > > operations. > > 2. IgniteAuthenticationProcessor - handle authentication of thin clients > > only. > > > > The main purpose of creating the IgniteAuthenticationProcessor was to > > bring default security implementation in Ignite (see [1]) because > > IgniteSecurity has always had a single implementation that delegates > > authorization and authentication operation to an external security plugin. > > > > But two different APIs that are related to the same leads to security > > checks duplication in code. As of now, it's possible to configure both > > security approaches at the same time, and that is confusing for the > > user. E.g., the user can provide a security plugin and execute ALTER / > > DROP / CREATE commands successfully. In this case, mentioned commands > > will do nothing because they only work with the authentication processor > > > > I propose to merge the two mentioned above security APIs into one based > > on the IgniteSecurity interface. > > > > For this it is proposed: > > 1. Remove an IgniteAuthenticationProcessor that is now treated as an > > independent processor. > > 2. Move the logic of IgniteAuthenticationProcessor into the > > implementation of the security plugin that will be used if > > authentication is enabled via configuration. > > 3. Remove duplication of security checks and leave IgniteSecurity as a > > single security API. As of now, authentication operations are not > > delegated to IgniteAuthenticationProcessor if a security plugin is > > specified. So the overall security behavior from the user side will > > remain intact. > > 4. Remove the AuthorizationContext completely as IgniteSecurity provides > > an API for storing and managing the security contexts. > > 5. Extend GridSecurityPlugin interface with methods that provide the > > ability to manage security users to support existing commands available > > for authentication processor - alter/drop/create through SQL and REST. > > > > As a result, we will make the security-related code more consistent and > > simpler. > > > > Proposed signatures of GridSecurityPlugin methods that provide the > > ability to manage security users: > > > > public void createUser(String login, UserOptions opts) throws > > IgniteCheckedException  > >  > > public void alterUser(String login, UserOptions opts) throws > > IgniteCheckedException > > > > public void dropUser(String login) throws IgniteCheckedException > > > > The UserOptions class is a wrapper over EnumMap that maps option values > > to their aliases. This allows the class to be used for both create > > and alter user operations and doesn't break backward compatibility in > > case new options are declared. > > > >  > > The proposed changes lead to the following compatibility issues: > > > > 1. When a user provides a security plugin and enables authentication - > > in this case, the user will face exceptions during the node start while > > now node starts smoothly. This case makes a little sense because now > > authentication operations are not delegated to > > IgniteAuthenticationProcessor at all if a security plugin is specified. > > 2. The current implementation of IgniteAuthenticationProcessor can > > enable authentication itself if the current node connects to the cluster > > with authentication enabled - this functionality will not be supported. > > The user can easily overcome this by explicitly enabling authentication > > in the configuration on all nodes. > > > > > > The remaining implementation of the IgniteAuthenticationProcessor and > > its general behavior will remain intact. I also propose to keep the > > current callbacks for the IgniteAuthenticationProcessor (e.g. > > IgniteAuthenticationProcessor#cacheProcessorStarted) that are called > > from other managers intact, just skip these calls if the authentication > > is disabled. > > > > WDYT? > > > > Ticket - https://issues.apache.org/jira/browse/IGNITE-14335 > > Draft PR - https://github.com/apache/ignite/pull/8892 > > > > [1] - > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Username-password-authentication-for-thin-clients-td26058.html > > > > Regards, > > Mikhail. > > > >
[jira] [Created] (IGNITE-14376) JmxMetricExporter fails to export discovery metrics
Mikhail Petrov created IGNITE-14376:
---
Summary: JmxMetricExporter fails to export discovery metrics
Key: IGNITE-14376
URL: https://issues.apache.org/jira/browse/IGNITE-14376
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Petrov
Reproducer:
{code:java}
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
cfg.setMetricExporterSpi(jmxSpi);
return cfg;
}
/** */
@Test
public void test() throws Exception {
IgniteEx srv = startGrid();
DynamicMBean mBean = metricRegistry(srv.name(), "io", "discovery");
mBean.getMBeanInfo();
}
{code}
The main reason: JMX exporter assumes that each metric must starts with the
name of the registry it belongs to, but discovery metrics do not obey this
naming convection -see TcpDiscoveryStatistics/ZookeeperDiscoveryStatistics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14375) Pending cache destroy messages can be erroneously send.
Stanilovsky Evgeny created IGNITE-14375: --- Summary: Pending cache destroy messages can be erroneously send. Key: IGNITE-14375 URL: https://issues.apache.org/jira/browse/IGNITE-14375 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.10 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Due to pending messages logic implementation its possible to process already outdated _DynamicCacheChangeBatch_ message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14374) Optimize SQL inline indexes format for Ignite 3.0
Yury Gerzhedovich created IGNITE-14374: -- Summary: Optimize SQL inline indexes format for Ignite 3.0 Key: IGNITE-14374 URL: https://issues.apache.org/jira/browse/IGNITE-14374 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich As of now, we always use 1 extra byte per column to keep type. It adds significant effort to index size. We should rethink the format of store for Ignite 3.0. At first glance, it could be a separate single byte to keep the null value for nullable types. In this case, we could inline not more than 8 columns that see as reasonable. May be index record format should be the same as we use for the data records. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
Hello, Mikhail. I'm +1 to follow your suggestion. чт, 18 мар. 2021 г. в 17:53, Mikhail Petrov : > Hello, Igniters. > > As of now, there are two independent APIs related to security: > 1. IgniteSecurity - handle node/client authentication and authorize all > operations. > 2. IgniteAuthenticationProcessor - handle authentication of thin clients > only. > > The main purpose of creating the IgniteAuthenticationProcessor was to > bring default security implementation in Ignite (see [1]) because > IgniteSecurity has always had a single implementation that delegates > authorization and authentication operation to an external security plugin. > > But two different APIs that are related to the same leads to security > checks duplication in code. As of now, it's possible to configure both > security approaches at the same time, and that is confusing for the > user. E.g., the user can provide a security plugin and execute ALTER / > DROP / CREATE commands successfully. In this case, mentioned commands > will do nothing because they only work with the authentication processor > > I propose to merge the two mentioned above security APIs into one based > on the IgniteSecurity interface. > > For this it is proposed: > 1. Remove an IgniteAuthenticationProcessor that is now treated as an > independent processor. > 2. Move the logic of IgniteAuthenticationProcessor into the > implementation of the security plugin that will be used if > authentication is enabled via configuration. > 3. Remove duplication of security checks and leave IgniteSecurity as a > single security API. As of now, authentication operations are not > delegated to IgniteAuthenticationProcessor if a security plugin is > specified. So the overall security behavior from the user side will > remain intact. > 4. Remove the AuthorizationContext completely as IgniteSecurity provides > an API for storing and managing the security contexts. > 5. Extend GridSecurityPlugin interface with methods that provide the > ability to manage security users to support existing commands available > for authentication processor - alter/drop/create through SQL and REST. > > As a result, we will make the security-related code more consistent and > simpler. > > Proposed signatures of GridSecurityPlugin methods that provide the > ability to manage security users: > > public void createUser(String login, UserOptions opts) throws > IgniteCheckedException  >  > public void alterUser(String login, UserOptions opts) throws > IgniteCheckedException > > public void dropUser(String login) throws IgniteCheckedException > > The UserOptions class is a wrapper over EnumMap that maps option values > to their aliases. This allows the class to be used for both create > and alter user operations and doesn't break backward compatibility in > case new options are declared. > >  > The proposed changes lead to the following compatibility issues: > > 1. When a user provides a security plugin and enables authentication - > in this case, the user will face exceptions during the node start while > now node starts smoothly. This case makes a little sense because now > authentication operations are not delegated to > IgniteAuthenticationProcessor at all if a security plugin is specified. > 2. The current implementation of IgniteAuthenticationProcessor can > enable authentication itself if the current node connects to the cluster > with authentication enabled - this functionality will not be supported. > The user can easily overcome this by explicitly enabling authentication > in the configuration on all nodes. > > > The remaining implementation of the IgniteAuthenticationProcessor and > its general behavior will remain intact. I also propose to keep the > current callbacks for the IgniteAuthenticationProcessor (e.g. > IgniteAuthenticationProcessor#cacheProcessorStarted) that are called > from other managers intact, just skip these calls if the authentication > is disabled. > > WDYT? > > Ticket - https://issues.apache.org/jira/browse/IGNITE-14335 > Draft PR - https://github.com/apache/ignite/pull/8892 > > [1] - > > http://apache-ignite-developers.2346864.n4.nabble.com/Username-password-authentication-for-thin-clients-td26058.html > > Regards, > Mikhail. > >
[jira] [Created] (IGNITE-14373) There's a race in auto rollover WAL segment and deactivate of WAL
Kirill Tkalenko created IGNITE-14373:
Summary: There's a race in auto rollover WAL segment and
deactivate of WAL
Key: IGNITE-14373
URL: https://issues.apache.org/jira/browse/IGNITE-14373
Project: Ignite
Issue Type: Bug
Components: persistence
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
Fix For: 2.11
A race was detected between auto rollover WAL segments and deactivation of WAL,
which can lead to an error and a fall of the node by FH.
Error:
{noformat}
Error when executing timeout callback:
o.a.i.i.processors.cache.persistence.wal.FileWriteAheadLogManager$2@421a963a
java.lang.AssertionError: Concurrent updates on rollover are not allowed
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.rollOver(FileWriteAheadLogManager.java:1325)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.closeBufAndRollover(FileWriteAheadLogManager.java:928)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkWalRolloverRequiredDuringInactivityPeriod(FileWriteAheadLogManager.java:819)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$900(FileWriteAheadLogManager.java:159)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$2.onTimeout(FileWriteAheadLogManager.java:782)
at
org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:234)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14372) Fix REST json configuration update requests
Ivan Bessonov created IGNITE-14372: -- Summary: Fix REST json configuration update requests Key: IGNITE-14372 URL: https://issues.apache.org/jira/browse/IGNITE-14372 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14371) Fix REST json representation for configuration
Ivan Bessonov created IGNITE-14371: -- Summary: Fix REST json representation for configuration Key: IGNITE-14371 URL: https://issues.apache.org/jira/browse/IGNITE-14371 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Assignee: Ivan Bessonov REST code is completely broken, it's time to fix it, partially at least. -- This message was sent by Atlassian Jira (v8.3.4#803005)
