[jira] [Created] (IGNITE-8120) Improve test coverage of rebalance failing

[Ivan Daschinskiy (JIRA)]

Ivan Daschinskiy created IGNITE-8120:


 Summary: Improve test coverage of rebalance failing
 Key: IGNITE-8120
 URL: https://issues.apache.org/jira/browse/IGNITE-8120
 Project: Ignite
  Issue Type: Test
  Components: general
Affects Versions: 2.4
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy
 Fix For: 2.5






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8121) Web console: import cluster from database doesn't work correctly for second import

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8121:
--

 Summary: Web console: import cluster from database doesn't work 
correctly for second import
 Key: IGNITE-8121
 URL: https://issues.apache.org/jira/browse/IGNITE-8121
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov


# initial state - no one cluster exists
# import from any DB - the first time all imported correctly
# import the second time - error "Cluster ... already exists"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Breaking change in JDBC connection string format

[Vladimir Ozerov]

Igniters,

Thanks to Alex Kuznetsov, we revealed serious usability issue in our thin
JDBC driver - we user ampersand character to delimit properties:

jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2

This leads to multiple problems:
1) This format is unusable from many console environments and require
special escaping (PowerShell, bash)
2) Also this causing issues when writing connection string is passed to
some 3rd-party applications as sometimes they cannot escape it as well.

I performed investigation on how other vendors do that. Bottom line -
nobody use ampersand. Instead semicolon or parentheses are used:

jdbc:ignite:thin://host:port/schema?param1=val1¶m2=val2
jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)

I propose to do a breaking change in AI 2.5 and change the format to
*parentheses*. This would be a disruptive experience for existing users,
but in the long term benefits will outweight. Also remember that we do not
offered officially any backward compatibility for our JDBC driver.

Alternatively we may allow users to use previous format with help of system
property or environment variable.

Thoughts?

Vladimir.

Re: Timeline for support of compute functions by thin clients

[Vladimir Ozerov]

I do not see any additional risks provided that authentication and
authorization will be integrated with thin clients in the same way it is
done for "thick" clients.

On Tue, Apr 3, 2018 at 7:40 AM, Dmitriy Setrakyan 
wrote:

> Val, my preference would be not to have compute functionality on thin
> clients, as it would introduce extra security risk.
>
> Any particular reason why you are asking for this feature?
>
> ⁣D.​
>
> On Apr 2, 2018, 8:47 PM, at 8:47 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> >Folks,
> >
> >Any other thoughts on this? Should we create tickets for compute
> >support if
> >there are no objections?
> >
> >-Val
> >
> >On Thu, Mar 22, 2018 at 4:27 PM, Valentin Kulichenko <
> >valentin.kuliche...@gmail.com> wrote:
> >
> >> I agree that compute and services functionality is important for thin
> >> client. It doesn't seem to be very hard to implement, but would
> >provide
> >> much better flexibility, as users would be able to do remote
> >invocation of
> >> arbitrary code, use collocated processing, etc. Having an ability to
> >do
> >> this from a thin client without joining the topology is a huge
> >advantage.
> >>
> >> -Val
> >>
> >> On Fri, Mar 16, 2018 at 4:00 AM, Vladimir Ozerov
> >
> >> wrote:
> >>
> >>> Denis,
> >>>
> >>> From client perspective any compute task is also request - response.
> >This
> >>> doesn't distinguish compute from any other API anyhow. There are no
> >>> problem
> >>> to add closures, tasks, services, etc.. What is really difficult is
> >>> components requiring non-trivial thread interaction and complex
> >request
> >>> workflows. E.g. streaming, COPY command, continuous queries, events.
> >>>
> >>> On Thu, Mar 15, 2018 at 10:25 PM, Denis Magda 
> >wrote:
> >>>
> >>> > Pavel,
> >>> >
> >>> > I just don't see a substantial reason why we need to support the
> >>> > compute APIs.
> >>> >
> >>> > As you properly mentioned, it's not easy to copy all the APIs and,
> >>> again,
> >>> > for what. It's right that the thin client allows decoupling .NET
> >from
> >>> JVM,
> >>> > but its implementation won't be more performant than the regular
> >>> client's
> >>> > one.
> >>> >
> >>> > So, personally, a thin client (.NET, Node.JS, Java, Python, etc.)
> >is a
> >>> > lightweight connection to the cluster that supports classic
> >>> client-server
> >>> > request-response operations. If someone needs more (compute,
> >services,
> >>> > streaming, ML), then go for the regular client which is
> >battle-tested
> >>> and
> >>> > available for usage.
> >>> >
> >>> > --
> >>> > Denis
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Mar 14, 2018 at 1:33 PM, Pavel Tupitsyn
> >
> >>> > wrote:
> >>> >
> >>> > > Hi Denis,
> >>> > >
> >>> > > > There are no any plans for that level of support
> >>> > > Why do you think so?
> >>> > > We already have ScanQuery with filter in .NET Thin Client, which
> >>> involves
> >>> > > remote code execution on server nodes.
> >>> > > It is quite similar to Compute.Broadcast and such.
> >>> > >
> >>> > > Thanks,
> >>> > > Pavel
> >>> > >
> >>> > >
> >>> > > On Wed, Mar 14, 2018 at 11:32 PM, Denis Magda
> >
> >>> wrote:
> >>> > >
> >>> > > > Raymond,
> >>> > > >
> >>> > > > Then I would suggest you keep using the regular .NET client
> >that
> >>> > supports
> >>> > > > and optimized for computations. Is there any reason why you
> >can't
> >>> use
> >>> > the
> >>> > > > regular one?
> >>> > > >
> >>> > > > --
> >>> > > > Denis
> >>> > > >
> >>> > > > On Wed, Mar 14, 2018 at 12:53 PM, Raymond Wilson <
> >>> > > > raymond_wil...@trimble.com
> >>> > > > > wrote:
> >>> > > >
> >>> > > > > Hi Denis,
> >>> > > > >
> >>> > > > > We are using Ignite.Net and are planning to use 2.4 + .Net
> >Core +
> >>> > thin
> >>> > > > > client support to enable lightweight containerisable
> >services that
> >>> > > > interact
> >>> > > > > with the main Ignite compute grid.
> >>> > > > >
> >>> > > > > These work flows are less about Get/Put style semantics, and
> >more
> >>> > about
> >>> > > > > using grid compute.
> >>> > > > >
> >>> > > > > Eg: Here's an example where a client context asks a remote
> >>> context to
> >>> > > > > render
> >>> > > > > a bitmap tile in an ICompute:
> >>> > > > >
> >>> > > > > public Bitmap Execute(TileRenderRequestArgument arg)
> >>> > > > > {
> >>> > > > > IComputeFunc
> >func
> >>> =
> >>> > new
> >>> > > > > TileRenderRequestComputeFunc();
> >>> > > > >
> >>> > > > > return
> >>> > > > > _ignite.GetCluster().ForRemotes().GetCompute().Apply(func,
> >arg);
> >>> > > > > }
> >>> > > > >
> >>> > > > > In this example, the calling context here could be a
> >lightweight
> >>> > > Kestrel
> >>> > > > > web
> >>> > > > > service end point delegating rendering to a remote service.
> >>> > > > >
> >>> > > > > Thanks,
> >>> > > > > Raymond.
> >>> > > > >
> >>> > > > > -Original Message-
> >>> > > > > From: Denis Magda [mailto:dma...@apache.org]
> >>> > > > > Sent: Thursday, Mar

Re: Breaking change in JDBC connection string format

[Alexey Kuznetsov]

Vladimir,

If we will use parentheses, do we really need "?"  symbol? It looks
redundant for me in case of parentheses.

jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
vs
jdbc:ignite:thin://host:port/schema(param1=val1)(param2=val2)


What do you think?


On Tue, Apr 3, 2018 at 3:30 PM, Vladimir Ozerov 
wrote:

> Igniters,
>
> Thanks to Alex Kuznetsov, we revealed serious usability issue in our thin
> JDBC driver - we user ampersand character to delimit properties:
>
> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
>
> This leads to multiple problems:
> 1) This format is unusable from many console environments and require
> special escaping (PowerShell, bash)
> 2) Also this causing issues when writing connection string is passed to
> some 3rd-party applications as sometimes they cannot escape it as well.
>
> I performed investigation on how other vendors do that. Bottom line -
> nobody use ampersand. Instead semicolon or parentheses are used:
>
> jdbc:ignite:thin://host:port/schema?param1=val1¶m2=val2
> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
>
> I propose to do a breaking change in AI 2.5 and change the format to
> *parentheses*. This would be a disruptive experience for existing users,
> but in the long term benefits will outweight. Also remember that we do not
> offered officially any backward compatibility for our JDBC driver.
>
> Alternatively we may allow users to use previous format with help of
> system property or environment variable.
>
> Thoughts?
>
> Vladimir.
>



-- 
Alexey Kuznetsov

Re: Breaking change in JDBC connection string format

[Taras Ledkov]

Hi,

1. Mysql JDBC driver Conenctor/J [1] and postgres JDBC driver [2] use 
ampersand to delimit properties.
2. Mysql use regular URL encoding for properties values instead of 
legacy escaping (e.g braces etc.)
3. Microsoft JDBC (and ODBC) driver for SQL Server [3] use semicolon to 
delimit and square braces to escape.


So, there is no true way to solve the issue.

However, the inconvenience of using the console is the last thing I paid 
attention to.

- using JDBC driver from console client is not common case;
- when any command line shell is used the various escaping of the 
parameters is routine job.


So, the root cause of the proposal is not clear for me.

[1]. 
https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-configuration-properties.html


[2]. https://jdbc.postgresql.org/documentation/80/connect.html

[3]. https://msdn.microsoft.com/ru-ru/library/ms378428(v=sql.100).aspx

On 03.04.2018 11:30, Vladimir Ozerov wrote:

Igniters,

Thanks to Alex Kuznetsov, we revealed serious usability issue in our thin
JDBC driver - we user ampersand character to delimit properties:

jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2

This leads to multiple problems:
1) This format is unusable from many console environments and require
special escaping (PowerShell, bash)
2) Also this causing issues when writing connection string is passed to
some 3rd-party applications as sometimes they cannot escape it as well.

I performed investigation on how other vendors do that. Bottom line -
nobody use ampersand. Instead semicolon or parentheses are used:

jdbc:ignite:thin://host:port/schema?param1=val1¶m2=val2
jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)

I propose to do a breaking change in AI 2.5 and change the format to
*parentheses*. This would be a disruptive experience for existing users,
but in the long term benefits will outweight. Also remember that we do not
offered officially any backward compatibility for our JDBC driver.

Alternatively we may allow users to use previous format with help of system
property or environment variable.

Thoughts?

Vladimir.



--
Taras Ledkov
Mail-To: tled...@gridgain.com

[GitHub] ignite pull request #3738: patch

[voipp]

GitHub user voipp opened a pull request:

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

patch



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

$ git pull https://github.com/voipp/ignite IGNITE-7481-patch

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

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


commit db8d8c606419067314eba8e911c5e515dc9f5c91
Author: voipp 
Date:   2018-04-03T08:59:34Z

patch




---

Re: Breaking change in JDBC connection string format

[Alexey Kuznetsov]

Taras,

I spent today 30 minutes trying to connect to cluster with sqlline in Power
Shell  :(

I predict 100500+ questions on user list about "Failed to connect in bash /
cmd / powershell  with sqlline"

On Tue, Apr 3, 2018 at 3:55 PM, Taras Ledkov  wrote:

> Hi,
>
> 1. Mysql JDBC driver Conenctor/J [1] and postgres JDBC driver [2] use
> ampersand to delimit properties.
> 2. Mysql use regular URL encoding for properties values instead of legacy
> escaping (e.g braces etc.)
> 3. Microsoft JDBC (and ODBC) driver for SQL Server [3] use semicolon to
> delimit and square braces to escape.
>
> So, there is no true way to solve the issue.
>
> However, the inconvenience of using the console is the last thing I paid
> attention to.
> - using JDBC driver from console client is not common case;
> - when any command line shell is used the various escaping of the
> parameters is routine job.
>
> So, the root cause of the proposal is not clear for me.
>
> [1]. https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-
> reference-configuration-properties.html
>
> [2]. https://jdbc.postgresql.org/documentation/80/connect.html
>
> [3]. https://msdn.microsoft.com/ru-ru/library/ms378428(v=sql.100).aspx
>
> On 03.04.2018 11:30, Vladimir Ozerov wrote:
>
>> Igniters,
>>
>> Thanks to Alex Kuznetsov, we revealed serious usability issue in our thin
>> JDBC driver - we user ampersand character to delimit properties:
>>
>> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
>>
>> This leads to multiple problems:
>> 1) This format is unusable from many console environments and require
>> special escaping (PowerShell, bash)
>> 2) Also this causing issues when writing connection string is passed to
>> some 3rd-party applications as sometimes they cannot escape it as well.
>>
>> I performed investigation on how other vendors do that. Bottom line -
>> nobody use ampersand. Instead semicolon or parentheses are used:
>>
>> jdbc:ignite:thin://host:port/schema?param1=val1¶m2=val2
>> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
>>
>> I propose to do a breaking change in AI 2.5 and change the format to
>> *parentheses*. This would be a disruptive experience for existing users,
>> but in the long term benefits will outweight. Also remember that we do not
>> offered officially any backward compatibility for our JDBC driver.
>>
>> Alternatively we may allow users to use previous format with help of
>> system
>> property or environment variable.
>>
>> Thoughts?
>>
>> Vladimir.
>>
>>
> --
> Taras Ledkov
> Mail-To: tled...@gridgain.com
>
>


-- 
Alexey Kuznetsov

Re: Breaking change in JDBC connection string format

[Ilya Kasnacheev]

Hello!

I think semicolon is the way to go, since round brackets are often
interpreted by shells and will need escaping on their own. Let's get rid of
& and ?.

jdbc:ignite:thin://host:port/schema:param1=val1:param2=val2

-- 
Ilya Kasnacheev

2018-04-03 11:30 GMT+03:00 Vladimir Ozerov :

> Igniters,
>
> Thanks to Alex Kuznetsov, we revealed serious usability issue in our thin
> JDBC driver - we user ampersand character to delimit properties:
>
> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
>
> This leads to multiple problems:
> 1) This format is unusable from many console environments and require
> special escaping (PowerShell, bash)
> 2) Also this causing issues when writing connection string is passed to
> some 3rd-party applications as sometimes they cannot escape it as well.
>
> I performed investigation on how other vendors do that. Bottom line -
> nobody use ampersand. Instead semicolon or parentheses are used:
>
> jdbc:ignite:thin://host:port/schema?param1=val1¶m2=val2
> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
>
> I propose to do a breaking change in AI 2.5 and change the format to
> *parentheses*. This would be a disruptive experience for existing users,
> but in the long term benefits will outweight. Also remember that we do not
> offered officially any backward compatibility for our JDBC driver.
>
> Alternatively we may allow users to use previous format with help of system
> property or environment variable.
>
> Thoughts?
>
> Vladimir.
>

[jira] [Created] (IGNITE-8122) Partition state restored from WAL may be lost if no checkpoints are done

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8122:
---

 Summary: Partition state restored from WAL may be lost if no 
checkpoints are done
 Key: IGNITE-8122
 URL: https://issues.apache.org/jira/browse/IGNITE-8122
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.4
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.5


Problem:
1) Start several nodes with enabled persistence.
2) Make sure that all partitions for 'ignite-sys-cache' have status OWN on all 
nodes and appropriate PartitionMetaStateRecord record is logged to WAL
3) Stop all nodes and start again, activate cluster. Checkpoint for 
'ignite-sys-cache' is empty, because there were no data in cache.
4) State for all partitions will be restored to OWN 
(GridCacheDatabaseSharedManager#restoreState) from WAL, but not recorded to 
page memory, because there were no checkpoints and data in cache. Store manager 
is not properly initialized for such partitions.
5) On exchange done we're trying to restore states of partitions 
(initPartitionsWhenAffinityReady) on all nodes. Because page memory is empty, 
states of all partitions will be restored to MOVING by default.
6) All nodes start to rebalance partitions from each other and this process 
become unpredictable because we're trying to rebalance from MOVING partitions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Breaking change in JDBC connection string format

[Andrey Gura]

Hi,

We've been solve this problem during JDBC2 driver implementation. And
I don't know any complains about connection string format. Why we can
just use the same approach? [1]

[1] 
https://issues.apache.org/jira/browse/IGNITE-1250?focusedCommentId=14706511&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14706511

On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
 wrote:
> Hello!
>
> I think semicolon is the way to go, since round brackets are often
> interpreted by shells and will need escaping on their own. Let's get rid of
> & and ?.
>
> jdbc:ignite:thin://host:port/schema:param1=val1:param2=val2
>
> --
> Ilya Kasnacheev
>
> 2018-04-03 11:30 GMT+03:00 Vladimir Ozerov :
>
>> Igniters,
>>
>> Thanks to Alex Kuznetsov, we revealed serious usability issue in our thin
>> JDBC driver - we user ampersand character to delimit properties:
>>
>> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
>>
>> This leads to multiple problems:
>> 1) This format is unusable from many console environments and require
>> special escaping (PowerShell, bash)
>> 2) Also this causing issues when writing connection string is passed to
>> some 3rd-party applications as sometimes they cannot escape it as well.
>>
>> I performed investigation on how other vendors do that. Bottom line -
>> nobody use ampersand. Instead semicolon or parentheses are used:
>>
>> jdbc:ignite:thin://host:port/schema?param1=val1¶m2=val2
>> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
>>
>> I propose to do a breaking change in AI 2.5 and change the format to
>> *parentheses*. This would be a disruptive experience for existing users,
>> but in the long term benefits will outweight. Also remember that we do not
>> offered officially any backward compatibility for our JDBC driver.
>>
>> Alternatively we may allow users to use previous format with help of system
>> property or environment variable.
>>
>> Thoughts?
>>
>> Vladimir.
>>

[jira] [Created] (IGNITE-8123) Web console: incorrect text after all clusters have been deleted

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8123:
--

 Summary: Web console: incorrect text after all clusters have been 
deleted
 Key: IGNITE-8123
 URL: https://issues.apache.org/jira/browse/IGNITE-8123
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov


# create two clusters
# delete all clusters
# see attachment



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8124) Web console: incorrect text after all clusters have been deleted

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8124:
--

 Summary: Web console: incorrect text after all clusters have been 
deleted
 Key: IGNITE-8124
 URL: https://issues.apache.org/jira/browse/IGNITE-8124
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov
 Attachments: screenshot-1.png

# create two clusters
# delete all clusters
# see attachment



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8125) Returns null on cache querying on column type PGOBJECT (JSONB) superset or @>

[Siddarth sreeni (JIRA)]

Siddarth sreeni created IGNITE-8125:
---

 Summary: Returns null on cache querying on column type PGOBJECT 
(JSONB) superset or @>
 Key: IGNITE-8125
 URL: https://issues.apache.org/jira/browse/IGNITE-8125
 Project: Ignite
  Issue Type: Bug
  Components: cache, jdbc, sql
Affects Versions: 2.4, 2.3, 2.2, 2.1, 2.0
Reporter: Siddarth sreeni


Apache Ignite briefly discusses the uses of SQL Cache query. It talks about the 
different transactional query it can be used to done. Apache Ignite is as said 
supported on PostGreSQL databases. 
For example: In a table of column type JSONB. Querying for a specific object 
superset in a column returns Null.
Query: Select * from Table where column @> 'Object' 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8126) Web console: the method 'LoadCaches' should not be generated if cache doesn't contain cache store configuration

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8126:
--

 Summary: Web console: the method 'LoadCaches' should not be 
generated if cache doesn't contain cache store configuration
 Key: IGNITE-8126
 URL: https://issues.apache.org/jira/browse/IGNITE-8126
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Vasiliy Sisko


# create cluster, save
# create cache, save
# see project structure



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3739: IGNITE-1776

[NSAmelchev]

GitHub user NSAmelchev opened a pull request:

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

IGNITE-1776



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

$ git pull https://github.com/NSAmelchev/ignite ignite-1776

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

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


commit 11424e9eeefc8fe1b8575623c18a8d565a376ab9
Author: NSAmelchev 
Date:   2017-11-28T14:25:13Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit 0b16700731bda414b8d7921f2c098c5ad1b6540b
Author: NSAmelchev 
Date:   2018-01-19T09:46:31Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit 0de054fe0a1ae41db58a67d3387d08deaf6d22e2
Author: NSAmelchev 
Date:   2018-02-27T11:00:41Z

Merge remote-tracking branch 'apache/master'

commit 29cb0f44d25621d1e41e00d504c3e7bf44c1d735
Author: NSAmelchev 
Date:   2018-03-15T10:58:37Z

Merge pull request #20 from apache/master

merge

commit 9b0f16930a5e1da4ef3a528b7879cd1fca5307f7
Author: NSAmelchev 
Date:   2018-03-20T08:17:26Z

Merge pull request #21 from apache/master

Merge

commit 28619f3040851925c7e176ea04749dcd47ad8cd7
Author: NSAmelchev 
Date:   2018-04-02T12:38:26Z

del fail




---

[GitHub] ignite pull request #3740: ignite-8049 Limit the number of operation cycles ...

[SpiderRus]

GitHub user SpiderRus opened a pull request:

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

ignite-8049 Limit the number of operation cycles in B+Tree



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

$ git pull https://github.com/SpiderRus/ignite ignite-8049

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

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


commit 035c5c44d008b79cfa2a9a29ca1775e3f06bef55
Author: Алексей Стельмак 
Date:   2018-04-03T11:33:04Z

Limit the number of operation cycles in B+Tree




---

Re: IGNITE-6827 - Review needed.

[Andrey Gura]

Alexey,

could you please create code review in Upsource? The PR is huge and it
would be great to have an ability to discuss changes in more
convenient way.

Thanks.

On Tue, Apr 3, 2018 at 12:42 AM, Dmitriy Setrakyan
 wrote:
> I looked into the ticket and do not understand this property
> name: RollbackOnTopologyChangeTimeout
>
> I think what we need to configure is a forceful kill of transactions in
> case of partition map exchange, right? In that case, the timeout should be
> configured for PME, not transactions. The property name should be
> PartitionMapExchangePreparationTimeout or PartitionMapExchangeTxTimeout.
>
> Am I missing something?
>
> D.
>
> On Mon, Apr 2, 2018 at 2:48 AM, Alexey Goncharuk > wrote:
>
>> Guys, especially Vladimir Ozerov, Yakov Zhanov, Dmitriy Setrakyan,
>>
>> While the technical side of the change is being reviewed, I would also ask
>> you to pay attention to the public API changes here.
>>
>> --AG
>>
>> 2018-03-21 23:43 GMT+03:00 Pavel Tupitsyn :
>>
>> > Hi Alexei,
>> >
>> > >  Pavel Tupitsyn, could you lend a hand to help completing .NET part
>> (two
>> > new
>> > public API methods are added as a part of working on [3], java code in
>> > branch [2])
>> >
>> > Please file a separate ticket for .NET changes.
>> > I would like to help, but maybe some time later. No need to delay your
>> > changes because of that.
>> >
>> > Thanks,
>> > Pavel
>> >
>> > On Wed, Mar 21, 2018 at 1:08 PM, Dmitry Pavlov 
>> > wrote:
>> >
>> > > Hi Alexei ,
>> > >
>> > > Thank you for contribution, unfortunately there is too much tests
>> failed
>> > > there:
>> > > .NET is broken
>> > >
>> > >   Ignite Platform .NET Long Running [ tests 3 ]
>> > > CachePartitionedNearEnabledTest.TestTransactionScopeMultiCache
>> (True)
>> > > CachePartitionedTest.TestTransactionScopeMultiCache(True)
>> > > CacheReplicatedTest.TestTransactionScopeMultiCache(True)
>> > >
>> > >Ignite Platform .NET Core Linux [ tests 2 TC_EXIT_CODE ]
>> > >  TransactionsParityTest.TestTransactions (fail rate 0,0%)
>> > >  CachePartitionedTest.TestTransactionScopeMultiCache(True) (fail
>> > rate
>> > > 0,0%)
>> > >
>> > >Ignite Platform .NET [ tests 1 ] agoncharuk More info >>
>> > > Test fail rate less than 1%, probably new failure  exe:
>> > > TransactionsParityTest.TestTransactions (fail rate 0,0%)
>> > >
>> > > Too much timeouts:
>> > >Ignite Cache Failover [2]
>> > >  with CacheAsyncOperationsFailoverTxTest.testPutAllAsyncFailover (last
>> > > started)
>> > >
>> > >~[Obsolete] Ignite Cache Expiry Policy [ tests 1 ]
>> > > with  IgniteCacheExpiryPolicyTestSuite:
>> > > IgniteCacheTtlCleanupSelfTest.testDeferredDeleteTtl
>> > >
>> > >  Ignite Cache Restarts [2]
>> > >   with
>> > > GridCachePutAllFailoverSelfTest.testPutAllFailoverNearDisabled
>> > ThreeBackups
>> > > (last started)
>> > >
>> > >   Ignite Cache Restarts [1]
>> > >with
>> > > GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest.
>> > > testRestartWithTxTenNodesTwoBackups
>> > > (last started)
>> > >
>> > >  Cache [6]
>> > >with  WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator
>> > > (last started)
>> > > it is not all.
>> > >
>> > > Please fix tests before review. Also you could change ticket status to
>> > 'In
>> > > Progress'.
>> > >
>> > > As easy option, you can merge current master to your branch, it is
>> > probably
>> > > that some test were fixed already.
>> > >
>> > > Sincerely,
>> > > Dmitriy Pavlov
>> > >
>> > > ср, 21 мар. 2018 г. в 9:58, Alexei Scherbakov <
>> > > alexey.scherbak...@gmail.com
>> > > >:
>> > >
>> > > > Igniters,
>> > > >
>> > > > I prepared rather important patch [1] related to grid stability and
>> > need
>> > > a
>> > > > review and some help to finish it.
>> > > >
>> > > > Semyon Boikov, could you please take a look on patch code ? [2]
>> > > >
>> > > > Pavel Tupitsyn, could you lend a hand to help completing .NET part
>> (two
>> > > new
>> > > > public API methods are added as a part of working on [3], java code
>> in
>> > > > branch [2])
>> > > >
>> > > > [1] https://issues.apache.org/jira/browse/IGNITE-6827
>> > > >
>> > > > [2] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2
>> > > >
>> > > > [3] https://issues.apache.org/jira/browse/IGNITE-7910
>> > > >
>> > > > --
>> > > >
>> > > > Best regards,
>> > > > Alexei Scherbakov
>> > > >
>> > >
>> >
>>

Make TC issues seems to be hung up

[Dmitry Pavlov]

Hi Igniters,

Following issues for tests fixing seems have no progress . Mainteiners,
please address.

https://issues.apache.org/jira/browse/IGNITE-7766
- Alexei Scherbakov - not responding, if contributor is not interested in
this test anymore, probably we should remove it from code base?

https://issues.apache.org/jira/browse/IGNITE-7809
- Ilya Lantukh, Alexey Goncharuk - not responding

https://issues.apache.org/jira/browse/IGNITE-7692
- Alexey Goncharuk, Vladimir Ozerov - not responding

Folks?

Sincerely,
Dmitriy Pavlov

[jira] [Created] (IGNITE-8127) .NET: Fix flaky test ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-8127:


 Summary: .NET: Fix flaky test 
ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress
 Key: IGNITE-8127
 URL: https://issues.apache.org/jira/browse/IGNITE-8127
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.5
Reporter: Alexey Popov
Assignee: Alexey Popov


https://ci.ignite.apache.org/viewLog.html?buildId=1173105&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgnitePlatformNetLongRunning

Test(s) failed.   Some tasks should have failed.
  Expected: True
  But was:  False

   at NUnit.Framework.Assert.That(Object actual, IResolveConstraint expression, 
String message, Object[] args)
   at 
Apache.Ignite.Core.Tests.Client.ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress()
 in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Client\ClientConnectionTest.cs:line
 277




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Welcome

[Yandex Mail]

Hello Ignite Community!



My name is Denis Garus. I want to contribute to Apache Ignite.

I would like to start with ticket
https://issues.apache.org/jira/browse/IGNITE-8111.

My Jira ID: garus.d.g



Thanks!



---
Это сообщение проверено на вирусы антивирусом Avast.
https://www.avast.com/antivirus

[jira] [Created] (IGNITE-8128) PDS Indexing suite timeout: failure handler incomatibility with test code

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-8128:
--

 Summary: PDS Indexing suite timeout: failure handler 
incomatibility with test code 
 Key: IGNITE-8128
 URL: https://issues.apache.org/jira/browse/IGNITE-8128
 Project: Ignite
  Issue Type: Test
  Components: persistence
Reporter: Dmitriy Pavlov
Assignee: Pavel Kovalenko


Ignite PDS Indexing [ tests 0 TIMEOUT , Exit Code warn 9 ] 
No fail rate info, probably new failure or suite critical failure  
IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALErrorWithoutMmap (last 
started) More >> 
 Thread Dump 
{noformat}
[06:06:21]W:[org.apache.ignite:ignite-indexing] [2018-04-03 
03:06:21,536][ERROR][wal-write-worker%file.IgnitePdsDiskErrorsRecoveringTest0][IgniteTestResources]
 Critical failure. Will be handled accordingly to configured handler [hnd=class 
o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable to 
write]] 
[06:06:21]W:[org.apache.ignite:ignite-indexing] [2018-04-03 
03:06:21,539][ERROR][test-runner-#29388%file.IgnitePdsDiskErrorsRecoveringTest%][IgniteTestResources]
 Critical failure. Will be handled accordingly to configured handler [hnd=class 
o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable to 
write]] 
{noformat}

https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePdsIndexing&branch=%3Cdefault%3E&tab=buildTypeStatusDiv




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3741: IGNITE-8128 Use StopNodeFailureHandler in tests w...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8128 Use StopNodeFailureHandler in tests where required.



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

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

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

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


commit 549ccdfe97c0d0a2e48ca3bb98ed7fcbbaae67b1
Author: Pavel Kovalenko 
Date:   2018-04-03T13:40:42Z

IGNITE-8128 Use StopNodeFailureHandler in tests where required.




---

Re: Welcome

[Alexey Goncharuk]

Hello Denis,

Welcome to the Ignite community! I have added you to the contributors list,
you should be able to assign the issue now.

Thanks,
AG

2018-04-03 16:08 GMT+03:00 Yandex Mail :

> Hello Ignite Community!
>
>
>
> My name is Denis Garus. I want to contribute to Apache Ignite.
>
> I would like to start with ticket
> https://issues.apache.org/jira/browse/IGNITE-8111.
>
> My Jira ID: garus.d.g
>
>
>
> Thanks!
>
>
>
> ---
> Это сообщение проверено на вирусы антивирусом Avast.
> https://www.avast.com/antivirus
>

Re: MTCGA: Hot failures

[Dmitry Pavlov]

Hi Igniters,

Thanks to all who assigned tickets. All excepting Data Structure failures
and https://issues.apache.org/jira/browse/IGNITE-8089 is now assigned.

Your contributions will help to improve TeamCity resutls so we could avoid
new failures introduction.

Sincerely,
Dmitriy Pavlov

пт, 30 мар. 2018 г. в 18:43, Dmitry Pavlov :

>
> Hi Igniters,
>
> Let me share some updates on test failures:
>
>   Basic [2] https://issues.apache.org/jira/browse/IGNITE-8079  - probably
> the same problem with https://issues.apache.org/jira/browse/IGNITE-7708
>
>   Binary Objects (Simple Mapper Basic)
> 
> - Waiting for fix, https://issues.apache.org/jira/browse/IGNITE-8058, -
> assigned.
>
>  Ignite Data Structures
> 
>  - I hope Anton V. Will take a look to
>
>IgniteCacheDataStructuresSelfTestSuite:
> IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1 (master fail
> rate 12,4%)
> 
>
>IgniteCacheDataStructuresSelfTestSuite:
> IgniteClientDataStructuresTest.testSequence (master fail rate 11,9%)
> 
>
>IgniteCacheDataStructuresSelfTestSuite:
> IgniteClientDataStructuresTest.testReentrantLock (master fail rate 10,3%)
> 
>
>  Ignite Start Nodes
> 
> test ticket https://issues.apache.org/jira/browse/IGNITE-8085 created,
> feel free to assign it to yourself.
>
>
>  Activate | Deactivate Cluster
> 
>
>
> https://issues.apache.org/jira/browse/IGNITE-8086 - test timeouts,
> unassigned
>
> https://issues.apache.org/jira/browse/IGNITE-8088 - flaky assertions for
> cahe presence validation
>
> https://issues.apache.org/jira/browse/IGNITE-8089 - Cache group presence
> assertion failed in (PM) exchange in
> IgniteStandByClientReconnectToNewClusterTest
>
> Last one it is 100th MTCGA ticket with empty resolution (opened).
>
> Committers, please identify related to your maintained features tickets
> and assign it to you.
>
> Sincerely,
>
> Dmitriy Pavlov
>
>
> ср, 28 мар. 2018 г. в 13:21, Anton Vinogradov :
>
>> Dmitriy,
>>
>> Have no chances to check TC this week, may be later.
>>
>> 2018-03-28 13:16 GMT+03:00 Dmitry Pavlov :
>>
>> > Dmitriy, defenetely at first stage we need issues to be created.
>> > summary= TestN failed
>> > labels=MakeTeamCityGreenAgain
>> > text=Desctiption of failure.
>> >
>> > I hope Igniters could provide assitance in creation of issues related to
>> > these failures.
>> >
>> > Anton,
>> >
>> > as expert in Data Structures could you please check failures in DS
>> suite?
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> > ср, 28 мар. 2018 г. в 3:15, Dmitriy Setrakyan :
>> >
>> > > Dmitriy,
>> > >
>> > > I think it would make sense to create a ticket for every single one of
>> > > these, or at least try to group them in to several tickets. What do
>> you
>> > > think?
>> > >
>> > > D.
>> > >
>> > > On Tue, Mar 27, 2018 at 5:17 AM, Dmitry Pavlov > >
>> > > wrote:
>> > >
>> > > > Hi Igniters,
>> > > >
>> > > > I’ve filtered report of master failures to find most failing tests.
>> > > > Following is 5 failing suites and their frequently failed test with
>> > links
>> > > > to TC.
>> > > >
>> > > > Igniters, please reply who would like to pick up
>> > > >
>> > > > - test failures context research,
>> > > >
>> > > > - tickets creation
>> > > >
>> > > > - and (the best option) fixing these fails.
>> > > >
>> > > > Sincerely,
>> > > >
>> > > > Dmitriy Pavlov
>> > > >
>> > > >   Basic [2]
>> > > > > > > >
>> IgniteTests24Java8_Basic2&branch=%3Cdefault%3E&tab=buildTypeStatusDiv>
>> > > >
>> > > > IgniteServiceConfigVariationsFullApiTestSuite:
>> > > > IgniteServiceConfigVariationsFullApiTest.testDeploy (master fail
>> rate
>> > > > 23,1%)
>> > > > > > > > IgniteTests24Java8&testNameId=-6001195444279699378&branch=%
>> > > > 3Cdefault%3E&tab=testDetails>
>> > > >
>> > > > IgniteServiceConfigVariationsFullApiTestSuite:
>> > > > IgniteServiceConfigVariationsFullApiTest.testClusterSingletonDeploy
>> > > > (master
>

Contribute to Apache Ignite

[Anton Kurbanov]

Hello Ignite Community!

My name is Anton Kurbanov and I want to contribute to Apache Ignite. 

I would like to begin with ticket
https://issues.apache.org/jira/browse/IGNITE-8110.

My Jira ID is: antkr

Best regards,
Anton

[GitHub] ignite pull request #3708: IGNITE-4193: Added transaction support for ODBC

[isapego]

Github user isapego closed the pull request at:

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


---

Re: Contribute to Apache Ignite

[Alexey Goncharuk]

Hello Anton,

Welcome to the Ignite community! I've added you to the list, please go
ahead with the ticket!

Thanks,
AG

2018-04-03 17:59 GMT+03:00 Anton Kurbanov :

> Hello Ignite Community!
>
> My name is Anton Kurbanov and I want to contribute to Apache Ignite.
>
> I would like to begin with ticket
> https://issues.apache.org/jira/browse/IGNITE-8110.
>
> My Jira ID is: antkr
>
> Best regards,
> Anton
>
>
>

[GitHub] ignite pull request #3741: IGNITE-8128 Use StopNodeFailureHandler in tests w...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: abbrevation rules plugin

[Vyacheslav Daradur]

Hi, Igniters!

I got into the task [1] in agreement with Dmitry.

I’ve prepared the PR [2] with following changes:
- added Apache 2.0 license to the header of each file
- replaced prefix ‘Grid’ by ‘Ignite’ in class names
- added README.md with a simple description
- changed version 2.6.3 -> 3.0.0 because the project has own GitHub
releases tab and completely new versioning isn't preferable IMO

Also, I’ve built new artifact and tested it, it works well.

Am I understood the task correct?
If not, please share your notes I will fix them shortly.

As far as I understand someone of GridGain employee should confirm the
plugin's code's donation. It’d be great to confirm that by corporate
email.


[1] https://issues.apache.org/jira/browse/IGNITE-5698
[2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/1


On Thu, Jul 6, 2017 at 12:30 PM, Dmitry Pavlov  wrote:
> Hi Dmitriy, Denis,
>
> Thank you for your effort to find out solution.
> It sound good for me, I have assigned IGNITE-5698 to myself.
>
> Best Regards,
> Dmitriy Pavlov
>
>
> чт, 6 июл. 2017 г. в 2:45, Denis Magda :
>
>> Dmitriy P.,
>>
>> Does it sound good to you? If yes, please make sure the plugin is
>> available via a public GitHub repo and refer to it from the doc.
>>
>> —
>> Denis
>>
>> > On Jul 5, 2017, at 4:43 PM, Dmitriy Setrakyan 
>> wrote:
>> >
>> > On Wed, Jul 5, 2017 at 4:41 PM, Denis Magda  wrote:
>> >
>> >> Ok, what if we make sure the plugin is available on GitHub (not Ignite)
>> >> and give a link to it on the documentation page? This seems to be the
>> >> easiest way to handle the topic.
>> >
>> >
>> > I think this will work.
>>
>>



-- 
Best Regards, Vyacheslav D.

Re: abbrevation rules plugin

[Anton Vinogradov]

Awesome!

Dmitriy,
please confirm donation and apply the patch.

BTW, we can relocate plugin to apache repo like we did for release scripts
[1].

[1] https://github.com/apache/ignite-release


2018-04-03 19:28 GMT+03:00 Vyacheslav Daradur :

> Hi, Igniters!
>
> I got into the task [1] in agreement with Dmitry.
>
> I’ve prepared the PR [2] with following changes:
> - added Apache 2.0 license to the header of each file
> - replaced prefix ‘Grid’ by ‘Ignite’ in class names
> - added README.md with a simple description
> - changed version 2.6.3 -> 3.0.0 because the project has own GitHub
> releases tab and completely new versioning isn't preferable IMO
>
> Also, I’ve built new artifact and tested it, it works well.
>
> Am I understood the task correct?
> If not, please share your notes I will fix them shortly.
>
> As far as I understand someone of GridGain employee should confirm the
> plugin's code's donation. It’d be great to confirm that by corporate
> email.
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-5698
> [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/1
>
>
> On Thu, Jul 6, 2017 at 12:30 PM, Dmitry Pavlov 
> wrote:
> > Hi Dmitriy, Denis,
> >
> > Thank you for your effort to find out solution.
> > It sound good for me, I have assigned IGNITE-5698 to myself.
> >
> > Best Regards,
> > Dmitriy Pavlov
> >
> >
> > чт, 6 июл. 2017 г. в 2:45, Denis Magda :
> >
> >> Dmitriy P.,
> >>
> >> Does it sound good to you? If yes, please make sure the plugin is
> >> available via a public GitHub repo and refer to it from the doc.
> >>
> >> —
> >> Denis
> >>
> >> > On Jul 5, 2017, at 4:43 PM, Dmitriy Setrakyan 
> >> wrote:
> >> >
> >> > On Wed, Jul 5, 2017 at 4:41 PM, Denis Magda 
> wrote:
> >> >
> >> >> Ok, what if we make sure the plugin is available on GitHub (not
> Ignite)
> >> >> and give a link to it on the documentation page? This seems to be the
> >> >> easiest way to handle the topic.
> >> >
> >> >
> >> > I think this will work.
> >>
> >>
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Breaking change in JDBC connection string format

[Denis Magda]

Vladimir, Taras,

Will "@" work for us as the delimiter? I would agree with Andrey to reuse
this approach for the thin client.

As for the breaking changes, if update the delimiter for the next driver
version and make sure that version understands 2 delimiters for some time
(& and the new one), then this would be ideal and not disrupting.

--
Denis

On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura  wrote:

> Hi,
>
> We've been solve this problem during JDBC2 driver implementation. And
> I don't know any complains about connection string format. Why we can
> just use the same approach? [1]
>
> [1] https://issues.apache.org/jira/browse/IGNITE-1250?
> focusedCommentId=14706511&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
>
> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
>  wrote:
> > Hello!
> >
> > I think semicolon is the way to go, since round brackets are often
> > interpreted by shells and will need escaping on their own. Let's get rid
> of
> > & and ?.
> >
> > jdbc:ignite:thin://host:port/schema:param1=val1:param2=val2
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-04-03 11:30 GMT+03:00 Vladimir Ozerov :
> >
> >> Igniters,
> >>
> >> Thanks to Alex Kuznetsov, we revealed serious usability issue in our
> thin
> >> JDBC driver - we user ampersand character to delimit properties:
> >>
> >> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
> >>
> >> This leads to multiple problems:
> >> 1) This format is unusable from many console environments and require
> >> special escaping (PowerShell, bash)
> >> 2) Also this causing issues when writing connection string is passed to
> >> some 3rd-party applications as sometimes they cannot escape it as well.
> >>
> >> I performed investigation on how other vendors do that. Bottom line -
> >> nobody use ampersand. Instead semicolon or parentheses are used:
> >>
> >> jdbc:ignite:thin://host:port/schema?param1=val1¶m2=val2
> >> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
> >>
> >> I propose to do a breaking change in AI 2.5 and change the format to
> >> *parentheses*. This would be a disruptive experience for existing users,
> >> but in the long term benefits will outweight. Also remember that we do
> not
> >> offered officially any backward compatibility for our JDBC driver.
> >>
> >> Alternatively we may allow users to use previous format with help of
> system
> >> property or environment variable.
> >>
> >> Thoughts?
> >>
> >> Vladimir.
> >>
>

Re: abbrevation rules plugin

[Dmitry Pavlov]

Thank you, Vyaceslav.

Excellent patch, I've applied PR to
https://github.com/dspavlov/ignite-abbrev-plugin

If we want code style will be learned by all contributors, this donation is
unavoidable.

Dmitriy S,

what do you think?

Lets keep current code base in my github and add build and link to build to
wiki page
https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules .

Sincerely,
Dmitriy Pavlov

вт, 3 апр. 2018 г. в 19:46, Anton Vinogradov :

> Awesome!
>
> Dmitriy,
> please confirm donation and apply the patch.
>
> BTW, we can relocate plugin to apache repo like we did for release scripts
> [1].
>
> [1] https://github.com/apache/ignite-release
>
>
> 2018-04-03 19:28 GMT+03:00 Vyacheslav Daradur :
>
> > Hi, Igniters!
> >
> > I got into the task [1] in agreement with Dmitry.
> >
> > I’ve prepared the PR [2] with following changes:
> > - added Apache 2.0 license to the header of each file
> > - replaced prefix ‘Grid’ by ‘Ignite’ in class names
> > - added README.md with a simple description
> > - changed version 2.6.3 -> 3.0.0 because the project has own GitHub
> > releases tab and completely new versioning isn't preferable IMO
> >
> > Also, I’ve built new artifact and tested it, it works well.
> >
> > Am I understood the task correct?
> > If not, please share your notes I will fix them shortly.
> >
> > As far as I understand someone of GridGain employee should confirm the
> > plugin's code's donation. It’d be great to confirm that by corporate
> > email.
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-5698
> > [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/1
> >
> >
> > On Thu, Jul 6, 2017 at 12:30 PM, Dmitry Pavlov 
> > wrote:
> > > Hi Dmitriy, Denis,
> > >
> > > Thank you for your effort to find out solution.
> > > It sound good for me, I have assigned IGNITE-5698 to myself.
> > >
> > > Best Regards,
> > > Dmitriy Pavlov
> > >
> > >
> > > чт, 6 июл. 2017 г. в 2:45, Denis Magda :
> > >
> > >> Dmitriy P.,
> > >>
> > >> Does it sound good to you? If yes, please make sure the plugin is
> > >> available via a public GitHub repo and refer to it from the doc.
> > >>
> > >> —
> > >> Denis
> > >>
> > >> > On Jul 5, 2017, at 4:43 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > >> wrote:
> > >> >
> > >> > On Wed, Jul 5, 2017 at 4:41 PM, Denis Magda 
> > wrote:
> > >> >
> > >> >> Ok, what if we make sure the plugin is available on GitHub (not
> > Ignite)
> > >> >> and give a link to it on the documentation page? This seems to be
> the
> > >> >> easiest way to handle the topic.
> > >> >
> > >> >
> > >> > I think this will work.
> > >>
> > >>
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: Breaking change in JDBC connection string format

[Dmitriy Setrakyan]

Vladimir, why can't we support both, the "&" and whatever other character
we choose? This way it will not be a breaking change.

D.

On Tue, Apr 3, 2018 at 1:30 AM, Vladimir Ozerov 
wrote:

> Igniters,
>
> Thanks to Alex Kuznetsov, we revealed serious usability issue in our thin
> JDBC driver - we user ampersand character to delimit properties:
>
> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
>
> This leads to multiple problems:
> 1) This format is unusable from many console environments and require
> special escaping (PowerShell, bash)
> 2) Also this causing issues when writing connection string is passed to
> some 3rd-party applications as sometimes they cannot escape it as well.
>
> I performed investigation on how other vendors do that. Bottom line -
> nobody use ampersand. Instead semicolon or parentheses are used:
>
> jdbc:ignite:thin://host:port/schema?param1=val1¶m2=val2
> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
>
> I propose to do a breaking change in AI 2.5 and change the format to
> *parentheses*. This would be a disruptive experience for existing users,
> but in the long term benefits will outweight. Also remember that we do not
> offered officially any backward compatibility for our JDBC driver.
>
> Alternatively we may allow users to use previous format with help of system
> property or environment variable.
>
> Thoughts?
>
> Vladimir.
>

Re: abbrevation rules plugin

[Dmitry Pavlov]

Anton, I also agree here.

Personal github repo is ok for very beginning of tool development, but
eventually apache repo is better.

вт, 3 апр. 2018 г. в 19:46, Anton Vinogradov :

> Awesome!
>
> Dmitriy,
> please confirm donation and apply the patch.
>
> BTW, we can relocate plugin to apache repo like we did for release scripts
> [1].
>
> [1] https://github.com/apache/ignite-release
>
>
> 2018-04-03 19:28 GMT+03:00 Vyacheslav Daradur :
>
> > Hi, Igniters!
> >
> > I got into the task [1] in agreement with Dmitry.
> >
> > I’ve prepared the PR [2] with following changes:
> > - added Apache 2.0 license to the header of each file
> > - replaced prefix ‘Grid’ by ‘Ignite’ in class names
> > - added README.md with a simple description
> > - changed version 2.6.3 -> 3.0.0 because the project has own GitHub
> > releases tab and completely new versioning isn't preferable IMO
> >
> > Also, I’ve built new artifact and tested it, it works well.
> >
> > Am I understood the task correct?
> > If not, please share your notes I will fix them shortly.
> >
> > As far as I understand someone of GridGain employee should confirm the
> > plugin's code's donation. It’d be great to confirm that by corporate
> > email.
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-5698
> > [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/1
> >
> >
> > On Thu, Jul 6, 2017 at 12:30 PM, Dmitry Pavlov 
> > wrote:
> > > Hi Dmitriy, Denis,
> > >
> > > Thank you for your effort to find out solution.
> > > It sound good for me, I have assigned IGNITE-5698 to myself.
> > >
> > > Best Regards,
> > > Dmitriy Pavlov
> > >
> > >
> > > чт, 6 июл. 2017 г. в 2:45, Denis Magda :
> > >
> > >> Dmitriy P.,
> > >>
> > >> Does it sound good to you? If yes, please make sure the plugin is
> > >> available via a public GitHub repo and refer to it from the doc.
> > >>
> > >> —
> > >> Denis
> > >>
> > >> > On Jul 5, 2017, at 4:43 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > >> wrote:
> > >> >
> > >> > On Wed, Jul 5, 2017 at 4:41 PM, Denis Magda 
> > wrote:
> > >> >
> > >> >> Ok, what if we make sure the plugin is available on GitHub (not
> > Ignite)
> > >> >> and give a link to it on the documentation page? This seems to be
> the
> > >> >> easiest way to handle the topic.
> > >> >
> > >> >
> > >> > I think this will work.
> > >>
> > >>
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: Memory usage per cache

[Denis Magda]

Dmitriy G., Alex G.,

Reminder. Still hope to get an answer to the question below.

--
Denis

On Fri, Mar 30, 2018 at 10:04 AM, Denis Magda  wrote:

> Dmitriy G., Alexey,
>
> What happens with CacheMetrics.getOffHeapAllocatedSize metric? Don't see
> it mentioned in the tickets.
>
>- Will it return a value of a respective cache group if the cache is
>the only one in the group.
>- What will it return if there are several caches in a group?
>
> --
> Denis
>
> On Fri, Mar 30, 2018 at 8:16 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>> Yes, I think we can maintain this metric inside lock ownership change
>> callbacks.
>>
>> 2018-03-30 17:34 GMT+03:00 Dmitriy Setrakyan :
>>
>> > I think "getLockedKeysCount" is better. Can we easily return this count
>> > without traversing all the transactions?
>> >
>> >
>> >
>> > On Fri, Mar 30, 2018 at 7:32 AM, Alexey Goncharuk <
>> > alexey.goncha...@gmail.com> wrote:
>> >
>> > > Dmitriy,
>> > >
>> > > getLockedKeys returns only the number of locked keys, not the keys
>> > > themselves. Looks like the method name is confusing, should we rename
>> it
>> > to
>> > > getLockedKeysNumber?
>> > >
>> > > --AG
>> > >
>> > > 2018-03-30 16:24 GMT+03:00 Dmitriy Setrakyan :
>> > >
>> > > > Dmitriy,
>> > > >
>> > > > For transactions, are these separate metrics for each transaction or
>> > > > aggregates for all of them? If these are aggregates, then methods
>> like
>> > > > "getLockedKeys" may produce a very large collection, which on top of
>> > > > everything else, will be very difficult to create.
>> > > >
>> > > > D.
>> > > >
>> > > > On Fri, Mar 30, 2018 at 2:04 AM, Dmitriy Govorukhin <
>> > > > dmitriy.govoruk...@gmail.com> wrote:
>> > > >
>> > > > > Folks,
>> > > > >
>> > > > > I created 2 Jira issue for new metrics. Also, I think they will be
>> > > > useful.
>> > > > > Let's discuss in comments.
>> > > > >
>> > > > > - Add new metrics for data storage IGNITE-8078
>> > > > > 
>> > > > > - Implement new JMX metrics for transactions IGNITE-8077
>> > > > > 
>> > > > >
>> > > > > On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda 
>> > > wrote:
>> > > > >
>> > > > > > Alexey,
>> > > > > >
>> > > > > > If to rephrase it differently, if a cache/table belongs to a
>> single
>> > > > cache
>> > > > > > group then its entries will never be mixed with the entries of
>> > > another
>> > > > > > caches/tables in both data and index pages. Please confirm that
>> my
>> > > > > > statement is correct. Also, does that counter accumulates size
>> of
>> > > > > > BinaryObjects or the whole data/index pages?
>> > > > > >
>> > > > > > Finally, do you plan to rework CacheMetrics.
>> > getOffHeapAllocatedSize
>> > > > > method
>> > > > > > for this purpose? (btw, to my knowledge the method is broken at
>> the
>> > > > > moment
>> > > > > > and returns 0).
>> > > > > >
>> > > > > > --
>> > > > > > Denis
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
>> > > > > > alexey.goncha...@gmail.com> wrote:
>> > > > > >
>> > > > > > > Denis,
>> > > > > > >
>> > > > > > > Currently there is an easy way to add per-cache-group metrics
>> for
>> > > > data
>> > > > > > and
>> > > > > > > index pages. There is an internal counter, but it is not
>> > published
>> > > as
>> > > > > an
>> > > > > > > MBean metric, we will do this as a part of IEP-6.
>> > > > > > >
>> > > > > > > As for the per-cache metrics, this can be implemented, but it
>> > will
>> > > > > take a
>> > > > > > > significantly greater effort and most likely will affect
>> > > performance.
>> > > > > As
>> > > > > > > Andrey noted, when two caches share the same cache group,
>> > multiple
>> > > > > > entries
>> > > > > > > may be written to the same page, this needs special handling.
>> I
>> > > > suggest
>> > > > > > we
>> > > > > > > first start with per-cache-group metrics and then, if there is
>> > high
>> > > > > > demand,
>> > > > > > > start thinking about per-cache metrics.
>> > > > > > >
>> > > > > > > --AG
>> > > > > > >
>> > > > > > > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <
>> stku...@gmail.com>:
>> > > > > > >
>> > > > > > > > I apologize for the previous message sent in hurry. It's
>> > > imposible
>> > > > to
>> > > > > > > > measure the difference between 'precise' and 'estimated'
>> page
>> > > > memory
>> > > > > > > usage
>> > > > > > > > per cache unless we fully implement approach 2. Current
>> model
>> > > > allows
>> > > > > to
>> > > > > > > > store objects from several caches in a single page.
>> > > > > > > >
>> > > > > > > > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <
>> stku...@gmail.com
>> > >:
>> > > > > > > >
>> > > > > > > > > Denis,
>> > > > > > > > >
>> > > > > > > > > I'll need to conduct some experiments to estimate the
>> > > difference.
>> > > > > And
>> > > > > > > the
>> > > > > > > > > answer will depend on numerous parameters: object si

[GitHub] ignite pull request #3742: IGNITE-8110

[antkr]

GitHub user antkr opened a pull request:

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

IGNITE-8110

Fixed ms to nanos transformation.

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

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

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

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


commit f901b799710fda853b9298ff4911b018400a8ceb
Author: Anton Kurbanov 
Date:   2018-04-03T14:32:57Z

IGNITE-8110 fixed transformation of cache flush frequency from ms into nanos

commit 85db60395ac1fbada93ae0fc6e3030dc2d3227eb
Author: Anton Kurbanov 
Date:   2018-04-03T16:58:55Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-8110




---

Re: Breaking change in JDBC connection string format

[Andrey Gura]

Denis,

actually params (key-value pairs) are separated by colon in provided
JIRA issue comment.

On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda  wrote:
> Vladimir, Taras,
>
> Will "@" work for us as the delimiter? I would agree with Andrey to reuse
> this approach for the thin client.
>
> As for the breaking changes, if update the delimiter for the next driver
> version and make sure that version understands 2 delimiters for some time
> (& and the new one), then this would be ideal and not disrupting.
>
> --
> Denis
>
> On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura  wrote:
>
>> Hi,
>>
>> We've been solve this problem during JDBC2 driver implementation. And
>> I don't know any complains about connection string format. Why we can
>> just use the same approach? [1]
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-1250?
>> focusedCommentId=14706511&page=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
>>
>> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
>>  wrote:
>> > Hello!
>> >
>> > I think semicolon is the way to go, since round brackets are often
>> > interpreted by shells and will need escaping on their own. Let's get rid
>> of
>> > & and ?.
>> >
>> > jdbc:ignite:thin://host:port/schema:param1=val1:param2=val2
>> >
>> > --
>> > Ilya Kasnacheev
>> >
>> > 2018-04-03 11:30 GMT+03:00 Vladimir Ozerov :
>> >
>> >> Igniters,
>> >>
>> >> Thanks to Alex Kuznetsov, we revealed serious usability issue in our
>> thin
>> >> JDBC driver - we user ampersand character to delimit properties:
>> >>
>> >> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
>> >>
>> >> This leads to multiple problems:
>> >> 1) This format is unusable from many console environments and require
>> >> special escaping (PowerShell, bash)
>> >> 2) Also this causing issues when writing connection string is passed to
>> >> some 3rd-party applications as sometimes they cannot escape it as well.
>> >>
>> >> I performed investigation on how other vendors do that. Bottom line -
>> >> nobody use ampersand. Instead semicolon or parentheses are used:
>> >>
>> >> jdbc:ignite:thin://host:port/schema?param1=val1¶m2=val2
>> >> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
>> >>
>> >> I propose to do a breaking change in AI 2.5 and change the format to
>> >> *parentheses*. This would be a disruptive experience for existing users,
>> >> but in the long term benefits will outweight. Also remember that we do
>> not
>> >> offered officially any backward compatibility for our JDBC driver.
>> >>
>> >> Alternatively we may allow users to use previous format with help of
>> system
>> >> property or environment variable.
>> >>
>> >> Thoughts?
>> >>
>> >> Vladimir.
>> >>
>>

Re: Timeline for support of compute functions by thin clients

[Valentin Kulichenko]

Dmitry,

I just think that it's natural to have this functionality and that it would
drastically increase flexibility of thin client. Multiple requests from
users (one of them in this thread) seem to confirm this. At the same time,
I don't see much technical challenge here (like with near caches or
continuous queries for example), and therefore don't see why we should be
against this features.

Can you please elaborate on security risks? What exactly do you have in
mind?

-Val

On Mon, Apr 2, 2018 at 9:40 PM, Dmitriy Setrakyan 
wrote:

> Val, my preference would be not to have compute functionality on thin
> clients, as it would introduce extra security risk.
>
> Any particular reason why you are asking for this feature?
>
> ⁣D.​
>
> On Apr 2, 2018, 8:47 PM, at 8:47 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> >Folks,
> >
> >Any other thoughts on this? Should we create tickets for compute
> >support if
> >there are no objections?
> >
> >-Val
> >
> >On Thu, Mar 22, 2018 at 4:27 PM, Valentin Kulichenko <
> >valentin.kuliche...@gmail.com> wrote:
> >
> >> I agree that compute and services functionality is important for thin
> >> client. It doesn't seem to be very hard to implement, but would
> >provide
> >> much better flexibility, as users would be able to do remote
> >invocation of
> >> arbitrary code, use collocated processing, etc. Having an ability to
> >do
> >> this from a thin client without joining the topology is a huge
> >advantage.
> >>
> >> -Val
> >>
> >> On Fri, Mar 16, 2018 at 4:00 AM, Vladimir Ozerov
> >
> >> wrote:
> >>
> >>> Denis,
> >>>
> >>> From client perspective any compute task is also request - response.
> >This
> >>> doesn't distinguish compute from any other API anyhow. There are no
> >>> problem
> >>> to add closures, tasks, services, etc.. What is really difficult is
> >>> components requiring non-trivial thread interaction and complex
> >request
> >>> workflows. E.g. streaming, COPY command, continuous queries, events.
> >>>
> >>> On Thu, Mar 15, 2018 at 10:25 PM, Denis Magda 
> >wrote:
> >>>
> >>> > Pavel,
> >>> >
> >>> > I just don't see a substantial reason why we need to support the
> >>> > compute APIs.
> >>> >
> >>> > As you properly mentioned, it's not easy to copy all the APIs and,
> >>> again,
> >>> > for what. It's right that the thin client allows decoupling .NET
> >from
> >>> JVM,
> >>> > but its implementation won't be more performant than the regular
> >>> client's
> >>> > one.
> >>> >
> >>> > So, personally, a thin client (.NET, Node.JS, Java, Python, etc.)
> >is a
> >>> > lightweight connection to the cluster that supports classic
> >>> client-server
> >>> > request-response operations. If someone needs more (compute,
> >services,
> >>> > streaming, ML), then go for the regular client which is
> >battle-tested
> >>> and
> >>> > available for usage.
> >>> >
> >>> > --
> >>> > Denis
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Mar 14, 2018 at 1:33 PM, Pavel Tupitsyn
> >
> >>> > wrote:
> >>> >
> >>> > > Hi Denis,
> >>> > >
> >>> > > > There are no any plans for that level of support
> >>> > > Why do you think so?
> >>> > > We already have ScanQuery with filter in .NET Thin Client, which
> >>> involves
> >>> > > remote code execution on server nodes.
> >>> > > It is quite similar to Compute.Broadcast and such.
> >>> > >
> >>> > > Thanks,
> >>> > > Pavel
> >>> > >
> >>> > >
> >>> > > On Wed, Mar 14, 2018 at 11:32 PM, Denis Magda
> >
> >>> wrote:
> >>> > >
> >>> > > > Raymond,
> >>> > > >
> >>> > > > Then I would suggest you keep using the regular .NET client
> >that
> >>> > supports
> >>> > > > and optimized for computations. Is there any reason why you
> >can't
> >>> use
> >>> > the
> >>> > > > regular one?
> >>> > > >
> >>> > > > --
> >>> > > > Denis
> >>> > > >
> >>> > > > On Wed, Mar 14, 2018 at 12:53 PM, Raymond Wilson <
> >>> > > > raymond_wil...@trimble.com
> >>> > > > > wrote:
> >>> > > >
> >>> > > > > Hi Denis,
> >>> > > > >
> >>> > > > > We are using Ignite.Net and are planning to use 2.4 + .Net
> >Core +
> >>> > thin
> >>> > > > > client support to enable lightweight containerisable
> >services that
> >>> > > > interact
> >>> > > > > with the main Ignite compute grid.
> >>> > > > >
> >>> > > > > These work flows are less about Get/Put style semantics, and
> >more
> >>> > about
> >>> > > > > using grid compute.
> >>> > > > >
> >>> > > > > Eg: Here's an example where a client context asks a remote
> >>> context to
> >>> > > > > render
> >>> > > > > a bitmap tile in an ICompute:
> >>> > > > >
> >>> > > > > public Bitmap Execute(TileRenderRequestArgument arg)
> >>> > > > > {
> >>> > > > > IComputeFunc
> >func
> >>> =
> >>> > new
> >>> > > > > TileRenderRequestComputeFunc();
> >>> > > > >
> >>> > > > > return
> >>> > > > > _ignite.GetCluster().ForRemotes().GetCompute().Apply(func,
> >arg);
> >>> > > > > }
> >>> > > > >
> >>> > > > > In this example, the calling context here could be a
> >lightweight

[GitHub] ignite pull request #3743: Ignite 1.9.11.b2

[Mikhail1988]

GitHub user Mikhail1988 opened a pull request:

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

Ignite 1.9.11.b2



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

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

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

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


commit aba9bf9982c6eba8cb57d64e6b1090914b8d020e
Author: Andrey V. Mashenkov 
Date:   2017-06-30T08:30:20Z

Merge branch 'ignite-1.8.8' into ignite-1.9.4

commit a4fc555b118d91ec0348154b88764f010dbbae52
Author: nikolay_tikhonov 
Date:   2017-06-30T11:38:54Z

Fixed "IGNITE-5424 GridServiceProxy does not unwraps exception message from 
InvocationTargetException." This closes #2168

Signed-off-by: nikolay_tikhonov 

commit 62876fefc8dbd334db9dc6741c2bc91b3409343d
Author: Andrey V. Mashenkov 
Date:   2017-06-30T11:45:18Z

IGNITE-5473 partial fix: Create ignite troubleshooting logger.

commit 75c442a8309d554f6894f30f63ed0b964e7a0aa1
Author: Slava Koptilin 
Date:   2017-06-26T12:37:26Z

Backported IGNITE-5076: improved multi-threaded start of nodes.

commit 551923e1e5139c484fcb716e7f10907fa71021d9
Author: nikolay_tikhonov 
Date:   2017-06-30T11:38:54Z

Backported "IGNITE-5424 GridServiceProxy does not unwraps exception message 
from InvocationTargetException."

commit 752b1368adbb5c77b5d5caca3c07a72decff5111
Author: Andrey V. Mashenkov 
Date:   2017-06-30T11:45:18Z

IGNITE-5473 partial fix: Create ignite troubleshooting logger.

commit fd3f947a1b49144a5b11aaf3f1a1b7a28ba961fd
Author: Andrey V. Mashenkov 
Date:   2017-06-30T15:36:50Z

Fixed service deployment tests.

commit 6ab152a85f70c05847823f65f8e095ab9eb6b1f7
Author: sboikov 
Date:   2017-04-19T09:46:31Z

Attempt to fix awaitPartitionMapExchange: wait for last exchange completion 
to avoid races with cache destroy.

(cherry picked from commit d383484)

commit 1525c6cf2cb015289392eb54fec4029e9b53b438
Author: Andrey V. Mashenkov 
Date:   2017-06-30T15:36:50Z

Fixed service deployment tests.

commit a24ca24dd7aaa34707d74a4e660d769d3d5b0ed8
Author: sboikov 
Date:   2017-04-19T09:46:31Z

Attempt to fix awaitPartitionMapExchange: wait for last exchange completion 
to avoid races with cache destroy.

(cherry picked from commit d383484)

commit 05fac7e8a0bf9e08cd758bed7bd35ec85b914592
Author: Evgenii Zhuravlev 
Date:   2017-04-19T11:01:21Z

Backported IGNITE-4925 Fix 
IgniteCacheBinaryObjectsScanSelfTest.testScanNoClasses - Fixes #1750.

(cherry picked from commit b47f29d)

commit ef0a874ceb5c8bfa53e16337f6fd1699afaf2a39
Author: nikolay_tikhonov 
Date:   2017-06-30T17:39:01Z

Fixed CacheSerializableTransactionsTest#testTxConflictRemoveWithOldValue 
test.

Signed-off-by: nikolay_tikhonov 

commit 4dce965ea86374cba7265cb5d22e975aeac7d480
Author: nikolay_tikhonov 
Date:   2017-06-30T18:36:02Z

Fixed org.jsr107.tck.PutTest tests.

Signed-off-by: nikolay_tikhonov 

commit 32f1e394c222a6f4a2c111d6b6284c8626442b68
Author: Andrey V. Mashenkov 
Date:   2017-07-03T09:28:12Z

Merge branch 'ignite-1.8.8' into ignite-1.9.4

commit 50887fed508e03a8b7df32569afb6d84ab3eb670
Author: Igor Sapego 
Date:   2017-07-04T17:01:01Z

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

commit da290cee855ef45a90ad539515e039f2826a6c00
Author: Igor Sapego 
Date:   2017-07-05T10:21:12Z

IGNITE-5663: Fix for test

commit 024a01d6bf91b4f301c4aee7f4a747e810a9a30b
Author: nikolay_tikhonov 
Date:   2017-07-05T15:58:00Z

Merged 1.7.12 into 1.8.9

Signed-off-by: nikolay_tikhonov 

commit 3536a58982e4c264bb72b2ccc1953049d2b5c67f
Author: Alexey Kukushkin 
Date:   2017-07-05T16:36:41Z

IGNITE-4901 Decrease logging level for DataStremer retry

commit 6d3a3ff2d99697882232070e715928336a9180cd
Author: Alexey Kukushkin 
Date:   2017-07-05T17:05:02Z

Fixed merge conflicts

commit aedc6aa8b17a39a6460c4b7f69255cd07d635bfb
Author: nikolay_tikhonov 
Date:   2017-07-05T17:42:15Z

Merge branch 'ignite-1.7.12' into ignite-1.9.4

Signed-off-by: nikolay_tikhonov 

commit acfc400b22738fa46397d392f88d49614e687969
Author: nikolay_tikhonov 
Date:   2017-07-05T17:42:48Z

Merge branch 'ignite-1.7.12' into ignite-1.9.4

Signed-off-by: nikolay_tikhonov 

commit 8dea19ba41bb9eda16f47933b2c46a081116d5f7
Author: Andrey V. Mashenkov 
Date:   2017-07-06T09:02:07Z

Minor fix.

commit f208f434f944196d531a1b51066dfe8d6394d739
Author: Andrey V. Mashenkov 
Date:   2017-07-06T12:17:50Z

Test fixed "IGNITE-5390: Bug in 
IgniteCacheTxStoreSessionWriteBehindCoalescingTest."

commit 355a5283559c885f57c4557bba2c6d9170a9b5fc
Author: mcherkasov 
Date:   2017-06-30T17:23:55Z

IGNITE-5554 ServiceProcessor may process failed r

[GitHub] ignite pull request #3744: Gg 13379 dev

[kukushal]

GitHub user kukushal opened a pull request:

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

Gg 13379 dev



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

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

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

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


commit 4925ffc10ce8e8287980eaec38b587512568a302
Author: Alexey Goncharuk 
Date:   2018-01-17T12:26:03Z

IGNITE-7453 Use GridUnsafe.cleanDirectBuffer in PageSnapshot

commit bcd68a058683b2f17b7ac60471b6e7aab3e4f6de
Author: Pavel Tupitsyn 
Date:   2018-01-17T12:38:20Z

IGNITE-7301 .NET: Baseline topology

This closes #3352

commit 66b96316a7775ce8a6e2ff4475185d5929e4998b
Author: devozerov 
Date:   2018-01-17T12:54:17Z

Merge branch 'master' into ignite-2.4

commit 268481c1cf7fe57df24be130eb67c3e3a13afe01
Author: Alexey Goncharuk 
Date:   2018-01-17T13:50:34Z

IGNITE-7453 Use GridUnsafe.cleanDirectBuffer in WalStat

commit db0cd105719c8ae713b13b34d9dca0a8cd45d377
Author: Pavel Tupitsyn 
Date:   2018-01-17T14:05:25Z

IGNITE-6776 .NET: Thin client: Add SQL & LINQ example

This closes #3390

commit c214db879101aa5660e2a50b11cd20964c0bc114
Author: Andrey Gura 
Date:   2018-01-17T12:42:41Z

ignite-7450 FileWriteAheadLogManager always uses RandomAccessFileIOFactory 
now

commit 75c27d5e49d7458e46eb46e6f87a445c3f1320ea
Author: Alexey Kuznetsov 
Date:   2018-01-18T02:25:19Z

IGNITE-7274 Web Console: Support multiple statements on Queries screen.
(cherry picked from commit 1926783)

commit 36cc822935387b2150e690c29bc6992dca0563f7
Author: Dmitriy Shabalin 
Date:   2018-01-18T04:49:08Z

IGNITE-7306 Web Console: Fixed export data from tables.
(cherry picked from commit 1bb60ec)

commit d753298b4012894b56f5c9218325211cd84a21d5
Author: Peter Ivanov 
Date:   2018-01-18T06:18:53Z

IGNITE-7107 Apache Ignite RPM packages

* added changelog to package specification

This closes #3396

commit 63445893f1bc75dc9777184499f7eabc1d4e51b1
Author: Denis Mekhanikov 
Date:   2018-01-18T08:36:18Z

IGNITE-3935 Use PeerDeployAware for streamer transformer - Fixes #3378.

Signed-off-by: Alexey Goncharuk 

commit f3f9f2a24b23027cf0c835140322e41a788932ae
Author: Pavel Tupitsyn 
Date:   2018-01-18T09:05:12Z

IGNITE-7413 Fix SqlDmlExample

This closes #3389

commit 1daa7c41bf1460a4d9a2b0c26a7a317f2fca3fb7
Author: Alexey Kuznetsov 
Date:   2018-01-18T10:14:53Z

IGNITE-7461 UI tools: Actualized data storage configuration.
(cherry picked from commit 577e632)

commit cf0080210d24d9dd8b057f959446fac5f8a4ca01
Author: dpavlov 
Date:   2018-01-18T10:53:29Z

IGNITE-7380 Implemented pluggable Direct IO - Fixes #3226.

Signed-off-by: Alexey Goncharuk 

commit dd06d0bd7ef266bfbe156e858b312d1ac86e8982
Author: Pavel Tupitsyn 
Date:   2018-01-18T12:55:49Z

IGNITE-7465 .NET: Fix SqlDdlExample failure with standalone node

commit 57479ec564e1761716da3d5f9feb7a64c396a9f9
Author: Pavel Tupitsyn 
Date:   2018-01-18T13:45:54Z

.NET: Fix CacheLocalTest.TestTxDeadlockDetection

commit bd6be8a4653322905a3b63850c7e033ce3801ce5
Author: Pavel Tupitsyn 
Date:   2018-01-18T18:25:05Z

.NET: Thin client: Fix OP_BINARY_TYPE_GET schema passing format

commit 97564d160586d6d57d300937e6b8877994e35fc7
Author: rkondakov 
Date:   2018-01-19T08:24:51Z

IGNITE-6456: Ability to separately enable or disable JDBC, ODBC and thin 
client endpoints. This closes #3309.

commit d50274ca8875c9680c12e8786ac355a787ba95e0
Author: Yakov Zhdanov 
Date:   2018-01-18T17:57:17Z

Javadoc enhancements - added @see

commit cb2d3cf22388ab19fb2d34ae5bdfc8f1b608db75
Author: Dmitriy Govorukhin 
Date:   2018-01-18T14:14:26Z

IGNITE-7471 Use soft reference for checkpoint entry contents to avoid 
excessive memory usage

commit 3965923369870bb4e8e57e3332c1a1eb1e5f5ed3
Author: rkondakov 
Date:   2018-01-19T09:00:55Z

IGNITE-6772: SQL exception messages became more informative. This closes 
#3342.

commit ba68cb0fa87f776fcd0499d030c333f182611f41
Author: devozerov 
Date:   2018-01-19T09:03:52Z

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

commit b54c0c8786bd74aa0abb208f537c29f0c4be4b1e
Author: tledkov-gridgain 
Date:   2018-01-19T09:09:34Z

IGNITE-7248: JDBC: fixed schema resolution for streaming mode. This closes 
#3384.

commit 2f5997788ccff265a088921210f561985f640517
Author: Dmitriy Govorukhin 
Date:   2018-01-19T11:46:38Z

IGNITE-7471 fix npe

commit 7adce10750704cc50cbf54fa7020aa3b20da87cb
Author: Oleg Ignatenko 
Date:   2018-01-19T11:59:01Z

IGNITE-7454 Wrong package in IgniteExamplesMLTestSuite

this closes #3393

(cherry picked from commit cb1233a)

commit 25e91b60694c589d8bf50c63a0d8