Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1

[Nikolay Izhikov]

Hello, Igniters.

Do we have a person who can fix this issue in the nearest time?
Right now IGNITE-12746 is Open and Unassigned.

> 3 марта 2020 г., в 23:54, Denis Magda  написал(а):
> 
> Ilya,
> 
> Thanks for catching that and sharing. I wonder if there are any other
> blockers that were pushed to 2.8.x version. If there are a few then we can
> produce 2.8.1 shortly, otherwise, it sounds reasonable to me to fix the
> issue with putAll, update the binaries and finish the process.
> 
> -
> Denis
> 
> 
> On Tue, Mar 3, 2020 at 2:34 PM Ilya Kasnacheev 
> wrote:
> 
>> Hello!
>> 
>> I have filed an issue https://issues.apache.org/jira/browse/IGNITE-12746
>> 
>> I think this is potentially a game breaker and makes me recommend avoiding
>> 2.8, if we release it without fix (for now).
>> 
>> If you are using any partitioned caches, anyway.
>> 
>> So I suggest we withhold 2.8.
>> 
>> Regards,
>> --
>> Ilya Kasnacheev
>> 
>> 
>> вт, 3 мар. 2020 г. в 20:53, Maxim Muzafarov :
>> 
>>> Ilya,
>>> 
>>> I do not want to force the release no matter what happens, but I think
>>> we should release what we have to get feedback not just from the
>>> developer community but from our users too.
>>> 
>>> And fix all these issues in 2.8.1.
>>> 
>>> On Tue, 3 Mar 2020 at 20:33, Ilya Kasnacheev 
>>> wrote:
 
 Hello!
 
 Can we please hold back publishing AI-2.8.0-rc1 as public Apache Ignite
>>> 2.8
 release?
 
 I have just been notified that
 
>>> 
>> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedColocated
 
>>> 
>> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedMixed
 are flaky: they seem to deadlock on putAll sorted keys maps. They used
>> to
 pass solidly on 2.7, but fail on master and ignite-2.8.
 
 (They fail around 1 time out of 10, so just run them 25 times to check)
 
 If there is indeed a deadlock, this would become a blocker to this
>>> release,
 in my opinion, but I need some time to check.
 
 Regards,
 --
 Ilya Kasnacheev
 
 
 вс, 1 мар. 2020 г. в 11:29, Maxim Muzafarov :
 
> Ivan,
> 
> 
> I agree with you that the more members will check the release the
> better will be. That's why I've shared the release candidate links
>> [1]
> before starting a vote. The best time for starting a vote is not
> mentioned at our release wiki page [2] (should we?) and I've also
> failed with googling the best practices for it too. So, I've supposed
> since all of us are working on their own tasks during weekdays the
> free time on the weekend is the best choice for cheking\voting on the
> release. Probably this decision was wrong.
> 
> [1]
> 
>>> 
>> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p46117.html
> [2]
>> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> 
> On Sun, 1 Mar 2020 at 00:37, Ivan Pavlukhin 
>>> wrote:
>> 
>> Also I have a comment regarding to voting. Voting for 72 hour
>>> spanning
>> a weekend sounds a little bit odd to me. In a particular case the
>>> more
>> people check the release the better. And I suppose there is more
>> time
>> for it on weekdays for the majority.
>> 
>> Best regards,
>> Ivan Pavlukhin
>> 
>> вс, 1 мар. 2020 г. в 00:33, Ivan Pavlukhin :
>>> 
 As I remember, that Pavlov suggested to discuss threats on a
>>> private
> PMC list
>>> Cannot understand why it should be discussed on a private list.
>>> What
>>> is the clue?
>>> 
>>> Best regards,
>>> Ivan Pavlukhin
>>> 
>>> сб, 29 февр. 2020 г. в 16:00, Alexey Zinoviev <
>>> zaleslaw@gmail.com
>> :
 
 As I remember, that Pavlov suggested to discuss threats on a
>>> private
> PMC
 list
 
 сб, 29 февр. 2020 г., 15:12 Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>:
 
> Hello!
> 
> As far as my understanding goes, ignite-zookeeper is listed
>> for
> removal
> because it brings a lot of dependencies, some of which may
>> have
> known
> vulnerabilities, which will make the distribution also
>>> considered
> vulnerable by some scanners.
> 
> Regards,
> --
> Ilya Kasnacheev
> 
> 
> сб, 29 февр. 2020 г. в 14:18, Alexey Zinoviev <
> zaleslaw@gmail.com>:
> 
>> Ok, lets move to this thread. Also, the slim release could
>> be
> form by
>> voting on user-list
>> 
>> сб, 29 февр. 2020 г., 9:55 Alexey Goncharuk <
> alexey.goncha...@gmail.com
>> :
>> 
>>> Nikolay, Alexey,
>>> 
>>> First, the idea of the slim binary release and docker
>>> image was

Re: [RESULT] [VOTE] Release Apache Ignite 2.8.0 RC1

[Alexey Zinoviev]

Maxim, you great, I was happy to work with you on that release, it was a
very difficult task and it required a lot of your time, thank you

ср, 4 мар. 2020 г., 8:46 Anton Vinogradov :

> Awesome!
> Thanks for leading this.
>
> BTW, do we have plans to start 2.9 release process in nearest future?
>
> On Tue, Mar 3, 2020 at 11:07 PM Maxim Muzafarov  wrote:
>
> > Folks,
> >
> >
> > I've done (with Santa's help) most of the steps related to the 2.8.0
> > RELEASE.
> > Here are some links according to accepted the release candidate.
> >
> >
> > Binary, Sources:
> > https://dist.apache.org/repos/dist/release/ignite/2.8.0/
> >
> > Bintray:
> > https://bintray.com/apache/ignite-rpm/apache-ignite/2.8.0
> > https://bintray.com/apache/ignite-deb/apache-ignite/2.8.0
> >
> > Javadocs:
> > https://svn.apache.org/repos/asf/ignite/site/trunk/releases/2.8.0/
> >
> > RELEASE_NOTES:
> >
> >
> https://svn.apache.org/repos/asf/ignite/site/trunk/releases/2.8.0/release_notes.html
> >
> > git tag:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6
> >
> > Download links:
> > https://ignite.apache.org/download.cgi
> >
> > On Mon, 2 Mar 2020 at 22:10, Maxim Muzafarov  wrote:
> > >
> > > Dear community,
> > >
> > >
> > > The vote for a new release candidate is closed, now.
> > > Vote result: The vote PASSES with 6 votes +1 (6 bindings), 0 two votes
> > > and no -1.
> > >
> > >
> > > +1 votes:
> > > - Denis Magda (binding)
> > > - Anton Vinogradov (binding)
> > > - Pavel Tupitsyn (binding)
> > > - Ivan Pavlukhin (binding)
> > > - Alexey Zinoviev (binding)
> > > - Nikolay Izhikov (binding)
> > >
> > > 0 votes:
> > > - Ilya Kasnacheev (binding)
> > > - Sergey Antonov
> > >
> > >
> > > Vote thread:
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html
> >
>

Re: [RESULT] [VOTE] Release Apache Ignite 2.8.0 RC1

[Anton Vinogradov]

Awesome!
Thanks for leading this.

BTW, do we have plans to start 2.9 release process in nearest future?

On Tue, Mar 3, 2020 at 11:07 PM Maxim Muzafarov  wrote:

> Folks,
>
>
> I've done (with Santa's help) most of the steps related to the 2.8.0
> RELEASE.
> Here are some links according to accepted the release candidate.
>
>
> Binary, Sources:
> https://dist.apache.org/repos/dist/release/ignite/2.8.0/
>
> Bintray:
> https://bintray.com/apache/ignite-rpm/apache-ignite/2.8.0
> https://bintray.com/apache/ignite-deb/apache-ignite/2.8.0
>
> Javadocs:
> https://svn.apache.org/repos/asf/ignite/site/trunk/releases/2.8.0/
>
> RELEASE_NOTES:
>
> https://svn.apache.org/repos/asf/ignite/site/trunk/releases/2.8.0/release_notes.html
>
> git tag:
>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6
>
> Download links:
> https://ignite.apache.org/download.cgi
>
> On Mon, 2 Mar 2020 at 22:10, Maxim Muzafarov  wrote:
> >
> > Dear community,
> >
> >
> > The vote for a new release candidate is closed, now.
> > Vote result: The vote PASSES with 6 votes +1 (6 bindings), 0 two votes
> > and no -1.
> >
> >
> > +1 votes:
> > - Denis Magda (binding)
> > - Anton Vinogradov (binding)
> > - Pavel Tupitsyn (binding)
> > - Ivan Pavlukhin (binding)
> > - Alexey Zinoviev (binding)
> > - Nikolay Izhikov (binding)
> >
> > 0 votes:
> > - Ilya Kasnacheev (binding)
> > - Sergey Antonov
> >
> >
> > Vote thread:
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html
>

Re: Ignite Hadoop Accelerator #CGO#

[Denis Magda]

Hello Prachi,

A recommended approach is to deploy Ignite in its standard configuration
and pre-load the required data there. This page shares more details:
https://www.gridgain.com/docs/latest/integrations/datalake-accelerator/getting-started

In case synchronization is needed between Ignite and Hadoop you can explore
various CDC methods or consider implementing CacheStore interface as
mentioned here:
http://apache-ignite-users.70518.x6.nabble.com/How-to-access-IGFS-file-written-one-node-from-other-node-in-cluster-td31495.html#a31508

-
Denis


On Tue, Mar 3, 2020 at 5:19 AM Shah, Prachi
 wrote:

> Hi Team,
>
> We are trying to use Ignite Hadoop Accelerator for one of our
> implementation.
>
> But I understand Ignite Hadoop Acceleration is to be discontinued very
> soon.
>
> Need to know the alternatives to the Accelerator to use Ignite for Hadoop
> file system.
>
>
>
> Thanks,
> Prachi
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient, you
> are not authorized to read, print, retain, copy, disseminate, distribute,
> or use this message or any part thereof. If you receive this message in
> error, please notify the sender immediately and delete all copies of this
> message.
>

Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1

[Denis Magda]

Ilya,

Thanks for catching that and sharing. I wonder if there are any other
blockers that were pushed to 2.8.x version. If there are a few then we can
produce 2.8.1 shortly, otherwise, it sounds reasonable to me to fix the
issue with putAll, update the binaries and finish the process.

-
Denis


On Tue, Mar 3, 2020 at 2:34 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> I have filed an issue https://issues.apache.org/jira/browse/IGNITE-12746
>
> I think this is potentially a game breaker and makes me recommend avoiding
> 2.8, if we release it without fix (for now).
>
> If you are using any partitioned caches, anyway.
>
> So I suggest we withhold 2.8.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 3 мар. 2020 г. в 20:53, Maxim Muzafarov :
>
> > Ilya,
> >
> > I do not want to force the release no matter what happens, but I think
> > we should release what we have to get feedback not just from the
> > developer community but from our users too.
> >
> > And fix all these issues in 2.8.1.
> >
> > On Tue, 3 Mar 2020 at 20:33, Ilya Kasnacheev 
> > wrote:
> > >
> > > Hello!
> > >
> > > Can we please hold back publishing AI-2.8.0-rc1 as public Apache Ignite
> > 2.8
> > > release?
> > >
> > > I have just been notified that
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedColocated
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedMixed
> > > are flaky: they seem to deadlock on putAll sorted keys maps. They used
> to
> > > pass solidly on 2.7, but fail on master and ignite-2.8.
> > >
> > > (They fail around 1 time out of 10, so just run them 25 times to check)
> > >
> > > If there is indeed a deadlock, this would become a blocker to this
> > release,
> > > in my opinion, but I need some time to check.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > вс, 1 мар. 2020 г. в 11:29, Maxim Muzafarov :
> > >
> > > > Ivan,
> > > >
> > > >
> > > > I agree with you that the more members will check the release the
> > > > better will be. That's why I've shared the release candidate links
> [1]
> > > > before starting a vote. The best time for starting a vote is not
> > > > mentioned at our release wiki page [2] (should we?) and I've also
> > > > failed with googling the best practices for it too. So, I've supposed
> > > > since all of us are working on their own tasks during weekdays the
> > > > free time on the weekend is the best choice for cheking\voting on the
> > > > release. Probably this decision was wrong.
> > > >
> > > > [1]
> > > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p46117.html
> > > > [2]
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > > >
> > > > On Sun, 1 Mar 2020 at 00:37, Ivan Pavlukhin 
> > wrote:
> > > > >
> > > > > Also I have a comment regarding to voting. Voting for 72 hour
> > spanning
> > > > > a weekend sounds a little bit odd to me. In a particular case the
> > more
> > > > > people check the release the better. And I suppose there is more
> time
> > > > > for it on weekdays for the majority.
> > > > >
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > > > > вс, 1 мар. 2020 г. в 00:33, Ivan Pavlukhin :
> > > > > >
> > > > > > > As I remember, that Pavlov suggested to discuss threats on a
> > private
> > > > PMC list
> > > > > > Cannot understand why it should be discussed on a private list.
> > What
> > > > > > is the clue?
> > > > > >
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > > >
> > > > > > сб, 29 февр. 2020 г. в 16:00, Alexey Zinoviev <
> > zaleslaw@gmail.com
> > > > >:
> > > > > > >
> > > > > > > As I remember, that Pavlov suggested to discuss threats on a
> > private
> > > > PMC
> > > > > > > list
> > > > > > >
> > > > > > > сб, 29 февр. 2020 г., 15:12 Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com>:
> > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > As far as my understanding goes, ignite-zookeeper is listed
> for
> > > > removal
> > > > > > > > because it brings a lot of dependencies, some of which may
> have
> > > > known
> > > > > > > > vulnerabilities, which will make the distribution also
> > considered
> > > > > > > > vulnerable by some scanners.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > --
> > > > > > > > Ilya Kasnacheev
> > > > > > > >
> > > > > > > >
> > > > > > > > сб, 29 февр. 2020 г. в 14:18, Alexey Zinoviev <
> > > > zaleslaw@gmail.com>:
> > > > > > > >
> > > > > > > > > Ok, lets move to this thread. Also, the slim release could
> be
> > > > form by
> > > > > > > > > voting on user-list
> > > > > > > > >
> > > > > > > > > сб, 29 февр. 2020 г., 9:55 Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com
> > > > > > > > >:
> > > > > > > > >
> > > > > > > > > > Nikolay, Alexey,
> > > > > > > > > >
> > > > > > > > > > First, the idea of the slim binary release 

Re: Update Apache Ignite docker documentation

[Denis Magda]

Could we also update the "Overview" page with the content from the README
file of GitHub?
https://github.com/apache/ignite/blob/master/README.md

-
Denis


On Tue, Mar 3, 2020 at 1:26 PM Maxim Muzafarov  wrote:

> Igniters,
>
>
> I've just found that a script with docked Apache Ignite on docker hub
> site [1] doesn't work for newer versions (start from 2.6.0?) since the
> word `fabric` has been removed from a release distribution name.
>
> Can we update this documentation to the newer one?
> I can also suggest using this URL [2] for resource download since at
> dist.apache.org will be available only the latest version.
>
>
> RUN curl
> https://dist.apache.org/repos/dist/release/ignite/${IGNITE_VERSION}/apache-ignite-fabric-${IGNITE_VERSION}-bin.zip
> -o ignite.zip \ && unzip ignite.zip \ && rm ignite.zip
>
>
> [1] https://hub.docker.com/r/apacheignite/ignite/dockerfile
> [2] https://archive.apache.org/dist/ignite/
>

Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1

[Ilya Kasnacheev]

Hello!

I have filed an issue https://issues.apache.org/jira/browse/IGNITE-12746

I think this is potentially a game breaker and makes me recommend avoiding
2.8, if we release it without fix (for now).

If you are using any partitioned caches, anyway.

So I suggest we withhold 2.8.

Regards,
-- 
Ilya Kasnacheev


вт, 3 мар. 2020 г. в 20:53, Maxim Muzafarov :

> Ilya,
>
> I do not want to force the release no matter what happens, but I think
> we should release what we have to get feedback not just from the
> developer community but from our users too.
>
> And fix all these issues in 2.8.1.
>
> On Tue, 3 Mar 2020 at 20:33, Ilya Kasnacheev 
> wrote:
> >
> > Hello!
> >
> > Can we please hold back publishing AI-2.8.0-rc1 as public Apache Ignite
> 2.8
> > release?
> >
> > I have just been notified that
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedColocated
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedMixed
> > are flaky: they seem to deadlock on putAll sorted keys maps. They used to
> > pass solidly on 2.7, but fail on master and ignite-2.8.
> >
> > (They fail around 1 time out of 10, so just run them 25 times to check)
> >
> > If there is indeed a deadlock, this would become a blocker to this
> release,
> > in my opinion, but I need some time to check.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вс, 1 мар. 2020 г. в 11:29, Maxim Muzafarov :
> >
> > > Ivan,
> > >
> > >
> > > I agree with you that the more members will check the release the
> > > better will be. That's why I've shared the release candidate links [1]
> > > before starting a vote. The best time for starting a vote is not
> > > mentioned at our release wiki page [2] (should we?) and I've also
> > > failed with googling the best practices for it too. So, I've supposed
> > > since all of us are working on their own tasks during weekdays the
> > > free time on the weekend is the best choice for cheking\voting on the
> > > release. Probably this decision was wrong.
> > >
> > > [1]
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p46117.html
> > > [2] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > >
> > > On Sun, 1 Mar 2020 at 00:37, Ivan Pavlukhin 
> wrote:
> > > >
> > > > Also I have a comment regarding to voting. Voting for 72 hour
> spanning
> > > > a weekend sounds a little bit odd to me. In a particular case the
> more
> > > > people check the release the better. And I suppose there is more time
> > > > for it on weekdays for the majority.
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > > вс, 1 мар. 2020 г. в 00:33, Ivan Pavlukhin :
> > > > >
> > > > > > As I remember, that Pavlov suggested to discuss threats on a
> private
> > > PMC list
> > > > > Cannot understand why it should be discussed on a private list.
> What
> > > > > is the clue?
> > > > >
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > > > > сб, 29 февр. 2020 г. в 16:00, Alexey Zinoviev <
> zaleslaw@gmail.com
> > > >:
> > > > > >
> > > > > > As I remember, that Pavlov suggested to discuss threats on a
> private
> > > PMC
> > > > > > list
> > > > > >
> > > > > > сб, 29 февр. 2020 г., 15:12 Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com>:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > As far as my understanding goes, ignite-zookeeper is listed for
> > > removal
> > > > > > > because it brings a lot of dependencies, some of which may have
> > > known
> > > > > > > vulnerabilities, which will make the distribution also
> considered
> > > > > > > vulnerable by some scanners.
> > > > > > >
> > > > > > > Regards,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > сб, 29 февр. 2020 г. в 14:18, Alexey Zinoviev <
> > > zaleslaw@gmail.com>:
> > > > > > >
> > > > > > > > Ok, lets move to this thread. Also, the slim release could be
> > > form by
> > > > > > > > voting on user-list
> > > > > > > >
> > > > > > > > сб, 29 февр. 2020 г., 9:55 Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > > > > >:
> > > > > > > >
> > > > > > > > > Nikolay, Alexey,
> > > > > > > > >
> > > > > > > > > First, the idea of the slim binary release and docker
> image was
> > > > > > > discussed
> > > > > > > > > openly on the dev-list [1]. Second, nobody talks about
> > > removing these
> > > > > > > > > modules from the product. The idea was to create an
> additional
> > > > > > > > distribution
> > > > > > > > > which is much lighter than the current full package to
> reduce
> > > the size
> > > > > > > of
> > > > > > > > > the downloadable artifact and reduce the number of
> potential
> > > > > > > > > vulnerabilities in third-party libraries.
> > > > > > > > >
> > > > > > > > > The list of modules was chosen subjectively by the number
> of
> > > questions
> > > > > > > on
> > 

[jira] [Created] (IGNITE-12746) Regression in GridCacheColocatedDebugTest: putAll of sorted keys causes deadlock

[Ilya Kasnacheev (Jira)]

Ilya Kasnacheev created IGNITE-12746:


 Summary: Regression in GridCacheColocatedDebugTest: putAll of 
sorted keys causes deadlock
 Key: IGNITE-12746
 URL: https://issues.apache.org/jira/browse/IGNITE-12746
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Ilya Kasnacheev
 Fix For: 2.8


After this commit:
7d4bb49264b IGNITE-12329 Invalid handling of remote entries causes partition 
desync and transaction hanging in COMMITTING state.

the following tests:
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedColocated
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedMixed
started to be flaky because their ordered putAll operations started deadlocking.

This is a regression compared to 2.7 and should be fixed, since it may affect 
production clusters.



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

Re: [RESULT] [VOTE] Release Apache Ignite 2.8.0 RC1

[Maxim Muzafarov]

Folks,


I've done (with Santa's help) most of the steps related to the 2.8.0 RELEASE.
Here are some links according to accepted the release candidate.


Binary, Sources:
https://dist.apache.org/repos/dist/release/ignite/2.8.0/

Bintray:
https://bintray.com/apache/ignite-rpm/apache-ignite/2.8.0
https://bintray.com/apache/ignite-deb/apache-ignite/2.8.0

Javadocs:
https://svn.apache.org/repos/asf/ignite/site/trunk/releases/2.8.0/

RELEASE_NOTES:
https://svn.apache.org/repos/asf/ignite/site/trunk/releases/2.8.0/release_notes.html

git tag:
https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6

Download links:
https://ignite.apache.org/download.cgi

On Mon, 2 Mar 2020 at 22:10, Maxim Muzafarov  wrote:
>
> Dear community,
>
>
> The vote for a new release candidate is closed, now.
> Vote result: The vote PASSES with 6 votes +1 (6 bindings), 0 two votes
> and no -1.
>
>
> +1 votes:
> - Denis Magda (binding)
> - Anton Vinogradov (binding)
> - Pavel Tupitsyn (binding)
> - Ivan Pavlukhin (binding)
> - Alexey Zinoviev (binding)
> - Nikolay Izhikov (binding)
>
> 0 votes:
> - Ilya Kasnacheev (binding)
> - Sergey Antonov
>
>
> Vote thread:
> http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html

Update Apache Ignite docker documentation

[Maxim Muzafarov]

Igniters,


I've just found that a script with docked Apache Ignite on docker hub
site [1] doesn't work for newer versions (start from 2.6.0?) since the
word `fabric` has been removed from a release distribution name.

Can we update this documentation to the newer one?
I can also suggest using this URL [2] for resource download since at
dist.apache.org will be available only the latest version.


RUN curl 
https://dist.apache.org/repos/dist/release/ignite/${IGNITE_VERSION}/apache-ignite-fabric-${IGNITE_VERSION}-bin.zip
-o ignite.zip \ && unzip ignite.zip \ && rm ignite.zip


[1] https://hub.docker.com/r/apacheignite/ignite/dockerfile
[2] https://archive.apache.org/dist/ignite/

Re: Ignite 2.8 announcement plan

[Alexey Zinoviev]

Sounds ineresting, will help with the post, please share the template, not
sure about webinar

вт, 3 мар. 2020 г., 20:59 Denis Magda :

> Igniters,
>
> Let's discuss approaches for a global announcement/promotion of the
> release. I would suggest focusing on a blog post and a community webinar.
>
> The blog post will introduce significant improvements (service grid, thin
> clients, new metrics system, ML, etc.) sharing references to documentation
> pages with more details.  It will be published on blogs.apache.org in a
> format similar to this one -
> https://blogs.apache.org/ignite/entry/apache-ignite-2-7-deep. I can work
> on
> it unless anybody else is willing to share the news on behalf of the
> community.
>
> Next, the blog post will be featuring a community webinar that is breaking
> down a subset of the improvements in more detail. Please see an abstract
> below with suggested topics for a detailed overview. @Alexey Zinoviev
> , would you be able to present the ML part?
> @Nikolay
> Izhikov  or @Andrey Gura  would
> you like to take over the metrics section? I'll work the attendees through
> the items listed in "Sustainable production under high load". We should
> target the webinar for the April timeframe.
>
>
>
> *Topmost changes in Apache Ignite 2.8 for production maintenance and
> machine learning*
>
>
> *Apache Ignite community rolled out more than 1900 changes in Ignite 2.8
> that enhanced almost all the components of the platform. The release notes
> go with hundreds of lines trying to catalog the improvements. Join this
> webinar led by Ignite community members demonstrating and dissecting new
> capabilities related to production maintenance, monitoring, and machine
> learning that you do not want to lose sight of:*
>
>- *Sustainable production under high load: Ignite persistence compaction
>and consistent crash recovery, baseline topology auto-adjustment, no
>interruption of operations for some cluster topology change events.*
>- *Next-generation system for monitoring and code tracing: design and
>usage, exporters configuration (JMX, SQL, OpenCensus) *
>- *Ignite Machine Learning major upgrade: a revised approach for models
>training/evaluation, models importing from Spark ML, XGBoost and much
> more
>  *
>
>
> -
> Denis
>

Ignite 2.8 announcement plan

[Denis Magda]

Igniters,

Let's discuss approaches for a global announcement/promotion of the
release. I would suggest focusing on a blog post and a community webinar.

The blog post will introduce significant improvements (service grid, thin
clients, new metrics system, ML, etc.) sharing references to documentation
pages with more details.  It will be published on blogs.apache.org in a
format similar to this one -
https://blogs.apache.org/ignite/entry/apache-ignite-2-7-deep. I can work on
it unless anybody else is willing to share the news on behalf of the
community.

Next, the blog post will be featuring a community webinar that is breaking
down a subset of the improvements in more detail. Please see an abstract
below with suggested topics for a detailed overview. @Alexey Zinoviev
, would you be able to present the ML part? @Nikolay
Izhikov  or @Andrey Gura  would
you like to take over the metrics section? I'll work the attendees through
the items listed in "Sustainable production under high load". We should
target the webinar for the April timeframe.



*Topmost changes in Apache Ignite 2.8 for production maintenance and
machine learning*


*Apache Ignite community rolled out more than 1900 changes in Ignite 2.8
that enhanced almost all the components of the platform. The release notes
go with hundreds of lines trying to catalog the improvements. Join this
webinar led by Ignite community members demonstrating and dissecting new
capabilities related to production maintenance, monitoring, and machine
learning that you do not want to lose sight of:*

   - *Sustainable production under high load: Ignite persistence compaction
   and consistent crash recovery, baseline topology auto-adjustment, no
   interruption of operations for some cluster topology change events.*
   - *Next-generation system for monitoring and code tracing: design and
   usage, exporters configuration (JMX, SQL, OpenCensus) *
   - *Ignite Machine Learning major upgrade: a revised approach for models
   training/evaluation, models importing from Spark ML, XGBoost and much more
 *


-
Denis

Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1

[Maxim Muzafarov]

Ilya,

I do not want to force the release no matter what happens, but I think
we should release what we have to get feedback not just from the
developer community but from our users too.

And fix all these issues in 2.8.1.

On Tue, 3 Mar 2020 at 20:33, Ilya Kasnacheev  wrote:
>
> Hello!
>
> Can we please hold back publishing AI-2.8.0-rc1 as public Apache Ignite 2.8
> release?
>
> I have just been notified that
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedColocated
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedMixed
> are flaky: they seem to deadlock on putAll sorted keys maps. They used to
> pass solidly on 2.7, but fail on master and ignite-2.8.
>
> (They fail around 1 time out of 10, so just run them 25 times to check)
>
> If there is indeed a deadlock, this would become a blocker to this release,
> in my opinion, but I need some time to check.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вс, 1 мар. 2020 г. в 11:29, Maxim Muzafarov :
>
> > Ivan,
> >
> >
> > I agree with you that the more members will check the release the
> > better will be. That's why I've shared the release candidate links [1]
> > before starting a vote. The best time for starting a vote is not
> > mentioned at our release wiki page [2] (should we?) and I've also
> > failed with googling the best practices for it too. So, I've supposed
> > since all of us are working on their own tasks during weekdays the
> > free time on the weekend is the best choice for cheking\voting on the
> > release. Probably this decision was wrong.
> >
> > [1]
> > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p46117.html
> > [2] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> >
> > On Sun, 1 Mar 2020 at 00:37, Ivan Pavlukhin  wrote:
> > >
> > > Also I have a comment regarding to voting. Voting for 72 hour spanning
> > > a weekend sounds a little bit odd to me. In a particular case the more
> > > people check the release the better. And I suppose there is more time
> > > for it on weekdays for the majority.
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > > вс, 1 мар. 2020 г. в 00:33, Ivan Pavlukhin :
> > > >
> > > > > As I remember, that Pavlov suggested to discuss threats on a private
> > PMC list
> > > > Cannot understand why it should be discussed on a private list. What
> > > > is the clue?
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > > сб, 29 февр. 2020 г. в 16:00, Alexey Zinoviev  > >:
> > > > >
> > > > > As I remember, that Pavlov suggested to discuss threats on a private
> > PMC
> > > > > list
> > > > >
> > > > > сб, 29 февр. 2020 г., 15:12 Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com>:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > As far as my understanding goes, ignite-zookeeper is listed for
> > removal
> > > > > > because it brings a lot of dependencies, some of which may have
> > known
> > > > > > vulnerabilities, which will make the distribution also considered
> > > > > > vulnerable by some scanners.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > сб, 29 февр. 2020 г. в 14:18, Alexey Zinoviev <
> > zaleslaw@gmail.com>:
> > > > > >
> > > > > > > Ok, lets move to this thread. Also, the slim release could be
> > form by
> > > > > > > voting on user-list
> > > > > > >
> > > > > > > сб, 29 февр. 2020 г., 9:55 Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > > > > >:
> > > > > > >
> > > > > > > > Nikolay, Alexey,
> > > > > > > >
> > > > > > > > First, the idea of the slim binary release and docker image was
> > > > > > discussed
> > > > > > > > openly on the dev-list [1]. Second, nobody talks about
> > removing these
> > > > > > > > modules from the product. The idea was to create an additional
> > > > > > > distribution
> > > > > > > > which is much lighter than the current full package to reduce
> > the size
> > > > > > of
> > > > > > > > the downloadable artifact and reduce the number of potential
> > > > > > > > vulnerabilities in third-party libraries.
> > > > > > > >
> > > > > > > > The list of modules was chosen subjectively by the number of
> > questions
> > > > > > on
> > > > > > > > the user-list, number third-party libraries (size) and
> > vulnerabilities
> > > > > > > the
> > > > > > > > module brings. Given that there are still questions, we are
> > definitely
> > > > > > > not
> > > > > > > > ready to release it in 2.8.0.
> > > > > > > >
> > > > > > > > Let's move discussion to the original thread?
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
> > > > > > > >
> > > > > > >
> > > > > >
> >

Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1

[Ilya Kasnacheev]

Hello!

Can we please hold back publishing AI-2.8.0-rc1 as public Apache Ignite 2.8
release?

I have just been notified that
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedColocated
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedMixed
are flaky: they seem to deadlock on putAll sorted keys maps. They used to
pass solidly on 2.7, but fail on master and ignite-2.8.

(They fail around 1 time out of 10, so just run them 25 times to check)

If there is indeed a deadlock, this would become a blocker to this release,
in my opinion, but I need some time to check.

Regards,
-- 
Ilya Kasnacheev


вс, 1 мар. 2020 г. в 11:29, Maxim Muzafarov :

> Ivan,
>
>
> I agree with you that the more members will check the release the
> better will be. That's why I've shared the release candidate links [1]
> before starting a vote. The best time for starting a vote is not
> mentioned at our release wiki page [2] (should we?) and I've also
> failed with googling the best practices for it too. So, I've supposed
> since all of us are working on their own tasks during weekdays the
> free time on the weekend is the best choice for cheking\voting on the
> release. Probably this decision was wrong.
>
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p46117.html
> [2] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
>
> On Sun, 1 Mar 2020 at 00:37, Ivan Pavlukhin  wrote:
> >
> > Also I have a comment regarding to voting. Voting for 72 hour spanning
> > a weekend sounds a little bit odd to me. In a particular case the more
> > people check the release the better. And I suppose there is more time
> > for it on weekdays for the majority.
> >
> > Best regards,
> > Ivan Pavlukhin
> >
> > вс, 1 мар. 2020 г. в 00:33, Ivan Pavlukhin :
> > >
> > > > As I remember, that Pavlov suggested to discuss threats on a private
> PMC list
> > > Cannot understand why it should be discussed on a private list. What
> > > is the clue?
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > > сб, 29 февр. 2020 г. в 16:00, Alexey Zinoviev  >:
> > > >
> > > > As I remember, that Pavlov suggested to discuss threats on a private
> PMC
> > > > list
> > > >
> > > > сб, 29 февр. 2020 г., 15:12 Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>:
> > > >
> > > > > Hello!
> > > > >
> > > > > As far as my understanding goes, ignite-zookeeper is listed for
> removal
> > > > > because it brings a lot of dependencies, some of which may have
> known
> > > > > vulnerabilities, which will make the distribution also considered
> > > > > vulnerable by some scanners.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > сб, 29 февр. 2020 г. в 14:18, Alexey Zinoviev <
> zaleslaw@gmail.com>:
> > > > >
> > > > > > Ok, lets move to this thread. Also, the slim release could be
> form by
> > > > > > voting on user-list
> > > > > >
> > > > > > сб, 29 февр. 2020 г., 9:55 Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > > > > >:
> > > > > >
> > > > > > > Nikolay, Alexey,
> > > > > > >
> > > > > > > First, the idea of the slim binary release and docker image was
> > > > > discussed
> > > > > > > openly on the dev-list [1]. Second, nobody talks about
> removing these
> > > > > > > modules from the product. The idea was to create an additional
> > > > > > distribution
> > > > > > > which is much lighter than the current full package to reduce
> the size
> > > > > of
> > > > > > > the downloadable artifact and reduce the number of potential
> > > > > > > vulnerabilities in third-party libraries.
> > > > > > >
> > > > > > > The list of modules was chosen subjectively by the number of
> questions
> > > > > on
> > > > > > > the user-list, number third-party libraries (size) and
> vulnerabilities
> > > > > > the
> > > > > > > module brings. Given that there are still questions, we are
> definitely
> > > > > > not
> > > > > > > ready to release it in 2.8.0.
> > > > > > >
> > > > > > > Let's move discussion to the original thread?
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
> > > > > > >
> > > > > >
> > > > >
>

[jira] [Created] (IGNITE-12745) Compute job system view

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12745:


 Summary: Compute job system view
 Key: IGNITE-12745
 URL: https://issues.apache.org/jira/browse/IGNITE-12745
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov


ComputeTaskView shows compute tasks that was started(initiated) on the local 
node.

We need to introduce another view that will show compute jobs - jobs that 
executing on the local node but was initiated on some remote node.



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

[Community] San Francisco, Chicago, Warsaw, NY let’s meet +online

[Kseniya Romanova]

Hi, Igniters!

If you are from the areas mentioned in subj, consider signing for events
featuring Ignite talks by our contributors and PMCs. Unless the spread of
coronavirus puts off those, you'll be able to meet our community experts in
person and challenge with your questions.

2020-03-09, San Francisco, In-Memory Computing Meetup (speaker - Denis
Magda and Nicolas Frankel of Hazelcast)[1]
2020-03-17, Chicago Postgres SQL Meetup (speaker - Val Kulichenko)[2]
2020-03-20, Warsaw (Poland), SQA Days EU (speaker - Ilya Suntsov)[3]
2020-03-23, NY, Postgress Con (speaker - Glenn Wiebe)[4]

If your talk about Ignite is confirmed for conference/meetup/online event,
please let me know, and I'll add it to the list[5] on the Ignite website.
Also, fill out the CFP form[6] if you'd like to share your Ignite story.

Finally, you can join expert sessions lead by our members remotely. Check
the following webinars; the next one is already tomorrow:

2020-03-04 - Security Guide for Apache Ignite and GridGain with
Configuration Examples (speaker - Andrey Alexandrov)[7]
2020-03-11 Using Apache Ignite for Continuous Machine and Deep Learning at
Scale (speaker - Ken Cottrell)[8]
2020-03-25 In-Memory Computing Essentials for Software Engineers (speaker -
Denis Magda)[9] - I highly recommend to share this webinar with colleagues
who are not familiar with IMC technologies.

Take care,
Kseniya
[1]
https://www.meetup.com/ru-RU/Bay-Area-In-Memory-Computing/events/268990399/
[2]
https://www.meetup.com/ru-RU/Chicago-PostgreSQL-User-Group/events/268744372/
[3] https://sqadays.eu/en/talk/81191
[4] https://postgresconf.org/conferences/2020
[5] https://ignite.apache.org/events.html
[6]
https://docs.google.com/forms/d/e/1FAIpQLSdiY7movHKvyWg3gOVedHgukJJnNiaejSO_X838vBseL9VmiQ/viewform
[7]
https://www.gridgain.com/resources/webinars/security-guide-apache-ignite-and-gridgain-configuration-examples
[8]
https://www.gridgain.com/resources/webinars/using-apache-ignite-continuous-machine-and-deep-learning-scale
[9]
https://www.gridgain.com/resources/webinars/in-memory-computing-essentials-software-engineers

Re: Ignite 2.8 documentation

[Maxim Muzafarov]

Folks,

This is in the `Ignite Core` section, so I think mostly related to
java functionality and thin client protocol extension [1]. Sorry for
not being too accurate with this statement
.
The same change is mentioned for C++ and .NET sections of the release
notes (but not for other thin clients).


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

On Tue, 3 Mar 2020 at 17:33, Igor Sapego  wrote:
>
> That's right, only C++ and .NET clients have partition awareness
>
> Best Regards,
> Igor
>
>
> On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov 
> wrote:
>
> > Hi everyone,
> >
> > Looks like the following line from the Ignite 2.8 release notes is a bit
> > of an overstatement and should be removed:
> >
> > > Added support best effort affinity for thin clients (partition awareness)
> >
> > Java thin client does not support partition awareness. Nodejs and python
> > thin clients from the distribution package do not have signs of this
> > feature as well.
> >
> > Igor,
> >
> > Could you please confirm or deny this?
> >
> > -Artem
> >
> > Artem Budnikov
> > Technical Writergridgain.com
> >
> > On 03.03.2020 01:47, Denis Magda wrote:
> >
> > Hi Alexey,
> >
> > Thanks for updating the documentation. The update process is cumbersome as
> > of now. What will happen is that we will be replacing the content of the
> > current pages (pre 2.8 pages) with the content from the 2.8 versions. Once
> > the text is copied manually, a 2.8 version of the page will be deleted. I
> > would advise Artem to do that this time and update the wiki page with more
> > details:
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document
> >
> > Also, why should we release this page?
> > https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms
> >
> > -
> > Denis
> >
> >
> > On Sun, Mar 1, 2020 at 7:59 AM Alexey Zinoviev 
> > wrote:
> >
> >> Hi, Igniters, I've finished the ML documentation.
> >>
> >> I have the issue that, for example I've created a new version of page with
> >> postfix -2.8 and the page name contains this postfix.
> >> How are we going to replace the URL? Or we will replace the content from
> >> initial page?
> >>
> >> For example, I've created the new version of page
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees
> >> and
> >> moved it under new page
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees-28
> >> How it will be processed to obtain the  decision-trees url for the new
> >> page?
> >>
> >>
> >> In all case the full list of removed/replaced pages for ML is next:
> >>
> >> In the release 2.8, please remove the pages
> >>
> >>1.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms
> >>
> >>2.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-multi-class-classification
> >>
> >>3. DeepLearning block with 3 pages
> >>4.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-cross-validation
> >>
> >>
> >> Next pages were replaced with postfix 2.8 and grouped under new pages
> >>
> >>1.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/machine-learning
> >>
> >>2.
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/preprocessing
> >>
> >>3.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/ols-multiple-linear-regression
> >>
> >>4.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/k-means-clustering
> >>
> >>5.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/multilayer-perceptron
> >>
> >>6.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-classification
> >>
> >>7.
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-regression
> >>
> >>8.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-binary-classification
> >>
> >>9.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/logistic-regression
> >>
> >>10.
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/random-forest
> >>
> >>11.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/gradient-boosting
> >>
> >>12.
> >>https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-updating
> >>13.
> >>
> >> https://dash.readme.io/project/apacheignite/v2.7.6/docs/ann-approximate-nearest-neighbor
> >>
> >>
> >>
> >>
> >> ср, 26 февр. 2020 г. в 03:32, Denis Magda :
> >>
> >> > Hi Prasad,
> >> >
> >> > This is odd behavior and before changing the docs I would try to get to
> >> the
> >> > bottom. Let me join the user list conversation.
> >> >
> >> > -
> >> > Denis
> >> >
> >> >
> >> > On Tue, Feb 25, 2020 at 3:46 AM Prasad Bhalerao <
> >> > prasadbhalerao1...@gmail.com> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > Can we have this behavior documented? This will help user to design
> >> their
> >> > > caches appropriately.
> >> > >
> >> > > *For Replicated Cache:*
> >> > >
> >> > > 

[jira] [Created] (IGNITE-12744) Add user attributes to GridRestRequest creation routine

[Andrey Kuznetsov (Jira)]

Andrey Kuznetsov created IGNITE-12744:
-

 Summary: Add user attributes to GridRestRequest creation routine
 Key: IGNITE-12744
 URL: https://issues.apache.org/jira/browse/IGNITE-12744
 Project: Ignite
  Issue Type: Improvement
  Components: rest
Affects Versions: 2.8
Reporter: Andrey Kuznetsov


Improvement [1] has added user attributes support to Ignite thin clients. REST 
API connections should also support this feature: 
{{GridJettyRestHandler.createRequest}} can read user attributes from HTTP 
request parameters.

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



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

Re: Ignite 2.8 documentation

[Igor Sapego]

That's right, only C++ and .NET clients have partition awareness

Best Regards,
Igor


On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov 
wrote:

> Hi everyone,
>
> Looks like the following line from the Ignite 2.8 release notes is a bit
> of an overstatement and should be removed:
>
> > Added support best effort affinity for thin clients (partition awareness)
>
> Java thin client does not support partition awareness. Nodejs and python
> thin clients from the distribution package do not have signs of this
> feature as well.
>
> Igor,
>
> Could you please confirm or deny this?
>
> -Artem
>
> Artem Budnikov
> Technical Writergridgain.com
>
> On 03.03.2020 01:47, Denis Magda wrote:
>
> Hi Alexey,
>
> Thanks for updating the documentation. The update process is cumbersome as
> of now. What will happen is that we will be replacing the content of the
> current pages (pre 2.8 pages) with the content from the 2.8 versions. Once
> the text is copied manually, a 2.8 version of the page will be deleted. I
> would advise Artem to do that this time and update the wiki page with more
> details:
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document
>
> Also, why should we release this page?
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms
>
> -
> Denis
>
>
> On Sun, Mar 1, 2020 at 7:59 AM Alexey Zinoviev 
> wrote:
>
>> Hi, Igniters, I've finished the ML documentation.
>>
>> I have the issue that, for example I've created a new version of page with
>> postfix -2.8 and the page name contains this postfix.
>> How are we going to replace the URL? Or we will replace the content from
>> initial page?
>>
>> For example, I've created the new version of page
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees
>> and
>> moved it under new page
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees-28
>> How it will be processed to obtain the  decision-trees url for the new
>> page?
>>
>>
>> In all case the full list of removed/replaced pages for ML is next:
>>
>> In the release 2.8, please remove the pages
>>
>>1.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms
>>
>>2.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-multi-class-classification
>>
>>3. DeepLearning block with 3 pages
>>4.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-cross-validation
>>
>>
>> Next pages were replaced with postfix 2.8 and grouped under new pages
>>
>>1.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/machine-learning
>>
>>2.
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/preprocessing
>>
>>3.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/ols-multiple-linear-regression
>>
>>4.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/k-means-clustering
>>
>>5.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/multilayer-perceptron
>>
>>6.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-classification
>>
>>7.
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-regression
>>
>>8.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-binary-classification
>>
>>9.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/logistic-regression
>>
>>10.
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/random-forest
>>
>>11.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/gradient-boosting
>>
>>12.
>>https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-updating
>>13.
>>
>> https://dash.readme.io/project/apacheignite/v2.7.6/docs/ann-approximate-nearest-neighbor
>>
>>
>>
>>
>> ср, 26 февр. 2020 г. в 03:32, Denis Magda :
>>
>> > Hi Prasad,
>> >
>> > This is odd behavior and before changing the docs I would try to get to
>> the
>> > bottom. Let me join the user list conversation.
>> >
>> > -
>> > Denis
>> >
>> >
>> > On Tue, Feb 25, 2020 at 3:46 AM Prasad Bhalerao <
>> > prasadbhalerao1...@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > Can we have this behavior documented? This will help user to design
>> their
>> > > caches appropriately.
>> > >
>> > > *For Replicated Cache:*
>> > >
>> > > Reference mail thread:
>> > >
>> > >
>> >
>> http://apache-ignite-users.70518.x6.nabble.com/Read-through-not-working-as-expected-in-case-of-Replicated-cache-td29990.html
>> > >
>> > >  read through for replicated cache would work where there is either:
>> > > - writeThrough enabled and all changes do through it.
>> > > - database contents do not change for already read keys.
>> > >
>> > > Thanks,
>> > > Prasad
>> > >
>> > > On Mon, Feb 24, 2020 at 7:31 PM Alexey Zinoviev <
>> zaleslaw@gmail.com>
>> > > wrote:
>> > >
>> > > > Please, could you post in this thread a few examples of the
>> > documentation
>> > > > tickets in JIRA for the current release, to create them correctly?
>> > > >
>> > > > пн, 24 февр. 2020 г. в 

[jira] [Created] (IGNITE-12743) Thin client: thread does not stop

[Surkov Aleksandr (Jira)]

Surkov Aleksandr created IGNITE-12743:
-

 Summary: Thin client: thread does not stop
 Key: IGNITE-12743
 URL: https://issues.apache.org/jira/browse/IGNITE-12743
 Project: Ignite
  Issue Type: Bug
Reporter: Surkov Aleksandr


If set *several* addresses for thin client and set option 
*setPartitionAwarenessEnabled(true)* then client is hanging.
{code:java}
public static void main(String[] args) throws Exception {

final ClientConfiguration clientCfg = new ClientConfiguration()
.setAddresses("10.36.8.68:" + ClientConnectorConfiguration.DFLT_PORT, 
"10.36.8.69:" + ClientConnectorConfiguration.DFLT_PORT)
.setPartitionAwarenessEnabled(true);

try (IgniteClient client = Ignition.startClient(clientCfg)) {

}

}{code}



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

[jira] [Created] (IGNITE-12742) Thick client: client hangs when trying to connect to port 10800

[Surkov Aleksandr (Jira)]

Surkov Aleksandr created IGNITE-12742:
-

 Summary: Thick client: client hangs when trying to connect to port 
10800
 Key: IGNITE-12742
 URL: https://issues.apache.org/jira/browse/IGNITE-12742
 Project: Ignite
  Issue Type: Bug
Reporter: Surkov Aleksandr


If connect by thick client to port 10800(port of thin client) then program can 
be hanging.

It would be great to receive message about protocol non-compliance.
{code:java}
public class HangingThickClient extends GridCommonAbstractTest {
private static final String CLIENT = "client";

@Override protected IgniteConfiguration getConfiguration(String 
igniteInstanceName) throws Exception {
final IgniteConfiguration configuration = new IgniteConfiguration()
.setIgniteInstanceName(igniteInstanceName);


if (igniteInstanceName.startsWith(CLIENT)) {
configuration
.setClientMode(true);
}

final Set addresses = igniteInstanceName.startsWith(CLIENT) ? 
Collections.singleton("127.0.0.1:10800") :
Collections.singleton("127.0.0.1:47500..47509");

configuration.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(
new TcpDiscoveryVmIpFinder(true)
.setAddresses(addresses)
)
);

return configuration;
}

@Test
public void hangingThickClientTest() throws Exception {
Ignite server = startGrid();
Ignite client = Ignition.start(getConfiguration(CLIENT));

}
}{code}



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

Re: Ignite 2.8 documentation

[Artem Budnikov]

Hi everyone,

Looks like the following line from the Ignite 2.8 release notes is a bit 
of an overstatement and should be removed:


> Added support best effort affinity for thin clients (partition awareness)

Java thin client does not support partition awareness. Nodejs and python 
thin clients from the distribution package do not have signs of this 
feature as well.


Igor,

Could you please confirm or deny this?

-Artem

Artem Budnikov
Technical Writer
gridgain.com

On 03.03.2020 01:47, Denis Magda wrote:

Hi Alexey,

Thanks for updating the documentation. The update process is 
cumbersome as of now. What will happen is that we will be replacing 
the content of the current pages (pre 2.8 pages) with the content from 
the 2.8 versions. Once the text is copied manually, a 2.8 version of 
the page will be deleted. I would advise Artem to do that this time 
and update the wiki page with more details:

https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document

Also, why should we release this page?
https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

-
Denis


On Sun, Mar 1, 2020 at 7:59 AM Alexey Zinoviev > wrote:


Hi, Igniters, I've finished the ML documentation.

I have the issue that, for example I've created a new version of
page with
postfix -2.8 and the page name contains this postfix.
How are we going to replace the URL? Or we will replace the
content from
initial page?

For example, I've created the new version of page
https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees
and
moved it under new page
https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees-28
How it will be processed to obtain the  decision-trees url for the
new page?


In all case the full list of removed/replaced pages for ML is next:

In the release 2.8, please remove the pages

   1.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

   2.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-multi-class-classification

   3. DeepLearning block with 3 pages
   4.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-cross-validation


Next pages were replaced with postfix 2.8 and grouped under new pages

   1.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/machine-learning

   2.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/preprocessing

   3.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/ols-multiple-linear-regression

   4.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/k-means-clustering

   5.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/multilayer-perceptron

   6.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-classification

   7.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-regression

   8.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-binary-classification

   9.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/logistic-regression

   10.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/random-forest

   11.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/gradient-boosting

   12.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-updating
   13.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/ann-approximate-nearest-neighbor




ср, 26 февр. 2020 г. в 03:32, Denis Magda mailto:dma...@apache.org>>:

> Hi Prasad,
>
> This is odd behavior and before changing the docs I would try to
get to the
> bottom. Let me join the user list conversation.
>
> -
> Denis
>
>
> On Tue, Feb 25, 2020 at 3:46 AM Prasad Bhalerao <
> prasadbhalerao1...@gmail.com
> wrote:
>
> > Hi,
> >
> > Can we have this behavior documented? This will help user to
design their
> > caches appropriately.
> >
> > *For Replicated Cache:*
> >
> > Reference mail thread:
> >
> >
>

http://apache-ignite-users.70518.x6.nabble.com/Read-through-not-working-as-expected-in-case-of-Replicated-cache-td29990.html
> >
> >  read through for replicated cache would work where there is
either:
> > - writeThrough enabled and all changes do through it.
> > - database contents do not change for already read keys.
> >
> > Thanks,
> > Prasad
> >
> > On Mon, Feb 24, 2020 at 7:31 PM Alexey Zinoviev
mailto:zaleslaw@gmail.com>>
> > wrote:
> >
> > > Please, could you post in this thread a few examples of the
> documentation
> > > tickets in JIRA for the current release, to create them
correctly?
> > >
> > > пн, 24 февр. 2020 г. в 14:53, Alexey Zinoviev
mailto:zaleslaw@gmail.com>
> >:
   

[jira] [Created] (IGNITE-12741) Allow exchange merges for PME free switch.

[Alexey Scherbakov (Jira)]

Alexey Scherbakov created IGNITE-12741:
--

 Summary: Allow exchange merges for PME free switch.
 Key: IGNITE-12741
 URL: https://issues.apache.org/jira/browse/IGNITE-12741
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.8
Reporter: Alexey Scherbakov
 Fix For: 2.9


Currently exchange merges are disabled if multiple baseline nodes left/failed.

It's possible to have enabled merges together with enabled optimization.



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

[jira] [Created] (IGNITE-12740) Supports feature flags on index meta pages

[Taras Ledkov (Jira)]

Taras Ledkov created IGNITE-12740:
-

 Summary: Supports feature flags on index meta pages
 Key: IGNITE-12740
 URL: https://issues.apache.org/jira/browse/IGNITE-12740
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


Some changes on indexing e.g. inl;ine java objects, unwrap PK columns and 
several planned features (change inline pojo format, inline DECIMAL fields etc) 
break backward compatibility.

We have to add metadata about index layout and format to index tree meta-page.



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

Re: Java thin client errors handling

[Alexey Kukushkin]

Hi Guys,

Most likely I just forgot to remove the "internal" ClientError and
ClientProtocolError when I was implementing a review comment to merge the
Java thin client into ignite-core (originally I developed the Java thin
client as a separate module). I see that the ClientProtocolError is not
used in the code at all and the ClientError is used to report some SSL
initialisation failures.

We cannot throw "internal" exceptions from public API. I would open a
"newbie" ticket to get rid of the "internal" ClientError and
ClientProtocolError.

The public ClientException and its subclasses are used to report the Java
thin client errors now.

As I understand we are reviewing some new feature that utilises the
internal "ClientProtocolError". I would create a new public
org.apache.ignite.client.ClientProtocolException extending ClientException
instead.



On Tue, Mar 3, 2020 at 2:50 PM Igor Sapego  wrote:

> Hi,
>
> I believe, we definitely should not ignore this.
>
> Alexey, you are the author of this code. What do you think?
>
> Best Regards,
> Igor
>
>
> On Thu, Feb 27, 2020 at 3:56 PM Aleksandr Shapkin 
> wrote:
>
> > Hello!
> >
> >
> >
> > I just noticed that the Java thin client throws the following internal
> > exceptions:
> >
> > ClientProtocolError
> >
> > ClientError
> >
> >
> >
> > Since the classes are not public, there is no way to catch them properly
> in
> > user code.
> >
> > Consider the recent changes, introduced by IGNITE-9410:
> >
> >
> >
> > throw new ClientProtocolError(String.format("Transactions have not
> > supported by the server's " +
> >
> > "protocol version %s, required version %s",
> > req.clientChannel().serverVersion(), V1_5_0));
> >
> >
> >
> > The code above correctly verifies the server version against the current
> > client and throws an exception
> >
> > In case of an outdated server. The only way to catch it in user code is
> by
> > RuntimeException
> >
> > that feels too broad to use.
> >
> >
> >
> > I’d like to discuss what’d be the best option to handle this scenario:
> >
> > -Should we make the ClientError public?
> >
> > -Should we introduce a new public error for every particular
> > exception?
> >
> > -Just ignore this?
> >
> >
> >
> > Thoughts?
> >
> > --
> > Alex.
> >
>


-- 
Best regards,
Alexey

Re: Java thin client errors handling

[Igor Sapego]

Hi,

I believe, we definitely should not ignore this.

Alexey, you are the author of this code. What do you think?

Best Regards,
Igor


On Thu, Feb 27, 2020 at 3:56 PM Aleksandr Shapkin  wrote:

> Hello!
>
>
>
> I just noticed that the Java thin client throws the following internal
> exceptions:
>
> ClientProtocolError
>
> ClientError
>
>
>
> Since the classes are not public, there is no way to catch them properly in
> user code.
>
> Consider the recent changes, introduced by IGNITE-9410:
>
>
>
> throw new ClientProtocolError(String.format("Transactions have not
> supported by the server's " +
>
> "protocol version %s, required version %s",
> req.clientChannel().serverVersion(), V1_5_0));
>
>
>
> The code above correctly verifies the server version against the current
> client and throws an exception
>
> In case of an outdated server. The only way to catch it in user code is by
> RuntimeException
>
> that feels too broad to use.
>
>
>
> I’d like to discuss what’d be the best option to handle this scenario:
>
> -Should we make the ClientError public?
>
> -Should we introduce a new public error for every particular
> exception?
>
> -Just ignore this?
>
>
>
> Thoughts?
>
> --
> Alex.
>

Ignite Hadoop Accelerator #CGO#

[Shah, Prachi]

Hi Team,

We are trying to use Ignite Hadoop Accelerator for one of our implementation.

But I understand Ignite Hadoop Acceleration is to be discontinued very soon.

Need to know the alternatives to the Accelerator to use Ignite for Hadoop file 
system.



Thanks,
Prachi
This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.

[jira] [Created] (IGNITE-12739) Optimistic serializable transactions may fail infinitely when read-through is enabled

[Alexey Goncharuk (Jira)]

Alexey Goncharuk created IGNITE-12739:
-

 Summary: Optimistic serializable transactions may fail infinitely 
when read-through is enabled
 Key: IGNITE-12739
 URL: https://issues.apache.org/jira/browse/IGNITE-12739
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk


In current design it is possible that the same key-value pair will be stored 
with different versions on primary and backup nodes. For example, a 
read-through is invoked separately on primary backup and values are stored with 
node local version.

With this precondition, if an optimistic serializable transaction is started 
from a backup node, the serializable check version is read from backup, but 
validated on primary node, which will fail the transaction with optimistic 
read/write conflict exception until the versions are overwritten to the same 
value (for example, via a pessimistic transaction).

While we need to additionally investigate whether we want to change the 
read-through logic to ensure the same value and version on all nodes, this 
particular scenario should be fixed by always enforcing reading from a primary 
node inside an optimistic serializable transaction.

The reproducer is attached. A known workaround is to disable read load 
balancing by setting "-DIGNITE_READ_LOAD_BALANCING=false" system property.



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

[jira] [Created] (IGNITE-12738) CVEs in the dependencies are in the execution path of your project

[XuCongying (Jira)]

XuCongying created IGNITE-12738:
---

 Summary: CVEs in the dependencies are in the execution path of 
your project
 Key: IGNITE-12738
 URL: https://issues.apache.org/jira/browse/IGNITE-12738
 Project: Ignite
  Issue Type: Bug
Reporter: XuCongying
 Attachments: apache-ignite_CVE-report.md

Your project uses some depenidencies with CVEs. I found that the buggy methods 
of the CVEs are in the program execution path of your project, which makes your 
project at risk. I have suggested some version updates. The details are as 
follows.
 * *Vulnerable Dependency:* org.apache.hadoop : hadoop-common : 2.9.1

 * *Call Chain to Buggy Methods:*

 ** *Some files in your project call the library method 
org.apache.hadoop.fs.FileUtil.unZip(java.io.File,java.io.File), which can reach 
the buggy method of 
[CVE-2018-8009|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8009].*

 *** Files in your project:  
modules/hadoop/src/main/java/org/apache/ignite/internal/processors/hadoop/impl/v2/HadoopV2JobResourceManager.java

 *** One of the possible call chain:
org.apache.hadoop.fs.FileUtil.unZip(java.io.File,java.io.File) [buggy method]
 ** Files in your project:  
modules/hadoop/src/main/java/org/apache/ignite/internal/processors/hadoop/impl/v2/HadoopV2JobResourceManager.java

 *** One of the possible call chain:
org.apache.hadoop.fs.FileUtil.unTar(java.io.File,java.io.File)
org.apache.hadoop.fs.FileUtil.unTarUsingJava(java.io.File,java.io.File,boolean)
org.apache.hadoop.fs.FileUtil.unpackEntries(org.apache.commons.compress.archivers.tar.TarArchiveInputStream,org.apache.commons.compress.archivers.tar.TarArchiveEntry,java.io.File)
 [buggy method]
 ** *Update suggestion:* version 3.2.0 3.2.0 is a safe version without CVEs. 
From 2.9.1 to 3.2.0, 4 of the APIs (called by 5 times in your project) were 
removed, 14 APIs (called by 44 times in your project) were modified.

 ** *Some files in your project call the library method 
org.apache.hadoop.fs.FileUtil.unTar(java.io.File,java.io.File), which can reach 
the buggy method of 
[CVE-2018-8009|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8009].*



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

Re: Reference of local service.

[Vyacheslav Daradur]

Denis, finally I understood your arguments about interfaces check, thank
you for the explanation.

I agree with the proposal to introduce a new method which returns proxy
include the case of locally deployed services.

Also, such a method should be able to work in mode "local services
preferred", perhaps with load-balancing (in case of multiple locally
deployed instances). This allows our end-users to reach better performance.



On Mon, Mar 2, 2020 at 7:51 PM Denis Mekhanikov 
wrote:

> Vyacheslav,
>
> You can't make service interfaces extend
> *org.apache.ignite.services.Service*. Currently it works perfectly if
> *org.apache.ignite.services.Service* and a user-defined interface are
> independent. This is actually the case in our current examples:
>
> https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/servicegrid/SimpleMapService.java
> I mentioned the *Serializable* interface just as an example of an interface
> that can be present, but it's not the one that is going to be called by a
> user.
>
> What I'm trying to say is that there is no way to say whether the service
> is going to be used through a proxy only, or usage of a local instance is
> also possible.
>
> Vladimir,
>
> I don't like the idea, that enabling or disabling of metrics will change
> the behaviour of the component you collect the metrics for. Such behaviour
> is far from obvious.
>
> Nikolay,
>
> I agree, that such approach is valid and makes total sense. But making the
> *IgniteServices#serviceProxy()* method always return a proxy instead of a
> local instance will change the public contract. The javadoc currently says
> the following:
>
> > If service is available locally, then local instance is returned,
> > otherwise, a remote proxy is dynamically created and provided for the
> > specified service.
>
>
> I propose introducing a new method that will always return a service proxy
> regardless of local availability, and deprecating *serviceProxy()* and
> *service()
> *methods. What do you think?
>
> Denis
>
> пн, 2 мар. 2020 г. в 16:08, Nikolay Izhikov :
>
> > Hello, Vladimir.
> >
> > > What if we just provide an option to disable service metrics at all?
> >
> > I don't think we should create an explicit property for service metrics.
> > We will implement the way to disable any metrics in the scope of
> > IGNITE-11927 [1].
> >
> > > Usage of a proxy instead of service instances can lead to performance
> > > degradation for local instances, which is another argument against such
> > change.
> >
> > As far as I know, many and many modern frameworks use a proxy approach.
> > Just to name one - Spring framework works with the proxy.
> >
> > We should measure the impact on the performance that brings proxy+metric
> > and after it make the decision on local service metrics implementation.
> > Vladimir, can you, as a contributor of this task make this measurement?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-11927
> >
> > пн, 2 мар. 2020 г. в 12:56, Vladimir Steshin :
> >
> > > Denis, Vyacheslav, hi.
> > >
> > > What if we just provide an option to disable service metrics at all? It
> > > would keep direct references for local services. Also, we can make
> > service
> > > metrics disabled by default to keep current code working. A warning of
> > > local service issues will be set with the option.
> > >
> > > пн, 2 мар. 2020 г. в 11:26, Vyacheslav Daradur :
> > >
> > > > >> Moreover, I don't see a way of implementing such a check. Are you
> > > going
> > > > to look just for any interface? What about Serializable? Will it do?
> > > >
> > > > The check should look for the interface which implements
> > > > "org.apache.ignite.services.Service", it covers the requirement to be
> > > > Serializable.
> > > >
> > > > >> For now though the best thing we can do is to calculate remote
> > > > invocations only, since all of them go through a proxy.
> > > >
> > > > Let's introduce a system property to manage local services
> monitoring:
> > > > - local services monitoring will be disabled by default - to avoid
> any
> > > > backward compatibility issues;
> > > > - local services monitoring can be enabled runtime with a known
> > > limitation
> > > > for new services for example;
> > > > Moreover, if we introduce such a feature flag to
> ServiceConfiguration -
> > > > the new feature can be enabled per service separately.
> > > >
> > > > What do you think?
> > > >
> > > >
> > > >
> > > > On Mon, Mar 2, 2020 at 12:33 AM Denis Mekhanikov <
> > dmekhani...@gmail.com>
> > > > wrote:
> > > >
> > > >> Vladimir, Slava,
> > > >>
> > > >> In general, I like the idea of abstracting the service deployment
> from
> > > >> its usage, but there are some backward-compatibility considerations
> > that
> > > >> won't let us do so.
> > > >>
> > > >> Or we can declare usage of services without interfaces incorrect
> > > >>
> > > >>
> > > >> I don't think we can introduce a requirement for all services to
> have
> >