[jira] [Created] (IGNITE-6219) IgniteCache#loadCache executes local load in caller thread

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-6219:
---

 Summary: IgniteCache#loadCache executes local load in caller thread
 Key: IGNITE-6219
 URL: https://issues.apache.org/jira/browse/IGNITE-6219
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.1
Reporter: Valentin Kulichenko
Priority: Critical
 Fix For: 2.2


{{IgniteCache#loadCache}} method broadcasts an internal task under the hood. If 
one of the jobs are local (i.e. if {{loadCache}} is invoked on server node), 
this job is executed in a caller thread, potentially *before all or some remote 
requests are sent*. Since data loading is generally long running process, its 
duration doubles in this scenario.

Possible solution is to check the list of nodes before task execution, and if 
local node is there, execute on remote nodes first, and only then submit to 
local node. This way we make sure that remote nodes never wait for the local 
node.



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

Re: Adding sqlline tool to Apache Ignite project

[Denis Magda]

Igniters,

Let me introduce Julian Hyde [1], creator of SQLLine tool and our Apache mate,

Julian,

Please grant that Apache Ignite community a permission to include SQLLine [2] 
it in every Ignite deliverable (source, binary). It’s planned to suggest the 
tool as a default command line SQL utility for Ignite clusters. SQLLite and 
Ignite usage will also be documented on Ignite’s technical documentation.

[1] https://people.apache.org/~jhyde/
[2] https://github.com/julianhyde/sqlline 


—
Denis

> On Aug 25, 2017, at 9:17 AM, Denis Magda  wrote:
> 
> Hi Ilya,
> 
> Thanks for the clarification! Referring to the page shared by you [1] if we 
> need to get author’s consent in a written form:
> 
> A permissive license similar to the BSD 2-Clause License, but with a 3rd 
> clause that prohibits others from using the name of the project or its 
> contributors to promote derived products without written consent.
> 
> [1] https://github.com/julianhyde/sqlline/blob/master/LICENSE 
> 
> 
> I’ll reach out the author requesting the permit.
> 
> —
> Denis
> 
>> On Aug 25, 2017, at 9:12 AM, Ilya Kasnacheev  
>> wrote:
>> 
>> Hi Denis,
>> 
>> There are two kinds of BSD license, 3-clause and 4-clause. The difference
>> between them is advertising clause:
>> 
>> "3. All advertising materials mentioning features or use of this software
>> must display the following acknowledgement: This product includes software
>> developed by the University of California, Berkeley and its contributors."
>> 
>> which is causing problems with other licenses and which sqlline's license
>> doesn't contain:
>> https://github.com/julianhyde/sqlline/blob/master/LICENSE
>> So it should be all good for inclusion.
>> 
>> -- 
>> Ilya Kasnacheev.
>> 
>> 2017-08-25 18:48 GMT+03:00 Denis Magda :
>> 
>>> Hi Ilya,
>>> 
>>> It will be a useful addition to Ignite. I would include the tool in one of
>>> the nearest releases. It’s license is BSD-3 which is compatible with ours.
>>> However, there is a note on ASF side saying that BSD licenses can be
>>> included without advertising clause [1]. What does it mean for us? Can we
>>> document the tool and mention on our site?
>>> 
>>> [1] https://www.apache.org/legal/resolved.html#category-a <
>>> https://www.apache.org/legal/resolved.html#category-a>
>>> 
>>> —
>>> Denis
>>> 
 On Aug 25, 2017, at 8:32 AM, Ilya Suntsov  wrote:
 
 Hi Igniters,
 
 I've found one command line tool that can be used for execute queries
 (DDL/DML) with data from Apache Ignite grid via
 *org.apache.ignite.IgniteJdbcThinDriver*.
 
 Here you can find overview of internal commands of this tool:
 https://cwiki.apache.org/confluence/display/IGNITE/Overview+sqlline+tool
 
 The most problems with sqlline relate with some issues from our side or
 some unsupported features.
 
 Would be nice to add tool like this (sqlline or something else) in our
 project.
 
 Have you any objections or other thoughts?
 
 
 --
 Ilya Suntsov
>>> 
>>> 
> 

Re: CREATE TABLE usage from Java API, .NET, C++

[Valentin Kulichenko]

Ideally, SQL API has to be completely decoupled from cache API. Otherwise
we will keep getting issues like this.

let's introduce top level API (IgniteSql?) and add everything there.

-Val

On Tue, Aug 29, 2017 at 7:47 PM Denis Magda  wrote:

> Igniters,
>
> Not sure we discussed this before, so let me start a new thread.
>
> It’s claimed the command is supported from native Java, .NET, C++ APIs but
> I had hard time trying to use it from there. Imagine this simple statement
> to be called from Java source code:
>
> SqlFieldsQuery query = new SqlFieldsQuery(
> "CREATE TABLE City (" +
> " id LONG PRIMARY KEY, name VARCHAR)" +
> " WITH \"template=replicated\"");
>
> *cache*.query(query).getAll();
>
> The CT command will be recognized but the *cache* is not the City cache.
> It’s some other cache existed prior the query execution.
>
> In my scenario I’ve planned to show how to configure the schema from
> scratch on an empty cluster and had to apply the following workaround
> instantiating a dummy cache:
>
> IgniteCache cache = ignite.getOrCreateCache(new
> CacheConfiguration<>("default").setIndexedTypes(Long.class,
> Long.class).setSqlSchema("PUBLIC"));
>
>
> How do we want to improve this poor experience? My options are:
>
> 1) Introduce some static API (cache-reference-free) method for quiries
> like that.
> 2) Deploy the cache prior that call and pass its name into “WITH”
> statement.
>
> —
> Denis

Override cache name created with CREATE TABLE

[Denis Magda]

Igniters,

That’s one more feedback about CREATE TABLE usage in practice.

The command automatically creates an IgniteCache naming it SQL_PUBLIC_{TABLE}. 
So, if a Person table is created you’ll have SQL_PUBLIC_PERSON cache in the 
cluster.

Honestly, if you keep to SQL APIs the cache name won’t bother you but as soon 
as key-value, compute, service grid APIs are needed the cache name will be used 
here and there looking bizarre.

Let me propose the following usability improvements until our user does this:

- *At least*
Give a way to pass the cache name into WITH clause parameters set

- *Ideally*
Support the above and if the cache already exists use it instead of creating a 
new one. This might help to resolve another issue brought up here: 
http://apache-ignite-developers.2346864.n4.nabble.com/CREATE-TABLE-usage-from-Java-API-NET-C-td21455.html

What do you think? If everyone is ok, I’ll file a JIRA ticket.

—
Denis

CREATE TABLE usage from Java API, .NET, C++

[Denis Magda]

Igniters,

Not sure we discussed this before, so let me start a new thread.

It’s claimed the command is supported from native Java, .NET, C++ APIs but I 
had hard time trying to use it from there. Imagine this simple statement to be 
called from Java source code:  

SqlFieldsQuery query = new SqlFieldsQuery(
"CREATE TABLE City (" +
" id LONG PRIMARY KEY, name VARCHAR)" +
" WITH \"template=replicated\"");

*cache*.query(query).getAll();

The CT command will be recognized but the *cache* is not the City cache. It’s 
some other cache existed prior the query execution.

In my scenario I’ve planned to show how to configure the schema from scratch on 
an empty cluster and had to apply the following workaround instantiating a 
dummy cache:

IgniteCache cache = ignite.getOrCreateCache(new 
CacheConfiguration<>("default").setIndexedTypes(Long.class,
Long.class).setSqlSchema("PUBLIC"));


How do we want to improve this poor experience? My options are:

1) Introduce some static API (cache-reference-free) method for quiries like 
that.
2) Deploy the cache prior that call and pass its name into “WITH” statement.

—
Denis

New PMC: Pavel Tupitsyn

[Denis Magda]

The Project Management Committee (PMC) for Apache Ignite has invited Pavel 
Tupitsyn to become a PMC member and we are pleased to announce that he has 
accepted the role. 

Being a PMC member enables assistance with the management and to guide the 
direction of the project.

Pavel, is a veteran of our community who drives and maintains Ignite.NET 
development:
https://apacheignite-net.readme.io/docs/

He worked on and closed more than 230 features and bugs:
https://issues.apache.org/jira/browse/IGNITE-5864?jql=project%20%3D%20IGNITE%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20assignee%20in%20(ptupitsyn)

Besides of his architectural and engineering contribution to the project he is 
an active member on both @user and @dev who helps to adopt Ignite and influence 
on its future.
- Dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes=191
- User list: 
http://apache-ignite-users.70518.x6.nabble.com/template/NamlServlet.jtp?macro=user_nodes=546

Moreover, he is one of few Ignite committers who blogs about Ignite constantly: 
https://ptupitsyn.github.io


Congratulations!
Denis

[GitHub] ignite pull request #2545: For testing

[ilantukh]

GitHub user ilantukh opened a pull request:

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

For testing



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

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

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

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


commit 1e08c3fb5c02ec8acafd71b50b6ad3b749259f1a
Author: Andrey V. Mashenkov 
Date:   2017-07-31T11:14:56Z

IGNITE-4800: Lucene query may fails with NPE. This closes #2315.

commit 3fdf453e89a7bd76dff6b6d0646e3821ea3921d5
Author: Andrey V. Mashenkov 
Date:   2017-07-31T14:32:12Z

IGNITE-4800: Lucene query may fails with NPE.
Test fixed.

commit e255a564985a12113984ec02f15a4443495b8ffc
Author: Nikolay Izhikov 
Date:   2017-08-02T08:52:44Z

ignite-5712 Context switching for optimistic transactions

commit 772d462b68c7de8517d1f61e2e05ec8eefb18eac
Author: Alexey Kuznetsov 
Date:   2017-08-03T04:55:15Z

Merge branch ignite-2.1.3 into ignite-2.1.4

commit 0f3b7ca25313083e4dc35e7842931a655abd
Author: tledkov-gridgain 
Date:   2017-08-04T08:46:14Z

IGNITE-5126: Batch support for this JDBC driver. This closes #2162.

commit d1a74a4be8744528e6ed23706174041ddb0f2618
Author: devozerov 
Date:   2017-08-04T09:04:38Z

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

commit 0b3a9a7176f5ae44a96ecf700c8147193dfbf064
Author: Igor Sapego 
Date:   2017-08-04T10:18:00Z

IGNITE-5923: ODBC: SQLGetTypeInfo now works with SQL_ALL_TYPES

(cherry picked from commit 48c914d)

commit 4e0385fbc0f50548f2da3407fdfdfe939b463c67
Author: Igor Sapego 
Date:   2017-08-04T15:34:27Z

IGNITE-5939: ODBC: SQLColAttributes now works with legacy attribute codes.

(cherry picked from commit 70ffa2c)

commit 4f02504475fd1e5cc3b9f4754856e44d20fdc1cb
Author: Alexey Kuznetsov 
Date:   2017-08-07T02:41:22Z

Merge branch ignite-2.1.3 into ignite-2.1.4.

commit b093afb8231135a4904f5fffd62f5b4c332f1d47
Author: tledkov-gridgain 
Date:   2017-08-08T09:05:36Z

IGNITE-5211: Added new constructor: QueryEntity(Class keyCls, Class 
valCls). This closes #2371. This closes #2388. This closes #2407.

commit 879f19106b22e66d5f6ea94424d961d049397410
Author: devozerov 
Date:   2017-08-08T12:16:58Z

IGNITE-5982: GridMapQueryExecutor was split into several pieces.

commit 7c77b869bc3efdf19e53cc2b064f4290fd73e2b2
Author: devozerov 
Date:   2017-08-09T08:47:58Z

IGNITE-5993: Removed unused SQL-related classes and methods (old tree 
index, snapshots, etc). This closes #2414.

commit ab18fdfcc4f6db1e54fb1f3b68ba7fbc31a7f6e7
Author: Andrey V. Mashenkov 
Date:   2017-07-14T17:14:47Z

IGNITE-5452: GridTimeoutProcessor can hang on stop. This closes #2279.

commit 580b6aa8e5a8a887397eab5c4c830ec28f45cd30
Author: Alexey Kuznetsov 
Date:   2017-08-09T10:22:54Z

IGNITE-5734 Web Console: Fixed npm dependencies.
(cherry picked from commit aeafbf1)

commit 841db65e56063605475710bc170de4aea672c31d
Author: Alexey Kuznetsov 
Date:   2017-08-09T11:55:04Z

IGNITE-5987 Added -nq (visor will not quit in batch mode) option for Visor 
Cmd.
(cherry picked from commit 8d6e842)

commit 5c2097856714a7803956d754735c68b21156019c
Author: Alexey Kuznetsov 
Date:   2017-08-11T03:25:36Z

IGNITE-5902 Implemented stop caches at once.
(cherry picked from commit ebb8765)

commit 8b2461942c18f228c0107020aa28c03711bdceda
Author: Alexey Kuznetsov 
Date:   2017-08-11T04:07:26Z

IGNITE-6012 Refactored GridJettyRestHandler.processRequest(): replace 
mapper.writeValueAsString with writeValue(stream, v).
(cherry picked from commit 3a390c8)

commit 3a7d4f4a79e7c0a23244387e3a68535375a66a87
Author: Alexey Kuznetsov 
Date:   2017-08-11T04:18:42Z

IGNITE-6013 Optimized processing response from cluster.
(cherry picked from commit b02c481)

commit 74d6ab9916b3a01c78cdf1ad86211c9fcbb2214d
Author: Alexey Goncharuk 
Date:   2017-08-14T08:08:28Z

Merge branch 'ignite-2.1.3' into ignite-2.1.4

commit fde550bac56fd0cc7c51c62a9c291dd4c3f3030c
Author: Ilya Lantukh 
Date:   2017-08-14T08:32:11Z

IGNITE-5941 - Fixed index name length restrictions. This closes #2408

commit 13f38d79b57b395e43d42a8f3c278cf48336d7c5
Author: Dmitriy Govorukhin 
Date:   

[jira] [Created] (IGNITE-6218) Document logging capabilities of Ignite

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6218:
---

 Summary: Document logging capabilities of Ignite
 Key: IGNITE-6218
 URL: https://issues.apache.org/jira/browse/IGNITE-6218
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Magda
Assignee: Prachi Garg
Priority: Critical
 Fix For: 2.3


Ignite supports a variety of logging libraries and frameworks but the 
capability is not documented on readme.io and even if you come across Ignite's 
logging modules it won't be obvious for you how to use them.

These are the loggers supported out-of-the box:

ignite-log4j
ignite-log4j2
ignite-jcl
ignite-slf4j

ignite-log4j2 explains how to enable this module in its README file. The rest 
of the modules miss even this basic info.

Document how to configure and use every logging framework with Ignite. Show an 
output produced by a specific logger. In addition, mention what's the default 
logger and how to integrate with a new one.



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

[GitHub] ignite pull request #2544: Tx recovery fix

[agura]

GitHub user agura opened a pull request:

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

Tx recovery fix



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

$ git pull https://github.com/agura/incubator-ignite tx-recovery-fix

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

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


commit 348593986b56ddfcec4a4455e49d9b279eae4dc8
Author: devozerov 
Date:   2016-11-05T10:28:03Z

Merge branch 'ignite-1.7.3' into ignite-1.7.4

commit 175da6b7e394dd76c27d5155ff98a5b2ef03bb9d
Author: tledkov-gridgain 
Date:   2016-11-07T06:16:58Z

IGNITE-3432:  check data/meta cache names are different for different IGFS 
instances. This closes #1201

commit ead15193899d08f41491166003cabed0560f0c59
Author: Pavel Tupitsyn 
Date:   2016-11-07T07:49:03Z

IGNITE-4028 Get rid of OP_META in PlatformAbstractTarget

This closes #1192

commit 40ef2f5ae42826fe8fd077e3013e8f55c8512bdd
Author: Dmitriy Govorukhin 
Date:   2016-11-07T09:09:41Z

ignite-4178 support permission builder

commit df670c7d64046d282c053f296c47a4743c58c8b1
Author: Pavel Tupitsyn 
Date:   2016-11-07T09:40:00Z

IGNITE-4118 .NET: Optimistic transaction example

This closes #1200

commit 474f22fda4c7cf4d7b2623c451cd7c10f0d8c636
Author: Pavel Tupitsyn 
Date:   2016-11-07T09:55:20Z

IGNITE-4119 .NET: add TransactionDeadlockException

commit fc7ce5a4d72145f2e8a86debeda264ef0a5b37e3
Author: isapego 
Date:   2016-11-07T10:26:05Z

IGNITE-4090: Added flags so stdint and limits can be used in C++.

commit a98804a249496ba9bafbc96daa7aaf25b3d36724
Author: Igor Sapego 
Date:   2016-11-07T11:00:00Z

IGNITE-4113: Added tests. Added Statement::Set/GetAttribute.

commit b1c7c9bb95c900083702d0ba0362edf3aea5a7b4
Author: sboikov 
Date:   2016-11-07T12:40:36Z

GG-11360 - Implement SQL queries cancellation
Fix for commit 80abd1b: for distributed joins need always send cancel 
request.

commit 319014de075c80fb15e58172cc24e35ce16b56cf
Author: Pavel Tupitsyn 
Date:   2016-11-07T14:53:40Z

IGNITE-4132 .NET: Improve BinaryConfiguration documentation

commit 950bad474ef29f9b808e74034c49a69d57eb2740
Author: dkarachentsev 
Date:   2016-11-08T11:03:34Z

GG-11655 - Restore service compatibility with releases before 1.5.30.

commit 3d19bfc2b66574e3945ce17c7a4dfe77d0070b8d
Author: dkarachentsev 
Date:   2016-11-08T11:04:36Z

Merge remote-tracking branch 'origin/ignite-1.6.11' into ignite-1.6.11

commit 1612b6d66fed032182a41e90da71e6b986ae087b
Author: Pavel Tupitsyn 
Date:   2016-11-08T11:07:54Z

.NET: Fix minor analysis warnings

commit e821dc0083003bc81058b1cb223d8a8a2ee44daf
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:09:21Z

IGNITE-2079 (revert commit) GridCacheIoManager eats exception trail if it 
falls into the directed case

commit c2c82ca44befe4570325dd6cf2ba885e0d90596c
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:10:10Z

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

commit 865bbcf0f41a0c4944e0928f1758d43a0eae82c5
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:18:29Z

Revert "Merge remote-tracking branch 'professional/ignite-1.6.11' into 
ignite-1.6.11"

This reverts commit c2c82ca44befe4570325dd6cf2ba885e0d90596c, reversing
changes made to e821dc0083003bc81058b1cb223d8a8a2ee44daf.

commit 9726421ff9efb2b19813b2fd6ad27a3728b5ab1a
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:59:00Z

  Revert  Revert  Merge remote-tracking branch 'professional/ignite-1.6.11'

commit 5a3a1960fff1dcf32961c45c0ba5149d6748d2fc
Author: Igor Sapego 
Date:   2016-11-08T14:36:35Z

Added license header.

commit f697fb5786fb4ce15f581c465ff0dcb3d2bb7b14
Author: Pavel Tupitsyn 
Date:   2016-11-08T16:13:48Z

IGNITE-4185 .NET: Fix NullReferenceException in IgniteOutputCacheProvider 
when igniteConfiguration is missing

commit 69487f2c375010737311af65750a519b403fc17f
Author: Pavel Tupitsyn 
Date:   2016-11-08T16:38:28Z

.NET: Fix error messages when IgniteConfigurationSection content is missing

commit d88f422aeb02738d676d86ce416551b805ad154e
Author: Andrey Novikov 
Date:   2016-11-09T07:25:38Z

GG-11028 Fixed resolving of host name.

commit ac660dcaa5bf8eb20e7dd4e442e97c1cf548a827
Author: Igor Sapego 
Date: 

[GitHub] ignite pull request #2543: IGNITE-6119: Added 'lazy' flag to ODBC

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-6119: Added 'lazy' flag to ODBC



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

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

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

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


commit 5aa2c7bc0d2da5596f54b554489b53d9fadd5f63
Author: Igor Sapego 
Date:   2017-08-29T13:56:43Z

IGNITE-6119: Java-side changes

commit adeae622789e00240966c3b16c76f013294d6795
Author: Igor Sapego 
Date:   2017-08-29T16:06:43Z

IGNITE-6119: Added 'lazy' flag to configuration

commit e1a38ac39c5c53d9b213a21f14d34b80fe09ea13
Author: Igor Sapego 
Date:   2017-08-29T16:39:10Z

IGNITE-6119: Added 'lazy' flag to DSN

commit ad7a68bfd5f199035128df79815f9765c2aa4f14
Author: Igor Sapego 
Date:   2017-08-29T17:09:45Z

IGNITE-6119: Fixed issues.




---
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 #2533: IGNITE-6122: Propagate SqlFieldsQuery.lazy proper...

[isapego]

Github user isapego closed the pull request at:

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


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

Re: Troubles with BigDecimal and BigInteger - maybe disable entirely?

[Ilya Kasnacheev]

Hello Andrey.

I'm not sure that BigDecimal makes for a passable SQL DECIMAL. Somebody
have to look at the standard sooner or later.

BigDecimal works as values as well, and BigInteger don't work, too.

I've created this remedy pull request and now am waiting for tests:
https://github.com/apache/ignite/pull/2512/commits/177be6475e7aee6fc0f04a010406bd57fb1da2ce
Also fixes BigIntever values.

The problem that in H2, there's special handling for BigInteger in DataType
class (which is used in statements) but not in Value class (which is used
in querying).

-- 
Ilya Kasnacheev

2017-08-29 19:07 GMT+03:00 Andrey Mashenkov :

> Ilya,
>
> Ignite doesn't support scale\precision constrains for Decimal type,
> so H2 treat them as Decimals with highest precision.
>
> It is different issue as BigDecimal keys works, but with limitation.
> However, BigInteger keys looks like doesn't work at all.
>
> Disable having BigDecimal & BigInteger doesn't look like a solution for me.
>
> What about using BigDecimal and BigInteger as values? Will SQL queries with
> condition on these values work?
>
>
>
> On Tue, Aug 29, 2017 at 6:45 PM, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> wrote:
>
> > Hello fellow Igniters,
> >
> > We have troubles with BigDecimal and BigInteger types used as cache keys
> > and then referenced in SQL.
> >
> > As far as I see, our implementation of SQL considers BigDecimal to be
> SQL's
> > DECIMAL type.
> > But semantics of BigDecimal are different. BigDecimal("4.2") not equals
> to
> > BigDecimal("4.20"), but people assume they can find a row with 4.20
> DECIMAL
> > key by searching for 4.2. Which doesn't work.
> >
> > On the side note, does anybody have seen what SQL standard has to say on
> > the issue? How should DECIMAL type work? I expect we've got to have our
> own
> > DECIMAL type implementation completely divorced from BigDecimal, but I
> have
> > no idea about migration path.
> >
> > BigInteger suffers from the opposite problem. Ignite doesn't treat it as
> > DECIMAL and just stores it as Object. But H2 indexing considers it a
> number
> > type and converts it to a ValueNumber when it gets passed as a parameter,
> > with subsequent comparisons on it failing, as outlined in
> > https://issues.apache.org/jira/browse/IGNITE-5855
> >
> > We could change our code to treat BigInteger in keys the same way
> > BigDecimals are treated, but this would most likely introduce an
> > incompatibility.
> >
> > Maybe we should disable having BigDecimal & BigInteger as cache keys at
> > all? Check for any of those in CacheConfiguration.setIndexedTypes()
> > perhaps
> > and throw and exception urging user to change those to String. This will
> > save people some fruitless effort and leave a door to introducing more
> > sophisticated number type for cache keys later on.
> >
> > WDYT?
> >
> >
> > --
> > Ilya Kasnacheev
> >
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: sql documentation

[Denis Magda]

Serge,

The attachment is missing. Try to share it via google drive or other storage.

—
Denis

> On Aug 29, 2017, at 2:38 AM, Serge Puchnin  wrote:
> 
> Hi !
> 
> As I can see, there is some room for documentation improvement.
> As a sample of documentation, I've prepared a description of "CREATE INDEX" 
> statement.
> 
> What’s your opinion?
> What can be improved?
> What should be added?
> 
> Thanks a lot!
> 
> ---
> Serge

Re: Ignite 2.1.0 - Thread deadlock on DefaultSingletonBeanRegistry.getSingleton

[Denis Magda]

Igor,

Could you share a test to reproduce the issue?

—
Denis


> On Aug 29, 2017, at 3:59 AM, igor.tanackovic  
> wrote:
> 
> Upgraded Ignite from 2.0.0 to 2.1.0 and ran into a thread deadlock on Ignite
> startup. I noticed the deadlock once I added CacheStore into a cache
> configuration which has Spring Data repository injected using
> @SpringResource. Ignite hangs during startup with one of executor threads
> blocked.
> 
> java.lang.Thread.State: BLOCKED (on object monitor)
>   at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:188)
>   - waiting to lock <0x000790d4e9b8> (a
> java.util.concurrent.ConcurrentHashMap)
>   at
> org.springframework.beans.factory.support.AbstractBeanFactory.isTypeMatch(AbstractBeanFactory.java:486)
>   at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.doGetBeanNamesForType(DefaultListableBeanFactory.java:432)
>   at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:403)
>   at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:389)
>   at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveNamedBean(DefaultListableBeanFactory.java:1002)
>   at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:345)
>   at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:340)
>   at
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1090)
>   at
> org.apache.ignite.internal.processors.resource.GridResourceSpringBeanInjector.getBeanByResourceAnnotation(GridResourceSpringBeanInjector.java:122)
>   at
> org.apache.ignite.internal.processors.resource.GridResourceSpringBeanInjector.inject(GridResourceSpringBeanInjector.java:64)
>   at
> org.apache.ignite.internal.processors.resource.GridResourceIoc$ClassDescriptor.injectInternal(GridResourceIoc.java:440)
>   at
> org.apache.ignite.internal.processors.resource.GridResourceIoc$ClassDescriptor.inject(GridResourceIoc.java:470)
>   at
> org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:278)
>   at
> org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:248)
>   at
> org.apache.ignite.internal.processors.resource.GridResourceProcessor.injectGeneric(GridResourceProcessor.java:229)
>   at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepare(GridCacheProcessor.java:609)
>   at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepare(GridCacheProcessor.java:598)
>   at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1416)
>   at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1867)
>   at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755)
>   at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619)
>   at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901)
>   at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> 
>   Locked ownable synchronizers:
>   - None
> 
> 
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-1-0-Thread-deadlock-on-DefaultSingletonBeanRegistry-getSingleton-tp16481.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

[GitHub] ignite pull request #2542: IGNITE-5905 .NET: Thin client: cache.Get for prim...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-5905 .NET: Thin client: cache.Get for primitives



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

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

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

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


commit 3e5119568e3a69496d1c54093be849b87a6e131f
Author: Pavel Tupitsyn 
Date:   2017-08-29T16:21:04Z

IGNITE-5905 .NET: Thin client: cache.Get for primitives




---
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-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-6217:


 Summary: Add benchmark to compare JDBC drivers and native SQL 
execution
 Key: IGNITE-6217
 URL: https://issues.apache.org/jira/browse/IGNITE-6217
 Project: Ignite
  Issue Type: Task
  Components: jdbc, sql, yardstick
Affects Versions: 2.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.2


We have to compare performance of the native SQL execution (via Ignite SQL 
API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC thin 
client.



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

Re: Troubles with BigDecimal and BigInteger - maybe disable entirely?

[Andrey Mashenkov]

Ilya,

Ignite doesn't support scale\precision constrains for Decimal type,
so H2 treat them as Decimals with highest precision.

It is different issue as BigDecimal keys works, but with limitation.
However, BigInteger keys looks like doesn't work at all.

Disable having BigDecimal & BigInteger doesn't look like a solution for me.

What about using BigDecimal and BigInteger as values? Will SQL queries with
condition on these values work?



On Tue, Aug 29, 2017 at 6:45 PM, Ilya Kasnacheev 
wrote:

> Hello fellow Igniters,
>
> We have troubles with BigDecimal and BigInteger types used as cache keys
> and then referenced in SQL.
>
> As far as I see, our implementation of SQL considers BigDecimal to be SQL's
> DECIMAL type.
> But semantics of BigDecimal are different. BigDecimal("4.2") not equals to
> BigDecimal("4.20"), but people assume they can find a row with 4.20 DECIMAL
> key by searching for 4.2. Which doesn't work.
>
> On the side note, does anybody have seen what SQL standard has to say on
> the issue? How should DECIMAL type work? I expect we've got to have our own
> DECIMAL type implementation completely divorced from BigDecimal, but I have
> no idea about migration path.
>
> BigInteger suffers from the opposite problem. Ignite doesn't treat it as
> DECIMAL and just stores it as Object. But H2 indexing considers it a number
> type and converts it to a ValueNumber when it gets passed as a parameter,
> with subsequent comparisons on it failing, as outlined in
> https://issues.apache.org/jira/browse/IGNITE-5855
>
> We could change our code to treat BigInteger in keys the same way
> BigDecimals are treated, but this would most likely introduce an
> incompatibility.
>
> Maybe we should disable having BigDecimal & BigInteger as cache keys at
> all? Check for any of those in CacheConfiguration.setIndexedTypes()
> perhaps
> and throw and exception urging user to change those to String. This will
> save people some fruitless effort and leave a door to introducing more
> sophisticated number type for cache keys later on.
>
> WDYT?
>
>
> --
> Ilya Kasnacheev
>



-- 
Best regards,
Andrey V. Mashenkov

[GitHub] ignite pull request #2541: IGNITE-5620

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5620



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

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

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

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


commit 5c0874281e1daecf72dbe7f3eb62221515e5d566
Author: Alexander Paschenko 
Date:   2017-08-28T17:18:29Z

IGNITE-5620 Began sorting out errors.

commit 71c3bb261ad9c80948fc797865dfe3583cee372e
Author: Alexander Paschenko 
Date:   2017-08-29T15:57:34Z

IGNITE-5620 contd




---
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.
---

Troubles with BigDecimal and BigInteger - maybe disable entirely?

[Ilya Kasnacheev]

Hello fellow Igniters,

We have troubles with BigDecimal and BigInteger types used as cache keys
and then referenced in SQL.

As far as I see, our implementation of SQL considers BigDecimal to be SQL's
DECIMAL type.
But semantics of BigDecimal are different. BigDecimal("4.2") not equals to
BigDecimal("4.20"), but people assume they can find a row with 4.20 DECIMAL
key by searching for 4.2. Which doesn't work.

On the side note, does anybody have seen what SQL standard has to say on
the issue? How should DECIMAL type work? I expect we've got to have our own
DECIMAL type implementation completely divorced from BigDecimal, but I have
no idea about migration path.

BigInteger suffers from the opposite problem. Ignite doesn't treat it as
DECIMAL and just stores it as Object. But H2 indexing considers it a number
type and converts it to a ValueNumber when it gets passed as a parameter,
with subsequent comparisons on it failing, as outlined in
https://issues.apache.org/jira/browse/IGNITE-5855

We could change our code to treat BigInteger in keys the same way
BigDecimals are treated, but this would most likely introduce an
incompatibility.

Maybe we should disable having BigDecimal & BigInteger as cache keys at
all? Check for any of those in CacheConfiguration.setIndexedTypes() perhaps
and throw and exception urging user to change those to String. This will
save people some fruitless effort and leave a door to introducing more
sophisticated number type for cache keys later on.

WDYT?


-- 
Ilya Kasnacheev

[GitHub] ignite pull request #2511: IGNITE-6178 Make CheckpointWriteOrder.SEQUENTIAL ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-6216) Add CheckpointWriteOrder enum in .NET persistent store configuration

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-6216:
--

 Summary: Add CheckpointWriteOrder enum in .NET persistent store 
configuration
 Key: IGNITE-6216
 URL: https://issues.apache.org/jira/browse/IGNITE-6216
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ivan Rakov
Assignee: Pavel Tupitsyn
 Fix For: 2.3


Since 2.2 we have CheckpointWriteOrder property in 
PersistentStoreConfiguration. It should be possible to set through .NET 
configuration classes.
Default value should be CheckpointWriteOrder#SEQUENTIAL.



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

[GitHub] ignite pull request #2540: Ignite 2.1.3.b5

[ntikhonov]

GitHub user ntikhonov opened a pull request:

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

Ignite 2.1.3.b5



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

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

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

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


commit 84c7427a53a8e1712b1d0b763d7539c9cb844cb6
Author: Sergey Stronchinskiy 
Date:   2017-07-04T11:51:25Z

IGNITE-5532 .NET: Split CacheLinqTest into partial classes

This closes #2226

commit 64c156e9252395504af00f09d934f36b6bc21913
Author: Igor Sapego 
Date:   2017-07-04T16:42:33Z

IGNITE-5663: ODBC: Closing cursor do not reset prepared statement anymore

commit 80c95ff79f344daf1fca3f094733a24bac2a218d
Author: Igor Sapego 
Date:   2017-07-05T15:41:28Z

IGNITE-5576: Added Compute::Run() for C++

commit 836906c89dfb880ac602046c37b3a2dba3ebdc46
Author: samaitra 
Date:   2017-07-06T04:28:15Z

IGNITE-5695 FlinkIgniteSinkSelfTest is failing due to conflicting default 
test timeout and default flush frequency - Fixes #2241.

Signed-off-by: samaitra 

commit 651ffc544bbc32cded55626adcd3ed4cc74f11ce
Author: shroman 
Date:   2017-07-06T05:00:08Z

Removed unnecessary line from the comments.

commit d1d6802378d874b039f775fe787f78c507661bb2
Author: devozerov 
Date:   2017-07-07T09:36:13Z

Merge branch 'ignite-2.1'

commit 45cd87fe73db117f5148ed2006f8de8d2517bbfe
Author: mcherkasov 
Date:   2017-06-30T17:23:55Z

IGNITE-5554 ServiceProcessor may process failed reassignments in timeout 
thread

commit fa974286e8f066a8d6aa57519edf5ec7761be095
Author: Igor Sapego 
Date:   2017-07-07T13:49:15Z

IGNITE-5582: Implemented Compute::Broadcast for C++

commit 01f504ff83cc77f80d37981b5c5a15b653861bbd
Author: NSAmelchev 
Date:   2017-07-10T12:03:01Z

IGNITE-5087 Enum comparison fails after marshal-unmarshal with 
BinaryMarshaller.

commit ecfbc2c97464ad7da3f24afaaf1868a2d2fdb87e
Author: devozerov 
Date:   2017-07-11T09:17:41Z

Merge branch 'ignite-2.1'

# Conflicts:
#   
modules/platforms/dotnet/Apache.Ignite.Core.Tests/Apache.Ignite.Core.Tests.csproj

commit 1be9b40c37efcbf332ebeeefc865c2fe864339e7
Author: sboikov 
Date:   2017-07-11T09:42:54Z

Exchange future cleanup, added special tasks for reassign/force rebalance.

commit 8d4a0c2ca2abc17a1d54fa0d33b161531fa59b12
Author: Pavel Tupitsyn 
Date:   2017-07-11T09:49:16Z

Merge branch 'ignite-2.1'

commit bf25b5c52be044f07076c0800447230c75174db3
Author: Slava Koptilin 
Date:   2017-07-07T12:35:33Z

ignite-5562: assert statements were changed to the 'if' blocks

commit e93b28488693381fcd232de93087ab8ec1d0f5bb
Author: sboikov 
Date:   2017-07-11T11:18:52Z

ignite-5446 Only lateAffinity logic in CacheAffinitySharedManager.

commit 5c363184c80f2fd8b79f1075d1eacbf9af5369a1
Author: Denis Magda 
Date:   2017-07-11T19:20:16Z

Simplified Memory Policies Example

commit b95f76f8a0a3a7e920f78f20b3d814112fc6d522
Author: sboikov 
Date:   2017-07-12T05:47:04Z

ignite-5727 Call TcpCommunicationSpi's discovery listener first

commit 120384fca2b5f6f141207697f776d7859afa857f
Author: devozerov 
Date:   2017-07-12T06:48:51Z

Merge branch 'ignite-2.1'

commit 5394bbdeff4e9fb97d3b413bf30001ede580bdd7
Author: sboikov 
Date:   2017-07-13T10:30:59Z

Unnecessary synchronous rollback in GridDhtTxLocal.prepareAsync

commit 00c6b6c4ba00fa6577f74fc95b378737fb5a789c
Author: Alexander Menshikov 
Date:   2017-07-13T12:24:59Z

IGNITE-5567 Make benchmark Ignite.reentrantLock vs IgniteCache.lock

commit 18bdfe96a1e579371108c661e3374183c58a296d
Author: Alexey Goncharuk 
Date:   2017-07-13T12:42:30Z

Fixed NPE in tests

commit 7338445ac9c1a2343fd41cdd20785de07b727796
Author: dkarachentsev 
Date:   2017-07-13T13:00:08Z

IGNITE-5597 - Fix javadoc in Affinity and AffinityFunction for REPLICATED 
cache. This closes #2268.

commit d9ed07c67e4a4ff3a9de543cbe039ac2a48f03a0
Author: Sergey Chugunov 
Date:   2017-07-13T14:32:06Z

Functionality of muted test is debated now

commit 871d9260f3b32bed5273852dbdb74c758f73d383
Author: Sergey Chugunov 
Date:   2017-07-13T15:34:01Z

Functionality of GridVersionSelfTest is debated now

[GitHub] ignite pull request #2539: Ignite 5817 x

[oleg-ostanin]

GitHub user oleg-ostanin opened a pull request:

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

Ignite 5817 x



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

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

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

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


commit 737874f65d2aa143a79dd5f6b0d223e07a4eceee
Author: Ivan Rakov 
Date:   2017-08-29T10:24:20Z

IGNITE-6204 Backport optimizations of checkpointing algorithm into 2.2

commit 28fb8c8ac5b6d2a24a2b394706bd5840623c5f83
Author: oleg-ostanin 
Date:   2017-08-29T14:25:36Z

IGNITE-5817 Changed checksum calculation methods




---
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 #2446: IGNITE-4642 Support enforceJoinOrder flag for JDB...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Re: ContinuousQueryWithTransformer implementation questions - 2

[Yakov Zhdanov]

Igniters,

Does anyone else see potential issues on user side with current approach?

Sam, is this JCache requirement?

--Yakov

2017-08-29 15:16 GMT+03:00 Nikolay Izhikov :

> Yakov.
>
> I think exception equals `true` is intended behavior.
>
> Filter evaluation implementation from master - [1]
> Test from master to check filter exception(without explicit asserts
> checking listeners call) - [2]
>
> Here is my quick test with asserts on listener call after filter exception:
>
> ```
> package org.apache.ignite.internal.processors.cache.query.continuous;
>
> //... imports
>
> public class GridCacheContinuousQueryFilterExceptionTest extends
> GridCacheContinuousQueryAbstractSelfTest implements Serializable {
> /**
>  * @throws Exception If failed.
>  */
> public void testListenerAfterFilterException() throws Exception {
> IgniteCache cache =
> grid(0).cache(DEFAULT_CACHE_NAME);
>
> ContinuousQuery qry = new ContinuousQuery<>();
>
> final CountDownLatch latch = new CountDownLatch(100);
>
> qry.setLocalListener(new CacheEntryUpdatedListener Integer>() {
> @Override public void onUpdated(Iterable> evts) {
> for (CacheEntryEvent
> evt : evts)
> latch.countDown();
> }
> });
>
> qry.setRemoteFilter(new CacheEntryEventSerializableFilter Integer>() {
> @Override public boolean evaluate(CacheEntryEvent Integer, ? extends Integer> evt) {
> throw new RuntimeException("Test error.");
> }
> });
>
> try (QueryCursor> ignored =
> cache.query(qry)) {
> for (int i = 0; i < 100; i++)
> cache.put(i, i);
>
> assertTrue(latch.await(10, SECONDS));
> }
> }
>
> @Override protected CacheMode cacheMode() {
> return CacheMode.REPLICATED;
> }
>
> @Override protected int gridCount() {
> return 1;
> }
> }
> ```
>
> [1] https://github.com/apache/ignite/blob/master/modules/core/
> src/main/java/org/apache/ignite/internal/processors/cache/
> query/continuous/CacheContinuousQueryHandler.java#L791
>
> [2] https://github.com/apache/ignite/blob/master/modules/core/
> src/test/java/org/apache/ignite/internal/processors/cache/
> query/continuous/GridCacheContinuousQueryAbstractSelfTest.java#L359
>
>
> 29.08.2017 14:46, Yakov Zhdanov пишет:
>
> If filter throws exception entry would be passed to listener.
>>>
>>
>> this is strange. Imagine a filter that very rarely throws some runtime
>> exception due to external or environmental reasons, but in case of normal
>> execution filter evaluates to false. In case of error entry is passed to a
>> local listener which can lead to some serious consequences and
>> inconsistencies in business logic. We probably need to send entry with a
>> notion that there was an error on server.
>>
>> --Yakov
>>
>>

[GitHub] ignite pull request #2538: IGNITE-6212 : Fixed assertion error for invalid n...

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-6212 : Fixed assertion error for invalid node2part.



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

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

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

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


commit bd04c328ea547064b2bdbcae8abe358d79e85b81
Author: Ilya Lantukh 
Date:   2017-08-29T13:45:02Z

ignite-6212 : Fixed assertion error for invalid node2part.




---
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-6214) Client hangs when executing SQL updates

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-6214:


 Summary: Client hangs when executing SQL updates
 Key: IGNITE-6214
 URL: https://issues.apache.org/jira/browse/IGNITE-6214
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov


Sometimes client may hang when performing concurrent SQL updates.

Reproducing code is in the attachment.



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

[jira] [Created] (IGNITE-6213) Unexpected setting local deployment owner anyone node

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-6213:
-

 Summary: Unexpected setting local deployment owner anyone node
 Key: IGNITE-6213
 URL: https://issues.apache.org/jira/browse/IGNITE-6213
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov


In my test I have seen, when one node tune up {{locDepOwner}} flag suddenly.
{noformat}
16:55:47.868 
[ DEBUG] 
[ o.a.i.i.p.c.GridCacheDeploymentManager] 
[ T:] - Prepared grid cache deployable 
[ dep=GridDeploymentInfoBean 
[ clsLdrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553, depMode=SHARED, 
userVer=0, locDepOwner=true, participants=null], 
deployable=GridNearAtomicSingleUpdateRequest 
[ key=UserKeyCacheObjectImpl 
[ part=111, val=4翿翿, hasValBytes=true], 
super=GridNearAtomicSingleUpdateRequest 
[ key=UserKeyCacheObjectImpl 
[ part=111, val=4翿翿, hasValBytes=true], 
parent=GridNearAtomicAbstractSingleUpdateRequest 
[ nodeId=45acc827-8a2d-47d3-aa04-94936ad25ac2, futId=81921, 
topVer=AffinityTopologyVersion 
[ topVer=4, minorTopVer=0], parent=GridNearAtomicAbstractUpdateRequest 
[ res=null, flags=]
{noformat}

By the reason global participant was been registered:

{noformat}
16:55:47.871 
[  DEBUG] 
[  o.a.i.i.m.d.GridDeploymentPerVersionStore] 
[  T:] - Explicitly added participant 
[  dep=SharedDeployment 
[  rmv=false, super=GridDeployment 
[  ts=1503050146264, depMode=SHARED, clsLdr=GridDeploymentClassLoader 
[  id=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, singleNode=false, 
nodeLdrMap={12bb727e-4815-4ab2-8f8c-cc6fd52c8553=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
 
101abc71-83b4-4a87-bb07-14e4cbc7226e=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
 
9d30737f-44d2-4414-b84d-25f032484290=e70b3c4fd51-9d30737f-44d2-4414-b84d-25f032484290},
 p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], 
clsLdrId=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, userVer=0, 
loc=false, sampleClsName=com.sbt.dpl.gridgain.index.InvokeIndexAdder, 
pendingUndeploy=false, undeployed=false, usage=0]], 
nodeId=12bb727e-4815-4ab2-8f8c-cc6fd52c8553, 
ldrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553]
{noformat}

And after that I am geting the Exception when try to get class from node where 
the class was not located:

{noformat}
16:55:50.684 [ERROR] [o.a.i.i.p.job.GridJobProcessor] [T:] - Task was not 
deployed or was redeployed since task execution 
[taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
 
taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
 codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e, 
seqNum=1503050088642, depMode=SHARED, dep=null]
org.apache.ignite.IgniteDeploymentException: Task was not deployed or was 
redeployed since task execution 
[taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
 
taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
 codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e, 
seqNum=1503050088642, depMode=SHARED, dep=null]
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1160)
 ~[ignite-core-2.1.3.jar:2.1.3]
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
 [ignite-core-2.1.3.jar:2.1.3]
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
 [ignite-core-2.1.3.jar:2.1.3]
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
 [ignite-core-2.1.3.jar:2.1.3]
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
 [ignite-core-2.1.3.jar:2.1.3]
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
 [ignite-core-2.1.3.jar:2.1.3]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
[na:1.7.0_80]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
[na:1.7.0_80]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_80]
{noformat}




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

[jira] [Created] (IGNITE-6212) Assertion error: Invalid node2part

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-6212:


 Summary: Assertion error: Invalid node2part
 Key: IGNITE-6212
 URL: https://issues.apache.org/jira/browse/IGNITE-6212
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh
Priority: Critical
 Fix For: 2.2


Reproduced by IgniteServiceDynamicCachesSelfTest with ~10% probability. Leads 
to hang-up.



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

guard() and checkClusterState() checks in Ignite Kernal

[Ilya Kasnacheev]

Dear Igniters,

I would like to know if guard() and checkClusterState() methods are always
called consistently in IgniteKernal.

Let's look at the list:
Out of cluster(), localNode(), compute(), message(), events(),
executorService(), services() only the last one is guarded by
checkClusterState()
Is this correct?

pingNode() is not checked or guarded, but pingNodeByAddress() is guarded.
Is this correct?

undeployTaskFromGrid() and executeTask() are neither checked nor guarded.

eventUserRecordable() and allEventsUserRecordable() are guarded but not
cheked. Is this correct?

getOrCreateCaches() and destroyCachesAsync() are guarded but not checked -
am I correct in trying to fix that in
https://github.com/apache/ignite/pull/2526 ?

destroyCache() and destroyCaches() are neither guarded nor checked, but
destroyCacheAsync() both guarded and checked. What's the reason for that?

binary() and affinity() are checked but not guarded.

active(), resetLostPartitions(), memoryMetrics(), persistentStoreMetrics(),
atomicSequence() are guarded but not checked.

I appreciate your support.

-- 
Ilya Kasnacheev

Re: ContinuousQueryWithTransformer implementation questions - 2

[Nikolay Izhikov]

Yakov.

I think exception equals `true` is intended behavior.

Filter evaluation implementation from master - [1]
Test from master to check filter exception(without explicit asserts 
checking listeners call) - [2]


Here is my quick test with asserts on listener call after filter exception:

```
package org.apache.ignite.internal.processors.cache.query.continuous;

//... imports

public class GridCacheContinuousQueryFilterExceptionTest extends 
GridCacheContinuousQueryAbstractSelfTest implements Serializable {

/**
 * @throws Exception If failed.
 */
public void testListenerAfterFilterException() throws Exception {
IgniteCache cache = 
grid(0).cache(DEFAULT_CACHE_NAME);


ContinuousQuery qry = new ContinuousQuery<>();

final CountDownLatch latch = new CountDownLatch(100);

qry.setLocalListener(new CacheEntryUpdatedListener() {
@Override public void onUpdated(Iterable> evts) {
for (CacheEntryEventInteger> evt : evts)

latch.countDown();
}
});

qry.setRemoteFilter(new 
CacheEntryEventSerializableFilter() {
@Override public boolean evaluate(CacheEntryEventInteger, ? extends Integer> evt) {

throw new RuntimeException("Test error.");
}
});

try (QueryCursor> ignored = 
cache.query(qry)) {

for (int i = 0; i < 100; i++)
cache.put(i, i);

assertTrue(latch.await(10, SECONDS));
}
}

@Override protected CacheMode cacheMode() {
return CacheMode.REPLICATED;
}

@Override protected int gridCount() {
return 1;
}
}
```

[1] 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryHandler.java#L791


[2] 
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/GridCacheContinuousQueryAbstractSelfTest.java#L359



29.08.2017 14:46, Yakov Zhdanov пишет:

If filter throws exception entry would be passed to listener.


this is strange. Imagine a filter that very rarely throws some runtime
exception due to external or environmental reasons, but in case of normal
execution filter evaluates to false. In case of error entry is passed to a
local listener which can lead to some serious consequences and
inconsistencies in business logic. We probably need to send entry with a
notion that there was an error on server.

--Yakov

Re: Plugins in tests

[Pavel Tupitsyn]

I've replied in JIRA. Yakov, please have a look as well.

On Wed, Aug 23, 2017 at 6:44 PM, Vyacheslav Daradur 
wrote:

> Hi,
>
> >> ticket filed: https://issues.apache.org/jira/browse/IGNITE-5879
> I've done it, could someone review it?
>
> 2017-07-31 11:13 GMT+03:00 Pavel Tupitsyn :
>
> > Got it, ticket filed: https://issues.apache.org/jira/browse/IGNITE-5879
> >
> > On Fri, Jul 28, 2017 at 5:58 PM, Yakov Zhdanov 
> > wrote:
> >
> > > Pavel, I would create a new module just like "modules/extdata/p2p".
> > >
> > > --Yakov
> > >
> >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[GitHub] ignite pull request #2537: IGNITE-6193 ML profile is missing in 2.1 binary r...

[oignatenko]

GitHub user oignatenko opened a pull request:

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

IGNITE-6193 ML profile is missing in 2.1 binary release

- verified with diffs overview and trial local build

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

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

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

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


commit 8bdda9ba9146c8e12713a74eb1d1a5612655c370
Author: Oleg Ignatenko 
Date:   2017-08-29T11:55:15Z

IGNITE-6193 ML profile is missing in 2.1 binary release
- verified with diffs overview and trial local build




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

Re: ContinuousQueryWithTransformer implementation questions - 2

[Yakov Zhdanov]

> If filter throws exception entry would be passed to listener.

this is strange. Imagine a filter that very rarely throws some runtime
exception due to external or environmental reasons, but in case of normal
execution filter evaluates to false. In case of error entry is passed to a
local listener which can lead to some serious consequences and
inconsistencies in business logic. We probably need to send entry with a
notion that there was an error on server.

--Yakov

Re: ContinuousQueryWithTransformer implementation questions - 2

[Nikolay Izhikov]

Hi, Yakov.

If filter throws exception entry would be passed to listener.

> Nikolay, I would also suggest you extract some super class for continuous
> query. It will help to avoid code duplicates.

Yes, I will do this after reaching consensus on API changes.

29.08.2017 14:04, Yakov Zhdanov пишет:

I don't like the idea of having separate class, but it seems to be the only
way as there are too many API and generics differences.

Nikolay, I would also suggest you extract some super class for continuous
query. It will help to avoid code duplicates.

As far as remote transformer failure - we should react in the same way as
we react now for filter failure. I don't think there should be a
difference. What is the reaction now?

--Yakov

[GitHub] ignite pull request #2448: IGNITE-6050

[asfgit]

Github user asfgit closed the pull request at:

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


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

Re: ContinuousQueryWithTransformer implementation questions - 2

[Yakov Zhdanov]

I don't like the idea of having separate class, but it seems to be the only
way as there are too many API and generics differences.

Nikolay, I would also suggest you extract some super class for continuous
query. It will help to avoid code duplicates.

As far as remote transformer failure - we should react in the same way as
we react now for filter failure. I don't think there should be a
difference. What is the reaction now?

--Yakov

Re: ContinuousQueryWithTransformer implementation questions - 2

[Anton Vinogradov]

Nikolay,

> 2. What behavior is expected if transformer throws exception for some
event? I see following options:

Client should be notified, I vote for
> Introduce special callback. onTransformError?


On Tue, Aug 29, 2017 at 1:36 PM, Nikolay Izhikov 
wrote:

> Hello, Igniters.
>
> I'm working on IGNITE-425 [1] issue.
>
> Text of issue:
>
> ===
> Currently if updated entry passes the filter, it is sent to node initiated
> the query entirely. It would be good to provide user with the ability to
> transform entry and, for example, select only fields that are important.
> This may bring huge economy to traffic and lower GC pressure as well.
> ===
>
> My pull request [2] is ready.
> Anton Vinogradov is OK with it.
> Nikolay Tikhonov reviewed my changes and want to discuss changes related
> to public API with community.
>
> 1. I introduce new query class - ContinuousQueryWithTransformer [3].
> Reasons:
> * ContinuousQuery is final so user can't extends it. I don't want to
> change that.
> * ContinuousQuery contains some deprecated methods(setRemoteFilter) so
> with new class we can get rid of them.
> * Such public API design disallow usage of existing localEventListener
> with new transformedEventListenr in compile time.
>
> Thoughts?
>
> 2. What behavior is expected if transformer throws exception for some
> event? I see following options:
>
> * Pass `null` to listener(pull request implementation).
> * Skip event. Don't call listener.
> * Introduce special callback. onTransformError?
>
> Thoughts?
>
> ```
> public final class ContinuousQueryWithTransformer extends
> Query> {
> //...
>
> private Factory>
> rmtFilterFactory;
>
> private Factory ? extends V>, T>> rmtTransFactory;
>
> private EventListener locLsnr;
>
> //...
>
> public interface EventListener {
> void onUpdated(Iterable events);
> }
> }
> ```
>
> Previous discussion - [4]
>
> [1] https://issues.apache.org/jira/browse/IGNITE-425
> [2] https://github.com/apache/ignite/pull/2372
> [3] https://github.com/apache/ignite/pull/2372/files#diff-22cc0c
> f0bc428b32a39e6cc0b22b0e3e
> [4] http://apache-ignite-developers.2346864.n4.nabble.com/Contin
> uousQueryWithTransformer-implementation-questions-td20078.html
>

[GitHub] ignite pull request #2536: IGNITE-6210 Size of the checkpoint buffer is limi...

[DmitriyGovorukhin]

GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-6210 Size of the checkpoint buffer is limited 



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

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

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

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


commit e0956a4db319113219b46f0fc033b1564423f831
Author: Dmitriy Govorukhin 
Date:   2017-08-29T10:46:20Z

IGNITE-6210 Size of the checkpoint buffer is limited by the size of the 
memory policy




---
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.
---

ContinuousQueryWithTransformer implementation questions - 2

[Nikolay Izhikov]

Hello, Igniters.

I'm working on IGNITE-425 [1] issue.

Text of issue:

===
Currently if updated entry passes the filter, it is sent to node 
initiated the query entirely. It would be good to provide user with the 
ability to transform entry and, for example, select only fields that are 
important. This may bring huge economy to traffic and lower GC pressure 
as well.

===

My pull request [2] is ready.
Anton Vinogradov is OK with it.
Nikolay Tikhonov reviewed my changes and want to discuss changes related 
to public API with community.


1. I introduce new query class - ContinuousQueryWithTransformer [3].
Reasons:
* ContinuousQuery is final so user can't extends it. I don't want to
change that.
* ContinuousQuery contains some deprecated methods(setRemoteFilter) so 
with new class we can get rid of them.

* Such public API design disallow usage of existing localEventListener
with new transformedEventListenr in compile time.

Thoughts?

2. What behavior is expected if transformer throws exception for some 
event? I see following options:


* Pass `null` to listener(pull request implementation).
* Skip event. Don't call listener.
* Introduce special callback. onTransformError?

Thoughts?

```
public final class ContinuousQueryWithTransformer extends 
Query> {

//...

private Factory> 
rmtFilterFactory;


private FactoryK, ? extends V>, T>> rmtTransFactory;


private EventListener locLsnr;

//...

public interface EventListener {
void onUpdated(Iterable events);
}
}
```

Previous discussion - [4]

[1] https://issues.apache.org/jira/browse/IGNITE-425
[2] https://github.com/apache/ignite/pull/2372
[3] 
https://github.com/apache/ignite/pull/2372/files#diff-22cc0cf0bc428b32a39e6cc0b22b0e3e
[4] 
http://apache-ignite-developers.2346864.n4.nabble.com/ContinuousQueryWithTransformer-implementation-questions-td20078.html

[jira] [Created] (IGNITE-6211) ODBC: SQLBindParameter should not unbind parameter if the ParameterValuePtr is NULL

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-6211:
---

 Summary: ODBC: SQLBindParameter should not unbind parameter if the 
ParameterValuePtr is NULL
 Key: IGNITE-6211
 URL: https://issues.apache.org/jira/browse/IGNITE-6211
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.1
Reporter: Igor Sapego


Currently, {{SQLBindParameter}} unbinds parameter if the {{ParameterValuePtr}} 
is {{NULL}} in analogy with {{SQLBindCol}}. Howeverm according to 
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlbindparameter-function
 there should not be such a behaviour. {{ParameterValuePtr}} can be set to 
{{NULL}} for example if user wants to bind {{SQL_NULL_DATA}} parameter.



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

[jira] [Created] (IGNITE-6210) inefficient memory consumption for checkpoint buffer

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-6210:
--

 Summary: inefficient memory consumption for checkpoint buffer
 Key: IGNITE-6210
 URL: https://issues.apache.org/jira/browse/IGNITE-6210
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.1
Reporter: Dmitriy Govorukhin
Assignee: Dmitriy Govorukhin
Priority: Critical
 Fix For: 2.2


Current implementation allows configure checkpoint buffer size in 
PersistentStoreConfiguration, but checkpoint buffer will be created for each 
memory configuration with size equals the one indicated in 
PersistentStoreConfiguration.

For example:
{code}
PersistentStoreConfiguration prCfg = new PersistentStoreConfiguration();
prCfg.setCheckpointingFrequency(5L * 1024L * 1024L * 1024L); // 5GB.

MemoryConfiguration memCfg = new MemoryConfiguration();

MemoryPolicyConfiguration pl1 = new MemoryPolicyConfiguration();

pl1.setMaxSize(100L * 1024L * 1024L); // 100 Mb.

MemoryPolicyConfiguration pl2 = new MemoryPolicyConfiguration();

pl2.setMaxSize(10L * 1024L * 1024L * 1024L); // 10GB.

memCfg.setMemoryPolicies(pl1, pl2);
{code}

pl1(max size 10Gb) will be have checkpoint buffer = 5GB and pl2(max size 100Mb) 
buffer= 5GB




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

[GitHub] ignite pull request #2535: IGNITE-6182

[gvvinblade]

GitHub user gvvinblade opened a pull request:

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

IGNITE-6182



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

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

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

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


commit 1e7b4a9881b186665e6c58887725b1e860ea2d14
Author: Igor Seliverstov 
Date:   2017-08-28T14:10:50Z

IGNITE-6182 Change default max memory size from 80% to 20%




---
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-6209) Build Ignite.NET NuGet packages for Apache-Ignite release on CI

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-6209:


 Summary: Build Ignite.NET NuGet packages for Apache-Ignite release 
on CI
 Key: IGNITE-6209
 URL: https://issues.apache.org/jira/browse/IGNITE-6209
 Project: Ignite
  Issue Type: Improvement
Reporter: Oleg Ostanin
 Fix For: 2.3


Create a suite to build Ignite.NET NuGet packages.



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

sql documentation

[Serge Puchnin]

Hi !

As I can see, there is some room for documentation improvement.
As a sample of documentation, I've prepared a description of "CREATE INDEX"
statement.

What’s your opinion?
What can be improved?
What should be added?

Thanks a lot!

---
Serge

[jira] [Created] (IGNITE-6208) SQL: Add documentation for lazy query execution

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6208:
---

 Summary: SQL: Add documentation for lazy query execution
 Key: IGNITE-6208
 URL: https://issues.apache.org/jira/browse/IGNITE-6208
 Project: Ignite
  Issue Type: Task
  Components: documentation, sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.3






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

[GitHub] ignite pull request #2491: IGNITE-6118 JDBC Thin: Propagate "lazy" flag

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---