Re: Zookeeper Discovery SPI & external IP address in AWS

[Valentin Kulichenko]

Igor,

You need to investigate deeper then. It's not obvious what's going on and
why there is an issue.

-Val

On Mon, Jun 26, 2017 at 3:36 PM, Igor Rudyak  wrote:

> I am 100% sure, cause  "*telnet11211*"  works just perfect.
>
> Igor
>
> On Mon, Jun 26, 2017 at 3:32 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Igor,
> >
> > Are you sure these connections are not blocked by firewall? If you
> provide
> > addresses explicitly in static IP finder, then it doesn't matter what is
> > published in shared IP finder. Is it possible that public addresses are
> > actually published and connectivity issue is caused by something else?
> >
> > -Val
> >
> > On Mon, Jun 26, 2017 at 3:01 PM, Igor Rudyak  wrote:
> >
> > > Val,
> > >
> > > Regarding resolver it makes sense.
> > >
> > > Actually as of now, Option 2 doesn't work to connect Ignite clients to
> > > cluster using private-to-public IPs mapping. It just falls into
> infinite
> > > connection loop and periodically reports something like this:
> > >
> > > *[14:42:15] Failed to connect to any address from IP finder (will retry
> > to
> > > join topology every 2 secs): [/0:0:0:0:0:0:0:1%1:47500, /
> 127.0.0.1:47500
> > > , /:47500,
> > > /:47500, /:47500]*
> > >
> > > Even if I manually specify all public IPs for discovery, like this:
> > >
> > > **
> > > * *
> > > *  > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.
> > > TcpDiscoveryMulticastIpFinder">*
> > > * *
> > > * *
> > > * *
> > > * *
> > > * *
> > > * *
> > > * *
> > > * *
> > > * *
> > > **
> > >
> > > It still can't connect to cluster and just periodically reports the
> same
> > > error.
> > >
> > > Does actually cluster membership protocol support the case when node
> > > available through multiple IP addresses and treats ,
> > >  and etc. as just different IPs corresponding to the same
> > > node?
> > >
> > >
> > > Igor
> > >
> > > On Mon, Jun 26, 2017 at 1:55 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Igor,
> > > >
> > > > It depends on how address resolver works. But I agree, in general
> case
> > > it's
> > > > possible that a node can only resolve public address for itself. In
> > such
> > > > scenario we must publish public addresses in IP finder.
> > > >
> > > > -Val
> > > >
> > > > On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak 
> > wrote:
> > > >
> > > > > Option 2 also will not work for IaaS environments, where node can
> > > > > dynamically join or leave cluster.
> > > > >
> > > > > Igor
> > > > >
> > > > > On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
> > > > > valentin.kuliche...@gmail.com> wrote:
> > > > >
> > > > > > Yakov,
> > > > > >
> > > > > > Nodes that join outside of the network (usually these are
> clients)
> > > need
> > > > > to
> > > > > > know public addresses to connect. To make it work either of these
> > > must
> > > > > > happen:
> > > > > >
> > > > > > 1. Server nodes publish their public addresses in IP finder so
> that
> > > > > clients
> > > > > > can use them to connect.
> > > > > > 2. Client nodes use address resolver to map published internal
> > > > addresses
> > > > > to
> > > > > > public addresses.
> > > > > >
> > > > > > Both will work, but frankly I like option 1 more. First of all,
> > it's
> > > > just
> > > > > > more intuitive that IP finder contains all possible addresses
> that
> > > can
> > > > be
> > > > > > used to join. Second of all, option 2 introduces requirement to
> > have
> > > > > > address resolver for server addresses configured on client nodes
> -
> > > this
> > > > > is
> > > > > > not very good from usability standpoint.
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov <
> > yzhda...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Guys, I don't get the point.
> > > > > > >
> > > > > > > 1. Why addresses processed by address resolver should appear in
> > > > shared
> > > > > > > finder? In my understanding finders contain only internal IPs
> > which
> > > > > > should
> > > > > > > be processed by a resolver.
> > > > > > >
> > > > > > > 2. This one is very critical. Nikolay and Anton, how can I
> review
> > > the
> > > > > > > changes?! Please update the ticket with PR or commit hash.
> > > > > > >
> > > > > > > --Yakov
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Zookeeper Discovery SPI & external IP address in AWS

[Igor Rudyak]

I am 100% sure, cause  "*telnet11211*"  works just perfect.

Igor

On Mon, Jun 26, 2017 at 3:32 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Igor,
>
> Are you sure these connections are not blocked by firewall? If you provide
> addresses explicitly in static IP finder, then it doesn't matter what is
> published in shared IP finder. Is it possible that public addresses are
> actually published and connectivity issue is caused by something else?
>
> -Val
>
> On Mon, Jun 26, 2017 at 3:01 PM, Igor Rudyak  wrote:
>
> > Val,
> >
> > Regarding resolver it makes sense.
> >
> > Actually as of now, Option 2 doesn't work to connect Ignite clients to
> > cluster using private-to-public IPs mapping. It just falls into infinite
> > connection loop and periodically reports something like this:
> >
> > *[14:42:15] Failed to connect to any address from IP finder (will retry
> to
> > join topology every 2 secs): [/0:0:0:0:0:0:0:1%1:47500, /127.0.0.1:47500
> > , /:47500,
> > /:47500, /:47500]*
> >
> > Even if I manually specify all public IPs for discovery, like this:
> >
> > **
> > * *
> > *  > class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.
> > TcpDiscoveryMulticastIpFinder">*
> > * *
> > * *
> > * *
> > * *
> > * *
> > * *
> > * *
> > * *
> > * *
> > **
> >
> > It still can't connect to cluster and just periodically reports the same
> > error.
> >
> > Does actually cluster membership protocol support the case when node
> > available through multiple IP addresses and treats ,
> >  and etc. as just different IPs corresponding to the same
> > node?
> >
> >
> > Igor
> >
> > On Mon, Jun 26, 2017 at 1:55 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Igor,
> > >
> > > It depends on how address resolver works. But I agree, in general case
> > it's
> > > possible that a node can only resolve public address for itself. In
> such
> > > scenario we must publish public addresses in IP finder.
> > >
> > > -Val
> > >
> > > On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak 
> wrote:
> > >
> > > > Option 2 also will not work for IaaS environments, where node can
> > > > dynamically join or leave cluster.
> > > >
> > > > Igor
> > > >
> > > > On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > Yakov,
> > > > >
> > > > > Nodes that join outside of the network (usually these are clients)
> > need
> > > > to
> > > > > know public addresses to connect. To make it work either of these
> > must
> > > > > happen:
> > > > >
> > > > > 1. Server nodes publish their public addresses in IP finder so that
> > > > clients
> > > > > can use them to connect.
> > > > > 2. Client nodes use address resolver to map published internal
> > > addresses
> > > > to
> > > > > public addresses.
> > > > >
> > > > > Both will work, but frankly I like option 1 more. First of all,
> it's
> > > just
> > > > > more intuitive that IP finder contains all possible addresses that
> > can
> > > be
> > > > > used to join. Second of all, option 2 introduces requirement to
> have
> > > > > address resolver for server addresses configured on client nodes -
> > this
> > > > is
> > > > > not very good from usability standpoint.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov <
> yzhda...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Guys, I don't get the point.
> > > > > >
> > > > > > 1. Why addresses processed by address resolver should appear in
> > > shared
> > > > > > finder? In my understanding finders contain only internal IPs
> which
> > > > > should
> > > > > > be processed by a resolver.
> > > > > >
> > > > > > 2. This one is very critical. Nikolay and Anton, how can I review
> > the
> > > > > > changes?! Please update the ticket with PR or commit hash.
> > > > > >
> > > > > > --Yakov
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Zookeeper Discovery SPI & external IP address in AWS

[Valentin Kulichenko]

Igor,

Are you sure these connections are not blocked by firewall? If you provide
addresses explicitly in static IP finder, then it doesn't matter what is
published in shared IP finder. Is it possible that public addresses are
actually published and connectivity issue is caused by something else?

-Val

On Mon, Jun 26, 2017 at 3:01 PM, Igor Rudyak  wrote:

> Val,
>
> Regarding resolver it makes sense.
>
> Actually as of now, Option 2 doesn't work to connect Ignite clients to
> cluster using private-to-public IPs mapping. It just falls into infinite
> connection loop and periodically reports something like this:
>
> *[14:42:15] Failed to connect to any address from IP finder (will retry to
> join topology every 2 secs): [/0:0:0:0:0:0:0:1%1:47500, /127.0.0.1:47500
> , /:47500,
> /:47500, /:47500]*
>
> Even if I manually specify all public IPs for discovery, like this:
>
> **
> * *
> *  class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.
> TcpDiscoveryMulticastIpFinder">*
> * *
> * *
> * *
> * *
> * *
> * *
> * *
> * *
> * *
> **
>
> It still can't connect to cluster and just periodically reports the same
> error.
>
> Does actually cluster membership protocol support the case when node
> available through multiple IP addresses and treats ,
>  and etc. as just different IPs corresponding to the same
> node?
>
>
> Igor
>
> On Mon, Jun 26, 2017 at 1:55 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Igor,
> >
> > It depends on how address resolver works. But I agree, in general case
> it's
> > possible that a node can only resolve public address for itself. In such
> > scenario we must publish public addresses in IP finder.
> >
> > -Val
> >
> > On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak  wrote:
> >
> > > Option 2 also will not work for IaaS environments, where node can
> > > dynamically join or leave cluster.
> > >
> > > Igor
> > >
> > > On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Yakov,
> > > >
> > > > Nodes that join outside of the network (usually these are clients)
> need
> > > to
> > > > know public addresses to connect. To make it work either of these
> must
> > > > happen:
> > > >
> > > > 1. Server nodes publish their public addresses in IP finder so that
> > > clients
> > > > can use them to connect.
> > > > 2. Client nodes use address resolver to map published internal
> > addresses
> > > to
> > > > public addresses.
> > > >
> > > > Both will work, but frankly I like option 1 more. First of all, it's
> > just
> > > > more intuitive that IP finder contains all possible addresses that
> can
> > be
> > > > used to join. Second of all, option 2 introduces requirement to have
> > > > address resolver for server addresses configured on client nodes -
> this
> > > is
> > > > not very good from usability standpoint.
> > > >
> > > > -Val
> > > >
> > > > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov 
> > > > wrote:
> > > >
> > > > > Guys, I don't get the point.
> > > > >
> > > > > 1. Why addresses processed by address resolver should appear in
> > shared
> > > > > finder? In my understanding finders contain only internal IPs which
> > > > should
> > > > > be processed by a resolver.
> > > > >
> > > > > 2. This one is very critical. Nikolay and Anton, how can I review
> the
> > > > > changes?! Please update the ticket with PR or commit hash.
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > >
> >
>

Re: Zookeeper Discovery SPI & external IP address in AWS

[Valentin Kulichenko]

Igor,

It depends on how address resolver works. But I agree, in general case it's
possible that a node can only resolve public address for itself. In such
scenario we must publish public addresses in IP finder.

-Val

On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak  wrote:

> Option 2 also will not work for IaaS environments, where node can
> dynamically join or leave cluster.
>
> Igor
>
> On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
> valentin.kuliche...@gmail.com> wrote:
>
> > Yakov,
> >
> > Nodes that join outside of the network (usually these are clients) need
> to
> > know public addresses to connect. To make it work either of these must
> > happen:
> >
> > 1. Server nodes publish their public addresses in IP finder so that
> clients
> > can use them to connect.
> > 2. Client nodes use address resolver to map published internal addresses
> to
> > public addresses.
> >
> > Both will work, but frankly I like option 1 more. First of all, it's just
> > more intuitive that IP finder contains all possible addresses that can be
> > used to join. Second of all, option 2 introduces requirement to have
> > address resolver for server addresses configured on client nodes - this
> is
> > not very good from usability standpoint.
> >
> > -Val
> >
> > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov 
> > wrote:
> >
> > > Guys, I don't get the point.
> > >
> > > 1. Why addresses processed by address resolver should appear in shared
> > > finder? In my understanding finders contain only internal IPs which
> > should
> > > be processed by a resolver.
> > >
> > > 2. This one is very critical. Nikolay and Anton, how can I review the
> > > changes?! Please update the ticket with PR or commit hash.
> > >
> > > --Yakov
> > >
> >
>

Re: Zookeeper Discovery SPI & external IP address in AWS

[Igor Rudyak]

Option 2 also will not work for IaaS environments, where node can
dynamically join or leave cluster.

Igor

On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" <
valentin.kuliche...@gmail.com> wrote:

> Yakov,
>
> Nodes that join outside of the network (usually these are clients) need to
> know public addresses to connect. To make it work either of these must
> happen:
>
> 1. Server nodes publish their public addresses in IP finder so that clients
> can use them to connect.
> 2. Client nodes use address resolver to map published internal addresses to
> public addresses.
>
> Both will work, but frankly I like option 1 more. First of all, it's just
> more intuitive that IP finder contains all possible addresses that can be
> used to join. Second of all, option 2 introduces requirement to have
> address resolver for server addresses configured on client nodes - this is
> not very good from usability standpoint.
>
> -Val
>
> On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov 
> wrote:
>
> > Guys, I don't get the point.
> >
> > 1. Why addresses processed by address resolver should appear in shared
> > finder? In my understanding finders contain only internal IPs which
> should
> > be processed by a resolver.
> >
> > 2. This one is very critical. Nikolay and Anton, how can I review the
> > changes?! Please update the ticket with PR or commit hash.
> >
> > --Yakov
> >
>

Re: IgniteCache#localEvict method

[Valentin Kulichenko]

Created ticket: https://issues.apache.org/jira/browse/IGNITE-5592

-Val

On Sun, Jun 25, 2017 at 7:49 AM, Ivan Rakov  wrote:

> Agree as well.
>
> Best Regards,
> Ivan Rakov
>
> On 22.06.2017 1:23, Valentin Kulichenko wrote:
>
> I agree. Ivan, do you have objections?
>
> -Val
>
> On Mon, Jun 19, 2017 at 3:55 PM, Dmitriy Setrakyan 
> wrote:
>
>> Ivan,
>>
>> The semantic now is very confusing, because localEvict does not evict to
>> off-heap, it just removes it from on-heap. The off-heap cache always has
>> the entry anyway.
>>
>> My vote would be to remove this method as I don't see anyone every needing
>> it. Perhaps a more useful method would be to flush the whole on-heap cache
>> altogether.
>>
>> D.
>>
>> On Mon, Jun 19, 2017 at 4:16 PM, Ivan Rakov  wrote:
>>
>> > Semantics in 2.0: if onheap cache enabled, method evicts entry from it.
>> If
>> > onheap cache is disabled (default case), implementation is no-op.
>> > Probably we should keep the method and add some note in javadoc.
>> >
>> > Best Regards,
>> > Ivan Rakov
>> >
>> > On 19.06.2017 17:01, Igor Sapego wrote:
>> >
>> >> What if user enables on-heap cache?
>> >>
>> >> Best Regards,
>> >> Igor
>> >>
>> >> On Mon, Jun 19, 2017 at 3:34 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org
>> >> >
>> >> wrote:
>> >>
>> >> Doesn't look useful to me.
>> >>>
>> >>> On Mon, Jun 19, 2017 at 1:03 AM, Valentin Kulichenko <
>> >>> valentin.kuliche...@gmail.com> wrote:
>> >>>
>> >>> Folks,
>> 
>>  Does the subj make sense in 2.0? Before this method could be used to
>> 
>> >>> evict
>> >>>
>>  from on-heap memory to off-heap or swap. What are the semantics now?
>> 
>>  -Val
>> 
>> 
>> >
>>
>
>
>

[jira] [Created] (IGNITE-5592) Remove IgniteCache#localEvict method

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-5592:
---

 Summary: Remove IgniteCache#localEvict method
 Key: IGNITE-5592
 URL: https://issues.apache.org/jira/browse/IGNITE-5592
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Valentin Kulichenko
 Fix For: 2.1


The method doesn't make much sense in 2.0. Before 2.0 it could be used to evict 
from on-heap memory to off-heap or swap. Currently off-heap always has the data 
and there is no swap, so the method should be removed to avoid confusion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Zookeeper Discovery SPI & external IP address in AWS

[Valentin Kulichenko]

Yakov,

Nodes that join outside of the network (usually these are clients) need to
know public addresses to connect. To make it work either of these must
happen:

1. Server nodes publish their public addresses in IP finder so that clients
can use them to connect.
2. Client nodes use address resolver to map published internal addresses to
public addresses.

Both will work, but frankly I like option 1 more. First of all, it's just
more intuitive that IP finder contains all possible addresses that can be
used to join. Second of all, option 2 introduces requirement to have
address resolver for server addresses configured on client nodes - this is
not very good from usability standpoint.

-Val

On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov  wrote:

> Guys, I don't get the point.
>
> 1. Why addresses processed by address resolver should appear in shared
> finder? In my understanding finders contain only internal IPs which should
> be processed by a resolver.
>
> 2. This one is very critical. Nikolay and Anton, how can I review the
> changes?! Please update the ticket with PR or commit hash.
>
> --Yakov
>

New Member

[caio.nishibe]

Hello guys, 

I'm a computer engineer and recently joined the ignite dev community. My
Jira user is "caio.nishibe" and I need some help with the permissions. Thank
you!

Best regards,
Caio



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/New-Member-tp19118.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[GitHub] ignite pull request #2198: Ignite 5591: WAL QueueFlusher replaced with sched...

[dspavlov]

GitHub user dspavlov opened a pull request:

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

Ignite 5591: WAL QueueFlusher replaced with schedule() method



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

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

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

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


commit 468033cc060cff8bdb7c74054eb47500d25732af
Author: dpavlov 
Date:   2017-06-21T14:10:04Z

IGNITE-5558: mock based test iterator created: Add ability to read WAL 
outside of an Ignite node

commit 3c1e28e46c3d5095ce00638e225768a10163a307
Author: dpavlov 
Date:   2017-06-21T15:00:25Z

IGNITE-5558: change to run on TC

commit defda5b4003bf990e6ca10ffef20ea0d35ee546b
Author: dpavlov 
Date:   2017-06-22T11:42:50Z

IGNITE-5558: first non-mockito based iterator implementation

commit 55fdb9ba2ecd46c4f701c11deb0cc2fea7ab5ff4
Author: dpavlov 
Date:   2017-06-22T12:10:46Z

IGNITE-5558: update for running on teamcity

commit 8e61faeb1a4eaa541c7ae7257721c302b966fbf5
Author: dpavlov 
Date:   2017-06-22T13:20:56Z

IGNITE-5558: WAL iterator creation moved to standalone class

commit b7024715585735a7011defafade5d267fe3f86e3
Author: dpavlov 
Date:   2017-06-22T14:24:41Z

IGNITE-5558: Mock factory extracted as standalone class

commit fed81a079b82d3445793fef37c61ef16a40c9446
Author: dpavlov 
Date:   2017-06-22T15:00:42Z

IGNITE-5558: compile fix

commit 9a844a8e7b80d6cde2247780500878a5ab70128a
Author: dpavlov 
Date:   2017-06-22T16:47:32Z

IGNITE-5558: WAL reader was moved to core, main() method was created

commit c6cbb4b910a29135e73298a7f64a63dbb354dfa0
Author: dpavlov 
Date:   2017-06-22T17:49:26Z

IGNITE-5558: WAL reader: correct close, record exception printing, file 
headers, javadoc

commit 1be55120fd9d56f9ef28fd691a526a3482ceef48
Author: dpavlov 
Date:   2017-06-22T18:35:03Z

IGNITE-5558: WAL reader: 2 modes were created: directory and files

commit 9df9b12297fd103a8f5564f600a90814961d94c1
Author: dpavlov 
Date:   2017-06-23T10:38:22Z

IGNITE-5558: WAL reader NPE fix and javadocs

commit 79d934d36e768430376655c05517f83386028cae
Author: dpavlov 
Date:   2017-06-23T12:36:52Z

IGNITE-5558: cosmetic & javadocs

commit 7b00272edf9dbcd35c9f2a6697253c61bbb7f80c
Author: dpavlov 
Date:   2017-06-26T14:16:46Z

IGNITE-5587: Generate File WAL Segment Archive Completed Event

commit 13a3b1a52cfb561011df96dda32eb41c2551ce26
Author: dpavlov 
Date:   2017-06-26T15:07:34Z

IGNITE-5587: Javadoc and cosmetic: Generate File WAL Segment Archive 
Completed Event

commit dce18c0581f9e3caff39c13cf0b681daa43934fc
Author: dpavlov 
Date:   2017-06-26T16:42:55Z

IGNITE-5587: Generate File WAL Segment Archive Completed Event

commit 69bbd6e7eedb90382128023a0ed478dd9cc42492
Author: dpavlov 
Date:   2017-06-26T16:57:56Z

IGNITE-5591: WAL queue flusher for background mode was replaced with 
Timeout processor




---
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 #2191: Ignite-1.8.8-b1

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
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-5591) WAL queue flusher for background mode can be replaced with Timeout processor

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-5591:
--

 Summary: WAL queue flusher for background mode can be replaced 
with Timeout processor
 Key: IGNITE-5591
 URL: https://issues.apache.org/jira/browse/IGNITE-5591
 Project: Ignite
  Issue Type: Improvement
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
Priority: Minor


Use 
 cctx.time().schedule(new Runnable() {});
intead of propriatery API and separate thread for WAL background mode



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2197: IGNITE-GG-12330 Fixed cache & group destroying

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-GG-12330 Fixed cache & group destroying



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

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

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

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


commit bdbba0ee9a5437a3f66d05c8175bfcb2f309b3bd
Author: Dmitriy Govorukhin 
Date:   2017-06-11T18:53:56Z

IGNITE-5392 - Joining node must accept cluster active status

commit 6bf5ce46c1e6c4e3dcf042ac91a5b61a726c5821
Author: Alexey Goncharuk 
Date:   2017-06-11T20:02:44Z

IGNITE-5267 - Moved ignite-ps module to ignite-core

commit 4dc81ca86347107848328d1e2e206b796976fb23
Author: Alexey Goncharuk 
Date:   2017-06-12T05:22:49Z

IGNITE-5267 - Added missing class

commit 195147d573d7cb3fc637f74937ee561b03a3c574
Author: Dmitriy Govorukhin 
Date:   2017-06-13T05:23:38Z

IGNITE-5267 - Activate nodes after start

commit d38dfcd5c4a49b6ec4be1cfdb4f28f7d152cd14a
Author: Dmitriy Govorukhin 
Date:   2017-06-13T10:01:16Z

ignite-5267-merge remove pds dependency, restore data structures only in 
snapshot operation

commit cf886fd5816534b46a1247d3bdc41061087608e4
Author: Dmitriy Govorukhin 
Date:   2017-06-13T10:22:30Z

ignite-2.1.1 fix java doc

commit d2dcc1d032c7f9692ddfe50fa8a80e375e8d4c9b
Author: Dmitriy Govorukhin 
Date:   2017-06-13T10:45:11Z

ignite-2.1.1 fix import

commit b65ca6854828c0f2368edab202ba00f31365a3e3
Author: Ivan Rakov 
Date:   2017-06-13T10:50:31Z

ignite-2.1.1 fixing pds tests

commit 1181b478d7810d4485da43204c9f64757be6a8e4
Author: Ivan Rakov 
Date:   2017-06-13T11:51:25Z

ignite-2.1.1 fixing pds tests

commit 68739b7cffae5b4bb3714dfe12bcf93327f136b8
Author: Alexey Kuznetsov 
Date:   2017-06-13T12:27:32Z

IGNITE-5267 Snapshots support.

commit ec50e23591c4d2e2332b7a81b7218ee44f358afe
Author: Ilya Lantukh 
Date:   2017-06-13T12:34:02Z

Merge with ignite-5267-merge.

commit 4342f46ab4258f8219e45f4b69435f38b6d0f2b5
Author: Ilya Lantukh 
Date:   2017-06-13T12:37:34Z

ignite-5267 : Test for unique name per group.

commit 2b0741039e7cc6e36871b97bab53780edfc84648
Author: Ilya Lantukh 
Date:   2017-06-13T12:38:55Z

ignite-5267 : Removed redundant test.

commit 4a86cae203ed9aed953cd6093884cf8cab4531e3
Author: Dmitriy Govorukhin 
Date:   2017-06-13T12:48:39Z

ignite-2.1.1 fix state processor, skip if daemon

commit 5c567aeb5458159bc41dbd251dfa8a65701f4861
Author: Ivan Rakov 
Date:   2017-06-13T13:06:42Z

ignite-2.1.1 moving pds tests that depend on indexing to separate suite

commit 5e9d9ebc1140f9647fc1b325ba81d0ad6c2c69f3
Author: Dmitriy Govorukhin 
Date:   2017-06-13T13:21:20Z

ignite-2.1.1 Added description to MX bean

commit 2c2a9e652b13cf60b7e878a4e20f4ab4ae014e9c
Author: Dmitriy Govorukhin 
Date:   2017-06-13T13:21:39Z

Merge remote-tracking branch 'professional/ignite-2.1.1' into ignite-2.1.1

commit 9141b3698d0ec98e512efbc78864cc06781fd8c7
Author: devozerov 
Date:   2017-06-13T13:32:28Z

IGNITE-5267: Fixed too early StoredCacheData initialization.

commit 0a00f03da78649320cb0bb3579f44d6fe037facc
Author: devozerov 
Date:   2017-06-13T13:32:58Z

Merge remote-tracking branch 'upstream/ignite-2.1.1' into ignite-2.1.1

commit 2d8c6519d36e2d7890a45b258d3b7439942dca66
Author: Dmitriy Govorukhin 
Date:   2017-06-13T13:39:13Z

ignite-2.1.1 Add joining node tests

commit c5cee32a510e5a3524ff88119acfd1963c74d8ad
Author: Dmitriy Govorukhin 
Date:   2017-06-13T13:39:30Z

Merge remote-tracking branch 'professional/ignite-2.1.1' into ignite-2.1.1

commit d369dfc4973c179861d1d2ff37fbe8c6c0543d1a
Author: Ivan Rakov 
Date:   2017-06-13T13:47:22Z

ignite-2.1.1 IgniteSpringDataTestSuite - added vm ip finder

commit ab62ce847cb73854f31f1232144f487786a6a3d1
Author: Pavel Kovalenko 
Date:   2017-06-08T21:30:41Z

IGNITE-5267 Remove entry from on-heap locks map if it was removed from 
off-heap

commit 33a9cc4cf9b32d93e34c5855d52ce208a3fd8228
Author: Pavel Kovalenko 
Date:   2017-06-08T21:33:30Z

IGNITE-5267 Deserialize binary object explicitly instead of 

Re: I am a new Ignite Development Community member

[Alexey Kuznetsov]

Hi, Alexey!

I added you to Ignite JIRA.

Looking forward for your contributions!

On Fri, Jun 23, 2017 at 6:58 PM, Alexey Kukushkin <
alexeykukush...@yahoo.com.invalid> wrote:

> Dear Ignite Development Community,
> I am a software engineer and joined the community to contribute to the
> product. Could you please help with granting me proper Ignite Jira
> permissions? My Jira user ID is "kukushal". Thank you!
>
> Best regards, Alexey




-- 
Alexey Kuznetsov

Re: GridCacheAdapter#size() has O(n) complexity

[Dmitriy Setrakyan]

On Mon, Jun 26, 2017 at 2:31 AM, Yakov Zhdanov  wrote:

> Guys, I see little inconsistency. Imagine user does 1000 puts with near
> cache enabled. Then user does some gets() and size() returns 1000 + N, more
> gets() and size() is 1000 + M. This is a bit weird. Can we have nearSize()
> on public API? Any thoughts here?
>

Completely agree. Cache size should not include near size. Near size should
be a separate count. The size, on the other hand, should always return the
actual size of the cache on the server side.


>
> As far as the original issue I would not bother with validity check on
> getting size and just return raw map size.
>

Agree.


>
> --Yakov
>

[GitHub] ignite pull request #2196: Ignite 5587: Generate File WAL Segment Archive Co...

[dspavlov]

GitHub user dspavlov opened a pull request:

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

Ignite 5587: Generate File WAL Segment Archive Completed Event

Don't merge, this PR is in progresss 

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

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

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

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


commit 2b0741039e7cc6e36871b97bab53780edfc84648
Author: Ilya Lantukh 
Date:   2017-06-13T12:38:55Z

ignite-5267 : Removed redundant test.

commit 4a86cae203ed9aed953cd6093884cf8cab4531e3
Author: Dmitriy Govorukhin 
Date:   2017-06-13T12:48:39Z

ignite-2.1.1 fix state processor, skip if daemon

commit 5c567aeb5458159bc41dbd251dfa8a65701f4861
Author: Ivan Rakov 
Date:   2017-06-13T13:06:42Z

ignite-2.1.1 moving pds tests that depend on indexing to separate suite

commit 5e9d9ebc1140f9647fc1b325ba81d0ad6c2c69f3
Author: Dmitriy Govorukhin 
Date:   2017-06-13T13:21:20Z

ignite-2.1.1 Added description to MX bean

commit 2c2a9e652b13cf60b7e878a4e20f4ab4ae014e9c
Author: Dmitriy Govorukhin 
Date:   2017-06-13T13:21:39Z

Merge remote-tracking branch 'professional/ignite-2.1.1' into ignite-2.1.1

commit 9141b3698d0ec98e512efbc78864cc06781fd8c7
Author: devozerov 
Date:   2017-06-13T13:32:28Z

IGNITE-5267: Fixed too early StoredCacheData initialization.

commit 0a00f03da78649320cb0bb3579f44d6fe037facc
Author: devozerov 
Date:   2017-06-13T13:32:58Z

Merge remote-tracking branch 'upstream/ignite-2.1.1' into ignite-2.1.1

commit 2d8c6519d36e2d7890a45b258d3b7439942dca66
Author: Dmitriy Govorukhin 
Date:   2017-06-13T13:39:13Z

ignite-2.1.1 Add joining node tests

commit c5cee32a510e5a3524ff88119acfd1963c74d8ad
Author: Dmitriy Govorukhin 
Date:   2017-06-13T13:39:30Z

Merge remote-tracking branch 'professional/ignite-2.1.1' into ignite-2.1.1

commit d369dfc4973c179861d1d2ff37fbe8c6c0543d1a
Author: Ivan Rakov 
Date:   2017-06-13T13:47:22Z

ignite-2.1.1 IgniteSpringDataTestSuite - added vm ip finder

commit ab62ce847cb73854f31f1232144f487786a6a3d1
Author: Pavel Kovalenko 
Date:   2017-06-08T21:30:41Z

IGNITE-5267 Remove entry from on-heap locks map if it was removed from 
off-heap

commit 33a9cc4cf9b32d93e34c5855d52ce208a3fd8228
Author: Pavel Kovalenko 
Date:   2017-06-08T21:33:30Z

IGNITE-5267 Deserialize binary object explicitly instead of calling cache. 
Small refactoring.

commit 95257a16aef0bc0bbacdee03503ee483ffc75bda
Author: Pavel Kovalenko 
Date:   2017-06-08T21:34:37Z

IGNITE-5267 Small test refactoring and speeding up

commit e2354cb5ea8965276c3696895c86e51315765571
Author: Pavel Kovalenko 
Date:   2017-06-08T21:37:38Z

IGNITE-5267 Fixed and simplified test

commit 41cea0bc2f887881a78436e54143313af27e7fa8
Author: Pavel Kovalenko 
Date:   2017-06-08T21:38:55Z

IGNITE-5267 Make partitionMapExchange timeout configurable

commit 8e1439782b993c8ccb974bcdbd55d4f2b28a5489
Author: Pavel Kovalenko 
Date:   2017-06-08T21:40:53Z

IGNITE-5267 Use owners instead of nodes to properly check finishing of 
partitionMapExchange

commit ef732dae02673c2ce79575b57454a573f0d1d591
Author: Pavel Kovalenko 
Date:   2017-06-08T21:42:00Z

IGNITE-5267 Provide entry key explicitly in cache queries. Fixed test.

commit 5eb40528bd6e52b4c13a4c21ecca74407b081898
Author: Pavel Kovalenko 
Date:   2017-06-08T21:42:34Z

IGNITE-5267 Explicitly fail test with known issue

commit e4f203b512cba1dc8ae82b506cadebfed3fd7f65
Author: sboikov 
Date:   2017-06-13T13:58:12Z

review

commit fd7050c72c8125ed1dd213ef781bdb9971d00413
Author: Dmitriy Govorukhin 
Date:   2017-06-13T14:02:54Z

ignite-2.1.1 Add joining node tests in suit

commit 3e509aa604ca342b3f42a73e771a5a4f678d7132
Author: Ivan Rakov 
Date:   2017-06-13T14:13:43Z

ignite-2.1.1 Fixing compilation in tests

commit dea416fa65874d4e33b37b46368f9e476a3904f4
Author: dpavlov 
Date:   2017-06-13T15:00:32Z

Merge fix: 4.ea2 into 5267: remove node is loopback check

commit b52a84e885b0f88971290200942e0bbe01252ff6
Author: sboikov 
Date:   2017-06-13T15:09:41Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-2.1.1

# Conflicts:
#   

[GitHub] ignite pull request #2195: Add unit-test for https://issues.apache.org/jira/...

[onishkov]

GitHub user onishkov opened a pull request:

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

Add unit-test for https://issues.apache.org/jira/browse/IGNITE-3935

Added unit-test corresponding to the problem 
https://issues.apache.org/jira/browse/IGNITE-3935 (ClassLoaders are not 
switched during object deserialization)

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

$ git pull https://github.com/onishkov/ignite ignite-3935

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

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


commit 8522a4b7dd45b1de69de38ad6e0cc93475aba8c5
Author: onishkov 
Date:   2017-06-26T14:01:27Z

Add unit-test for https://issues.apache.org/jira/browse/IGNITE-3935




---
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-5590) Physical and logical caches wtih the same amount of data have different storage size

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-5590:
---

 Summary: Physical and logical caches wtih the same amount of data 
have different storage size
 Key: IGNITE-5590
 URL: https://issues.apache.org/jira/browse/IGNITE-5590
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ksenia Rybakova
Priority: Minor


The following experiment was done to compare logical vs physical caches witn 
PDS:
- CacheRandomOperation benchmark was used to load data into caches
- Number of loaded entries 10M per cache
- All caches are atomic: 10 logical caches in 1 group vs 10 physical caches
- walHistorySize =2
- One default memory policy, memory config is default as well
Configs are attached.

||10 logical caches in 1 group|| 10 physical caches ||Comments||
||Total size of work/db/127_0_0_1*| |Among all hosts|
|23.6G|28.6G|Mainly because total size of partitions files (part-.bin) in 
"physical" case is bigger. In "phisical" case index.bin is one per cache while 
in "logical" case is one per group, but it's size is 16Kb so it doesn't make 
any difference.|
||Total size of work/db/wal/archive| |Among all hosts|
|86.7G|63.6G|In "physical" case archive has more files.|
||Total size of work/db/wal/127_0_0_1*| |Among all hosts|
|7.6G|7.6G| |

The size difference should be investigated, currently reason is unclear.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2194: Ignite 5076 1

[sk0x50]

GitHub user sk0x50 opened a pull request:

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

Ignite 5076 1



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

$ git pull https://github.com/sk0x50/ignite ignite-5076-1

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

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


commit 926aa519d7dc37ac5e8960f4368646ae94171290
Author: vozerov-gridgain 
Date:   2016-10-26T08:13:52Z

Removed unused imports from GridClosureProcessor.

commit 3d01ee1edf72f17bf6c027afad88fc29e321970a
Author: Pavel Tupitsyn 
Date:   2016-10-18T14:17:17Z

IGNITE-4030 Streamline PlatformTarget operation methods

Conflicts:

modules/core/src/main/java/org/apache/ignite/internal/processors/platform/cache/PlatformCache.java
modules/platforms/dotnet/Apache.Ignite.Core/Impl/Cache/CacheImpl.cs
modules/platforms/dotnet/Apache.Ignite.Core/Impl/Ignite.cs

commit e0b846758a6331e13095e9dcefa407ddfd57d6ff
Author: Pavel Tupitsyn 
Date:   2016-10-26T12:41:27Z

IGNITE-4030 Streamline PlatformTarget operation methods

commit 44740465677c39068dc813dabd464e60f09e5f49
Author: tledkov-gridgain 
Date:   2016-10-26T13:00:11Z

IGNITE-4062: fix BinaryObject.equals: compare only bytes containing the 
fields' data (without header and footer). This closes  #1182.

commit 3e724fd8a8da38c955e7ab4712e0cb8b5685a16c
Author: AMRepo 
Date:   2016-10-19T15:33:59Z

IGNITE-3448 Support SQL queries with distinct aggregates added. This closes 
#3448.

(cherry picked from commit 7ed2bb7)

commit b9d28caad2670557e381d2d67823fc58b4dfd97d
Author: Pavel Tupitsyn 
Date:   2016-10-27T14:04:01Z

Revert "IGNITE-4028 .NET: Get rid of OP_META in PlatformAbstractTarget"

This reverts commit 2a90fcaf8e46a829306ca92e226d984111b3aefe.

commit 2e7f59bf113bb76af0ddb5029b6af4900a6b1d54
Author: Pavel Tupitsyn 
Date:   2016-10-27T14:04:01Z

Revert "IGNITE-4028 .NET: Get rid of OP_META in PlatformAbstractTarget"

This reverts commit 2a90fcaf8e46a829306ca92e226d984111b3aefe.

# Conflicts:
#   
modules/platforms/dotnet/Apache.Ignite.Core/Impl/Cluster/ClusterGroupImpl.cs

commit 160e37f1bf83289b1295f0bf772be1f18bc342b8
Author: Pavel Tupitsyn 
Date:   2016-10-27T14:36:11Z

Revert "IGNITE-4028 .NET: Get rid of OP_META in PlatformAbstractTarget"

This reverts commit 2a90fcaf8e46a829306ca92e226d984111b3aefe.

# Conflicts:
#   
modules/platforms/dotnet/Apache.Ignite.Core/Impl/Cluster/ClusterGroupImpl.cs

commit 9ddb8be1243df8e489f7ebc716d315415775439a
Author: Dmitriy Govorukhin 
Date:   2016-10-27T14:52:22Z

IGNITE-2079 GridCacheIoManager eats exception trail if it falls into the 
directed case
merger from ignite-2079-2

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/query/GridCacheQueryMetricsAdapter.java

commit 087f6405d21ffe33181ced407ef67bd78583900d
Author: Andrey Novikov 
Date:   2016-10-28T10:26:33Z

Web console beta-5.

commit 44db38f3c56107badcf4948afff967ae12d115d6
Author: Pavel Tupitsyn 
Date:   2016-10-28T14:23:52Z

IGNITE-4115 Ignite.NET: Clean up instructions in README.txt file

commit a801f01c3933b992ae8b5282f438f06059c22523
Author: Pavel Tupitsyn 
Date:   2016-10-28T15:24:48Z

IGNITE-4151 .NET: Fix project build settings consistency

commit 6a2ecdbf5dbc86ff0c25cca579a669e90b3cfffd
Author: Pavel Tupitsyn 
Date:   2016-10-28T16:45:29Z

IGNITE-4131 .NET: Improve "Unsupported type exception" with additional 
information

commit 9ebbaea586d9ba360a1325a840fc7d81c93a95fc
Author: Valentin Kulichenko 
Date:   2016-10-28T23:08:44Z

IGNITE-4110 - Fixed BUFFER_UNDERFLOW and BUFFER_OVERFLOW handling in 
BlockingSslHandler

commit 6f160728c544d252f77bdb85c0ff2857559707a3
Author: Valentin Kulichenko 
Date:   2016-10-28T23:18:14Z

IGNITE-4110 - Fixed BUFFER_UNDERFLOW and BUFFER_OVERFLOW handling in 
BlockingSslHandler

commit 6b78ad0cbbcf286cb083136c49cebd5dd85de58c
Author: sboikov 
Date:   2016-10-31T07:35:44Z

TcoDiscovery: reduced amount of debug logging (heartbeat/connection check 
messages are logged trace level).

commit b1b87036fa180df80e07db00f3674eba6089fe71
Author: Pavel Tupitsyn 
Date:   2016-10-31T15:26:25Z

.NET: Fix ASP.NET session state provider test failures due to incorrect 
merge

commit 8add10e2ac9a91b0d7e473e6f40ff14d650abf96

[GitHub] ignite pull request #2193: IGNITE-5468

[BiryukovVA]

GitHub user BiryukovVA opened a pull request:

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

IGNITE-5468

IGNITE-5468: Added the ability to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE and 
IGNITE_SQL_MERGE_TABLE_PREFETCH_SIZE via cache configuration

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

$ git pull https://github.com/BiryukovVA/ignite IGNITE-5468

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

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


commit eeb9a4cf5d868c7c2361a7b9b83b0245ee5970c3
Author: Vitaliy 
Date:   2017-06-26T09:37:16Z

IGNITE-5468: Added the ability to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE and 
IGNITE_SQL_MERGE_TABLE_PREFETCH_SIZE via cache configuration

commit 6446d085419c140f03511e1867c72069d47b3055
Author: Vitaliy 
Date:   2017-06-26T11:17:10Z

IGNITE-5468: Refactoring.

commit 08734b11c7456aee6292ecc3b0778a8187fe76a4
Author: Vitaliy 
Date:   2017-06-26T09:37:16Z

IGNITE-5468: Added the ability to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE and 
IGNITE_SQL_MERGE_TABLE_PREFETCH_SIZE via cache configuration

commit 4a2c75c785c6a7403a0e7b9a05a3b3a07b888e5e
Author: Vitaliy 
Date:   2017-06-26T11:17:10Z

IGNITE-5468: Refactoring.

commit 2aa81f94b31c94efde0ad7d765bd4a70cb486e32
Author: Vitaliy 
Date:   2017-06-26T12:52:21Z

Merge remote-tracking branch 'origin/IGNITE-5468' into IGNITE-5468




---
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-5589) Archive WAL segment after significiant period of grid inactivity

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-5589:
--

 Summary: Archive WAL segment after significiant period of grid 
inactivity
 Key: IGNITE-5589
 URL: https://issues.apache.org/jira/browse/IGNITE-5589
 Project: Ignite
  Issue Type: Improvement
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


Placing WAL records into files in work directory (preallocated size; files with 
same name) was intitially done for perfomance reasons.

But for case there is no activity in the system there is no need to keep open 
segment in work directory. 
It is possible move data of this incomplete segment into archive.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5588) .NET: InstanceResourceAttribute does not work in scan queries

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5588:
--

 Summary: .NET: InstanceResourceAttribute does not work in scan 
queries
 Key: IGNITE-5588
 URL: https://issues.apache.org/jira/browse/IGNITE-5588
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.1


Ignite is not injected in scan query filter



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Sergi Vladykin]

No, we don't have plans for it.

Sergi

2017-06-26 14:20 GMT+03:00 Vyacheslav Daradur :

> Sergi, thanks for the answer.
>
> >> see TDE is just an option for PCI DSS compliancy but not a requirement.
> Requirement: "Protect stored cardholder data"
> Encryption is required.
> TDE - is one of ways to implement it at the database level.
>
> Sure, an implementation at the application level solve it.
>
> I meant another.
> I thought maybe this feature is in the Ignite roadmap?
>
>
> 2017-06-26 13:53 GMT+03:00 Sergi Vladykin :
>
> > I think no one is interested in this stuff right now.
> >
> > Also as far as I see TDE is just an option for PCI DSS compliancy but
> not a
> > requirement.
> >
> > Your system should pass PCI DSS if you will do the required encryption at
> > the application level and will properly manage encryption keys.
> >
> > Sergi
> >
> > 2017-06-26 11:40 GMT+03:00 Vyacheslav Daradur :
> >
> > > Guys, any thoughts?
> > >
> > > 2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur :
> > >
> > > > Hi Igniters.
> > > >
> > > > I have some user cases where I need fast storage with TDE support.
> > > > It is requered for PCI DSS certification.
> > > >
> > > > As far as I know AI doesn't support it.
> > > >
> > > > I looked at other storages.
> > > > Many storages support it or are engaged in development this feature.
> > > >
> > > > Cassandra community are working on TDE support.[1]
> > > >
> > > > Oracle support it.[2] Moreover it supports indexing and querying on
> > > > encrypted data.
> > > >
> > > > I think it will be very usefull to support TDE by AI.
> > > >
> > > > What do you think? Maybe development is already under way?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
> > > > [2] https://docs.oracle.com/cd/B19306_01/network.102/b14268/
> > > > asotrans.htm#ASOAG600
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Vyacheslav Daradur]

Sergi, thanks for the answer.

>> see TDE is just an option for PCI DSS compliancy but not a requirement.
Requirement: "Protect stored cardholder data"
Encryption is required.
TDE - is one of ways to implement it at the database level.

Sure, an implementation at the application level solve it.

I meant another.
I thought maybe this feature is in the Ignite roadmap?


2017-06-26 13:53 GMT+03:00 Sergi Vladykin :

> I think no one is interested in this stuff right now.
>
> Also as far as I see TDE is just an option for PCI DSS compliancy but not a
> requirement.
>
> Your system should pass PCI DSS if you will do the required encryption at
> the application level and will properly manage encryption keys.
>
> Sergi
>
> 2017-06-26 11:40 GMT+03:00 Vyacheslav Daradur :
>
> > Guys, any thoughts?
> >
> > 2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur :
> >
> > > Hi Igniters.
> > >
> > > I have some user cases where I need fast storage with TDE support.
> > > It is requered for PCI DSS certification.
> > >
> > > As far as I know AI doesn't support it.
> > >
> > > I looked at other storages.
> > > Many storages support it or are engaged in development this feature.
> > >
> > > Cassandra community are working on TDE support.[1]
> > >
> > > Oracle support it.[2] Moreover it supports indexing and querying on
> > > encrypted data.
> > >
> > > I think it will be very usefull to support TDE by AI.
> > >
> > > What do you think? Maybe development is already under way?
> > >
> > > [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
> > > [2] https://docs.oracle.com/cd/B19306_01/network.102/b14268/
> > > asotrans.htm#ASOAG600
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>



-- 
Best Regards, Vyacheslav D.

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Sergi Vladykin]

I think no one is interested in this stuff right now.

Also as far as I see TDE is just an option for PCI DSS compliancy but not a
requirement.

Your system should pass PCI DSS if you will do the required encryption at
the application level and will properly manage encryption keys.

Sergi

2017-06-26 11:40 GMT+03:00 Vyacheslav Daradur :

> Guys, any thoughts?
>
> 2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur :
>
> > Hi Igniters.
> >
> > I have some user cases where I need fast storage with TDE support.
> > It is requered for PCI DSS certification.
> >
> > As far as I know AI doesn't support it.
> >
> > I looked at other storages.
> > Many storages support it or are engaged in development this feature.
> >
> > Cassandra community are working on TDE support.[1]
> >
> > Oracle support it.[2] Moreover it supports indexing and querying on
> > encrypted data.
> >
> > I think it will be very usefull to support TDE by AI.
> >
> > What do you think? Maybe development is already under way?
> >
> > [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
> > [2] https://docs.oracle.com/cd/B19306_01/network.102/b14268/
> > asotrans.htm#ASOAG600
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Transaction Boundary - Data Streamer

[Yakov Zhdanov]

Done. Revision hash ec9d47b197738459b7721d5b393f5be223cd76e0

--Yakov

[jira] [Created] (IGNITE-5587) Generate File WAL Segment Archive Completed Event

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-5587:
--

 Summary: Generate File WAL Segment Archive Completed Event
 Key: IGNITE-5587
 URL: https://issues.apache.org/jira/browse/IGNITE-5587
 Project: Ignite
  Issue Type: Improvement
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


Now segment archive complete event is based internally on wait-notifyAll
It is impossible to subscribe to this event outside archiver module.

It is required to create SEGMENT_ARCHIVED event type and fire this event each 
time segment archiving was completed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Zookeeper Discovery SPI & external IP address in AWS

[Yakov Zhdanov]

Guys, I don't get the point.

1. Why addresses processed by address resolver should appear in shared
finder? In my understanding finders contain only internal IPs which should
be processed by a resolver.

2. This one is very critical. Nikolay and Anton, how can I review the
changes?! Please update the ticket with PR or commit hash.

--Yakov

Re: Ignite JDBC and "Runnable tasks outlived thread pool executor service"

[Yakov Zhdanov]

Igor, can you please share the reproducer? This message is printed only
when Ignite node or internal client stops with active tasks in internal
pools. Stop may occur due to GC pause. Please give more details.

--Yakov

Re: place for printing info about partition distribution

[Yakov Zhdanov]

Vadim, we don't have FairAffinity any more. Can you please provide brief
and descriptive format for this message. I think we should print the
message on exchange finish before rebalancing procedure start.

--Yakov

Re: Replace Cron4J with Quartz for ignite-schedule module.

[Yakov Zhdanov]

Guys, I remember we discussed this some time ago.

http://apache-ignite-developers.2346864.n4.nabble.com/Tasks-Scheduling-and-Chaining-td14293.html

Denis, do you have any ticket or SoW?

--Yakov

[GitHub] ignite pull request #2192: fix metadata update

[sboikov]

GitHub user sboikov opened a pull request:

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

fix metadata update



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

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

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

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


commit a2b4751f5eefd70a5a1aa26652c9671240125f78
Author: dkarachentsev 
Date:   2017-03-17T11:57:48Z

IGNITE-4473 - Client should re-try connection attempt in case of concurrent 
network failure.

(cherry picked from commit d124004)

commit c4de164392ddc114c88d5a6eba0ff0b13d32542f
Author: AMRepo 
Date:   2017-03-20T13:31:15Z

IGNITE-518: Unmuted tests that was fixed in ignite-4036. This closes #1636.

commit e0c012d977b6db13dfdf2fb8347677998287c1e4
Author: Igor Sapego 
Date:   2017-03-21T14:50:06Z

IGNITE-4200: Added copying of the C++ binaries.

commit 8d9ade2cc2d71f12a427e3effa3846a928b0681e
Author: dkarachentsev 
Date:   2017-03-22T11:57:24Z

Merge branch 'ignite-1.7.9-p1' into ignite-1.7.10

commit b7ab27301b59bf93fc73b52fdf8e0bcf124fec1d
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4832: Prevent service deployment on client by default when 
configuration is provided on startup. This closes #1748.

commit 443ac9a7aa82af1359a03bcfc8f9212b108300e4
Author: Andrey V. Mashenkov 
Date:   2017-04-05T12:01:02Z

IGNITE-4917: Fixed failure when accessing BinaryObjectBuilder field value 
serialized with OptimizedMarshaller . This closes #1736.

commit 4a1415ad01ff9fde30d5c7c02e6d938f1515178d
Author: Andrey V. Mashenkov 
Date:   2017-04-12T10:01:25Z

IGNITE-4907: Fixed excessive service instances can be started with dynamic 
deployment. This closes #1766.

(cherry picked from commit 0f7ef74)

commit bf1049741f7a64728bd433f78262ba273f969848
Author: Andrey V. Mashenkov 
Date:   2017-04-17T16:00:30Z

IGNITE-4954 - Configurable expiration timeout for Cassandra session. This 
closes #1785.

commit f9ecacc625b458539775e6550bd9b7613ed38f21
Author: dkarachentsev 
Date:   2017-04-28T08:46:23Z

IGNITE-5077 - Support service security permissions

backport from master
(cherry picked from commit 6236b5f)

commit 91c899b909383c78b78b9bf0c8f233b8c75ef29e
Author: Valentin Kulichenko 
Date:   2017-04-28T12:48:57Z

IGNITE-5081 - Removed redundant duplication of permissions in 
SecurityPermissionSetBuilder

commit b48a26b9b1e97fb8eb52c2a2f36005770922ac3d
Author: Valentin Kulichenko 
Date:   2017-04-28T12:53:33Z

IGNITE-5080 - Fixes in SecurityBasicPermissionSet

commit f66c23cbb9a6f2c923ebf75c58f00afaf1c0b5f3
Author: Evgenii Zhuravlev 
Date:   2017-05-03T14:47:45Z

IGNITE-4939 Receive event before cache initialized fix

commit 45b4d6316145d0b4b46713409f5e8fbe55ff4c41
Author: Evgenii Zhuravlev 
Date:   2017-05-04T09:11:37Z

IGNITE-4939 Receive event before cache initialized fix

commit 075bcfca0ea22633be13cd02647e359ad6fdca16
Author: Andrey V. Mashenkov 
Date:   2017-05-04T09:21:04Z

Fix flacky service deployment tests.

commit 25c06b50d46937cb39534cdf4147b862217289a2
Author: rfqu 
Date:   2017-05-02T16:46:44Z

ignite-4220 Support statements for JDBC and Cassandra store

commit 987c182686962673e70398395cb27e94f894713b
Author: nikolay_tikhonov 
Date:   2017-05-15T08:54:16Z

Fixed "IGNITE-5214 ConcurrentModificationException with enable DEBUG log 
level"

Signed-off-by: nikolay_tikhonov 

commit ebc4a1648a80fbbd485e4c351fce9bee163318f9
Author: sboikov 
Date:   2017-05-16T08:30:29Z

DirectByteBufferStreamImpl: converted asserts into exceptions.

(cherry picked from commit 560ef60)

commit 9cd7e0f8d132f9b7c496fe64f75f271ef60da5eb
Author: Alexey Kuznetsov 
Date:   2017-02-09T09:44:41Z

IGNITE-4676 Fixed hang if closure executed nested internal task with 
continuation. Added test.
(cherry picked from commit e7a5307)

commit 43bcc15127bd3fd7ac4e277da6da9e5fb6a855c0
Author: Vasiliy Sisko 
Date:   2017-03-30T04:08:10Z

IGNITE-4838 Fixed internal task detection logic. Added tests.
(cherry picked from commit ba68c6c)

commit 2a818d36395dd1af23acf444adf396b2e2edbede
Author: Konstantin Dudkov 
Date:   2017-05-22T13:28:07Z

Fixed "IGNITE-4205 

Re: GridCacheAdapter#size() has O(n) complexity

[Yakov Zhdanov]

Guys, I see little inconsistency. Imagine user does 1000 puts with near
cache enabled. Then user does some gets() and size() returns 1000 + N, more
gets() and size() is 1000 + M. This is a bit weird. Can we have nearSize()
on public API? Any thoughts here?

As far as the original issue I would not bother with validity check on
getting size and just return raw map size.

--Yakov

[jira] [Created] (IGNITE-5586) Visor CMD: Add possibility to activate/deactivate grid

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-5586:
-

 Summary: Visor CMD: Add possibility to activate/deactivate grid
 Key: IGNITE-5586
 URL: https://issues.apache.org/jira/browse/IGNITE-5586
 Project: Ignite
  Issue Type: Task
  Components: wizards
Affects Versions: 2.1
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


Extend top command to activate/deactivate grid.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5585) NPE at CacheContinuousQueryManager.skipUpdateEvent during load test

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-5585:
---

 Summary: NPE at CacheContinuousQueryManager.skipUpdateEvent during 
load test
 Key: IGNITE-5585
 URL: https://issues.apache.org/jira/browse/IGNITE-5585
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.8
Reporter: Ksenia Rybakova


Load test config:
- CacheRandomOperation benchmark
- Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
remove_all, put_if_absent, replace
- Heap: 8Gb for servers, 4Gb for clients
- 5 clients, 20 servers
- 12 caches od different types (refer to config)
- Backups count: 1

NPE occurs at different server nodes:
{noformat}
[11:02:40,210][ERROR][sys-stripe-3-#4%null%][GridCacheIoManager] Failed 
processing message [senderId=4563d4fe-26a7-4b51-8bee-27159c9595d9, 
msg=GridDhtAtomicUpdateRequest [futVer=GridCacheVersion [topVer=109944018, 
time=1498464160167, ord
er=1498486560554, nodeOrder=12], writeVer=GridCacheVersion [topVer=109944018, 
time=1498464160167, order=1498486560553, nodeOrder=12], 
topVer=AffinityTopologyVersion [topVer=25, minorTopVer=0], 
keys=[KeyCacheObjectImpl [val=1047562, hasVa
lBytes=true], KeyCacheObjectImpl [val=106245, hasValBytes=true], 
KeyCacheObjectImpl [val=1246917, hasValBytes=true], KeyCacheObjectImpl 
[val=127624, hasValBytes=true], KeyCacheObjectImpl [val=166631, 
hasValBytes=true], KeyCacheObjectImpl
 [val=31560, hasValBytes=true], KeyCacheObjectImpl [val=446054, 
hasValBytes=true]], vals=[o.a.i.yardstick.cache.model.Account 
[idHash=2028849570, hash=1858002766, balance=1047562], 
o.a.i.yardstick.cache.model.Person1 [idHash=53911759, ha
sh=106245, val1=106245], o.a.i.yardstick.cache.model.Person1 
[idHash=2004318126, hash=1246917, val1=1246917], 
o.a.i.yardstick.cache.model.Account [idHash=1146256840, hash=1589210217, 
balance=127624], o.a.i.yardstick.cache.model.Account [
idHash=62912643, hash=39960152, balance=166631], 
o.a.i.yardstick.cache.model.Account [idHash=810836577, hash=1131557455, 
balance=31560], o.a.i.yardstick.cache.model.Account [idHash=1946609424, 
hash=1691380387, balance=446054]], prevVals=
null, ttls=null, conflictExpireTimes=null, nearTtls=null, nearExpireTimes=null, 
syncMode=PRIMARY_SYNC, nearKeys=null, nearVals=null, 
forceTransformBackups=false, subjId=fb6f99ad-09fb-471f-8e8a-280049758dcd, 
taskNameHash=0, updateCntrs=Gr
idLongList [idx=7, arr=[5235,6992,6993,7223,7169,5376,6439]], keepBinary=false, 
flags=0, super=GridCacheMessage [msgId=15154, depInfo=null, err=null, 
skipPrepare=false, cacheId=1489451830, cacheId=1489451830]]]
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.skipUpdateEvent(CacheContinuousQueryManager.java:186)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2283)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3276)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1800(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$8.apply(GridDhtAtomicCache.java:379)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$8.apply(GridDhtAtomicCache.java:374)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:827)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:369)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:95)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:238)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1512)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1140)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:119)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1080)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:428)
at java.lang.Thread.run(Thread.java:745)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Vyacheslav Daradur]

Guys, any thoughts?

2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur :

> Hi Igniters.
>
> I have some user cases where I need fast storage with TDE support.
> It is requered for PCI DSS certification.
>
> As far as I know AI doesn't support it.
>
> I looked at other storages.
> Many storages support it or are engaged in development this feature.
>
> Cassandra community are working on TDE support.[1]
>
> Oracle support it.[2] Moreover it supports indexing and querying on
> encrypted data.
>
> I think it will be very usefull to support TDE by AI.
>
> What do you think? Maybe development is already under way?
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
> [2] https://docs.oracle.com/cd/B19306_01/network.102/b14268/
> asotrans.htm#ASOAG600
>
> --
> Best Regards, Vyacheslav D.
>



-- 
Best Regards, Vyacheslav D.

[jira] [Created] (IGNITE-5584) Exception on grid activation on daemon node

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-5584:
-

 Summary: Exception on grid activation on daemon node
 Key: IGNITE-5584
 URL: https://issues.apache.org/jira/browse/IGNITE-5584
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Vasiliy Sisko
Assignee: Dmitriy Govorukhin


On activation of grid failed exception on connected to grid Visor cmd.

{code}
Failed to register MBean for MemoryMetrics with name: '15MB_Region_Swapping'
javax.management.InstanceAlreadyExistsException: 
org.apache:clsLdr=a2c6f70,igniteInstanceName=tester,group=MemoryMetrics,name=15MB_Region_Swapping
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at 
org.apache.ignite.internal.util.IgniteUtils.registerMBean(IgniteUtils.java:4501)
at 
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.registerMetricsMBean(IgniteCacheDatabaseSharedManager.java:152)
at 
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.registerMetricsMBeans(IgniteCacheDatabaseSharedManager.java:137)
at 
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.init(IgniteCacheDatabaseSharedManager.java:121)
at 
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:104)
at 
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.onActivate(IgniteCacheDatabaseSharedManager.java:968)
at 
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onActivate(GridClusterStateProcessor.java:747)
at 
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onChangeGlobalState(GridClusterStateProcessor.java:655)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:719)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:563)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1859)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)