Re: [DISCUSSION] Pull-request checks on GitHub
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
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
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
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
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
[jira] [Created] (IGNITE-12893) Add support for the SimplifyBooleanExpression rule to checkstyle
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
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
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
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.
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.
+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
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.
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
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
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
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.
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. > >
Registration CQ on client nodes.
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.
