[jira] [Created] (IGNITE-12281) Data search from Ignite Cache value object

[ROHIT SANGWAN (Jira)]

ROHIT SANGWAN created IGNITE-12281:
--

 Summary: Data search from Ignite Cache value object
 Key: IGNITE-12281
 URL: https://issues.apache.org/jira/browse/IGNITE-12281
 Project: Ignite
  Issue Type: Wish
Reporter: ROHIT SANGWAN


Hi Team,

 

I am solution for data look up from Ignite cache value. I found multiple 
operation where I can use key to get the value. But I have a use case where I 
want to apply search on few attributes of value on a certain cache. I tried 
scan query but its very costly operation. Please help me to find a effective 
solution.



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

Re: IGNITE-12236 RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in IgniteRepositoryFactory

[Denis Magda]

Hello Thibaut,

If IGNITE-12236 and IGNITE-12259 solve your problem, then it's totally fine
to get them merged.

Maxim, looks like you are already reviewing one of the tickets. Could you
please double-check two tickets holistically and merge them in case of no
concerns?

-
Denis


On Wed, Oct 9, 2019 at 3:27 AM thibaut 
wrote:

> Hello,
>
> New guy here.
>
> When I was trying to use ignite with an up to date version of
> spring-data-commons I ended up having some issues since ignite uses version
> 2.0.9. (see  IGNITE-12236
>   )
> As of 2.1.0 RepositoryFactorySupport#getQueryLookupStrategy changed its
> signature with this  commit
> <
> https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5>
>
> .
>
> Already made a PR but I realized after the fact that there is a few issues
> asking to update but not one seems to fix this problem:
> IGNITE-12129
> <
> https://issues.apache.org/jira/browse/IGNITE-12129?jql=project%20%3D%20IGNITE%20AND%20component%20%3D%20spring>
>
> IGNITE-12259 
>
> Maybe 12129 and my issue should be merged (its pom + this
> IgniteRepositoryFactory).
>
> What do you think?
>
> BR,
> Thibaut
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[jira] [Created] (IGNITE-12280) Removal of this limitation "It's not recommended to have class hierarchies with raw reading/writing"

[Sam (Jira)]

Sam created IGNITE-12280:


 Summary: Removal of this limitation "It's not recommended to  have 
class hierarchies with raw reading/writing"
 Key: IGNITE-12280
 URL: https://issues.apache.org/jira/browse/IGNITE-12280
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.7
Reporter: Sam


when tried to use raw mode with a class chain where both extending class and 
superclass calls rawReader(), facing 
"org.apache.ignite.binary.BinaryObjectException: Method rawReader can be called 
only once." . 

This seems to be a limitation that needs extra programmatic workaround to 
support hierarchy or chain of classes in serializer/deserializer. Extra code 
has the hassle of maintenance and quite different from other tools. 

more details on user group 
[http://apache-ignite-users.70518.x6.nabble.com/Exception-Method-rawReader-can-be-called-only-once-td29556.html]

 

 

 

 



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

Re: Ignite Community Growth Activities and Twitter

[Denis Magda]

Kseniya, welcome to the community and thanks for offering the help with
these activities. Most of us are focused on the code over community
+  awareness, and that's great to have you among those who can dedicate
more time for community growth and Ignite/ASF promotion.

Let me also introduce you to Sally Khudairi (ASF VP of Marketing &
Publicity & Sponsor Relations) who can support you from the ASF end.

I'll send you over the twitter credentials. Would you also keep our events
page up-to-date? [1] Mauricio tended to help us with updates before.
https://ignite.apache.org/events.html

-
Denis


On Thu, Oct 10, 2019 at 12:42 PM Kseniya Romanova 
wrote:

> Hi igniters!
>
> For last two years I've been organizing Ignite online and offline events
> for Russia. Now I would like to offer my help with global community growth
> activities: events, working with blog authors, cross-promotion with other
> communities etc.
>
> Could you share access to AI twitter, so I can post sometimes info about
> these activities?
>
> Regards,
> Kseniya
>

Ignite Community Growth Activities and Twitter

[Kseniya Romanova]

Hi igniters!

For last two years I've been organizing Ignite online and offline events
for Russia. Now I would like to offer my help with global community growth
activities: events, working with blog authors, cross-promotion with other
communities etc.

Could you share access to AI twitter, so I can post sometimes info about
these activities?

Regards,
Kseniya

Re: How to free up space on disc after removing entries from IgniteCache with enabled PDS?

[Sergey Kozlov]

Alexey

I'm ok for the suggested way in [1]

1. https://issues.apache.org/jira/browse/IGNITE-12263

On Tue, Oct 8, 2019 at 9:59 PM Denis Magda  wrote:

> Anton,
>
> Seems like we have a name for the defragmentation mode with a downtime -
> Rolling Defrag )
>
> -
> Denis
>
>
> On Mon, Oct 7, 2019 at 11:04 PM Anton Vinogradov  wrote:
>
> > Denis,
> >
> > I like the idea that defragmentation is just an additional step on a node
> > (re)start like we perform PDS recovery now.
> > We may just use special key to specify node should defragment persistence
> > on (re)start.
> > Defragmentation can be the part of Rolling Upgrade in this case :)
> > It seems to be not a problem to restart nodes one-by-one, this will "eat"
> > only one backup guarantee.
> >
> > On Mon, Oct 7, 2019 at 8:28 PM Denis Magda  wrote:
> >
> > > Alex, thanks for the summary and proposal. Anton, Ivan and others who
> > took
> > > part in this discussion, what're your thoughts? I see this
> > > rolling-upgrades-based approach as a reasonable solution. Even though a
> > > node shutdown is expected, the procedure doesn't lead to the cluster
> > outage
> > > meaning it can be utilized for 24x7 production environments.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Mon, Oct 7, 2019 at 1:35 AM Alexey Goncharuk <
> > > alexey.goncha...@gmail.com>
> > > wrote:
> > >
> > > > Created a ticket for the first stage of this improvement. This can
> be a
> > > > first change towards the online mode suggested by Sergey and Anton.
> > > > https://issues.apache.org/jira/browse/IGNITE-12263
> > > >
> > > > пт, 4 окт. 2019 г. в 19:38, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > > >
> > > > > Maxim,
> > > > >
> > > > > Having a cluster-wide lock for a cache does not improve
> availability
> > of
> > > > > the solution. A user cannot defragment a cache if the cache is
> > involved
> > > > in
> > > > > a mission-critical operation, so having a lock on such a cache is
> > > > > equivalent to the whole cluster shutdown.
> > > > >
> > > > > We should decide between either a single offline node or a more
> > complex
> > > > > fully online solution.
> > > > >
> > > > > пт, 4 окт. 2019 г. в 11:55, Maxim Muzafarov :
> > > > >
> > > > >> Igniters,
> > > > >>
> > > > >> This thread seems to be endless, but we if some kind of cache
> group
> > > > >> distributed write lock (exclusive for some of the internal Ignite
> > > > >> process) will be introduced? I think it will help to solve a batch
> > of
> > > > >> problems, like:
> > > > >>
> > > > >> 1. defragmentation of all cache group partitions on the local node
> > > > >> without concurrent updates.
> > > > >> 2. improve data loading with data streamer isolation mode [1]. It
> > > > >> seems we should not allow concurrent updates to cache if we on
> `fast
> > > > >> data load` step.
> > > > >> 3. recovery from a snapshot without cache stop\start actions
> > > > >>
> > > > >>
> > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-11793
> > > > >>
> > > > >> On Thu, 3 Oct 2019 at 22:50, Sergey Kozlov 
> > > > wrote:
> > > > >> >
> > > > >> > Hi
> > > > >> >
> > > > >> > I'm not sure that node offline is a best way to do that.
> > > > >> > Cons:
> > > > >> >  - different caches may have different defragmentation but we
> > force
> > > to
> > > > >> stop
> > > > >> > whole node
> > > > >> >  - offline node is a maintenance operation will require to add
> +1
> > > > >> backup to
> > > > >> > reduce the risk of data loss
> > > > >> >  - baseline auto adjustment?
> > > > >> >  - impact to index rebuild?
> > > > >> >  - cache configuration changes (or destroy) during node offline
> > > > >> >
> > > > >> > What about other ways without node stop? E.g. make cache group
> on
> > a
> > > > node
> > > > >> > offline? Add *defrag  *command to control.sh to
> force
> > > > start
> > > > >> > rebalance internally in the node with expected impact to
> > > performance.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Thu, Oct 3, 2019 at 12:08 PM Anton Vinogradov  >
> > > > wrote:
> > > > >> >
> > > > >> > > Alexey,
> > > > >> > > As for me, it does not matter will it be IEP, umbrella or a
> > single
> > > > >> issue.
> > > > >> > > The most important thing is Assignee :)
> > > > >> > >
> > > > >> > > On Thu, Oct 3, 2019 at 11:59 AM Alexey Goncharuk <
> > > > >> > > alexey.goncha...@gmail.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Anton, do you think we should file a single ticket for this
> or
> > > > >> should we
> > > > >> > > go
> > > > >> > > > with an IEP? As of now, the change does not look big enough
> > for
> > > an
> > > > >> IEP
> > > > >> > > for
> > > > >> > > > me.
> > > > >> > > >
> > > > >> > > > чт, 3 окт. 2019 г. в 11:18, Anton Vinogradov  >:
> > > > >> > > >
> > > > >> > > > > Alexey,
> > > > >> > > > >
> > > > >> > > > > Sounds good to me.
> > > > >> > > > >
> > > > >> > > > > On Thu, Oct 3, 2019 at 10:51 AM Alexey Goncharuk <
> > > > >> > > > > alexey.goncha...@gmail.com>
> > 

[jira] [Created] (IGNITE-12279) Add support for using H2O MOJO models for inference

[Michal (Jira)]

Michal created IGNITE-12279:
---

 Summary: Add support for using H2O MOJO models for inference
 Key: IGNITE-12279
 URL: https://issues.apache.org/jira/browse/IGNITE-12279
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Michal






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

Re: Metric showing how many nodes may safely leave the cluster

[Ivan Rakov]

https://issues.apache.org/jira/browse/IGNITE-12278

Best Regards,
Ivan Rakov

On 07.10.2019 15:08, Ivan Rakov wrote:

Denis, Alex,

Sure, new metric will be integrated into new metrics framework.
Let's not expose its value to control.sh right now. I'll create an 
issue for aggregated "getMinimumNumberOfPartitionCopies" if everyone 
agrees.


Best Regards,
Ivan Rakov

On 04.10.2019 20:06, Denis Magda wrote:

I'm for the proposal to add new JMX metrics and enhance the existing
tooling. But I would encourage us to integrate this into the new metrics
framework Nikolay has been working on. Otherwise, we will be deprecating
these JMX metrics in a short time frame in favor of the new 
monitoring APIs.


-
Denis


On Fri, Oct 4, 2019 at 9:33 AM Alexey Goncharuk 


wrote:


I agree that we should have the ability to read any metric using simple
Ignite tooling. I am not sure if visor.sh is a good fit - if I
remember correctly, it will start a daemon node which will bump the
topology version with all related consequences. I believe in the 
long term

it will beneficial to migrate all visor.sh functionality to a more
lightweight protocol, such as used in control.sh.

As for the metrics, the metric suggested by Ivan totally makes sense 
to me

- it is a simple and, actually, quite critical metric. It will be
completely unusable to select a minimum of some metric for all cache 
groups
manually. A monitoring system, on the other hand, might not be 
available

when the metric is needed, or may not support aggregation.

--AG

пт, 4 окт. 2019 г. в 18:58, Ivan Rakov :


Nikolay,

Many users start to use Ignite with a small project without
production-level monitoring. When proof-of-concept appears to be 
viable,

they tend to expand Ignite usage by growing cluster and adding needed
environment (including monitoring systems).
Inability to find such basic thing as survival in case of next node
crash may affect overall product impression. We all want Ignite to be
successful and widespread.


Can you clarify, what do you mean, exactly?
Right now user can access metric mentioned by Alex and choose 
minimum of

all cache groups. I want to highlight that not every user understands
Ignite and its internals so much to find out that exactly these 
sequence

of actions will bring him to desired answer.


Can you clarify, what do you mean, exactly?
We have a ticket[1] to support metrics output via visor.sh.

My understanding: we should have an easy way to output metric values

for

each node in cluster.

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

I propose to add metric method for aggregated
"getMinimumNumberOfPartitionCopies" and expose it to control.sh.
My understanding: it's result is critical enough to be accessible in a
short path. I've started this topic due to request from user list, and
I've heard many similar complaints before.

Best Regards,
Ivan Rakov

On 04.10.2019 17:18, Nikolay Izhikov wrote:

Ivan.


We shouldn't force users to configure external tools and write extra

code for basic things.

Actually, I don't agree with you.
Having external monitoring system for any production cluster is a

*basic* thing.

Can you, please, define "basic things"?


single method for the whole cluster

Can you clarify, what do you mean, exactly?
We have a ticket[1] to support metrics output via visor.sh.

My understanding: we should have an easy way to output metric values

for

each node in cluster.

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


В Пт, 04/10/2019 в 17:09 +0300, Ivan Rakov пишет:

Max,

What if user simply don't have configured monitoring system?
Knowing whether cluster will survive node shutdown is critical 
for any

administrator that performs any manipulations with cluster topology.
Essential information should be easily accessed. We shouldn't force
users to configure external tools and write extra code for basic

things.

Alex,

Thanks, that's exact metric we need.
My point is that we should make it more accessible: via control.sh
command and single method for the whole cluster.

Best Regards,
Ivan Rakov

On 04.10.2019 16:34, Alex Plehanov wrote:

Ivan, there already exist metric
CacheGroupMetricsMXBean#getMinimumNumberOfPartitionCopies, which

shows

the

current redundancy level for the cache group.
We can lose up to ( getMinimumNumberOfPartitionCopies-1) nodes

without

data

loss in this cache group.

пт, 4 окт. 2019 г. в 16:17, Ivan Rakov :


Igniters,

I've seen numerous requests to find out an easy way to check 
whether

is

it safe to turn off cluster node. As we know, in Ignite protection

from

sudden node shutdown is implemented through keeping several backup
copies of each partition. However, this guarantee can be weakened

for

a

while in case cluster has recently experienced node restart and
rebalancing process is still in progress.
Example scenario is restarting nodes one by one in order to 
update a

local configuration parameter. User restarts one node and

rebalancing

starts: 

[jira] [Created] (IGNITE-12278) Add metric showing how many nodes may safely leave the cluster wihout partition loss

[Ivan Rakov (Jira)]

Ivan Rakov created IGNITE-12278:
---

 Summary: Add metric showing how many nodes may safely leave the 
cluster wihout partition loss
 Key: IGNITE-12278
 URL: https://issues.apache.org/jira/browse/IGNITE-12278
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Rakov
 Fix For: 2.8


We already have getMinimumNumberOfPartitionCopies metrics that shows partitions 
redundancy number for a specific cache group.
It would be handy if user has single aggregated metric for all cache groups 
showing how many nodes may leave the cluster without partition loss in any 
cache.



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

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Ilya Kasnacheev]

Hello!

I think that Documentation tickets may be safely postponed until final
stages of release, since it's not included in artifacts, rather available
on readme.io, etc.

Regards,
-- 
Ilya Kasnacheev


чт, 10 окт. 2019 г. в 14:41, Pavel Kovalenko :

> Issues link is broken, because it has a filter that can't be found.
> Here is correct link:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened%2C%20%22In%20Progress%22%2C%20%22Patch%20Available%22)%20AND%20fixVersion%20%3D%202.8%20and%20component%20%3D%20Documentation%20order%20by%20status
>
> чт, 10 окт. 2019 г. в 13:38, Maxim Muzafarov :
>
> > Igniters,
> >
> >
> > Who can advise what we can\should do with the issues related to
> > `documentation` component to release Ignite 2.8 version?
> > How can I sort them and prioritize?
> > What are best-practices here?
> >
> > Currently, we have 81 issues pinned to 2.8 release [1].
> >
> > 6 - `In Progress`
> > 2 - `Patch Available`
> > 73 - `Open`
> >
> > Some of the issues are assigned to the `Prachi Garg` which is not
> > active since February 15-th 2019.
> >
> > [1]
> >
> https://issues.apache.org/jira/issues/?filter=12347303=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened%2C%20%22In%20Progress%22%2C%20%22Patch%20Available%22)%20AND%20fixVersion%20%3D%202.8%20and%20component%20%3D%20Documentation%20order%20by%20status
> >
> >
> > On Thu, 3 Oct 2019 at 01:52, Denis Magda  wrote:
> > >
> > > Maxim,
> > >
> > > This sounds reasonable to me.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Wed, Oct 2, 2019 at 8:55 AM Maxim Muzafarov 
> > wrote:
> > >
> > > > Folks,
> > > >
> > > > Since we are focusing on new SQL engine implementation I'd like to
> > > > perform bulk moving of all MVCC related unassigned tickets [1] to the
> > > > next release.
> > > > Can you confirm?
> > > >
> > > > [1]
> > > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20fixVersion%20%3D%202.8%20and%20priority%20in%20(Major)%20and%20summary%20~%20MVCC
> > > >
> > > > On Wed, 2 Oct 2019 at 01:27, Denis Magda  wrote:
> > > > >
> > > > > Alexey Z.,
> > > > >
> > > > > Could you please answer some of the questions
> > > > >
> > > > >
> > > > > > - IGNITE-11942 IGFS and Hadoop Accelerator Discontinuation [2].
> > > > > > Probably should be moved to the next release due to dependency on
> > > > > > Tensorflow. Need to check. (Andrey Gura)
> > > > >
> > > > >
> > > > > Can we decouple Tensorflow from the IGFS?
> > > > >
> > > > > Mark all the issues related to ML, Spark 2.4, Monitoring major
> > > > > > features and track their comletion to be sure on there is no
> > > > > > unfinished major changes will be present in 2.8 release.
> > > > > > - ML (Alexey Zinoviev)
> > > > >
> > > > >
> > > > > Are there any other ML contributors who will be helping you with
> this
> > > > > release?
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Tue, Oct 1, 2019 at 6:56 AM Maxim Muzafarov 
> > > > wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > >
> > > > > > Here is the list of activities we've agreed on to prepare the
> > Apache
> > > > > > Ignite 2.8 release.
> > > > > >
> > > > > > 1.
> > > > > > Preliminary release dates with the ability to shift them if some
> of
> > > > > > the planned activities will not be finalized. But anyway we
> should
> > > > > > build our engagement based on these dates.
> > > > > >
> > > > > > Scope Freeze: November 5, 2019
> > > > > > Code Freeze: December 2, 2019
> > > > > > Voting Date: January 10, 2020
> > > > > > Release Date: January 17, 2020
> > > > > >
> > > > > > 2.
> > > > > > Mark all the issues related to ML, Spark 2.4, Monitoring major
> > > > > > features and track their comletion to be sure on there is no
> > > > > > unfinished major changes will be present in 2.8 release.
> > > > > > - ML (Alexey Zinoviev)
> > > > > > - Spark [1] [4] (Alexey Zinoviev)
> > > > > > - Monitoring (Nikolay Izhikov)
> > > > > >
> > > > > > 3.
> > > > > > Review and mark all the partially completed major issues
> currently
> > > > > > present in the master branch.
> > > > > > - major IEPs e.g. IEP-18, non-blocking PME (Maxim Muzafarov)
> > > > > > - review major commits in the master branch (Maxim Muzafarov)
> > > > > >
> > > > > > 4.
> > > > > > Review blocker issues currently pinned to 2.8 release.
> > > > > > - IGNITE-11942 IGFS and Hadoop Accelerator Discontinuation [2].
> > > > > > Probably should be moved to the next release due to dependency on
> > > > > > Tensorflow. Need to check. (Andrey Gura)
> > > > > > - IGNITE-9489 CorruptedTreeException on index create [3]. Check
> all
> > > > > > the issues releated to this. Some of them already fixed by
> > GridGain.
> > > > > > Need to check. (Andrey Gura)
> > > > > > - IGNITE-12181 Rebalance hangs on BLT change. The cause has been
> > > > > > found. Will be fixed. (Maxim Muzafarov)
> > > > > > - Need to 

[DISCUSS] Pub/Sub Streamer Implementation

[Emmanouil Gkatziouras]

Hello everyone,

I started using Ignite lately. Part of my work involves Pub/Sub, thus I
created a pub/sub streamer.
Pub/Sub is pretty close to Kafka.
Here's how the streamer works. Every node creates an instance of a Pub/Sub
client.
The clients subscribe to the same topic using the same subscription name.
A message is being sent and one of the nodes will receive the message,
process it and then forward it to Ignite using the extractor provided.

Any thoughts?

*Emmanouil Gkatziouras*
https://egkatzioura.com/ | https://www.linkedin.com/in/gkatziourasemmanouil/
https://github.com/gkatzioura

Re: Custom REST processor configuration.

[Nikolay Izhikov]

Hello, Mikhail.

I will take a look, shortly.

В Чт, 10/10/2019 в 16:08 +0300, Mikhail Petrov пишет:
> Hello, Igniters.
> 
> My project demands extended logic of Apache Ignite REST processor. I'd 
> like to implement a specific one and use it with Apache Ignite, but now 
> it's impossible. I have created Ticket [1] and PR [2] to provide an 
> ability to configure custom REST processor implementation via Ignite 
> plugin functionality. Could anyone take a look at it, please?
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-12268
> [2] https://github.com/apache/ignite/pull/6948
> 
> 


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

Custom REST processor configuration.

[Mikhail Petrov]

Hello, Igniters.

My project demands extended logic of Apache Ignite REST processor. I'd 
like to implement a specific one and use it with Apache Ignite, but now 
it's impossible. I have created Ticket [1] and PR [2] to provide an 
ability to configure custom REST processor implementation via Ignite 
plugin functionality. Could anyone take a look at it, please?


[1] https://issues.apache.org/jira/browse/IGNITE-12268
[2] https://github.com/apache/ignite/pull/6948

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Pavel Kovalenko]

Issues link is broken, because it has a filter that can't be found.
Here is correct link:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened%2C%20%22In%20Progress%22%2C%20%22Patch%20Available%22)%20AND%20fixVersion%20%3D%202.8%20and%20component%20%3D%20Documentation%20order%20by%20status

чт, 10 окт. 2019 г. в 13:38, Maxim Muzafarov :

> Igniters,
>
>
> Who can advise what we can\should do with the issues related to
> `documentation` component to release Ignite 2.8 version?
> How can I sort them and prioritize?
> What are best-practices here?
>
> Currently, we have 81 issues pinned to 2.8 release [1].
>
> 6 - `In Progress`
> 2 - `Patch Available`
> 73 - `Open`
>
> Some of the issues are assigned to the `Prachi Garg` which is not
> active since February 15-th 2019.
>
> [1]
> https://issues.apache.org/jira/issues/?filter=12347303=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened%2C%20%22In%20Progress%22%2C%20%22Patch%20Available%22)%20AND%20fixVersion%20%3D%202.8%20and%20component%20%3D%20Documentation%20order%20by%20status
>
>
> On Thu, 3 Oct 2019 at 01:52, Denis Magda  wrote:
> >
> > Maxim,
> >
> > This sounds reasonable to me.
> >
> > -
> > Denis
> >
> >
> > On Wed, Oct 2, 2019 at 8:55 AM Maxim Muzafarov 
> wrote:
> >
> > > Folks,
> > >
> > > Since we are focusing on new SQL engine implementation I'd like to
> > > perform bulk moving of all MVCC related unassigned tickets [1] to the
> > > next release.
> > > Can you confirm?
> > >
> > > [1]
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20fixVersion%20%3D%202.8%20and%20priority%20in%20(Major)%20and%20summary%20~%20MVCC
> > >
> > > On Wed, 2 Oct 2019 at 01:27, Denis Magda  wrote:
> > > >
> > > > Alexey Z.,
> > > >
> > > > Could you please answer some of the questions
> > > >
> > > >
> > > > > - IGNITE-11942 IGFS and Hadoop Accelerator Discontinuation [2].
> > > > > Probably should be moved to the next release due to dependency on
> > > > > Tensorflow. Need to check. (Andrey Gura)
> > > >
> > > >
> > > > Can we decouple Tensorflow from the IGFS?
> > > >
> > > > Mark all the issues related to ML, Spark 2.4, Monitoring major
> > > > > features and track their comletion to be sure on there is no
> > > > > unfinished major changes will be present in 2.8 release.
> > > > > - ML (Alexey Zinoviev)
> > > >
> > > >
> > > > Are there any other ML contributors who will be helping you with this
> > > > release?
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Tue, Oct 1, 2019 at 6:56 AM Maxim Muzafarov 
> > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > >
> > > > > Here is the list of activities we've agreed on to prepare the
> Apache
> > > > > Ignite 2.8 release.
> > > > >
> > > > > 1.
> > > > > Preliminary release dates with the ability to shift them if some of
> > > > > the planned activities will not be finalized. But anyway we should
> > > > > build our engagement based on these dates.
> > > > >
> > > > > Scope Freeze: November 5, 2019
> > > > > Code Freeze: December 2, 2019
> > > > > Voting Date: January 10, 2020
> > > > > Release Date: January 17, 2020
> > > > >
> > > > > 2.
> > > > > Mark all the issues related to ML, Spark 2.4, Monitoring major
> > > > > features and track their comletion to be sure on there is no
> > > > > unfinished major changes will be present in 2.8 release.
> > > > > - ML (Alexey Zinoviev)
> > > > > - Spark [1] [4] (Alexey Zinoviev)
> > > > > - Monitoring (Nikolay Izhikov)
> > > > >
> > > > > 3.
> > > > > Review and mark all the partially completed major issues currently
> > > > > present in the master branch.
> > > > > - major IEPs e.g. IEP-18, non-blocking PME (Maxim Muzafarov)
> > > > > - review major commits in the master branch (Maxim Muzafarov)
> > > > >
> > > > > 4.
> > > > > Review blocker issues currently pinned to 2.8 release.
> > > > > - IGNITE-11942 IGFS and Hadoop Accelerator Discontinuation [2].
> > > > > Probably should be moved to the next release due to dependency on
> > > > > Tensorflow. Need to check. (Andrey Gura)
> > > > > - IGNITE-9489 CorruptedTreeException on index create [3]. Check all
> > > > > the issues releated to this. Some of them already fixed by
> GridGain.
> > > > > Need to check. (Andrey Gura)
> > > > > - IGNITE-12181 Rebalance hangs on BLT change. The cause has been
> > > > > found. Will be fixed. (Maxim Muzafarov)
> > > > > - Need to check all the other blocker issues (Maxim Muzafarov)
> > > > >
> > > > > 5.
> > > > > QA regression (2.7 -> 2.8). I'll provide additional details when
> I'll
> > > get
> > > > > them.
> > > > > Review and check test-cases, optioannly schedule meeting (Maxim
> > > Muzafarov)
> > > > >
> > > > > 6.
> > > > > (optional) Need to create an INFRA ticket to add `Epic` JIRA issue
> > > > > type to the Apache Ignite JIRA. The issue [6] has been created but
> not
> > > > > sure that I have the right permission to do 

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Igniters,


Who can advise what we can\should do with the issues related to
`documentation` component to release Ignite 2.8 version?
How can I sort them and prioritize?
What are best-practices here?

Currently, we have 81 issues pinned to 2.8 release [1].

6 - `In Progress`
2 - `Patch Available`
73 - `Open`

Some of the issues are assigned to the `Prachi Garg` which is not
active since February 15-th 2019.

[1] 
https://issues.apache.org/jira/issues/?filter=12347303=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened%2C%20%22In%20Progress%22%2C%20%22Patch%20Available%22)%20AND%20fixVersion%20%3D%202.8%20and%20component%20%3D%20Documentation%20order%20by%20status


On Thu, 3 Oct 2019 at 01:52, Denis Magda  wrote:
>
> Maxim,
>
> This sounds reasonable to me.
>
> -
> Denis
>
>
> On Wed, Oct 2, 2019 at 8:55 AM Maxim Muzafarov  wrote:
>
> > Folks,
> >
> > Since we are focusing on new SQL engine implementation I'd like to
> > perform bulk moving of all MVCC related unassigned tickets [1] to the
> > next release.
> > Can you confirm?
> >
> > [1]
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20fixVersion%20%3D%202.8%20and%20priority%20in%20(Major)%20and%20summary%20~%20MVCC
> >
> > On Wed, 2 Oct 2019 at 01:27, Denis Magda  wrote:
> > >
> > > Alexey Z.,
> > >
> > > Could you please answer some of the questions
> > >
> > >
> > > > - IGNITE-11942 IGFS and Hadoop Accelerator Discontinuation [2].
> > > > Probably should be moved to the next release due to dependency on
> > > > Tensorflow. Need to check. (Andrey Gura)
> > >
> > >
> > > Can we decouple Tensorflow from the IGFS?
> > >
> > > Mark all the issues related to ML, Spark 2.4, Monitoring major
> > > > features and track their comletion to be sure on there is no
> > > > unfinished major changes will be present in 2.8 release.
> > > > - ML (Alexey Zinoviev)
> > >
> > >
> > > Are there any other ML contributors who will be helping you with this
> > > release?
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Tue, Oct 1, 2019 at 6:56 AM Maxim Muzafarov 
> > wrote:
> > >
> > > > Igniters,
> > > >
> > > >
> > > > Here is the list of activities we've agreed on to prepare the Apache
> > > > Ignite 2.8 release.
> > > >
> > > > 1.
> > > > Preliminary release dates with the ability to shift them if some of
> > > > the planned activities will not be finalized. But anyway we should
> > > > build our engagement based on these dates.
> > > >
> > > > Scope Freeze: November 5, 2019
> > > > Code Freeze: December 2, 2019
> > > > Voting Date: January 10, 2020
> > > > Release Date: January 17, 2020
> > > >
> > > > 2.
> > > > Mark all the issues related to ML, Spark 2.4, Monitoring major
> > > > features and track their comletion to be sure on there is no
> > > > unfinished major changes will be present in 2.8 release.
> > > > - ML (Alexey Zinoviev)
> > > > - Spark [1] [4] (Alexey Zinoviev)
> > > > - Monitoring (Nikolay Izhikov)
> > > >
> > > > 3.
> > > > Review and mark all the partially completed major issues currently
> > > > present in the master branch.
> > > > - major IEPs e.g. IEP-18, non-blocking PME (Maxim Muzafarov)
> > > > - review major commits in the master branch (Maxim Muzafarov)
> > > >
> > > > 4.
> > > > Review blocker issues currently pinned to 2.8 release.
> > > > - IGNITE-11942 IGFS and Hadoop Accelerator Discontinuation [2].
> > > > Probably should be moved to the next release due to dependency on
> > > > Tensorflow. Need to check. (Andrey Gura)
> > > > - IGNITE-9489 CorruptedTreeException on index create [3]. Check all
> > > > the issues releated to this. Some of them already fixed by GridGain.
> > > > Need to check. (Andrey Gura)
> > > > - IGNITE-12181 Rebalance hangs on BLT change. The cause has been
> > > > found. Will be fixed. (Maxim Muzafarov)
> > > > - Need to check all the other blocker issues (Maxim Muzafarov)
> > > >
> > > > 5.
> > > > QA regression (2.7 -> 2.8). I'll provide additional details when I'll
> > get
> > > > them.
> > > > Review and check test-cases, optioannly schedule meeting (Maxim
> > Muzafarov)
> > > >
> > > > 6.
> > > > (optional) Need to create an INFRA ticket to add `Epic` JIRA issue
> > > > type to the Apache Ignite JIRA. The issue [6] has been created but not
> > > > sure that I have the right permission to do so.
> > > >
> > > > [1]
> > > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/The-Spark-2-4-support-td43777.html
> > > > [2] https://issues.apache.org/jira/browse/IGNITE-11942
> > > > [3] https://issues.apache.org/jira/browse/IGNITE-9489
> > > > [4] https://issues.apache.org/jira/browse/IGNITE-12054
> > > > [5] https://issues.apache.org/jira/browse/IGNITE-12181
> > > > [6] https://issues.apache.org/jira/browse/INFRA-19164
> > > >
> > > > On Mon, 30 Sep 2019 at 12:14, Ivan Pavlukhin 
> > wrote:
> > > > >
> > > > > Maxim, Folks,
> > > > >
> > > > > Could you please share a results of the Slack discussion from Sep 25?
> > > > >
> > > 

[jira] [Created] (IGNITE-12277) Index usage is not applicable for mixed IN and EQUALS queries.

[Stanilovsky Evgeny (Jira)]

Stanilovsky Evgeny created IGNITE-12277:
---

 Summary: Index usage is not applicable for mixed IN and EQUALS 
queries.
 Key: IGNITE-12277
 URL: https://issues.apache.org/jira/browse/IGNITE-12277
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.7.6
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
 Fix For: 2.8


create table test(pk int, a int, b int);
create index idx on test(a);
select * from test where a in(r1 ...r2) <- index usage passed here, explain 
show correctness.
select * from test where a in(r1 ...r2) and b = r3 <- index usage failed here, 
but there is no rejection for using it.



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