Re: IGNITE-4437 Make sure data structures do not use outTx call

[Semyon Boikov]

Hi,

Yes, this was done as part of IGNITE-2893, I closed ticket.

Semyon

On Tue, May 2, 2017 at 4:33 PM, Дмитрий Рябов  wrote:

> Hello, igniters. Seems like someone already cut all outTx calls, because
> 2.0rc2 doesn't have any of them. So we can just close this ticket.
>

Re: partitions exchange protocol details question

[ALEKSEY KUZNETSOV]

I know this.
But the question was as follows.
Imagine, remaining set contains 2 nodes. It implies that both nodes had
sent two GridDhtPartitionsSingleMessage with the same exchangeId.
So, how could it possible 2 messages from different nodes has got equal
exchangeId.

ср, 3 мая 2017 г. в 19:23, Dmitry Pavlov :

> Hi, Aleksey,
>
> empty remaining set
>
> (org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#remaining)
> is the mandatory condition of sendAllPartitions() to be activated.
>
> When coordinator receives single partition message (
> GridDhtPartitionsSingleMessage), it removes one node from remaining set.
> The same is true for node left message.
>
> Best Regards,
> Dmitry Pavlov
>
> ср, 3 мая 2017 г. в 19:10, ALEKSEY KUZNETSOV :
>
> > Hi, Igntrs! When processing single partitions message in
> > GridDhtPartitionsExchangeFuture#processMessage() then , coordinator could
> > answer with GridDhtPartitionsFullMessage
> > from sendAllPartitions.
> > But the field GridDhtPartitionsExchangeFuture#remaining must be empty in
> > this case.
> >
> > I wounder, how could it be empty in case if "remaining" held 2 nodes, or
> > more ?
> >
> >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1904: IGNITE-1094 corrupted cache recovery resolved

[voipp]

GitHub user voipp opened a pull request:

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

IGNITE-1094 corrupted cache recovery resolved



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

$ git pull https://github.com/voipp/ignite Ignite-1094

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

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


commit e47ce114e6431cc55e58ea2fdcbdc53b93ea57df
Author: voipp 
Date:   2017-05-03T13:22:19Z

IGNITE-1094 corrupted cache recovery resolved




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1905: IGNITE-5128 Support queries for GridClientData

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-5128  Support queries for GridClientData



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

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

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

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


commit 67d0f08a0ff26d59cc6ef8ed57efd0b682779f78
Author: tledkov-gridgain 
Date:   2017-05-03T10:52:17Z

IGNITE-5128: Support queries for GridClientData based on rest protocol

commit 2d1dd52f291e8471cd6f194ef76a3130c72d57cb
Author: tledkov-gridgain 
Date:   2017-05-04T08:54:14Z

Merge branch '_master' into ignite-5128




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Apache Flink meets Apache Ignite next week in London

[Christos Erotocritou]

Hello Igniters of London,

I know this has be shared already, the fellas at Apache Flink will be hosting 
us this coming Wednesday, 10th of May, where we will dive into Ignite/Flink 
Integration.

Speaker Bio:

Akmal B. Chaudhri is a Technical Evangelist for GridGain, specializing in Big 
Data, NoSQL and NewSQL database technologies. His current interests also 
include Apache Spark, Machine Learning, Data Science and how to become a Data 
Scientist. He has over 25 years experience in IT and has previously held roles 
as a developer, consultant, product strategist and technical trainer. He has 
worked for several blue-chip companies, such as Reuters and IBM and also the 
Big Data startups Hortonworks (Hadoop) and DataStax (Cassandra NoSQL Database). 
He has regularly presented at many international conferences and served on the 
program committees for a number of major conferences and workshops. He has 
published and presented widely and edited or co-edited 10 books. He holds a BSc 
(1st Class Hons.) in Computing and Information Systems, MSc in Business Systems 
Analysis and Design and a PhD in Computer Science. He is a Member of the 
British Computer Society (MBCS) and a Chartered IT Professional (CITP).

Abstract:

Apache Ignite is a high-performance, integrated and distributed in-memory 
platform for computing and transacting on large-scale data sets in real-time, 
orders of magnitude faster than possible with traditional disk-based or flash 
technologies. Ignite as a collection of independent, well-integrated, in-memory 
components geared to improve performance and scalability of your application. 
Some of these components include: Advanced Clustering, Data Grid, SQL Grid, 
Streaming & CEP, Compute Grid, Service Grid, Ignite File System. Ignite also 
has integrations for accelerating data processing frameworks such as Hadoop and 
Spark. In addition to its own its own stream processing capability, 
integrations also exist for JMS, MQTT, Apache Flume, Apache Storm, Apache 
Kafka, Apache Camel, and Apache Flink, which will be covered in the session.

RSVP: https://www.meetup.com/Apache-Flink-London-Meetup/events/239663941/ 

We hope to see you there!

Cheers,
Christos

dynamic cache creation question

[ALEKSEY KUZNETSOV]

Hello, Igntrs!
When node dinamically creates new cache it sends
GridDhtPartitionsSingleMessage to coordinator so partition maps got redone.
Why it sends the message after cache creation?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: partitions exchange protocol details question

[Dmitry Pavlov]

Thank you for clarification.

All Single Message will have same exchange ID because single messages are
issued in one round of ExchangeFuture (one complete round of exchange is to
be finished before next will start).


Exchange ID on non coordinator nodes is filled in single messages
(GridDhtPartitionsSingleMessage) from
GridDhtPartitionsExchangeFuture#exchangeId field. Value of exchange ID is
the same in all nodes and content of exchange future is determined by
original event caused this exchange (e.g. node left, node joined, node
failed) for current topology version.


чт, 4 мая 2017 г. в 11:32, ALEKSEY KUZNETSOV :

> I know this.
> But the question was as follows.
> Imagine, remaining set contains 2 nodes. It implies that both nodes had
> sent two GridDhtPartitionsSingleMessage with the same exchangeId.
> So, how could it possible 2 messages from different nodes has got equal
> exchangeId.
>
> ср, 3 мая 2017 г. в 19:23, Dmitry Pavlov :
>
> > Hi, Aleksey,
> >
> > empty remaining set
> >
> >
> (org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#remaining)
> > is the mandatory condition of sendAllPartitions() to be activated.
> >
> > When coordinator receives single partition message (
> > GridDhtPartitionsSingleMessage), it removes one node from remaining set.
> > The same is true for node left message.
> >
> > Best Regards,
> > Dmitry Pavlov
> >
> > ср, 3 мая 2017 г. в 19:10, ALEKSEY KUZNETSOV :
> >
> > > Hi, Igntrs! When processing single partitions message in
> > > GridDhtPartitionsExchangeFuture#processMessage() then , coordinator
> could
> > > answer with GridDhtPartitionsFullMessage
> > > from sendAllPartitions.
> > > But the field GridDhtPartitionsExchangeFuture#remaining must be empty
> in
> > > this case.
> > >
> > > I wounder, how could it be empty in case if "remaining" held 2 nodes,
> or
> > > more ?
> > >
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[jira] [Created] (IGNITE-5162) Get rid of version-depended ODBC server code

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5162:
---

 Summary: Get rid of version-depended ODBC server code
 Key: IGNITE-5162
 URL: https://issues.apache.org/jira/browse/IGNITE-5162
 Project: Ignite
  Issue Type: Task
  Components: odbc
Affects Versions: 2.0
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.1


It is no longer needed as compatibility is broken.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5163) JDBC Driver: thin jdbc driver is based on pure TCP protocol

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5163:


 Summary: JDBC Driver: thin jdbc driver is based on pure TCP 
protocol
 Key: IGNITE-5163
 URL: https://issues.apache.org/jira/browse/IGNITE-5163
 Project: Ignite
  Issue Type: Task
  Components: jdbc-driver
Affects Versions: 1.9
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.1


The GridClient must be removed from thin jdbc driver.
It is the first step to unify JDBC & ODBC protocols.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

ignite-5097 is ready for review (BinaryMarshaller should write ints in "varint" encoding where it makes sense)

[Vyacheslav Daradur]

Hi Igniteres!

Java part is ready for review.

BinaryMarshaller should write ints in "varint" encoding where it makes sense

ci.tests 
PR 


-- 
Best Regards, Vyacheslav

[jira] [Created] (IGNITE-5164) Rename common ODBC/JDBC classes

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5164:
---

 Summary: Rename common ODBC/JDBC classes
 Key: IGNITE-5164
 URL: https://issues.apache.org/jira/browse/IGNITE-5164
 Project: Ignite
  Issue Type: Task
  Components: jdbc-driver, odbc
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.1






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1906: Ignite 4991

[rfqu]

GitHub user rfqu opened a pull request:

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

Ignite 4991

issue IGNITE-4991 fixed

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

$ git pull https://github.com/rfqu/ignite ignite-4991

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

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


commit d6e7050280817b4705302346e170a1809a3d1a91
Author: Ivan Rakov 
Date:   2017-05-03T08:24:01Z

IGNITE-5134: Fixed ClassCastException in IgniteCacheDatabaseSharedManager. 
This closes #1895.

commit ff08c8e09033a1a703aae602c36a21565fbae606
Author: Anton Vinogradov 
Date:   2017-05-03T09:49:18Z

Hibernate module deploy fix

commit af3bec468ebd82ccaba850843925b5709efe78d7
Author: rfqu 
Date:   2017-05-04T10:08:27Z

issue fixed: IGNITE-4991




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-5165) Web Console: Buttons redesign

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-5165:


 Summary: Web Console:  Buttons redesign 
 Key: IGNITE-5165
 URL: https://issues.apache.org/jira/browse/IGNITE-5165
 Project: Ignite
  Issue Type: Task
  Components: UI, wizards
Reporter: Dmitriy Shabalin
Assignee: Ilya Borisov


Create common style to all buttons in project.
Refactoring current style for buttons in 
web-console/frontend/public/stylesheets/style.scss
1) Button with icon and text
2) Button with only icon
3) Button with only text
4) Button group
5) fill and stroke buttons for color Red, Blue, White

Implement class modificator .btn-ignite to apply this features



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5166) .NET: ComputeTaskSession

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5166:
--

 Summary: .NET: ComputeTaskSession
 Key: IGNITE-5166
 URL: https://issues.apache.org/jira/browse/IGNITE-5166
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Reporter: Pavel Tupitsyn


See {{ComputeTaskSession}} in Java.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5167) ODBC: Abstract out handler and parser interfaces

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5167:
---

 Summary: ODBC: Abstract out handler and parser interfaces
 Key: IGNITE-5167
 URL: https://issues.apache.org/jira/browse/IGNITE-5167
 Project: Ignite
  Issue Type: Task
  Components: jdbc-driver, odbc, SQL
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.1


This is necessary for smooth thin JDBC driver integrration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1907: IGNITE-5167

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5167



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

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

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

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


commit 0b06343240d0d8988629bc854ff6b2707bc9d85e
Author: devozerov 
Date:   2017-05-04T11:07:59Z

Done.

commit e5f6141822edc00ae5225250701a0a90f85795ca
Author: devozerov 
Date:   2017-05-04T11:08:39Z

Minors.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Update docs reference on ignite.apache.org to the version 2.0.0

[Vladimir Ozerov]

Hi Mauricio,

As we've released Apache Ignite 2.0, may I ask you to update version of our
docs to 2.0.0 as per post-release step 3 on "Release Process" page [1]?

Regards,
Vladimir

[1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process

[jira] [Created] (IGNITE-5168) Expose IGFS metrics via an MBean or console Visor.

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-5168:
---

 Summary: Expose IGFS metrics via an MBean or console Visor.
 Key: IGNITE-5168
 URL: https://issues.apache.org/jira/browse/IGNITE-5168
 Project: Ignite
  Issue Type: New Feature
  Components: IGFS
Affects Versions: 2.0
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky


Now in Ignite the only way to see IGFS metrics is to get them programmically 
from the code. But customers need them to understand what is cached in IGFS, so 
to expose the metrics would be useful. 
There are options to expose the metrics via MBean and/or via console Visor 
interface.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: partitions exchange protocol details question

[ALEKSEY KUZNETSOV]

Thank you!

чт, 4 мая 2017 г. в 12:25, Dmitry Pavlov :

> Thank you for clarification.
>
> All Single Message will have same exchange ID because single messages are
> issued in one round of ExchangeFuture (one complete round of exchange is to
> be finished before next will start).
>
>
> Exchange ID on non coordinator nodes is filled in single messages
> (GridDhtPartitionsSingleMessage) from
> GridDhtPartitionsExchangeFuture#exchangeId field. Value of exchange ID is
> the same in all nodes and content of exchange future is determined by
> original event caused this exchange (e.g. node left, node joined, node
> failed) for current topology version.
>
>
> чт, 4 мая 2017 г. в 11:32, ALEKSEY KUZNETSOV :
>
> > I know this.
> > But the question was as follows.
> > Imagine, remaining set contains 2 nodes. It implies that both nodes had
> > sent two GridDhtPartitionsSingleMessage with the same exchangeId.
> > So, how could it possible 2 messages from different nodes has got equal
> > exchangeId.
> >
> > ср, 3 мая 2017 г. в 19:23, Dmitry Pavlov :
> >
> > > Hi, Aleksey,
> > >
> > > empty remaining set
> > >
> > >
> >
> (org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#remaining)
> > > is the mandatory condition of sendAllPartitions() to be activated.
> > >
> > > When coordinator receives single partition message (
> > > GridDhtPartitionsSingleMessage), it removes one node from remaining
> set.
> > > The same is true for node left message.
> > >
> > > Best Regards,
> > > Dmitry Pavlov
> > >
> > > ср, 3 мая 2017 г. в 19:10, ALEKSEY KUZNETSOV  >:
> > >
> > > > Hi, Igntrs! When processing single partitions message in
> > > > GridDhtPartitionsExchangeFuture#processMessage() then , coordinator
> > could
> > > > answer with GridDhtPartitionsFullMessage
> > > > from sendAllPartitions.
> > > > But the field GridDhtPartitionsExchangeFuture#remaining must be empty
> > in
> > > > this case.
> > > >
> > > > I wounder, how could it be empty in case if "remaining" held 2 nodes,
> > or
> > > > more ?
> > > >
> > > >
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1907: IGNITE-5167

[devozerov]

Github user devozerov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: partitions exchange protocol details question

[ALEKSEY KUZNETSOV]

As i understand Single message is sent when new node joins cluster , or
when node dynamically creates new cache.
So it sends Single message to coordinator and receives
GridDhtPartitionsFullMessage(holding edited partitions info).

Still hardly can understand how could it be two
GridDhtPartitionsSingleMessage with the same exchangeId? What is the
scenario of this situation

чт, 4 мая 2017 г. в 14:45, ALEKSEY KUZNETSOV :

> Thank you!
>
> чт, 4 мая 2017 г. в 12:25, Dmitry Pavlov :
>
>> Thank you for clarification.
>>
>> All Single Message will have same exchange ID because single messages are
>> issued in one round of ExchangeFuture (one complete round of exchange is
>> to
>> be finished before next will start).
>>
>>
>> Exchange ID on non coordinator nodes is filled in single messages
>> (GridDhtPartitionsSingleMessage) from
>> GridDhtPartitionsExchangeFuture#exchangeId field. Value of exchange ID is
>> the same in all nodes and content of exchange future is determined by
>> original event caused this exchange (e.g. node left, node joined, node
>> failed) for current topology version.
>>
>>
>> чт, 4 мая 2017 г. в 11:32, ALEKSEY KUZNETSOV :
>>
>> > I know this.
>> > But the question was as follows.
>> > Imagine, remaining set contains 2 nodes. It implies that both nodes had
>> > sent two GridDhtPartitionsSingleMessage with the same exchangeId.
>> > So, how could it possible 2 messages from different nodes has got equal
>> > exchangeId.
>> >
>> > ср, 3 мая 2017 г. в 19:23, Dmitry Pavlov :
>> >
>> > > Hi, Aleksey,
>> > >
>> > > empty remaining set
>> > >
>> > >
>> >
>> (org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#remaining)
>> > > is the mandatory condition of sendAllPartitions() to be activated.
>> > >
>> > > When coordinator receives single partition message (
>> > > GridDhtPartitionsSingleMessage), it removes one node from remaining
>> set.
>> > > The same is true for node left message.
>> > >
>> > > Best Regards,
>> > > Dmitry Pavlov
>> > >
>> > > ср, 3 мая 2017 г. в 19:10, ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com>:
>> > >
>> > > > Hi, Igntrs! When processing single partitions message in
>> > > > GridDhtPartitionsExchangeFuture#processMessage() then , coordinator
>> > could
>> > > > answer with GridDhtPartitionsFullMessage
>> > > > from sendAllPartitions.
>> > > > But the field GridDhtPartitionsExchangeFuture#remaining must be
>> empty
>> > in
>> > > > this case.
>> > > >
>> > > > I wounder, how could it be empty in case if "remaining" held 2
>> nodes,
>> > or
>> > > > more ?
>> > > >
>> > > >
>> > > > --
>> > > >
>> > > > *Best Regards,*
>> > > >
>> > > > *Kuznetsov Aleksey*
>> > > >
>> > >
>> > --
>> >
>> > *Best Regards,*
>> >
>> > *Kuznetsov Aleksey*
>> >
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[jira] [Created] (IGNITE-5169) ODBC: Rework handshake to allow different handlers

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5169:
---

 Summary: ODBC: Rework handshake to allow different handlers
 Key: IGNITE-5169
 URL: https://issues.apache.org/jira/browse/IGNITE-5169
 Project: Ignite
  Issue Type: Task
  Components: jdbc-driver, odbc, SQL
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 2.1






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1908: IGNITE-5169

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5169



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

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

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

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


commit 24a197c93c2abee65c2e362c806d1dfb4b398a2b
Author: devozerov 
Date:   2017-05-04T14:49:03Z

Finished Java part.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1898: Ignite 1.7.11 ignite 4220

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-5170) .NET: Use peer deployment in examples

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5170:
--

 Summary: .NET: Use peer deployment in examples
 Key: IGNITE-5170
 URL: https://issues.apache.org/jira/browse/IGNITE-5170
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
 Fix For: 2.1


Once IGNITE-2492 is finished, we should simplify examples:
* Remove the requirement to start Apache.Ignite.exe with {{-assembly}} parameter
* Remove ExamplesDll project, put all classes into one project to avoid 
confusion



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Ignite ML, next steps (IGNITE-5029)

[ArtemM]

Update about DNNs: there is  DL4J    framework
which currently has module for integration with spark. Maybe we can write a
module for integration with Apache Ignite and get their rich functionality
rather easily. Still investigating it, but it looks promising. If someone
has thoughts on it, please, share.

Regards, Artem.



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-ML-next-steps-IGNITE-5029-tp17096p17466.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: dynamic cache creation question

[Dmitriy Setrakyan]

Alexey,

I am not sure I understand the question. This message is obviously
necessary. Can you clarify?

D.

On Thu, May 4, 2017 at 2:19 AM, ALEKSEY KUZNETSOV 
wrote:

> Hello, Igntrs!
> When node dinamically creates new cache it sends
> GridDhtPartitionsSingleMessage to coordinator so partition maps got redone.
> Why it sends the message after cache creation?
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[GitHub] ignite pull request #1636: IGNITE-518: unmute fixed tests.

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1090: IGNITE-3939: Compact long zero values binary repr...

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: dynamic cache creation question

[ALEKSEY KUZNETSOV]

Well, for me its not obvious. The point is - why do we need to send it ?

чт, 4 мая 2017 г. в 18:54, Dmitriy Setrakyan :

> Alexey,
>
> I am not sure I understand the question. This message is obviously
> necessary. Can you clarify?
>
> D.
>
> On Thu, May 4, 2017 at 2:19 AM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com>
> wrote:
>
> > Hello, Igntrs!
> > When node dinamically creates new cache it sends
> > GridDhtPartitionsSingleMessage to coordinator so partition maps got
> redone.
> > Why it sends the message after cache creation?
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

IGNITE-1094 Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

[ALEKSEY KUZNETSOV]

Igntrs! Plz, review my changes
https://issues.apache.org/jira/browse/IGNITE-1094

*https://github.com/apache/ignite/pull/1904
*
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: dynamic cache creation question

[Denis Magda]

Aleksey,

What’s your goal? :) What are you working on or researching? I would start with 
this first.

—
Denis

> On May 4, 2017, at 9:14 AM, ALEKSEY KUZNETSOV  
> wrote:
> 
> Well, for me its not obvious. The point is - why do we need to send it ?
> 
> чт, 4 мая 2017 г. в 18:54, Dmitriy Setrakyan :
> 
>> Alexey,
>> 
>> I am not sure I understand the question. This message is obviously
>> necessary. Can you clarify?
>> 
>> D.
>> 
>> On Thu, May 4, 2017 at 2:19 AM, ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com>
>> wrote:
>> 
>>> Hello, Igntrs!
>>> When node dinamically creates new cache it sends
>>> GridDhtPartitionsSingleMessage to coordinator so partition maps got
>> redone.
>>> Why it sends the message after cache creation?
>>> --
>>> 
>>> *Best Regards,*
>>> 
>>> *Kuznetsov Aleksey*
>>> 
>> 
> -- 
> 
> *Best Regards,*
> 
> *Kuznetsov Aleksey*

Re: dynamic cache creation question

[Dmitriy Setrakyan]

On Thu, May 4, 2017 at 9:14 AM, ALEKSEY KUZNETSOV 
wrote:

> Well, for me its not obvious. The point is - why do we need to send it ?
>

Alexey, are you asking for the purpose of the message? Whenever a new cache
is created, we must create an partition map for it on all nodes. I would
suggest that you setup a break point and trace what changes are caused by
this message. If you believe that something can be done better, please
suggest an approach.


> чт, 4 мая 2017 г. в 18:54, Dmitriy Setrakyan :
>
> > Alexey,
> >
> > I am not sure I understand the question. This message is obviously
> > necessary. Can you clarify?
> >
> > D.
> >
> > On Thu, May 4, 2017 at 2:19 AM, ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com>
> > wrote:
> >
> > > Hello, Igntrs!
> > > When node dinamically creates new cache it sends
> > > GridDhtPartitionsSingleMessage to coordinator so partition maps got
> > redone.
> > > Why it sends the message after cache creation?
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[jira] [Created] (IGNITE-5171) Show how to make index fields of embedded objects

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5171:
---

 Summary: Show how to make index fields of embedded objects
 Key: IGNITE-5171
 URL: https://issues.apache.org/jira/browse/IGNITE-5171
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
 Fix For: 2.1


Document and demonstrate how to index and use fields of embedded objects:
https://apacheignite.readme.io/v2.0/docs/indexes

For instance, if we have this object

Person {
int age;
int id;

Addrees addr;
}

where Address includes {street and zip} fileds.

Show how to index {{street}} and {{zip}} and use from SQL.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5172) .NET: Dynamic type registration uses assembly-qualified type name

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5172:
--

 Summary: .NET: Dynamic type registration uses assembly-qualified 
type name
 Key: IGNITE-5172
 URL: https://issues.apache.org/jira/browse/IGNITE-5172
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.0


{{BinaryProcessor.RegisterType}} uses {{AssemblyQualifiedName}}, which includes 
assembly version.

This has two issues:
* We ignore current name mapper, so this type name is not the same as type name 
in binary metadata, marshaller, etc
* This breaks when same type comes from assemblies with different versions, 
which is a valid scenario. Binary protocol is flexible and does not care about 
type versions, it tolerates new or missing fields.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Apache Ignite 2.0 Documentation

[Denis Magda]

Evgeniy,

Thanks a lot for pointing out to this! I’ve fixed the docs.

—
Denis

> On May 3, 2017, at 11:56 PM, Evgeniy Ignatiev  
> wrote:
> 
> Hello.
> 
> On a "Resource Injection" page LoadBalancerResource line states that it 
> injects IgniteLogger - seems to be an issue with docs. Also on "Asynchronous 
> Support" in "Closures Execution and Thread Pools" section there seems to be 
> some typos/missed words:
> 
> asynchronous operation has been *comp* completed
> Otherwise, the closure will be  asynchronously upon the operation 
> completion
> 
> On 5/4/2017 3:07 AM, Denis Magda wrote:
>> Well, so many stuff that I eventually forgot about RocketMQ integration, 
>> sorry Roman ;)
>> Just released the latest doc: 
>> https://apacheignite-mix.readme.io/docs/rocketmq-streamer
>> 
>> —
>> Denis
>> 
>>> On May 3, 2017, at 4:00 PM, Denis Magda  wrote:
>>> 
>>> Igniters, thanks to all of you who helped documenting 2.0 features! We 
>>> could complete the documentation just in time and I’ve just released it.
>>> 
>>> Just to give you a sense on how many things were added to Ignite 2.0 here 
>>> is a list of completely new or significantly updated docs:
>>> * Page memory: https://apacheignite.readme.io/docs/page-memory
>>> * Memory & Cache Metrics: 
>>> https://apacheignite.readme.io/docs/memory-and-cache-metrics
>>> * Eviction policies: https://apacheignite.readme.io/docs/evictions
>>> 
>>> * DDL: https://apacheignite.readme.io/docs/distributed-ddl
>>> 
>>> * Machine Learning Grid (beta): 
>>> https://apacheignite.readme.io/docs/machine-learning
>>> 
>>> * Renewed Async API: https://apacheignite.readme.io/docs/async-support
>>> * Apache Ignite thread pools including the new custom one: 
>>> https://apacheignite.readme.io/docs/thread-pools
>>> 
>>> * .NET Plugins: https://apacheignite-net.readme.io/docs/plugins
>>> 
>>> * C++ Continuous Queries remote filters: 
>>> https://apacheignite-cpp.readme.io/docs/continuous-queries#section-remote-filter
>>> 
>>> * Spring Data Integration: 
>>> https://apacheignite-mix.readme.io/v2.0/docs/spring-data
>>> 
>>> And, for the first time we prepare a migration guide for you dear users: 
>>> https://apacheignite.readme.io/docs/apache-ignite-20
>>> 
>>> —
>>> Denis
>>> 
 On Apr 13, 2017, at 6:46 PM, Dmitriy Setrakyan  
 wrote:
 
 Denis, thanks for tracking the documentation changes! This is the part that
 usually gets missed by the community.
 
 On Thu, Apr 13, 2017 at 12:46 PM, Denis Magda  wrote:
 
> Folks,
> 
> I’ve prepared a list of changes that have to be documented before the
> public release of 2.0:
> https://issues.apache.org/jira/browse/IGNITE-4960
> 
> That’s an impressive release and there are some many things to document.
> Actually, I’ll try to document the biggest part contacting contributors in
> person but still need a help from some of you:
> 
> * Nikita, Oleg (Machine Learning): https://issues.apache.org/
> jira/browse/IGNITE-4964
> * Vovan or Alex P. (DDL indexing statements): https://issues.apache.org/
> jira/browse/IGNITE-4967
> * Vovan (custom thread pools): https://issues.apache.org/
> jira/browse/IGNITE-4969
> * Vovan or Taras (next gen async API): https://issues.apache.org/
> jira/browse/IGNITE-4972
> * Val (Hibernate improvements): https://issues.apache.org/
> jira/browse/IGNITE-4972
> * Pavel (.NET plugin system): https://issues.apache.org/
> jira/browse/IGNITE-4973
> * Pavel (.NET dynamically registered classes): https://issues.apache.org/
> jira/browse/IGNITE-4974
> * Igor Sapego (C++ CQ remote filters): https://issues.apache.org/
> jira/browse/IGNITE-4976
> 
> Let’s pull together and accomplish this part of the release together.
> 
> —
> Denis
> 
> 
> 

[GitHub] ignite pull request #1909: IGNITE-5172 .NET: Fix type name resolving during ...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-5172 .NET: Fix type name resolving during dynamic registration



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

$ git pull https://github.com/ptupitsyn/ignite ignite-5172

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

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


commit 190476e55d29214d8c5dd87523e70abb58175efa
Author: Pavel Tupitsyn 
Date:   2017-05-04T18:07:35Z

IGNITE-5172 .NET: Fix type name mapping for dynamic registration

commit 95e0c20285c8b84307753b09eff5c8aea8efde95
Author: Pavel Tupitsyn 
Date:   2017-05-04T18:48:26Z

Add test

commit 7fefe5f60a505b85e0d03576de18bc70e52ec677
Author: Pavel Tupitsyn 
Date:   2017-05-04T18:50:31Z

Fix compilation

commit 435a91a3258615e0e4fc1a1e23dab96687ddb1f0
Author: Pavel Tupitsyn 
Date:   2017-05-04T19:13:02Z

Fixing TypeResolver

commit 31435b3ae30d7326c5ec726c3806e9074b1d02ee
Author: Pavel Tupitsyn 
Date:   2017-05-04T19:23:51Z

Fixing generic type resolver




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

[Denis Magda]

Nick,

Looks like we need to look into it, thanks for extensive explanation and your 
time. I’ve updated the originally created ticket:
https://issues.apache.org/jira/browse/IGNITE-5038

Feel free to expand the description if needed.

—
Denis

> On Apr 28, 2017, at 4:35 PM, npordash  wrote:
> 
> Hey Denis,
> 
> I tried your solution as that is what Alexei was more-or-less suggesting:
> create a delegating classloader, but in this case delegate to whatever
> context class loader is set. The problem is that resolved classes will
> always be stored by the instantiated classloader, which would be the
> delegating one here, and there is no way around that from what I can tell.
> There is a fair amount of native code involved and I'm not sure exactly
> what's going on there (f.e. Class.forName eventually calls Class.forName0
> which is native and ClassLoader.loadClass eventually calls
> ClassLoader.resolveClass0 which is also native). 
> 
> I ran a test to prove out the above where I created a dynamic class using
> ByteBuddy and the following happened:
> 1) Create URLClassLoader and successfully loaded the class there
> 2) Attempted to resolve the class using the system classloader (failed as
> expected)
> 3) Created a delegating classloader and attempted to resolve (failed as
> expected)
> 4) Set the context classloader to the urlclassloader and attempted to
> resolve (worked as expected)
> 5) Restored the context classloader to the system classloader and attempted
> to resolve (worked which I was hoping it didn't do).
> 
> Regarding your code snippet - I did see that and was wondering if it could
> do something like the following instead:
> 
> 
> 
> I believe getContextClassLoader by default doesn't return null anymore
> (since after Java 1.4 or something I believe?) but it is still technically
> possible.
> 
> I think at least when running sql queries or getting data out of a cache it
> is probably a safe assumption that if the calling thread wants to
> deserialize as a class called Foo then that class is probably already
> available via the context classloader and that takes the burden off of
> Ignite on trying to "do the right thing" about class resolution.
> 
> -Nick
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-tp17126p17339.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[jira] [Created] (IGNITE-5173) Write-Behind store flushes single entry at a time in the sync mode

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5173:
---

 Summary: Write-Behind store flushes single entry at a time in the 
sync mode
 Key: IGNITE-5173
 URL: https://issues.apache.org/jira/browse/IGNITE-5173
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
 Fix For: 2.1


When the write-behind store reaches maximum write-behind queue/buffer size on 
the next update operation, then the data will be flushed from the queue 
synchronously in order to free some room for the just arrived update. The issue 
is that the store flushes a single entry at a time in the synchronous mode that 
can dramatically affect the performance.

The following has to be addressed as a part of the ticket:
* the store has to flush multiple entries in the sync mode to avoid a 
performance hit.
* `CacheConfiguration.getWriteBehindFlushSize` and respective setter method 
must be renamed to `CacheConfiguration.getWriteBehindBufferSize`. Presently 
it's totally confusing.

See more details here:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-s-Performance-Drops-Dramatically-Why-td12337.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: CacheStore's Performance Drops Dramatically - Why?

[Denis Magda]

Looks like the naming of ‘getWriteBehindFlushSize’ method is totally wrong. It 
confuses so many people. However, if we refer to the documentation of this 
method or look into the source code we will find out that it sets the maximum 
size of the write-behind queue/buffer on a single node. Once this size is 
reached data will be flushed to a storage in the sync mode.

So, you need to set the flush size (maximum queue/buffer size) to a bigger 
value if you can’t keep up with updates and always switch to the sync mode.

In any case, I’ve created a ticket to address both issues discussed here:
https://issues.apache.org/jira/browse/IGNITE-5173 


Thanks for your patience.

—
Denis

> On May 3, 2017, at 10:10 AM, Jessie Lin  wrote:
> 
> I thought flushsize could be set as several times higher than the batch size 
> is that in a cluster, data nodes would flush in parallel. For example there's 
> a cluster with 10 nodes, and flushSize is 10240, thread count = 2, batch size 
> = 512. Then each node would flush out in 2 thread, and each thread flushes 
> out in batch of 512. 
> 
> Could someone confirms or clarify the understanding? Thank you!
> 
> On Wed, May 3, 2017 at 12:16 AM, Matt  > wrote:
> In fact, I don't see why you would need both batchSize and flushSize. If I 
> got it right, only the min of them would be used by Ignite to know when to 
> flush, why do we have both in the first place?
> 
> In case they're both necessary for a reason I'm not seeing, I still wonder if 
> the default values should be batchSize > flushSize as I think or not.
> 
> On Wed, May 3, 2017 at 3:26 AM, Matt  > wrote:
> I'm writing to confirm I managed to fix my problem by fine tuning the config 
> params for the write behind cache until the performance was fine. I still see 
> single element inserts from time to time, but just a few of them every now 
> and then not like before. You should definitely avoid synchronous single 
> elements insertions, I hope that changes in future versions.
> 
> Regarding writeBehindBatchSize and writeBehindFlushSize, I don't see the 
> point of setting both values when batchSize < flushSize (default values are 
> 512 and 10240 respectively). If I'm not wrong, the cache is flushed whenever 
> the its size is equal to min(batchSize, flushSize). Since batchSize is less 
> than flushSize, flushSize is never really used and the size of the flush is 
> controlled by the size of the cache itself only.
> 
> That is how it works by default, on the other hand if we swap their values 
> (ie, batchSize=10240 and flushSize=512) the behavior would be the same 
> (Ignite would call writeAll() with 512 elements each time), but the number of 
> elements flushed would be controlled by the correct variable (ie, flushSize).
> 
> Were the default values supposed to be the other way around or am I missing 
> something?
> 
> On Tue, May 2, 2017 at 9:13 PM, Denis Magda  > wrote:
> Matt,
> 
> Cross-posting to the dev list.
> 
> Yes, Ignite switches to the synchronous mode once the buffer is exhausted. 
> However, I do agree that it would be a right solution to flush multiple 
> entries rather than one in the synchronous mode. *Igniters*, I was sure we 
> had a ticket for that optimization but unable to find it.  Does anybody know 
> the ticket name/number?
> 
> To omit the performance degradation you have to tweak the following 
> parameters so that the write-behind store can keep up with you updates:
> - setWriteBehindFlushThreadCount
> - setWriteBehindFlushFrequency
> - setWriteBehindBatchSize
> - setWriteBehindFlushSize
> 
> Usually it helped all the times to Apache Ignite users.
> 
> > QUESTION 2
> >
> > I've read on the docs that using ATOMIC mode (default mode) is better for 
> > performance, but I'm not getting why. If I'm not wrong using TRANSACTIONAL 
> > mode would cause the CacheStore to reuse connections (not call 
> > openConnection(autocommit=true) on each writeAll()).
> >
> > Shouldn't it be better to use transactional mode?
> 
> Transactional mode enables 2 phase commit protocol: 
> https://apacheignite.readme.io/docs/transactions#two-phase-commit-2pc 
> 
> 
> This is why atomic operations are swifter in general.
> 
> —
> Denis
> 
> > On May 2, 2017, at 10:40 AM, Matt  > > wrote:
> >
> > No, only with inserts, I haven't tried removing at this rate yet but it may 
> > have the same problem.
> >
> > I'm debugging Ignite internal code and I may be onto something. The thing 
> > is Ignite has a cacheMaxSize (aka, WriteBehindFlushSize) and 
> > cacheCriticalSize (which by default is cacheMaxSize*1.5). When the cache 
> > reaches that size Ignite starts writing elements SYNCHRONOUSLY, as you can 
> > see in [1].
> >
> > I think this makes things worse since only one single value is fl

Re: Update docs reference on ignite.apache.org to the version 2.0.0

[Denis Magda]

Mauricio,

Thanks, I’ve merged the patch. Please double check that everything works as 
expected on your side.

—
Denis

> On May 4, 2017, at 1:12 PM, Mauricio Stekl  wrote:
> 
> Hi, 
> Attached you can find the patch with the following changes for the website: 
> 
> - .htaccess with proper rewrite rules to have 2.0 docs as /latest/
> - Canonical URL meta tag added to all .html files under 2.0 docs. Also added 
> GA code.
> - Canonical URL meta tag for /latest/ removed from all .html files under 1.9 
> docs. And also added canonical tag for https://. And finally added NOINDEX 
> robot tag for SEO purposes. 
> 
> 
> Please let me know if you have any question.
> 
> Best,
> Mauricio
> 
> 
> 
> 
> 
>> On May 4, 2017, at 08:22, Vladimir Ozerov > > wrote:
>> 
>> Hi Mauricio,
>> 
>> As we've released Apache Ignite 2.0, may I ask you to update version of our 
>> docs to 2.0.0 as per post-release step 3 on "Release Process" page [1]?
>> 
>> Regards,
>> Vladimir
>> 
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process 
>> 

Joining

[Mandhir Gidda]

SUBSCRIBE

Re: Joining

[Denis Magda]

Mandhir,

Click on “subscribe” reference that is in the dev list row and send a message 
to the address pop up:
https://ignite.apache.org/community/resources.html#mail-lists

-
Denis

> On May 4, 2017, at 7:20 AM, Mandhir Gidda  wrote:
> 
> SUBSCRIBE

[jira] [Created] (IGNITE-5174) Need to have opportunity to list only server nodes for specified topology version

[Stanilovsky Evgeny (JIRA)]

Stanilovsky Evgeny created IGNITE-5174:
--

 Summary: Need to have opportunity to list only server nodes for 
specified topology version
 Key: IGNITE-5174
 URL: https://issues.apache.org/jira/browse/IGNITE-5174
 Project: Ignite
  Issue Type: Bug
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
Priority: Minor
 Fix For: 2.1


Need to have common utility function which filters client nodes for specified 
topology version.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1910: IGNITE-5174 client nodes filter func

[zstan]

GitHub user zstan opened a pull request:

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

IGNITE-5174 client nodes filter func



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

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

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

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


commit 2185c173059db0615bfbb6b9d54ed92f5e1cb511
Author: Evgeny Stanilovskiy 
Date:   2017-05-05T06:50:04Z

IGNITE-5174 client nodes filter func




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---