Re: [ANNOUNCE] New committer: Aleksei Scherbakov

[Zhenya Stanilovsky]

Big deal and huge responsibility.

Congrats Aleksei!


Hello Ignite Community,

The Project Management Committee (PMC) for Apache Ignite has invited
Aleksei Scherbakov to become a committer and we are pleased to announce
that he has accepted.

Aleksei investigated and fixed a lot of critical issues. Seems,  
everybody's

familiar with "partitions counters" fix
https://issues.apache.org/jira/browse/IGNITE-10078 solved huge
data loss issue. On top of that, Aleksei recently finished Data  
Consistency

wiki: https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency
It will definitely help newcomers in better understanding of product
internals.

Being a committer enables easier contribution to the project since there  
is

no need to go via the patch submission process. This should enable better
productivity.

Aleksei, thank you!

Best Regards,
Dmitriy Pavlov
on behalf of Apache Ignite PMC

Re: joining

[Prashant Rahulkar]

Hello Everyone,
I have started software firm in India, with complete motivation to focus on
open source technologies, so as a part of company policy we will star to
contribute in this project with our company name.


Thanks,
PrashantR.

Re: [ANNOUNCE] New Apache Ignite PMC member: Ivan Pavlukhin

[Ivan Pavlukhin]

Thanks!

чт, 12 дек. 2019 г. в 18:31, Kseniya Romanova :
>
> My congratulations!
>
> чт, 12 дек. 2019 г., 15:24 Andrey Mashenkov :
>
> > Congrats, Ivan!
> >
> > On Thu, Dec 12, 2019 at 5:41 PM Dmitriy Pavlov  wrote:
> >
> > > Hello Ignite Community,
> > >
> > >
> > >
> > > The Project Management Committee (PMC) for Apache Ignite has invited Ivan
> > > Pavlukhin to become a PMC member and we are pleased to announce that he
> > has
> > > accepted.
> > >
> > >
> > >
> > > We appreciate Ivan’s efforts in supporting newcomers. Also, Ivan
> > > contributed MVCC deadlock detector. He is very active dev-list member, he
> > > contributes ideas and does review,- all these things are essential for
> > > community building.
> > >
> > >
> > >
> > > Being a PMC member enables assistance with the management and to guide
> > the
> > > direction of the project.
> > >
> > >
> > >
> > > Please join me in welcoming Ivan’s in his new role in the Apache Ignite
> > > community. Ivan, keep the pace!
> > >
> > >
> > >
> > > Best Regards,
> > >
> > > Dmitriy Pavlov
> > >
> > > on behalf of Apache Ignite PMC
> > >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >



-- 
Best regards,
Ivan Pavlukhin

[ANNOUNCE] New committer: Aleksei Scherbakov

[Dmitriy Pavlov]

Hello Ignite Community,

The Project Management Committee (PMC) for Apache Ignite has invited
Aleksei Scherbakov to become a committer and we are pleased to announce
that he has accepted.

Aleksei investigated and fixed a lot of critical issues. Seems, everybody's
familiar with "partitions counters" fix
https://issues.apache.org/jira/browse/IGNITE-10078 solved huge
data loss issue. On top of that, Aleksei recently finished Data Consistency
wiki: https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency
It will definitely help newcomers in better understanding of product
internals.

Being a committer enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.

Aleksei, thank you!

Best Regards,
Dmitriy Pavlov
on behalf of Apache Ignite PMC

[jira] [Created] (IGNITE-12451) Introduce deadlock detection for cache entry reentrant locks

[Ivan Rakov (Jira)]

Ivan Rakov created IGNITE-12451:
---

 Summary: Introduce deadlock detection for cache entry reentrant 
locks
 Key: IGNITE-12451
 URL: https://issues.apache.org/jira/browse/IGNITE-12451
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.7.6
Reporter: Ivan Rakov
 Fix For: 2.9


Aside from IGNITE-12365, we still have possible threat of cache-entry-level 
deadlock in case of careless usage of JCache mass operations (putAll, 
removeAll):
1. If two different user threads will perform putAll on the same two keys in 
reverse order (primary node for which is the same), there's a chance that 
sys-stripe threads will be deadlocked.
2. Even without direct contract violation from user side, HashMap can be passed 
as argument for putAll. Even if user threads have called mass operations with 
two keys in the same order, HashMap iteration order is not strictly defined, 
which may cause the same deadlock. 

Local deadlock detection should mitigate this issue. We can create a wrapper 
for ReentrantLock with logic that performs cycle detection in wait-for graph in 
case we are waiting for lock acquisition for too long. Exception will be thrown 
from one of the threads in such case, failing user operation, but letting the 
system make progress.



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

[jira] [Created] (IGNITE-12450) Transaction operations metrics

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12450:


 Summary: Transaction operations metrics
 Key: IGNITE-12450
 URL: https://issues.apache.org/jira/browse/IGNITE-12450
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.7.6
Reporter: Nikolay Izhikov
 Fix For: 2.8


We should add histogram metrics that measure tx.commit and tx.rollback time.



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

Re: joining

[Ilya Kasnacheev]

Hello again!

I have added you to Contributors, you may now assign tickets to yourself.

Please read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Regards,
-- 
Ilya Kasnacheev


чт, 12 дек. 2019 г. в 18:34, Ilya Kasnacheev :

> Hello!
>
> You will need to register on https://issues.apache.org/jira/ first.
>
> Please tell me when you do.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 12 дек. 2019 г. в 18:09, :
>
>> Hi Ilya,
>>
>> it’d be nice if it were rkoriakov
>>
>>
>>
>> Best regards,
>>
>> T-Systems RUS
>> Point of Production
>> Roman Koriakov
>> Software Developer
>> Kirova 11, Voronezh, Russia
>> Tel: + 7 473 200 15 30
>> E-mail: roman.koria...@t-systems.com
>> http://www.t-systems.com
>>
>>
>>
>> -Original Message-
>> From: Ilya Kasnacheev 
>> Sent: Thursday, December 12, 2019 5:25 PM
>> To: dev 
>> Subject: Re: joining
>>
>>
>>
>> Hello!
>>
>>
>>
>> I will need an Apache JIRA username to add you to contributors. Can you
>> provide it?
>>
>>
>>
>> Regards,
>>
>> --
>>
>> Ilya Kasnacheev
>>
>>
>>
>>
>>
>> чт, 12 дек. 2019 г. в 17:20, > roman.koria...@t-systems.com>>:
>>
>>
>>
>> > Hi everyone,
>>
>> > I'd like to participate in this  project!
>>
>> >
>>
>> > Best regards,
>>
>> >
>>
>> > T-Systems RUS
>>
>> > Point of Production
>>
>> > Roman Koriakov
>>
>> > Software Developer
>>
>> > Kirova 11, Voronezh, Russia
>>
>> > Tel: + 7 473 200 15 30
>>
>> > E-mail: roman.koria...@t-systems.com> roman.koria...@t-systems.com> 3cmailto:roman.koria...@t-systems.com>>
>>
>> > http://www.t-systems.com> http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
>>
>> >
>>
>> >
>>
>

[jira] [Created] (IGNITE-12449) Calcite integration. Execution flow.

[Igor Seliverstov (Jira)]

Igor Seliverstov created IGNITE-12449:
-

 Summary: Calcite integration. Execution flow.
 Key: IGNITE-12449
 URL: https://issues.apache.org/jira/browse/IGNITE-12449
 Project: Ignite
  Issue Type: Task
Reporter: Igor Seliverstov


We need to introduce query execution environment.

Execution should:
* use streaming approach
* have suspend/resume ability
* work in event loop threads



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

[jira] [Created] (IGNITE-12448) Calcite integration. Communication protocol.

[Igor Seliverstov (Jira)]

Igor Seliverstov created IGNITE-12448:
-

 Summary: Calcite integration. Communication protocol.
 Key: IGNITE-12448
 URL: https://issues.apache.org/jira/browse/IGNITE-12448
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Igor Seliverstov


We need to introduce a communication protocol between query fragments in scope 
of query execution.
* Protocol should have Push semantics with back pressure ability
* Protocol have to provide ordering guaranties - the data batches processed in 
same order they sent to remote node.
* Protocol have to provide delivery guaranties.



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

[jira] [Created] (IGNITE-12447) Modification of S#compact method

[Kirill Tkalenko (Jira)]

Kirill Tkalenko created IGNITE-12447:


 Summary: Modification of S#compact method
 Key: IGNITE-12447
 URL: https://issues.apache.org/jira/browse/IGNITE-12447
 Project: Ignite
  Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
 Fix For: 2.8


Modification of S#compact method so that it is possible to pass collection of 
Numbers.



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

[jira] [Created] (IGNITE-12446) Calcite integration. Fix javadocs and code style.

[Igor Seliverstov (Jira)]

Igor Seliverstov created IGNITE-12446:
-

 Summary: Calcite integration. Fix javadocs and code style.
 Key: IGNITE-12446
 URL: https://issues.apache.org/jira/browse/IGNITE-12446
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov


Fix javadocs and code style



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

[jira] [Created] (IGNITE-12445) When Cache Metrics are switched on (statisticsEnabled = true) the empty cache events arrive to the client nodes

[Roman Koriakov (Jira)]

Roman Koriakov created IGNITE-12445:
---

 Summary: When Cache Metrics are switched on (statisticsEnabled = 
true) the empty cache events arrive to the client nodes 
 Key: IGNITE-12445
 URL: https://issues.apache.org/jira/browse/IGNITE-12445
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.7.6
 Environment: OS Name Microsoft Windows 10 Pro
 java version "1.8.0_231"
 java version OpenJDK 64-Bit Server VM 11+28
Reporter: Roman Koriakov


If we want to react on some PUT or READ cache operations first of all we need 
to turn on the appropriate cache events on the server node and catch those 
events on the client nodes using remote approach with two listeners. It works 
well until we switch on *statisticsEnabled* on the server node, it will lead to 
the situation when we get empty *CacheEvent* objects.

The example that demonstrates this issue is in the attachments. This example is 
consists of three nodes:  1 server node with cache and 2 clients.  One client 
is filling the cache and the second one is listening PUT operations. When we 
turn on Cache Metrics on the server node: 
*cacheConfig.setStatisticsEnabled(true);* in *EventServerCache.java* we get 
empty events ({color:#172b4d}Sometimes {color}CacheEvent objects with null 
fields. Sometimes there are no events at all)

My suppose is there is some Exception in GridCacheEventManager.addEvent() when 
Cache Metrics is turned on. 

{color:#cc7832}catch {color}(Exception e) {
   {color:#cc7832}if 
{color}(!{color:#9876aa}cctx{color}.cacheObjectContext().kernalContext().cacheObjects().isBinaryEnabled({color:#9876aa}cctx{color}.config()))
     {color:#cc7832}throw {color}e{color:#cc7832};{color}{color:#cc7832}  if 
{color}({color:#9876aa}log{color}.isDebugEnabled())
      {color:#9876aa}log{color}.debug({color:#6a8759}"Failed to unmarshall 
cache object value for the event notification: " {color}+ 
e){color:#cc7832};{color}{color:#cc7832}  {color}

{color:#cc7832}  if {color}(!{color:#9876aa}forceKeepBinary{color})
     LT.warn({color:#9876aa}log{color}{color:#cc7832}, 
{color}{color:#6a8759}"Failed to unmarshall cache object value for the event 
notification " {color}+
              {color:#6a8759}"(all further notifications will keep binary 
object format)."{color}){color:#cc7832};{color} 

{color:#9876aa}  forceKeepBinary {color}= {color:#cc7832}true;{color} 

  key0 = 
{color:#9876aa}cctx{color}.cacheObjectContext().unwrapBinaryIfNeeded(key{color:#cc7832},
 true, false{color}){color:#cc7832};{color} 

  val0 = 
{color:#9876aa}cctx{color}.cacheObjectContext().unwrapBinaryIfNeeded(newVal{color:#cc7832},
 true, false{color}){color:#cc7832};{color} 

  oldVal0 = 
{color:#9876aa}cctx{color}.cacheObjectContext().unwrapBinaryIfNeeded(oldVal{color:#cc7832},
 true, false{color}){color:#cc7832};{color}

}



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

[jira] [Created] (IGNITE-12444) SQL: Query reduce can fail with NPE on retry.

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-12444:
-

 Summary: SQL: Query reduce can fail with NPE on retry.
 Key: IGNITE-12444
 URL: https://issues.apache.org/jira/browse/IGNITE-12444
 Project: Ignite
  Issue Type: Test
  Components: sql
Reporter: Andrey Mashenkov


GridReduceQueryExecutor can fail with NPE on retry if it couldn't map during 
retry timeout.
So, 'lastRun' can be null here

{code:java}
   if (attempt > 0 && retryTimeout > 0 && (U.currentTimeMillis() - startTime > 
retryTimeout)) {
UUID retryNodeId = lastRun.retryNodeId();
String retryCause = lastRun.retryCause();

assert !F.isEmpty(retryCause);
{code}

Also assertion above is not correct. 
It is possible, we failed to send request, then retried with success to remap.
So, 'lastRun' would be not null, but cause is empty.



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

[jira] [Created] (IGNITE-12443) Document the Ignite Sandbox

[Denis Garus (Jira)]

Denis Garus created IGNITE-12443:


 Summary: Document the Ignite Sandbox
 Key: IGNITE-12443
 URL: https://issues.apache.org/jira/browse/IGNITE-12443
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Garus


Document how to configure and use the Ignite Sandbox.



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

[jira] [Created] (IGNITE-12442) Fix unnecessary synchronized on PagesCache#add.

[Stanilovsky Evgeny (Jira)]

Stanilovsky Evgeny created IGNITE-12442:
---

 Summary: Fix unnecessary synchronized on PagesCache#add.
 Key: IGNITE-12442
 URL: https://issues.apache.org/jira/browse/IGNITE-12442
 Project: Ignite
  Issue Type: Improvement
  Components: data structures
Affects Versions: 2.7.6
Reporter: Stanilovsky Evgeny


After [IGNITE-6930|https://issues.apache.org/jira/browse/IGNITE-6930] was 
implemented, there are some synchronization extra usage found.
1. 
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#add
2. 
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#emptyFlushCnt

hope need to fix it.



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

Re: Adding support for Ignite secondary indexes to Apache Calcite planner

[Seliverstov Igor]

Colleagues,

As far as I understand, materialization acts like a special rule, that matches 
some subtree pattern (a leaf part of a query plan) to a star table, which may 
have better cost than the subtree, it replaces. Saying that, in general, there 
is no difference between approaches - they do the same almost in the same way 
but using different API.

My opinion is it’s better to do the deal using rules - it makes overall 
approach consistent.

Regards,
Igor

> 12 дек. 2019 г., в 10:03, Vladimir Ozerov  написал(а):
> 
> Roman,
> 
> What I am trying to understand is what advantage of materialization API you
> see over the normal optimization process? Does it save optimization time,
> or reduce memory footprint, or maybe provide better plans? I am asking
> because I do not see how expressing indexes as materializations fit
> classical optimization process. We discussed Sort <- Scan optimization.
> Let's consider another example:
> 
> LogicalSort[a ASC]
>  LogicalJoin
> 
> Initially, you do not know the implementation of the join, and hence do not
> know it's collation. Then you may execute physical join rules, which
> produce, say, PhysicalMergeJoin[a ASC]. If you execute sort implementation
> rule afterwards, you may easily eliminate the sort, or make it simpler
> (e.g. remove local sorting phase), depending on the distribution. In other
> words, proper implementation of sorting optimization assumes that you have
> a kind of SortRemoveRule anyway, irrespectively of whether you use
> materializations or not, because sorting may be injected on top of any
> operator. With this in mind, the use of materializations doesn't make the
> planner simpler. Neither it improves the outcome of the whole optimization
> process.
> 
> What is left is either lower CPU or RAM usage? Is this the case?
> 
> ср, 11 дек. 2019 г. в 18:37, Roman Kondakov :
> 
>> Vladimir,
>> 
>> the main advantage of the Phoenix approach I can see is the using of
>> Calcite's native materializations API. Calcite has advanced support for
>> materializations [1] and lattices [2]. Since secondary indexes can be
>> considered as materialized views (it's just a sorted representation of
>> the same table) we can seamlessly use views to simulate indexes behavior
>> for Calcite planner.
>> 
>> 
>> [1] https://calcite.apache.org/docs/materialized_views.html
>> [2] https://calcite.apache.org/docs/lattice.html
>> 
>> --
>> Kind Regards
>> Roman Kondakov
>> 
>> 
>> On 11.12.2019 17:11, Vladimir Ozerov wrote:
>>> Roman,
>>> 
>>> What is the advantage of Phoenix approach then? BTW, it looks like
>> Phoenix
>>> integration with Calcite never made it to production, did it?
>>> 
>>> вт, 10 дек. 2019 г. в 19:50, Roman Kondakov >> :
>>> 
 Hi Vladimir,
 
 from what I understand, Drill does not exploit collation of indexes. To
 be precise it does not exploit index collation in "natural" way where,
 say, we a have sorted TableScan and hence we do not create a new Sort.
 Instead of it Drill always create a Sort operator, but if TableScan can
 be replaced with an IndexScan, this Sort operator is removed by the
 dedicated rule.
 
 Lets consider initial an operator tree:
 
 Project
  Sort
TableScan
 
 after applying rule DbScanToIndexScanPrule this tree will be converted
>> to:
 
 Project
  Sort
IndexScan
 
 and finally, after applying DbScanSortRemovalRule we have:
 
 Project
  IndexScan
 
 while for Phoenix approach we would have two equivalent subsets in our
 planner:
 
 Project
  Sort
TableScan
 
 and
 
 Project
  IndexScan
 
 and most likely the last plan  will be chosen as the best one.
 
 --
 Kind Regards
 Roman Kondakov
 
 
 On 10.12.2019 17:19, Vladimir Ozerov wrote:
> Hi Roman,
> 
> Why do you think that Drill-style will not let you exploit collation?
> Collation should be propagated from the index scan in the same way as
>> in
> other sorted operators, such as merge join or streaming aggregate.
 Provided
> that you use converter-hack (or any alternative solution to trigger
 parent
> re-analysis).
> In other words, propagation of collation from Drill-style indexes
>> should
 be
> no different from other sorted operators.
> 
> Regards,
> Vladimir.
> 
> вт, 10 дек. 2019 г. в 16:40, Zhenya Stanilovsky
 > :
> 
>> 
>> Roman just as fast remark, Phoenix builds their approach on
>> already existing monolith HBase architecture, most cases it`s just a
 stub
>> for someone who wants use secondary indexes with a base with no
>> native support of it. Don`t think it`s good idea here.
>> 
>>> 
>>> 
>>> --- Forwarded message ---
>>> From: "Roman Kondakov" < kondako...@mail.ru.invalid >
>>> To:  dev@ignite.apache.org
>>> Cc:
>>> Subject: 

When Cache Metrics are switched on (statisticsEnabled = true) the empty cache events arrive to the client nodes

[Roman.Koriakov]

Hi Community,

I’d like to ask you about the following behavior of Apache Ignite:


If we want to react on some PUT or READ cache operations first of all we need 
to turn on the appropriate cache events on the server node and catch those 
events on the client nodes using remote approach with two listeners. It works 
well until we switch on statisticsEnabled on the server node, it will lead to 
the situation when we get empty CacheEvent objects.

The example that demonstrates this issue is in the attachments. This example is 
consists of three nodes:  1 server node with cache and 2 clients.  One client 
is filling the cache and the second one is listening PUT operations. When we 
turn on Cache Metrics on the server node: 
cacheConfig.setStatisticsEnabled(true); in EventServerCache.java we get empty 
events (Sometimes CacheEvent objects with null fields. Sometimes there are no 
events at all)

My suppose is there is some Exception in GridCacheEventManager.addEvent() when 
Cache Metrics is turned on.

catch (Exception e) {
  if 
(!cctx.cacheObjectContext().kernalContext().cacheObjects().isBinaryEnabled(cctx.config()))
throw e;  if (log.isDebugEnabled())
 log.debug("Failed to unmarshall cache object value for the event 
notification: " + e);

  if (!forceKeepBinary)
LT.warn(log, "Failed to unmarshall cache object value for the event 
notification " +
 "(all further notifications will keep binary object format).");

  forceKeepBinary = true;

  key0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(key, true, false);

  val0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(newVal, true, false);

  oldVal0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(oldVal, true, false);

}

Can public this point in JIRA?

Best regards,

T-Systems RUS
Point of Production
Roman Koriakov
Software Developer
Kirova 11, Voronezh, Russia
Tel: + 7 473 200 15 30
E-mail: roman.koria...@t-systems.com
http://www.t-systems.com



-Original Message-
From: Ilya Kasnacheev 
Sent: Thursday, December 12, 2019 6:35 PM
To: dev 
Subject: Re: joining



Hello!



You will need to register on https://issues.apache.org/jira/ first.



Please tell me when you do.



Regards,

--

Ilya Kasnacheev





чт, 12 дек. 2019 г. в 18:09, 
mailto:roman.koria...@t-systems.com>>:



> Hi Ilya,

>

> it’d be nice if it were rkoriakov

>

>

>

> Best regards,

>

> T-Systems RUS

> Point of Production

> Roman Koriakov

> Software Developer

> Kirova 11, Voronezh, Russia

> Tel: + 7 473 200 15 30

> E-mail: 
> roman.koria...@t-systems.com>

> http://www.t-systems.com>

>

>

>

> -Original Message-

> From: Ilya Kasnacheev 
> mailto:ilya.kasnach...@gmail.com>>

> Sent: Thursday, December 12, 2019 5:25 PM

> To: dev mailto:dev@ignite.apache.org>>

> Subject: Re: joining

>

>

>

> Hello!

>

>

>

> I will need an Apache JIRA username to add you to contributors. Can you

> provide it?

>

>

>

> Regards,

>

> --

>

> Ilya Kasnacheev

>

>

>

>

>

> чт, 12 дек. 2019 г. в 17:20,  roman.koria...@t-systems.com>>:

>

>

>

> > Hi everyone,

>

> > I'd like to participate in this  project!

>

> >

>

> > Best regards,

>

> >

>

> > T-Systems RUS

>

> > Point of Production

>

> > Roman Koriakov

>

> > Software Developer

>

> > Kirova 11, Voronezh, Russia

>

> > Tel: + 7 473 200 15 30

>

> > E-mail: 
> > roman.koria...@t-systems.com

>  >>

>

> > http://www.t-systems.com

> http://www.t-systems.com%3chttp:/www.t-systems.ru/>>

>

> >

>

> >

>

Re: Re[4]: Text queries/indexes (GridLuceneIndex, @QueryTextFiled)

[Ivan Pavlukhin]

Yuriy,

Sure, I will be glad to help.

> - incorrect nodes/partition selection during querying?
Apparently this is the problem. If you feel it really complicated to
understand and debug then I can dig deeper and share my vision how the
problem can be fixed.

ср, 11 дек. 2019 г. в 18:46, Yuriy Shuliga :
>
> I will look to the MOVING partition issue.
> But also need a guidance there.
>
> Ivan, don't you mind to be that person?
>
> The question is whether we have an issue with:
> -  wrong storing targets during indexing OR
> - incorrect nodes/partition selection during querying?
>
> BR,
> Yuriy Shluiha
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/



-- 
Best regards,
Ivan Pavlukhin