Re: [DISCUSSION] Common approach to print sensitive information

[Evgenii Zhuravlev]

Ivan,

I've been talking with different users from different industries and some
of them(definitely not all of them) consider schema sensitive information.
As a framework, that can be used by different types of users, we should
cover this use case too. The solution, suggested by Ilya sounds very
reasonable here - not all the users have so strict restrictions, but still,
some of them have.

Best Regards,
Evgenii

пн, 5 апр. 2021 г. в 04:07, Ivan Daschinsky :

> Ilya, great idea, but I suppose that third option is a little bit paranoid.
> But nevertheless, let it be, it's quite simple to implement it.
>
> пн, 5 апр. 2021 г. в 14:04, Ilya Kasnacheev :
>
> > Hello!
> >
> > I have two ideas here:
> >
> > - Let's have more than a single level of sensitive information
> withholding.
> > Currently it is on/off, but I think we may need three levels: "print
> all",
> > "print structure but not content", "print none".
> > By structure I mean table/column/field names and data types. So we can
> > print SQL statements in their EXPLAIN form to log, but do not print any
> > query arguments or values, substituting them with '?'. We can also print
> > class and field names in various places.
> > - If we have a default different from "print all", we should add a
> > developer warning about it, such as
> > [WARN ] Sensitive information will not be written to log by default.
> > Consider *doing things* to enable developer mode.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 5 апр. 2021 г. в 13:45, Taras Ledkov :
> >
> > > Hi,
> > >
> > > I work on ticket IGNITE-14441 [1] to hide sensitive information at the
> > > log messages produced by SQL.
> > > There are negative comments for the patch.
> > >
> > > I guess we have to produce view to work with sensitive information and
> > > make rules to define sensitive information.
> > >
> > > See on the usage of the GridToStringBuilder#includeSensitive. Class
> > > names and  field names now are considered sensitive.
> > > My train of thought is this: SQL query and query plan contain table
> name
> > > (similar to class name) and field name.
> > > So, the query and plan are completely sensitive.
> > >
> > > Lets define sensitive info and work with it for Ignite.
> > >
> > > Someone proposes introduce one more Ignite property for print SQL
> > > sensitive info.
> > > I think this leads to complication.
> > >
> > > Introduce levels of the sensitivity make sense but all similar
> > > information must be handled with the same rules.
> > >
> > > Igniters, WDYT?
> > >
> > > [1]. https://issues.apache.org/jira/browse/IGNITE-14441
> > >
> > > --
> > > Taras Ledkov
> > > Mail-To: tled...@gridgain.com
> > >
> > >
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>

[jira] [Created] (IGNITE-14482) Update the code snippet

[Nikita Safonov (Jira)]

Nikita Safonov created IGNITE-14482:
---

 Summary: Update the code snippet 
 Key: IGNITE-14482
 URL: https://issues.apache.org/jira/browse/IGNITE-14482
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Reporter: Nikita Safonov


See the XML code snippet of this section: 
[https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#google-compute-discovery]
 and change the line
{{}}
{code:java}
 name="projectName" ref="YOUR_GOOGLE_PLATFORM_PROJECT_NAME"{code}
{{}} to{{}}
{code:java}
name="projectName" value="YOUR_GOOGLE_PLATFORM_PROJECT_NAME" on both pages{code}



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

Re: Azure Cloud IP Finder

[Ilya Kasnacheev]

Hello again!

I re-checked our cloud discovery options by moving ignite-aws, ignite-gce,
ignite-cloud directories from lib/optional to lib/ and trying to run Ignite
with simple config taken from examples.

The results are the following:
ignite-aws seems to work (complains about unknown key)
ignite-gce seems to work too (complains about zero length key, this is
before it tries any network access so maybe there are other issues down the
path)
ignite-cloud (jclouds) DOES NOT work. Filed
https://issues.apache.org/jira/browse/IGNITE-14481 . I guess this discovery
finder is not widely used.
ignite-azure, presently, will not work too. Please use ignite-aws as an
example since it sees the most usage.

Regards,
-- 
Ilya Kasnacheev


пн, 5 апр. 2021 г. в 16:05, Ilya Kasnacheev :

> Hello!
>
> I'm not sure that I can see any attachment to your e-mail. Can you please
> re-send?
>
> We could have broken some of those, I guess, since we seem to not run
> integration tests for them.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 2 апр. 2021 г. в 12:59, Atri Sharma :
>
>> Hello,
>>
>> Thank you for sharing.
>>
>> I was finally able to replicate the issue. However, I tried with other
>> IPFinders and ran into the same problem (attached are the logs).
>>
>> Not sure what is causing this?
>>
>> Atri
>>
>> On Fri, Apr 2, 2021 at 2:29 PM Ilya Kasnacheev
>>  wrote:
>> >
>> > Hello!
>> >
>> > Please find attached the log file of errors. This is yesterday's (Apr
>> 1) build.
>> >
>> > Regards,
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > пт, 2 апр. 2021 г. в 11:52, Atri Sharma :
>> >>
>> >> I was able to, but then, it might be that something is cached locally.
>> >>
>> >> What errors did you run into? (I am assuming you are trying with a
>> >> build from the latest iteration of the PR).
>> >>
>> >> Atri
>> >>
>> >> On Fri, Apr 2, 2021 at 2:19 PM Ilya Kasnacheev
>> >>  wrote:
>> >> >
>> >> > Hello!
>> >> >
>> >> > But are you successful in running a node with Azure IP finder
>> enabled in
>> >> > configuration, starting from that release directory?
>> >> >
>> >> > I amn't.
>> >> >
>> >> > Regards,
>> >> > --
>> >> > Ilya Kasnacheev
>> >> >
>> >> >
>> >> > пт, 2 апр. 2021 г. в 07:42, Atri Sharma :
>> >> >
>> >> > > Hello,
>> >> > >
>> >> > > Thank you for taking a look.
>> >> > >
>> >> > > I am not sure what the confusion is. On the current iteration of
>> PR, I
>> >> > > am able to build and release and looking in the location you
>> >> > > mentioned, I see:
>> >> > >
>> >> > > Atris-MacBook-Pro-15:libs atrisharma$ cd optional/
>> >> > >
>> >> > > Atris-MacBook-Pro-15:optional atrisharma$ cd ignite-azure/
>> >> > >
>> >> > > Atris-MacBook-Pro-15:ignite-azure atrisharma$ ls
>> >> > >
>> >> > > README.txt azure-storage-blob-12.0.0.jar
>> ignite-azure-2.11.0-SNAPSHOT.jar
>> >> > >
>> >> > >
>> >> > > Attached is the screenshot.
>> >> > >
>> >> > > I have fixed the comments on the PR, please see and let me know.
>> >> > >
>> >> > > Atri
>> >> > >
>> >> > > On Thu, Apr 1, 2021 at 8:21 PM Ilya Kasnacheev
>> >> > >  wrote:
>> >> > > >
>> >> > > > Hello!
>> >> > > >
>> >> > > > Were you successful with using it from the deliverable of mvn
>> initialize
>> >> > > > -Prelease?
>> >> > > >
>> >> > > > Please refer for example to aws module dependencies section:
>> >> > > >
>> >> > > > 
>> >> > > > com.amazonaws
>> >> > > > aws-java-sdk-core
>> >> > > > ${aws.sdk.version}
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > com.amazonaws
>> >> > > > aws-java-sdk-s3
>> >> > > > ${aws.sdk.version}
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > com.amazonaws
>> >> > > > aws-java-sdk-ec2
>> >> > > > ${aws.sdk.version}
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > com.amazonaws
>> >> > > > aws-java-sdk-elasticloadbalancing
>> >> > > > ${aws.sdk.version}
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > com.amazonaws
>> >> > > > aws-java-sdk-elasticloadbalancingv2
>> >> > > > ${aws.sdk.version}
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > com.amazonaws
>> >> > > > aws-java-sdk-kms
>> >> > > > ${aws.sdk.version}
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > 
>> >> > > > com.fasterxml.jackson.core
>> >> > > > jackson-core
>> >> > > > ${jackson.version}
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > 
>> >> > > > com.fasterxml.jackson.core
>> >> > > > jackson-annotations
>> >> > > > ${jackson.version}
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > 
>> >> > > > com.fasterxml.jackson.core
>> >> > > > jackson-databind
>> >> > > > ${jackson.version}
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > com.amazonaws
>> >> > > > aws-encryption-sdk-java
>> >> > > > ${aws.encryption.sdk.version}
>> >> > > > 
>> >> > > > 
>> >> > > > org.bouncycastle
>> >> > > > bcprov-ext-jdk15on
>> >> > > > 
>> >> > > > 
>> >> > > > 
>> >> > > >
>> >> > > > 
>> >> > > > org.bouncycastle
>> >> 

[jira] [Created] (IGNITE-14481) Missing dependencies for JClouds discovery (ignite-cloud)

[Ilya Kasnacheev (Jira)]

Ilya Kasnacheev created IGNITE-14481:


 Summary: Missing dependencies for JClouds discovery (ignite-cloud)
 Key: IGNITE-14481
 URL: https://issues.apache.org/jira/browse/IGNITE-14481
 Project: Ignite
  Issue Type: Bug
  Components: integrations
Affects Versions: 2.10
Reporter: Ilya Kasnacheev


We seem to skip some essential dependencies for jclouds-based discovery, since 
trying to start a node results in the following error:
{code}
Caused by: org.springframework.beans.factory.BeanCreationException: Error 
creating bean with name 
'org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinder#1877ab81'
 defined in URL 
[file:/home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/config/cloud-config.xml]:
 Initialization of bean failed; nested exception is 
java.lang.NoClassDefFoundError: Lorg/jclouds/compute/ComputeService;
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:562)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:481)
at 
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:299)
... 28 more
Caused by: java.lang.NoClassDefFoundError: Lorg/jclouds/compute/ComputeService;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
at java.lang.Class.getDeclaredFields(Class.java:1916)
at 
org.springframework.util.ReflectionUtils.getDeclaredFields(ReflectionUtils.java:713)
at 
org.springframework.util.ReflectionUtils.findField(ReflectionUtils.java:97)
at 
org.springframework.util.ReflectionUtils.findField(ReflectionUtils.java:80)
at org.springframework.core.convert.Property.getField(Property.java:225)
at 
org.springframework.core.convert.Property.resolveAnnotations(Property.java:202)
at 
org.springframework.core.convert.Property.getAnnotations(Property.java:123)
at 
org.springframework.core.convert.TypeDescriptor.(TypeDescriptor.java:115)
at 
org.springframework.beans.BeanWrapperImpl.convertForProperty(BeanWrapperImpl.java:214)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.convertForProperty(AbstractAutowireCapableBeanFactory.java:1568)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1527)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1269)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:551)
... 30 more
Caused by: java.lang.ClassNotFoundException: org.jclouds.compute.ComputeService
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 45 more
{code}

The following default config is used:
{code}

  

  

 
 
 
 
 
 
 us-central1-a
 asia-east1-a
 
 
 
  

  

{code}

By the way, there is extra closing slash in initial  tag in 
org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinder 
javadoc (line 112). Makes sense to fix.



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

Contributor grants request

[Rodion Smolnikov]

Hello!
Can I get contributor access?
Task https://issues.apache.org/jira/browse/IGNITE-14474

-- 

Rodion Smolnikov

+7(915)256-54-81
Software Developer, Russia

*gridgain.com *

[jira] [Created] (IGNITE-14480) Add release notes for performance-statistics-ext, spring-data*-ext, spring-tx-ext extensions 1.0.0 version

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-14480:


 Summary: Add release notes for performance-statistics-ext, 
spring-data*-ext, spring-tx-ext extensions 1.0.0 version
 Key: IGNITE-14480
 URL: https://issues.apache.org/jira/browse/IGNITE-14480
 Project: Ignite
  Issue Type: Task
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita






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

[jira] [Created] (IGNITE-14479) Add column default values support.

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-14479:
-

 Summary: Add column default values support.
 Key: IGNITE-14479
 URL: https://issues.apache.org/jira/browse/IGNITE-14479
 Project: Ignite
  Issue Type: New Feature
Reporter: Andrey Mashenkov


Let's add default column values support.

Tuple has no default-value-map support (like null-map).
Thus, we should be able to answer if a 'null' value was set or a value was not 
set to Tuple
and write a default column value to Row explicitely if it was not specified in 
Tuple.

This may require extending the Tuple contract, which is ok.






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

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Maxim Muzafarov]

Denis,

If the initial release of some of the extension happens there is no
need to release each time a new Ignite version is released (if there
are no changes of a particular extension). So we should release the
initial release as fast as possible and do the others according to
needs. This is my view, but maybe I'm missing something.

On Mon, 5 Apr 2021 at 15:57, Denis Magda  wrote:
>
> Hi Maxim,
>
> I would suggest we time a release of the Ignite core and the extensions in
> the future. As of now, I can't switch to Ignite 2.10 only due to the Spring
> Data module. Not the end of the world but delays the upgrade to the new
> version.
>
> -
> Denis
>
>
> On Mon, Apr 5, 2021 at 6:32 AM Maxim Muzafarov  wrote:
>
> > Denis,
> >
> > There is no spring data artifact for the 2.10 release. We should
> > prepare the release of these extensions as fast as possible.
> >
> > On Fri, 2 Apr 2021 at 20:06, Denis Magda  wrote:
> > >
> > > Is this the first time we're releasing spring data 2.2 as an ext? Can't
> > > find any version available for 2.10? What should I use if I need Spring
> > > Data integration now for Ignite 2.10?
> > >
> > https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data_2.2
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Fri, Mar 26, 2021 at 12:55 AM Nikita Amelchev 
> > > wrote:
> > >
> > > > Hi, Denis.
> > > >
> > > > > - How is the performance stats ext is different from the profiling
> > tool
> > > > >   released in 2.10?
> > > >
> > > > The performance statistics extension is a script to build an HTML
> > > > report. The core module collects statistics to binary files and this
> > > > feature was released in 2.10.
> > > >
> > > > чт, 25 мар. 2021 г. в 21:05, Denis Magda :
> > > > >
> > > > > +1
> > > > >
> > > > > I missed our progress on the extensions frontier. Great to see more
> > > > > capabilities added to the Spring framework support.
> > > > >
> > > > > Several questions (but, I fully support the release of the
> > extensions):
> > > > >
> > > > >- How is the performance stats ext is different from the profiling
> > > > tool
> > > > >released in 2.10?
> > > > >- I've created this tutorial[1] a while ago for the Spring Data
> > > > >integration. Would you advise updating it considering any new
> > features
> > > > >(such as thin-client support)?
> > > > >- Don't you want guys to submit a talk to the Ignite Summit[2]?
> > It can
> > > > >be a "hitchhiker guide to the Spring support in Ignite" or "Using
> > > > Profiling
> > > > >to Solve Performance issues in Ignite". Happy to help with an
> > > > abstract.
> > > > >
> > > > >
> > > > > [1]
> > > > https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial
> > > > > [2] https://ignite-summit.org
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev <
> > namelc...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > Since Ignite 2.10 has been released, I think we can now release new
> > > > > > extension modules:
> > > > > >
> > > > > > performance-statistics-ext
> > > > > > spring-data-ext
> > > > > > spring-tx-ext
> > > > > >
> > > > > > I want to be a release manager for these if nobody minds.
> > > > > >
> > > > > > The release process can be started after resolving a few
> > documentation
> > > > > > issues:
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/IGNITE-14417
> > > > > > https://issues.apache.org/jira/browse/IGNITE-14398
> > > > > > https://issues.apache.org/jira/browse/IGNITE-14397
> > > > > > https://issues.apache.org/jira/browse/IGNITE-13769
> > > > > >
> > > > > > --
> > > > > > Best wishes,
> > > > > > Amelchev Nikita
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best wishes,
> > > > Amelchev Nikita
> > > >
> >

Re: Azure Cloud IP Finder

[Ilya Kasnacheev]

Hello!

I'm not sure that I can see any attachment to your e-mail. Can you please
re-send?

We could have broken some of those, I guess, since we seem to not run
integration tests for them.

Regards,
-- 
Ilya Kasnacheev


пт, 2 апр. 2021 г. в 12:59, Atri Sharma :

> Hello,
>
> Thank you for sharing.
>
> I was finally able to replicate the issue. However, I tried with other
> IPFinders and ran into the same problem (attached are the logs).
>
> Not sure what is causing this?
>
> Atri
>
> On Fri, Apr 2, 2021 at 2:29 PM Ilya Kasnacheev
>  wrote:
> >
> > Hello!
> >
> > Please find attached the log file of errors. This is yesterday's (Apr 1)
> build.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 2 апр. 2021 г. в 11:52, Atri Sharma :
> >>
> >> I was able to, but then, it might be that something is cached locally.
> >>
> >> What errors did you run into? (I am assuming you are trying with a
> >> build from the latest iteration of the PR).
> >>
> >> Atri
> >>
> >> On Fri, Apr 2, 2021 at 2:19 PM Ilya Kasnacheev
> >>  wrote:
> >> >
> >> > Hello!
> >> >
> >> > But are you successful in running a node with Azure IP finder enabled
> in
> >> > configuration, starting from that release directory?
> >> >
> >> > I amn't.
> >> >
> >> > Regards,
> >> > --
> >> > Ilya Kasnacheev
> >> >
> >> >
> >> > пт, 2 апр. 2021 г. в 07:42, Atri Sharma :
> >> >
> >> > > Hello,
> >> > >
> >> > > Thank you for taking a look.
> >> > >
> >> > > I am not sure what the confusion is. On the current iteration of
> PR, I
> >> > > am able to build and release and looking in the location you
> >> > > mentioned, I see:
> >> > >
> >> > > Atris-MacBook-Pro-15:libs atrisharma$ cd optional/
> >> > >
> >> > > Atris-MacBook-Pro-15:optional atrisharma$ cd ignite-azure/
> >> > >
> >> > > Atris-MacBook-Pro-15:ignite-azure atrisharma$ ls
> >> > >
> >> > > README.txt azure-storage-blob-12.0.0.jar
> ignite-azure-2.11.0-SNAPSHOT.jar
> >> > >
> >> > >
> >> > > Attached is the screenshot.
> >> > >
> >> > > I have fixed the comments on the PR, please see and let me know.
> >> > >
> >> > > Atri
> >> > >
> >> > > On Thu, Apr 1, 2021 at 8:21 PM Ilya Kasnacheev
> >> > >  wrote:
> >> > > >
> >> > > > Hello!
> >> > > >
> >> > > > Were you successful with using it from the deliverable of mvn
> initialize
> >> > > > -Prelease?
> >> > > >
> >> > > > Please refer for example to aws module dependencies section:
> >> > > >
> >> > > > 
> >> > > > com.amazonaws
> >> > > > aws-java-sdk-core
> >> > > > ${aws.sdk.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > com.amazonaws
> >> > > > aws-java-sdk-s3
> >> > > > ${aws.sdk.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > com.amazonaws
> >> > > > aws-java-sdk-ec2
> >> > > > ${aws.sdk.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > com.amazonaws
> >> > > > aws-java-sdk-elasticloadbalancing
> >> > > > ${aws.sdk.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > com.amazonaws
> >> > > > aws-java-sdk-elasticloadbalancingv2
> >> > > > ${aws.sdk.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > com.amazonaws
> >> > > > aws-java-sdk-kms
> >> > > > ${aws.sdk.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > 
> >> > > > com.fasterxml.jackson.core
> >> > > > jackson-core
> >> > > > ${jackson.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > 
> >> > > > com.fasterxml.jackson.core
> >> > > > jackson-annotations
> >> > > > ${jackson.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > 
> >> > > > com.fasterxml.jackson.core
> >> > > > jackson-databind
> >> > > > ${jackson.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > com.amazonaws
> >> > > > aws-encryption-sdk-java
> >> > > > ${aws.encryption.sdk.version}
> >> > > > 
> >> > > > 
> >> > > > org.bouncycastle
> >> > > > bcprov-ext-jdk15on
> >> > > > 
> >> > > > 
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > org.bouncycastle
> >> > > > bcprov-ext-jdk15on
> >> > > > ${bouncycastle.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > joda-time
> >> > > > joda-time
> >> > > > 2.8.1
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > org.apache.httpcomponents
> >> > > > httpclient
> >> > > > ${httpclient.version}
> >> > > > 
> >> > > >
> >> > > > 
> >> > > > org.apache.httpcomponents
> >> > > > httpcore
> >> > > > ${httpcore.version}
> >> > > > 
> >> > > >
> >> > > > azure module should likewise list all of its actual dependencies.
> Right
> >> > > now
> >> > > > the module directory is empty so I'm not even going to test to
> run it in
> >> > > > stand-alone mode:
> >> > > > ~/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin% ls
> >> > > libs/optional/ignite-azure
> >> > > > azure-storage-blob-12.0.0.jar  ignite-azure-2.11.0-SNAPSHOT.jar
> >> > > README.txt
> >> > > >
> >> > > > Please address this issue along with other things which I have
> 

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Denis Magda]

Hi Maxim,

I would suggest we time a release of the Ignite core and the extensions in
the future. As of now, I can't switch to Ignite 2.10 only due to the Spring
Data module. Not the end of the world but delays the upgrade to the new
version.

-
Denis


On Mon, Apr 5, 2021 at 6:32 AM Maxim Muzafarov  wrote:

> Denis,
>
> There is no spring data artifact for the 2.10 release. We should
> prepare the release of these extensions as fast as possible.
>
> On Fri, 2 Apr 2021 at 20:06, Denis Magda  wrote:
> >
> > Is this the first time we're releasing spring data 2.2 as an ext? Can't
> > find any version available for 2.10? What should I use if I need Spring
> > Data integration now for Ignite 2.10?
> >
> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data_2.2
> >
> > -
> > Denis
> >
> >
> > On Fri, Mar 26, 2021 at 12:55 AM Nikita Amelchev 
> > wrote:
> >
> > > Hi, Denis.
> > >
> > > > - How is the performance stats ext is different from the profiling
> tool
> > > >   released in 2.10?
> > >
> > > The performance statistics extension is a script to build an HTML
> > > report. The core module collects statistics to binary files and this
> > > feature was released in 2.10.
> > >
> > > чт, 25 мар. 2021 г. в 21:05, Denis Magda :
> > > >
> > > > +1
> > > >
> > > > I missed our progress on the extensions frontier. Great to see more
> > > > capabilities added to the Spring framework support.
> > > >
> > > > Several questions (but, I fully support the release of the
> extensions):
> > > >
> > > >- How is the performance stats ext is different from the profiling
> > > tool
> > > >released in 2.10?
> > > >- I've created this tutorial[1] a while ago for the Spring Data
> > > >integration. Would you advise updating it considering any new
> features
> > > >(such as thin-client support)?
> > > >- Don't you want guys to submit a talk to the Ignite Summit[2]?
> It can
> > > >be a "hitchhiker guide to the Spring support in Ignite" or "Using
> > > Profiling
> > > >to Solve Performance issues in Ignite". Happy to help with an
> > > abstract.
> > > >
> > > >
> > > > [1]
> > > https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial
> > > > [2] https://ignite-summit.org
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev <
> namelc...@apache.org>
> > > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > Since Ignite 2.10 has been released, I think we can now release new
> > > > > extension modules:
> > > > >
> > > > > performance-statistics-ext
> > > > > spring-data-ext
> > > > > spring-tx-ext
> > > > >
> > > > > I want to be a release manager for these if nobody minds.
> > > > >
> > > > > The release process can be started after resolving a few
> documentation
> > > > > issues:
> > > > >
> > > > > https://issues.apache.org/jira/browse/IGNITE-14417
> > > > > https://issues.apache.org/jira/browse/IGNITE-14398
> > > > > https://issues.apache.org/jira/browse/IGNITE-14397
> > > > > https://issues.apache.org/jira/browse/IGNITE-13769
> > > > >
> > > > > --
> > > > > Best wishes,
> > > > > Amelchev Nikita
> > > > >
> > >
> > >
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> > >
>

[jira] [Created] (IGNITE-14478) Custom fork/Custom tests Documentation at README.MD

[Anton Vinogradov (Jira)]

Anton Vinogradov created IGNITE-14478:
-

 Summary: Custom fork/Custom tests Documentation at README.MD
 Key: IGNITE-14478
 URL: https://issues.apache.org/jira/browse/IGNITE-14478
 Project: Ignite
  Issue Type: Improvement
Reporter: Anton Vinogradov
Assignee: Nikolay Izhikov


We have to append a proper explanation of "Custom Ignites (forks) testing" to 
sections "Local run" and "# Real environment run".

Currently "Custom Ignites (forks) testing" is a separate section which is not 
true anymore, let spread it to *run sections.

P.s. Currently, we have a 4 options
- Run AI tests versus AI
- Run AI tests versus Fork
- Run External (Fork's) tests versus AI
- Run External (Fork's) tests versus Fork (this case requires no additional 
explanation since it obviously equals to first one).



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

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

[Andrey Mashenkov]

Hi Ivan,

JDK flow API looks interesting. I think we should use it abroad.
Though, Java 14 is not LTS (long-term support) release. I guess many users
will prefer Java 15,
but actually, we have no agreement about switching to Java 15 which may
require some additional efforts.
For now, we could import the required classes into Ignite module as we've
done with JSR-166 (concurrent collections).

I think we should use Flow-like API for Queries, Cursors, Compute results
and even Transactions.
E.g. reactive transaction API is must have and it can be looked like:
Transaction.compose(tx -> table1.getAsync(a)).thenApply(tx ->
table2.putAsync()).thenApply(tx -> tx.commit());

Agree, CompletableFuture looks totally unusable for cases that supposed
cancellation capabilities, due to broken cancellation semantic [1].
However, cancellation support for simple table operations doesn't make any
sense and we still can use CompletableFuture for e.g. table operations
unless we found it unusable for Transaction API that is not designed yet.

I've looked at reactive API as CompletableFuture replacement for simple
cases.
At first glance, it is very complex and may require too much effort on our
user side, and/or hard to understand for the user.

Maybe it make sense to create an IEP for future replacement with all the
examples for the table, transaction, compute APIs?
WDYT?

[1]
https://stackoverflow.com/questions/43389894/recursively-cancel-an-allof-completablefuture

On Sat, Apr 3, 2021 at 1:40 AM Ivan Pavlukhin  wrote:

> Andrey,
>
> As you might know Java has it is own Reactive abstractions since 9
> [1]. Moreover, an original Reactive Streams library has a bridge with
> Java [2].
>
> Personally I do not love CompletableFuture because it's API seems
> questionable to me in various aspects, e.g. mentioned cancellation.
> Currently I think that the cleanest way is custom abstractions
> (possibly implementing CompletionStage) at first. And providing
> bridges to other APIs (including CompletableFuture) as a next step.
> Various API integrations can come in form of extensions.
>
> > JDK classes are well-known and reactive frameworks usually have
> converters
> to/from CompletableFuture [1] [2].
>
> Here I have doubts that it is feasible to achieve it fairly. E.g. once
> again cancellation. While reactive API supports cancellation it will
> not be possible to cancel computation for anything built from
> CompletableFuture.
>
> [1]
> https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/concurrent/Flow.Publisher.html
> [2]
> https://www.reactive-streams.org/reactive-streams-1.0.3-javadoc/org/reactivestreams/FlowAdapters.html
>
> 2021-04-02 12:00 GMT+03:00, Andrey Mashenkov :
> > Ivan,
> > thanks for the link. I think, now I've got what you mean.
> >
> > I don't think we want to have any framework as a dependency and rely on
> > their lifecycle, roadmaps goals and
> > bother about compatibility.
> > JDK classes are well-known and reactive frameworks usually have
> converters
> > to/from CompletableFuture [1] [2].
> > So, users are free to choose any reactive framework.
> >
> > I think will need reactive abstractions in near future for Queries API
> and
> > maybe Transaction API design.
> > These projects are good enough where we can get inspiration.
> >
> > [1]
> >
> https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html#fromFuture-java.util.concurrent.CompletableFuture-
> > [2]
> >
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/internal/jdk8/CompletableFromCompletionStage.java
> >
> > On Thu, Apr 1, 2021 at 1:29 PM Ivan Pavlukhin 
> wrote:
> >
> >> Andrey,
> >>
> >> > Reactive abstractions look more suitable for Queries rather than
> >> > cache/table async operations and don't offer the power of chaining
> like
> >> > CompletableStage.
> >>
> >> Could you please elaborate what capabilities do you mean? AFAIK there
> >> are quite powerful APIs for singular reactive abstractions as well.
> >> E.g. [1].
> >>
> >> [1]
> >>
> https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html
> >>
> >> 2021-04-01 12:33 GMT+03:00, Andrey Mashenkov
> >> :
> >> > Val,
> >> > I just complain JDK CompletableFuture itself is not ideal, but already
> >> > implemented, well-known and tested.
> >> > It still a good alternative compared to custom future implementation
> to
> >> me.
> >> >
> >> > Ok, I feel most of us agree with CompletableFuture as a replacement
> for
> >> > custom IgniteFuture.
> >> > Let's try to use it, but keep in mind that we MUST return a defective
> >> copy
> >> > (via copy() or minimalStage()) to user to prevent misusage on the user
> >> > side.
> >> > It would be nice if we'll follow the same requirement in our internal
> >> code,
> >> > e.g. if a component returns a future that further can be used in other
> >> > components, especially in custom plugins.
> >> >
> >> > Ivan, thanks for the example.
> >> > Reactive abstractions look mo

Re: [DISCUSSION] Common approach to print sensitive information

[Ivan Daschinsky]

Ilya, great idea, but I suppose that third option is a little bit paranoid.
But nevertheless, let it be, it's quite simple to implement it.

пн, 5 апр. 2021 г. в 14:04, Ilya Kasnacheev :

> Hello!
>
> I have two ideas here:
>
> - Let's have more than a single level of sensitive information withholding.
> Currently it is on/off, but I think we may need three levels: "print all",
> "print structure but not content", "print none".
> By structure I mean table/column/field names and data types. So we can
> print SQL statements in their EXPLAIN form to log, but do not print any
> query arguments or values, substituting them with '?'. We can also print
> class and field names in various places.
> - If we have a default different from "print all", we should add a
> developer warning about it, such as
> [WARN ] Sensitive information will not be written to log by default.
> Consider *doing things* to enable developer mode.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 5 апр. 2021 г. в 13:45, Taras Ledkov :
>
> > Hi,
> >
> > I work on ticket IGNITE-14441 [1] to hide sensitive information at the
> > log messages produced by SQL.
> > There are negative comments for the patch.
> >
> > I guess we have to produce view to work with sensitive information and
> > make rules to define sensitive information.
> >
> > See on the usage of the GridToStringBuilder#includeSensitive. Class
> > names and  field names now are considered sensitive.
> > My train of thought is this: SQL query and query plan contain table name
> > (similar to class name) and field name.
> > So, the query and plan are completely sensitive.
> >
> > Lets define sensitive info and work with it for Ignite.
> >
> > Someone proposes introduce one more Ignite property for print SQL
> > sensitive info.
> > I think this leads to complication.
> >
> > Introduce levels of the sensitivity make sense but all similar
> > information must be handled with the same rules.
> >
> > Igniters, WDYT?
> >
> > [1]. https://issues.apache.org/jira/browse/IGNITE-14441
> >
> > --
> > Taras Ledkov
> > Mail-To: tled...@gridgain.com
> >
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Common approach to print sensitive information

[Ivan Daschinsky]

Taras, it's strange that table schema and binary object schema are
considered sensitive information. I suppose, that current realization is
what it is because of simplicity of implementation.
I've never heard from any cybersecurity expert, that sql plan or table
schema are personal or sensitive info. If attacker already can read logs
from graylog or kibana, you have already pwned.
It's strange to worry about SQL schema when this event occurs.

пн, 5 апр. 2021 г. в 13:45, Taras Ledkov :

> Hi,
>
> I work on ticket IGNITE-14441 [1] to hide sensitive information at the
> log messages produced by SQL.
> There are negative comments for the patch.
>
> I guess we have to produce view to work with sensitive information and
> make rules to define sensitive information.
>
> See on the usage of the GridToStringBuilder#includeSensitive. Class
> names and  field names now are considered sensitive.
> My train of thought is this: SQL query and query plan contain table name
> (similar to class name) and field name.
> So, the query and plan are completely sensitive.
>
> Lets define sensitive info and work with it for Ignite.
>
> Someone proposes introduce one more Ignite property for print SQL
> sensitive info.
> I think this leads to complication.
>
> Introduce levels of the sensitivity make sense but all similar
> information must be handled with the same rules.
>
> Igniters, WDYT?
>
> [1]. https://issues.apache.org/jira/browse/IGNITE-14441
>
> --
> Taras Ledkov
> Mail-To: tled...@gridgain.com
>
>

-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Common approach to print sensitive information

[Ilya Kasnacheev]

Hello!

I have two ideas here:

- Let's have more than a single level of sensitive information withholding.
Currently it is on/off, but I think we may need three levels: "print all",
"print structure but not content", "print none".
By structure I mean table/column/field names and data types. So we can
print SQL statements in their EXPLAIN form to log, but do not print any
query arguments or values, substituting them with '?'. We can also print
class and field names in various places.
- If we have a default different from "print all", we should add a
developer warning about it, such as
[WARN ] Sensitive information will not be written to log by default.
Consider *doing things* to enable developer mode.

Regards,
-- 
Ilya Kasnacheev


пн, 5 апр. 2021 г. в 13:45, Taras Ledkov :

> Hi,
>
> I work on ticket IGNITE-14441 [1] to hide sensitive information at the
> log messages produced by SQL.
> There are negative comments for the patch.
>
> I guess we have to produce view to work with sensitive information and
> make rules to define sensitive information.
>
> See on the usage of the GridToStringBuilder#includeSensitive. Class
> names and  field names now are considered sensitive.
> My train of thought is this: SQL query and query plan contain table name
> (similar to class name) and field name.
> So, the query and plan are completely sensitive.
>
> Lets define sensitive info and work with it for Ignite.
>
> Someone proposes introduce one more Ignite property for print SQL
> sensitive info.
> I think this leads to complication.
>
> Introduce levels of the sensitivity make sense but all similar
> information must be handled with the same rules.
>
> Igniters, WDYT?
>
> [1]. https://issues.apache.org/jira/browse/IGNITE-14441
>
> --
> Taras Ledkov
> Mail-To: tled...@gridgain.com
>
>

[jira] [Created] (IGNITE-14477) Ducktape test of rebalance for persistent mode

[Dmitriy Sorokin (Jira)]

Dmitriy Sorokin created IGNITE-14477:


 Summary: Ducktape test of rebalance for persistent mode
 Key: IGNITE-14477
 URL: https://issues.apache.org/jira/browse/IGNITE-14477
 Project: Ignite
  Issue Type: Sub-task
Reporter: Dmitriy Sorokin
Assignee: Dmitriy Sorokin






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

[DISCUSSION] Common approach to print sensitive information

[Taras Ledkov]

Hi,

I work on ticket IGNITE-14441 [1] to hide sensitive information at the 
log messages produced by SQL.

There are negative comments for the patch.

I guess we have to produce view to work with sensitive information and 
make rules to define sensitive information.


See on the usage of the GridToStringBuilder#includeSensitive. Class 
names and  field names now are considered sensitive.
My train of thought is this: SQL query and query plan contain table name 
(similar to class name) and field name.

So, the query and plan are completely sensitive.

Lets define sensitive info and work with it for Ignite.

Someone proposes introduce one more Ignite property for print SQL 
sensitive info.

I think this leads to complication.

Introduce levels of the sensitivity make sense but all similar 
information must be handled with the same rules.


Igniters, WDYT?

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

--
Taras Ledkov
Mail-To: tled...@gridgain.com

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Maxim Muzafarov]

Denis,

There is no spring data artifact for the 2.10 release. We should
prepare the release of these extensions as fast as possible.

On Fri, 2 Apr 2021 at 20:06, Denis Magda  wrote:
>
> Is this the first time we're releasing spring data 2.2 as an ext? Can't
> find any version available for 2.10? What should I use if I need Spring
> Data integration now for Ignite 2.10?
> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data_2.2
>
> -
> Denis
>
>
> On Fri, Mar 26, 2021 at 12:55 AM Nikita Amelchev 
> wrote:
>
> > Hi, Denis.
> >
> > > - How is the performance stats ext is different from the profiling tool
> > >   released in 2.10?
> >
> > The performance statistics extension is a script to build an HTML
> > report. The core module collects statistics to binary files and this
> > feature was released in 2.10.
> >
> > чт, 25 мар. 2021 г. в 21:05, Denis Magda :
> > >
> > > +1
> > >
> > > I missed our progress on the extensions frontier. Great to see more
> > > capabilities added to the Spring framework support.
> > >
> > > Several questions (but, I fully support the release of the extensions):
> > >
> > >- How is the performance stats ext is different from the profiling
> > tool
> > >released in 2.10?
> > >- I've created this tutorial[1] a while ago for the Spring Data
> > >integration. Would you advise updating it considering any new features
> > >(such as thin-client support)?
> > >- Don't you want guys to submit a talk to the Ignite Summit[2]? It can
> > >be a "hitchhiker guide to the Spring support in Ignite" or "Using
> > Profiling
> > >to Solve Performance issues in Ignite". Happy to help with an
> > abstract.
> > >
> > >
> > > [1]
> > https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial
> > > [2] https://ignite-summit.org
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev 
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > Since Ignite 2.10 has been released, I think we can now release new
> > > > extension modules:
> > > >
> > > > performance-statistics-ext
> > > > spring-data-ext
> > > > spring-tx-ext
> > > >
> > > > I want to be a release manager for these if nobody minds.
> > > >
> > > > The release process can be started after resolving a few documentation
> > > > issues:
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-14417
> > > > https://issues.apache.org/jira/browse/IGNITE-14398
> > > > https://issues.apache.org/jira/browse/IGNITE-14397
> > > > https://issues.apache.org/jira/browse/IGNITE-13769
> > > >
> > > > --
> > > > Best wishes,
> > > > Amelchev Nikita
> > > >
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >

[jira] [Created] (IGNITE-14476) Get rid of using storage implementation explicitly in ConfigurationRoot annotation

[Vladislav Pyatkov (Jira)]

Vladislav Pyatkov created IGNITE-14476:
--

 Summary: Get rid of using storage implementation explicitly in 
ConfigurationRoot annotation
 Key: IGNITE-14476
 URL: https://issues.apache.org/jira/browse/IGNITE-14476
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladislav Pyatkov
 Fix For: 3.0.0-alpha2


Today we are using generated schema classes in public API, but we don't want to 
provide an implementation in it. 
For example:
{code:java}
@ConfigurationRoot(rootName = "rest", storage = 
InMemoryConfigurationStorage.class)
public class RestConfigurationSchema {
...
{code}
The mention of InMemoryConfigurationStorage should be changed to a specific 
constant:
{code:java}
@ConfigurationRoot(rootName = "rest", storage = 
IgniteConsts.MEMORY_CONFIGURATION_STORAGE)
public class RestConfigurationSchema {
...
{code}



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

[jira] [Created] (IGNITE-14475) C++/dotnet query-example select result is various with additional node

[Igor Sapego (Jira)]

Igor Sapego created IGNITE-14475:


 Summary: C++/dotnet query-example select result is various with 
additional node
 Key: IGNITE-14475
 URL: https://issues.apache.org/jira/browse/IGNITE-14475
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.10
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.11


Steps:

Start some additional nodes

Execute query-example

Expected output: 

{noformat}
Names of all employees and organizations they belong to: 
Jane Doe is working in ApacheIgnite
John Doe is working in ApacheIgnite
Jane Smith is working in Other
John Smith is working in Other
{noformat}

Actual (in 80% cases):

{noformat}
Names of all employees and organizations they belong to: 
Jane Doe is working in ApacheIgnite
John Doe is working in ApacheIgnite
John Smith is working in Other
{noformat}



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

[jira] [Created] (IGNITE-14474) Improve error message in case rebalance fails

[Denis Chudov (Jira)]

Denis Chudov created IGNITE-14474:
-

 Summary: Improve error message in case rebalance fails
 Key: IGNITE-14474
 URL: https://issues.apache.org/jira/browse/IGNITE-14474
 Project: Ignite
  Issue Type: Improvement
Reporter: Denis Chudov


Currently we can get a message like this when rebalance fails with an exception 
(examples from ignite 2.5, in newer versions the log messages were changed but 
the problem is still actual):
{code:java}
2019-11-27 13:41:14,504[WARN ][utility-#79%xxx%][GridDhtPartitionDemander] 
Rebalancing from node cancelled [grp=ignite-sys-cache, 
topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1], 
supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topic=0]. Supply message 
couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to 
unmarshal object with optimized marshaller
2019-11-27 13:41:14,504[INFO ][utility-#79%xxx%][GridDhtPartitionDemander] 
Cancelled rebalancing [grp=ignite-sys-cache, 
supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topVer=AffinityTopologyVersion 
[topVer=1932, minorTopVer=1], time=88 ms]
2019-11-27 13:41:14,508[WARN ][utility-#76%xxx%][GridDhtPartitionDemander] 
Rebalancing from node cancelled [grp=ignite-sys-cache, 
topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1], 
supplier=dfa5ee06-48c9-4458-ae55-48cc6ceda998, topic=0]. Supply message 
couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to 
unmarshal object with optimized marshaller
{code}
In the case above, a marshalling exception leads to rebalance failure which 
will never be resolved - i.e. the cluster enters into a erroneous state.

We should report issues like this as ERROR. The message should explain that the 
rebalance has failed, data for the cache was not fully copied to the node, the 
backup factor is not recovered and the cluster may not work correctly.



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

Re: [DISCUSSION] Java thin client: Continuous Queries public API

[Atri Sharma]

I do agree with your proposition, but the idea of an interface being
exposed through documentation seems a bit clunky to me.

On Mon, Apr 5, 2021 at 12:40 PM Alex Plehanov  wrote:
>
> Hi Atri,
>
> The new interface is only needed for thin client, it's not a good idea to
> add such a method to thick client too.
>
> пн, 5 апр. 2021 г. в 09:48, Atri Sharma :
>
> > Hi Alex,
> >
> > Sorry for the late reply.
> >
> > Regarding the thick client, would it be a challenge to add a new method
> > which takes takes interface as parameter? That will not break the back
> > compatible
> >
> > On Fri, 2 Apr 2021, 14:32 Alex Plehanov,  wrote:
> >
> > > Hello, Atri
> > >
> > > 1. ClientChannelDisconnectListener is thin client specific.
> > > 2. Thick client API uses JCache interfaces, which cannot be modified.
> > > 2. We can't modify thick client public API either, due to backward
> > > compatibility.
> > >
> > > пт, 2 апр. 2021 г. в 11:51, Atri Sharma :
> > >
> > > > Personally, I would disagree with an interface implementation being
> > > > dictated by the documentation rather than the method signature.
> > > >
> > > > How about having a generic interface (placeholder interface), have
> > > > both the thick and thin clients expose methods using the interface as
> > > > parameters, then let ClientChannelDisconnectListener actually
> > > > implement that interface and override the base methods? The methods
> > > > can be no-op in the thick clients.
> > > >
> > > > On Fri, Apr 2, 2021 at 2:04 PM Alex Plehanov 
> > > > wrote:
> > > > >
> > > > > Hello, Igniters!
> > > > >
> > > > > I'd like to discuss java thin client Continuous Queries public API.
> > > > >
> > > > > Currently, the thin client is not JCache compatible and without
> > JCache
> > > > > compatible cache instance we can't use classes and API which already
> > > used
> > > > > by the thick client for cache entry events listening.
> > > > > In my first attempt to implement thin client CQ I've tried to create
> > > own
> > > > CQ
> > > > > classes and interfaces for thin client, but such API looks weird. On
> > > the
> > > > > one hand, we should use CacheEntryEventFilter (JCache interface)
> > since
> > > > it's
> > > > > required by the server-side, on the other hand, we can't use
> > > > > CacheEntryUpdatedListener since it requires CacheEntryEvent which
> > > > requires
> > > > > an instance of Cache (JCache interface), which doesn't exist on the
> > > > > thin-client side.
> > > > > We've already discussed this problem with Pavel Tupitsyn in ticket
> > [1]
> > > > and
> > > > > come to an agreement that the most suitable solution is to implement
> > > some
> > > > > private thin-client cache to JCache adapter, but not expose it to
> > > public
> > > > > API and don't provide full JCache support by the thin client (see
> > > > comments
> > > > > in the ticket for more details). In this case, we can reuse CQ
> > classes
> > > > and
> > > > > interfaces and make the API similar to thick-client.
> > > > >
> > > > > Another problem: for the thin client we should be able to inform the
> > > user
> > > > > about channel failure. I propose to introduce some interface
> > > > > ClientChannelDisconnectListener and notify about channel failure if
> > > > > provided CacheEntryListener implements this interface. Unfortunately,
> > > if
> > > > we
> > > > > want to keep thin client API similar to the thick client we can't
> > > > > explicitly use this interface in methods parameters, so the knowledge
> > > > that
> > > > > user can use this interface for cache entry listener can be obtained
> > > only
> > > > > from JavaDoc or Ignite documentation.
> > > > >
> > > > > Igniters, WDYT?
> > > > >
> > > > > Here is PR with implemented proposals [2].
> > > > >
> > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-14402
> > > > > [2]: https://github.com/apache/ignite/pull/8960
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Atri
> > > > Apache Concerted
> > > >
> > >
> >

-- 
Regards,

Atri
Apache Concerted

Re: [DISCUSSION] Java thin client: Continuous Queries public API

[Alex Plehanov]

Hi Atri,

The new interface is only needed for thin client, it's not a good idea to
add such a method to thick client too.

пн, 5 апр. 2021 г. в 09:48, Atri Sharma :

> Hi Alex,
>
> Sorry for the late reply.
>
> Regarding the thick client, would it be a challenge to add a new method
> which takes takes interface as parameter? That will not break the back
> compatible
>
> On Fri, 2 Apr 2021, 14:32 Alex Plehanov,  wrote:
>
> > Hello, Atri
> >
> > 1. ClientChannelDisconnectListener is thin client specific.
> > 2. Thick client API uses JCache interfaces, which cannot be modified.
> > 2. We can't modify thick client public API either, due to backward
> > compatibility.
> >
> > пт, 2 апр. 2021 г. в 11:51, Atri Sharma :
> >
> > > Personally, I would disagree with an interface implementation being
> > > dictated by the documentation rather than the method signature.
> > >
> > > How about having a generic interface (placeholder interface), have
> > > both the thick and thin clients expose methods using the interface as
> > > parameters, then let ClientChannelDisconnectListener actually
> > > implement that interface and override the base methods? The methods
> > > can be no-op in the thick clients.
> > >
> > > On Fri, Apr 2, 2021 at 2:04 PM Alex Plehanov 
> > > wrote:
> > > >
> > > > Hello, Igniters!
> > > >
> > > > I'd like to discuss java thin client Continuous Queries public API.
> > > >
> > > > Currently, the thin client is not JCache compatible and without
> JCache
> > > > compatible cache instance we can't use classes and API which already
> > used
> > > > by the thick client for cache entry events listening.
> > > > In my first attempt to implement thin client CQ I've tried to create
> > own
> > > CQ
> > > > classes and interfaces for thin client, but such API looks weird. On
> > the
> > > > one hand, we should use CacheEntryEventFilter (JCache interface)
> since
> > > it's
> > > > required by the server-side, on the other hand, we can't use
> > > > CacheEntryUpdatedListener since it requires CacheEntryEvent which
> > > requires
> > > > an instance of Cache (JCache interface), which doesn't exist on the
> > > > thin-client side.
> > > > We've already discussed this problem with Pavel Tupitsyn in ticket
> [1]
> > > and
> > > > come to an agreement that the most suitable solution is to implement
> > some
> > > > private thin-client cache to JCache adapter, but not expose it to
> > public
> > > > API and don't provide full JCache support by the thin client (see
> > > comments
> > > > in the ticket for more details). In this case, we can reuse CQ
> classes
> > > and
> > > > interfaces and make the API similar to thick-client.
> > > >
> > > > Another problem: for the thin client we should be able to inform the
> > user
> > > > about channel failure. I propose to introduce some interface
> > > > ClientChannelDisconnectListener and notify about channel failure if
> > > > provided CacheEntryListener implements this interface. Unfortunately,
> > if
> > > we
> > > > want to keep thin client API similar to the thick client we can't
> > > > explicitly use this interface in methods parameters, so the knowledge
> > > that
> > > > user can use this interface for cache entry listener can be obtained
> > only
> > > > from JavaDoc or Ignite documentation.
> > > >
> > > > Igniters, WDYT?
> > > >
> > > > Here is PR with implemented proposals [2].
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/IGNITE-14402
> > > > [2]: https://github.com/apache/ignite/pull/8960
> > >
> > > --
> > > Regards,
> > >
> > > Atri
> > > Apache Concerted
> > >
> >
>