[GitHub] ignite pull request #4511: IGNITE-9031: SpringCacheManager throws AssertionE...

[amirakhmedov]

GitHub user amirakhmedov opened a pull request:

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

IGNITE-9031: SpringCacheManager throws AssertionError during Spring i…

…nitialization

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

$ git pull https://github.com/amirakhmedov/ignite IGNITE-9031

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

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


commit e8c4b0f96c1ee107fbc024caebdd7323ee17bba4
Author: Amir Akhmedov 
Date:   2018-08-10T04:25:28Z

IGNITE-9031: SpringCacheManager throws AssertionError during Spring 
initialization




---

[GitHub] ignite pull request #4510: Ignite 2.5.1 p11 txfix

[ascherbakoff]

GitHub user ascherbakoff opened a pull request:

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

Ignite 2.5.1 p11 txfix



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

$ git pull https://github.com/gridgain/apache-ignite ignite-2.5.1-p11-txfix

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

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


commit b6ad3705c1e68683b72d2237037af66fea23a7ae
Author: devozerov 
Date:   2018-04-11T13:44:33Z

IGNITE-8148: JDBC thin: semicolon as delimiter for properties. This closes 
#3794.

commit e6c30e17c6f0f1852fa781078ee54ccf8c654846
Author: Pavel Kovalenko 
Date:   2018-04-11T11:12:50Z

IGNITE-7871 Check local join future on error. - Fixes #3793.

Signed-off-by: dpavlov 

commit 2769981a5df64f3cd0c38b7599c49580c66192fa
Author: Aleksey Plekhanov 
Date:   2018-04-11T15:24:51Z

IGNITE-6892 OOM should be covered by failure handling

Signed-off-by: Andrey Gura 

commit 687194461f445be9902752f38f873d321cde1d85
Author: Ilya Borisov 
Date:   2018-04-06T04:17:05Z

IGNITE-7996 Move configuration form templates.

(cherry picked from commit c2c03a9)

commit 9955728a72e0f9c11faa313a521d4566b5a93dc1
Author: Ilya Borisov 
Date:   2018-04-06T04:19:07Z

IGNITE-7996 Move config state module index.

(cherry picked from commit d5e0be0)

commit 536d8b2080b93505e67206a240385baced150674
Author: Ilya Borisov 
Date:   2018-04-06T04:20:13Z

IGNITE-7996 Use configuration.state for state registration only.

(cherry picked from commit 2800ef0)

commit a2d9f97c0ae77e81344849bc2c3cba2d3964cf01
Author: Ilya Borisov 
Date:   2018-04-06T04:20:39Z

IGNITE-7996 Rename configuration.state to states.

(cherry picked from commit 14dd2df)

commit 1d5f45b4eb900a3c4cc0bedb8919b35f2a0032c8
Author: Ilya Borisov 
Date:   2018-04-06T04:22:20Z

IGNITE-7996 Move configuration assets into page-configure module.

(cherry picked from commit d02e87b)

commit a5a83d211a572b8419866fabbc31975168157729
Author: Alexey Kuznetsov 
Date:   2018-04-12T04:21:23Z

IGNITE-7996 Merge with master.

commit dbf2d722b0563a9637cc72fe2fcdf3dbd07291fc
Author: devozerov 
Date:   2018-04-12T07:37:36Z

IGNITE-8042: .NET thin client: authentication support. This closes #3790.

commit 72259b01e0c6d72794eca4c28c9d9d848b0ff97f
Author: dmitrievanthony 
Date:   2018-04-12T08:16:22Z

IGNITE-8176: Integrate gradient descent linear regression with partition 
based dataset

this closes #3787

(cherry picked from commit df6356d)

commit f143ad0057ddb326f6d8199bf660b354913e6b61
Author: devozerov 
Date:   2018-04-12T12:02:57Z

IGNITE-8135: SQL: authentication for CREATE TABLE and DROP TABLE commands. 
This closes #3801.

commit 2c4a7a2e366d7308485ae5cc95d4b60e66b09589
Author: devozerov 
Date:   2018-04-12T12:13:51Z

IGNITE-8230: SQL: Fixed backup number propagation in CREATE TABLE command. 
This closes #3803.

commit 80f4340f61742988aaf9437eb08ed76644a1c8ca
Author: Pavel Kovalenko 
Date:   2018-04-12T11:29:43Z

IGNITE-7871 Fixed condition for cache partitions validation. - Fixes #3804.

Signed-off-by: dpavlov 

(cherry picked from commit 7a1d0ea)

commit dfe17074593d9d12cbab7b60aa73e73c37bbffb7
Author: Anton Kurbanov 
Date:   2018-04-12T17:31:50Z

IGNITE-8110 GridCacheWriteBehindStore.Flusher thread uses the wrong 
transformation from milliseconds to nanoseconds. - Fixes #3742.

Signed-off-by: dpavlov 

(cherry picked from commit adaedb4)

commit fe99497528cd040ab3b4d5f7bfc40e788393a5ed
Author: Andrey Kuznetsov 
Date:   2018-04-12T18:23:28Z

IGNITE-7983: NPE fixed in transactions

Signed-off-by: Andrey Gura 

commit 6a77dd8b182091fe4e38850098c6334597c14a6d
Author: zaleslaw 
Date:   2018-04-13T09:49:56Z

IGNITE-7829: Adopt kNN regression example to the new Partitioned Dataset

this closes #3798

(cherry picked from commit 8550d61)

commit 687ae653bd66745c49ba9f85a169e27191ddc16c
Author: Pavel Tupitsyn 
Date:   2018-04-13T09:28:19Z

IGNITE-8240 .NET: Use default scheduler when starting Tasks

This closes #3812

commit 0a64e4affae9ec2e16c3a99128985f6bd9c788cb
Author: Pavel Tupitsyn 
Date:   2018-04-13T09:44:17Z

IGNITE-8042: .NET: Thin client: authentication support - fix naming and 
inspections

commit 6072af825ca1507ad9d8143ca73e556539960e1d
Author: Pavel Tupitsyn 
Date:   2018-04-13T10:36:20Z

IGNITE-8042: .NET: Thin client: authentication support - fix 
TestAuthenticationEmptyCredentials

commit 78e7414cf568ef7e3f7567fdb74334012896b632
Author: Dmitriy Shabalin 
Date:   2018-04-13T10:55:02Z

IGNITE-8245 Fixed input appearance position with error.

(cherry picked from commit 56e3f43)

commit 

[GitHub] ignite pull request #4509: IGNITE-9243: G.allGrids() replaced by IgnitionEx....

[BiryukovVA]

GitHub user BiryukovVA opened a pull request:

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

IGNITE-9243: G.allGrids() replaced by IgnitionEx.allGridsx()



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

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

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

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






---

[jira] [Created] (IGNITE-9243) Avoid test suit hangs on stopAllGrids

[Vitaliy Biryukov (JIRA)]

Vitaliy Biryukov created IGNITE-9243:


 Summary: Avoid test suit hangs on stopAllGrids
 Key: IGNITE-9243
 URL: https://issues.apache.org/jira/browse/IGNITE-9243
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Vitaliy Biryukov
Assignee: Vitaliy Biryukov
 Fix For: 2.7


Tests sometimes hang on node join to topology, and this leads to the hang of 
the whole suite.

Solution: Do not wait for nodes to join a topology in *stopAllGrids* method.



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

[GitHub] ignite pull request #4508: Ignite 2.4.8.b1

[mcherkasov]

GitHub user mcherkasov opened a pull request:

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

Ignite 2.4.8.b1



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

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

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

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


commit 699561265ae616b5eb75897343be84d8c83be804
Author: Anton Kalashnikov 
Date:   2018-03-21T15:53:15Z

GG-13631 fix GridDhtPartitionDemandLegacyMessage

(cherry picked from commit ffbc56e)

commit 37c8033c72ac4fd1ec1e419ba68142c4fe11ad8b
Author: tledkov-gridgain 
Date:   2018-03-13T09:37:29Z

IGNITE-7860: JDBC thin: changed default socket buffer size to 64Kb. This 
closes #3600.

commit 130adcf29ddb61f8e9baa784b81454d3ed7c3b75
Author: Pavel Tupitsyn 
Date:   2018-01-26T08:48:14Z

IGNITE-7530 .NET: Fix GetAll memory usage and performance in binary mode

This closes #3436

commit 824004909b23a9a7d599500967af34103acb8c47
Author: Igor Sapego 
Date:   2018-01-30T12:56:17Z

IGNITE-6810: Implemented SSL support for ODBC.

This closes #3361

commit 82da0b5e9dc2ee2339c3fb1023e35d415bf1b647
Author: Pavel Kuznetsov 
Date:   2018-02-07T12:37:52Z

IGNITE-6217: Added benchmark to compare JDBC vs native SQL

This closes #2558

commit 701c6f141f6812ad7bc050a86266e696cf5863ed
Author: tledkov-gridgain 
Date:   2018-02-08T12:29:42Z

IGNITE-6625: JDBC thin: support SSL connection to Ignite node

This closes #3233

commit 2d729bf5c6f6fca9d07be2d57850642ba4b55004
Author: tledkov-gridgain 
Date:   2018-02-09T11:08:15Z

IGNITE-6625: SSL support for thin JDBC: additional fix test; change error 
message

commit 8994f847d7f5f15db73706d9210cdccb1cf3fb26
Author: devozerov 
Date:   2018-02-12T13:34:24Z

IGNITE-7003: Fixed faulty test 
WalModeChangeAdvancedSelfTest.testJoinCoordinator.

commit b142712264007d7397d1594541681a4a7e3d4b93
Author: Igor Sapego 
Date:   2018-02-26T12:02:07Z

IGNITE-7362: Fixed PDO ODBC integration issue

commit a2b2aee52cc65d01f2ecaf9462adc4bd368438ea
Author: Igor Sapego 
Date:   2018-02-28T10:23:12Z

IGNITE-7763: Fixed 32bit tests configurations to prevent OOM

This closes #3557

commit 652f3c4cdbaad40f5de25b06f0c13710aa7f2fd9
Author: Pavel Kuznetsov 
Date:   2018-03-13T12:46:36Z

IGNITE-7531: Data load benchmarks. This closes #3571.

commit 9337a53d9fcd62af87f6760080d350b43e275105
Author: tledkov-gridgain 
Date:   2018-03-16T11:38:38Z

IGNITE-7879: Fixed splitter logic for DISTINCT with subqueries. This closes 
#3634.

commit 7bec8b13cb373002d2a6b1b268d410338259bac2
Author: Igor Sapego 
Date:   2018-03-19T11:17:33Z

IGNITE-7811: Implemented connection failover for ODBC

This closes #3643

commit e512e5e0a2602df0ecfb69b2b5efabce836b04db
Author: Igor Sapego 
Date:   2018-03-20T10:37:02Z

IGNITE-7888: Implemented login timeout for ODBC.

This closes #3657

commit 211fca3a55e84b78ff0c1af04d91e25d6fc846c4
Author: devozerov 
Date:   2018-03-20T11:13:46Z

IGNITE-7984: SQL: improved deadlock handling in DML. This closes #3655.

commit bcd2888d27afe65f1a060e35b99a05ea420979c7
Author: Roman Guseinov 
Date:   2018-02-16T09:57:26Z

IGNITE-7192: Implemented JDBC support FQDN to multiple IPs

This closes #3439

commit d2659d0ec9f6e1a0b905fc7bf23b65fd5522c80a
Author: Alexander Paschenko 
Date:   2018-03-14T09:23:37Z

IGNITE-7253: JDBC thin driver: implemented streaming. This closes #3499. 
This closes #3591.

commit bc9018ef8b116f81b8e06d2ff7651ba2b6c7beae
Author: tledkov-gridgain 
Date:   2018-03-19T08:01:26Z

IGNITE-7029: JDBC thin driver now supports multiple IP addresses with 
transparent failover. This closes #3585.

commit 587022862fd5bdbb076ab6207ae6fd9bc7583c13
Author: Sergey Chugunov 
Date:   2018-03-16T16:24:17Z

IGNITE-7964 rmvId is stored to MetaStorage metapage during operations - 
Fixes #3645.

commit 006ef4d15e4faedb6dfce6ce9637602055b97293
Author: tledkov-gridgain 
Date:   2018-03-22T11:47:06Z

IGNITE-7436: Simple username/password authentication. This closes #3483.

commit 1c7f59c90514670e802d9d07544b00b7562fe6d2
Author: Pavel Tupitsyn 
Date:   2018-01-30T09:48:16Z

.NET: Fix build status icon in README

commit 162df61b305fccfc55e186d07351727f35b55179
Author: Pavel Tupitsyn 
Date:   2018-02-01T11:53:16Z

IGNITE-7561 .NET: Add IServices.GetDynamicServiceProxy

This closes #3457

commit 9a0328ebbc9d52f8e96898a384fa45743d2efa5b
Author: Pavel Tupitsyn 
Date:   2018-02-02T12:01:27Z

.NET: Update README regarding C++ interop and thin client

commit b804cfea51c87724b45b40de4fd58d300c049be1
Author: Pavel Tupitsyn 
Date:   2018-01-31T09:39:19Z

.NET: Suppress API parity check for SSL in 

[GitHub] ignite pull request #4507: Ignite 8926 9200

[mcherkasov]

GitHub user mcherkasov opened a pull request:

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

Ignite 8926 9200



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

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

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

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


commit e96c197f9f2f166930d8df435f1e9e9d2e9917ce
Author: Viktoria Abramova 
Date:   2018-08-03T13:00:22Z

IGNITE-9085 Web Console: Updated landing page images.

commit 0bf4340b8a6b627d4700bf0c8b8a417eb565e20e
Author: Ilya Lantukh 
Date:   2018-07-09T10:56:29Z

IGNITE-8926 : Fixed deadlock when binary metadata got updated while holding 
topology read lock.

commit fa75ec049fb0d19d570b732dc04cda1ff02da341
Author: Ilya Lantukh 
Date:   2018-07-09T11:12:50Z

IGNITE-8926 : Added license header.

commit 278a83d36d39004ecb9a1e6d5545835c9ca4ff1e
Author: Sergey Chugunov 
Date:   2018-07-09T14:44:17Z

IGNITE-8926 minor code style fixes

commit a7dfedd22bf91e1ef961cbc7ec3b2e9fabac39e2
Author: Ilya Lantukh 
Date:   2018-07-09T15:05:38Z

IGNITE-8926 : Fixed incorrect exception handling due to wrapping.

commit f2fe3e2267a68fb46a84196e78a0a8a662e343ad
Author: Ilya Lantukh 
Date:   2018-07-09T20:48:13Z

IGNITE-8926 : Fixed nested binary writers.

commit b3b2294a078558e13a85f4de61d5170a41c6c764
Author: Ilya Lantukh 
Date:   2018-07-12T11:54:18Z

IGNITE-8926 : Added topology lock check for all groups.

commit 11caa6f906faa532450b7c76eb5b710c843b05ef
Author: Ilya Lantukh 
Date:   2018-07-13T15:13:30Z

IGNITE-8926 : Added meaningful exception message.

commit 5fa10465a8b2509f98a2bb1e9620be6575dea612
Author: Alexey Goncharuk 
Date:   2018-07-16T09:22:41Z

IGNITE-8926 Fixed missed flag

commit 9230242e82c178319fb9f3b729e916abbfd472c8
Author: Ilya Lantukh 
Date:   2018-07-16T15:58:35Z

IGNITE-8926 : Fixed case with enum registration, added test.

commit b32d63f34cde6e5b8186d125c0a94d59316f2657
Author: Ilya Lantukh 
Date:   2018-07-16T16:52:18Z

IGNITE-8926 : Fixed compilation.

commit a5db25c7617a8f365895abe5270b1a8a29292fa0
Author: Ilya Lantukh 
Date:   2018-07-16T19:08:32Z

IGNITE-8926 : Fixed handling of Unregistered Class / BinaryType Exceptions 
in BPlusTree.invoke(...).

commit a047465422045b73f515b97e818248d54ea31bd9
Author: Ilya Lantukh 
Date:   2018-07-18T13:31:04Z

IGNITE-8926 : Fixed handling of invoke result.

commit 38f7ad1edacff6d321f1191a67abe9348019949b
Author: Ilya Lantukh 
Date:   2018-07-19T13:40:00Z

IGNITE-8926 : Enabled binary serialization on KeyCacheObject creation for 
IGFS caches.

commit 16794a4edb06bf03141841c5ef47122f9ea33208
Author: Ilya Lantukh 
Date:   2018-07-20T13:49:59Z

IGNITE-8926 : Fixed topLocked check.

commit e444e8b4f81964a65fbefbcacffe654808152d05
Author: Ilya Lantukh 
Date:   2018-07-25T11:18:51Z

IGNITE-8926 : Javadocs.

commit 067cea0bacd7cb53732b94a840ff0cbdc5c02b1d
Author: EdShangGG 
Date:   2018-08-03T14:36:49Z

IGNITE-9159 Basic 2 TC configuration is halted by failure handler - Fixes 
#4471.

Signed-off-by: Ivan Rakov 

commit 107be2a073854b96bf4c924ed322e22b43cad5a2
Author: pereslegin-pa 
Date:   2018-08-03T14:49:24Z

IGNITE-9148 Split Cache 3 TC configuration. - Fixes #4472.

Signed-off-by: Ivan Rakov 

commit a6db547f61b16d0edb3f78e8aa6734910203d2b4
Author: Maxim Muzafarov 
Date:   2018-08-03T14:56:05Z

IGNITE-9170 .NET: Test CachePartitionedAtomicNearEnabledTest.TestRebalance 
hangs - Fixes #4479.

Signed-off-by: Dmitriy Pavlov 

commit 02db06ae6a780c9441ce4cf4d32099b46106dbd1
Author: Pavel Kovalenko 
Date:   2018-08-03T15:01:50Z

IGNITE-9157 Optimize memory usage of data regions in tests - Fixes #4470.

Signed-off-by: Dmitriy Pavlov 

commit 8ebfbad3db6af5692dad95077122f4982d271f2b
Author: Vitaliy Biryukov 
Date:   2018-08-03T15:14:46Z

IGNITE-9134 ZookeeperDiscoverySpiTest#testLargeUserAttribute3 fails with 
OOME. - Fixes #4461.

Signed-off-by: Dmitriy Pavlov 

commit 26223420097bab8e557ab7de8d7afff71844ecb6
Author: Denis Mekhanikov 
Date:   2018-08-03T15:26:01Z

IGNITE-9043 Collections cannot be assigned to fields of type Object in 
BinaryObject - Fixes #4447.

Signed-off-by: Dmitriy Pavlov 

commit d110cc0d93fd21b6540a8f54c39bc732e4d0bf80
Author: Alexey Kuznetsov 
Date:   2018-08-06T03:29:54Z

IGNITE-9176 Web Console: Show error if failed to toggle cluster state.

commit a205ae7615885158f85443117388e3eaceaaae7c
Author: Anton Vinogradov 
Date:   2018-08-06T09:56:22Z

IGNITE-8446 Ability to check and completely fill transactions on creation

Signed-off-by: Anton Vinogradov 

commit 37f86a9de6e0fd0a9222961b9e6807c46762e802
Author: Ilya Borisov 
Date:   2018-08-06T11:02:56Z

IGNITE-9194 

Re: Benchmarking

[Pavel Kovalenko]

Igniters,

I would like to add that it would be very nice to have prepared scenarios
in packed docker images with docker-compose, to easily deploy and run it on
AWS environment. This will give the possibility to benchmark any changes
independently and fastly.

2018-08-09 18:51 GMT+03:00 Anton Vinogradov :

> Igniters,
>
> All critical code changes should be covered by benchmarks.
> Currently, community have no dedicated benchmarking service.
>
> Everyone can run yandstick locally, but this seems to be useless.
> You have to run cluster on 4 clients and 4 servers, at least.
>
> Currently it is not possible for me to perform benchmarking using 8+ real
> servers.
> Also, some automation requred to have reliable check of two branchs with
> one feature difference, since yardstick will provide you branch check, not
> a branches comparision.
>
> So, my question is:
> Is there anybody at community able to perform benchmarks on real hardware
> and already have automation to compare 2 branches?
>

Benchmarking

[Anton Vinogradov]

Igniters,

All critical code changes should be covered by benchmarks.
Currently, community have no dedicated benchmarking service.

Everyone can run yandstick locally, but this seems to be useless.
You have to run cluster on 4 clients and 4 servers, at least.

Currently it is not possible for me to perform benchmarking using 8+ real
servers.
Also, some automation requred to have reliable check of two branchs with
one feature difference, since yardstick will provide you branch check, not
a branches comparision.

So, my question is:
Is there anybody at community able to perform benchmarks on real hardware
and already have automation to compare 2 branches?

[jira] [Created] (IGNITE-9242) IgniteConfiguration.PeerAssemblyLoadingEnabled referenced in error message but doesn't exist

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-9242:
---

 Summary: IgniteConfiguration.PeerAssemblyLoadingEnabled referenced 
in error message but doesn't exist
 Key: IGNITE-9242
 URL: https://issues.apache.org/jira/browse/IGNITE-9242
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.6
Reporter: Ilya Kasnacheev


Instead, there is IgniteConfiguration.PeerAssemblyLoadingMode as per 
https://apacheignite-net.readme.io/docs/zero-deployment

Message should be amended.



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

Re: C++ Thin client. JVM dependency.

[Igor Sapego]

Hi,

This is not true, thin client does not depend on libignite. It only
depends on libignite-binary and libignite-common. Neither of them
depends on jvm.

Best Regards,
Igor


On Thu, Aug 9, 2018 at 4:16 PM Nikolay Izhikov  wrote:

> Hello, Igniters.
>
> I have a question from one of an early adopter of Ignite C++ thin client.
> Seems, that our C++ thin client depends on JVM lib.
>
> thin-client [1] depends on libignite, and libignite depends on jvm libs
> [2].
>
> Is that correct?
> Why do we need it?
> I thought that a thin client is a binary protocol with minimum
> dependencies.
> Do we have the plan to reduce that dependency?
>
> Igor, can you comment on this?
>
> [1]
> https://github.com/apache/ignite/blob/master/modules/platforms/cpp/thin-client/Makefile.am#L40
> [2]
> https://github.com/apache/ignite/blob/master/modules/platforms/cpp/core/Makefile.am#L30

Re: TDE: Upgrade Team City JDK

[Petr Ivanov]

Done


> On 9 Aug 2018, at 17:44, Nikolay Izhikov  wrote:
> 
> Petr.
> 
> Seems, now I has to put my tests in "Basic Tests With Persistence".
> Can you configure Team city so I can run "Basic Tests With Persistence" on 
> publicagent03_9091?
> 
> В Чт, 09/08/2018 в 16:35 +0300, Petr Ivanov пишет:
>> Yeap.
>> 
>> As it is disabled, it will not take tasks from queue automatically, but can 
>> be assigned tasks manually.
>> 
>> 
>>> On 9 Aug 2018, at 16:27, Nikolay Izhikov  wrote:
>>> 
>>> Hello, Petr.
>>> 
>>> I'm able to select thi agent for build.
>>> But it has "disabled" comment.
>>> 
>>> Is that OK?
>>> 
>>> https://ci.ignite.apache.org/viewQueued.html?itemId=1620053:0:153=queuedBuildOverviewTab
>>> 
>>> В Ср, 08/08/2018 в 17:44 +0300, Petr Ivanov пишет:
 Nikolay,
 
 
 I’ve updated publicagent03_9091 and tested all current builds for Ignite 
 Tests 2.4+ project for master branch.
 Please test your PR on this agent (select it when starting build) for 
 correct java configuration.
 
 If everything is OK — I’ll distribute this Java among all other agents.
 
 
 
> On 31 Jul 2018, at 22:18, Petr Ivanov  wrote:
> 
>> 8u111.
> 
> I’ve started the process of update, will try to accomplish by the end of 
> the week.
> 
> 
>> On 31 Jul 2018, at 21:26, Denis Magda  wrote:
>> 
>> Nikolay,
>> 
>> Do you need 8u111 and later? Or any JDK 8 works for you?
>> 
>> --
>> Denis
>> 
>> On Tue, Jul 31, 2018 at 6:55 AM Nikolay Izhikov  
>> wrote:
>> 
>>> Hello, Petr.
>>> 
 What JDK is required for running this build?
>>> 
>>> 8u111 and later.
>>> 
 I can filter agents with correct JDK for now.
>>> 
>>> Encryption tests are executed by following build plans:
>>> 
>>> * Basic 1
>>> * Binary Objects (Simple Mapper Basic)
>>> * Queries 1
>>> * Spring
>>> 
>>> В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
 No we cannot do it right now.
 
 What JDK is required for running this build?
 I can filter agents with correct JDK for now.
 
 
 
> On 31 Jul 2018, at 16:35, Nikolay Izhikov  wrote:
> 
> Hello, Igniters.
> 
> I have to up this thread.
> 
> TDE. Phase 1 development is over.
> But, I still can't run TDE tests on Team city [1].
> 
> I think that source of error is [2]
> 
> Can we upgrade Team City JDK?
> 
> [1]
>>> 
>>> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1566703&_focus=446976
> [2] https://bugs.openjdk.java.net/browse/JDK-8149411
> 
> В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
>> Hi.
>> 
>>> can we add option enables AES 128
>> 
>> Currently, 128 bit key used [1]
>> 
>> 
>>> I guess we should update environment to meet test requirements
>>> 
>>> prior putting changes to master.
>> 
>> Yes.
>> 
>> [1]
>>> 
>>> https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
>> 
>> 
>> В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
>>> Hi Nikolay,
>>> 
>>> can we add option enables AES 128 for test mode? This should work
>>> 
>>> well
>>> without update env.
>>> 
>>> Sincerely,
>>> 
>>> ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
>>> 
 
 
> On 27 Jun 2018, at 18:06, Nikolay Izhikov 
>>> 
>>> wrote:
> 
> Hello, Eduard.
> 
>> We should make suites which are restricted by agents to make
>>> 
>>> as small
 
 as> possible.
> 
> Agree. That means we should enable java cryptography on all
>>> 
>>> agents.
 
 Isn't it?
> 
>> So, I strictly against adding such test (therefore
>>> 
>>> restriction) to
 
 these> suites.>
> 
> What is wrong with tests?
 
 Tests in current configuration require specific environment.
 I guess we should update environment to meet test requirements
>>> 
>>> prior
 putting changes to master.
 
 
> Do you looked at it or something?
> 
> 
> В Ср, 27/06/2018 в 14:24 +0300, Eduard Shangareev пишет:
>> Nikolay, Petr,
>> 
>> We should make suites which are restricted by agents to make
>>> 
>>> as small as
>> possible.
>> 
>> So, I strictly against adding such 

Re: Service grid redesign

[Dmitriy Setrakyan]

Versions will complicate the implementation and will not be done in 2.7. I
would vote for the hot redeployment for now and add versions in 2.8.

D.

On Thu, Aug 9, 2018 at 10:06 AM, Anton Vinogradov  wrote:

> Real case is A/B testing.
> When you want to allow new service usage only to 0.1% of users.
> And only when you sure it works then replace all v1 with v2.
>
> So, I vote for versions.
> Let's do this in maven way (exact version, range, RELEASE or LATEST)
>
> чт, 9 авг. 2018 г. в 17:55, Dmitriy Setrakyan :
>
> > Vyacheslav,
> >
> > For the case you are describing, I would take the same approach as we
> have
> > for compute tasks. Keep the older version around only as long as there
> are
> > active requests and then undeploy it automatically. No need to allow it
> > linger around indefinitely.
> >
> > D.
> >
> > On Thu, Aug 9, 2018 at 9:52 AM, Vyacheslav Daradur 
> > wrote:
> >
> > > Dmitry, it's not only about hot redeployment.
> > >
> > > Denis, I don't see such use case, because of the answer in a different
> > > front.
> > >
> > > It relates to the best practices of SOA versioning [1] [2].
> > >
> > > For example:
> > > * we have a cluster with service [name="MySevice", v="1"];
> > > * I want to upgrade service to [name="MySevice", v="2"], but I have
> > > clients which are using [name="MySevice", v="1"] and can't stop
> > > processing;
> > > * With service versioning, we are able to deploy new service near
> > > existing service, then switch clients and undeploy outdated service.
> > >
> > > My only question is: are we going to implement such a feature [3] or
> > > not? Maybe PMC don't see such feature in Service Grid roadmap.
> > > IMO it's a good feature for a microservices platform.
> > >
> > >
> > > [1] https://www.thbs.com/thbs-insights/soa-service-
> > > versioning-best-practices
> > > [2] https://www.ibm.com/blogs/bluemix/2017/08/rapidly-
> > > developing-applications-part-6-exposing-and-versioning-apis/
> > > [3] https://issues.apache.org/jira/browse/IGNITE-6069
> > > On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > > wrote:
> > > >
> > > > Guys,
> > > >
> > > > I thought this was about automatic service redeployment, which should
> > > have
> > > > been a part of the current IEP, no? Can you please clarify?
> > > >
> > > > D.
> > > >
> > > > On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov <
> > dmekhani...@gmail.com>
> > > > wrote:
> > > >
> > > > > Vyacheslav,
> > > > >
> > > > > It looks like an overcomplication to me.
> > > > > Could you describe a case, that can be solved using versioning, but
> > not
> > > > > naming?
> > > > >
> > > > > Denis
> > > > >
> > > > > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur <
> daradu...@gmail.com
> > >:
> > > > >
> > > > > > Denis, it's not about different users services implementations.
> > > > > >
> > > > > > A real use case is user's services API versioning which is being
> > used
> > > > > > widely t in SOAP/REST microservices infrastructure.
> > > > > >
> > > > > > In my opinion, it is about services with the same name and the
> same
> > > > > > full class name, but different classes versions for example in
> > > > > > different classloaders.
> > > > > >
> > > > > >
> > > > > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <
> > > dmekhani...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > I don't think, that we really need this feature.
> > > > > > > It seems to me, that if you want to use a different
> > implementation
> > > of a
> > > > > > > service, you can assign a different name to it.
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <
> > > dsetrak...@apache.org>:
> > > > > > >
> > > > > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > > > > > daradu...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi, Igniters!
> > > > > > > > >
> > > > > > > > > I found a ticket about a service’s versioning [1].
> > > > > > > > >
> > > > > > > > > It’s out of scope IEP-17, but if we are going to implement
> > this
> > > > > > > > > feature we should build a base in the first iteration of
> > IEP-17
> > > > > > > > > because of change messages formats.
> > > > > > > > >
> > > > > > > > > In case of the versioning which assumes that we are able to
> > > host
> > > > > > > > > services with the same name, but with different
> > class/version,
> > > we
> > > > > > > > > should introduce *service’s id* to manage service’s
> lifecycle
> > > > > instead
> > > > > > > > > of service’s name.
> > > > > > > > >
> > > > > > > > > Thoughts?
> > > > > > > > >
> > > > > > > >
> > > > > > > > My only concern would be on the usability side. Is user going
> > to
> > > have
> > > > > > to
> > > > > > > > deal with IDs now, or will it be handled internally?
> > > > > > > >
> > > > > > > > D.
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, 

Re: Service grid redesign

[Anton Vinogradov]

Real case is A/B testing.
When you want to allow new service usage only to 0.1% of users.
And only when you sure it works then replace all v1 with v2.

So, I vote for versions.
Let's do this in maven way (exact version, range, RELEASE or LATEST)

чт, 9 авг. 2018 г. в 17:55, Dmitriy Setrakyan :

> Vyacheslav,
>
> For the case you are describing, I would take the same approach as we have
> for compute tasks. Keep the older version around only as long as there are
> active requests and then undeploy it automatically. No need to allow it
> linger around indefinitely.
>
> D.
>
> On Thu, Aug 9, 2018 at 9:52 AM, Vyacheslav Daradur 
> wrote:
>
> > Dmitry, it's not only about hot redeployment.
> >
> > Denis, I don't see such use case, because of the answer in a different
> > front.
> >
> > It relates to the best practices of SOA versioning [1] [2].
> >
> > For example:
> > * we have a cluster with service [name="MySevice", v="1"];
> > * I want to upgrade service to [name="MySevice", v="2"], but I have
> > clients which are using [name="MySevice", v="1"] and can't stop
> > processing;
> > * With service versioning, we are able to deploy new service near
> > existing service, then switch clients and undeploy outdated service.
> >
> > My only question is: are we going to implement such a feature [3] or
> > not? Maybe PMC don't see such feature in Service Grid roadmap.
> > IMO it's a good feature for a microservices platform.
> >
> >
> > [1] https://www.thbs.com/thbs-insights/soa-service-
> > versioning-best-practices
> > [2] https://www.ibm.com/blogs/bluemix/2017/08/rapidly-
> > developing-applications-part-6-exposing-and-versioning-apis/
> > [3] https://issues.apache.org/jira/browse/IGNITE-6069
> > On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan 
> > wrote:
> > >
> > > Guys,
> > >
> > > I thought this was about automatic service redeployment, which should
> > have
> > > been a part of the current IEP, no? Can you please clarify?
> > >
> > > D.
> > >
> > > On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov <
> dmekhani...@gmail.com>
> > > wrote:
> > >
> > > > Vyacheslav,
> > > >
> > > > It looks like an overcomplication to me.
> > > > Could you describe a case, that can be solved using versioning, but
> not
> > > > naming?
> > > >
> > > > Denis
> > > >
> > > > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur  >:
> > > >
> > > > > Denis, it's not about different users services implementations.
> > > > >
> > > > > A real use case is user's services API versioning which is being
> used
> > > > > widely t in SOAP/REST microservices infrastructure.
> > > > >
> > > > > In my opinion, it is about services with the same name and the same
> > > > > full class name, but different classes versions for example in
> > > > > different classloaders.
> > > > >
> > > > >
> > > > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <
> > dmekhani...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > I don't think, that we really need this feature.
> > > > > > It seems to me, that if you want to use a different
> implementation
> > of a
> > > > > > service, you can assign a different name to it.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <
> > dsetrak...@apache.org>:
> > > > > >
> > > > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > > > > daradu...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi, Igniters!
> > > > > > > >
> > > > > > > > I found a ticket about a service’s versioning [1].
> > > > > > > >
> > > > > > > > It’s out of scope IEP-17, but if we are going to implement
> this
> > > > > > > > feature we should build a base in the first iteration of
> IEP-17
> > > > > > > > because of change messages formats.
> > > > > > > >
> > > > > > > > In case of the versioning which assumes that we are able to
> > host
> > > > > > > > services with the same name, but with different
> class/version,
> > we
> > > > > > > > should introduce *service’s id* to manage service’s lifecycle
> > > > instead
> > > > > > > > of service’s name.
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >
> > > > > > >
> > > > > > > My only concern would be on the usability side. Is user going
> to
> > have
> > > > > to
> > > > > > > deal with IDs now, or will it be handled internally?
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: ConcurrentLinkedHashMap works incorrectly after clear()

[Dmitriy Setrakyan]

On Thu, Aug 9, 2018 at 8:16 AM, Alexey Goncharuk  wrote:

> Guys, I think we can definitely change current implementation of CLHM with
> a more stable one, but as a temporal solution I see nothing wrong with
> throwing an UnsupportedOperationException from clear() method. Ilya already
> provided a patch which replaces all clear() calls with a new map creation,
> semantically it has the same behavior as a correct clear() method.
>
> I suggest to merge the provided PR because IgniteH2Indexing is broken
> because of this bug and then create a ticket to replace/fix/whatever it
> feels right to do with current CLHM.
>
> Thoughts?
>

I agree. This sounds like a less risky approach.

D.

Re: DataFrame integration does not support ARRAY type

[Dmitriy Setrakyan]

On Thu, Aug 9, 2018 at 8:19 AM, Nikolay Izhikov  wrote:

> Dmitriy, I will take care of this ticket in a few days.
>

Great!

Re: Data regions on client nodes

[Dmitriy Setrakyan]

Alexey,

I see your point. However, I would still argue that there are more benefits
to the dynamic region allocation than not. For example, if we have this
feature, users would be able to create more regions after the node and
cluster start, which will allow to grow the data size indefinitely in the
cloud.

D.

On Thu, Aug 9, 2018 at 8:41 AM, Alexey Goncharuk  wrote:

> Once the OS gave us the pointer, no exceptions can be raised in the user
> code. If the OS overcommitted the memory, then the process will be halted
> when OOME occurs, not much we can do here.
>
> My point was that dynamic data region allocation can lead to another
> dynamic exception that should be properly handled during cache start. When
> the data region is allocated statically, this exception is handled on node
> start, which is much easier.
>
> ср, 8 авг. 2018 г. в 18:18, Dmitriy Pavlov :
>
> > I used to think that OS allocates pages not immediately after call to
> > allocate(), but only during first touch of each page.
> >
> > I'm not sure every OS provides guaranee that 'allocated' memory will
> never
> > cause OOME. Please correct me if I'm wrong.
> >
> > ср, 8 авг. 2018 г. в 17:38, Dmitriy Setrakyan :
> >
> > > Alexey,
> > >
> > > I am not sure I understand. If cache creation proceeds, but memory
> region
> > > was not allocated, how can the cache operate?
> > >
> > > D.
> > >
> > > On Wed, Aug 8, 2018 at 8:05 AM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > wrote:
> > >
> > > > I do not mind making this change, but note that the reason for
> non-lazy
> > > > region allocation is the need to gracefully handle OOME errors during
> > > cache
> > > > start. When a region is pre-allocated, no OOME can happen.
> > > >
> > > > If a region is allocated dynamically, then all errors that happened
> > > during
> > > > the node start before should be properly handled (a client node must
> be
> > > > stopped, but cache creation should proceed).
> > > >
> > > > пт, 27 июл. 2018 г. в 20:04, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com>:
> > > >
> > > > > Ticket created: https://issues.apache.org/jira/browse/IGNITE-9113
> > > > >
> > > > > -Val
> > > > >
> > > > > On Fri, Jul 27, 2018 at 5:59 AM Dmitry Pavlov <
> dpavlov@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Maxim, thank you.
> > > > > >
> > > > > > If it seems it is technically possible, we can file ticket for
> this
> > > > > change.
> > > > > >
> > > > > > I find this proposal reasonable, change makes perfectly sense to
> > me.
> > > > > >
> > > > > > We can wait Alex G. feedback on this change before starting
> actual
> > > > > > implementation. It can take for a while, because he is travelling
> > > now.
> > > > > >
> > > > > > пт, 27 июл. 2018 г. в 14:35, Maxim Muzafarov  >:
> > > > > >
> > > > > > > Guys,
> > > > > > >
> > > > > > > I can miss some details, but at the first glance we have
> > everething
> > > > we
> > > > > > need
> > > > > > > to defer
> > > > > > > region memory allocation if it has no cache groups assignments.
> > And
> > > > it
> > > > > > > doesn't matter
> > > > > > > where it happens on client or server nodes.
> > > > > > >
> > > > > > > Currently region memory allocation happens at exchange future
> > init
> > > > > > method.
> > > > > > > At the
> > > > > > > node startup method initCachesOnLocalJoin executes. This method
> > > > > > resposnible
> > > > > > > for
> > > > > > > memory allocation (through initiating cache managers) and it
> also
> > > > > starts
> > > > > > > caches.
> > > > > > > So, at this point we have all existing caches descriptors and
> can
> > > > find
> > > > > > out
> > > > > > > which
> > > > > > > cache matches which region to defer some regions initialization
> > to
> > > > the
> > > > > > > moment when
> > > > > > > newly cache assings to this region (happend at
> > > onCacheChangeRequest).
> > > > > > >
> > > > > > > Please, сorrect me if I'm wrong and missing something.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 25 Jul 2018 at 19:32 Dmitry Pavlov <
> > dpavlov@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Maxim,
> > > > > > > >
> > > > > > > > thank you for stepping in. How do you think, is it possible
> to
> > > > check
> > > > > > > cache
> > > > > > > > assignment to region at stage of memory allocation?
> > > > > > > >
> > > > > > > > Sincerely,
> > > > > > > > Dmitriy Pavlov
> > > > > > > >
> > > > > > > > ср, 25 июл. 2018 г. в 18:22, Maxim Muzafarov <
> > maxmu...@gmail.com
> > > >:
> > > > > > > >
> > > > > > > > > Folks,
> > > > > > > > >
> > > > > > > > > I've checked memory allocation. It looks like we are
> > allocating
> > > > > > memory
> > > > > > > > only
> > > > > > > > > on the first exchange future init on local join occurs on
> > node.
> > > > > Also,
> > > > > > > > seems
> > > > > > > > > like we are allocating only the first chunk of memory (not
> > the
> > > > > whole
> > > > > > > > bunch)
> > > > > > > > > and it 

Re: Service grid redesign

[Dmitriy Setrakyan]

Vyacheslav,

For the case you are describing, I would take the same approach as we have
for compute tasks. Keep the older version around only as long as there are
active requests and then undeploy it automatically. No need to allow it
linger around indefinitely.

D.

On Thu, Aug 9, 2018 at 9:52 AM, Vyacheslav Daradur 
wrote:

> Dmitry, it's not only about hot redeployment.
>
> Denis, I don't see such use case, because of the answer in a different
> front.
>
> It relates to the best practices of SOA versioning [1] [2].
>
> For example:
> * we have a cluster with service [name="MySevice", v="1"];
> * I want to upgrade service to [name="MySevice", v="2"], but I have
> clients which are using [name="MySevice", v="1"] and can't stop
> processing;
> * With service versioning, we are able to deploy new service near
> existing service, then switch clients and undeploy outdated service.
>
> My only question is: are we going to implement such a feature [3] or
> not? Maybe PMC don't see such feature in Service Grid roadmap.
> IMO it's a good feature for a microservices platform.
>
>
> [1] https://www.thbs.com/thbs-insights/soa-service-
> versioning-best-practices
> [2] https://www.ibm.com/blogs/bluemix/2017/08/rapidly-
> developing-applications-part-6-exposing-and-versioning-apis/
> [3] https://issues.apache.org/jira/browse/IGNITE-6069
> On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan 
> wrote:
> >
> > Guys,
> >
> > I thought this was about automatic service redeployment, which should
> have
> > been a part of the current IEP, no? Can you please clarify?
> >
> > D.
> >
> > On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov 
> > wrote:
> >
> > > Vyacheslav,
> > >
> > > It looks like an overcomplication to me.
> > > Could you describe a case, that can be solved using versioning, but not
> > > naming?
> > >
> > > Denis
> > >
> > > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur :
> > >
> > > > Denis, it's not about different users services implementations.
> > > >
> > > > A real use case is user's services API versioning which is being used
> > > > widely t in SOAP/REST microservices infrastructure.
> > > >
> > > > In my opinion, it is about services with the same name and the same
> > > > full class name, but different classes versions for example in
> > > > different classloaders.
> > > >
> > > >
> > > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <
> dmekhani...@gmail.com>
> > > > wrote:
> > > > >
> > > > > I don't think, that we really need this feature.
> > > > > It seems to me, that if you want to use a different implementation
> of a
> > > > > service, you can assign a different name to it.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Denis
> > > > >
> > > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <
> dsetrak...@apache.org>:
> > > > >
> > > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > > > daradu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi, Igniters!
> > > > > > >
> > > > > > > I found a ticket about a service’s versioning [1].
> > > > > > >
> > > > > > > It’s out of scope IEP-17, but if we are going to implement this
> > > > > > > feature we should build a base in the first iteration of IEP-17
> > > > > > > because of change messages formats.
> > > > > > >
> > > > > > > In case of the versioning which assumes that we are able to
> host
> > > > > > > services with the same name, but with different class/version,
> we
> > > > > > > should introduce *service’s id* to manage service’s lifecycle
> > > instead
> > > > > > > of service’s name.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > >
> > > > > > My only concern would be on the usability side. Is user going to
> have
> > > > to
> > > > > > deal with IDs now, or will it be handled internally?
> > > > > >
> > > > > > D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

[Vyacheslav Daradur]

Dmitry, it's not only about hot redeployment.

Denis, I don't see such use case, because of the answer in a different front.

It relates to the best practices of SOA versioning [1] [2].

For example:
* we have a cluster with service [name="MySevice", v="1"];
* I want to upgrade service to [name="MySevice", v="2"], but I have
clients which are using [name="MySevice", v="1"] and can't stop
processing;
* With service versioning, we are able to deploy new service near
existing service, then switch clients and undeploy outdated service.

My only question is: are we going to implement such a feature [3] or
not? Maybe PMC don't see such feature in Service Grid roadmap.
IMO it's a good feature for a microservices platform.


[1] https://www.thbs.com/thbs-insights/soa-service-versioning-best-practices
[2] 
https://www.ibm.com/blogs/bluemix/2017/08/rapidly-developing-applications-part-6-exposing-and-versioning-apis/
[3] https://issues.apache.org/jira/browse/IGNITE-6069
On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan  wrote:
>
> Guys,
>
> I thought this was about automatic service redeployment, which should have
> been a part of the current IEP, no? Can you please clarify?
>
> D.
>
> On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov 
> wrote:
>
> > Vyacheslav,
> >
> > It looks like an overcomplication to me.
> > Could you describe a case, that can be solved using versioning, but not
> > naming?
> >
> > Denis
> >
> > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur :
> >
> > > Denis, it's not about different users services implementations.
> > >
> > > A real use case is user's services API versioning which is being used
> > > widely t in SOAP/REST microservices infrastructure.
> > >
> > > In my opinion, it is about services with the same name and the same
> > > full class name, but different classes versions for example in
> > > different classloaders.
> > >
> > >
> > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov 
> > > wrote:
> > > >
> > > > I don't think, that we really need this feature.
> > > > It seems to me, that if you want to use a different implementation of a
> > > > service, you can assign a different name to it.
> > > >
> > > > What do you think?
> > > >
> > > > Denis
> > > >
> > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan :
> > > >
> > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > > daradu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi, Igniters!
> > > > > >
> > > > > > I found a ticket about a service’s versioning [1].
> > > > > >
> > > > > > It’s out of scope IEP-17, but if we are going to implement this
> > > > > > feature we should build a base in the first iteration of IEP-17
> > > > > > because of change messages formats.
> > > > > >
> > > > > > In case of the versioning which assumes that we are able to host
> > > > > > services with the same name, but with different class/version, we
> > > > > > should introduce *service’s id* to manage service’s lifecycle
> > instead
> > > > > > of service’s name.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > >
> > > > > My only concern would be on the usability side. Is user going to have
> > > to
> > > > > deal with IDs now, or will it be handled internally?
> > > > >
> > > > > D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

[Dmitriy Setrakyan]

Guys,

I thought this was about automatic service redeployment, which should have
been a part of the current IEP, no? Can you please clarify?

D.

On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov 
wrote:

> Vyacheslav,
>
> It looks like an overcomplication to me.
> Could you describe a case, that can be solved using versioning, but not
> naming?
>
> Denis
>
> чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur :
>
> > Denis, it's not about different users services implementations.
> >
> > A real use case is user's services API versioning which is being used
> > widely t in SOAP/REST microservices infrastructure.
> >
> > In my opinion, it is about services with the same name and the same
> > full class name, but different classes versions for example in
> > different classloaders.
> >
> >
> > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov 
> > wrote:
> > >
> > > I don't think, that we really need this feature.
> > > It seems to me, that if you want to use a different implementation of a
> > > service, you can assign a different name to it.
> > >
> > > What do you think?
> > >
> > > Denis
> > >
> > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan :
> > >
> > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > daradu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi, Igniters!
> > > > >
> > > > > I found a ticket about a service’s versioning [1].
> > > > >
> > > > > It’s out of scope IEP-17, but if we are going to implement this
> > > > > feature we should build a base in the first iteration of IEP-17
> > > > > because of change messages formats.
> > > > >
> > > > > In case of the versioning which assumes that we are able to host
> > > > > services with the same name, but with different class/version, we
> > > > > should introduce *service’s id* to manage service’s lifecycle
> instead
> > > > > of service’s name.
> > > > >
> > > > > Thoughts?
> > > > >
> > > >
> > > > My only concern would be on the usability side. Is user going to have
> > to
> > > > deal with IDs now, or will it be handled internally?
> > > >
> > > > D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: TDE: Upgrade Team City JDK

[Nikolay Izhikov]

Petr.

Seems, now I has to put my tests in "Basic Tests With Persistence".
Can you configure Team city so I can run "Basic Tests With Persistence" on 
publicagent03_9091?

В Чт, 09/08/2018 в 16:35 +0300, Petr Ivanov пишет:
> Yeap.
> 
> As it is disabled, it will not take tasks from queue automatically, but can 
> be assigned tasks manually.
> 
> 
> > On 9 Aug 2018, at 16:27, Nikolay Izhikov  wrote:
> > 
> > Hello, Petr.
> > 
> > I'm able to select thi agent for build.
> > But it has "disabled" comment.
> > 
> > Is that OK?
> > 
> > https://ci.ignite.apache.org/viewQueued.html?itemId=1620053:0:153=queuedBuildOverviewTab
> > 
> > В Ср, 08/08/2018 в 17:44 +0300, Petr Ivanov пишет:
> > > Nikolay,
> > > 
> > > 
> > > I’ve updated publicagent03_9091 and tested all current builds for Ignite 
> > > Tests 2.4+ project for master branch.
> > > Please test your PR on this agent (select it when starting build) for 
> > > correct java configuration.
> > > 
> > > If everything is OK — I’ll distribute this Java among all other agents.
> > > 
> > > 
> > > 
> > > > On 31 Jul 2018, at 22:18, Petr Ivanov  wrote:
> > > > 
> > > > > 8u111.
> > > > 
> > > > I’ve started the process of update, will try to accomplish by the end 
> > > > of the week.
> > > > 
> > > > 
> > > > > On 31 Jul 2018, at 21:26, Denis Magda  wrote:
> > > > > 
> > > > > Nikolay,
> > > > > 
> > > > > Do you need 8u111 and later? Or any JDK 8 works for you?
> > > > > 
> > > > > --
> > > > > Denis
> > > > > 
> > > > > On Tue, Jul 31, 2018 at 6:55 AM Nikolay Izhikov  
> > > > > wrote:
> > > > > 
> > > > > > Hello, Petr.
> > > > > > 
> > > > > > > What JDK is required for running this build?
> > > > > > 
> > > > > > 8u111 and later.
> > > > > > 
> > > > > > > I can filter agents with correct JDK for now.
> > > > > > 
> > > > > > Encryption tests are executed by following build plans:
> > > > > > 
> > > > > >  * Basic 1
> > > > > >  * Binary Objects (Simple Mapper Basic)
> > > > > >  * Queries 1
> > > > > >  * Spring
> > > > > > 
> > > > > > В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
> > > > > > > No we cannot do it right now.
> > > > > > > 
> > > > > > > What JDK is required for running this build?
> > > > > > > I can filter agents with correct JDK for now.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > On 31 Jul 2018, at 16:35, Nikolay Izhikov  
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > Hello, Igniters.
> > > > > > > > 
> > > > > > > > I have to up this thread.
> > > > > > > > 
> > > > > > > > TDE. Phase 1 development is over.
> > > > > > > > But, I still can't run TDE tests on Team city [1].
> > > > > > > > 
> > > > > > > > I think that source of error is [2]
> > > > > > > > 
> > > > > > > > Can we upgrade Team City JDK?
> > > > > > > > 
> > > > > > > > [1]
> > > > > > 
> > > > > > https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1566703&_focus=446976
> > > > > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8149411
> > > > > > > > 
> > > > > > > > В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
> > > > > > > > > Hi.
> > > > > > > > > 
> > > > > > > > > > can we add option enables AES 128
> > > > > > > > > 
> > > > > > > > > Currently, 128 bit key used [1]
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > I guess we should update environment to meet test 
> > > > > > > > > > requirements
> > > > > > 
> > > > > > prior putting changes to master.
> > > > > > > > > 
> > > > > > > > > Yes.
> > > > > > > > > 
> > > > > > > > > [1]
> > > > > > 
> > > > > > https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
> > > > > > > > > > Hi Nikolay,
> > > > > > > > > > 
> > > > > > > > > > can we add option enables AES 128 for test mode? This 
> > > > > > > > > > should work
> > > > > > 
> > > > > > well
> > > > > > > > > > without update env.
> > > > > > > > > > 
> > > > > > > > > > Sincerely,
> > > > > > > > > > 
> > > > > > > > > > ср, 27 июн. 2018 г. в 18:43, Petr Ivanov 
> > > > > > > > > > :
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > On 27 Jun 2018, at 18:06, Nikolay Izhikov 
> > > > > > > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > Hello, Eduard.
> > > > > > > > > > > > 
> > > > > > > > > > > > > We should make suites which are restricted by agents 
> > > > > > > > > > > > > to make
> > > > > > 
> > > > > > as small
> > > > > > > > > > > 
> > > > > > > > > > > as> possible.
> > > > > > > > > > > > 
> > > > > > > > > > > > Agree. That means we should enable java cryptography on 
> > > > > > > > > > > > all
> > > > > > 
> > > > > > agents.
> > > > > > > > > > > 
> > > > > > > > > > > Isn't it?
> > > > > > > > > > > > 
> > > > > > > > > > > > > So, I strictly against adding such test (therefore
> > > > > > 
> > > > > > restriction) to
> > > > > 

Re: Service grid redesign

[Denis Mekhanikov]

Vyacheslav,

It looks like an overcomplication to me.
Could you describe a case, that can be solved using versioning, but not
naming?

Denis

чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur :

> Denis, it's not about different users services implementations.
>
> A real use case is user's services API versioning which is being used
> widely t in SOAP/REST microservices infrastructure.
>
> In my opinion, it is about services with the same name and the same
> full class name, but different classes versions for example in
> different classloaders.
>
>
> On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov 
> wrote:
> >
> > I don't think, that we really need this feature.
> > It seems to me, that if you want to use a different implementation of a
> > service, you can assign a different name to it.
> >
> > What do you think?
> >
> > Denis
> >
> > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan :
> >
> > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> daradu...@gmail.com>
> > > wrote:
> > >
> > > > Hi, Igniters!
> > > >
> > > > I found a ticket about a service’s versioning [1].
> > > >
> > > > It’s out of scope IEP-17, but if we are going to implement this
> > > > feature we should build a base in the first iteration of IEP-17
> > > > because of change messages formats.
> > > >
> > > > In case of the versioning which assumes that we are able to host
> > > > services with the same name, but with different class/version, we
> > > > should introduce *service’s id* to manage service’s lifecycle instead
> > > > of service’s name.
> > > >
> > > > Thoughts?
> > > >
> > >
> > > My only concern would be on the usability side. Is user going to have
> to
> > > deal with IDs now, or will it be handled internally?
> > >
> > > D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

[Vyacheslav Daradur]

Denis, it's not about different users services implementations.

A real use case is user's services API versioning which is being used
widely t in SOAP/REST microservices infrastructure.

In my opinion, it is about services with the same name and the same
full class name, but different classes versions for example in
different classloaders.


On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov  wrote:
>
> I don't think, that we really need this feature.
> It seems to me, that if you want to use a different implementation of a
> service, you can assign a different name to it.
>
> What do you think?
>
> Denis
>
> чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan :
>
> > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur 
> > wrote:
> >
> > > Hi, Igniters!
> > >
> > > I found a ticket about a service’s versioning [1].
> > >
> > > It’s out of scope IEP-17, but if we are going to implement this
> > > feature we should build a base in the first iteration of IEP-17
> > > because of change messages formats.
> > >
> > > In case of the versioning which assumes that we are able to host
> > > services with the same name, but with different class/version, we
> > > should introduce *service’s id* to manage service’s lifecycle instead
> > > of service’s name.
> > >
> > > Thoughts?
> > >
> >
> > My only concern would be on the usability side. Is user going to have to
> > deal with IDs now, or will it be handled internally?
> >
> > D.
> >



-- 
Best Regards, Vyacheslav D.

[GitHub] ignite pull request #3849: B+Tree operation may result in an infinite loop i...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Data regions on client nodes

[Alexey Goncharuk]

Once the OS gave us the pointer, no exceptions can be raised in the user
code. If the OS overcommitted the memory, then the process will be halted
when OOME occurs, not much we can do here.

My point was that dynamic data region allocation can lead to another
dynamic exception that should be properly handled during cache start. When
the data region is allocated statically, this exception is handled on node
start, which is much easier.

ср, 8 авг. 2018 г. в 18:18, Dmitriy Pavlov :

> I used to think that OS allocates pages not immediately after call to
> allocate(), but only during first touch of each page.
>
> I'm not sure every OS provides guaranee that 'allocated' memory will never
> cause OOME. Please correct me if I'm wrong.
>
> ср, 8 авг. 2018 г. в 17:38, Dmitriy Setrakyan :
>
> > Alexey,
> >
> > I am not sure I understand. If cache creation proceeds, but memory region
> > was not allocated, how can the cache operate?
> >
> > D.
> >
> > On Wed, Aug 8, 2018 at 8:05 AM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > wrote:
> >
> > > I do not mind making this change, but note that the reason for non-lazy
> > > region allocation is the need to gracefully handle OOME errors during
> > cache
> > > start. When a region is pre-allocated, no OOME can happen.
> > >
> > > If a region is allocated dynamically, then all errors that happened
> > during
> > > the node start before should be properly handled (a client node must be
> > > stopped, but cache creation should proceed).
> > >
> > > пт, 27 июл. 2018 г. в 20:04, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com>:
> > >
> > > > Ticket created: https://issues.apache.org/jira/browse/IGNITE-9113
> > > >
> > > > -Val
> > > >
> > > > On Fri, Jul 27, 2018 at 5:59 AM Dmitry Pavlov  >
> > > > wrote:
> > > >
> > > > > Maxim, thank you.
> > > > >
> > > > > If it seems it is technically possible, we can file ticket for this
> > > > change.
> > > > >
> > > > > I find this proposal reasonable, change makes perfectly sense to
> me.
> > > > >
> > > > > We can wait Alex G. feedback on this change before starting actual
> > > > > implementation. It can take for a while, because he is travelling
> > now.
> > > > >
> > > > > пт, 27 июл. 2018 г. в 14:35, Maxim Muzafarov :
> > > > >
> > > > > > Guys,
> > > > > >
> > > > > > I can miss some details, but at the first glance we have
> everething
> > > we
> > > > > need
> > > > > > to defer
> > > > > > region memory allocation if it has no cache groups assignments.
> And
> > > it
> > > > > > doesn't matter
> > > > > > where it happens on client or server nodes.
> > > > > >
> > > > > > Currently region memory allocation happens at exchange future
> init
> > > > > method.
> > > > > > At the
> > > > > > node startup method initCachesOnLocalJoin executes. This method
> > > > > resposnible
> > > > > > for
> > > > > > memory allocation (through initiating cache managers) and it also
> > > > starts
> > > > > > caches.
> > > > > > So, at this point we have all existing caches descriptors and can
> > > find
> > > > > out
> > > > > > which
> > > > > > cache matches which region to defer some regions initialization
> to
> > > the
> > > > > > moment when
> > > > > > newly cache assings to this region (happend at
> > onCacheChangeRequest).
> > > > > >
> > > > > > Please, сorrect me if I'm wrong and missing something.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 25 Jul 2018 at 19:32 Dmitry Pavlov <
> dpavlov@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hi Maxim,
> > > > > > >
> > > > > > > thank you for stepping in. How do you think, is it possible to
> > > check
> > > > > > cache
> > > > > > > assignment to region at stage of memory allocation?
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > ср, 25 июл. 2018 г. в 18:22, Maxim Muzafarov <
> maxmu...@gmail.com
> > >:
> > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > I've checked memory allocation. It looks like we are
> allocating
> > > > > memory
> > > > > > > only
> > > > > > > > on the first exchange future init on local join occurs on
> node.
> > > > Also,
> > > > > > > seems
> > > > > > > > like we are allocating only the first chunk of memory (not
> the
> > > > whole
> > > > > > > bunch)
> > > > > > > > and it calculates as:
> > > > > > > >
> > > > > > > > Math.max((maxSize - startSize) / (SEG_CNT - 1), 256L * 1024 *
> > > 1024)
> > > > > > > >
> > > > > > > > But, I'm agree with Val. It's better to allocate memory only
> > when
> > > > > when
> > > > > > > > the first cache assigned to this region.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Also, It seems like we have some problem with user
> notification
> > > > about
> > > > > > > > available
> > > > > > > > physical resources. For client nodes method requiredOffheap()
> > > > returns
> > > > > > > > always
> > > > > > > > zero [1]. That's why WARN message shown here [2] would be not
> > not
> > > > > quite
> > 

Re: Service grid redesign

[Denis Mekhanikov]

I don't think, that we really need this feature.
It seems to me, that if you want to use a different implementation of a
service, you can assign a different name to it.

What do you think?

Denis

чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan :

> On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur 
> wrote:
>
> > Hi, Igniters!
> >
> > I found a ticket about a service’s versioning [1].
> >
> > It’s out of scope IEP-17, but if we are going to implement this
> > feature we should build a base in the first iteration of IEP-17
> > because of change messages formats.
> >
> > In case of the versioning which assumes that we are able to host
> > services with the same name, but with different class/version, we
> > should introduce *service’s id* to manage service’s lifecycle instead
> > of service’s name.
> >
> > Thoughts?
> >
>
> My only concern would be on the usability side. Is user going to have to
> deal with IDs now, or will it be handled internally?
>
> D.
>

Re: Service grid redesign

[Vyacheslav Daradur]

We won't change API, user will continue to use service's name to manage it.

Some kind of service id will be used internally, this allow us to
distinguish services with the same name, but different version.


On Thu, Aug 9, 2018 at 4:32 PM Dmitriy Setrakyan  wrote:
>
> On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur 
> wrote:
>
> > Hi, Igniters!
> >
> > I found a ticket about a service’s versioning [1].
> >
> > It’s out of scope IEP-17, but if we are going to implement this
> > feature we should build a base in the first iteration of IEP-17
> > because of change messages formats.
> >
> > In case of the versioning which assumes that we are able to host
> > services with the same name, but with different class/version, we
> > should introduce *service’s id* to manage service’s lifecycle instead
> > of service’s name.
> >
> > Thoughts?
> >
>
> My only concern would be on the usability side. Is user going to have to
> deal with IDs now, or will it be handled internally?
>
> D.



-- 
Best Regards, Vyacheslav D.

Re: TDE: Upgrade Team City JDK

[Petr Ivanov]

Yeap.

As it is disabled, it will not take tasks from queue automatically, but can be 
assigned tasks manually.


> On 9 Aug 2018, at 16:27, Nikolay Izhikov  wrote:
> 
> Hello, Petr.
> 
> I'm able to select thi agent for build.
> But it has "disabled" comment.
> 
> Is that OK?
> 
> https://ci.ignite.apache.org/viewQueued.html?itemId=1620053:0:153=queuedBuildOverviewTab
> 
> В Ср, 08/08/2018 в 17:44 +0300, Petr Ivanov пишет:
>> Nikolay,
>> 
>> 
>> I’ve updated publicagent03_9091 and tested all current builds for Ignite 
>> Tests 2.4+ project for master branch.
>> Please test your PR on this agent (select it when starting build) for 
>> correct java configuration.
>> 
>> If everything is OK — I’ll distribute this Java among all other agents.
>> 
>> 
>> 
>>> On 31 Jul 2018, at 22:18, Petr Ivanov  wrote:
>>> 
 8u111.
>>> 
>>> I’ve started the process of update, will try to accomplish by the end of 
>>> the week.
>>> 
>>> 
 On 31 Jul 2018, at 21:26, Denis Magda  wrote:
 
 Nikolay,
 
 Do you need 8u111 and later? Or any JDK 8 works for you?
 
 --
 Denis
 
 On Tue, Jul 31, 2018 at 6:55 AM Nikolay Izhikov  
 wrote:
 
> Hello, Petr.
> 
>> What JDK is required for running this build?
> 
> 8u111 and later.
> 
>> I can filter agents with correct JDK for now.
> 
> Encryption tests are executed by following build plans:
> 
>  * Basic 1
>  * Binary Objects (Simple Mapper Basic)
>  * Queries 1
>  * Spring
> 
> В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
>> No we cannot do it right now.
>> 
>> What JDK is required for running this build?
>> I can filter agents with correct JDK for now.
>> 
>> 
>> 
>>> On 31 Jul 2018, at 16:35, Nikolay Izhikov  wrote:
>>> 
>>> Hello, Igniters.
>>> 
>>> I have to up this thread.
>>> 
>>> TDE. Phase 1 development is over.
>>> But, I still can't run TDE tests on Team city [1].
>>> 
>>> I think that source of error is [2]
>>> 
>>> Can we upgrade Team City JDK?
>>> 
>>> [1]
> 
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1566703&_focus=446976
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8149411
>>> 
>>> В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
 Hi.
 
> can we add option enables AES 128
 
 Currently, 128 bit key used [1]
 
 
> I guess we should update environment to meet test requirements
> 
> prior putting changes to master.
 
 Yes.
 
 [1]
> 
> https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
 
 
 В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
> Hi Nikolay,
> 
> can we add option enables AES 128 for test mode? This should work
> 
> well
> without update env.
> 
> Sincerely,
> 
> ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
> 
>> 
>> 
>>> On 27 Jun 2018, at 18:06, Nikolay Izhikov 
> 
> wrote:
>>> 
>>> Hello, Eduard.
>>> 
 We should make suites which are restricted by agents to make
> 
> as small
>> 
>> as> possible.
>>> 
>>> Agree. That means we should enable java cryptography on all
> 
> agents.
>> 
>> Isn't it?
>>> 
 So, I strictly against adding such test (therefore
> 
> restriction) to
>> 
>> these> suites.>
>>> 
>>> What is wrong with tests?
>> 
>> Tests in current configuration require specific environment.
>> I guess we should update environment to meet test requirements
> 
> prior
>> putting changes to master.
>> 
>> 
>>> Do you looked at it or something?
>>> 
>>> 
>>> В Ср, 27/06/2018 в 14:24 +0300, Eduard Shangareev пишет:
 Nikolay, Petr,
 
 We should make suites which are restricted by agents to make
> 
> as small as
 possible.
 
 So, I strictly against adding such test (therefore
> 
> restriction) to these
 suites.
 
 On Wed, Jun 27, 2018 at 11:39 AM, Petr Ivanov <
> 
> mr.wei...@gmail.com>
>> 
>> wrote:
 
> IgniteSpiTestSuite is called from ’SPI’ build type and
> 
> I’ve added agent
> filter there.
> IgniteKernalSelfTestSuite is not found in build types.
> 
> 
> 
>> On 27 Jun 2018, at 11:26, Nikolay Izhikov <
> 
> nizhi...@apache.org>
>> 
>> wrote:
>> 
>> Well, it's a good 

Re: Spark SQL Table Name Resolution

[Stuart Macdonald]

Hi Nikolay, yes would be happy to - will likely be early next week.
I’ll go with the approach of adding a new optional field to the Spark
data source provider unless there are any objections.

Stuart.

> On 9 Aug 2018, at 14:20, Nikolay Izhikov  wrote:
>
> Stuart, do you want to work on this ticket?
>
> В Вт, 07/08/2018 в 11:13 -0700, Stuart Macdonald пишет:
>> Thanks Val, here’s the ticket:
>>
>> https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-9228
>> 
>>
>> (Thanks for correcting my terminology - I work mostly with the traditional
>> CacheConfiguration interface where I believe each cache occupies its own
>> schema.)
>>
>> Stuart.
>>
>> On 7 Aug 2018, at 18:34, Valentin Kulichenko 
>> wrote:
>>
>> Stuart,
>>
>> Two tables can have same names only if they are located in different
>> schemas. Said that, sdding schema name support makes sense to me for sure.
>> We can implement this using either separate SCHEMA_NAME parameter, or
>> similar to what you suggested in option 3 but with schema name instead of
>> cache name.
>>
>> Please feel free to create a ticket.
>>
>> -Val
>>
>> On Tue, Aug 7, 2018 at 9:32 AM Stuart Macdonald  wrote:
>>
>> Hello Igniters,
>>
>>
>> The Ignite Spark SQL interface currently takes just “table name” as a
>>
>> parameter which it uses to supply a Spark dataset with data from the
>>
>> underlying Ignite SQL table with that name.
>>
>>
>> To do this it loops through each cache and finds the first one with the
>>
>> given table name [1]. This causes issues if there are multiple tables
>>
>> registered in different caches with the same table name as you can only
>>
>> access one of those caches from Spark. Is the right thing to do here:
>>
>>
>> 1. Simply not support such a scenario and note in the Spark documentation
>>
>> that table names must be unique?
>>
>> 2. Pass an extra parameter through the Ignite Spark data source which
>>
>> optionally specifies the cache name?
>>
>> 3. Support namespacing in the existing table name parameter, ie
>>
>> “cacheName.tableName”?
>>
>>
>> Thanks,
>>
>> Stuart.
>>
>>
>> [1]
>>
>>
>> https://github.com/apache/ignite/blob/ca973ad99c6112160a305df05be9458e29f88307/modules/spark/src/main/scala/org/apache/ignite/spark/impl/package.scala#L119

Re: Service grid redesign

[Dmitriy Setrakyan]

On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur 
wrote:

> Hi, Igniters!
>
> I found a ticket about a service’s versioning [1].
>
> It’s out of scope IEP-17, but if we are going to implement this
> feature we should build a base in the first iteration of IEP-17
> because of change messages formats.
>
> In case of the versioning which assumes that we are able to host
> services with the same name, but with different class/version, we
> should introduce *service’s id* to manage service’s lifecycle instead
> of service’s name.
>
> Thoughts?
>

My only concern would be on the usability side. Is user going to have to
deal with IDs now, or will it be handled internally?

D.

Re: TDE: Upgrade Team City JDK

[Nikolay Izhikov]

Hello, Petr.

I'm able to select thi agent for build.
But it has "disabled" comment.

Is that OK?

https://ci.ignite.apache.org/viewQueued.html?itemId=1620053:0:153=queuedBuildOverviewTab

В Ср, 08/08/2018 в 17:44 +0300, Petr Ivanov пишет:
> Nikolay,
> 
> 
> I’ve updated publicagent03_9091 and tested all current builds for Ignite 
> Tests 2.4+ project for master branch.
> Please test your PR on this agent (select it when starting build) for correct 
> java configuration.
> 
> If everything is OK — I’ll distribute this Java among all other agents.
> 
> 
> 
> > On 31 Jul 2018, at 22:18, Petr Ivanov  wrote:
> > 
> > > 8u111.
> > 
> > I’ve started the process of update, will try to accomplish by the end of 
> > the week.
> > 
> > 
> > > On 31 Jul 2018, at 21:26, Denis Magda  wrote:
> > > 
> > > Nikolay,
> > > 
> > > Do you need 8u111 and later? Or any JDK 8 works for you?
> > > 
> > > --
> > > Denis
> > > 
> > > On Tue, Jul 31, 2018 at 6:55 AM Nikolay Izhikov  
> > > wrote:
> > > 
> > > > Hello, Petr.
> > > > 
> > > > > What JDK is required for running this build?
> > > > 
> > > > 8u111 and later.
> > > > 
> > > > > I can filter agents with correct JDK for now.
> > > > 
> > > > Encryption tests are executed by following build plans:
> > > > 
> > > >   * Basic 1
> > > >   * Binary Objects (Simple Mapper Basic)
> > > >   * Queries 1
> > > >   * Spring
> > > > 
> > > > В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
> > > > > No we cannot do it right now.
> > > > > 
> > > > > What JDK is required for running this build?
> > > > > I can filter agents with correct JDK for now.
> > > > > 
> > > > > 
> > > > > 
> > > > > > On 31 Jul 2018, at 16:35, Nikolay Izhikov  
> > > > > > wrote:
> > > > > > 
> > > > > > Hello, Igniters.
> > > > > > 
> > > > > > I have to up this thread.
> > > > > > 
> > > > > > TDE. Phase 1 development is over.
> > > > > > But, I still can't run TDE tests on Team city [1].
> > > > > > 
> > > > > > I think that source of error is [2]
> > > > > > 
> > > > > > Can we upgrade Team City JDK?
> > > > > > 
> > > > > > [1]
> > > > 
> > > > https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1566703&_focus=446976
> > > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8149411
> > > > > > 
> > > > > > В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
> > > > > > > Hi.
> > > > > > > 
> > > > > > > > can we add option enables AES 128
> > > > > > > 
> > > > > > > Currently, 128 bit key used [1]
> > > > > > > 
> > > > > > > 
> > > > > > > > I guess we should update environment to meet test requirements
> > > > 
> > > > prior putting changes to master.
> > > > > > > 
> > > > > > > Yes.
> > > > > > > 
> > > > > > > [1]
> > > > 
> > > > https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
> > > > > > > 
> > > > > > > 
> > > > > > > В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
> > > > > > > > Hi Nikolay,
> > > > > > > > 
> > > > > > > > can we add option enables AES 128 for test mode? This should 
> > > > > > > > work
> > > > 
> > > > well
> > > > > > > > without update env.
> > > > > > > > 
> > > > > > > > Sincerely,
> > > > > > > > 
> > > > > > > > ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > On 27 Jun 2018, at 18:06, Nikolay Izhikov 
> > > > > > > > > > 
> > > > 
> > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > Hello, Eduard.
> > > > > > > > > > 
> > > > > > > > > > > We should make suites which are restricted by agents to 
> > > > > > > > > > > make
> > > > 
> > > > as small
> > > > > > > > > 
> > > > > > > > > as> possible.
> > > > > > > > > > 
> > > > > > > > > > Agree. That means we should enable java cryptography on all
> > > > 
> > > > agents.
> > > > > > > > > 
> > > > > > > > > Isn't it?
> > > > > > > > > > 
> > > > > > > > > > > So, I strictly against adding such test (therefore
> > > > 
> > > > restriction) to
> > > > > > > > > 
> > > > > > > > > these> suites.>
> > > > > > > > > > 
> > > > > > > > > > What is wrong with tests?
> > > > > > > > > 
> > > > > > > > > Tests in current configuration require specific environment.
> > > > > > > > > I guess we should update environment to meet test requirements
> > > > 
> > > > prior
> > > > > > > > > putting changes to master.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > Do you looked at it or something?
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > В Ср, 27/06/2018 в 14:24 +0300, Eduard Shangareev пишет:
> > > > > > > > > > > Nikolay, Petr,
> > > > > > > > > > > 
> > > > > > > > > > > We should make suites which are restricted by agents to 
> > > > > > > > > > > make
> > > > 
> > > > as small as
> > > > > > > > > > > possible.
> > > > > > > > > > > 
> > > > > > > > > > > So, I strictly against adding such test (therefore
> > > > 
> > > > restriction) to these
> > > > > > > > > > > suites.
> > > > > > > > > > > 
> > > > > > > > > > > On Wed, Jun 27, 2018 at 

Re: Deprecate force server mode for clients.

[Nikolay Izhikov]

+1 from me.

В Чт, 09/08/2018 в 12:51 +0300, Pavel Kovalenko пишет:
> Andrey,
> 
> Huge +1 for that.
> "Force server mode" increases the complexity of understanding how cluster
> in ring mode works without real benefits.
> If a user wants to start client node first before server nodes have
> started, he can adjust timeouts on connection and spin till a client is
> connected. Ability to join client node to topology without server nodes
> looks dubious.
> As we have thin clients and Zookeeper Discovery SPI this mode looks like a
> crutch and should be removed.
> 
> 2018-08-09 12:41 GMT+03:00 Andrey Mashenkov :
> 
> > Hi Igniters,
> > 
> > I've found that KernalContext.clientNode() and TcpDusciveryNode.isClient()
> > means different and it looks confusing.
> > 
> > 1. The first one return true if "node is configured as client" and false
> > otherwise,
> > 2. The second one can return false if server mode is forced for client (via
> > TcpDiscoverySpi.setForceServerMode(true)) ,
> >  so actually true value means "a client node is out of the ring".
> > 
> > Thus, TcpDiscoveryNode.isClient() semantic is broken and  we can get
> > confusing results on client node with forced server mode,
> > when kernalContext.clientNode() return true and
> > kernalContex.localNode().isClient() return false.
> > 
> > Also, we have a number of places in code where node.isClient() method is
> > used.
> > 
> > My suggestion is
> > 1. Deprecate force server mode and plan to remove it to next major release.
> > 2. Fix TcpDiscoveryNode,isClient() semantic e.g. to use node attributes to
> > make ClusterNode.isClient method consistent with node configuration.
> > 2. Add isRingNode (possibly package private) with current
> > TcpDiscoveryNode.isClient() semantic to preserve compatibility.
> > 
> > Any pros or cons?
> > 
> > --
> > Best regards,
> > Andrey V. Mashenkov
> > 

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

Re: Spark SQL Table Name Resolution

[Nikolay Izhikov]

Stuart, do you want to work on this ticket?

В Вт, 07/08/2018 в 11:13 -0700, Stuart Macdonald пишет:
> Thanks Val, here’s the ticket:
> 
> https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-9228
> 
> 
> (Thanks for correcting my terminology - I work mostly with the traditional
> CacheConfiguration interface where I believe each cache occupies its own
> schema.)
> 
> Stuart.
> 
> On 7 Aug 2018, at 18:34, Valentin Kulichenko 
> wrote:
> 
> Stuart,
> 
> Two tables can have same names only if they are located in different
> schemas. Said that, sdding schema name support makes sense to me for sure.
> We can implement this using either separate SCHEMA_NAME parameter, or
> similar to what you suggested in option 3 but with schema name instead of
> cache name.
> 
> Please feel free to create a ticket.
> 
> -Val
> 
> On Tue, Aug 7, 2018 at 9:32 AM Stuart Macdonald  wrote:
> 
> Hello Igniters,
> 
> 
> The Ignite Spark SQL interface currently takes just “table name” as a
> 
> parameter which it uses to supply a Spark dataset with data from the
> 
> underlying Ignite SQL table with that name.
> 
> 
> To do this it loops through each cache and finds the first one with the
> 
> given table name [1]. This causes issues if there are multiple tables
> 
> registered in different caches with the same table name as you can only
> 
> access one of those caches from Spark. Is the right thing to do here:
> 
> 
> 1. Simply not support such a scenario and note in the Spark documentation
> 
> that table names must be unique?
> 
> 2. Pass an extra parameter through the Ignite Spark data source which
> 
> optionally specifies the cache name?
> 
> 3. Support namespacing in the existing table name parameter, ie
> 
> “cacheName.tableName”?
> 
> 
> Thanks,
> 
> Stuart.
> 
> 
> [1]
> 
> 
> https://github.com/apache/ignite/blob/ca973ad99c6112160a305df05be9458e29f88307/modules/spark/src/main/scala/org/apache/ignite/spark/impl/package.scala#L119

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

Re: DataFrame integration does not support ARRAY type

[Nikolay Izhikov]

Dmitriy, I will take care of this ticket in a few days.

В Ср, 08/08/2018 в 18:06 -0500, Dmitriy Setrakyan пишет:
> Would be nice if someone in the community would pick this ticket up.
> 
> On Wed, Aug 8, 2018 at 1:19 AM, Nikolay Izhikov  wrote:
> 
> > Hello, Valentin.
> > 
> > Yes, this is a bug.
> > 
> > Ticket created - https://issues.apache.org/jira/browse/IGNITE-9229
> > 
> > В Вт, 31/07/2018 в 16:01 -0700, Valentin Kulichenko пишет:
> > > Hi Nikolay,
> > > 
> > > Can you please take a look at this thread on SO?
> > 
> > https://stackoverflow.com/questions/51621280/saving-a-
> > spark-dataset-to-apache-ignite-with-array-column-and-savemode-overwrite
> > > 
> > > Looks like org.apache.ignite.spark.impl.QueryUtils#dataType method
> > 
> > should also support ArrayType as one of the cases. Currently it doesn't and
> > throws an exception.
> > > 
> > > Is it a bug?
> > > 
> > > -Val

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

[GitHub] ignite pull request #4506: IGNITE-9231 improvement throttle implementation

[zstan]

GitHub user zstan opened a pull request:

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

IGNITE-9231 improvement throttle implementation

…Buf condition.

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

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

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

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


commit 8601b8393cb86a80b978b8c26c5bbc9d28841f67
Author: Evgeny Stanilovskiy 
Date:   2018-08-09T10:50:50Z

IGNITE-9231 improvement throttle implementation, unpark threads on cpBuf 
condition.




---

Re: ConcurrentLinkedHashMap works incorrectly after clear()

[Alexey Goncharuk]

Guys, I think we can definitely change current implementation of CLHM with
a more stable one, but as a temporal solution I see nothing wrong with
throwing an UnsupportedOperationException from clear() method. Ilya already
provided a patch which replaces all clear() calls with a new map creation,
semantically it has the same behavior as a correct clear() method.

I suggest to merge the provided PR because IgniteH2Indexing is broken
because of this bug and then create a ticket to replace/fix/whatever it
feels right to do with current CLHM.

Thoughts?

пт, 27 июл. 2018 г. в 16:43, Anton Vinogradov :

> Is it possible to replace current implementation with google's [1] or some
> other?
> It a bad idea to have own CLHM and keep it outdated (this version based on
> CHM from java7!) and broken.
>
> [1]
>
> https://mvnrepository.com/artifact/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru
>
> пт, 27 июл. 2018 г. в 16:40, Ilya Kasnacheev :
>
> > Hello!
> >
> > Most of our code uses CLHM as a container with fixed size. I can surely
> fix
> > LogThrottle but my main concern is H2 indexing code which uses the same
> > CLHM with cap.
> >
> > Regards,
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-07-27 16:38 GMT+03:00 Maxim Muzafarov :
> >
> > > Ilya,
> > >
> > > As for me, the main cause of this problem is not in CLHM itself but
> that
> > > we are using it for GridLogThrottle as container with fixed size.
> > Suppose,
> > > at current moment we have no alternative and should start thinking
> about
> > > futher steps.
> > >
> > > Can you create clear reproducer for described issue with CLHM above?
> > >
> > > As workaround for GridLogThrottle we can change clear() like this:
> > >
> > > public static void clear() {
> > > errors.forEach((k, v) -> errors.remove(k));
> > > }
> > >
> > > Will it helps you to fix test?
> > >
> > > Thoughts?
> > >
> > > On Wed, 25 Jul 2018 at 19:57 Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > LT stops throttling input as soon as it is unable to add any entries
> to
> > > > underlying map since it would consider itself full with 0 entries.
> > > >
> > > > I have tried to implement both suggestions, and they all have big
> > impact
> > > on
> > > > CLHM code. I am super uncomfortable with making non-trivial edits to
> > it.
> > > >
> > > > If the first approach is chosen, there's the need to iterate values
> > > instead
> > > > of clearing table, and if second approach is chosen, locking becomes
> > > > non-trivial since we're grabbing segment locks outside of segment
> > code..
> > > >
> > > > Changing LongAdder to AtomicLong also has potential implications
> which
> > > are
> > > > not readily understood.
> > > >
> > > > Note that entryQ is not cleared in clear() either which can cause
> > further
> > > > problems. My suggestion is still to either disallow clear() or throw
> > this
> > > > class away in its entirety.
> > > >
> > > > Regards,
> > > >
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > > 2018-07-25 12:00 GMT+03:00 Maxim Muzafarov :
> > > >
> > > > > Hello Ilya,
> > > > >
> > > > > Can you add more info about why and how LT for this test case
> prints
> > > log
> > > > > message twice?
> > > > >
> > > > > From my point, maiking clear() method to throw
> > > > > UnsupportedOperationException is not right
> > > > > fix for flaky test issues. A brief search through CLHM led me to a
> > > > thought
> > > > > that we just forgot to drop down
> > > > > LongAdder size when iterating over HashEntry array. We incrementing
> > and
> > > > > decrementing this
> > > > > counter on put/remove operations by why not in clear method? Am I
> > > right?
> > > > > So, replacing LongAdder to AtomicLong
> > > > > sounds good to me too, as it was suggested by Ilya Lantukh. But I
> can
> > > > > mistake here.
> > > > >
> > > > > In general way, I think it's a good case to start thinking about
> how
> > to
> > > > get
> > > > > rid of CLHM. E.g. we can consider this implementaion [1].
> > > > >
> > > > > [1] https://github.com/ben-manes/concurrentlinkedhashmap
> > > > >
> > > > > вт, 24 июл. 2018 г. в 16:45, Stanislav Lukyanov <
> > > stanlukya...@gmail.com
> > > > >:
> > > > >
> > > > > > It seems that we currently use the CLHM primarily as a FIFO
> cache.
> > > > > > I see two ways around that.
> > > > > >
> > > > > > First, we could implement such LRU/FIFO cache based on another,
> > > > properly
> > > > > > supported data structure from j.u.c.
> > > > > > ConcurrentSkipListMap seems OK. I have a draft implementation of
> > > > > > LruEvictionPolicy based on it that passes functional tests,
> > > > > > but I haven’t benchmarked it yet.
> > > > > >
> > > > > > Second, Guava has a Cache API with a lot of configuration options
> > > that
> > > > we
> > > > > > could use (license is Apache, should be OK).
> > > > > >
> > > > > > Stan
> > > > > >
> > > > > > From: Nikolay Izhikov
> > > > > > Sent: 24 июля 2018 г. 16:27
> 

C++ Thin client. JVM dependency.

[Nikolay Izhikov]

Hello, Igniters.

I have a question from one of an early adopter of Ignite C++ thin client.
Seems, that our C++ thin client depends on JVM lib.

thin-client [1] depends on libignite, and libignite depends on jvm libs [2].

Is that correct?
Why do we need it?
I thought that a thin client is a binary protocol with minimum dependencies.
Do we have the plan to reduce that dependency?

Igor, can you comment on this?

[1] 
https://github.com/apache/ignite/blob/master/modules/platforms/cpp/thin-client/Makefile.am#L40
[2] 
https://github.com/apache/ignite/blob/master/modules/platforms/cpp/core/Makefile.am#L30

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

Re: Is there a partial document missing in the section of the data grid?

[李玉珏]

Oh, sorry, found it.


在 2018/8/9 下午8:39, Ilya Kasnacheev 写道:

Hello!

I am able to find all of those under
https://apacheignite.readme.io/docs/cache-configuration subsection in
"Key-Value Data Grid" section.

Regards,

TDE Implementation details.

[Nikolay Izhikov]

Hello, Igniters.

I want to share with you TDE implementation details.
I think it can simplify review and acception of TDE implementation.
This mail is copy of wiki page [1].

Please, share your thoughts.

TDE is ready for review [2]. 
Please, let me know, who is able to make final review.

This document describes some internal details of TDE.Phase 1 implementation [3].
I suggest that reader familiar with the general design described in IEP-18 [4]. 


Cache group key management and node join enhancements: 

1. GridEncryptionManager encapsulates all logic related to key 
management: 
a. All group encryption keys are stored in MetaStore.

b. Joining node sends to cluster:
* Master key digest. 
* All group keys saved locally (Map). 
Keys send over a network in encrypted form.

c. Coordinator on new node join:
* Compares new node master key digest with the local 
master key digest. 
If differs then new node join is rejected.

* Compares local and received group keys.
If some key differs then new node join is rejected. 

d. All server nodes:
* If some of received keys are new then they save 
locally.

2. Dynamic cache creation:
a. On server node - Encryption key is generated and added to 
DynamicCacheChangeRequest.

b. On client node:
* Prior to creation of DynamicCacheChangeRequest we 
have to get new encryption key from some server node.
* New request added to solve this - 
GenerateEncryptionKeyRequest.


WAL Record encryption: 


1. New type of WAL record created – EncryptedRecord.

2. EncryptedRecord is a container that stores some 
WalRecordCacheGroupAware in encrypted form inside.

3. Write:
Each record for an encrypted group that implements 
WalRecordCacheGroupAware written to WAL in encrypted form.
Instead of that record we write EncryptedRecord with plain record 
inside(PageSnapshot, PageDeltaRecord, etc).

4. Read: There are 3 different cases on EncryptedRecord read:
a. WAL restore – we read EncryptedRecord, decrypt internal 
record and return it.

b. Offline WAL iteration(StandaloneWalRecordsIterator) - 
EncryptionSpi is null so wecan’t decrypt EncryptedRecord and just return it 
from an iterator.

c. Meta storage restore process – On node start we restore 
MetaStore.
When we do it no encryption keys are available, because they 
are stored in MetaStore.
So we can’t decrypt EncryptedRecord and just return it from an 
iterator.  
We don't need decrypted record on this step to operate properly.


Page encryption: 


1. We have to write on disk pages aligned on 2^n (2kb, 4kb, etc) for 
gain maximum perfrormance. 

2. There is a 16 byte overhead for and AES CBC mode. 

3. So we have to preserve 16 bytes in page in memory to get encrypted 
page size equal to 2^n when written it to disk. 

4. PageIO has many methods with pageSize parameter. 
So for encrypted cache groups page size is calculated as 
cfg.getPageSize() - 16 byte. 


[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89067473
[2] https://github.com/apache/ignite/pull/4167
[3] https://issues.apache.org/jira/browse/IGNITE-8485
[4] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-18%3A+Transparent+Data+Encryption
 


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

[GitHub] ignite pull request #4505: IGNITE-9196 Fix memory leak in MapNodeResults

[dmekhanikov]

GitHub user dmekhanikov opened a pull request:

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

IGNITE-9196 Fix memory leak in MapNodeResults



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

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

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

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


commit bc6377008fa62f1217a5cd54bae34f6ad4d809d0
Author: Denis Mekhanikov 
Date:   2018-08-09T12:43:46Z

IGNITE-9196 Fix memory leak in MapNodeResults.




---

Re: Is there a partial document missing in the section of the data grid?

[Ilya Kasnacheev]

Hello!

I am able to find all of those under
https://apacheignite.readme.io/docs/cache-configuration subsection in
"Key-Value Data Grid" section.

Regards,

-- 
Ilya Kasnacheev

2018-08-09 14:56 GMT+03:00 李玉珏@163 <18624049...@163.com>:

> Hi,
>
> Some pages are missing in the latest version of the data grid
> document,why？Is there anyone who can confirm it?
>
> https://apacheignite.readme.io/v2.4/docs/cache-modes
>
> https://apacheignite.readme.io/v2.4/docs/partition-loss-policies
>
> https://apacheignite.readme.io/v2.4/docs/primary-and-backup-copies
>
> https://apacheignite.readme.io/v2.4/docs/cache-groups
>
>
>

[GitHub] ignite pull request #4485: ignite-8888 write fix

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4504: IGNITE-9219 Uncomment tests in IgniteCacheTestSui...

[alamar]

GitHub user alamar opened a pull request:

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

IGNITE-9219 Uncomment tests in IgniteCacheTestSuite4, minor fixes.



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

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

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

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


commit bf6b49e29026ecf6117751d10e73db1c2dc7c05f
Author: Ilya Kasnacheev 
Date:   2018-08-09T12:15:28Z

IGNITE-9219 Uncomment tests in IgniteCacheTestSuite4, minor fixes.




---

[GitHub] ignite pull request #4503: Ignite 9238

[xtern]

GitHub user xtern opened a pull request:

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

Ignite 9238



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

$ git pull https://github.com/xtern/ignite IGNITE-9238

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

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


commit 89edf34f40f9f8464df691e72758b3be9736e2a6
Author: pereslegin-pa 
Date:   2018-08-09T11:36:45Z

IGNITE-9238 Fixes incorrect forcing client to reconnect when the affinity 
version is already updated but the exchange future is not fully completed.

commit 421263660c9e7939fce39ce71fe3e0b268342918
Author: pereslegin-pa 
Date:   2018-08-09T11:53:16Z

IGNITE-9238 Minor code cleanup.




---

Re: [MTCGA]: new failures in builds [1570331] needs to be handled

[Maxim Muzafarov]

Dmitry,

Sure, I've already informed author about this issue. Hope he will have time
to look at.  I see no problems fixing it myself if fix will be simple. In
other
cases I doubt my ability of fixing complex .NET tests.

On Wed, 8 Aug 2018 at 19:08 Dmitriy Pavlov  wrote:

> This change will trigger master every time if free agent percent >50%
> longer than 10 minutes. And likelihood that was just one commit in each
> runall is increased. But it is not 100% because several commit may be done
> while TC was loaded.
>
> Contributed change is not bisect based on git revisions,- I hope this
> change will be also contributed some day.
>
> About this failure, could you please contact author directly or using dev.
> list with ask to contribute fix?
>
> ср, 8 авг. 2018 г. в 18:38, Maxim Muzafarov :
>
> > Dmitry,
> >
> > Good news.
> > How can I trigger build\MTCGA.Bot to find the problem commit?
> >
> > As for this case I've already found commit who caused the test to fall.
> > I don't know how to fix this problem. Probably, we slould conslut with
> > author to find out the right case.
> >
> > On Wed, 8 Aug 2018 at 18:29 Dmitriy Pavlov 
> wrote:
> >
> > > Ok, let's fill priority and version for new failures.
> > >
> > > About locating changes, which break particular build:
> > >
> > > Thanks to Pavel Pereslegin for his recent contribution to MTCGA.Bot.
> > Patch
> > > allows to adaptively trigger 'run all' in case there are enought of
> free
> > > agents. So it will be easier to locate particular commit.
> > >
> > > ср, 8 авг. 2018 г. в 17:42, Dmitriy Setrakyan :
> > >
> > > > Dmitriy, yes, if you set it as blocker and assign it to the next
> > release,
> > > > the likelihood of someone looking at it before the release will
> > increase.
> > > > We should follow this practice for all new test failures.
> > > >
> > > > Moreover, if someone's change caused a new test failure, then we
> should
> > > try
> > > > to contact that person on the dev list and bring it to his/her
> > attention.
> > > >
> > > > D.
> > > >
> > > > On Wed, Aug 8, 2018 at 7:25 AM, Dmitriy Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Dmitriy,
> > > > >
> > > > > Would it increase likelihood that somebody will pick up this ticket
> > if
> > > we
> > > > > will set blocker priority?
> > > > >
> > > > > If it would increase I totally agree. IMO, JIRA priorities do not
> > have
> > > > much
> > > > > effect on community members, do it?
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > вт, 7 авг. 2018 г. в 14:00, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > >
> > > > > > Maxim, if it is a new failure, why is it filed as Minor and is
> not
> > > > > assigned
> > > > > > to any release? I would suggest that any new failure should be
> > filed
> > > > as a
> > > > > > Blocker and assigned to the next release.
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Tue, Aug 7, 2018 at 12:55 AM, Maxim Muzafarov <
> > maxmu...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > Seems this is a new failures due to last changes.
> > > > > > > I've created new issue [1].
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9202
> > > > > > >
> > > > > > > On Fri, 3 Aug 2018 at 20:57  wrote:
> > > > > > >
> > > > > > > > Hi Ignite Developer,
> > > > > > > >
> > > > > > > > I am MTCGA.Bot, and I've detected some issue on TeamCity to
> be
> > > > > > addressed.
> > > > > > > > I hope you can help.
> > > > > > > >
> > > > > > > >  *New test failure in master
> > > > > > > > ExamplesTest.TestRemoteNodes(BinaryModeExample)
> > > > > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > > > > IgniteTests24Java8=-3155722801840665529=%
> > > > > > > 3Cdefault%3E=testDetails
> > > > > > > >
> > > > > > > >  *New test failure in master
> ExamplesTest.TestRemoteNodes(
> > > > > > > LinqExample)
> > > > > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > > > > IgniteTests24Java8=8941219717117543602=%
> > > > > > > 3Cdefault%3E=testDetails
> > > > > > > >
> > > > > > > >  *New test failure in master
> ExamplesTest.TestRemoteNodes(
> > > > > > > SqlExample)
> > > > > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > > > > IgniteTests24Java8=-61288549283153227=%
> > > > > > > 3Cdefault%3E=testDetails
> > > > > > > >  Changes may led to failure were done by
> > > > > > > >  - nsamelchev
> > > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > > 827132=false
> > > > > > > >  - biryukovvitaliy92
> > > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > > 827130=false
> > > > > > > >  - ppozerov
> > > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > > 827122=false
> > > > > > > >  - ppozerov
> > > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 

[GitHub] ignite pull request #3315: IGNITE-7251 Remove term "fabric" from Ignite deli...

[vveider]

Github user vveider closed the pull request at:

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


---

[jira] [Created] (IGNITE-9241) TcpClusterNode.isClient semantic is broken.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-9241:


 Summary: TcpClusterNode.isClient semantic is broken.
 Key: IGNITE-9241
 URL: https://issues.apache.org/jira/browse/IGNITE-9241
 Project: Ignite
  Issue Type: Bug
Reporter: Andrew Mashenkov
 Fix For: 2.7


For now TcpClusterNode.isClient() cal return false is client mode is started 
with forced server mode.
 ServerMode is feature of TcpClusterNode (concrete implementation of 
ClusterNode).

We should fix isClient semantic e.g. to use node attributes and introduce 
separate internal isRingNode() as a part of concrete implementation (not 
interface) that can be used in TcpDiscoverySpi.

Also, seems forceServerMode should be deprecated [1]


 [1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html



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

[GitHub] ignite pull request #4497: IGNITE-9225

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Deprecate force server mode for clients.

[Pavel Kovalenko]

Andrey,

Huge +1 for that.
"Force server mode" increases the complexity of understanding how cluster
in ring mode works without real benefits.
If a user wants to start client node first before server nodes have
started, he can adjust timeouts on connection and spin till a client is
connected. Ability to join client node to topology without server nodes
looks dubious.
As we have thin clients and Zookeeper Discovery SPI this mode looks like a
crutch and should be removed.

2018-08-09 12:41 GMT+03:00 Andrey Mashenkov :

> Hi Igniters,
>
> I've found that KernalContext.clientNode() and TcpDusciveryNode.isClient()
> means different and it looks confusing.
>
> 1. The first one return true if "node is configured as client" and false
> otherwise,
> 2. The second one can return false if server mode is forced for client (via
> TcpDiscoverySpi.setForceServerMode(true)) ,
>  so actually true value means "a client node is out of the ring".
>
> Thus, TcpDiscoveryNode.isClient() semantic is broken and  we can get
> confusing results on client node with forced server mode,
> when kernalContext.clientNode() return true and
> kernalContex.localNode().isClient() return false.
>
> Also, we have a number of places in code where node.isClient() method is
> used.
>
> My suggestion is
> 1. Deprecate force server mode and plan to remove it to next major release.
> 2. Fix TcpDiscoveryNode,isClient() semantic e.g. to use node attributes to
> make ClusterNode.isClient method consistent with node configuration.
> 2. Add isRingNode (possibly package private) with current
> TcpDiscoveryNode.isClient() semantic to preserve compatibility.
>
> Any pros or cons?
>
> --
> Best regards,
> Andrey V. Mashenkov
>

[jira] [Created] (IGNITE-9240) Web console: plus sign not clickable on low resolution

[Stepan Pilschikov (JIRA)]

Stepan Pilschikov created IGNITE-9240:
-

 Summary: Web console: plus sign not clickable on low resolution
 Key: IGNITE-9240
 URL: https://issues.apache.org/jira/browse/IGNITE-9240
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Stepan Pilschikov
 Attachments: image-2018-08-09-12-37-13-907.png

path: /configuration/advanced/clusters
Binary configuration panel
On resolution less then 960px plus sign in Type configurations going under 
parent element and becoming not clickable

Also this behavior correct for others configuration elements except addresses

!image-2018-08-09-12-37-13-907.png!



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

Re: Service grid redesign

[Vyacheslav Daradur]

Hi, Igniters!

I found a ticket about a service’s versioning [1].

It’s out of scope IEP-17, but if we are going to implement this
feature we should build a base in the first iteration of IEP-17
because of change messages formats.

In case of the versioning which assumes that we are able to host
services with the same name, but with different class/version, we
should introduce *service’s id* to manage service’s lifecycle instead
of service’s name.

Thoughts?


[1] https://issues.apache.org/jira/browse/IGNITE-6069
On Sat, Jul 28, 2018 at 3:51 AM Dmitriy Setrakyan  wrote:
>
> Anton, clients could be remote, not local. However, even if I agreed with
> you, we cannot remove the current functionality from the product.
>
> As suggested, by default services are deployed only on server nodes. If a
> user wants to involve client nodes, then it should be done by specifying a
> node filter. This is how the system works today. Let's not change it for no
> good reason.
>
> D.
>
> On Fri, Jul 27, 2018 at 3:31 AM, Anton Vinogradov  wrote:
>
> > Denis,
> >
> > Main features of Ignite Cache are availability and throughput.
> >
> > I'd like to refactor Serviсe Grid to be the same.
> > Main feature should be guarantee of availability and throughput (instance
> > count).
> >
> > Client should ask grid to execute the service, that's all. No matter how
> > grid will do this.
> > This should be like cache 'put' or 'get' call.
> >
> > In case you want to execute something locally you should just implement it
> > inside your application rather than deploy it to Ignite Cluster.
> > There are absolutely no reason to mix local services and Service Grid.
> >
> > P.s. As for me, all "local" features should be deprecated, since we're
> > distributed.
> >
> > чт, 26 июл. 2018 г. в 21:13, Denis Mekhanikov :
> >
> > > Anton,
> > >
> > > I believe, there are cases, when people want to have node singleton
> > > services, that are deployed to clients, as well as to all other nodes.
> > > And currently clients can execute compute jobs, issued by other clients,
> > > and services are not very different from them.
> > > Clients may store data and run code. We shouldn't consider them as
> > > "end-user nodes". Only thin clients should be run by end users.
> > >
> > > But I agree, that we shouldn't encourage people to use services this way.
> > > So, if it doesn't complicate the implementation too much, then a warning
> > in
> > > log will be enough, I think.
> > >
> > > Denis
> > >
> > > чт, 26 июл. 2018 г. в 19:56, Anton Vinogradov :
> > >
> > > > Folks,
> > > >
> > > > I don't think that it's a good idea to host services on client nodes.
> > > > Client topology is not stable enough, and I don't see how to guarantee
> > > > availability of such services.
> > > > We'll have huge problems to guarantee availability in case of blinking
> > > > clients.
> > > >
> > > > Also, taking into account that ignite cluster can have more that one
> > user
> > > > it looks odd that one user able to start service at another user's
> > > hardware
> > > > (bitcoin miners can be disagree with me).
> > > >
> > > > In case you want to use nodes only to host services - all you need is
> > to
> > > > filter them from cache affinity functions.
> > > >
> > > > I propose to implement Services pretty close to Cache implementation.
> > > > It's a bad idea to reinvent the weel there.
> > > > Let's just analyse Cache's code and do the same for services with same
> > > > guarantee.
> > > >
> > > > ср, 25 июл. 2018 г. в 21:58, Vyacheslav Daradur :
> > > >
> > > > > Denis, long service initialization isn't a big problem for us.
> > > > >
> > > > > The problem is hung initialization, that means the service deployment
> > > > > will never complete.
> > > > > On Wed, Jul 25, 2018 at 8:08 PM Denis Mekhanikov <
> > > dmekhani...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > I think, that this timeout shouldn't be mandatory, and it should be
> > > > > > disabled by default.
> > > > > > We should be ready for long service initialization. So, it
> > shouldn't
> > > be
> > > > > > done in any crucial threads like discovery or exchange.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > ср, 25 июл. 2018 г. в 15:59, Vyacheslav Daradur <
> > daradu...@gmail.com
> > > >:
> > > > > >
> > > > > > > FYI, I've filled the tickets:
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-9075
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-9076
> > > > > > > On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <
> > > > > daradu...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I think such timeout should be determined on per-service
> > level.
> > > > > Can we
> > > > > > > make
> > > > > > > > > it part of the service configuration, or pass it into deploy
> > > > > method?
> > > > > > > >
> > > > > > > > Agree, per ServiceConfiguration level is more flexible
> > solution.
> > > > > > > >
> > > > > > > > > This is a 

Deprecate force server mode for clients.

[Andrey Mashenkov]

Hi Igniters,

I've found that KernalContext.clientNode() and TcpDusciveryNode.isClient()
means different and it looks confusing.

1. The first one return true if "node is configured as client" and false
otherwise,
2. The second one can return false if server mode is forced for client (via
TcpDiscoverySpi.setForceServerMode(true)) ,
 so actually true value means "a client node is out of the ring".

Thus, TcpDiscoveryNode.isClient() semantic is broken and  we can get
confusing results on client node with forced server mode,
when kernalContext.clientNode() return true and
kernalContex.localNode().isClient() return false.

Also, we have a number of places in code where node.isClient() method is
used.

My suggestion is
1. Deprecate force server mode and plan to remove it to next major release.
2. Fix TcpDiscoveryNode,isClient() semantic e.g. to use node attributes to
make ClusterNode.isClient method consistent with node configuration.
2. Add isRingNode (possibly package private) with current
TcpDiscoveryNode.isClient() semantic to preserve compatibility.

Any pros or cons?

-- 
Best regards,
Andrey V. Mashenkov

[jira] [Created] (IGNITE-9239) [ML] KMeansTrainer crashed if amount of possible clusters more than amount of partitions in dataset

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-9239:


 Summary: [ML] KMeansTrainer crashed if amount of possible clusters 
more than amount of partitions in dataset
 Key: IGNITE-9239
 URL: https://issues.apache.org/jira/browse/IGNITE-9239
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


How to reproduce?

Set the K parameter in KMeans Trainer to 100, and run KMeansClusterization 
Example

\

StackTrace is

Exception in thread "KMeansClusterizationExample-#44" 
java.lang.RuntimeException: java.lang.IllegalArgumentException: bound must be 
positive
 at 
org.apache.ignite.ml.clustering.kmeans.KMeansTrainer.fit(KMeansTrainer.java:112)
 at 
org.apache.ignite.ml.clustering.kmeans.KMeansTrainer.fit(KMeansTrainer.java:46)
 at org.apache.ignite.ml.trainers.DatasetTrainer.fit(DatasetTrainer.java:68)
 at 
org.apache.ignite.examples.ml.clustering.KMeansClusterizationExample.lambda$main$0(KMeansClusterizationExample.java:60)
 at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: bound must be positive
 at java.util.Random.nextInt(Random.java:388)
 at 
org.apache.ignite.ml.clustering.kmeans.KMeansTrainer.initClusterCentersRandomly(KMeansTrainer.java:193)
 at 
org.apache.ignite.ml.clustering.kmeans.KMeansTrainer.fit(KMeansTrainer.java:86)
 ... 4 more

 

 

The possible solution :

correct the mechanism of rndPnts computation in the row 180-190 in KMeansTrainer



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

[GitHub] ignite pull request #4313: IGNITE-8714

[NSAmelchev]

Github user NSAmelchev closed the pull request at:

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


---

[GitHub] ignite pull request #3815: IGNITE-7024

[NSAmelchev]

Github user NSAmelchev closed the pull request at:

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


---

[GitHub] ignite pull request #4501: IGNITE-8493 GridToStringBuilder arrayToString ref...

[zstan]

GitHub user zstan opened a pull request:

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

IGNITE-8493 GridToStringBuilder arrayToString refactoring.



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

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

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

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


commit 05438f8fed26e2b0dac34349062b8c10f96fabad
Author: Evgeny Stanilovskiy 
Date:   2018-08-09T07:22:37Z

IGNITE-8493 GridToStringBuilder arrayToString refactoring.




---

[GitHub] ignite pull request #3999: IGNITE-8493: refactor arrayToString, decrease hea...

[zstan]

Github user zstan closed the pull request at:

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


---

[GitHub] ignite pull request #4500: #ignite example - Readme.txt typo fix

[k4utech]

GitHub user k4utech opened a pull request:

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

#ignite example - Readme.txt typo fix

I believe there is typo error (he instead of the)  in  README.txt inside 
example folder. Please look into this if pull request stand correct take 
necessary action.

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

$ git pull https://github.com/k4utech/ignite example-readme

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

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


commit 5994263c41a7f5dddfc17a36e894ea5d0479cd6c
Author: Kishor 
Date:   2018-08-09T06:13:36Z

#ignite example - Readme.txt typo fix




---