Re: [DISCUSSION] Pull-request checks on GitHub

2020-04-13 Thread Alexey Zinoviev
It's a good idea and many of mature projects have the same

вт, 14 апр. 2020 г., 2:14 Maxim Muzafarov :

> Igniters,
>
> It's really `must-have` feature for me to enable Apache Ignite
> pull-request status checks on GitHub. Currently we don't have any of
> them. The most obvious check for each pull-request is:
>  - build the source code and check code-style violations;
>
> This will give us some advantages. For instance:
> 1. Each PR even a very simple (not require tests execution) will be
> checked by checkstyle and for compile errors.
> 2. Developers can be get notified earlier if checkstyle has been
> violated in their PRs.
>
> To achieve this we can do the following:
> 1. Configure our TeamCity integration with the Ignite GitHub
> repository and PR build. It seems it is possible [2].
> 2. Use Travis-ci which is free for open-source projects and also has
> an integration with GitHub checks [1].
>
>
> What do you think?
> What options will be the best for us?
>
> [1]
> https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com
> [2]
> https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/
>


Ignite Assets and Picture for Your Ignite slides with materials

2020-04-13 Thread Denis Magda
Igniters, especially those who write blog posts or create presentations for
various talks,

As part of the website redesign, we've produced new Ignite diagrams and
pictures that are hosted in Ignite's website Github repo:
https://github.com/apache/ignite-website/tree/master/images/png-diagrams

I added a quick reference to the repo folder from the navigation menu (see
the attachment). In the future, we can create a dedicated HTML page hosted
on the website with logos, wallpapers, etc.

Enjoy!

-
Denis


[DISCUSSION] Pull-request checks on GitHub

2020-04-13 Thread Maxim Muzafarov
Igniters,

It's really `must-have` feature for me to enable Apache Ignite
pull-request status checks on GitHub. Currently we don't have any of
them. The most obvious check for each pull-request is:
 - build the source code and check code-style violations;

This will give us some advantages. For instance:
1. Each PR even a very simple (not require tests execution) will be
checked by checkstyle and for compile errors.
2. Developers can be get notified earlier if checkstyle has been
violated in their PRs.

To achieve this we can do the following:
1. Configure our TeamCity integration with the Ignite GitHub
repository and PR build. It seems it is possible [2].
2. Use Travis-ci which is free for open-source projects and also has
an integration with GitHub checks [1].


What do you think?
What options will be the best for us?

[1] 
https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com
[2] 
https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/


Re: Change Ignite download.cgi page to satisfy requirements

2020-04-13 Thread Maxim Muzafarov
Folks,


As another suggestion, we can place such files (pgp, sha512) here
https://downloads.apache.org/ignite/gce/ (`gce` directory must be
created). I don't have access rights there.

All files have been prepared by me. I'm ready to provide them.

On Mon, 13 Apr 2020 at 19:49, Denis Magda  wrote:
>
> I'm ok with that approach. Petr, what's your thinking?
>
> -
> Denis
>
>
> On Fri, Apr 10, 2020 at 4:20 PM Maxim Muzafarov  wrote:
>
> > Denis, Petr
> >
> > If I'll prepare pgp and sha512 for this Google Compute Image file [1]
> > is there any official repository where we can store these files to use
> > them?
> > Can we upload them to the storage.googleapis.com/ignite-media site?
> >
> > [1] https://storage.googleapis.com/ignite-media/ignite-google-image.tar.gz
> >
> > On Tue, 7 Apr 2020 at 18:56, Denis Magda  wrote:
> > >
> > > Maxim, please go ahead and update the page.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Mon, Apr 6, 2020 at 7:24 PM Maxim Muzafarov 
> > wrote:
> > >
> > > > Denis,
> > > >
> > > > Since the Apache Ignite website has been updated and moved to git can
> > > > we proceed with changing the `download.cgi` page [2]?
> > > >
> > > >
> > > > [1] https://ignite.apache.org/download.cgi
> > > > [2] https://issues.apache.org/jira/browse/IGNITE-12775
> > > >
> > > > On Sat, 28 Mar 2020 at 01:55, Denis Magda  wrote:
> > > > >
> > > > > Agreed,
> > > > >
> > > > > I'll ask INFRA to proceed with the Git migration first days next
> > week.
> > > > > Please wait while the migration ends.
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Fri, Mar 27, 2020 at 11:22 AM Maxim Muzafarov 
> > > > wrote:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > I think we can move to git first. I'll do the changes discussed
> > above
> > > > > > by the end of the next week.
> > > > > >
> > > > > > On Fri, 27 Mar 2020 at 20:55, Denis Magda 
> > wrote:
> > > > > > >
> > > > > > > Maxim,
> > > > > > >
> > > > > > > The new website is launched [1] and we can proceed with the
> > changes
> > > > > > > discussed in this thread.
> > > > > > >
> > > > > > > Will you have time to implement those next week? If it's highly
> > > > unlikely
> > > > > > > then I would request INFRA to move the website to Git first.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > >
> > > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/ANNOUNCEMENT-Ignite-New-Website-is-Live-td46730.html
> > > > > > >
> > > > > > > -
> > > > > > > Denis
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 25, 2020 at 9:47 AM Denis Magda 
> > > > wrote:
> > > > > > >
> > > > > > > > Hi Maxim,
> > > > > > > >
> > > > > > > > Here is a ticket [1] where I've collected INFRA recommendations
> > > > shared
> > > > > > in
> > > > > > > > an adjacent discussion thread. Please check it, add anything
> > new
> > > > you
> > > > > > heard
> > > > > > > > from them.
> > > > > > > >
> > > > > > > > Feel free to take over this task, appreciate your help.
> > However,
> > > > please
> > > > > > > > give me a couple of days to finish the merge of the new
> > website to
> > > > the
> > > > > > > > master branch. After that, you can update the downloads page
> > and
> > > > I'll
> > > > > > > > request INFRA to move the website to a Git repository. I'll
> > send a
> > > > note
> > > > > > > > here once the new website is released.
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12775
> > > > > > > >
> > > > > > > > -
> > > > > > > > Denis
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 25, 2020 at 3:31 AM Maxim Muzafarov <
> > mmu...@apache.org
> > > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > >> Igniters,
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> I've recently found that some of our releases were missed at
> > the
> > > > > > > >> Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3].
> > > > > > > >>
> > > > > > > >> I've contacted the Apache announce list moderators and got the
> > > > > > > >> requirements for our download page [6] (see the message
> > below).
> > > > I'm
> > > > > > > >> going to update the download page on the Apache Ignite website
> > > > > > > >> according to received instructions using these pages as an
> > > > example [1]
> > > > > > > >> [2].
> > > > > > > >>
> > > > > > > >> WDYT?
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Denis,
> > > > > > > >>
> > > > > > > >> Do we have maintainer here or I can proceed with this by
> > myself?
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> >  >
> > > > > > > >>
> > > > > > > >> Sorry, but the download page does not meet the requirements.
> > > > > > > >>
> > > > > > > >> 1) There is no link to the KEYS file
> > > > > > > >> https://downloads.apache.org/ignite/KEYS
> > > > > > > >> This is necessary for validating downloaded artifacts
> > > > > > > >>
> > > > > > > >> 2) No description of how to validate downloads
> > > > > > > >>
> > > > > > > >> 3) There is a 

[jira] [Created] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

2020-04-13 Thread Alexey Kukushkin (Jira)
Alexey Kukushkin created IGNITE-12894:
-

 Summary: Cannot use IgniteAtomicSequence in Ignite services
 Key: IGNITE-12894
 URL: https://issues.apache.org/jira/browse/IGNITE-12894
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


h2. Repro Steps
Execute the below steps in default service deployment mode and in 
discovery-based service deployment mode. 
Use the {{ -DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to 
switch to the discovery-based service deployment mode.
 * Create a service initializing an IgniteAtomicService in method 
Service#init() and using the IgniteAtomicService in a business method.
 * Start an Ignite node with the service specified in the IgniteConfiguration
 * Invoke the service's business method on the Ignite node

h3. Actual Result
h4. In Default Service Deployment Mode
Deadlock on the business method invocation
h4. In Discovery-Based Service Deployment Mode
The method invocation fails with {{IgniteException: Failed to find deployed 
service: IgniteTestService}}

h2. Reproducer
h3. Test.java
{code:java}
public interface Test {
String sayHello(String name);
}
{code}

h3. IgniteTestService.java
{code:java}
public class IgniteTestService implements Test, Service {
private @IgniteInstanceResource Ignite ignite;
private IgniteAtomicSequence seq;

@Override public void cancel(ServiceContext ctx) {
}

@Override public void init(ServiceContext ctx) throws InterruptedException {
seq = ignite.atomicSequence("TestSeq", 0, true);
}

@Override public void execute(ServiceContext ctx) {
}

@Override public String sayHello(String name) {
return "Hello, " + name + "! #" + seq.getAndIncrement();
}
}
{code}

h3. Reproducer.java
{code:java}
public class Reproducer {
public static void main(String[] args) {
IgniteConfiguration igniteCfg = new IgniteConfiguration()
.setServiceConfiguration(
new ServiceConfiguration()
.setName(IgniteTestService.class.getSimpleName())
.setMaxPerNodeCount(1)
.setTotalCount(0)
.setService(new IgniteTestService())
)
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
);

try (Ignite ignite = Ignition.start(igniteCfg)) {

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false)
.sayHello("World");
}
}
}
{code}

h2. Workaround
Specifying a service wait timeout solves the problem in the discovery-based 
service deployment mode (but not in the default deployment mode):
{code:java}

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false, 1_000)
.sayHello("World");
{code}

This workaround cannot be used in Ignite.NET clients since .NET 
{{GetServiceProxy}} API does not support the service wait timeout, which is 
hard-coded to 0 on the server side.

h2. Full Exception in Discovery-Based Service Deployment Mode
{noformat}
[01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor] 
Failed to initialize service (service will not be deployed): IgniteTestService
class org.apache.ignite.IgniteInterruptedException: Got interrupted while 
waiting for future to complete.
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
at 
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.lambda$processDeploymentActions$5(ServiceDeploymentTask.java:318)
at java.base/java.util.HashMap.forEach(HashMap.java:1336)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.processDeploymentActions(ServiceDeploymentTask.java:302)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.init(ServiceDeploymentTask.java:262)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:475)
at 
org.apache.ignite.internal.util.worker

[jira] [Created] (IGNITE-12893) Add support for the SimplifyBooleanExpression rule to checkstyle

2020-04-13 Thread Maxim Muzafarov (Jira)
Maxim Muzafarov created IGNITE-12893:


 Summary: Add support for the SimplifyBooleanExpression rule to 
checkstyle
 Key: IGNITE-12893
 URL: https://issues.apache.org/jira/browse/IGNITE-12893
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov


The rule must be supported by the checkstyle according to Ignite coding 
conventions [1].

{code}

{code}
 
https://checkstyle.sourceforge.io/config_coding.html#SimplifyBooleanExpression

https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Useof%22!%22insteadofexplicit%22==true%22and%22==false%22



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-12892) Clarify WAL archive size configuration

2020-04-13 Thread Semyon Danilov (Jira)
Semyon Danilov created IGNITE-12892:
---

 Summary: Clarify WAL archive size configuration
 Key: IGNITE-12892
 URL: https://issues.apache.org/jira/browse/IGNITE-12892
 Project: Ignite
  Issue Type: Sub-task
Reporter: Semyon Danilov
Assignee: Semyon Danilov


Actual maximum size of WAL archive that can be reserved for historical 
rebalance is calculated as minimum of three properties:
 # DataStorageConfiguration#walHistSize (units: number of checkpoints)
 # DataStorageConfiguration#maxWalArchiveSize (units: bytes)
 # IgniteSystemProperties#IGNITE_PDS_MAX_CHECKPOINT_MEMORY_HISTORY_SIZE (units: 
number of checkpoints)

The logic is a little unclear, so I propose following changes:
 # Stop using walHistSize at all (it's already deprecated) for WAL truncation
 # Use IGNITE_PDS_MAX_CHECKPOINT_MEMORY_HISTORY_SIZE only in case WAL archive 
is managed externally (so we limit the quantity of checkpoints stored in 
memory, but don't remove WAL files)
 # Use -1 for maxWalArchiveSize (instead of Long.MAX_VALUE) to disable WAL 
truncation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: No commits to Ignite website: migration from SVN to Git is in progress

2020-04-13 Thread Denis Magda
Hello Saikat,

You can find short website development guidelines on this page [1]. They
are elementary and request to use pull-requests, especially, if the one is
not a committer. Feel free to elaborate on the process.

Btw, what are the scripts referred by you?

[1] https://cwiki.apache.org/confluence/display/IGNITE/Website+Development
-
Denis


On Sun, Apr 12, 2020 at 12:26 PM Saikat Maitra 
wrote:

> Hello,
>
> Are we following the same contribution flow as we are doing for ignite git
> repo?
>
>
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ClosingaTicket
>
> I have observed that github ignite-website is also mirrored at
> https://gitbox.apache.org/repos/asf?p=ignite-website.git
>
> I can add our scripts folder in ignite-website folder if it helps.
>
> Regards,
> Saikat
>
> On Tue, Apr 7, 2020 at 12:49 AM Ivan Pavlukhin 
> wrote:
>
> > Thank you!
> >
> > Best regards,
> > Ivan Pavlukhin
> >
> > вт, 7 апр. 2020 г. в 00:46, Denis Magda :
> > >
> > > The website is back to normal and serves the content from the Git
> > > repository's "master" branch:
> > > https://github.com/apache/ignite-website/blob/master
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Mon, Apr 6, 2020 at 2:19 PM Denis Magda  wrote:
> > >
> > > > I'm checking with the INFRA. It's down for at least the last couple
> of
> > > > hours.
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Mon, Apr 6, 2020 at 12:44 PM Ivan Pavlukhin 
> > > > wrote:
> > > >
> > > >> Denis,
> > > >>
> > > >> Is it expected that main website https://ignite.apache.org/ does
> not
> > > >> work now?
> > > >>
> > > >> Best regards,
> > > >> Ivan Pavlukhin
> > > >>
> > > >> сб, 4 апр. 2020 г. в 01:15, Denis Magda :
> > > >> >
> > > >> > Igniters,
> > > >> >
> > > >> > Please avoid any commits to the website repository until further
> > notice.
> > > >> > We're in a process of the migration:
> > > >> > https://issues.apache.org/jira/browse/INFRA-20065
> > > >> >
> > > >> > -
> > > >> > Denis
> > > >>
> > > >
> >
>


Re: Change Ignite download.cgi page to satisfy requirements

2020-04-13 Thread Denis Magda
I'm ok with that approach. Petr, what's your thinking?

-
Denis


On Fri, Apr 10, 2020 at 4:20 PM Maxim Muzafarov  wrote:

> Denis, Petr
>
> If I'll prepare pgp and sha512 for this Google Compute Image file [1]
> is there any official repository where we can store these files to use
> them?
> Can we upload them to the storage.googleapis.com/ignite-media site?
>
> [1] https://storage.googleapis.com/ignite-media/ignite-google-image.tar.gz
>
> On Tue, 7 Apr 2020 at 18:56, Denis Magda  wrote:
> >
> > Maxim, please go ahead and update the page.
> >
> > -
> > Denis
> >
> >
> > On Mon, Apr 6, 2020 at 7:24 PM Maxim Muzafarov 
> wrote:
> >
> > > Denis,
> > >
> > > Since the Apache Ignite website has been updated and moved to git can
> > > we proceed with changing the `download.cgi` page [2]?
> > >
> > >
> > > [1] https://ignite.apache.org/download.cgi
> > > [2] https://issues.apache.org/jira/browse/IGNITE-12775
> > >
> > > On Sat, 28 Mar 2020 at 01:55, Denis Magda  wrote:
> > > >
> > > > Agreed,
> > > >
> > > > I'll ask INFRA to proceed with the Git migration first days next
> week.
> > > > Please wait while the migration ends.
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Fri, Mar 27, 2020 at 11:22 AM Maxim Muzafarov 
> > > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > I think we can move to git first. I'll do the changes discussed
> above
> > > > > by the end of the next week.
> > > > >
> > > > > On Fri, 27 Mar 2020 at 20:55, Denis Magda 
> wrote:
> > > > > >
> > > > > > Maxim,
> > > > > >
> > > > > > The new website is launched [1] and we can proceed with the
> changes
> > > > > > discussed in this thread.
> > > > > >
> > > > > > Will you have time to implement those next week? If it's highly
> > > unlikely
> > > > > > then I would request INFRA to move the website to Git first.
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/ANNOUNCEMENT-Ignite-New-Website-is-Live-td46730.html
> > > > > >
> > > > > > -
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 25, 2020 at 9:47 AM Denis Magda 
> > > wrote:
> > > > > >
> > > > > > > Hi Maxim,
> > > > > > >
> > > > > > > Here is a ticket [1] where I've collected INFRA recommendations
> > > shared
> > > > > in
> > > > > > > an adjacent discussion thread. Please check it, add anything
> new
> > > you
> > > > > heard
> > > > > > > from them.
> > > > > > >
> > > > > > > Feel free to take over this task, appreciate your help.
> However,
> > > please
> > > > > > > give me a couple of days to finish the merge of the new
> website to
> > > the
> > > > > > > master branch. After that, you can update the downloads page
> and
> > > I'll
> > > > > > > request INFRA to move the website to a Git repository. I'll
> send a
> > > note
> > > > > > > here once the new website is released.
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12775
> > > > > > >
> > > > > > > -
> > > > > > > Denis
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 25, 2020 at 3:31 AM Maxim Muzafarov <
> mmu...@apache.org
> > > >
> > > > > wrote:
> > > > > > >
> > > > > > >> Igniters,
> > > > > > >>
> > > > > > >>
> > > > > > >> I've recently found that some of our releases were missed at
> the
> > > > > > >> Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3].
> > > > > > >>
> > > > > > >> I've contacted the Apache announce list moderators and got the
> > > > > > >> requirements for our download page [6] (see the message
> below).
> > > I'm
> > > > > > >> going to update the download page on the Apache Ignite website
> > > > > > >> according to received instructions using these pages as an
> > > example [1]
> > > > > > >> [2].
> > > > > > >>
> > > > > > >> WDYT?
> > > > > > >>
> > > > > > >>
> > > > > > >> Denis,
> > > > > > >>
> > > > > > >> Do we have maintainer here or I can proceed with this by
> myself?
> > > > > > >>
> > > > > > >>
> > > > > > >> >  >
> > > > > > >>
> > > > > > >> Sorry, but the download page does not meet the requirements.
> > > > > > >>
> > > > > > >> 1) There is no link to the KEYS file
> > > > > > >> https://downloads.apache.org/ignite/KEYS
> > > > > > >> This is necessary for validating downloaded artifacts
> > > > > > >>
> > > > > > >> 2) No description of how to validate downloads
> > > > > > >>
> > > > > > >> 3) There is a link to nightly builds.
> > > > > > >> That is not allowed on a public download page, as the builds
> have
> > > not
> > > > > been
> > > > > > >> voted on.
> > > > > > >>
> > > > > > >> 4) The paragraph introducing the binary artifact says:
> > > > > > >>
> > > > > > >> "In order to verify the release, we recommend that you
> download
> > > the
> > > > > > >> official source distribution and verify the signatures of the
> > > > > downloaded
> > > > > > >> files before opening them."
> > > > > > >>
> > > > > > >> This does not make sense in the binary section (it belongs in
> the
> > > > > source
> > > 

Re: Registration CQ on client nodes.

2020-04-13 Thread Mikhail Petrov

Alexey,

Thanks for clarification. I think that is all I wanted to know.

Thank you.

On 13.04.2020 11:43, Alexey Goncharuk wrote:

Mikhail,

I think you've answered your first question in your second question. The
CQ handler on client nodes does not make sense because there is no data on
client nodes that can be notified of, therefore there is no reason to fail
the CQ as it does not affect the execution in any way.

As for the message being sent to clients - if I remember correctly, there
were no mechanics to filter out discovery messages to exclude clients.
Perhaps, such a mechanics can be introduced to the SPI to resolve
this issue.

пн, 13 апр. 2020 г. в 09:33, Mikhail Petrov :


Hello, Igniters.

I recently noticed that if the client node failed to register the CQ
handler during CQ start, the start of CQ succeeds despite this.

In this case, the error message appears in the client log. It can be
something like this:

[2020-04-13
09:20:48,315][ERROR][disco-notifier-worker-#84%continuous.ContinuousQueryRemoteFilterMissingInClassPathSelfTest2%][GridContinuousProcessor]

Failed to register handler [nodeId=aa8e3541-0b93-40f7-8310-3f3a7e61,
routineId=6fb6f0e9-4c30-46d2-9cf2-1765e0b3c9be]
class org.apache.ignite.IgniteCheckedException:

org.apache.ignite.tests.p2p.CacheDeploymentCacheEntryEventSerializableFilter
  at

org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1385)
  at

org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:117)
  at

org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:220)
  at

org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:211)
  at

org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:670)
  at

org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
  at

org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2635)
  at

org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2673)
  at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
  at java.lang.Thread.run(Thread.java:748)

The test [1] demonstrates this behavior as valid.


Can someone please clarify why this behavior is considered valid?

Moreover, are there any reasons for sending the CQ registration message
to client nodes given that there is no data on them?

I'll appreciate any thoughts.


[1] -

https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java#L223

Regards,
Mikhail.




Re: Add user defined attributes to all GridClient messages.

2020-04-13 Thread Andrey Kuznetsov
+1

We should garantee user attributes transmission to cluster once they are
set in client configuration.

пн, 13 апр. 2020 г. в 15:09, Oleg Ostanin :

> Hello, Igniters!
>
> Recently we added the possibility of sending user defined attributes from
> clients, and check those attributes in a custom authenticator
> implementation[1]. However in some cases it's not working well for
> GridClient because currently the attributes are only added to TOPOLOGY
> message. I've created a ticket with a reproducer:
>
> https://issues.apache.org/jira/browse/IGNITE-12891
>
> I suggest solving this problem by adding user defined attributes to other
> GridClient messages such as GridClientAutheticationRequest and so on.
>
> What do you think?
>
> Best regards
> Oleg
>
> [1]
> https://issues.apache.org/jira/browse/IGNITE-12049
>


-- 
Best regards,
  Andrey Kuznetsov.


Re: Remove "This operating system has been tested less rigorously" diagnostic

2020-04-13 Thread Pavel Tupitsyn
Since there are no objections, I'll go ahead with removal.

Thanks

On Wed, Apr 8, 2020 at 10:35 PM Pavel Tupitsyn  wrote:

> Igniters,
>
> Let's remove "This operating system has been tested less rigorously"
> diagnostic [1] [2].
> It does not make sense:
> * All Linux and macOS versions are considered the same
> * Windows versions are differentiated
> * Windows 10 and all Windows Servers are considered badly tested
>
> None of that is correct. We barely test on macOS. We don't test all the
> different Linux distros, old kernels, and so on.
>
> It is hardly possible to make this diagnostic useful. Let's remove it.
> Any objections?
>
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/GridDiagnostic.java#L94
> [2]
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L6864
>


Add user defined attributes to all GridClient messages.

2020-04-13 Thread Oleg Ostanin
Hello, Igniters!

Recently we added the possibility of sending user defined attributes from
clients, and check those attributes in a custom authenticator
implementation[1]. However in some cases it's not working well for
GridClient because currently the attributes are only added to TOPOLOGY
message. I've created a ticket with a reproducer:

https://issues.apache.org/jira/browse/IGNITE-12891

I suggest solving this problem by adding user defined attributes to other
GridClient messages such as GridClientAutheticationRequest and so on.

What do you think?

Best regards
Oleg

[1]
https://issues.apache.org/jira/browse/IGNITE-12049


[jira] [Created] (IGNITE-12891) Add userAttributes map to all GridClient messages

2020-04-13 Thread Oleg Ostanin (Jira)
Oleg Ostanin created IGNITE-12891:
-

 Summary: Add userAttributes map to all GridClient messages
 Key: IGNITE-12891
 URL: https://issues.apache.org/jira/browse/IGNITE-12891
 Project: Ignite
  Issue Type: Bug
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin


Currently we are only sending userAttributes map in GridClient TOPOLOGY 
message. In some particular circumstances it can lead to an authentication 
failure.

Reproducer:

https://github.com/oleg-ostanin/ignite/blob/gridclient-fail-reproducer/modules/core/src/test/java/org/apache/ignite/internal/processors/security/client/AdditionalSecurityCheckGridClientTest.java



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: Сontribution permission

2020-04-13 Thread Ilya Kasnacheev
Hello!

I have added you to Contributors role, you can now assign this issue to
yourself.

Please make sure to read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Regards,
-- 
Ilya Kasnacheev


пн, 13 апр. 2020 г. в 12:25, Maria Makedonskaya :

> Hello!
>
> I would like to contribute to apache ignite and i am asking for
> contribution permission.
>
> I would like to start with IGNITE-12890.
>
> My github username: makedonskaya
>
> Jira username: makedonskaya
>


Сontribution permission

2020-04-13 Thread Maria Makedonskaya
Hello!

I would like to contribute to apache ignite and i am asking for
contribution permission.

I would like to start with IGNITE-12890.

My github username: makedonskaya

Jira username: makedonskaya


Re: Registration CQ on client nodes.

2020-04-13 Thread Alexey Goncharuk
Mikhail,

I think you've answered your first question in your second question. The
CQ handler on client nodes does not make sense because there is no data on
client nodes that can be notified of, therefore there is no reason to fail
the CQ as it does not affect the execution in any way.

As for the message being sent to clients - if I remember correctly, there
were no mechanics to filter out discovery messages to exclude clients.
Perhaps, such a mechanics can be introduced to the SPI to resolve
this issue.

пн, 13 апр. 2020 г. в 09:33, Mikhail Petrov :

> Hello, Igniters.
>
> I recently noticed that if the client node failed to register the CQ
> handler during CQ start, the start of CQ succeeds despite this.
>
> In this case, the error message appears in the client log. It can be
> something like this:
>
> [2020-04-13
> 09:20:48,315][ERROR][disco-notifier-worker-#84%continuous.ContinuousQueryRemoteFilterMissingInClassPathSelfTest2%][GridContinuousProcessor]
>
> Failed to register handler [nodeId=aa8e3541-0b93-40f7-8310-3f3a7e61,
> routineId=6fb6f0e9-4c30-46d2-9cf2-1765e0b3c9be]
> class org.apache.ignite.IgniteCheckedException:
>
> org.apache.ignite.tests.p2p.CacheDeploymentCacheEntryEventSerializableFilter
>  at
>
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1385)
>  at
>
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:117)
>  at
>
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:220)
>  at
>
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:211)
>  at
>
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:670)
>  at
>
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
>  at
>
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2635)
>  at
>
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2673)
>  at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>  at java.lang.Thread.run(Thread.java:748)
>
> The test [1] demonstrates this behavior as valid.
>
>
> Can someone please clarify why this behavior is considered valid?
>
> Moreover, are there any reasons for sending the CQ registration message
> to client nodes given that there is no data on them?
>
> I'll appreciate any thoughts.
>
>
> [1] -
>
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java#L223
>
> Regards,
> Mikhail.
>
>