Re: [IGNITE-7909]: Java code examples are needed for Spark Data Frames.

[Akmal Chaudhri]

Nikolay,

Ok. I _think_ it should be better now, so we can try again.

1. I removed the 3 pull requests.
2. I renamed the Java code files with a "Java" prefix.
3. I created a test file for the Java code, using the existing test file
for the Scala code.
4. I updated the TestSuite with bullet #3 above.
5. I combined all changes into a single pull request.

Note that one of the tests still fails locally due to the path issue. I
have no idea how to fix this, although the code works fine.

Thank you.



On 19 April 2018 at 22:41, Nikolay Izhikov  wrote:

> Hello, Akmal.
>
> 1. As a first step. Let's combine all changes you want to merge into a
> single pull request.
>
> I suggest that your changes relates only to "examples" module.
>
> 2. So, when you will have one pull request, please, run "Examples" test
> suite on Team City for your branch.
> After that, attach link to execution into issue.
>
> After completing step 1 I will be able to review your changes.
> After completing step 2 and review we will be to merge your changes to
> master.
>
> В Чт, 19/04/2018 в 15:30 +0100, Akmal Chaudhri пишет:
> > Nikolay,
> >
> > The code is the same for the attached version to the ticket, as well as
> the
> > pull version. The tests are also the same as those provided for the Scala
> > DF examples. I have checked and they work correctly with the exception of
> > the path issue which I previously mentioned on the dev list.
> >
> > I'm afraid I am new to this whole process, so need someone in the
> community
> > to assist.
> >
> > To summarise,
> >
> > 1. The Java Spark DF code is equivalent in functionality to the Scala
> Spark
> > DF code. These Java examples were requested by Denis Magda, since only
> > Scala examples were previously available.
> > 2. The tests scripts provided with the Scala DF code work just fine with
> > the Java code.
> > 3. There is a problem with a path issue in test #2, where the code reads
> a
> > JSON file. Since the Java code is equivalent to the Scala code, I don't
> > know how the Scala code passed this test.
> >
> >
> >
> > On 18 April 2018 at 22:11, Nikolay Izhikov  wrote:
> >
> > > Hello, Akmal.
> > >
> > > I see 3 pull requests attached to the ticket [1], [2], [3].
> > > I see 3 java files attached to the ticket, also.
> > >
> > > Which changes you want to be reviewed and merge? Please, clarify.
> > >
> > > Delete all unnecessary pull requests link from the ticket.
> > > Add new examples to the tests so we can test it on the Team City.
> > > You can take IgniteDataFrameSelfTest as an example.
> > >
> > > I also suggest to rename java examples with "Java" prefix.
> > >
> > > IgniteDataFrameWriteExample.java -> JavaIgniteDataFrameWriteExampl
> e.java
> > >
> > > [1] https://github.com/apache/ignite/pull/3857
> > > [2] https://github.com/apache/ignite/pull/3858I
> > > [3] https://github.com/apache/ignite/pull/3859
> > > [4] https://github.com/apache/ignite/blob/master/examples/
> > > src/test/spark/org/apache/ignite/spark/examples/
> > > IgniteDataFrameSelfTest.java
> > >
> > >
> > >
> > >
> > > В Ср, 18/04/2018 в 17:20 +0100, Akmal Chaudhri пишет:
> > > > If any community members have time, please review the code. Three
> Java
> > > > files are attached to the Jira ticket:
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-7909
> > > >
> > > > The code should be functionally equivalent to the Scala Data Frames
> code
> > > > that was shipped in 2.4.
> > > >
> > > > Data Frame documentation is here:
> > > >
> > > > https://apacheignite-fs.readme.io/docs/ignite-data-frame
> > > >
> > > > Thank you!
>

[GitHub] ignite pull request #3883: IGNITE-7909 Java code examples are needed for Spa...

[VeryFatBoy]

GitHub user VeryFatBoy opened a pull request:

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

IGNITE-7909 Java code examples are needed for Spark Data Frames.

New source files and test file for Java code examples.

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

$ git pull https://github.com/VeryFatBoy/ignite master

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

https://github.com/apache/ignite/pull/3883.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 #3883


commit 3708d74c6cb035700199d54262509975604cf369
Author: Akmal Chaudhri 
Date:   2018-04-20T04:57:53Z

IGNITE-7909 Java code examples are needed for Spark Data Frames.

New source files and test file for Java code examples.




---

[GitHub] ignite pull request #3857: IGNITE-7909 - Java code example.

[VeryFatBoy]

Github user VeryFatBoy closed the pull request at:

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


---

[GitHub] ignite pull request #3858: IGNITE-7909 - Java code example.

[VeryFatBoy]

Github user VeryFatBoy closed the pull request at:

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


---

[GitHub] ignite pull request #3858: IGNITE-7909 - Java code example.

[VeryFatBoy]

Github user VeryFatBoy closed the pull request at:

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


---

[GitHub] ignite pull request #3858: IGNITE-7909 - Java code example.

[VeryFatBoy]

GitHub user VeryFatBoy reopened a pull request:

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

IGNITE-7909 - Java code example.

Java version of IgniteDataFrameExample.scala

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

$ git pull https://github.com/VeryFatBoy/ignite VeryFatBoy-patch-2

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

https://github.com/apache/ignite/pull/3858.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 #3858


commit 52026e922b670289d928a2b711f3c53e0ea23a2a
Author: VeryFatBoy 
Date:   2018-04-17T17:33:41Z

IGNITE-7909 - Java code example.




---

[GitHub] ignite pull request #3859: IGNITE-7909 - Java code example.

[VeryFatBoy]

Github user VeryFatBoy closed the pull request at:

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


---

[jira] [Created] (IGNITE-8333) Web console: Editors for table values have wrong baseline

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-8333:
-

 Summary: Web console: Editors for table values have wrong baseline
 Key: IGNITE-8333
 URL: https://issues.apache.org/jira/browse/IGNITE-8333
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Vasiliy Sisko
Assignee: Ilya Borisov
 Attachments: Selection_120.png, Selection_121.png

Baseline for table editor is higher than label baseline.



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

Re: Apache Ignite RPM packaging (Stage II)

[Dmitriy Setrakyan]

+1

On Thu, Apr 19, 2018 at 5:45 AM, Ilya Kasnacheev 
wrote:

> Hello!
>
> I recommend inclusion of this change so that it can make way into 2.5.
>
> Regards,
>
> --
> Ilya Kasnacheev
>
> 2018-04-19 9:03 GMT+03:00 Petr Ivanov :
>
> > There is not much time left for Apache Ignite 2.5 release, so let’s move
> > stage II of packaging architecture implementation (with additional split
> > scheme discussion) to 2.6 scope.
> >
> > Instead, I’d like to include DEB package to Apache Ignite 2.5 release.
> > Corresponding PR is already prepared [1].
> >
> > Also, I’ll try to prepare modifications for release procedure scripts to
> > automate uploading packages to our new Bintray RPM and DEB repositories
> > before the code freeze.
> >
> >
> > [1] https://github.com/apache/ignite/pull/3869 <
> https://github.com/apache/
> > ignite/pull/3869>
> >
> >
> >
> > > On 18 Apr 2018, at 14:44, Ilya Kasnacheev 
> > wrote:
> > >
> > > Copying anything manually to anywhere /usr (excluding /usr/local) is an
> > > example of slackwarization that package users and creators try to
> avoid.
> > >
> > >> By linux file hierarchy convention, home dir should be in /usr/lib
> > >
> > > Citation needed! I bet you're interpreting it wrong, since I've listed
> a
> > > random dir in /var/lib, and:
> > > ~/w/incubator-ignite% sudo ls -al /var/lib/lightdm
> > > drwxr-x---  6 lightdm lightdm 4096 авг 14  2017 .
> > > drwxr-xr-x 89 rootroot4096 мар 10 22:37 ..
> > > drwxrwxr-x  4 lightdm lightdm 4096 июл 19  2017 .cache
> > > drwxr-xr-x  5 lightdm lightdm 4096 июл 19  2017 .config
> > > drwx--  2 lightdm lightdm 4096 апр 11 18:25 .gconf
> > > drwxr-xr-x  3 lightdm lightdm 4096 июл 19  2017 .local
> > > -rw---  1 lightdm lightdm  283 апр 11 18:25 .Xauthority
> > >
> > > ...it definitely looks like a home dir. Which goes with additional
> > benefit
> > > of being writable by end-user.
> > >
> > > --
> > > Ilya Kasnacheev
> > >
> > > 2018-04-16 9:22 GMT+03:00 Petr Ivanov :
> > >
> > >>
> > >>
> > >>> On 15 Apr 2018, at 10:19, Ilya Kasnacheev  >
> > >> wrote:
> > >>>
> > >>> Hello!
> > >>>
> > >>> With existing binary archive, user can move directories from
> > >>> apache-ignite-fabric/libs/optional to apache-ignite-fabric/libs to
> > >> activate
> > >>> them.
> > >>>
> > >>> But with RPM, user should not contemplate moving directories from
> > >>> /usr/lib/apache-ignite/optional to /usr/lib/apache-ignite.
> > >>
> > >> I always thought of that option as COPYING optional libs, not MOVING.
> > >>
> > >>
> > >>>
> > >>>
> > >>> User lacks permissions for that operation and it would defeat the
> > purpose
> > >>> of having a RPM (imagine trying to upgrade Ignite RPM version with a
> > >> setup
> > >>> like that). "Turning distribution into Slackware" should not be an
> > >> offering.
> > >>
> > >> Can’t imagine use case where Apache Ignite software is installed by
> one
> > >> user, and run by another, without sudo/root permissions.
> > >> Yet, ignite user’s login shell is disabled indeed and without
> sudo/root
> > >> permissions optional libs cannot be copied.
> > >> Also — the symlinks is a good idea, but I’ve already thought of it and
> > I’m
> > >> planning addition of special utility for enabling / disabling optional
> > libs
> > >> (like a2enable/a2disable) in next development iteration.
> > >>
> > >>
> > >>>
> > >>> How it could work: Imagine we create /var/lib/ignite, use it as
> > >>> IGNITE_HOME, add symlinks from files in /usr/lib to /var/lib/ignite.
> > This
> > >>> way, we can add and remove symlinks to modules in optional/, and thus
> > >>> enable and disable them as user sees fit.
> > >>
> > >> By linux file hierarchy convention, home dir should be in /usr/lib.
> > >> /var/lib/ is currently used for working files (MySQL alike).
> > >>
> > >>
> > >>>
> > >>> This also answers the problem of "what's IGNITE_HOME for visor
> launched
> > >>> from /usr/bin”
> > >>
> > >> That is addressed in separate task and will be fixed with minor
> startup
> > >> script redesign with universal location-independent solution.
> > >>
> > >>
> > >>>
> > >>> But obviously this will require dedication and effort.
> > >>
> > >> No problems with efforts after final design is discussed an agreed.
> > >>
> > >>
> > >>>
> > >>>
> > >>> --
> > >>> Ilya Kasnacheev
> > >>>
> > >>> 2018-04-14 8:03 GMT+03:00 Peter Ivanov :
> > >>>
> >  Current packages design (after installation) does not differ from
> > binary
> >  archive - everything works (except necessity to run service instead
> >  ignite.sh) just the same way, including libs/optional.
> > 
> >  Also, there can be issues with system JDK version by default, but
> > every
> >  problem will be in journalctl and/or  /var/log, and package has
> strong
> >  dependency on any implementation of JDK 1.8.
> > 
> > 
> >  I am 

[jira] [Created] (IGNITE-8332) Web console: Empty cells in SQL Scheme table

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-8332:
-

 Summary: Web console: Empty cells in SQL Scheme table
 Key: IGNITE-8332
 URL: https://issues.apache.org/jira/browse/IGNITE-8332
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.5
Reporter: Vasiliy Sisko
Assignee: Ilya Borisov
 Attachments: Selection_118.png

# Open SQL Scheme tab of configuration.
 # Add new SQL Scheme

Row for new scheme is appeared but it's cells are empty.

See attached screenshot.



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

Re: Topology-wide notification on critical errors

[Dmitriy Setrakyan]

On Thu, Apr 19, 2018 at 8:19 AM, Yakov Zhdanov  wrote:

> Guys,
>
> We have activity to implement a set of mechanisms to handle critical issues
> on nodes (IEP-14 - [1]).
>
> I have an idea to spread message about critical issues to nodes through
> entire topology and put it to logs of all nodes. In my view this will add
> much more clarity. Imagine all nodes output message to log - "Critical
> system thread failed on node XXX [details=...]". This should help a lot
> with investigations.
>
> Andrey Gura, Alex Goncharuk what do you think?
>

Yakov, even though you did not ask me what I think, but I really like the
idea :)

[GitHub] ignite pull request #3882: Ignite 2.4.4.b3

[slukyano]

GitHub user slukyano opened a pull request:

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

Ignite 2.4.4.b3



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

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

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

https://github.com/apache/ignite/pull/3882.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 #3882


commit 915dd2966084d78f7b4f3d482e6bd25f860c1e23
Author: Alexey Goncharuk 
Date:   2018-01-31T08:22:26Z

IGNITE-7569 Fixed index rebuild future - Fixes #3454.

commit 8ea8609259039852ab0c26f26ac528c1ffae7c94
Author: Alexey Goncharuk 
Date:   2018-01-31T08:24:57Z

IGNITE-7577 Fixing public API active flag on baseline changes - Fixes #3455.

commit c8ce1f66e98b3174d771a3b801a2538499dc2c3d
Author: Ivan Rakov 
Date:   2018-01-31T09:51:09Z

IGNITE-7475 Improved VerifyBackupPartitionsTask to calculate partition 
hashes in parallel - Fixes #3407.

Signed-off-by: Alexey Goncharuk 

commit 258ff4299da20122d7c387cb8579264035c93c18
Author: Alexey Goncharuk 
Date:   2018-01-31T13:52:24Z

IGNITE-7573 Fixed full API tests to be compliant with baseline topology

commit 254ed3a9c32d092702a0461509bf867cbd7cdee6
Author: Alexey Kuznetsov 
Date:   2018-02-01T08:22:53Z

ignite-2.4.0 Update version.

(cherry picked from commit 2e43749)

commit c1a9c0a404d77fba08170bedf14844f87abe3028
Author: Alexey Goncharuk 
Date:   2018-02-01T10:17:28Z

IGNITE-7569 Fixing index rebuild future

commit e43799ce70cdbe03d9e206381d1d5138b820b075
Author: Alexey Goncharuk 
Date:   2018-02-01T13:39:17Z

IGNITE-7520 Provide util-methods to get baseline from context - Fixes #3431.

commit 8f5fc7cfb0624cf2048efad38dfff32f782116e8
Author: Sergey Chugunov 
Date:   2018-02-02T08:24:29Z

IGNITE-7580 Fix compatibilityMode flag consistency

This closes #3466

(cherry picked from commit 8f2045e)

commit d3ddd50cb2b889173176b6c47c9ff61410e1d909
Author: Ilya Lantukh 
Date:   2018-02-07T10:33:28Z

IGNITE-7514 Affinity assignment should be recalculated when primary node is 
not OWNER

(cherry picked from commit faf50f1)

commit d3745e9d0a3ff5a64fba494889b7e2605f3af6bb
Author: Alexey Goncharuk 
Date:   2018-02-07T18:10:32Z

IGNITE-7639 Fixed NPE

commit f7c16855ba802d9d47048521aec7e14285e4a281
Author: Pavel Kovalenko 
Date:   2018-02-09T13:55:15Z

IGNITE-7540 Prevent page memory metadata corruption during checkpoint and 
group destroying. - Fixes #3490.

Signed-off-by: Alexey Goncharuk 

commit c92f167fc491078f02b9f94fe89edafc2902ebc2
Author: ilantukh 
Date:   2018-02-14T12:40:13Z

Updated version in properties.

commit 1ecf348dd429cf7861b414e0e5a7776b72dba281
Author: Sergey Chugunov 
Date:   2018-02-16T13:21:12Z

IGNITE-7699 BinaryMetadata exchange should not be triggered if metadata was 
not updated - Fixes #3523.

Signed-off-by: Alexey Goncharuk 

(cherry-picked from commit bcd3881)

commit 2458bd08a5b501b3eeb5caf0ae6dcaa2bcccd915
Author: EdShangGG 
Date:   2018-02-16T13:29:49Z

IGNITE-7676 Add affinity version to snapshot plugin stub - Fixes #3510.

Signed-off-by: Alexey Goncharuk 
(cherry picked from commit b6d21fb)

commit bfdcda7a2a6b5cf64f15ed169d2beb886f131fac
Author: EdShangGG 
Date:   2018-02-12T16:36:30Z

IGNITE-7626 Unify code in test which cleans up persistence directories - 
Fixes #3477.

Signed-off-by: Alexey Goncharuk 
(cherry picked from commit a0997b9)

commit 2e92e0094b270aa8489e66d94bfcf15eadabfb4f
Author: EdShangGG 
Date:   2018-02-12T18:44:10Z

IGNITE-7626 Unify code in test which clean up persistence directories - 
Fixes #3512.

Signed-off-by: Alexey Goncharuk 
(cherry picked from commit 6f6f8dd)

commit 3f86c127c78065999663a4fc4eaedb5e5d4bee1c
Author: EdShangGG 
Date:   2018-02-12T18:26:31Z

compilation fix

commit 0b9322c566f9b464291854142ac02495bd1817e4
Author: gg-shq 
Date:   2018-02-07T11:28:04Z

IGNITE-6917: Implemented SQL COPY command.

commit c5e386ca96750213bddcd98d0af0c589fee476ca
Author: gg-shq 
Date:   2018-02-07T15:31:27Z

IGNITE-7586: Added COPY command into the JDBC example.

This closes #3485

commit d8203e2d81f8fbf0f7fbe5e710c9908f2fcb8307
Author: shq 
Date:   2018-02-15T10:36:00Z

Re: Service grid redesign

[Valentin Kulichenko]

Denis,

I totally agree with you. I'm just not sure why do we need two methods
(init and execute) that have virtually same semantics. With the new design,
what would be the difference between these methods from user point of view,
and how one would determine what exactly should go in each of them? Unless
I'm missing something, it looks like unnecessary complication.

-Val

On Tue, Apr 17, 2018 at 1:00 AM, Denis Mekhanikov 
wrote:

> Val,
>
> Service initialisation is not going to happen in the discovery thread.
> It should be done asynchronously, and initialisation results should be sent
> to the coordinator over communication.
> This is described in the IEP:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> Successfulscenario
>
> *init()* method is a validation step, making sure, that service is ready
> for work.
> And deployment shouldn't be considered successful until *init()* methods
> finish their work on the assigned nodes.
> Also *cancel() *and *init() *methods may be useful if we decide to
> implement moving existing services to new nodes
>  17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> Movingexistingservicestonewnodes>
>  in
> future.
> These methods can be used to save and restore service's state from cache,
> when it is rebalanced to another node.
>
> As Denis said, if we are not going to prevent nodes from starting on
> service failures, then we should at least generate corresponding events.
> Otherwise there won't be any way to react to service initialization
> failures during nodes startup.
>
> Denis
>
> вт, 17 апр. 2018 г. в 6:59, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > I agree we shouldn't do anything synchronously within discovery threads.
> If
> > something goes wrong, we just need to properly notify the user, logging
> and
> > events seem to be right options to achieve that.
> >
> > BTW, with this design I'm not sure init() method makes sense, probably we
> > should deprecate it.
> >
> > -Val
> >
> > On Mon, Apr 16, 2018 at 12:03 PM, Denis Magda  wrote:
> >
> > > Denis,
> > >
> > > In general, service initialization shouldn't prevent a node from
> joining
> > > the cluster or slowing down that process. Thus, I would start the
> > > initialization routines only after the node is accepted by the cluster.
> > If
> > > the initialization fails then we need to report a respective message to
> > the
> > > logs and, probably, generate a system event the user can be subscribed
> > to.
> > >
> > > Regardless, of the service initialization time, I think we still need
> to
> > > utilize discovery SPI to avoid problems discussed later.
> > >
> > > Val, others, what do you think about that?
> > >
> > >
> > > --
> > > Denis
> > >
> > > On Mon, Apr 16, 2018 at 10:29 AM, Denis Mekhanikov <
> > dmekhani...@gmail.com>
> > > wrote:
> > >
> > > > Basically, my question is: at which moment services should be
> deployed
> > on
> > > > connecting nodes?
> > > > Should we reject a node from being included into a topology, if
> > services,
> > > > that are assigned to it, fail to deploy?
> > > >
> > > > It would be good to be sure, that all assigned services are
> initialised
> > > and
> > > > working, when node start is finished.
> > > > Otherwise it's unclear, how to notify a user about failures in
> service
> > > > initialisation on new nodes.
> > > >
> > > > If we decide to provide such guarantee, then how are we going to do
> > that?
> > > > Is procedure, that I described, viable?
> > > > It requires hacking through the discovery protocol, which is a thing,
> > > that
> > > > should be avoided.
> > > > So, maybe there is another way to achieve the same thing?
> > > >
> > > > Denis
> > > >
> > > > сб, 14 апр. 2018 г. в 1:48, Denis Magda :
> > > >
> > > > > It sounds like it's not a trivial thing to support the automatic
> > > services
> > > > > redeployment after a restart. Let's postpone it for now, guys
> > > > concentrating
> > > > > on more urgent things related to the services.
> > > > >
> > > > > Alex, Vladimir,
> > > > >
> > > > > Could you have a look at Denis question about the discovery-based
> > > > > deployment? Guess it's the only one thing that prevents us from the
> > IEP
> > > > > finalization.
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > > On Fri, Apr 13, 2018 at 5:30 AM, Denis Mekhanikov <
> > > dmekhani...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Vladimir,
> > > > > >
> > > > > > Currently we don't save binary metadata to disk, when persistence
> > is
> > > > > > disabled.
> > > > > > But we still persist marshaller mappings for some reason, and I
> > > > > personally
> > > > > > believe, that we shouldn't.
> > > > > >
> > > > > > But I agree, that we should separate data and service persistence
> > > > > > configuration.
> > 

Re: GA Grid: Can IGNITE-8242 be include in 2.5 release?

[Denis Magda]

Yuri, Andrey,

Could you have a look and include the ticket into the release?

--
Denis


On Thu, Apr 19, 2018 at 3:23 PM, techbysample  wrote:

> Denis/Yury
>
> Can ticket https://issues.apache.org/jira/browse/IGNITE-8242  be included
> within 2.5 release?
> Upon review of my tickets today, I noticed the fixed version was updated
> from 2.5 to 2.6?
>
> This ticket addresses a minor bug in GA Grid.
>
> I have removed method GAGridUtils.getGenesForChromosome() as it is
> problematic when Chromosome contains duplicate genes.
>
> GAGridUtils.getGenesInOrderForChromosome() will be used instead.
>
> Please advise.
>
> Turik
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

GA Grid: Can IGNITE-8242 be include in 2.5 release?

[techbysample]

Denis/Yury

Can ticket https://issues.apache.org/jira/browse/IGNITE-8242  be included
within 2.5 release?
Upon review of my tickets today, I noticed the fixed version was updated
from 2.5 to 2.6?

This ticket addresses a minor bug in GA Grid.

I have removed method GAGridUtils.getGenesForChromosome() as it is
problematic when Chromosome contains duplicate genes.

GAGridUtils.getGenesInOrderForChromosome() will be used instead.

Please advise.

Turik



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

[jira] [Created] (IGNITE-8331) SQL: Add Decimal precision and scale constraint

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-8331:
---

 Summary: SQL: Add Decimal precision and scale constraint
 Key: IGNITE-8331
 URL: https://issues.apache.org/jira/browse/IGNITE-8331
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov


We should support DECIMAL(X, Y) syntax. 
Currently, we ignore it. 
It affects semantics. 
E.g., one can insert a DECIMAL with greater precision into a cache/table 
without any problems. 



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

Re: Ticket review checklist

[Nikolay Izhikov]

Hello, Vladimir.

Thank you for seting up this discussion.

As we discussed, I think an important part of this check list is compatibility 
rules.

* What should be backward compatible?
* How should we maintain it?

> 3) If ticket changes public API or existing behavior, at least two commiters 
> should approve the changes

We can learn from other open source project experience.
Apache Kafka [1], for example, requires KIP(kafka improvement proposal) for 
*every* major change.
Major change definition includes public API.

[1] 
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals


В Чт, 19/04/2018 в 23:00 +0300, Vladimir Ozerov пишет:
> Hi Igniters,
> 
> It's glad to see our community becomes larger every day. But as it grows it
> becomes more and more difficult to manage review and merge processes and
> keep quality of our decisions at the proper level. More contributors, more
> commits, more components interlinked with each other in subtle ways.
> 
> I would like to propose to setup a formal review checklist. This would be a
> set of actions every reviewer needs to check before approving merge of a
> certain feature. Passing the checklist would be *necessary but not
> sufficient* phase before commit could be added to the main branch. The
> checklist would help us to detect a lot of common problems such a broken
> tests or bad UX earlier, and would help contributors lead their pull
> requests to merge.
> 
> Hallmarks of a good checklist:
> - It must be followed be everyone without exceptions
> - It must be clear and disallow multiple interpretations
> - It must be lightweight, otherwise Ignite development would become a
> nightmare
> - It must be non-blocking, i.e. inacessibility of a single contributor
> should not block ticket progress forever.
> 
> Please let me know if you think the idea makes sense. If we agree on it,
> let's start defining action items for the checklist. My 2 cents:
> 1) All unit tests pass on TC without new failures
> 2) If ticket targets specific component, it should be reviewed by
> component's maintainer*
> 3) If ticket changes public API or existing behavior, at least two
> commiters should approve the changes **
> 
> Thoughts?
> 
> Vladimir.
> 
> * TBD: Review component list and define maintainers; define what to do if
> maintainer is unavailable
> ** TBD: Define what is "public API"

signature.asc
Description: This is a digitally signed message part

Re: [IGNITE-7909]: Java code examples are needed for Spark Data Frames.

[Nikolay Izhikov]

Hello, Akmal.

1. As a first step. Let's combine all changes you want to merge into a single 
pull request.

I suggest that your changes relates only to "examples" module.

2. So, when you will have one pull request, please, run "Examples" test suite 
on Team City for your branch.
After that, attach link to execution into issue.

After completing step 1 I will be able to review your changes.
After completing step 2 and review we will be to merge your changes to master.

В Чт, 19/04/2018 в 15:30 +0100, Akmal Chaudhri пишет:
> Nikolay,
> 
> The code is the same for the attached version to the ticket, as well as the
> pull version. The tests are also the same as those provided for the Scala
> DF examples. I have checked and they work correctly with the exception of
> the path issue which I previously mentioned on the dev list.
> 
> I'm afraid I am new to this whole process, so need someone in the community
> to assist.
> 
> To summarise,
> 
> 1. The Java Spark DF code is equivalent in functionality to the Scala Spark
> DF code. These Java examples were requested by Denis Magda, since only
> Scala examples were previously available.
> 2. The tests scripts provided with the Scala DF code work just fine with
> the Java code.
> 3. There is a problem with a path issue in test #2, where the code reads a
> JSON file. Since the Java code is equivalent to the Scala code, I don't
> know how the Scala code passed this test.
> 
> 
> 
> On 18 April 2018 at 22:11, Nikolay Izhikov  wrote:
> 
> > Hello, Akmal.
> > 
> > I see 3 pull requests attached to the ticket [1], [2], [3].
> > I see 3 java files attached to the ticket, also.
> > 
> > Which changes you want to be reviewed and merge? Please, clarify.
> > 
> > Delete all unnecessary pull requests link from the ticket.
> > Add new examples to the tests so we can test it on the Team City.
> > You can take IgniteDataFrameSelfTest as an example.
> > 
> > I also suggest to rename java examples with "Java" prefix.
> > 
> > IgniteDataFrameWriteExample.java -> JavaIgniteDataFrameWriteExample.java
> > 
> > [1] https://github.com/apache/ignite/pull/3857
> > [2] https://github.com/apache/ignite/pull/3858I
> > [3] https://github.com/apache/ignite/pull/3859
> > [4] https://github.com/apache/ignite/blob/master/examples/
> > src/test/spark/org/apache/ignite/spark/examples/
> > IgniteDataFrameSelfTest.java
> > 
> > 
> > 
> > 
> > В Ср, 18/04/2018 в 17:20 +0100, Akmal Chaudhri пишет:
> > > If any community members have time, please review the code. Three Java
> > > files are attached to the Jira ticket:
> > > 
> > > https://issues.apache.org/jira/browse/IGNITE-7909
> > > 
> > > The code should be functionally equivalent to the Scala Data Frames code
> > > that was shipped in 2.4.
> > > 
> > > Data Frame documentation is here:
> > > 
> > > https://apacheignite-fs.readme.io/docs/ignite-data-frame
> > > 
> > > Thank you!

signature.asc
Description: This is a digitally signed message part

[jira] [Created] (IGNITE-8330) Docs: Put JDBC/ODBC URL in Brackets When Connecting From Bash

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8330:
---

 Summary: Docs: Put JDBC/ODBC URL in Brackets When Connecting From 
Bash
 Key: IGNITE-8330
 URL: https://issues.apache.org/jira/browse/IGNITE-8330
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Magda
Assignee: Prachi Garg
 Fix For: 2.5


We need to add a warning callout with the content below to both JDBC and ODBC 
documentation pages:
Title: Put JDBC/ODBC URL in Brackets When Connecting From Bash
Description:
Make sure to put the connection URL in " brackets when opening it up from a 
bash environment, as follows: 
"jdbc:ignite:thin://[address]:[port];user=ignite;password=[password]"



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

Ticket review checklist

[Vladimir Ozerov]

Hi Igniters,

It's glad to see our community becomes larger every day. But as it grows it
becomes more and more difficult to manage review and merge processes and
keep quality of our decisions at the proper level. More contributors, more
commits, more components interlinked with each other in subtle ways.

I would like to propose to setup a formal review checklist. This would be a
set of actions every reviewer needs to check before approving merge of a
certain feature. Passing the checklist would be *necessary but not
sufficient* phase before commit could be added to the main branch. The
checklist would help us to detect a lot of common problems such a broken
tests or bad UX earlier, and would help contributors lead their pull
requests to merge.

Hallmarks of a good checklist:
- It must be followed be everyone without exceptions
- It must be clear and disallow multiple interpretations
- It must be lightweight, otherwise Ignite development would become a
nightmare
- It must be non-blocking, i.e. inacessibility of a single contributor
should not block ticket progress forever.

Please let me know if you think the idea makes sense. If we agree on it,
let's start defining action items for the checklist. My 2 cents:
1) All unit tests pass on TC without new failures
2) If ticket targets specific component, it should be reviewed by
component's maintainer*
3) If ticket changes public API or existing behavior, at least two
commiters should approve the changes **

Thoughts?

Vladimir.

* TBD: Review component list and define maintainers; define what to do if
maintainer is unavailable
** TBD: Define what is "public API"

[jira] [Created] (IGNITE-8329) Clarify TransactionRollbackException-related paragraph in documentation

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-8329:


 Summary: Clarify TransactionRollbackException-related paragraph in 
documentation
 Key: IGNITE-8329
 URL: https://issues.apache.org/jira/browse/IGNITE-8329
 Project: Ignite
  Issue Type: Task
Reporter: Andrey Kuznetsov


As documentation states currently [1], TransactionRollbackException is thrown 
"if the transaction was rolled back automatically". This should be extended to 
manual rollback as well, if it took place before commit for some reason.

[1] 
https://apacheignite.readme.io/docs/transactions#section-handling-failed-transactions



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

[jira] [Created] (IGNITE-8328) .NET: Thin client: Run in browser with Blazor

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-8328:
--

 Summary: .NET: Thin client: Run in browser with Blazor
 Key: IGNITE-8328
 URL: https://issues.apache.org/jira/browse/IGNITE-8328
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn


Blazor runs .NET IL code in browser with WebAssembly.

Investigate if we can make Ignite.NET thin client run there.



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

[GitHub] ignite pull request #3881: IGNITE-8313 Add trace logs on exchange phases and...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8313 Add trace logs on exchange phases and affinity calculation.



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

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

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

https://github.com/apache/ignite/pull/3881.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 #3881


commit b23bc4ba0af209facb7251d1579cd93ad24b746b
Author: Pavel Kovalenko 
Date:   2018-04-19T16:11:06Z

IGNITE-8313 Add trace logs on exchange phases and affinity calculation.




---

[GitHub] ignite pull request #3877: IGNITE-8325 Compressor thread may miss notificati...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Topology-wide notification on critical errors

[Yakov Zhdanov]

Guys,

We have activity to implement a set of mechanisms to handle critical issues
on nodes (IEP-14 - [1]).

I have an idea to spread message about critical issues to nodes through
entire topology and put it to logs of all nodes. In my view this will add
much more clarity. Imagine all nodes output message to log - "Critical
system thread failed on node XXX [details=...]". This should help a lot
with investigations.

Andrey Gura, Alex Goncharuk what do you think?

--Yakov

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling

[GitHub] ignite pull request #3880: IGNITE-8324 Update discovery cache as well as top...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8324 Update discovery cache as well as topology version



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

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

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

https://github.com/apache/ignite/pull/3880.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 #3880


commit df540e065c34ea80fe6c6e874521cd130879
Author: Pavel Kovalenko 
Date:   2018-04-19T15:12:06Z

IGNITE-8324 Update discovery caches as well as topology version. Remove 
unnecessary `updateTopologies` calls.




---

[GitHub] ignite pull request #3800: Mmuzaf ignite 7791

[Mmuzaf]

Github user Mmuzaf closed the pull request at:

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


---

[GitHub] ignite pull request #3879: IGNITE-8077 implemented getTxHoldingLockNum and g...

[akalash]

GitHub user akalash opened a pull request:

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

IGNITE-8077 implemented getTxHoldingLockNum and getLockedKeysNum in 
TxMXBeanImpl



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

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

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

https://github.com/apache/ignite/pull/3879.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 #3879


commit d5e1457006e042508b7394d38e878fd942851d2e
Author: AMedvedev 
Date:   2018-04-03T02:46:26Z

IGNITE-8077: wip

commit a0eef40e1b270276e1e75d15cb76303c7bcaaa37
Author: AMedvedev 
Date:   2018-04-03T04:33:20Z

IGNITE-8077: simplify

commit 830aeaedd9397835f6cf0fc6da224e4d6a8f014c
Author: Anton Kalashnikov 
Date:   2018-04-19T15:00:13Z

IGNITE-8077 implemented getTxHoldingLockNum and getLockedKeysNum in 
TxMXBeanImpl




---

[GitHub] ignite pull request #3878: IGNITE-8327 : Removed delaying CommunicationSpi f...

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-8327 : Removed delaying CommunicationSpi from test.



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

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

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

https://github.com/apache/ignite/pull/3878.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 #3878


commit 70db1f31ccaa595b3587dcebb0a272376664fca3
Author: Ilya Lantukh 
Date:   2018-04-06T10:49:10Z

ignite-8327 : Removed delaying CommunicationSpi from test.




---

Re: [IGNITE-7909]: Java code examples are needed for Spark Data Frames.

[Akmal Chaudhri]

Nikolay,

The code is the same for the attached version to the ticket, as well as the
pull version. The tests are also the same as those provided for the Scala
DF examples. I have checked and they work correctly with the exception of
the path issue which I previously mentioned on the dev list.

I'm afraid I am new to this whole process, so need someone in the community
to assist.

To summarise,

1. The Java Spark DF code is equivalent in functionality to the Scala Spark
DF code. These Java examples were requested by Denis Magda, since only
Scala examples were previously available.
2. The tests scripts provided with the Scala DF code work just fine with
the Java code.
3. There is a problem with a path issue in test #2, where the code reads a
JSON file. Since the Java code is equivalent to the Scala code, I don't
know how the Scala code passed this test.



On 18 April 2018 at 22:11, Nikolay Izhikov  wrote:

> Hello, Akmal.
>
> I see 3 pull requests attached to the ticket [1], [2], [3].
> I see 3 java files attached to the ticket, also.
>
> Which changes you want to be reviewed and merge? Please, clarify.
>
> Delete all unnecessary pull requests link from the ticket.
> Add new examples to the tests so we can test it on the Team City.
> You can take IgniteDataFrameSelfTest as an example.
>
> I also suggest to rename java examples with "Java" prefix.
>
> IgniteDataFrameWriteExample.java -> JavaIgniteDataFrameWriteExample.java
>
> [1] https://github.com/apache/ignite/pull/3857
> [2] https://github.com/apache/ignite/pull/3858I
> [3] https://github.com/apache/ignite/pull/3859
> [4] https://github.com/apache/ignite/blob/master/examples/
> src/test/spark/org/apache/ignite/spark/examples/
> IgniteDataFrameSelfTest.java
>
>
>
>
> В Ср, 18/04/2018 в 17:20 +0100, Akmal Chaudhri пишет:
> > If any community members have time, please review the code. Three Java
> > files are attached to the Jira ticket:
> >
> > https://issues.apache.org/jira/browse/IGNITE-7909
> >
> > The code should be functionally equivalent to the Scala Data Frames code
> > that was shipped in 2.4.
> >
> > Data Frame documentation is here:
> >
> > https://apacheignite-fs.readme.io/docs/ignite-data-frame
> >
> > Thank you!
>

[GitHub] ignite pull request #3779: IGNITE-7791: fix CacheInfo initialization after c...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-8327) Node stop hangs because thread sleep blocks gateway lock

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8327:


 Summary: Node stop hangs because thread sleep blocks gateway lock
 Key: IGNITE-8327
 URL: https://issues.apache.org/jira/browse/IGNITE-8327
 Project: Ignite
  Issue Type: Test
Reporter: Alexey Goncharuk


CacheBaselineTopologyTest#testAffinityAssignmentChangedAfterRestart 
periodically hangs on TC because the test delay communication SPI blocks thread 
under gateway lock for 1000 seconds.

It looks like we can change the delay communication SPI to 
{{setRebalanceDelay=-1}}.



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

[jira] [Created] (IGNITE-8326) Can't execute SQL query for create index

[Stepanov Mikhail (JIRA)]

Stepanov Mikhail created IGNITE-8326:


 Summary: Can't execute SQL query for create index
 Key: IGNITE-8326
 URL: https://issues.apache.org/jira/browse/IGNITE-8326
 Project: Ignite
  Issue Type: Bug
Reporter: Stepanov Mikhail


I try to execute SQL query
{code:java}
CREATE INDEX IF NOT EXISTS "personNameIndex" ON "person" ("name");{code}
using method 
{code:java}
cache.query(query).getColumnsCount(){code}
and this call is never ends, because it contains semicolon.

 

See the code in org.apache.ignite.internal.sql.command.SqlCreateIndexCommand 
method parseIndexProperties. This method doesn't break when tokenType is 
SEMICOLON, but break when tokenType is EOF



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

Re: Orphaned, duplicate, and main-class tests!

[Ilya Kasnacheev]

Hello!

I have also noticed that we seem to miss a Cassandra test suite.

We have a Cassandra module with quite a few tests, but they're not in any
suite.

Maybe we should set one up?

-- 
Ilya Kasnacheev

2018-04-18 16:42 GMT+03:00 Ilya Kasnacheev :

> Hello!
>
> I've decided to return to this task after a break.
>
> Can you please tell me why do we have main-class tests? Such as
>
> GridBasicPerformanceTest.class,
> GridBenchmarkCacheGetLoadTest.class,
> GridBoundedConcurrentLinkedHashSetLoadTest.class,
> GridCacheDataStructuresLoadTest.class,
> GridCacheReplicatedPreloadUndeploysTest.class,
> GridCacheLoadTest.class,
> GridCacheMultiNodeDataStructureTest.class,
> GridCapacityLoadTest.class,
> GridContinuousOperationsLoadTest.class,
> GridFactoryVmShutdownTest.class,
> GridFutureListenPerformanceTest.class,
> GridFutureQueueTest.class,
> GridGcTimeoutTest.class,
> GridJobExecutionSingleNodeLoadTest.class,
> GridJobExecutionSingleNodeSemaphoreLoadTest.class,
> GridJobLoadTest.class,
> GridMergeSortLoadTest.class,
> GridNioBenchmarkTest.class,
> GridThreadPriorityTest.class,
> GridSystemCurrentTimeMillisTest.class,
> BlockingQueueTest.class,
> MultipleFileIOTest.class,
> GridSingleExecutionTest.class
>
>
> If nobody wants them, how about we delete them in master branch? Start
> afresh?
>
> --
> Ilya Kasnacheev
>
> 2018-02-13 17:02 GMT+03:00 Ilya Kasnacheev :
>
>> Anton,
>>
>> >Tests should be attached to appropriate suites
>>
>> This I can do
>>
>> > and muted if necessary, Issues should be created on each mute.
>>
>> This is roughly a week of work. I can't spare that right now. I doubt
>> anyone can.
>>
>> Can we approach this by smaller steps?
>>
>> --
>> Ilya Kasnacheev
>>
>> 2018-02-06 19:55 GMT+03:00 Anton Vinogradov :
>>
>>> Val,
>>>
>>> Tests should be attached to appropriate suites and muted if necessary,
>>> Issues should be created on each mute.
>>>
>>> On Tue, Feb 6, 2018 at 7:23 PM, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>>
>>> > Anton,
>>> >
>>> > I tend to agree with Ilya that identifying and fixing all the possible
>>> > broken tests in one go is not feasible. What is the proper way in your
>>> > view? What are you suggesting?
>>> >
>>> > -Val
>>> >
>>> > On Mon, Feb 5, 2018 at 2:18 AM, Anton Vinogradov <
>>> avinogra...@gridgain.com
>>> > >
>>> > wrote:
>>> >
>>> > > Ilya,
>>> > >
>>> > > 1) Still see no reason for such changes. Does this break something?
>>> > >
>>> > > 2) Looks like you're trying to add Trash*TestSuite.java which will
>>> never
>>> > be
>>> > > refactored.
>>> > > We should do everything in proper way now, not sometime.
>>> > >
>>> > > 3) Your comments looks odd to me.
>>> > > Issue should be resolved in proper way.
>>> > >
>>> > > On Mon, Feb 5, 2018 at 1:07 PM, Ilya Kasnacheev <
>>> > ilya.kasnach...@gmail.com
>>> > > >
>>> > > wrote:
>>> > >
>>> > > > Anton,
>>> > > >
>>> > > > 1) We already have ~100 files named "*AbstractTest.java". Renaming
>>> > these
>>> > > > several files will help checking for orphaned tests in the future,
>>> as
>>> > > well
>>> > > > as increasing code base consistency.
>>> > > >
>>> > > > 2) This is huge work that is not doable by any single developer.
>>> While
>>> > > > IgniteLostAndFoundTestSuite can be slowly refactored away
>>> > > > This is unless you are OK with putting all these tests, most of
>>> which
>>> > are
>>> > > > red and some are hanging, in production test suites and therefore
>>> > > breaking
>>> > > > productivity for a couple months while this gets sorted.
>>> > > > Are you OK with that? Anybody else?
>>> > > >
>>> > > > 3) I think I *could* put them in some test suite or another, but
>>> I'm
>>> > > pretty
>>> > > > sure I can't fix them all, not in one commit, not ever. Nobody can
>>> do
>>> > > that
>>> > > > single-handedly. We need a plan here.
>>> > > >
>>> > > > Ilya.
>>> > > >
>>> > > >
>>> > > > --
>>> > > > Ilya Kasnacheev
>>> > > >
>>> > > > 2018-02-05 13:00 GMT+03:00 Anton Vinogradov <
>>> avinogra...@gridgain.com
>>> > >:
>>> > > >
>>> > > > > Ilya,
>>> > > > >
>>> > > > > 1) I don't think it's a good idea to rename classes to
>>> > > *AbstractTest.java
>>> > > > > since they already have abstract word at definition.
>>> > > > > We can perform such renaming only in case whole project will be
>>> > > > refactored,
>>> > > > > but I see no reason to do this.
>>> > > > >
>>> > > > > 2) All not included test should be included to appropriate
>>> siutes.
>>> > > > > Creating IgniteLostAndFoundTestSuite,java is not acceptable.
>>> > > > >
>>> > > > > 3) In case you're not sure what to do with particular tests,
>>> please
>>> > > > provide
>>> > > > > lists of such tests. Please group tests by "problem".
>>> > > > >
>>> > > > >
>>> > > > > On Fri, Feb 2, 2018 at 12:28 AM, Dmitry Pavlov <
>>> > dpavlov@gmail.com>
>>> > 

[GitHub] ignite pull request #3877: IGNITE-8325 Compressor thread may miss notificati...

[glukos]

GitHub user glukos opened a pull request:

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

IGNITE-8325 Compressor thread may miss notification on stop



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

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

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

https://github.com/apache/ignite/pull/3877.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 #3877


commit d5916da01a041a870a930c90134dd95b8d2030f5
Author: Ivan Rakov 
Date:   2018-04-19T13:38:39Z

IGNITE-8325 Compressor thread may miss notification on stop




---

[jira] [Created] (IGNITE-8325) Compressor thread may miss notification on stop

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8325:


 Summary: Compressor thread may miss notification on stop
 Key: IGNITE-8325
 URL: https://issues.apache.org/jira/browse/IGNITE-8325
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk


I saw the following hang on TC:

{code}
"main" #1 prio=5 os_prio=0 tid=0x7f76b800d000 nid=0x33bf in Object.wait() 
[0x7f76be6ce000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1245)
- locked <0xa50d52e0> (a 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor)
at java.lang.Thread.join(Thread.java:1319)
at 
org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:7688)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.shutdown(FileWriteAheadLogManager.java:1993)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.access$800(FileWriteAheadLogManager.java:1775)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.stop0(FileWriteAheadLogManager.java:520)
at 
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:941)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2240)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2118)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
- locked <0xa58a3978> (a 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
at org.apache.ignite.Ignition.stop(Ignition.java:229)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1081)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1124)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1102)
at 
org.apache.ignite.internal.processors.cache.persistence.db.wal.WalCompactionTest.afterTest(WalCompactionTest.java:98)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1687)
at 
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
at junit.framework.TestCase.runBare(TestCase.java:146)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:83)
at 
org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:84)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1107)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)

[GitHub] ignite pull request #3876: IGNITE-8092 Put hang on destroy.

[xtern]

GitHub user xtern opened a pull request:

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

IGNITE-8092 Put hang on destroy.



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

$ git pull https://github.com/xtern/ignite IGNITE-8092

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

https://github.com/apache/ignite/pull/3876.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 #3876


commit 14c62b87992013faf849d9d39f4a7bf9f0bdd715
Author: pereslegin-pa 
Date:   2018-04-19T13:06:59Z

IGNITE-8092 Put hang on destroy.




---

[jira] [Created] (IGNITE-8324) Ignite Cache Restarts 1 suite hangs with assertion error

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8324:
---

 Summary: Ignite Cache Restarts 1 suite hangs with assertion error
 Key: IGNITE-8324
 URL: https://issues.apache.org/jira/browse/IGNITE-8324
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.4
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.5


{noformat}
[ERROR][exchange-worker-#620749%replicated.GridCacheReplicatedNodeRestartSelfTest0%][GridDhtPartitionsExchangeFuture]
 Failed to notify listener: 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2@6dd7cc93
java.lang.AssertionError: Invalid topology version [grp=ignite-sys-cache, 
topVer=AffinityTopologyVersion [topVer=323, minorTopVer=0], 
exchTopVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], 
discoCacheVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], 
exchDiscoCacheVer=AffinityTopologyVersion [topVer=323, minorTopVer=0], 
fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
[evtNode=TcpDiscoveryNode [id=48a5d243-7f63-4069-aba1-868c6895, 
addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, 
intOrder=163, lastExchangeTime=1524043684082, loc=false, 
ver=2.5.0#20180417-sha1:56be24b9, isClient=false], topVer=322, 
nodeId8=b51b3893, msg=Node joined: TcpDiscoveryNode 
[id=48a5d243-7f63-4069-aba1-868c6895, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, intOrder=163, 
lastExchangeTime=1524043684082, loc=false, ver=2.5.0#20180417-sha1:56be24b9, 
isClient=false], type=NODE_JOINED, tstamp=1524043684166], crd=TcpDiscoveryNode 
[id=b51b3893-377a-465f-88ea-316a6560, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1524043633288, loc=true, ver=2.5.0#20180417-sha1:56be24b9, 
isClient=false], exchId=GridDhtPartitionExchangeId 
[topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], 
discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=48a5d243-7f63-4069-aba1-868c6895, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, intOrder=163, 
lastExchangeTime=1524043684082, loc=false, ver=2.5.0#20180417-sha1:56be24b9, 
isClient=false], topVer=322, nodeId8=b51b3893, msg=Node joined: 
TcpDiscoveryNode [id=48a5d243-7f63-4069-aba1-868c6895, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47503], discPort=47503, order=322, intOrder=163, 
lastExchangeTime=1524043684082, loc=false, ver=2.5.0#20180417-sha1:56be24b9, 
isClient=false], type=NODE_JOINED, tstamp=1524043684166], nodeId=48a5d243, 
evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=true, hash=527135060], init=true, 
lastVer=GridCacheVersion [topVer=135523955, order=1524043694535, nodeOrder=3], 
partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=322, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], futures=[]], 
AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion [topVer=322, 
minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], futures=[]], 
LocalTxReleaseFuture [topVer=AffinityTopologyVersion [topVer=322, 
minorTopVer=0], futures=[]], AllTxReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=322, minorTopVer=0], futures=[RemoteTxReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=322, minorTopVer=0], futures=[]], 
exchActions=null, affChangeMsg=null, initTs=1524043684166, 
centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
done=false, state=CRD, evtLatch=0, remaining=[], super=GridFutureAdapter 
[ignoreInterrupts=false, state=INIT, res=null, hash=1570781250]]]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateTopologyVersion(GridDhtPartitionTopologyImpl.java:257)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updateTopologies(GridDhtPartitionsExchangeFuture.java:845)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2461)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2200)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:127)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2057)
at 

[GitHub] ignite pull request #3862: Ignite-8082 ZK MBean

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3864: IGNITE-8021 Fix test issues

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Apache Ignite RPM packaging (Stage II)

[Ilya Kasnacheev]

Hello!

I recommend inclusion of this change so that it can make way into 2.5.

Regards,

-- 
Ilya Kasnacheev

2018-04-19 9:03 GMT+03:00 Petr Ivanov :

> There is not much time left for Apache Ignite 2.5 release, so let’s move
> stage II of packaging architecture implementation (with additional split
> scheme discussion) to 2.6 scope.
>
> Instead, I’d like to include DEB package to Apache Ignite 2.5 release.
> Corresponding PR is already prepared [1].
>
> Also, I’ll try to prepare modifications for release procedure scripts to
> automate uploading packages to our new Bintray RPM and DEB repositories
> before the code freeze.
>
>
> [1] https://github.com/apache/ignite/pull/3869  ignite/pull/3869>
>
>
>
> > On 18 Apr 2018, at 14:44, Ilya Kasnacheev 
> wrote:
> >
> > Copying anything manually to anywhere /usr (excluding /usr/local) is an
> > example of slackwarization that package users and creators try to avoid.
> >
> >> By linux file hierarchy convention, home dir should be in /usr/lib
> >
> > Citation needed! I bet you're interpreting it wrong, since I've listed a
> > random dir in /var/lib, and:
> > ~/w/incubator-ignite% sudo ls -al /var/lib/lightdm
> > drwxr-x---  6 lightdm lightdm 4096 авг 14  2017 .
> > drwxr-xr-x 89 rootroot4096 мар 10 22:37 ..
> > drwxrwxr-x  4 lightdm lightdm 4096 июл 19  2017 .cache
> > drwxr-xr-x  5 lightdm lightdm 4096 июл 19  2017 .config
> > drwx--  2 lightdm lightdm 4096 апр 11 18:25 .gconf
> > drwxr-xr-x  3 lightdm lightdm 4096 июл 19  2017 .local
> > -rw---  1 lightdm lightdm  283 апр 11 18:25 .Xauthority
> >
> > ...it definitely looks like a home dir. Which goes with additional
> benefit
> > of being writable by end-user.
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-04-16 9:22 GMT+03:00 Petr Ivanov :
> >
> >>
> >>
> >>> On 15 Apr 2018, at 10:19, Ilya Kasnacheev 
> >> wrote:
> >>>
> >>> Hello!
> >>>
> >>> With existing binary archive, user can move directories from
> >>> apache-ignite-fabric/libs/optional to apache-ignite-fabric/libs to
> >> activate
> >>> them.
> >>>
> >>> But with RPM, user should not contemplate moving directories from
> >>> /usr/lib/apache-ignite/optional to /usr/lib/apache-ignite.
> >>
> >> I always thought of that option as COPYING optional libs, not MOVING.
> >>
> >>
> >>>
> >>>
> >>> User lacks permissions for that operation and it would defeat the
> purpose
> >>> of having a RPM (imagine trying to upgrade Ignite RPM version with a
> >> setup
> >>> like that). "Turning distribution into Slackware" should not be an
> >> offering.
> >>
> >> Can’t imagine use case where Apache Ignite software is installed by one
> >> user, and run by another, without sudo/root permissions.
> >> Yet, ignite user’s login shell is disabled indeed and without sudo/root
> >> permissions optional libs cannot be copied.
> >> Also — the symlinks is a good idea, but I’ve already thought of it and
> I’m
> >> planning addition of special utility for enabling / disabling optional
> libs
> >> (like a2enable/a2disable) in next development iteration.
> >>
> >>
> >>>
> >>> How it could work: Imagine we create /var/lib/ignite, use it as
> >>> IGNITE_HOME, add symlinks from files in /usr/lib to /var/lib/ignite.
> This
> >>> way, we can add and remove symlinks to modules in optional/, and thus
> >>> enable and disable them as user sees fit.
> >>
> >> By linux file hierarchy convention, home dir should be in /usr/lib.
> >> /var/lib/ is currently used for working files (MySQL alike).
> >>
> >>
> >>>
> >>> This also answers the problem of "what's IGNITE_HOME for visor launched
> >>> from /usr/bin”
> >>
> >> That is addressed in separate task and will be fixed with minor startup
> >> script redesign with universal location-independent solution.
> >>
> >>
> >>>
> >>> But obviously this will require dedication and effort.
> >>
> >> No problems with efforts after final design is discussed an agreed.
> >>
> >>
> >>>
> >>>
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>> 2018-04-14 8:03 GMT+03:00 Peter Ivanov :
> >>>
>  Current packages design (after installation) does not differ from
> binary
>  archive - everything works (except necessity to run service instead
>  ignite.sh) just the same way, including libs/optional.
> 
>  Also, there can be issues with system JDK version by default, but
> every
>  problem will be in journalctl and/or  /var/log, and package has strong
>  dependency on any implementation of JDK 1.8.
> 
> 
>  I am lacking enough feedback about Apache Ignite from packages from
> real
>  users, don’t know real use cases so still "moving in the dark".
> 
> 
>  On Fri, 13 Apr 2018 at 22:18, Denis Magda  wrote:
> 
> > Ilya,
> >
> > Thanks for your inputs. The reason why we decided to split Ignite
> into
> > several packages mimics the 

[jira] [Created] (IGNITE-8323) Assertion error during simultaneous auto-activation and manual activation

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8323:


 Summary: Assertion error during simultaneous auto-activation and 
manual activation
 Key: IGNITE-8323
 URL: https://issues.apache.org/jira/browse/IGNITE-8323
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk


I observe the following assertion in IgnitePdsDestroyCacheTest.testDestroyCaches
{code}
[2018-04-19 
15:31:02,994][ERROR][tcp-disco-msg-worker-#131%persistence.IgnitePdsDestroyCacheTest0%][TcpDiscoverySpi]
 Failed to unmarshal discovery custom message.
java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=3, 
minorTopVer=1], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1], 
customMsg=ChangeGlobalStateMessage 
[id=59bcd2ed261-f35bb298-fc8b-46dd-9d06-7800f7c11d67, 
reqId=01b3cf41-63e0-4ddc-80bc-a3e9b5414c14, 
initiatingNodeId=0fc03864-7d8a-49bb-ba8a-ff6fb8c0, activate=true, 
baselineTopology=BaselineTopology [id=0, branchingHash=-1713401276, 
branchingType='Cluster activation', 
baselineNodes=[c2d35f40-7229-43b3-9342-305eb5a63897, 
f79b6d68-feaa-4b75-805a-8287b396b3eb, 442fe461-480c-4b32-8b81-28af4f66e165]], 
forceChangeBaselineTopology=false, timestamp=1524141062984]
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:174)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3371)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:694)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
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)
{code}

>From a quick investigation I see that this topology version is updated from 
>both auto-activation and manual activation requests.



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

[jira] [Created] (IGNITE-8322) Yardstick benchmark preloading option

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-8322:


 Summary: Yardstick benchmark preloading option
 Key: IGNITE-8322
 URL: https://issues.apache.org/jira/browse/IGNITE-8322
 Project: Ignite
  Issue Type: Improvement
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin


Yardstick has no benchmarks with eviction on the disk (PDS). For that puspose 
we need following:
1. Make new configuration and put every cache into a separate date region:
atomic,tx,atomic-index,query,compute
2. Add a new preload option for a benchmark: preload up to a size passed from 
that option. There two options:
 * total size of preload data (bytes)
 * the size of data in memory against total size (percent)



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

Re: Can't run CPP tests locally on linux machine

[Nikolay Izhikov]

Igor.

Following settings helps to remove some error, but I still can't make all 
things works.
Is it right way to get things work?

```
> export LDFLAGS='-L/usr/lib/x86_64-linux-gnu/'
> export LIBS='-lboost_unit_test_framework'
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure --enable-odbc --enable-tests
> make
```

Now, It seems that compiler can found references to boost functions.
The only error I see from the output is

make[3]: вход в каталог 
«/home/dragon/src/ignite/modules/platforms/cpp/odbc-test»
  CXXLDignite-odbc-tests
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

I work on Ubuntu linux x64:

```
> uname -a
Linux host 4.13.0-38-generic #43-Ubuntu SMP Wed Mar 14 15:20:44 UTC 2018 x86_64 
x86_64 x86_64 GNU/Linux
```

В Чт, 19/04/2018 в 13:40 +0300, Nikolay Izhikov пишет:
> Hello, Igor.
> 
> Still doesn't work.
> 
> I removed files you mentioned and got following error messages:
> 
> make[3]: вход в каталог 
> «/home/dragon/src/ignite/modules/platforms/cpp/odbc-test»
>   CXXLDignite-odbc-tests
> /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In 
> function `_start':
> (.text+0x20): undefined reference to `main'
> src/cursor_test.o: In function `CheckCursorNeedUpdate(ignite::odbc::Cursor&)':
> /home/dragon/src/ignite/modules/platforms/cpp/odbc-test/src/cursor_test.cpp:77:
>  undefined reference to 
> `boost::unit_test::unit_test_log_t::set_checkpoint(boost::unit_test::basic_cstring  const>,
> unsigned long, boost::unit_test::basic_cstring)'
> 
> 
> В Чт, 19/04/2018 в 13:15 +0300, Igor Sapego пишет:
> > They can be executed locally, and no, you don't need any library.
> > It is just that Teamcity plugin depends on exact version of Boost,
> > as I mentioned before. You can disable it if you are going to run
> > tests locally.
> > 
> > For this you should remove from these files
> > platform/cpp/core-test/Makefile.am and
> > platform/cpp/odcs-test/Makefile.am
> > 
> > following lines:
> > src/teamcity_messages.cpp \
> > src/teamcity_boost.cpp \
> > 
> > 
> > Best Regards,
> > Igor
> > 
> > On Wed, Apr 18, 2018 at 6:17 PM, Nikolay Izhikov 
> > wrote:
> > 
> > > Igor.
> > > 
> > > I tried to comment unexisted header and got following error:
> > > 
> > > src/teamcity/teamcity_boost.cpp: In constructor ‘JetBrains::
> > > TeamcityFormatterRegistrar::TeamcityFormatterRegistrar()’:
> > > src/teamcity/teamcity_boost.cpp:72:100: error: invalid new-expression of
> > > abstract class type ‘JetBrains::TeamcityBoostLogFormatter’
> > >  boost::unit_test::unit_test_log.set_formatter(new JetBrains::
> > > TeamcityBoostLogFormatter());
> > > 
> > > Do I need some additional team city library for tets?
> > > Can tests for odbc be executed locally?
> > > 
> > > В Ср, 18/04/2018 в 16:29 +0300, Igor Sapego пишет:
> > > > I think it is better to remove this strong dependency on the
> > > > exact Boost version at all. I've filed a ticket for that: [1].
> > > > 
> > > > [1] - https://issues.apache.org/jira/browse/IGNITE-8310
> > > > 
> > > > Best Regards,
> > > > Igor
> > > > 
> > > > On Wed, Apr 18, 2018 at 4:20 PM, Nikolay Izhikov 
> > > 
> > > wrote:
> > > > > Hello, Igor.
> > > > > 
> > > > > Thanks!
> > > > > I will try to find boost-1.58.0 distribution and setup it.
> > > > > 
> > > > > > 2. Well, it is the old issue that we are working only with the
> > > 
> > > specific> Boost version (1.58.0). You can try commenting out the following
> > > line:>
> > > > > 
> > > > > Should we mention it in DEVNOTES?
> > > > > Should we add some readme to setup development environment for CPP
> > > 
> > > module?
> > > > > 
> > > > > В Ср, 18/04/2018 в 16:11 +0300, Igor Sapego пишет:
> > > > > > Hi, Nikolay,
> > > > > > 
> > > > > > 1. Yes, it's OK;
> > > > > > 2. Well, it is the old issue that we are working only with the
> > > 
> > > specific
> > > > > > Boost version (1.58.0). You can try commenting out the following
> > > 
> > > line:
> > > > > > 
> > > > > > #include 
> > > > > > 
> > > > > > in teamcity_boost.cpp files to make it working with your version.
> > > > > > 
> > > > > > Best Regards,
> > > > > > Igor
> > > > > > 
> > > > > > On Wed, Apr 18, 2018 at 3:55 PM, Nikolay Izhikov <
> > > 
> > > nizhi...@apache.org>
> > > > > > wrote:
> > > > > > 
> > > > > > > Hello, Igniters.
> > > > > > > 
> > > > > > > Is there way to run CPP tests locally on linux machine?
> > > > > > > 
> > > > > > > I'm trying to follow DEVNOTES.txt but doesn't get lucky.
> > > > > > > 
> > > > > > > 1. `./configure --enable-odbc --enable-tests` [1]
> > > > > > > I see
> > > > > > > 
> > > > > > > "rm: cannot remove 'core': Is a directory"
> > > > > > > 
> > > > > > > Is it OK?
> > > > > > > 
> > > > > > > 2. `make` [2]
> > > > > > > 
> > > > > > > I got following error:
> > > > > > > 
> > > > > > 

Re: Can't run CPP tests locally on linux machine

[Nikolay Izhikov]

Hello, Igor.

Still doesn't work.

I removed files you mentioned and got following error messages:

make[3]: вход в каталог 
«/home/dragon/src/ignite/modules/platforms/cpp/odbc-test»
  CXXLDignite-odbc-tests
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'
src/cursor_test.o: In function `CheckCursorNeedUpdate(ignite::odbc::Cursor&)':
/home/dragon/src/ignite/modules/platforms/cpp/odbc-test/src/cursor_test.cpp:77: 
undefined reference to 
`boost::unit_test::unit_test_log_t::set_checkpoint(boost::unit_test::basic_cstring,
unsigned long, boost::unit_test::basic_cstring)'


В Чт, 19/04/2018 в 13:15 +0300, Igor Sapego пишет:
> They can be executed locally, and no, you don't need any library.
> It is just that Teamcity plugin depends on exact version of Boost,
> as I mentioned before. You can disable it if you are going to run
> tests locally.
> 
> For this you should remove from these files
> platform/cpp/core-test/Makefile.am and
> platform/cpp/odcs-test/Makefile.am
> 
> following lines:
> src/teamcity_messages.cpp \
> src/teamcity_boost.cpp \
> 
> 
> Best Regards,
> Igor
> 
> On Wed, Apr 18, 2018 at 6:17 PM, Nikolay Izhikov 
> wrote:
> 
> > Igor.
> > 
> > I tried to comment unexisted header and got following error:
> > 
> > src/teamcity/teamcity_boost.cpp: In constructor ‘JetBrains::
> > TeamcityFormatterRegistrar::TeamcityFormatterRegistrar()’:
> > src/teamcity/teamcity_boost.cpp:72:100: error: invalid new-expression of
> > abstract class type ‘JetBrains::TeamcityBoostLogFormatter’
> >  boost::unit_test::unit_test_log.set_formatter(new JetBrains::
> > TeamcityBoostLogFormatter());
> > 
> > Do I need some additional team city library for tets?
> > Can tests for odbc be executed locally?
> > 
> > В Ср, 18/04/2018 в 16:29 +0300, Igor Sapego пишет:
> > > I think it is better to remove this strong dependency on the
> > > exact Boost version at all. I've filed a ticket for that: [1].
> > > 
> > > [1] - https://issues.apache.org/jira/browse/IGNITE-8310
> > > 
> > > Best Regards,
> > > Igor
> > > 
> > > On Wed, Apr 18, 2018 at 4:20 PM, Nikolay Izhikov 
> > 
> > wrote:
> > > > Hello, Igor.
> > > > 
> > > > Thanks!
> > > > I will try to find boost-1.58.0 distribution and setup it.
> > > > 
> > > > > 2. Well, it is the old issue that we are working only with the
> > 
> > specific> Boost version (1.58.0). You can try commenting out the following
> > line:>
> > > > 
> > > > Should we mention it in DEVNOTES?
> > > > Should we add some readme to setup development environment for CPP
> > 
> > module?
> > > > 
> > > > В Ср, 18/04/2018 в 16:11 +0300, Igor Sapego пишет:
> > > > > Hi, Nikolay,
> > > > > 
> > > > > 1. Yes, it's OK;
> > > > > 2. Well, it is the old issue that we are working only with the
> > 
> > specific
> > > > > Boost version (1.58.0). You can try commenting out the following
> > 
> > line:
> > > > > 
> > > > > #include 
> > > > > 
> > > > > in teamcity_boost.cpp files to make it working with your version.
> > > > > 
> > > > > Best Regards,
> > > > > Igor
> > > > > 
> > > > > On Wed, Apr 18, 2018 at 3:55 PM, Nikolay Izhikov <
> > 
> > nizhi...@apache.org>
> > > > > wrote:
> > > > > 
> > > > > > Hello, Igniters.
> > > > > > 
> > > > > > Is there way to run CPP tests locally on linux machine?
> > > > > > 
> > > > > > I'm trying to follow DEVNOTES.txt but doesn't get lucky.
> > > > > > 
> > > > > > 1. `./configure --enable-odbc --enable-tests` [1]
> > > > > > I see
> > > > > > 
> > > > > > "rm: cannot remove 'core': Is a directory"
> > > > > > 
> > > > > > Is it OK?
> > > > > > 
> > > > > > 2. `make` [2]
> > > > > > 
> > > > > > I got following error:
> > > > > > 
> > > > > > "src/teamcity/teamcity_boost.cpp:22:10: fatal error:
> > > > > > boost/test/unit_test_suite_impl.hpp: Нет такого файла или каталога
> > > > > >  #include "
> > > > > > 
> > > > > > I've installed boost-dev - `sudo apt-get install libboost-all-dev`
> > > > > > But, there is no `unit_test_suite_impl.hpp` in
> > 
> > /usr/header/boost/test.
> > > > > > Without tests it all compiles OK.
> > > > > > 
> > > > > > What should I do to be able run tests for CPP locally?
> > > > > > 
> > > > > > [1] https://gist.github.com/nizhikov/
> > 
> > 8a451b73db17fa05d10992ae50524b7b
> > > > > > [2] https://gist.github.com/nizhikov/
> > 
> > 9d0da202c3e52f3ee1cd5bc2053e1073
> > > 
> > > 

signature.asc
Description: This is a digitally signed message part

[jira] [Created] (IGNITE-8321) Web console: Wrong layout in data storage configuration of cluster

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-8321:
-

 Summary: Web console: Wrong layout in data storage configuration 
of cluster
 Key: IGNITE-8321
 URL: https://issues.apache.org/jira/browse/IGNITE-8321
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Vasiliy Sisko
Assignee: Ilya Borisov


In data storage configuration of cluster:
# By 3 fields in line.
# Missed selection of: s, ms, ns for Metric rate time interval.

In Discovery configuration of cluster:
# By 3 fields in line.

In Connector configuration of cluster:
# By 3 fields in line.

In Client Connector configuration of cluster:
# By 3 fields in line.

In Query configuration of cluster for Ignite 2.1:
# By 3 fields in line.

In Rebalance configuration of cache:
# By 3 fields in line.



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

Re: Can't run CPP tests locally on linux machine

[Igor Sapego]

They can be executed locally, and no, you don't need any library.
It is just that Teamcity plugin depends on exact version of Boost,
as I mentioned before. You can disable it if you are going to run
tests locally.

For this you should remove from these files
platform/cpp/core-test/Makefile.am and
platform/cpp/odcs-test/Makefile.am

following lines:
src/teamcity_messages.cpp \
src/teamcity_boost.cpp \


Best Regards,
Igor

On Wed, Apr 18, 2018 at 6:17 PM, Nikolay Izhikov 
wrote:

> Igor.
>
> I tried to comment unexisted header and got following error:
>
> src/teamcity/teamcity_boost.cpp: In constructor ‘JetBrains::
> TeamcityFormatterRegistrar::TeamcityFormatterRegistrar()’:
> src/teamcity/teamcity_boost.cpp:72:100: error: invalid new-expression of
> abstract class type ‘JetBrains::TeamcityBoostLogFormatter’
>  boost::unit_test::unit_test_log.set_formatter(new JetBrains::
> TeamcityBoostLogFormatter());
>
> Do I need some additional team city library for tets?
> Can tests for odbc be executed locally?
>
> В Ср, 18/04/2018 в 16:29 +0300, Igor Sapego пишет:
> > I think it is better to remove this strong dependency on the
> > exact Boost version at all. I've filed a ticket for that: [1].
> >
> > [1] - https://issues.apache.org/jira/browse/IGNITE-8310
> >
> > Best Regards,
> > Igor
> >
> > On Wed, Apr 18, 2018 at 4:20 PM, Nikolay Izhikov 
> wrote:
> > > Hello, Igor.
> > >
> > > Thanks!
> > > I will try to find boost-1.58.0 distribution and setup it.
> > >
> > > > 2. Well, it is the old issue that we are working only with the
> specific> Boost version (1.58.0). You can try commenting out the following
> line:>
> > >
> > > Should we mention it in DEVNOTES?
> > > Should we add some readme to setup development environment for CPP
> module?
> > >
> > > В Ср, 18/04/2018 в 16:11 +0300, Igor Sapego пишет:
> > > > Hi, Nikolay,
> > > >
> > > > 1. Yes, it's OK;
> > > > 2. Well, it is the old issue that we are working only with the
> specific
> > > > Boost version (1.58.0). You can try commenting out the following
> line:
> > > >
> > > > #include 
> > > >
> > > > in teamcity_boost.cpp files to make it working with your version.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > > On Wed, Apr 18, 2018 at 3:55 PM, Nikolay Izhikov <
> nizhi...@apache.org>
> > > > wrote:
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > Is there way to run CPP tests locally on linux machine?
> > > > >
> > > > > I'm trying to follow DEVNOTES.txt but doesn't get lucky.
> > > > >
> > > > > 1. `./configure --enable-odbc --enable-tests` [1]
> > > > > I see
> > > > >
> > > > > "rm: cannot remove 'core': Is a directory"
> > > > >
> > > > > Is it OK?
> > > > >
> > > > > 2. `make` [2]
> > > > >
> > > > > I got following error:
> > > > >
> > > > > "src/teamcity/teamcity_boost.cpp:22:10: fatal error:
> > > > > boost/test/unit_test_suite_impl.hpp: Нет такого файла или каталога
> > > > >  #include "
> > > > >
> > > > > I've installed boost-dev - `sudo apt-get install libboost-all-dev`
> > > > > But, there is no `unit_test_suite_impl.hpp` in
> /usr/header/boost/test.
> > > > > Without tests it all compiles OK.
> > > > >
> > > > > What should I do to be able run tests for CPP locally?
> > > > >
> > > > > [1] https://gist.github.com/nizhikov/
> 8a451b73db17fa05d10992ae50524b7b
> > > > > [2] https://gist.github.com/nizhikov/
> 9d0da202c3e52f3ee1cd5bc2053e1073
> >
> >
>

[GitHub] ignite pull request #2878: IGNITE-6666

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-8320) Page corruption during the rebalancing cache.

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-8320:
---

 Summary: Page corruption during the rebalancing cache.
 Key: IGNITE-8320
 URL: https://issues.apache.org/jira/browse/IGNITE-8320
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.4
Reporter: Vyacheslav Koptilin


Cache rebalance may result in page memory corruption.

{code}
[2018-04-18T14:33:23,260][ERROR][sys-#54][GridCacheIoManager] Failed processing 
message [senderId=95f06c25-e6bb-48f7-a3e5-4c05fc1c49be, 
msg=GridDhtPartitionSupplyMessage [rebalanceId=37, 
topVer=AffinityTopologyVersion [topVer=53, minorTopVer=1], missed=null, 
clean=null, msgSize=525350, estimatedKeysCnt=1690216, size=2, parts=[1, 2], 
super=GridCacheGroupIdMessage [grpId=-1831596270]]]
 org.apache.ignite.IgniteException: Runtime failure on row: Row@33b6805c[ key: 
 [idHash=773709078, hash=-630455542, ...], val:  [idHash=1309051286, 
hash=-1321165334, ver: GridCacheVersion [topVer=135435024, order=1523963943331, 
nodeOrder=4] ]
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
 ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:454)
 ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:653)
 ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1866)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1391)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1255)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1451)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:352)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2735)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:823)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:704)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:347)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:365)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:355)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:99)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1603)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:126)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 

[GitHub] ignite pull request #3875: IGNITE-8190 Print out an information message when...

[alex-plekhanov]

GitHub user alex-plekhanov opened a pull request:

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

IGNITE-8190 Print out an information message when local node is not in 
baseline



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

$ git pull https://github.com/alex-plekhanov/ignite ignite-8190

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

https://github.com/apache/ignite/pull/3875.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 #3875


commit 51c1194d5048a9b47deccbf694b33f20deddf82b
Author: Aleksey Plekhanov 
Date:   2018-04-18T16:31:35Z

IGNITE-8190 Print out an information message when local node is not in 
baseline

commit db424eca8bbea69b192a31764416569b99a5a02a
Author: Aleksey Plekhanov 
Date:   2018-04-19T09:55:29Z

IGNITE-8190 Unit test

commit d8501eadf7c89b4d3a60e50b1167b92f70f91176
Author: Aleksey Plekhanov 
Date:   2018-04-19T09:56:05Z

IGNITE-8190 Unit test removed




---

[jira] [Created] (IGNITE-8319) Examples do not launch from Intellij Idea because ML module is configured incorrectly.

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-8319:


 Summary: Examples do not launch from Intellij Idea because ML 
module is configured incorrectly.
 Key: IGNITE-8319
 URL: https://issues.apache.org/jira/browse/IGNITE-8319
 Project: Ignite
  Issue Type: Bug
Reporter: Oleg Ostanin


Examples do not launch from Intellij Idea because ML module is configured 
incorrectly.



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

[GitHub] ignite pull request #3874: IGNITE-7319: Cancelable future task for backup cl...

[aealeksandrov]

GitHub user aealeksandrov opened a pull request:

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

IGNITE-7319: Cancelable future task for backup cleaner should be closed on 
CacheContinuousQueryManager stop

When cache is created then new CONTINUOUS_QUERY task is created too. This 
task should work until it canceled but in Ignite code we don't store the 
CancelableTask somewhere. After destroying the cache this task continue its 
work.

Now this issue is fixed.

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

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

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

https://github.com/apache/ignite/pull/3874.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 #3874


commit e1826b023834872b8b09fbf820054f2c23a34b25
Author: Andrei Aleksandrov 
Date:   2018-04-19T09:09:12Z

IGNITE-7319: Cancelable future task for backup cleaner should be closed on 
CacheContinuousQueryManager stop




---

[GitHub] ignite pull request #3873: IGNITE-5979

[dgarus]

GitHub user dgarus opened a pull request:

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

IGNITE-5979



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

$ git pull https://github.com/dgarus/ignite ignite-5979

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

https://github.com/apache/ignite/pull/3873.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 #3873


commit 72c62bdd076ea5d49c49130b1292fef6be21244c
Author: denis.garus 
Date:   2018-04-19T07:21:26Z

IGNITE-5979 changes for TC build

commit 310ae470bb2b76afcb47e6c72246f69116abe3c9
Author: denis.garus 
Date:   2018-04-19T08:04:53Z

IGNITE-5979 start test 33 times on TC




---

[jira] [Created] (IGNITE-8318) MVCC TX: Scan query call throws an exception when it is mixed with Key-Value API in the same transaction.

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-8318:
--

 Summary: MVCC TX: Scan query call throws an exception when it is 
mixed with Key-Value API in the same transaction. 
 Key: IGNITE-8318
 URL: https://issues.apache.org/jira/browse/IGNITE-8318
 Project: Ignite
  Issue Type: Bug
  Components: cache, sql
Reporter: Roman Kondakov


Scan queries should not throw Exceptions in key-value API transactions.

Reproducer: {{CacheMvccTransactionsTest#testPutAllGetAll_SingleNode_Scan}}



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

[GitHub] ignite pull request #3867: IGNITE-4756 Print info about partition distributi...

[daradurvs]

Github user daradurvs closed the pull request at:

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


---

[GitHub] ignite pull request #3872: IGNITE-8315 Print info about partition distributi...

[daradurvs]

GitHub user daradurvs opened a pull request:

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

IGNITE-8315 Print info about partition distribution to log



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

$ git pull https://github.com/daradurvs/ignite ignite-8315

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

https://github.com/apache/ignite/pull/3872.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 #3872


commit b9993aa5ce2ecac1773b6be9733e6e5212cad5f6
Author: Vyacheslav Daradur 
Date:   2018-04-19T07:51:58Z

ignite-4756: implemented




---

[jira] [Created] (IGNITE-8317) Loader bug in safari

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-8317:


 Summary: Loader bug in safari
 Key: IGNITE-8317
 URL: https://issues.apache.org/jira/browse/IGNITE-8317
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin






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

[jira] [Created] (IGNITE-8316) Update RPM and DEB documentation

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8316:


 Summary: Update RPM and DEB documentation
 Key: IGNITE-8316
 URL: https://issues.apache.org/jira/browse/IGNITE-8316
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Peter Ivanov
 Fix For: 2.5


# Add DEB repository configuration and packages installation.
# Update RPM repository configuration and packages installation.



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

[jira] [Created] (IGNITE-8315) Prevent printing the partition distribution on clients nodes

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-8315:
--

 Summary: Prevent printing the partition distribution on clients 
nodes
 Key: IGNITE-8315
 URL: https://issues.apache.org/jira/browse/IGNITE-8315
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.6
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
 Fix For: 2.6


subj



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

Re: Apache Ignite RPM packaging (Stage II)

[Petr Ivanov]

There is not much time left for Apache Ignite 2.5 release, so let’s move stage 
II of packaging architecture implementation (with additional split scheme 
discussion) to 2.6 scope.

Instead, I’d like to include DEB package to Apache Ignite 2.5 release.
Corresponding PR is already prepared [1].

Also, I’ll try to prepare modifications for release procedure scripts to 
automate uploading packages to our new Bintray RPM and DEB repositories before 
the code freeze.


[1] https://github.com/apache/ignite/pull/3869 




> On 18 Apr 2018, at 14:44, Ilya Kasnacheev  wrote:
> 
> Copying anything manually to anywhere /usr (excluding /usr/local) is an
> example of slackwarization that package users and creators try to avoid.
> 
>> By linux file hierarchy convention, home dir should be in /usr/lib
> 
> Citation needed! I bet you're interpreting it wrong, since I've listed a
> random dir in /var/lib, and:
> ~/w/incubator-ignite% sudo ls -al /var/lib/lightdm
> drwxr-x---  6 lightdm lightdm 4096 авг 14  2017 .
> drwxr-xr-x 89 rootroot4096 мар 10 22:37 ..
> drwxrwxr-x  4 lightdm lightdm 4096 июл 19  2017 .cache
> drwxr-xr-x  5 lightdm lightdm 4096 июл 19  2017 .config
> drwx--  2 lightdm lightdm 4096 апр 11 18:25 .gconf
> drwxr-xr-x  3 lightdm lightdm 4096 июл 19  2017 .local
> -rw---  1 lightdm lightdm  283 апр 11 18:25 .Xauthority
> 
> ...it definitely looks like a home dir. Which goes with additional benefit
> of being writable by end-user.
> 
> -- 
> Ilya Kasnacheev
> 
> 2018-04-16 9:22 GMT+03:00 Petr Ivanov :
> 
>> 
>> 
>>> On 15 Apr 2018, at 10:19, Ilya Kasnacheev 
>> wrote:
>>> 
>>> Hello!
>>> 
>>> With existing binary archive, user can move directories from
>>> apache-ignite-fabric/libs/optional to apache-ignite-fabric/libs to
>> activate
>>> them.
>>> 
>>> But with RPM, user should not contemplate moving directories from
>>> /usr/lib/apache-ignite/optional to /usr/lib/apache-ignite.
>> 
>> I always thought of that option as COPYING optional libs, not MOVING.
>> 
>> 
>>> 
>>> 
>>> User lacks permissions for that operation and it would defeat the purpose
>>> of having a RPM (imagine trying to upgrade Ignite RPM version with a
>> setup
>>> like that). "Turning distribution into Slackware" should not be an
>> offering.
>> 
>> Can’t imagine use case where Apache Ignite software is installed by one
>> user, and run by another, without sudo/root permissions.
>> Yet, ignite user’s login shell is disabled indeed and without sudo/root
>> permissions optional libs cannot be copied.
>> Also — the symlinks is a good idea, but I’ve already thought of it and I’m
>> planning addition of special utility for enabling / disabling optional libs
>> (like a2enable/a2disable) in next development iteration.
>> 
>> 
>>> 
>>> How it could work: Imagine we create /var/lib/ignite, use it as
>>> IGNITE_HOME, add symlinks from files in /usr/lib to /var/lib/ignite. This
>>> way, we can add and remove symlinks to modules in optional/, and thus
>>> enable and disable them as user sees fit.
>> 
>> By linux file hierarchy convention, home dir should be in /usr/lib.
>> /var/lib/ is currently used for working files (MySQL alike).
>> 
>> 
>>> 
>>> This also answers the problem of "what's IGNITE_HOME for visor launched
>>> from /usr/bin”
>> 
>> That is addressed in separate task and will be fixed with minor startup
>> script redesign with universal location-independent solution.
>> 
>> 
>>> 
>>> But obviously this will require dedication and effort.
>> 
>> No problems with efforts after final design is discussed an agreed.
>> 
>> 
>>> 
>>> 
>>> --
>>> Ilya Kasnacheev
>>> 
>>> 2018-04-14 8:03 GMT+03:00 Peter Ivanov :
>>> 
 Current packages design (after installation) does not differ from binary
 archive - everything works (except necessity to run service instead
 ignite.sh) just the same way, including libs/optional.
 
 Also, there can be issues with system JDK version by default, but every
 problem will be in journalctl and/or  /var/log, and package has strong
 dependency on any implementation of JDK 1.8.
 
 
 I am lacking enough feedback about Apache Ignite from packages from real
 users, don’t know real use cases so still "moving in the dark".
 
 
 On Fri, 13 Apr 2018 at 22:18, Denis Magda  wrote:
 
> Ilya,
> 
> Thanks for your inputs. The reason why we decided to split Ignite into
> several packages mimics the reason why Java community introduced
>> modular
> subsystem for JDK. That's all about size. Ignite distribution is too
>> big,
> and we're trying to separate it into several components so that people
 can
> install only the features they need.
> 
> The point of a package is to ship something into root file system that
 can
>> be used from root file system. If cpp