Re: Removing "fabric" from Ignite binary package name

[Peter Ivanov]

Ok, then I will update issue code and start preparation for build
configuration changes.


On Thu, 7 Jun 2018 at 23:41, Denis Magda  wrote:

> >
> > With which one — current implementation in issue?
>
>
> That's the answer to your question:
>
> 1. quickly fix all of them (can be solved by preliminary preparations —
> searching for -fabric- usages in build configuration);
> 2. update all branches to master because otherwise old branch will stop
> building.
>
>
> --
> Denis
>
> On Thu, Jun 7, 2018 at 1:12 PM, Petr Ivanov  wrote:
>
> >
> > > On 7 Jun 2018, at 23:04, Denis Magda  wrote:
> > >
> > > I'm fine with the suggested approach.
> >
> > With which one — current implementation in issue?
> >
> >
> > > However, not sure we need to update
> > > all the branches. Can't branch owners just pull the changes back from
> > > master if the plan to merge back later?
> >
> > Of course, we as an initiative group of this issue should do nothing, it
> > will lie on shoulders of developers.
> >
> >
> > >
> > > --
> > > Denis
> > >
> > > On Thu, Jun 7, 2018 at 12:57 PM, Petr Ivanov 
> > wrote:
> > >
> > >> Denis,
> > >>
> > >>
> > >> The most simple approach — repack and rearchive binary archive after
> > >> release build, however that would not resolve the problem globally
> (and
> > >> will require fixing every build configuration we have on TeamCity).
> > >> Current approach implemented in task — creates already correct folder
> > and
> > >> binary archive name, but old name (with -fabric-) is used in almost
> > every
> > >> build configuration too and merge code to master will require to:
> > >>1. quickly fix all of them (can be solved by preliminary
> preparations
> > >> — searching for -fabric- usages in build configuration);
> > >>2. update all branches to master because otherwise old branch will
> > >> stop building.
> > >>
> > >> WDYT?
> > >>
> > >>
> > >>
> > >>> On 7 Jun 2018, at 22:42, Denis Magda  wrote:
> > >>>
> > >>> Petr,
> > >>>
> > >>> Thanks for pulling up the conversation.
> > >>>
> > >>> I still prefer us not to complicate the things and just remove
> "fabric"
> > >>> from the *package name*. Use the easiest way possible.
> > >>>
> > >>> Personally, I don't care about Hadoop and would not suggest the
> > community
> > >>> wasting its time on it. So, just rename the suffixes/prefixes of the
> > >> build
> > >>> files the way you like to address Anton's concerns.
> > >>>
> > >>> --
> > >>> Denis
> > >>>
> > >>>
> > >>> On Thu, Jun 7, 2018 at 1:49 AM, Petr Ivanov 
> > wrote:
> > >>>
> >  Igniters,
> > 
> > 
> >  Lets define once again what should be done in this [1] task?
> >  If current implementation is good, than I’ll update it to master and
> > >> pass
> >  for review.
> > 
> >  Yet, there is other part of the task which concerns our build server
> > — I
> >  assume that almost all our build configurations will fail due to
> name
> >  change and there is no simple way of updating configurations other
> > then
> >  merge task to master and start fixing failing builds.
> > 
> > 
> >  [1] https://issues.apache.org/jira/browse/IGNITE-7251
> > 
> > 
> > 
> > > On 10 Feb 2018, at 01:56, Denis Magda  wrote:
> > >
> > >> I don't think we necessarily need to remove 'fabric' word from
> every
> >  file
> > >> in the project, we just need to rename the name of downloadable
> > >> package.
> > >
> > > Couldn’t say it better than you, Val. Thanks for pitching in :)
> This
> > is
> >  exactly what the ticket is about.
> > >
> > > —
> > > Denis
> > >
> > >> On Feb 9, 2018, at 11:53 AM, Valentin Kulichenko <
> >  valentin.kuliche...@gmail.com> wrote:
> > >>
> > >> Anton,
> > >>
> > >> I don't think we necessarily need to remove 'fabric' word from
> every
> >  file
> > >> in the project, we just need to rename the name of downloadable
> >  package. Is
> > >> there any other place where 'fabric' is exposed to the user?
> > >>
> > >> If that's the case, it should not be a big change, no?
> > >>
> > >> -Val
> > >>
> > >> On Fri, Feb 9, 2018 at 3:49 AM, Anton Vinogradov <
> >  avinogra...@gridgain.com>
> > >> wrote:
> > >>
> > >>> Denis,
> > >>>
> > >>> You're proposing changes without viewing a code :)
> > >>>
> > >>>
> > >>> On Thu, Feb 8, 2018 at 10:07 PM, Denis Magda 
> >  wrote:
> > >>>
> >  Anton,
> > 
> >  What’s wrong if we just go ahead and:
> >  - replace “fabric” with “ignite”
> >  - replace “hadoop” with “ignite-hadoop"
> > 
> >  —
> >  Denis
> > 
> > > On Feb 8, 2018, at 1:51 AM, Anton Vinogradov <
> >  avinogra...@gridgain.com
> > 
> >  wrote:
> > >
> > > Denis,
> > >
> > > "hadoop" and "fabric" words work on same engine.
> > >
> > 

Re: Apache Ignite 2.6 - Packages roadmap

[Peter Ivanov]

On Fri, 8 Jun 2018 at 00:37, Denis Magda  wrote:

> Petr,
>
> Am I correct that all 3 points were tested for VirtualBox?


No, it was tested for Windows 10 WSL.


I would
> introduce a documentation sub-section for VirtualBox then.


As I said previously — under “honest” virtual environments (i. e.
VirtualBox, VMWare, Hyper-V, etc.) everything will work just as on the bare
metal. And no special section is required, otherwise you will end up
describing support of every virtualization technology in the world. I would
suggest we wait for some user and dev experience about using packages in
virtual and containerized environments to better understand what should be
mentioned in documentation and what should not.



>
> As for the Windows WSL, did you have a change to look into it?
>
> --
> Denis
>
> On Thu, Jun 7, 2018 at 2:42 AM, Petr Ivanov  wrote:
>
> > Here are the results of checks:
> >
> >
> > 1. Ubuntu. Running Apache Ignite as a stand-alone application works fine,
> > I have successful connections to another Apache Ignite node running under
> > VirtualBox CentOS.
> > NOTE: connectivity started working only after creation of “allow all
> > incoming connections” rule in Windows Defender Firewall.
> >
> > 2. Debian. Running Apache Ignite as a stand-alone application works fine,
> > I have successful connections to another Apache Ignite node running under
> > VirtualBox CentOS.
> > NOTE: in addition to Ubuntu’s NOTE, it is required to install dirmngr
> > program for apt-key be able to download gpg keys over network (this NOTE
> > can be added to documentation + I can add dependency to DEB package in
> next
> > release).
> >
> > 3. SUSE. Has neither APT no YUM commands. RPM package can be installed
> via
> > rpm -i command, but I think that this case is out of Apache Ignite 2.5
> > scope and the question of “officially supported Linux distributions”
> should
> > be discussed separately.
> >
> >
> >
> >
> > > On 7 Jun 2018, at 08:43, Peter Ivanov  wrote:
> > >
> > > Understood. Will do today.
> > >
> > >
> > > On Thu, 7 Jun 2018 at 08:43, Dmitriy Setrakyan  > > wrote:
> > > On Wed, Jun 6, 2018 at 10:40 PM, Peter Ivanov  > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > >
> > > > What kind of instructions? Systemd or stand-alone?
> > > > I thought we have already agreed that systemd services are not
> > eligible for
> > > > Windows 10 WSL.
> > > >
> > > > So have I to check that Debian, Ubuntu and SUSE environments for
> > Windows 10
> > > > WSL supports running Apache Ignite installed from packages as a
> > stand-alone
> > > > application?
> > > >
> > >
> > > Yes.
> >
> >
>

[jira] [Created] (IGNITE-8744) Incorrect behavior of cluster activation control

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8744:
--

 Summary: Incorrect behavior of cluster activation control
 Key: IGNITE-8744
 URL: https://issues.apache.org/jira/browse/IGNITE-8744
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Andrey Novikov


# start node 
# activate
# go to Queries history tab, click Refresh
# deactivate cluster using component- after several seconds component gets 
switched to 'Activating...' stage and hangs in this state for about minute



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4152: IGNITE-8736 Add transaction label to CU.txString(...

[macrergate]

GitHub user macrergate opened a pull request:

https://github.com/apache/ignite/pull/4152

IGNITE-8736 Add transaction label to CU.txString() method output



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8736

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4152.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4152


commit 2a0600acc524128335cffd06ae63e056b217d484
Author: Sergey Kosarev 
Date:   2018-06-08T03:12:30Z

IGNITE-8736 Add transaction label to CU.txString() method output




---

Re: Apache Ignite 2.6 - Packages roadmap

[Denis Magda]

Petr,

Am I correct that all 3 points were tested for VirtualBox? I would
introduce a documentation sub-section for VirtualBox then.

As for the Windows WSL, did you have a change to look into it?

--
Denis

On Thu, Jun 7, 2018 at 2:42 AM, Petr Ivanov  wrote:

> Here are the results of checks:
>
>
> 1. Ubuntu. Running Apache Ignite as a stand-alone application works fine,
> I have successful connections to another Apache Ignite node running under
> VirtualBox CentOS.
> NOTE: connectivity started working only after creation of “allow all
> incoming connections” rule in Windows Defender Firewall.
>
> 2. Debian. Running Apache Ignite as a stand-alone application works fine,
> I have successful connections to another Apache Ignite node running under
> VirtualBox CentOS.
> NOTE: in addition to Ubuntu’s NOTE, it is required to install dirmngr
> program for apt-key be able to download gpg keys over network (this NOTE
> can be added to documentation + I can add dependency to DEB package in next
> release).
>
> 3. SUSE. Has neither APT no YUM commands. RPM package can be installed via
> rpm -i command, but I think that this case is out of Apache Ignite 2.5
> scope and the question of “officially supported Linux distributions” should
> be discussed separately.
>
>
>
>
> > On 7 Jun 2018, at 08:43, Peter Ivanov  wrote:
> >
> > Understood. Will do today.
> >
> >
> > On Thu, 7 Jun 2018 at 08:43, Dmitriy Setrakyan  > wrote:
> > On Wed, Jun 6, 2018 at 10:40 PM, Peter Ivanov  > wrote:
> >
> > > Dmitriy,
> > >
> > >
> > > What kind of instructions? Systemd or stand-alone?
> > > I thought we have already agreed that systemd services are not
> eligible for
> > > Windows 10 WSL.
> > >
> > > So have I to check that Debian, Ubuntu and SUSE environments for
> Windows 10
> > > WSL supports running Apache Ignite installed from packages as a
> stand-alone
> > > application?
> > >
> >
> > Yes.
>
>

Re: Removing "fabric" from Ignite binary package name

[Denis Magda]

>
> With which one — current implementation in issue?


That's the answer to your question:

1. quickly fix all of them (can be solved by preliminary preparations —
searching for -fabric- usages in build configuration);
2. update all branches to master because otherwise old branch will stop
building.


--
Denis

On Thu, Jun 7, 2018 at 1:12 PM, Petr Ivanov  wrote:

>
> > On 7 Jun 2018, at 23:04, Denis Magda  wrote:
> >
> > I'm fine with the suggested approach.
>
> With which one — current implementation in issue?
>
>
> > However, not sure we need to update
> > all the branches. Can't branch owners just pull the changes back from
> > master if the plan to merge back later?
>
> Of course, we as an initiative group of this issue should do nothing, it
> will lie on shoulders of developers.
>
>
> >
> > --
> > Denis
> >
> > On Thu, Jun 7, 2018 at 12:57 PM, Petr Ivanov 
> wrote:
> >
> >> Denis,
> >>
> >>
> >> The most simple approach — repack and rearchive binary archive after
> >> release build, however that would not resolve the problem globally (and
> >> will require fixing every build configuration we have on TeamCity).
> >> Current approach implemented in task — creates already correct folder
> and
> >> binary archive name, but old name (with -fabric-) is used in almost
> every
> >> build configuration too and merge code to master will require to:
> >>1. quickly fix all of them (can be solved by preliminary preparations
> >> — searching for -fabric- usages in build configuration);
> >>2. update all branches to master because otherwise old branch will
> >> stop building.
> >>
> >> WDYT?
> >>
> >>
> >>
> >>> On 7 Jun 2018, at 22:42, Denis Magda  wrote:
> >>>
> >>> Petr,
> >>>
> >>> Thanks for pulling up the conversation.
> >>>
> >>> I still prefer us not to complicate the things and just remove "fabric"
> >>> from the *package name*. Use the easiest way possible.
> >>>
> >>> Personally, I don't care about Hadoop and would not suggest the
> community
> >>> wasting its time on it. So, just rename the suffixes/prefixes of the
> >> build
> >>> files the way you like to address Anton's concerns.
> >>>
> >>> --
> >>> Denis
> >>>
> >>>
> >>> On Thu, Jun 7, 2018 at 1:49 AM, Petr Ivanov 
> wrote:
> >>>
>  Igniters,
> 
> 
>  Lets define once again what should be done in this [1] task?
>  If current implementation is good, than I’ll update it to master and
> >> pass
>  for review.
> 
>  Yet, there is other part of the task which concerns our build server
> — I
>  assume that almost all our build configurations will fail due to name
>  change and there is no simple way of updating configurations other
> then
>  merge task to master and start fixing failing builds.
> 
> 
>  [1] https://issues.apache.org/jira/browse/IGNITE-7251
> 
> 
> 
> > On 10 Feb 2018, at 01:56, Denis Magda  wrote:
> >
> >> I don't think we necessarily need to remove 'fabric' word from every
>  file
> >> in the project, we just need to rename the name of downloadable
> >> package.
> >
> > Couldn’t say it better than you, Val. Thanks for pitching in :) This
> is
>  exactly what the ticket is about.
> >
> > —
> > Denis
> >
> >> On Feb 9, 2018, at 11:53 AM, Valentin Kulichenko <
>  valentin.kuliche...@gmail.com> wrote:
> >>
> >> Anton,
> >>
> >> I don't think we necessarily need to remove 'fabric' word from every
>  file
> >> in the project, we just need to rename the name of downloadable
>  package. Is
> >> there any other place where 'fabric' is exposed to the user?
> >>
> >> If that's the case, it should not be a big change, no?
> >>
> >> -Val
> >>
> >> On Fri, Feb 9, 2018 at 3:49 AM, Anton Vinogradov <
>  avinogra...@gridgain.com>
> >> wrote:
> >>
> >>> Denis,
> >>>
> >>> You're proposing changes without viewing a code :)
> >>>
> >>>
> >>> On Thu, Feb 8, 2018 at 10:07 PM, Denis Magda 
>  wrote:
> >>>
>  Anton,
> 
>  What’s wrong if we just go ahead and:
>  - replace “fabric” with “ignite”
>  - replace “hadoop” with “ignite-hadoop"
> 
>  —
>  Denis
> 
> > On Feb 8, 2018, at 1:51 AM, Anton Vinogradov <
>  avinogra...@gridgain.com
> 
>  wrote:
> >
> > Denis,
> >
> > "hadoop" and "fabric" words work on same engine.
> >
> > We have special assembly desctiptors, for example:
> > dependencies-fabric.xml
> > dependencies-fabric-lgpl.xml
> > dependencies-hadoop.xml
> > release-base.xml
> > release-fabric.xml
> > release-fabric-base.xml
> > release-fabric-lgpl.xml
> > release-hadoop.xml
> >
> > So, I'ts impossible for now to remove "fabric" without "hadoop"
> >>> removal.
> > Only one case is to 

Re: Removing "fabric" from Ignite binary package name

[Petr Ivanov]

> On 7 Jun 2018, at 23:04, Denis Magda  wrote:
> 
> I'm fine with the suggested approach.

With which one — current implementation in issue?


> However, not sure we need to update
> all the branches. Can't branch owners just pull the changes back from
> master if the plan to merge back later?

Of course, we as an initiative group of this issue should do nothing, it will 
lie on shoulders of developers.


> 
> --
> Denis
> 
> On Thu, Jun 7, 2018 at 12:57 PM, Petr Ivanov  wrote:
> 
>> Denis,
>> 
>> 
>> The most simple approach — repack and rearchive binary archive after
>> release build, however that would not resolve the problem globally (and
>> will require fixing every build configuration we have on TeamCity).
>> Current approach implemented in task — creates already correct folder and
>> binary archive name, but old name (with -fabric-) is used in almost every
>> build configuration too and merge code to master will require to:
>>1. quickly fix all of them (can be solved by preliminary preparations
>> — searching for -fabric- usages in build configuration);
>>2. update all branches to master because otherwise old branch will
>> stop building.
>> 
>> WDYT?
>> 
>> 
>> 
>>> On 7 Jun 2018, at 22:42, Denis Magda  wrote:
>>> 
>>> Petr,
>>> 
>>> Thanks for pulling up the conversation.
>>> 
>>> I still prefer us not to complicate the things and just remove "fabric"
>>> from the *package name*. Use the easiest way possible.
>>> 
>>> Personally, I don't care about Hadoop and would not suggest the community
>>> wasting its time on it. So, just rename the suffixes/prefixes of the
>> build
>>> files the way you like to address Anton's concerns.
>>> 
>>> --
>>> Denis
>>> 
>>> 
>>> On Thu, Jun 7, 2018 at 1:49 AM, Petr Ivanov  wrote:
>>> 
 Igniters,
 
 
 Lets define once again what should be done in this [1] task?
 If current implementation is good, than I’ll update it to master and
>> pass
 for review.
 
 Yet, there is other part of the task which concerns our build server — I
 assume that almost all our build configurations will fail due to name
 change and there is no simple way of updating configurations other then
 merge task to master and start fixing failing builds.
 
 
 [1] https://issues.apache.org/jira/browse/IGNITE-7251
 
 
 
> On 10 Feb 2018, at 01:56, Denis Magda  wrote:
> 
>> I don't think we necessarily need to remove 'fabric' word from every
 file
>> in the project, we just need to rename the name of downloadable
>> package.
> 
> Couldn’t say it better than you, Val. Thanks for pitching in :) This is
 exactly what the ticket is about.
> 
> —
> Denis
> 
>> On Feb 9, 2018, at 11:53 AM, Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:
>> 
>> Anton,
>> 
>> I don't think we necessarily need to remove 'fabric' word from every
 file
>> in the project, we just need to rename the name of downloadable
 package. Is
>> there any other place where 'fabric' is exposed to the user?
>> 
>> If that's the case, it should not be a big change, no?
>> 
>> -Val
>> 
>> On Fri, Feb 9, 2018 at 3:49 AM, Anton Vinogradov <
 avinogra...@gridgain.com>
>> wrote:
>> 
>>> Denis,
>>> 
>>> You're proposing changes without viewing a code :)
>>> 
>>> 
>>> On Thu, Feb 8, 2018 at 10:07 PM, Denis Magda 
 wrote:
>>> 
 Anton,
 
 What’s wrong if we just go ahead and:
 - replace “fabric” with “ignite”
 - replace “hadoop” with “ignite-hadoop"
 
 —
 Denis
 
> On Feb 8, 2018, at 1:51 AM, Anton Vinogradov <
 avinogra...@gridgain.com
 
 wrote:
> 
> Denis,
> 
> "hadoop" and "fabric" words work on same engine.
> 
> We have special assembly desctiptors, for example:
> dependencies-fabric.xml
> dependencies-fabric-lgpl.xml
> dependencies-hadoop.xml
> release-base.xml
> release-fabric.xml
> release-fabric-base.xml
> release-fabric-lgpl.xml
> release-hadoop.xml
> 
> So, I'ts impossible for now to remove "fabric" without "hadoop"
>>> removal.
> Only one case is to make some ditry hack, but that's not a good
>> idea.
> 
> On Thu, Feb 8, 2018 at 11:29 AM, Sergey Kozlov <
>> skoz...@gridgain.com
> 
 wrote:
> 
>> +1 hadoop accelerator removing for AI 2.5
>> 
>> Also probably IGFS should be either removed or refactored, e.g.
 create
 FS
>> directly over the data region without using "cache" entity as an
>> intermidiate stage
>> 
>> On Thu, Feb 8, 2018 at 2:13 AM, Denis Magda 
>>> wrote:
>> 
>>> Anton,
>>> 
>>> I don’t get how the hadoop editions 

Re: Removing "fabric" from Ignite binary package name

[Denis Magda]

I'm fine with the suggested approach. However, not sure we need to update
all the branches. Can't branch owners just pull the changes back from
master if the plan to merge back later?

--
Denis

On Thu, Jun 7, 2018 at 12:57 PM, Petr Ivanov  wrote:

> Denis,
>
>
> The most simple approach — repack and rearchive binary archive after
> release build, however that would not resolve the problem globally (and
> will require fixing every build configuration we have on TeamCity).
> Current approach implemented in task — creates already correct folder and
> binary archive name, but old name (with -fabric-) is used in almost every
> build configuration too and merge code to master will require to:
> 1. quickly fix all of them (can be solved by preliminary preparations
> — searching for -fabric- usages in build configuration);
> 2. update all branches to master because otherwise old branch will
> stop building.
>
> WDYT?
>
>
>
> > On 7 Jun 2018, at 22:42, Denis Magda  wrote:
> >
> > Petr,
> >
> > Thanks for pulling up the conversation.
> >
> > I still prefer us not to complicate the things and just remove "fabric"
> > from the *package name*. Use the easiest way possible.
> >
> > Personally, I don't care about Hadoop and would not suggest the community
> > wasting its time on it. So, just rename the suffixes/prefixes of the
> build
> > files the way you like to address Anton's concerns.
> >
> > --
> > Denis
> >
> >
> > On Thu, Jun 7, 2018 at 1:49 AM, Petr Ivanov  wrote:
> >
> >> Igniters,
> >>
> >>
> >> Lets define once again what should be done in this [1] task?
> >> If current implementation is good, than I’ll update it to master and
> pass
> >> for review.
> >>
> >> Yet, there is other part of the task which concerns our build server — I
> >> assume that almost all our build configurations will fail due to name
> >> change and there is no simple way of updating configurations other then
> >> merge task to master and start fixing failing builds.
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-7251
> >>
> >>
> >>
> >>> On 10 Feb 2018, at 01:56, Denis Magda  wrote:
> >>>
>  I don't think we necessarily need to remove 'fabric' word from every
> >> file
>  in the project, we just need to rename the name of downloadable
> package.
> >>>
> >>> Couldn’t say it better than you, Val. Thanks for pitching in :) This is
> >> exactly what the ticket is about.
> >>>
> >>> —
> >>> Denis
> >>>
>  On Feb 9, 2018, at 11:53 AM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com> wrote:
> 
>  Anton,
> 
>  I don't think we necessarily need to remove 'fabric' word from every
> >> file
>  in the project, we just need to rename the name of downloadable
> >> package. Is
>  there any other place where 'fabric' is exposed to the user?
> 
>  If that's the case, it should not be a big change, no?
> 
>  -Val
> 
>  On Fri, Feb 9, 2018 at 3:49 AM, Anton Vinogradov <
> >> avinogra...@gridgain.com>
>  wrote:
> 
> > Denis,
> >
> > You're proposing changes without viewing a code :)
> >
> >
> > On Thu, Feb 8, 2018 at 10:07 PM, Denis Magda 
> >> wrote:
> >
> >> Anton,
> >>
> >> What’s wrong if we just go ahead and:
> >> - replace “fabric” with “ignite”
> >> - replace “hadoop” with “ignite-hadoop"
> >>
> >> —
> >> Denis
> >>
> >>> On Feb 8, 2018, at 1:51 AM, Anton Vinogradov <
> >> avinogra...@gridgain.com
> >>
> >> wrote:
> >>>
> >>> Denis,
> >>>
> >>> "hadoop" and "fabric" words work on same engine.
> >>>
> >>> We have special assembly desctiptors, for example:
> >>> dependencies-fabric.xml
> >>> dependencies-fabric-lgpl.xml
> >>> dependencies-hadoop.xml
> >>> release-base.xml
> >>> release-fabric.xml
> >>> release-fabric-base.xml
> >>> release-fabric-lgpl.xml
> >>> release-hadoop.xml
> >>>
> >>> So, I'ts impossible for now to remove "fabric" without "hadoop"
> > removal.
> >>> Only one case is to make some ditry hack, but that's not a good
> idea.
> >>>
> >>> On Thu, Feb 8, 2018 at 11:29 AM, Sergey Kozlov <
> skoz...@gridgain.com
> >>>
> >> wrote:
> >>>
>  +1 hadoop accelerator removing for AI 2.5
> 
>  Also probably IGFS should be either removed or refactored, e.g.
> >> create
> >> FS
>  directly over the data region without using "cache" entity as an
>  intermidiate stage
> 
>  On Thu, Feb 8, 2018 at 2:13 AM, Denis Magda 
> > wrote:
> 
> > Anton,
> >
> > I don’t get how the hadoop editions are related to this task. The
> >> project
> > is not named as “data fabric” for a while. Check up the site or
> >> docs.
> >
> > The “fabric” word is being removed from all over the places and
> >> needs
> >> to
> > be removed from the editions’ names.
> >
> 

[Article] Using Linear Regression with Apache Ignite

[Akmal Chaudhri]

Second article in a multi-part series:

https://www.gridgain.com/resources/blog/using-linear-regression-apacher-ignitetm

Feedback welcome.

Thank you.

Re: Service grid redesign

[Vyacheslav Daradur]

Hi Igniters, sorry for the delay in replying.

I going to finish the task [1] to the end of this month.

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

On Wed, May 16, 2018 at 10:57 PM, Vyacheslav Daradur
 wrote:
> Hi, Igniters!
>
> I had a discussion about the scope of work of IEP-17 with Denis and Pavel.
>
> To estimate the time I took 2 weeks for R during which I would do the task:
> https://issues.apache.org/jira/browse/IGNITE-8361
>
> Then I will inform the community about the planned work time.
>
>
> On Tue, May 8, 2018 at 9:50 PM, Vyacheslav Daradur  
> wrote:
>> Thanks, Denis! I assigned the task to myself.
>>
>> I going to start work next week.
>>
>> On Tue, May 8, 2018 at 7:50 PM, Denis Mekhanikov  
>> wrote:
>>> Hi Vyacheslav!
>>>
>>> Thanks for the enthusiasm!
>>> The first ticket to be implemented here is IGNITE-8361
>>> .
>>> I think, until this one is resolved, other tasks can't be started.
>>>
>>> Please assign it to yourself, if you feel confident enough.
>>> Feel free to ask for any help, if you need.
>>>
>>> For now it will be enough to perform service deployment and initialization
>>> in the discovery thread.
>>> Making it asynchronous will be our next step: IGNITE-8362
>>> 
>>>
>>> Denis
>>>
>>> вт, 24 апр. 2018 г. в 15:43, Vyacheslav Daradur :
>>>
 Hi, Denis M.,

 I'd like to pick up a ticket from IEP-17 next week.

 Could you please advise a ticket to start?

 On Tue, Apr 24, 2018 at 11:47 AM, Dmitriy Setrakyan
  wrote:
 > On Tue, Apr 24, 2018, 3:59 PM Denis Mekhanikov 
 > wrote:
 >
 >> Dmitriy,
 >>
 >> After the proposed changes are made the utility cache won't be needed at
 >> all.
 >>
 >
 > I was rather talking about prioritization. In my view, first and foremost
 > we must fix deployment before anything else.
 >
 > D.



 --
 Best Regards, Vyacheslav D.

>>
>>
>>
>> --
>> Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.

Re: Node.JS thin client: Node.JS thin client fails

[Pavel Petroshenko]

Thank, Vladimir.

Denis, confirming, AI 2.5 is not supported.

However, all the tests and examples happily pass on the latest master (as
of today). So please use it for testing.

Thanks,
p.


On Thu, Jun 7, 2018 at 12:33 AM, Vladimir Ozerov 
wrote:

> Denis,
>
> No, AI 2.5 is not supported.
>
> чт, 7 июня 2018 г. в 2:37, Denis Magda :
>
>> Pavel,
>>
>> I'm tried to run an SQL example following the prepared documentation:
>> https://apacheignite.readme.io/v2.5/docs/nodejs-thin-
>> client#section-examples
>>
>> Getting an exception below when execute `node SqlQueryEntriesExample.js`
>> example. Do we support Ignite 2.5 (using its binaries)? Do I need to use
>> Ignite master instead?
>>
>> [16:31:13,389][SEVERE][client-connector-#46][ClientListenerNioListener]
>> Failed to parse client request.
>>
>> class org.apache.ignite.binary.BinaryObjectException: Unexpected field
>> type
>> [pos=73, expected=String, actual=-1]
>>
>> at
>> org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(
>> BinaryReaderExImpl.java:1677)
>>
>> at
>> org.apache.ignite.internal.binary.BinaryReaderExImpl.
>> readString(BinaryReaderExImpl.java:1055)
>>
>> at
>> org.apache.ignite.internal.processors.platform.utils.
>> PlatformConfigurationUtils.readQueryEntity(PlatformConfigurationUtils.
>> java:500)
>>
>> at
>> org.apache.ignite.internal.processors.platform.client.cache.
>> ClientCacheConfigurationSerializer.read(ClientCacheConfigurationSerial
>> izer.java:352)
>>
>> at
>> org.apache.ignite.internal.processors.platform.client.cache.
>> ClientCacheGetOrCreateWithConfigurationRequest.(
>> ClientCacheGetOrCreateWithConfigurationRequest.java:46)
>>
>> at
>> org.apache.ignite.internal.processors.platform.client.
>> ClientMessageParser.decode(ClientMessageParser.java:336)
>>
>> at
>> org.apache.ignite.internal.processors.platform.client.
>> ClientMessageParser.decode(ClientMessageParser.java:220)
>>
>> at
>> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.
>> onMessage(ClientListenerNioListener.java:138)
>>
>> at
>> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.
>> onMessage(ClientListenerNioListener.java:44)
>>
>> at
>> org.apache.ignite.internal.util.nio.GridNioFilterChain$
>> TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>>
>> at
>> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.
>> proceedMessageReceived(GridNioFilterAdapter.java:109)
>>
>> at
>> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.
>> body(GridNioAsyncNotifyFilter.java:97)
>>
>> at
>> org.apache.ignite.internal.util.worker.GridWorker.run(
>> GridWorker.java:110)
>>
>> at
>> org.apache.ignite.internal.util.worker.GridWorkerPool$1.
>> run(GridWorkerPool.java:70)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1142)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> ThreadPoolExecutor.java:617)
>>
>> at java.lang.Thread.run(Thread.java:745)
>>
>

[GitHub] ignite pull request #4151: Ignite-8681: check if 8503 fix test issues.

[AMashenkov]

GitHub user AMashenkov opened a pull request:

https://github.com/apache/ignite/pull/4151

Ignite-8681: check if 8503 fix test issues.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8681-8503

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4151.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4151


commit c069f31c90a5b4be02d4d6b4b390f278fb6c98f3
Author: Andrey V. Mashenkov 
Date:   2018-06-01T15:51:37Z

WIP. Introduce expiry throttling.
Thread will avoid try to clean expired entries if recent try has finished 
with "nothing to clean".

commit 38e179c9d658aa7091770322d4698a70f434b8d5
Author: Andrey V. Mashenkov 
Date:   2018-06-01T17:14:06Z

WIP. Avoid useless unwindEvict try for caches with eagerTtl disabled.

commit 2fd31ed3b896f4a99e189af74c4d1ee5b32c2cc8
Author: Andrey V. Mashenkov 
Date:   2018-06-01T20:25:54Z

WIP. Minor

commit 50d9984ab8ba2dcda15f515568ec0fe6123c3a82
Author: Andrey V. Mashenkov 
Date:   2018-06-05T09:32:02Z

WIP.
Added per-cacheGroup unwind throttling.
Styles.

commit 4b38d9c4343e671f29880c8022cc9f17a8a3cdbc
Author: Andrey V. Mashenkov 
Date:   2018-06-06T09:09:42Z

Wip. Minors

commit 3507d89c513d84184d8401f46c2010260d43ad0f
Author: Andrey V. Mashenkov 
Date:   2018-06-06T09:13:54Z

Merge branch 'master' into ignite-8681

commit f9048aa0c288ac21b03811c00eadf1af363def93
Author: Andrey V. Mashenkov 
Date:   2018-06-06T09:54:22Z

Wip.
Disable throttling for in memory store.

commit f4ee6812cc136eba5b4aad526c30d615621bc674
Author: Andrey V. Mashenkov 
Date:   2018-06-06T10:49:01Z

Revert "Wip. Disable throttling for in memory store."

This reverts commit f9048aa

commit 2d24ff19a21fc40bdca2afd7ee02b584417c439a
Author: Andrey V. Mashenkov 
Date:   2018-06-06T12:28:18Z

IGNITE-8503: Fixed entry startVersion.

(cherry picked from commit f0259f6)




---

[jira] [Created] (IGNITE-8743) TcpCommunicationSpi hangs in rare circumstances on outgoing descriptor reservation.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-8743:
-

 Summary: TcpCommunicationSpi hangs in rare circumstances on 
outgoing descriptor reservation.
 Key: IGNITE-8743
 URL: https://issues.apache.org/jira/browse/IGNITE-8743
 Project: Ignite
  Issue Type: Bug
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov


Relevant stack trace:

{noformat}
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at 
org.apache.ignite.internal.util.nio.GridNioRecoveryDescriptor.reserve(GridNioRecoveryDescriptor.java:275)
- locked <0x7fca4b14f560> (a 
org.apache.ignite.internal.util.nio.GridNioRecoveryDescriptor)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3140)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2863)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2750)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2611)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2575)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1642)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1714)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1166)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:311)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:208)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.loadAsync(GridDhtColocatedCache.java:389)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.loadMissing(GridNearTxLocal.java:2506)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.checkMissed(GridNearTxLocal.java:3888)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:1927)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:197)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Ignite schedule module

[Alexey Kuznetsov]

Dima,

See https://issues.apache.org/jira/browse/IGNITE-5565

On Thu, Jun 7, 2018 at 10:09 PM, Dmitry Pavlov 
wrote:

> Hi Ilya, I appreciate you answer.
>
> Sincerely,
>
> чт, 7 июн. 2018 г. в 17:16, Ilya Kasnacheev :
>
> > Hello!
> >
> > This module depends on a library which is under LGPL.
> >
> > This means you will have to build this module yourself, deploy to your
> > local maven, to satisfly licences' terms. This is the reason it's not
> > published. There's ongoing discussion about replacing scheduler
> > implementation to one with less restrictive license, resume publishing
> this
> > module.
> >
> > Regards,
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-06-06 19:05 GMT+03:00 Dmitry Pavlov :
> >
> > > Hi Igniters,
> > >
> > > I've tried to use
> > >
> > > ignite.scheduler().scheduleLocal(this::checkFailures, "? * * * * *");
> > >
> > > Result is
> > > class org.apache.ignite.IgniteException: Current Ignite configuration
> > does
> > > not support schedule functionality (consider adding ignite-schedule
> > module
> > > to classpath).
> > > at
> > > org.apache.ignite.internal.processors.schedule.
> > > IgniteNoopScheduleProcessor.processorException(
> > > IgniteNoopScheduleProcessor.java:50)
> > >
> > > Maven repos does not contain this module.
> > > I guess ignite-schedule is not deployed:
> > >
> > > org.apache.maven.plugins
> > > maven-deploy-plugin
> > > 
> > > true
> > > 
> > >
> > > What should I do? Error message refers I should add unexistent module
> to
> > > classpath, but
> > > https://mvnrepository.com/artifact/org.apache.ignite/ignite-schedule
> is
> > > not
> > > available since 2015.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> >
>



-- 
Alexey Kuznetsov

Things To Do Before You Turn 30^W^WRelease 3.0

[Ilya Kasnacheev]

Hello!

Do we have an official subj list? Such as Wiki page or JIRA label?

Cause if we don't, we'll surely forget a lot of things and will have to
wait for 4.0.
We already did that with IGNITE_BINARY_SORT_OBJECT_FIELDS in 2.0 :(

I expect to have in this list breaking changes, and @Deprecated stuff to be
finally removed, and maybe unmaintained modules to be put to rest.

Regards,
-- 
Ilya Kasnacheev

Re: [oss-security] [CVE-2014-0114]: Apache Ignite is vulnerable to existing CVE-2014-0114

[Andrey Gura]

Hi,

I've looked to the problem and didn't see any problem with BeanUtils.
Only module that depends on BeanUtils is Cassandra cache store in
order to map POJO to CQL queries. Usages are only on Ignite side with
configured Cassandra cache store and can't exploit described
vulnerability from my point of view. All classes are already
accessible on Ignite node (so class loader is also accessible without
any exploites) and this classes don't exist on Cassandra side.

I also don't see any reason to include BeanUtils library into Ignite
.Net package because it never uses this library. Just a bug in build
procedure.

Thanks!

On Wed, Jun 6, 2018 at 7:08 PM, Denis Magda  wrote:
> Hello Tomas,
>
> We've just updated the version of Binutils because Ignite doesn't use this
> library directly. So we don't need to inject addBeanIntrospector call.
>
> Binutils are used by some dependencies like Cassandra. Let us confirm that
> the dependencies shouldn't be upgraded.
>
> --
> Denis
>
> On Wed, Jun 6, 2018 at 4:33 AM, Tomas Hoger  wrote:
>
>> Hi Denis!
>>
>> On Fri, 1 Jun 2018 10:16:50 -0700 Denis Magda wrote:
>>
>> > [CVE-2014-0114]: Apache Ignite is vulnerable to existing CVE-2014-0114
>> >
>> > Severity: Important
>> >
>> > Vendor: The Apache Software Foundation
>> >
>> > Versions Affected: Apache Ignite 2.4 or earlier
>> >
>> > Impact:
>> > An attacker can execute arbitrary code on Ignite nodes in the case
>> > when Ignite classpath contains arbitrary vulnerable classes.
>> >
>> > Description:
>> > Apache Ignite used commons-beanutils-1.8.3.jar library which did not
>> > suppress the class property, which allowed remote attackers to
>> > "manipulate" the ClassLoader and execute arbitrary code via the class
>> > parameter, as demonstrated by the passing of this parameter to the
>> > getClass method of the ActionForm object in Struts 1.
>>
>> This announcement is very light on details.  Would it be possible to
>> provide more details, ideally a link to the fix that was applied to
>> address this issue?
>>
>> Searching for more information, I found out that the upstream Jira
>> ticket for this issue should be:
>>
>> https://issues.apache.org/jira/browse/IGNITE-8472
>>
>> The ticket is non-public, but its content is leaked via a mailing list:
>>
>> https://www.mail-archive.com/search?l=issues%40ignite.
>> apache.org=subject%3AIGNITE-8472
>>
>> This has some important info, indicating that the problem (only?)
>> affects Ignite for .NET.  The reported problem basically seems to be:
>> Ignite for .NET bundles commons-beanutils 1.8.3 and that should be
>> upgraded to 1.9.2.  Looking into apache.ignite.2.4.0.nupkg and
>> apache.ignite.2.5.0.nupkg, I can see that commons-beanutils upgrade as
>> requested did happen in 2.5.0.
>>
>> Note that I do not see any commons-beanutils jar in
>> apache-ignite-fabric-2.4.0-bin.zip and
>> apache-ignite-fabric-2.5.0-bin.zip.  Are those, as well as source
>> distribution, considered unaffected?
>>
>> Now back to the CVE - I do not believe that your re-use of the old
>> CVE-2014-0114 is correct.  In the report, there was some ambiguity
>> whether Struts or Commons-BeanUtils should be blamed for the flaw,
>> however it seems to be explicit enough that the CVE-2014-0114 is for
>> Struts:
>>
>> http://openwall.com/lists/oss-security/2014/06/15/10
>>
>> As noted in the mail, the problem wasn't fixed in Commons-BeanUtils,
>> which only added mechanisms to make it easy for applications using
>> Commons-BeanUtils to easily disable processing of the "class"
>> property.  It did not even disable processing by default, as noted in
>> the release notes:
>>
>> http://commons.apache.org/proper/commons-beanutils/
>> javadocs/v1.9.2/RELEASE-NOTES.txt
>>
>> """
>> Release 1.9.2 mainly addresses a potential security issue when accessing
>> properties in an uncontrolled way. In a nutshell, if an application that
>> uses
>> Commons BeanUtils passes property paths from an external source directly to
>> the getProperty() method of BeanUtilsBean, an attacker can access the class
>> loader via the class property available on all Java objects.
>>
>> In version 1.9.2 now a special BeanIntrospector class was added which
>> allows
>> suppressing this property. Note that this BeanIntrospector is NOT enabled
>> by
>> default! Commons BeanUtils is a low-level library, and on this layer it
>> cannot
>> be decided whether access to a certain property is legal or not. Therefore,
>> an application has to activate this suppressing BeanIntrospector
>> explicitly.
>> This can be done with the following lines of code:
>>
>> BeanUtilsBean bub = new BeanUtilsBean();
>> bub.getPropertyUtils().addBeanIntrospector(
>> SuppressPropertiesBeanIntrospector.SUPPRESS_CLASS);
>>
>> Now all access to properties has to be done via the specially configured
>> BeanUtilsBean instance. More information about this issue can be found at
>> https://issues.apache.org/jira/browse/BEANUTILS-463 or in section 2.5
>> of the user's guide.
>> """
>>
>> 

[GitHub] ignite pull request #4150: IGNITE-8509 Fix cache 6 suite flaky tests.

[ascherbakoff]

GitHub user ascherbakoff opened a pull request:

https://github.com/apache/ignite/pull/4150

IGNITE-8509 Fix cache 6 suite flaky tests.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8509

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4150.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4150


commit e1b4ff58dd522d6b6c5ac557be437576ded1
Author: Aleksei Scherbakov 
Date:   2018-06-07T16:14:49Z

IGNITE-8509 Fixed race in TxRollbackAsyncTest.

commit 607b091da484c6fb1c07092880f51e1d34292442
Author: Aleksei Scherbakov 
Date:   2018-06-07T16:19:43Z

IGNITE-8509 Fixed race in TxRollbackAsyncTest.




---

[GitHub] ignite pull request #4149: IGNITE-8713 Spring Data dependencies upgraded

[agura]

GitHub user agura opened a pull request:

https://github.com/apache/ignite/pull/4149

IGNITE-8713 Spring Data dependencies upgraded



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agura/incubator-ignite ignite-8713

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4149.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4149


commit 5e9babc210ad0b22fc03442da86cd6a36360f907
Author: Andrey Gura 
Date:   2018-06-07T16:04:46Z

IGNITE-8713 Spring Data dependencies upgraded




---

Re: Ignite schedule module

[Dmitry Pavlov]

Hi Ilya, I appreciate you answer.

Sincerely,

чт, 7 июн. 2018 г. в 17:16, Ilya Kasnacheev :

> Hello!
>
> This module depends on a library which is under LGPL.
>
> This means you will have to build this module yourself, deploy to your
> local maven, to satisfly licences' terms. This is the reason it's not
> published. There's ongoing discussion about replacing scheduler
> implementation to one with less restrictive license, resume publishing this
> module.
>
> Regards,
>
> --
> Ilya Kasnacheev
>
> 2018-06-06 19:05 GMT+03:00 Dmitry Pavlov :
>
> > Hi Igniters,
> >
> > I've tried to use
> >
> > ignite.scheduler().scheduleLocal(this::checkFailures, "? * * * * *");
> >
> > Result is
> > class org.apache.ignite.IgniteException: Current Ignite configuration
> does
> > not support schedule functionality (consider adding ignite-schedule
> module
> > to classpath).
> > at
> > org.apache.ignite.internal.processors.schedule.
> > IgniteNoopScheduleProcessor.processorException(
> > IgniteNoopScheduleProcessor.java:50)
> >
> > Maven repos does not contain this module.
> > I guess ignite-schedule is not deployed:
> >
> > org.apache.maven.plugins
> > maven-deploy-plugin
> > 
> > true
> > 
> >
> > What should I do? Error message refers I should add unexistent module to
> > classpath, but
> > https://mvnrepository.com/artifact/org.apache.ignite/ignite-schedule is
> > not
> > available since 2015.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
>

[jira] [Created] (IGNITE-8742) Direct IO 2 suite is timed out by out of disk space failure emulation test: WAL manager failure does not stoped.

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-8742:
--

 Summary: Direct IO 2 suite is timed out by out of disk space 
failure emulation test: WAL manager failure does not stoped.
 Key: IGNITE-8742
 URL: https://issues.apache.org/jira/browse/IGNITE-8742
 Project: Ignite
  Issue Type: Test
  Components: persistence
Reporter: Dmitriy Pavlov


Test 
org.apache.ignite.internal.processors.cache.persistence.IgniteNativeIoWalFlushFsyncSelfTest#testFailAfterStart
emulates problem with disc space using exception.

In direct IO environment real IO with disk is performed, tmpfs is not used.

Sometimes this error can come from rollover() of segment, failure handler 
reacted accordingly.
{noformat}
detected. Will be handled accordingly to configured handler [hnd=class 
o.a.i.failure.StopNodeFailureHandler, failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable to 
write]]
class org.apache.ignite.internal.pagemem.wal.StorageException: Unable to write
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.writeBuffer(FsyncModeFileWriteAheadLogManager.java:2964)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flush(FsyncModeFileWriteAheadLogManager.java:2640)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flush(FsyncModeFileWriteAheadLogManager.java:2572)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flushOrWait(FsyncModeFileWriteAheadLogManager.java:2525)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.close(FsyncModeFileWriteAheadLogManager.java:2795)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.access$700(FsyncModeFileWriteAheadLogManager.java:2340)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager.rollOver(FsyncModeFileWriteAheadLogManager.java:1029)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager.log(FsyncModeFileWriteAheadLogManager.java:673)
{noformat}

But test seems to be not able to stop, node stopper thread tries to stop cache, 
flush WAL. flush wait for rollover, which will never happen.
{noformat}
Thread [name="node-stopper", id=2836, state=WAITING, blockCnt=7, waitCnt=9]
Lock 
[object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@47f6473,
 ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
at o.a.i.i.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7473)
at 
o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flushOrWait(FsyncModeFileWriteAheadLogManager.java:2546)
at 
o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.fsync(FsyncModeFileWriteAheadLogManager.java:2750)
at 
o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.access$2000(FsyncModeFileWriteAheadLogManager.java:2340)
at 
o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager.flush(FsyncModeFileWriteAheadLogManager.java:699)
at 
o.a.i.i.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1243)
at 
o.a.i.i.processors.cache.GridCacheProcessor.stopCaches(GridCacheProcessor.java:969)
at 
o.a.i.i.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:943)
at o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2289)
at o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2167)
at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
- locked o.a.i.i.IgnitionEx$IgniteNamedInstance@90f6bfd
at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
at o.a.i.i.IgnitionEx.stop(IgnitionEx.java:372)
at 
o.a.i.failure.StopNodeFailureHandler$1.run(StopNodeFailureHandler.java:36)
at java.lang.Thread.run(Thread.java:748)
{noformat}


It seems invalidating environment of WAL manager is not working propertly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8741) [ML] Make a tutorial for data preprocessing

[Yury Babak (JIRA)]

Yury Babak created IGNITE-8741:
--

 Summary: [ML] Make a tutorial for data preprocessing
 Key: IGNITE-8741
 URL: https://issues.apache.org/jira/browse/IGNITE-8741
 Project: Ignite
  Issue Type: Wish
  Components: ml
Reporter: Yury Babak
Assignee: Aleksey Zinoviev
 Fix For: 2.6






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8740:
---

 Summary: Support reuse of already initialized Ignite in 
IgniteSpringBean
 Key: IGNITE-8740
 URL: https://issues.apache.org/jira/browse/IGNITE-8740
 Project: Ignite
  Issue Type: Improvement
  Components: spring
Affects Versions: 2.4
Reporter: Ilya Kasnacheev


See 
http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724
 (there's patch available)

The idea is to introduce a workaround for users hit by IGNITE-6555, which 
unfortunately broke some scenarios.





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: NodeJS thin client: full API

[Pavel Petroshenko]

Hi Ivan,

Thanks for taking care of this. I will give the scripts a try and get back
to you if any questions.

Could you please update the JIRA ticket [1] so that we keep it up-to-date.

Thanks!
p.

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


On Thu, Jun 7, 2018 at 4:47 AM, Иван Артюхов  wrote:

> Hi Igniters!
>
> I've prepared two scripts to benchmark the throughput of Node.JS thin
> client using 'atomic-put' operations [1]. They work in the following way:
> - Main script 'bench-starter.js' starts the given number of thin clients as
> sub-processes. AFAIK, Node.JS is one-threaded so we should fork clients
> from some parent process to make the benchmark fully utilize all CPU cores.
> - The Node.JS thin client script 'CachePut.js' uses the 'sandra' benchmark
> package [2] which is simple and suites the asynchronous logic of the
> Node.JS thin client package itself. Every second 'CachePut.js' calculates
> and prints on screen the average throughput for current iteration.
>
> I tried to make the logic of 'CachePut.js' to be close to Java thin client
> benchmarks for Yardstick framework available in a pull request [3]. Because
> I'm not a Node.JS expert, it would be great if someone could review these
> two scripts and compare them with Java thin client benchmarks. Specifically
> the 'IgniteThinPutBenchmark.java' benchmark which also does atomic puts.
> Any
> feedback is greatly appreciated!
>
> [1] https://gist.github.com/iartiukhov/c02385d265330e2c9192931759616f95
> [2] https://www.npmjs.com/package/sandra
> [3] https://github.com/apache/ignite/pull/3942
>
> Thanks,
> Ivan
>
>
> вт, 29 мая 2018 г. в 20:05, Denis Magda :
>
> > Hi Pavel,
> >
> > Thanks for prompt improvements. I'll check them this week.
> >
> > --
> > Denis
> >
> > On Sun, May 27, 2018 at 5:04 PM, Pavel Petroshenko <
> pa...@petroshenko.com>
> > wrote:
> >
> > > Hi Denis,
> > >
> > > Thanks for your feedback on the documentation! I addressed all your
> > > comments from https://issues.apache.org/jira/browse/IGNITE-8589.
> > >
> > > Please let me know if you have any questions.
> > >
> > > Thanks,
> > > p.
> > >
> > >
> > > On Thu, May 24, 2018 at 12:42 PM, Pavel Petroshenko <
> > pa...@petroshenko.com
> > > >
> > > wrote:
> > >
> > > > Hi Denis,
> > > >
> > > > That's a good point, thanks. This should be a part of the "Usage"
> > > section.
> > > > I'll follow up in JIRA.
> > > >
> > > > p.
> > > >
> > > > On Thu, May 24, 2018 at 10:49 AM, Denis Magda 
> > wrote:
> > > >
> > > >> Pavel,
> > > >>
> > > >> Recalled that we've not described how to authenticate and set up SSL
> > > from
> > > >> the client side. Please consider this for the doc. Left some notes
> in
> > > the
> > > >> JIRA.
> > > >>
> > > >> --
> > > >> Denis
> > > >>
> > > >> On Wed, May 23, 2018 at 12:25 PM, Denis Magda 
> > > wrote:
> > > >>
> > > >> > Alexey, Pavel,
> > > >> >
> > > >> > I've done a preliminary review of the doc and moved it to the
> > > readme.io
> > > >> > page:
> > > >> > https://apacheignite.readme.io/v2.4/docs/nodejs-thin-client
> > > >> >
> > > >> > The page is hidden. I'll grant you access to readme so that you
> can
> > > >> update
> > > >> > the doc taking my suggestions into account:
> > > >> > https://issues.apache.org/jira/browse/IGNITE-8589
> > > >> >
> > > >> > --
> > > >> > Denis
> > > >> >
> > > >> >
> > > >> > On Mon, May 21, 2018 at 6:39 PM, Alexey Kuznetsov <
> > > >> akuznet...@apache.org>
> > > >> > wrote:
> > > >> >
> > > >> >> Hi,
> > > >> >>
> > > >> >> FYI, HZ also has NodeJs client: https://github.com/
> > > >> >> hazelcast/hazelcast-nodejs-client
> > > >> >> May be it is worth to take a look?
> > > >> >>
> > > >> >> --
> > > >> >> Alexey Kuznetsov
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: Platform .NET add to RunAll Basic suite

[Ilya Kasnacheev]

Hello!

I would agree to modifying some tests to check for this case in Java if you
prop up my Orphaned Tests PR :)

Regards,

-- 
Ilya Kasnacheev

2018-05-31 13:58 GMT+03:00 Dmitry Pavlov :

> Hi Pavel,
>
> Unfortunately the time that I now can dedicate to the community is very
> limited.
>
> I would be happy if Ilya K. agrees to make a separate test in Java.
>
> Best Regards,
> Pavlov Dmitry
>
> вт, 29 мая 2018 г. в 21:19, Pavel Tupitsyn :
>
> > Sorry for the late notice, but there are no tests in that PR, so the
> > regression is possible again.
> > Let's not rely on .NET tests for this.
> >
> > On Tue, May 29, 2018 at 5:14 PM, Dmitry Pavlov 
> > wrote:
> >
> > > Hi Igniters, Pavel, Ilya,
> > >
> > > Ilya's fix is merged to master. Ilya, thank you for contribution.
> > >
> > > Tests seems to be passing now. The only one left
> > > is DataRegionMetricsTest.TestMemoryMetrics, probably failed by
> > > IGNITE-8583.
> > >
> > > And I've also added dependency from Run All Basic to Platform .NET, so
> > > these tests will be executed on per-commit basis.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > вт, 29 мая 2018 г. в 10:49, Pavel Tupitsyn :
> > >
> > > > Dmitry, the fix looks good to me, I would appreciate if you merge it.
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On Tue, May 29, 2018 at 12:02 AM, Dmitry Pavlov <
> dpavlov@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Pavel,
> > > > >
> > > > > Thank you for pointing to this. We've noticed that, and Ilya K. has
> > > > already
> > > > > prepared the fix,
> > > > > https://issues.apache.org/jira/browse/IGNITE-8604
> > > > > https://github.com/apache/ignite/pull/4072
> > > > >
> > > > > If you have some time you can apply the PR, or I will merge it
> later.
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > пн, 28 мая 2018 г. в 23:45, Pavel Tupitsyn :
> > > > >
> > > > > > Hi Dmirty,
> > > > > >
> > > > > > IGNITE-5789 merge [1] introduces this bug:
> > > > > >
> > > > > > Additional cache is being started from a template (cache name
> ends
> > > with
> > > > > *).
> > > > > > Normally template caches are only started when a cache with
> > matching
> > > > name
> > > > > > has been requested.
> > > > > >
> > > > > > Pavel
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > > https://github.com/apache/ignite/commit/
> > > d821d0999749a1be318a2106d73654
> > > > > 2272a42ab0
> > > > > >
> > > > > > On Fri, May 25, 2018 at 8:23 PM, Dmitriy Setrakyan <
> d...@gridgain.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > Hi Pavel, can you please respond here?
> > > > > > >
> > > > > > > -- Forwarded message --
> > > > > > > From: Dmitry Pavlov 
> > > > > > > Date: Fri, May 25, 2018 at 5:08 AM
> > > > > > > Subject: Platform .NET add to RunAll Basic suite
> > > > > > > To: dev 
> > > > > > >
> > > > > > >
> > > > > > > Hi Igniters,
> > > > > > >
> > > > > > > recently we've got 60-70 new test failures in .NET
> > > > > > >
> > > > > > > For me it is not simple to say which commit has failed build,
> so
> > I
> > > > > > suggest
> > > > > > > the following:
> > > > > > >
> > > > > > > 1. Add Platform .NET tests to run-all basic, it will be started
> > by
> > > > > > > per-VCS-commit basis. Per commit run will indicate change which
> > > > failed
> > > > > > the
> > > > > > > build.
> > > > > > >
> > > > > > > 2. Find out and mute flaky tests with tickets (if any).
> > > > > > >
> > > > > > > WDYT?
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[GitHub] ignite pull request #4143: IGNITE-8668 K-fold cross validation of models

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4143


---

[GitHub] ignite pull request #4148: IGNITE-8739 cherry picked from GG-13874 Implement...

[akalash]

GitHub user akalash opened a pull request:

https://github.com/apache/ignite/pull/4148

IGNITE-8739 cherry picked from GG-13874 Implement WA for TCP communic…

…ation related to hanging on descriptor reservation.

(cherry picked from commit f2a6133)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8739

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4148.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4148


commit e25ef8f076ce01a43b68eee20556041757d003e8
Author: Aleksei Scherbakov 
Date:   2018-05-31T08:01:30Z

IGNITE-8739 cherry picked from GG-13874 Implement WA for TCP communication 
related to hanging on descriptor reservation.

(cherry picked from commit f2a6133)




---

[jira] [Created] (IGNITE-8739) Implement WA for TCP communication related to hanging on descriptor reservation

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-8739:
-

 Summary: Implement WA for TCP communication related to hanging on 
descriptor reservation
 Key: IGNITE-8739
 URL: https://issues.apache.org/jira/browse/IGNITE-8739
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4147: IGNITE-8565 Client marshalling improvements

[agura]

GitHub user agura opened a pull request:

https://github.com/apache/ignite/pull/4147

IGNITE-8565 Client marshalling improvements



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agura/incubator-ignite ignite-8565

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4147.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4147


commit 497f6a3cbd8985371f85bfea9504719f6a7bafb9
Author: Andrey Gura 
Date:   2018-06-07T12:53:11Z

IGNITE-8565 Client marshalling improvements




---

[jira] [Created] (IGNITE-8738) Improve coordinator change information

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8738:


 Summary: Improve coordinator change information
 Key: IGNITE-8738
 URL: https://issues.apache.org/jira/browse/IGNITE-8738
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8737) Improve checkpoint logging information

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8737:


 Summary: Improve checkpoint logging information
 Key: IGNITE-8737
 URL: https://issues.apache.org/jira/browse/IGNITE-8737
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8736) Add transaction label to CU.txString() method output

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8736:


 Summary: Add transaction label to CU.txString() method output
 Key: IGNITE-8736
 URL: https://issues.apache.org/jira/browse/IGNITE-8736
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8735) Metastorage creates its own index partition

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8735:
--

 Summary: Metastorage creates its own index partition
 Key: IGNITE-8735
 URL: https://issues.apache.org/jira/browse/IGNITE-8735
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Ivan Rakov
 Fix For: 2.6


By design, all metastorage data should be stored in single partition with index 
= 0. However, allocatePageNoReuse is not overriden in MetastorageTree, which 
cause allocation of extra pages for the tree in index partition.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: NodeJS thin client: full API

[Иван Артюхов]

Hi Igniters!

I've prepared two scripts to benchmark the throughput of Node.JS thin
client using 'atomic-put' operations [1]. They work in the following way:
- Main script 'bench-starter.js' starts the given number of thin clients as
sub-processes. AFAIK, Node.JS is one-threaded so we should fork clients
from some parent process to make the benchmark fully utilize all CPU cores.
- The Node.JS thin client script 'CachePut.js' uses the 'sandra' benchmark
package [2] which is simple and suites the asynchronous logic of the
Node.JS thin client package itself. Every second 'CachePut.js' calculates
and prints on screen the average throughput for current iteration.

I tried to make the logic of 'CachePut.js' to be close to Java thin client
benchmarks for Yardstick framework available in a pull request [3]. Because
I'm not a Node.JS expert, it would be great if someone could review these
two scripts and compare them with Java thin client benchmarks. Specifically
the 'IgniteThinPutBenchmark.java' benchmark which also does atomic puts. Any
feedback is greatly appreciated!

[1] https://gist.github.com/iartiukhov/c02385d265330e2c9192931759616f95
[2] https://www.npmjs.com/package/sandra
[3] https://github.com/apache/ignite/pull/3942

Thanks,
Ivan


вт, 29 мая 2018 г. в 20:05, Denis Magda :

> Hi Pavel,
>
> Thanks for prompt improvements. I'll check them this week.
>
> --
> Denis
>
> On Sun, May 27, 2018 at 5:04 PM, Pavel Petroshenko 
> wrote:
>
> > Hi Denis,
> >
> > Thanks for your feedback on the documentation! I addressed all your
> > comments from https://issues.apache.org/jira/browse/IGNITE-8589.
> >
> > Please let me know if you have any questions.
> >
> > Thanks,
> > p.
> >
> >
> > On Thu, May 24, 2018 at 12:42 PM, Pavel Petroshenko <
> pa...@petroshenko.com
> > >
> > wrote:
> >
> > > Hi Denis,
> > >
> > > That's a good point, thanks. This should be a part of the "Usage"
> > section.
> > > I'll follow up in JIRA.
> > >
> > > p.
> > >
> > > On Thu, May 24, 2018 at 10:49 AM, Denis Magda 
> wrote:
> > >
> > >> Pavel,
> > >>
> > >> Recalled that we've not described how to authenticate and set up SSL
> > from
> > >> the client side. Please consider this for the doc. Left some notes in
> > the
> > >> JIRA.
> > >>
> > >> --
> > >> Denis
> > >>
> > >> On Wed, May 23, 2018 at 12:25 PM, Denis Magda 
> > wrote:
> > >>
> > >> > Alexey, Pavel,
> > >> >
> > >> > I've done a preliminary review of the doc and moved it to the
> > readme.io
> > >> > page:
> > >> > https://apacheignite.readme.io/v2.4/docs/nodejs-thin-client
> > >> >
> > >> > The page is hidden. I'll grant you access to readme so that you can
> > >> update
> > >> > the doc taking my suggestions into account:
> > >> > https://issues.apache.org/jira/browse/IGNITE-8589
> > >> >
> > >> > --
> > >> > Denis
> > >> >
> > >> >
> > >> > On Mon, May 21, 2018 at 6:39 PM, Alexey Kuznetsov <
> > >> akuznet...@apache.org>
> > >> > wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> FYI, HZ also has NodeJs client: https://github.com/
> > >> >> hazelcast/hazelcast-nodejs-client
> > >> >> May be it is worth to take a look?
> > >> >>
> > >> >> --
> > >> >> Alexey Kuznetsov
> > >> >>
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>

[jira] [Created] (IGNITE-8734) Visor metrics don't include transactions started on client node

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8734:


 Summary: Visor metrics don't include transactions started on 
client node
 Key: IGNITE-8734
 URL: https://issues.apache.org/jira/browse/IGNITE-8734
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov


Problem arizes from method VisorNodeDataCollectorJob#caches().
When we are collecting metrics in this method, client node is filtered out by
VisorNodeDataCollectorJob#proxyCache().



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8733) Add benchmarks for NodeJS thin client

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-8733:


 Summary: Add benchmarks for NodeJS thin client
 Key: IGNITE-8733
 URL: https://issues.apache.org/jira/browse/IGNITE-8733
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.5
Reporter: Ilya Suntsov


We have several benchmarks for Java thin client 
([PR|https://github.com/apache/ignite/pull/3942]). The same set should be 
implemented on NodeJS



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3933: Ignite 8186 - test base for sql feature coverage

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3933


---

[jira] [Created] (IGNITE-8732) SQL: REPLICATED cache cannot be left-joined to PARTITIONED

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8732:
---

 Summary: SQL: REPLICATED cache cannot be left-joined to PARTITIONED
 Key: IGNITE-8732
 URL: https://issues.apache.org/jira/browse/IGNITE-8732
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.5
Reporter: Vladimir Ozerov


*Steps to reproduce*
# Run 
{{org.apache.ignite.sqltests.ReplicatedSqlTest#testLeftJoinReplicatedPartitioned}}
# Observe that we have 2x results on 2-node cluster

*Root Cause*
{{left LEFT JOIN right ON cond}} operation assumes full scan of of a left 
expression. Currently we perform this scan on every node and then simply merge 
results on reducer. Two nodes, two scans of {{REPLICATED}} cache, 2x results.

*Solution*
We may consider several solutions. Deeper analysis is required to understand 
which is the right one.

# Perform deduplication on reducer
# Treat {{REPLICATED}} cache as {{PARTITIONED}}. Essentially, we just need to 
pass proper backup filter. But what if {{REPLICATED}} cache spans more nodes 
than {{PARTITIONED}}? We cannot rely on primary/backup in this case
# Implement additional execution phase as follows: 
{code}
SELECT left.cols, right.cols FROM left INNER JOIN right ON cond; // Get common 
part
UNION
SELECT left.cols, [NULL].cols FROM left WHERE left.id NOT IN ([ids from the 
first phase])
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Apache Ignite 2.6 - Packages roadmap

[Petr Ivanov]

Here are the results of checks:


1. Ubuntu. Running Apache Ignite as a stand-alone application works fine, I 
have successful connections to another Apache Ignite node running under 
VirtualBox CentOS.
NOTE: connectivity started working only after creation of “allow all incoming 
connections” rule in Windows Defender Firewall.

2. Debian. Running Apache Ignite as a stand-alone application works fine, I 
have successful connections to another Apache Ignite node running under 
VirtualBox CentOS.
NOTE: in addition to Ubuntu’s NOTE, it is required to install dirmngr program 
for apt-key be able to download gpg keys over network (this NOTE can be added 
to documentation + I can add dependency to DEB package in next release).

3. SUSE. Has neither APT no YUM commands. RPM package can be installed via rpm 
-i command, but I think that this case is out of Apache Ignite 2.5 scope and 
the question of “officially supported Linux distributions” should be discussed 
separately.




> On 7 Jun 2018, at 08:43, Peter Ivanov  wrote:
> 
> Understood. Will do today.
> 
> 
> On Thu, 7 Jun 2018 at 08:43, Dmitriy Setrakyan  > wrote:
> On Wed, Jun 6, 2018 at 10:40 PM, Peter Ivanov  > wrote:
> 
> > Dmitriy,
> >
> >
> > What kind of instructions? Systemd or stand-alone?
> > I thought we have already agreed that systemd services are not eligible for
> > Windows 10 WSL.
> >
> > So have I to check that Debian, Ubuntu and SUSE environments for Windows 10
> > WSL supports running Apache Ignite installed from packages as a stand-alone
> > application?
> >
> 
> Yes.

[GitHub] ignite pull request #4146: Ignite-8714

[SharplEr]

GitHub user SharplEr opened a pull request:

https://github.com/apache/ignite/pull/4146

Ignite-8714

For [Ignite-8714](https://issues.apache.org/jira/browse/IGNITE-8714)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SharplEr/ignite ignite-8714

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4146.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4146


commit ef809b3f0dc6089c5cbd6a108d980959ab8c5c56
Author: Alexander Menshikov 
Date:   2018-06-04T09:11:31Z

ignite-8687 Add JCache TCK 1.1.0 to TC

commit 92c2a9621d497cbc6069716fae7d7a334d3ca211
Author: Alexander Menshikov 
Date:   2018-06-07T09:37:51Z

ignite-8714 CacheEntryEvent.getOldValue should be available




---

Re: Thin clients compatibility policy

[Pavel Tupitsyn]

Vladimir,

Not sure I see the point of 2 release policy.
It is not very good both for users and developers.

* Developers still have the burden on maintaining multiple protocol versions
* Users are quite limited with version choices

We should either go with a full-blown versioning so any client can work
with any server,
or don't bother with compat at all, IMO.

Pavel

On Wed, Jun 6, 2018 at 6:24 PM, Vladimir Ozerov 
wrote:

> Igniters,
>
> Let's discuss how to implement tests in separate thread. At this point it
> is more important to agree on compatibility policies.
>
> On Wed, Jun 6, 2018 at 6:02 PM, Vyacheslav Daradur 
> wrote:
>
> > Hello, Igniters!
> >
> > I am not familiar with the Ignite's thin client.
> >
> > I'd suggest defining tests scenarios first, to understand what we need
> > for testing.
> >
> > For example, our Compatibility Framework may be used for the following
> > scenario:
> > 1. Start node of a previously released version in separate JVM and fill
> > data;
> > 2. Start thin client of an actual version in local JVM then read and
> > validate data;
> >
> > Opposite scenario with new nodes and previously released thin clients
> > is possible too, but such tests will look difficult. If we need such
> > scenarios, may be required to extend frameworks API to simplify
> > coding.
> >
> >
> > On Wed, Jun 6, 2018 at 2:41 PM, Dmitry Pavlov 
> > wrote:
> > > Hi Vyacheslav,
> > >
> > > WDYT about applicability of PDS compatibiltiy framework for thin
> clients?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov :
> > >>
> > >> Hi Nikolay,
> > >>
> > >> Huge +1 for automated compatibility tests. Luckily, we already did
> that
> > >> for
> > >> persistence, so probably we can re-use some infrastructure from there.
> > >>
> > >> On Wed, Jun 6, 2018 at 1:20 PM, Nikolay Izhikov 
> > >> wrote:
> > >>
> > >> > +1 From me.
> > >> >
> > >> > As I wrote in previous mail-threads,
> > >> > I think we need to create test framework to be able to test
> > >> > compatibility
> > >> > for all clients we have.
> > >> >
> > >> > AFAIK, currently, there is no possibility to automatically check
> > >> > compatibility.
> > >> >
> > >> > В Ср, 06/06/2018 в 11:39 +0300, Vladimir Ozerov пишет:
> > >> > > Igniters,
> > >> > >
> > >> > > I'd like to discuss once again our compatibility policy for thin
> > >> > > clients
> > >> > > (.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now,
> so
> > >> > > let's
> > >> > > try to come to agreement.
> > >> > >
> > >> > > Normally database vendors work as follows:
> > >> > > 1) There is a set of currently supported database versions
> > >> > > 2) There is a set of currently supported JDBC/ODBC drivers
> > >> > > 3) Every supported driver can work with every supported database
> > (with
> > >> > > little exclusions to this rule).
> > >> > >
> > >> > > That is, they are both backward and forward compatible. I can take
> > >> > > latest
> > >> > > Oracle's JDBC and some ancient Oracle version, and it will work,
> > >> > > unless
> > >> > > this version reached EOL and is no longer supported. And vice
> versa
> > -
> > >> > > new
> > >> > > database, old driver, all is fine.
> > >> > >
> > >> > > This is ideal scheme which I'd like to see in Ignite, but:
> > >> > > 1) Our protocol is still relatively young and evolve rapidly
> > >> > > 2) AI does not have any maintenance releases, so we cannot define
> > >> > > which
> > >> > > version is supported and which is not.
> > >> > > 3)
> > >> > >
> > >> > > I'd like to propose the following compatibility policy:
> > >> > > 1) Maintain forward and backward compatibility between two nearest
> > >> > > minor
> > >> > > releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc.
> > >> > > 2) Think of more strict compatibility rules in AI 3.0 because at
> > this
> > >> > point
> > >> > > our protocol will be stable enough.
> > >> > >
> > >> > > Thoughts?
> > >> > >
> > >> > > Vladimir.
> > >> >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

[GitHub] ignite pull request #4145: IGNITE-8724 U.warn mislead implementation fix

[zstan]

GitHub user zstan opened a pull request:

https://github.com/apache/ignite/pull/4145

IGNITE-8724 U.warn mislead implementation fix



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8724

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4145.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4145


commit 1eacc9477ba05cc5b7908718951bbb1f0999b877
Author: Evgeny Stanilovskiy 
Date:   2018-06-07T09:27:31Z

IGNITE-8724 U.warn mislead implementation fix




---

Re: Removing "fabric" from Ignite binary package name

[Petr Ivanov]

Igniters,


Lets define once again what should be done in this [1] task?
If current implementation is good, than I’ll update it to master and pass for 
review.

Yet, there is other part of the task which concerns our build server — I assume 
that almost all our build configurations will fail due to name change and there 
is no simple way of updating configurations other then merge task to master and 
start fixing failing builds.


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



> On 10 Feb 2018, at 01:56, Denis Magda  wrote:
> 
>> I don't think we necessarily need to remove 'fabric' word from every file
>> in the project, we just need to rename the name of downloadable package.
> 
> Couldn’t say it better than you, Val. Thanks for pitching in :) This is 
> exactly what the ticket is about.
> 
> —
> Denis
> 
>> On Feb 9, 2018, at 11:53 AM, Valentin Kulichenko 
>>  wrote:
>> 
>> Anton,
>> 
>> I don't think we necessarily need to remove 'fabric' word from every file
>> in the project, we just need to rename the name of downloadable package. Is
>> there any other place where 'fabric' is exposed to the user?
>> 
>> If that's the case, it should not be a big change, no?
>> 
>> -Val
>> 
>> On Fri, Feb 9, 2018 at 3:49 AM, Anton Vinogradov 
>> wrote:
>> 
>>> Denis,
>>> 
>>> You're proposing changes without viewing a code :)
>>> 
>>> 
>>> On Thu, Feb 8, 2018 at 10:07 PM, Denis Magda  wrote:
>>> 
 Anton,
 
 What’s wrong if we just go ahead and:
 - replace “fabric” with “ignite”
 - replace “hadoop” with “ignite-hadoop"
 
 —
 Denis
 
> On Feb 8, 2018, at 1:51 AM, Anton Vinogradov >>> 
 wrote:
> 
> Denis,
> 
> "hadoop" and "fabric" words work on same engine.
> 
> We have special assembly desctiptors, for example:
> dependencies-fabric.xml
> dependencies-fabric-lgpl.xml
> dependencies-hadoop.xml
> release-base.xml
> release-fabric.xml
> release-fabric-base.xml
> release-fabric-lgpl.xml
> release-hadoop.xml
> 
> So, I'ts impossible for now to remove "fabric" without "hadoop"
>>> removal.
> Only one case is to make some ditry hack, but that's not a good idea.
> 
> On Thu, Feb 8, 2018 at 11:29 AM, Sergey Kozlov 
 wrote:
> 
>> +1 hadoop accelerator removing for AI 2.5
>> 
>> Also probably IGFS should be either removed or refactored, e.g. create
 FS
>> directly over the data region without using "cache" entity as an
>> intermidiate stage
>> 
>> On Thu, Feb 8, 2018 at 2:13 AM, Denis Magda 
>>> wrote:
>> 
>>> Anton,
>>> 
>>> I don’t get how the hadoop editions are related to this task. The
 project
>>> is not named as “data fabric” for a while. Check up the site or docs.
>>> 
>>> The “fabric” word is being removed from all over the places and needs
 to
>>> be removed from the editions’ names.
>>> 
>>> As for the hadoop future, my personal position is to retire this
>> component
>>> and forget about it. I would restart the conversation again after we
 done
>>> with 2.4.
>>> 
>>> —
>>> Denis
>>> 
 On Feb 7, 2018, at 2:13 AM, Anton Vinogradov  wrote:
 
 Denis, Petr,
 
 I checked PR and found we have *overcomplicated* logic with "fabric"
>> and
 "hadoop" postfixs.
 
 Do we really need to assembly 2 editions?
 "Hadoop" edition still valued?
 
 My proposal is to get rid of "hadoop" edition and replace it with
 instruction of how to use "fabric" edition instead.
 Instruction will be pretty easy -> move "hadoop" folder from
 "optional"
>>> to
 root directory :)
 
 In that case we can just remove all postfix logic from maven poms
>>> and
 simplify release process.
 
 On Thu, Dec 28, 2017 at 9:20 PM, Denis Magda 
>> wrote:
 
> Petr, thanks for solving it!
> 
> Hope that Anton V. or some other build master will double-check the
> changes and merge them.
> 
> —
> Denis
> 
>> On Dec 28, 2017, at 8:29 AM, Petr Ivanov 
>> wrote:
>> 
>> IGNITE-7251 is done, needs review and some additional tests. See
>>> PR
> #3315 [1].
>> 
>> 
>> [1] https://github.com/apache/ignite/pull/3315 <
> https://github.com/apache/ignite/pull/3315>
>> 
>> 
>> 
>>> On 20 Dec 2017, at 23:15, Denis Magda  wrote:
>>> 
>>> Petr, thanks, such a swift turnaround!
>>> 
>>> Have you found the one who can asses and review the changes?
>>> 
>>> Maintainers label might be helpful. Just ping them directly:
>>> https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+Contribute#HowtoContribute-ReviewProcessandMaintainers <
> 

[GitHub] ignite pull request #4142: IGNITE-8721

[devozerov]

Github user devozerov closed the pull request at:

https://github.com/apache/ignite/pull/4142


---

[jira] [Created] (IGNITE-8731) .NET: intermittent failures in DataStreamerTest.TestFinalizer test

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8731:
---

 Summary: .NET: intermittent failures in 
DataStreamerTest.TestFinalizer test
 Key: IGNITE-8731
 URL: https://issues.apache.org/jira/browse/IGNITE-8731
 Project: Ignite
  Issue Type: Task
  Components: platforms
Affects Versions: 2.5
Reporter: Vladimir Ozerov
 Fix For: 2.6






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Question on peer class loading

[vbm]

Hi,

I have a Ignite server running with 3rd partyDB (MYSQL). I have the below
configuration in xml file:


  
   
  
  



* *
  ...



On the server the jar for mysql jdbc driver is present iand the servers are
coming up successfully.
I have placed the mysql jdbc driver in a seperate folder and added it to the
path using USER_LIBS env.


Now if I try to start a client, with the same the xml (only extra thing is
the client mode part), the client ignite node doesn't start and throws below
error. 

* org.springframework.beans.MethodInvocationException: Property
'driverClassName' threw exception; nested exception is
java.lang.IllegalStateException: Could not load JDBC driver class
[com.mysql.jdbc.Driver]*

As peer class loading is enabled, I expect the client to get the class from
the server. Why is this not happening ?













--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-8730) Class org.jsr166.ConcurrentHashMap8 does not implement the requested interface java.util.concurrent.ConcurrentMap

[Saurin (JIRA)]

Saurin created IGNITE-8730:
--

 Summary:  Class org.jsr166.ConcurrentHashMap8 does not implement 
the requested interface java.util.concurrent.ConcurrentMap
 Key: IGNITE-8730
 URL: https://issues.apache.org/jira/browse/IGNITE-8730
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Saurin


Cannot start Ignite 2.5 using java code Ignite ignite = Ignition.start(); 

Getting error: java.lang.IncompatibleClassChangeError: Class 
org.jsr166.ConcurrentHashMap8 does not implement the requested interface 
java.util.concurrent.ConcurrentMap

at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.start(IgniteH2Indexing.java:2062)
 at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.start(GridQueryProcessor.java:242)
 at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1738)
 at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:986)
 at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
 at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
 at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
 at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1069)
 at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:955)
 at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:854)
 at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:578)
 at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:558)
 at org.apache.ignite.Ignition.start(Ignition.java:309)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Node.JS thin client: Node.JS thin client fails

[Vladimir Ozerov]

Denis,

No, AI 2.5 is not supported.

чт, 7 июня 2018 г. в 2:37, Denis Magda :

> Pavel,
>
> I'm tried to run an SQL example following the prepared documentation:
>
> https://apacheignite.readme.io/v2.5/docs/nodejs-thin-client#section-examples
>
> Getting an exception below when execute `node SqlQueryEntriesExample.js`
> example. Do we support Ignite 2.5 (using its binaries)? Do I need to use
> Ignite master instead?
>
> [16:31:13,389][SEVERE][client-connector-#46][ClientListenerNioListener]
> Failed to parse client request.
>
> class org.apache.ignite.binary.BinaryObjectException: Unexpected field type
> [pos=73, expected=String, actual=-1]
>
> at
>
> org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(BinaryReaderExImpl.java:1677)
>
> at
>
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readString(BinaryReaderExImpl.java:1055)
>
> at
>
> org.apache.ignite.internal.processors.platform.utils.PlatformConfigurationUtils.readQueryEntity(PlatformConfigurationUtils.java:500)
>
> at
>
> org.apache.ignite.internal.processors.platform.client.cache.ClientCacheConfigurationSerializer.read(ClientCacheConfigurationSerializer.java:352)
>
> at
>
> org.apache.ignite.internal.processors.platform.client.cache.ClientCacheGetOrCreateWithConfigurationRequest.(ClientCacheGetOrCreateWithConfigurationRequest.java:46)
>
> at
>
> org.apache.ignite.internal.processors.platform.client.ClientMessageParser.decode(ClientMessageParser.java:336)
>
> at
>
> org.apache.ignite.internal.processors.platform.client.ClientMessageParser.decode(ClientMessageParser.java:220)
>
> at
>
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:138)
>
> at
>
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:44)
>
> at
>
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>
> at
>
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>
> at
>
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>
> at
>
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
> at java.lang.Thread.run(Thread.java:745)
>

[jira] [Created] (IGNITE-8729) Deadlock in DataStreamer using addData(..) concurrently

[JIRA]

Martin Askøe created IGNITE-8729:


 Summary: Deadlock in DataStreamer using addData(..) concurrently
 Key: IGNITE-8729
 URL: https://issues.apache.org/jira/browse/IGNITE-8729
 Project: Ignite
  Issue Type: Bug
  Components: cache, compute
Affects Versions: 2.3
Reporter: Martin Askøe
 Attachments: thread-dump-extract.txt

Experiencing deadlocks when using the DataStreamer.addData(...) to ingest into 
a cache from multiple threads (5x). Attached an extract of my thread-dump from 
one node. I do however have multiple nodes/host in the cluster, all using a 
data streamer to the same cache.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8728) Nodes down after other nodes reboot in the cluster

[Mahesh Renduchintala (JIRA)]

Mahesh Renduchintala created IGNITE-8728:


 Summary: Nodes down after other nodes reboot in the cluster
 Key: IGNITE-8728
 URL: https://issues.apache.org/jira/browse/IGNITE-8728
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Mahesh Renduchintala


I have two nodes on which we have 3 tables are partitioned.  Index are also 
built on these node. 

For 24 hours caches work fine.  The tables are definitely distributed across 
both the nodes

Node 2 reboots, ignite service gets started and in Node 1 we see a crash. 

 

[10:38:35,437][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery accepted 
incoming connection [rmtAddr=/192.168.1.7, rmtPort=45102]
[10:38:35,437][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery spawning 
a new thread for connection [rmtAddr=/192.168.1.7, rmtPort=45102]
[10:38:35,437][INFO][tcp-disco-sock-reader-#12][TcpDiscoverySpi] Started 
serving remote node connection [rmtAddr=/192.168.1.7:45102, rmtPort=45102]
[10:38:35,451][INFO][tcp-disco-sock-reader-#12][TcpDiscoverySpi] Finished 
serving remote node connection [rmtAddr=/192.168.1.7:45102, rmtPort=45102
[10:38:35,457][SEVERE][tcp-disco-msg-worker-#3][TcpDiscoverySpi] 
TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node in 
order to prevent cluster wide instability.
java.lang.IllegalStateException: Duplicate key
 at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223)
 at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174)
 at 
org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114)
 at 
org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536)
 at 
org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
 at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[10:38:35,459][SEVERE][tcp-disco-msg-worker-#3][] Critical system error 
detected. Will be handled accordingly to configured handler [hnd=class 
o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext 
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Duplicate 
key]]
java.lang.IllegalStateException: Duplicate key
 at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223)
 at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174)
 at 
org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114)
 at 
org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536)
 at 
org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
 at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[10:38:35,460][SEVERE][tcp-disco-msg-worker-#3][] JVM will be halted 
immediately due to the failure: [failureCtx=FailureContext 
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Duplicate 
key]]

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)