[jira] [Updated] (IGNITE-12718) Python Thin Client: add an ability to specify keyfile password
[
https://issues.apache.org/jira/browse/IGNITE-12718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-12718:
--
Fix Version/s: (was: 2.9)
python-0.4.0
> Python Thin Client: add an ability to specify keyfile password
> --
>
> Key: IGNITE-12718
> URL: https://issues.apache.org/jira/browse/IGNITE-12718
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
> Labels: Python, SSL, TLS
> Fix For: python-0.4.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In pyignite, there is no way to specify password for keyfile being used to
> establish TLS connection to Ignite cluster. If keyfile is encrypted, then
> OpenSSL library prompts for password interactively.
> In order to add configurable password, one can set up explicit {{SSLContext}}
> instead of {{ssl.wrap_socket}} call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10358) thin python: put collections have no data type specification
[ https://issues.apache.org/jira/browse/IGNITE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-10358: -- Fix Version/s: (was: python-0.4.0) > thin python: put collections have no data type specification > > > Key: IGNITE-10358 > URL: https://issues.apache.org/jira/browse/IGNITE-10358 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.7 >Reporter: Stepan Pilschikov >Assignee: Dmitry Melnichuk >Priority: Major > Labels: python > Fix For: 2.8 > > > Trying to put collection with Integers through python thin client and get > through others clients > Value type in others clients specified as "collection with Integers" > > During GET operation clients throwing exceptions that "type wrong, expected > Integer type but getting Long type" (because python collection data types are > not specified) > Python put and php and js get code/output: > https://gist.github.com/pilshchikov/7ba7a7a2568c758b7b8680ba9a4215f5 > Also same behavior right for Map data type -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10358) thin python: put collections have no data type specification
[ https://issues.apache.org/jira/browse/IGNITE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-10358: -- Fix Version/s: python-0.4.0 > thin python: put collections have no data type specification > > > Key: IGNITE-10358 > URL: https://issues.apache.org/jira/browse/IGNITE-10358 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.7 >Reporter: Stepan Pilschikov >Assignee: Dmitry Melnichuk >Priority: Major > Labels: python > Fix For: 2.8, python-0.4.0 > > > Trying to put collection with Integers through python thin client and get > through others clients > Value type in others clients specified as "collection with Integers" > > During GET operation clients throwing exceptions that "type wrong, expected > Integer type but getting Long type" (because python collection data types are > not specified) > Python put and php and js get code/output: > https://gist.github.com/pilshchikov/7ba7a7a2568c758b7b8680ba9a4215f5 > Also same behavior right for Map data type -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14418) Document asyncio version of python ignite thin client
[ https://issues.apache.org/jira/browse/IGNITE-14418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316940#comment-17316940 ] Ivan Daschinskiy commented on IGNITE-14418: --- [~isapego] Hi, could you please review? Examples of doc attached > Document asyncio version of python ignite thin client > - > > Key: IGNITE-14418 > URL: https://issues.apache.org/jira/browse/IGNITE-14418 > Project: Ignite > Issue Type: New Feature > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14472) Performance drop on primitive operations.
[ https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14472: -- Fix Version/s: python-0.4.0 > Performance drop on primitive operations. > - > > Key: IGNITE-14472 > URL: https://issues.apache.org/jira/browse/IGNITE-14472 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python, thin > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Reason of performance drop: header struct of Response is not cached (now it > is instance variable, earlier it will be class variable) > Performance drop approx 15 %. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14472) Performance drop on primitive operations.
[
https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314748#comment-17314748
]
Ivan Daschinskiy commented on IGNITE-14472:
---
*before*
{code}
benchmark 'binary_object_get': 12 tests
Name (time in us) Min Max
Mean StdDevMedian
IQROutliers OPSRounds Iterations
-
benchmark_sync_binary_get[simple-1024] 503.3497 (1.0)542.5109
(1.0)524.7468 (1.0) 11.9913 (1.29) 527.0175 (1.0)
11.3102 (1.0) 4;0 1,905.6809 (1.0) 10 100
benchmark_sync_binary_get[simple-4096] 545.7228 (1.08) 681.6326
(1.26) 573.7108 (1.09) 38.6286 (4.17) 562.4087 (1.07)
11.4088 (1.01) 1;1 1,743.0386 (0.91) 10 100
benchmark_sync_binary_get[simple-10240] 557.1264 (1.11) 663.1032
(1.22) 597.0065 (1.14) 28.5202 (3.08) 592.0662 (1.12)
20.9598 (1.85) 2;1 1,675.0237 (0.88) 10 100
benchmark_async_binary_get[simple-1024] 709.6196 (1.41) 749.4574
(1.38) 722.3022 (1.38) 14.1358 (1.52) 716.2776 (1.36)
24.3055 (2.15) 3;0 1,384.4621 (0.73) 10 100
benchmark_async_binary_get[simple-4096] 749.6903 (1.49) 779.9036
(1.44) 764.4456 (1.46) 9.2736 (1.0)763.2206 (1.45)
11.5306 (1.02) 4;0 1,308.1376 (0.69) 10 100
benchmark_async_binary_get[simple-10240] 768.9985 (1.53) 796.4124
(1.47) 786.9617 (1.50) 10.5591 (1.14) 790.4466 (1.50)
16.7354 (1.48) 2;0 1,270.7099 (0.67) 10 100
benchmark 'binary_object_put': 12 tests
Name (time in us) Min Max
Mean StdDevMedian
IQROutliers OPSRounds Iterations
-
benchmark_sync_binary_put[simple-1024] 422.0449 (1.0)443.4763
(1.0)430.9277 (1.0)7.2775 (1.08) 429.2968 (1.0)
11.3402 (1.41) 3;0 2,320.5747 (1.0) 10 100
benchmark_sync_binary_put[simple-4096] 432.6478 (1.03) 454.3953
(1.02) 444.2581 (1.03) 6.7669 (1.0)445.7960 (1.04)
8.0276 (1.0) 3;0 2,250.9438 (0.97) 10 100
benchmark_sync_binary_put[simple-10240] 474.8603 (1.13) 515.2363
(1.16) 496.1305 (1.15) 13.6759 (2.02) 498.2116 (1.16)
20.8986 (2.60) 3;0 2,015.5987 (0.87) 10 100
benchmark_async_binary_put[simple-1024] 535.3795 (1.27) 685.1283
(1.54) 567.3985 (1.32) 44.3217 (6.55) 548.0161 (1.28)
33.4157 (4.16) 1;1 1,762.4297 (0.76) 10 100
benchmark_async_binary_put[simple-4096] 571.5587 (1.35) 616.8044
(1.39) 592.2703 (1.37) 14.5426 (2.15) 591.8616 (1.38)
18.8717 (2.35) 4;0 1,688.4183 (0.73) 10 100
benchmark_async_binary_put[simple-10240] 622.7088 (1.48) 714.9631
(1.61) 656.8940 (1.52) 26.2311 (3.88) 655.6965 (1.53)
33.0954 (4.12) 2;0 1,522.3156 (0.66) 10 100
{code}
*after*
{code}
benchmark 'binary_object_get': 12 tests
Name (time in us) Min Max
Mean StdDevMedian
IQROutliers OPSRounds Iterations
[jira] [Commented] (IGNITE-14472) Performance drop on primitive operations.
[
https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314747#comment-17314747
]
Ivan Daschinskiy commented on IGNITE-14472:
---
*Before*:
{code}
--
benchmark 'string_get': 10 tests
--
Name (time in us)Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
--
benchmark_sync_string_get[simple-128] 352.9188 (1.0) 373.0795 (1.0)
361.5633 (1.0) 7.3642 (2.16) 361.9580 (1.0) 10.8843 (2.59)
3;02.7658 (1.0) 101000
benchmark_sync_string_get[simple-256] 358.5299 (1.02) 383.5096 (1.03)
370.6923 (1.03) 7.7361 (2.27) 370.2248 (1.02) 4.1944 (1.0)
3;32.6977 (0.98) 101000
benchmark_sync_string_get[simple-1024] 364.8562 (1.03) 388.6522 (1.04)
375.3570 (1.04) 7.2215 (2.12) 375.6628 (1.04) 9.5607 (2.28)
3;02.6641 (0.96) 101000
benchmark_sync_string_get[simple-2048] 392.4290 (1.11) 402.3911 (1.08)
396.3332 (1.10) 3.4034 (1.0) 395.3264 (1.09) 5.2861 (1.26)
3;02.5231 (0.91) 101000
benchmark_sync_string_get[simple-4096] 418.6008 (1.19) 452.7802 (1.21)
426.6729 (1.18) 10.5182 (3.09) 422.9948 (1.17) 10.8302 (2.58)
1;12.3437 (0.85) 101000
benchmark_async_string_get[simple-128] 516.2550 (1.46) 552.0531 (1.48)
530.5335 (1.47) 9.8132 (2.88) 531.2685 (1.47) 9.8281 (2.34)
2;11.8849 (0.68) 101000
benchmark_async_string_get[simple-256] 524.5846 (1.49) 572.8096 (1.54)
537.5614 (1.49) 13.5860 (3.99) 536.4263 (1.48) 11.1575 (2.66)
1;11.8603 (0.67) 101000
benchmark_async_string_get[simple-1024] 524.7691 (1.49) 560.3995 (1.50)
544.3051 (1.51) 12.3997 (3.64) 542.4853 (1.50) 21.1719 (5.05)
4;01.8372 (0.66) 101000
benchmark_async_string_get[simple-2048] 547.0813 (1.55) 586.5175 (1.57)
563.1756 (1.56) 13.3071 (3.91) 558.9927 (1.54) 17.0010 (4.05)
3;01.7756 (0.64) 101000
benchmark_async_string_get[simple-4096] 564.6848 (1.60) 615.9083 (1.65)
586.0929 (1.62) 17.1826 (5.05) 587.9250 (1.62) 28.2196 (6.73)
3;01.7062 (0.62) 101000
--
--
benchmark 'string_put': 10 tests
--
Name (time in us)Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
--
benchmark_sync_string_put[simple-256] 325.9658 (1.0) 351.0994 (1.0)
337.2916 (1.0) 8.5597 (1.32) 337.3050 (1.0) 9.4780 (1.68)
4;02.9648 (1.0) 101000
benchmark_sync_string_put[simple-128] 334.7044 (1.03) 357.9547 (1.02)
343.1400 (1.02) 7.7337 (1.19) 342.2236 (1.01) 5.6582 (1.0)
4;22.9143 (0.98) 101000
benchmark_sync_string_put[simple-1024] 339.7010 (1.04) 370.3226 (1.05)
352.4340 (1.04) 11.0125 (1.69) 350.4053 (1.04) 20.6439 (3.65)
5;02.8374 (0.96) 101000
benchmark_sync_string_put[simple-2048] 361.9507 (1.11) 384.4600 (1.10)
372.5959 (1.10) 6.5051 (1.0) 371.9587 (1.10) 8.3985 (1.48)
3;02.6839 (0.91) 101000
benchmark_sync_string_put[simple-4096] 388.3225 (1.19) 421.1529 (1.20)
399.8351 (1.19) 9.5191 (1.46) 399.2213 (1.18) 7.5771 (1.34)
3;1
[jira] [Commented] (IGNITE-14472) Performance drop on primitive operations.
[
https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314745#comment-17314745
]
Ivan Daschinskiy commented on IGNITE-14472:
---
Benchmark examples
*before:*
{code}
benchmark 'long_get': 2 tests
Name (time in us) Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
---
benchmark_sync_long_get[simple] 335.3812 (1.0) 359.0669 (1.0)
343.4707 (1.0) 7.9492 (1.0) 341.8763 (1.0) 5.8493 (1.0)
3;22.9115 (1.0) 101000
benchmark_async_long_get[simple] 489.9539 (1.46) 532.6032 (1.48)
513.4271 (1.49) 12.8345 (1.61) 514.0811 (1.50) 20.5015 (3.50)
2;01.9477 (0.67) 101000
---
---
benchmark 'long_put': 2 tests
Name (time in us) Min Max
MeanStdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
--
benchmark_sync_long_put[simple] 310.4296 (1.0) 323.5723 (1.0)
316.5834 (1.0) 3.6066 (1.0) 316.7651 (1.0) 3.9376 (1.0)
2;03.1587 (1.0) 101000
benchmark_async_long_put[simple] 417.9511 (1.35) 442.7839 (1.37)
431.7079 (1.36) 9.5637 (2.65) 433.7149 (1.37) 20.4647 (5.20)
6;02.3164 (0.73) 101000
--
{code}
*after:*
{code}
benchmark 'long_get': 2 tests
Name (time in us) Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
---
benchmark_sync_long_get[simple] 282.0120 (1.0) 306.0031 (1.0)
291.5331 (1.0) 7.8233 (1.0) 290.0198 (1.0) 12.3822 (1.0)
3;03.4301 (1.0) 101000
benchmark_async_long_get[simple] 430.0521 (1.52) 484.0667 (1.58)
446.6028 (1.53) 19.2004 (2.45) 437.3707 (1.51) 20.9369 (1.69)
2;02.2391 (0.65) 101000
---
benchmark 'long_put': 2 tests
Name (time in us) Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
---
benchmark_sync_long_put[simple] 283.3018 (1.0) 313.3918 (1.0)
296.9479 (1.0) 8.7095 (1.0) 295.4214 (1.0) 13.2546 (1.0)
2;03.3676 (1.0) 101000
benchmark_async_long_put[simple] 381.2551 (1.35) 419.1923 (1.34)
[jira] [Commented] (IGNITE-11854) Serialization of arrays of primitives in python thin client is not optimal
[
https://issues.apache.org/jira/browse/IGNITE-11854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314724#comment-17314724
]
Ivan Daschinskiy commented on IGNITE-11854:
---
{code:java}
- benchmark
'binary_object_get': 1 tests
Name (time in ms) Min Max
Mean StdDev Median IQR Outliers OPS Rounds Iterations
-
benchmark_sync_binary_get[partition_aware-10485760] 44.4116 47.2139
45.2577 0.8969 44.9754 1.3467 1;0 22.0957 10 100
-
- benchmark
'binary_object_put': 1 tests
Name (time in ms) Min Max
Mean StdDev Median IQR Outliers OPS Rounds Iterations
-
benchmark_sync_binary_put[partition_aware-10485760] 35.5823 37.1995
36.4751 0.4259 36.5096 0.3459 2;2 27.4160 10 100
-
{code}
And this is for partition aware client, 4 ignite server nodes, 8Gb heap, 16 Gb
offheap
> Serialization of arrays of primitives in python thin client is not optimal
> --
>
> Key: IGNITE-11854
> URL: https://issues.apache.org/jira/browse/IGNITE-11854
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: python-0.4.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The following code hangs indefinitely inside of invocation to
> {{my_cache.put()}}
> {code:java}
> from pyignite import Client
> arr_len = 3_000_000
> content = bytearray(arr_len)
> for i in range(arr_len):
> content[i] = i % 256
> client = Client()
> client.connect('127.0.0.1', 10800)
> my_cache = client.get_or_create_cache('my cache')
> my_cache.put("key_bin", content){code}
> While the value is only 3MB in size. Implementation of serialization of
> primitive arrays seems to be quadratic in length of the array.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11854) Serialization of arrays of primitives in python thin client is not optimal
[
https://issues.apache.org/jira/browse/IGNITE-11854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314717#comment-17314717
]
Ivan Daschinskiy commented on IGNITE-11854:
---
[~dmekhanikov] Currently, serialization-deserialization are fully reworked,
moreover, hashcode caclulation are now much faster due to C module
Here is some benchmarks (put-get) of BinaryObject with 10Mb field
{code:java}
benchmark 'binary_object_get':
1 tests
Name (time in ms) Min Max Mean
StdDev Median IQR Outliers OPS Rounds Iterations
benchmark_sync_binary_get[simple-10485760] 67.7753 73.2509 70.5726
1.6236 70.5608 1.9794 3;0 14.1698 10 100
benchmark 'binary_object_put':
1 tests
Name (time in ms) Min Max Mean
StdDev Median IQR Outliers OPS Rounds Iterations
benchmark_sync_binary_put[simple-10485760] 61.6861 66.3933 63.5946
1.7068 62.9506 3.0117 3;0 15.7246 10 100
{code}
70ms for get and 60ms for put doesn't seems to be infinite, does it? And this
is without partition awareness :)
> Serialization of arrays of primitives in python thin client is not optimal
> --
>
> Key: IGNITE-11854
> URL: https://issues.apache.org/jira/browse/IGNITE-11854
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Dmitry Melnichuk
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The following code hangs indefinitely inside of invocation to
> {{my_cache.put()}}
> {code:java}
> from pyignite import Client
> arr_len = 3_000_000
> content = bytearray(arr_len)
> for i in range(arr_len):
> content[i] = i % 256
> client = Client()
> client.connect('127.0.0.1', 10800)
> my_cache = client.get_or_create_cache('my cache')
> my_cache.put("key_bin", content){code}
> While the value is only 3MB in size. Implementation of serialization of
> primitive arrays seems to be quadratic in length of the array.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-11854) Serialization of arrays of primitives in python thin client is not optimal
[
https://issues.apache.org/jira/browse/IGNITE-11854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-11854:
-
Fix Version/s: python-0.4.0
Assignee: Ivan Daschinskiy (was: Dmitry Melnichuk)
Resolution: Fixed
> Serialization of arrays of primitives in python thin client is not optimal
> --
>
> Key: IGNITE-11854
> URL: https://issues.apache.org/jira/browse/IGNITE-11854
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: python-0.4.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The following code hangs indefinitely inside of invocation to
> {{my_cache.put()}}
> {code:java}
> from pyignite import Client
> arr_len = 3_000_000
> content = bytearray(arr_len)
> for i in range(arr_len):
> content[i] = i % 256
> client = Client()
> client.connect('127.0.0.1', 10800)
> my_cache = client.get_or_create_cache('my cache')
> my_cache.put("key_bin", content){code}
> While the value is only 3MB in size. Implementation of serialization of
> primitive arrays seems to be quadratic in length of the array.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14465) Add the ability to activate the cluster via the Python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314201#comment-17314201 ] Ivan Daschinskiy commented on IGNITE-14465: --- [~isapego] I suppose that fix is ok, proceed with merge, please > Add the ability to activate the cluster via the Python thin client > -- > > Key: IGNITE-14465 > URL: https://issues.apache.org/jira/browse/IGNITE-14465 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.3.4 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.4.0 > > Time Spent: 3h > Remaining Estimate: 0h > > This feature will be extremely useful when working with clusters that have > the "persistenceEnabled" option. Since they require activation to get > started. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14472) Performance drop on primitive operations.
[ https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14472: - Assignee: Ivan Daschinskiy > Performance drop on primitive operations. > - > > Key: IGNITE-14472 > URL: https://issues.apache.org/jira/browse/IGNITE-14472 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python, thin > > Reason of performance drop: header struct of Response is not cached (now it > is instance variable, earlier it will be class variable) > Performance drop approx 15 %. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14472) Performance drop on primitive operations.
Ivan Daschinskiy created IGNITE-14472: - Summary: Performance drop on primitive operations. Key: IGNITE-14472 URL: https://issues.apache.org/jira/browse/IGNITE-14472 Project: Ignite Issue Type: Bug Components: python, thin client Affects Versions: python-0.4.0 Reporter: Ivan Daschinskiy Reason of performance drop: header struct of Response is not cached (now it is instance variable, earlier it will be class variable) Performance drop approx 15 %. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14465) Add the ability to activate the cluster via the Python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313816#comment-17313816 ] Ivan Daschinskiy commented on IGNITE-14465: --- [~isapego] Ok, suggested some changes in personal conversation. > Add the ability to activate the cluster via the Python thin client > -- > > Key: IGNITE-14465 > URL: https://issues.apache.org/jira/browse/IGNITE-14465 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.3.4 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > This feature will be extremely useful when working with clusters that have > the "persistenceEnabled" option. Since they require activation to get > started. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14162) Python thin gives ambiguous message when using a wrong username/password to connect
[
https://issues.apache.org/jira/browse/IGNITE-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy resolved IGNITE-14162.
---
Resolution: Fixed
> Python thin gives ambiguous message when using a wrong username/password to
> connect
> ---
>
> Key: IGNITE-14162
> URL: https://issues.apache.org/jira/browse/IGNITE-14162
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Affects Versions: python-0.3.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: python-0.4.0
>
>
> Starting a server w/authentication, then connecting to it via a python thin
> client w/an incorrect username and password.
> The message/stacktrace is ambiguous leading clients to believe that they've
> connected, and something is amiss w/the server.
> {code:python}client = Client(username='incorrect-user-name',
> password='incorrect-password', use_ssl=False)
> client.connect('127.0.0.1', 10800)
> #client(nodes)
> print("connected to: ".format(client))
> print("cache names: ".format(client.get_cache_names)){code}
> the stacktrace is :
> {code:python}connected to:
> Traceback (most recent call last):
> cache names:
> File "C:/dev/python-thin-client/examples/get_and_put.py", line 30, in
>
> print(client.get_cache_names())
> File "C:\dev\python-thin-client\pyignite\utils.py", line 249, in ste_wrapper
> result = fn(*args, **kwargs)
> File "C:\dev\python-thin-client\pyignite\client.py", line 521, in
> get_cache_names
> return cache_get_names(self.random_node)
> File "C:\dev\python-thin-client\pyignite\utils.py", line 273, in wrapper
> return func(obj, *args, **kwargs)
> File "C:\dev\python-thin-client\pyignite\client.py", line 222, in
> random_node
> raise ReconnectError('Can not reconnect: out of nodes.') from None
> pyignite.exceptions.ReconnectError: Can not reconnect: out of nodes.{code}
> *ReconnectError: Can not reconnect: out of nodes exception*: allows the user
> to make the conclusion that the connection is successful, but something is
> wrong with the server.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14444) Move affinity calculation and storage to client
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311680#comment-17311680 ] Ivan Daschinskiy commented on IGNITE-1: --- [~isapego] Hi, patch is ready for review > Move affinity calculation and storage to client > --- > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Labels: python > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > In current implementation, affinity storage and affinity calculation are > located in cache. > It is not optimal: > 1. affinity is not shared between Cache instance with same name > 2. affinity mapping requests per cache and add additional loads. > 3. if we start implementing transactions or expiry policy, this can be an > issue. > I propose to move affinity storage to Client and AioClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14444) Move affinity calculation and storage to client
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-1: -- Affects Version/s: python-0.4.0 > Move affinity calculation and storage to client > --- > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Labels: python > > In current implementation, affinity storage and affinity calculation are > located in cache. > It is not optimal: > 1. affinity is not shared between Cache instance with same name > 2. affinity mapping requests per cache and add additional loads. > 3. if we start implementing transactions or expiry policy, this can be an > issue. > I propose to move affinity storage to Client and AioClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14444) Move affinity calculation and storage to client
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-1: - Assignee: Ivan Daschinskiy > Move affinity calculation and storage to client > --- > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Labels: python > > In current implementation, affinity storage and affinity calculation are > located in cache. > It is not optimal: > 1. affinity is not shared between Cache instance with same name > 2. affinity mapping requests per cache and add additional loads. > 3. if we start implementing transactions or expiry policy, this can be an > issue. > I propose to move affinity storage to Client and AioClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14444) Move affinity calculation and storage to client
Ivan Daschinskiy created IGNITE-1: - Summary: Move affinity calculation and storage to client Key: IGNITE-1 URL: https://issues.apache.org/jira/browse/IGNITE-1 Project: Ignite Issue Type: Improvement Components: python Reporter: Ivan Daschinskiy In current implementation, affinity storage and affinity calculation are located in cache. It is not optimal: 1. affinity is not shared between Cache instance with same name 2. affinity mapping requests per cache and add additional loads. 3. if we start implementing transactions or expiry policy, this can be an issue. I propose to move affinity storage to Client and AioClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13405) [Pyignite] Invalid cache configuration parameters
[ https://issues.apache.org/jira/browse/IGNITE-13405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13405: -- Fix Version/s: python-0.4.0 > [Pyignite] Invalid cache configuration parameters > - > > Key: IGNITE-13405 > URL: https://issues.apache.org/jira/browse/IGNITE-13405 > Project: Ignite > Issue Type: Bug > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Smirnov >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python > Fix For: python-0.4.0 > > Original Estimate: 1h > Time Spent: 20m > Remaining Estimate: 40m > > Invalid argument for prop_partition_loss_policy in python thin client that > affects the cache creation > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13405) [Pyignite] Invalid cache configuration parameters
[ https://issues.apache.org/jira/browse/IGNITE-13405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13405: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > [Pyignite] Invalid cache configuration parameters > - > > Key: IGNITE-13405 > URL: https://issues.apache.org/jira/browse/IGNITE-13405 > Project: Ignite > Issue Type: Bug > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Smirnov >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python > Fix For: python-0.4.0 > > Original Estimate: 1h > Time Spent: 0.5h > Remaining Estimate: 0.5h > > Invalid argument for prop_partition_loss_policy in python thin client that > affects the cache creation > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13405) [Pyignite] Invalid cache configuration parameters
[ https://issues.apache.org/jira/browse/IGNITE-13405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311326#comment-17311326 ] Ivan Daschinskiy commented on IGNITE-13405: --- [~iamnotaprogrammer] Ivan, there are some other issues with CacheConfiguration. I fixed all of them (and your also) and add additional tests. Thanks for highlighting this! I realy appreciate your effort. > [Pyignite] Invalid cache configuration parameters > - > > Key: IGNITE-13405 > URL: https://issues.apache.org/jira/browse/IGNITE-13405 > Project: Ignite > Issue Type: Bug > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Smirnov >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python > Original Estimate: 1h > Time Spent: 20m > Remaining Estimate: 40m > > Invalid argument for prop_partition_loss_policy in python thin client that > affects the cache creation > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13405) [Pyignite] Invalid cache configuration parameters
[ https://issues.apache.org/jira/browse/IGNITE-13405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-13405: - Assignee: Ivan Daschinskiy > [Pyignite] Invalid cache configuration parameters > - > > Key: IGNITE-13405 > URL: https://issues.apache.org/jira/browse/IGNITE-13405 > Project: Ignite > Issue Type: Bug > Components: python >Reporter: Ivan Smirnov >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python > Original Estimate: 1h > Time Spent: 10m > Remaining Estimate: 50m > > Invalid argument for prop_partition_loss_policy in python thin client that > affects the cache creation > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14429) Python thin client cache.get_size works not as expected and PeekModes are incorrect.
[ https://issues.apache.org/jira/browse/IGNITE-14429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310561#comment-17310561 ] Ivan Daschinskiy commented on IGNITE-14429: --- [~isapego] Hi, patch is ready for review > Python thin client cache.get_size works not as expected and PeekModes are > incorrect. > > > Key: IGNITE-14429 > URL: https://issues.apache.org/jira/browse/IGNITE-14429 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: python-0.4.0 > > > 1. PeekModes is now ByteArray, so class variables should be changed. > Currently these values are incorrect, seems like masks. They should be > changed to ordinal values in order to resemble java enum. > 2. By default, peek_modes in get_size should be None, not 0 > * If pass 0, behaviour is not if we use PeekModes.ALL, but PeekModes.PRIMARY -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14429) Python thin client cache.get_size works not as expected and PeekModes are incorrect.
[ https://issues.apache.org/jira/browse/IGNITE-14429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14429: -- Fix Version/s: python-0.4.0 > Python thin client cache.get_size works not as expected and PeekModes are > incorrect. > > > Key: IGNITE-14429 > URL: https://issues.apache.org/jira/browse/IGNITE-14429 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: python-0.4.0 > > > 1. PeekModes is now ByteArray, so class variables should be changed. > Currently these values are incorrect, seems like masks. They should be > changed to ordinal values in order to resemble java enum. > 2. By default, peek_modes in get_size should be None, not 0 > * If pass 0, behaviour is not if we use PeekModes.ALL, but PeekModes.PRIMARY -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14429) Python thin client cache.get_size works not as expected and PeekModes are incorrect.
[ https://issues.apache.org/jira/browse/IGNITE-14429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14429: - Assignee: Ivan Daschinskiy > Python thin client cache.get_size works not as expected and PeekModes are > incorrect. > > > Key: IGNITE-14429 > URL: https://issues.apache.org/jira/browse/IGNITE-14429 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > 1. PeekModes is now ByteArray, so class variables should be changed. > Currently these values are incorrect, seems like masks. They should be > changed to ordinal values in order to resemble java enum. > 2. By default, peek_modes in get_size should be None, not 0 > * If pass 0, behaviour is not if we use PeekModes.ALL, but PeekModes.PRIMARY -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14432) Python thin: Support "with" statement for connection method
[
https://issues.apache.org/jira/browse/IGNITE-14432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310457#comment-17310457
]
Ivan Daschinskiy commented on IGNITE-14432:
---
[~isapego] Hi, patch is ready for review.
> Python thin: Support "with" statement for connection method
> ---
>
> Key: IGNITE-14432
> URL: https://issues.apache.org/jira/browse/IGNITE-14432
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Igor Sapego
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: python-0.4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [pep-0343|https://www.python.org/dev/peps/pep-0343/]
> instead of this:
> {code:python}client.connect(environ['DB_HOST'], int(environ['DB_PORT']))
> try:
> return client.sql(q, query_args=q_args, include_field_names=True)
> finally:
> client.close(){code}
> The user will be able to use this:
> {code:python}with client.connect(environ['DB_HOST'], int(environ['DB_PORT'])):
> return client.sql(q, query_args=q_args, include_field_names=True){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14432) Python thin: Support "with" statement for connection method
[
https://issues.apache.org/jira/browse/IGNITE-14432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-14432:
-
Assignee: Ivan Daschinskiy
> Python thin: Support "with" statement for connection method
> ---
>
> Key: IGNITE-14432
> URL: https://issues.apache.org/jira/browse/IGNITE-14432
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Igor Sapego
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: python-0.4.0
>
>
> [pep-0343|https://www.python.org/dev/peps/pep-0343/]
> instead of this:
> {code:python}client.connect(environ['DB_HOST'], int(environ['DB_PORT']))
> try:
> return client.sql(q, query_args=q_args, include_field_names=True)
> finally:
> client.close(){code}
> The user will be able to use this:
> {code:python}with client.connect(environ['DB_HOST'], int(environ['DB_PORT'])):
> return client.sql(q, query_args=q_args, include_field_names=True){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14432) Python thin: Support "with" statement for connection method
[
https://issues.apache.org/jira/browse/IGNITE-14432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-14432:
--
Issue Type: Improvement (was: Bug)
> Python thin: Support "with" statement for connection method
> ---
>
> Key: IGNITE-14432
> URL: https://issues.apache.org/jira/browse/IGNITE-14432
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Igor Sapego
>Priority: Major
> Fix For: python-0.4.0
>
>
> [pep-0343|https://www.python.org/dev/peps/pep-0343/]
> instead of this:
> {code:python}client.connect(environ['DB_HOST'], int(environ['DB_PORT']))
> try:
> return client.sql(q, query_args=q_args, include_field_names=True)
> finally:
> client.close(){code}
> The user will be able to use this:
> {code:python}with client.connect(environ['DB_HOST'], int(environ['DB_PORT'])):
> return client.sql(q, query_args=q_args, include_field_names=True){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13862) Python Thin Client: put_all operation results in connection timeout
[ https://issues.apache.org/jira/browse/IGNITE-13862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309569#comment-17309569 ] Ivan Daschinskiy commented on IGNITE-13862: --- Not reproduced on recent master, test was added to cover this case. > Python Thin Client: put_all operation results in connection timeout > > > Key: IGNITE-13862 > URL: https://issues.apache.org/jira/browse/IGNITE-13862 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Archita Sukhwani >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > put_all operation with a huge dictionary of say 1 keys results in > connection timeout, same happens with multiple consecutive put operations > using a for loop unless a sleep statement is executed between each put > operation. > [Reproducible > code|https://stackoverflow.com/questions/65303573/pyignite-connection-timeout-error-when-trying-to-load-json-into-cache-using-put] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13862) Python Thin Client: put_all operation results in connection timeout
[ https://issues.apache.org/jira/browse/IGNITE-13862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-13862: - Fix Version/s: python-0.4.0 Assignee: Ivan Daschinskiy > Python Thin Client: put_all operation results in connection timeout > > > Key: IGNITE-13862 > URL: https://issues.apache.org/jira/browse/IGNITE-13862 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Archita Sukhwani >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > put_all operation with a huge dictionary of say 1 keys results in > connection timeout, same happens with multiple consecutive put operations > using a for loop unless a sleep statement is executed between each put > operation. > [Reproducible > code|https://stackoverflow.com/questions/65303573/pyignite-connection-timeout-error-when-trying-to-load-json-into-cache-using-put] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14429) Python thin client cache.get_size works not as expected and PeekModes are incorrect.
Ivan Daschinskiy created IGNITE-14429: - Summary: Python thin client cache.get_size works not as expected and PeekModes are incorrect. Key: IGNITE-14429 URL: https://issues.apache.org/jira/browse/IGNITE-14429 Project: Ignite Issue Type: Bug Components: python, thin client Reporter: Ivan Daschinskiy 1. PeekModes is now ByteArray, so class variables should be changed. Currently these values are incorrect, seems like masks. They should be changed to ordinal values in order to resemble java enum. 2. By default, peek_modes in get_size should be None, not 0 * If pass 0, behaviour is not if we use PeekModes.ALL, but PeekModes.PRIMARY -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14422) Version management for ducktape.
[
https://issues.apache.org/jira/browse/IGNITE-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-14422:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Version management for ducktape.
>
>
> Key: IGNITE-14422
> URL: https://issues.apache.org/jira/browse/IGNITE-14422
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinskiy
>Priority: Major
> Labels: IEP-56
>
> I propose following:
> 1. Add to {{update-versions}} task a sub-task, that bumps versions in
> {{ignitetests.__init__.py}} (i.e. {{2.11-SNAPSHOT}} to {{2.11-dev}})
> 2. Change {{ignitetests.versions.DEV}} to
> {{IgniteVersion(ignitetests.__version__)}}
> This automatically set {{DEV}} as latest version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14422) Version management for ducktape.
[
https://issues.apache.org/jira/browse/IGNITE-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-14422:
--
Description:
I propose following:
1. Add to {{update-versions}} task a sub-task, that bumps versions in
{{ignitetests.__init__.py}} (i.e. {{2.11-SNAPSHOT}} to {{2.11-dev}})
2. Change {{ignitetests.versions.DEV}} to
{{IgniteVersion(ignitetests.__version__)}}
This automatically set {{DEV}} as latest version.
was:
I propose following:
1. Add to {{update-versions}} task a sub-task, that bumps versions in
{{ignitetests.__init__.py}} (i.e. {{2.11-SNAPSHOT}} to {{2.11-dev}})
2. Change `ignitetests.versions.DEV` to `IgniteVersion(ignitetests.__version__)`
This automatically set `DEV` as latest version.
> Version management for ducktape.
>
>
> Key: IGNITE-14422
> URL: https://issues.apache.org/jira/browse/IGNITE-14422
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinskiy
>Priority: Major
> Labels: IEP-56
>
> I propose following:
> 1. Add to {{update-versions}} task a sub-task, that bumps versions in
> {{ignitetests.__init__.py}} (i.e. {{2.11-SNAPSHOT}} to {{2.11-dev}})
> 2. Change {{ignitetests.versions.DEV}} to
> {{IgniteVersion(ignitetests.__version__)}}
> This automatically set {{DEV}} as latest version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14422) Version management for ducktape.
[
https://issues.apache.org/jira/browse/IGNITE-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-14422:
--
Description:
I propose following:
1. Add to {{update-versions}} task a sub-task, that bumps versions in
{{ignitetests.__init__.py}} (i.e. {{2.11-SNAPSHOT}} to {{2.11-dev}})
2. Change `ignitetests.versions.DEV` to `IgniteVersion(ignitetests.__version__)`
This automatically set `DEV` as latest version.
was:
I propose following:
1. Add to `update-versions` task a sub-task, that bumps versions in
`ignitetests.__init__.py` (i.e. `2.11-SNAPSHOT` to `2.11-dev`)
2. Change `ignitetests.versions.DEV` to `IgniteVersion(ignitetests.__version__)`
This automatically set `DEV` as latest version.
> Version management for ducktape.
>
>
> Key: IGNITE-14422
> URL: https://issues.apache.org/jira/browse/IGNITE-14422
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinskiy
>Priority: Major
> Labels: IEP-56
>
> I propose following:
> 1. Add to {{update-versions}} task a sub-task, that bumps versions in
> {{ignitetests.__init__.py}} (i.e. {{2.11-SNAPSHOT}} to {{2.11-dev}})
> 2. Change `ignitetests.versions.DEV` to
> `IgniteVersion(ignitetests.__version__)`
> This automatically set `DEV` as latest version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14422) Version management for ducktape.
Ivan Daschinskiy created IGNITE-14422: - Summary: Version management for ducktape. Key: IGNITE-14422 URL: https://issues.apache.org/jira/browse/IGNITE-14422 Project: Ignite Issue Type: Improvement Reporter: Ivan Daschinskiy I propose following: 1. Add to `update-versions` task a sub-task, that bumps versions in `ignitetests.__init__.py` (i.e. `2.11-SNAPSHOT` to `2.11-dev`) 2. Change `ignitetests.versions.DEV` to `IgniteVersion(ignitetests.__version__)` This automatically set `DEV` as latest version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14418) Document asyncio version of python ignite thin client
[ https://issues.apache.org/jira/browse/IGNITE-14418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14418: - Assignee: Ivan Daschinskiy > Document asyncio version of python ignite thin client > - > > Key: IGNITE-14418 > URL: https://issues.apache.org/jira/browse/IGNITE-14418 > Project: Ignite > Issue Type: New Feature > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14418) Document asyncio version of python ignite thin client
Ivan Daschinskiy created IGNITE-14418: - Summary: Document asyncio version of python ignite thin client Key: IGNITE-14418 URL: https://issues.apache.org/jira/browse/IGNITE-14418 Project: Ignite Issue Type: New Feature Components: python, thin client Reporter: Ivan Daschinskiy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13911) asyncio version of python ignite thin client
[ https://issues.apache.org/jira/browse/IGNITE-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299522#comment-17299522 ] Ivan Daschinskiy commented on IGNITE-13911: --- [~isapego] Hi, patch is ready for review > asyncio version of python ignite thin client > > > Key: IGNITE-13911 > URL: https://issues.apache.org/jira/browse/IGNITE-13911 > Project: Ignite > Issue Type: New Feature > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, asyncio is default event-loop and coroutine engine for python > 3.6+. This approach can drastically improve performance of IO-bound tasks. So > it is important to implement asyncio version of python ignite client. Old > synchronous version should remain and share common code with asyncio version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14245) Infinite loop while trying to get affinity mapping on failed node
[ https://issues.apache.org/jira/browse/IGNITE-14245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291404#comment-17291404 ] Ivan Daschinskiy commented on IGNITE-14245: --- [~isapego] Also, travis also fixed > Infinite loop while trying to get affinity mapping on failed node > - > > Key: IGNITE-14245 > URL: https://issues.apache.org/jira/browse/IGNITE-14245 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currenlty, it's possible to jump in infinite loop trying to reconnect to > failed node while requesting affinity mapping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14245) Infinite loop while trying to get affinity mapping on failed node
[ https://issues.apache.org/jira/browse/IGNITE-14245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14245: - Assignee: Ivan Daschinskiy > Infinite loop while trying to get affinity mapping on failed node > - > > Key: IGNITE-14245 > URL: https://issues.apache.org/jira/browse/IGNITE-14245 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > Currenlty, it's possible to jump in infinite loop trying to reconnect to > failed node while requesting affinity mapping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14245) Infinite loop while trying to get affinity mapping on failed node
Ivan Daschinskiy created IGNITE-14245: - Summary: Infinite loop while trying to get affinity mapping on failed node Key: IGNITE-14245 URL: https://issues.apache.org/jira/browse/IGNITE-14245 Project: Ignite Issue Type: Bug Components: python, thin client Reporter: Ivan Daschinskiy Currenlty, it's possible to jump in infinite loop trying to reconnect to failed node while requesting affinity mapping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14240) Handle authentication error on python thin client properly
[ https://issues.apache.org/jira/browse/IGNITE-14240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290256#comment-17290256 ] Ivan Daschinskiy commented on IGNITE-14240: --- It's ok that build is failed, some steps need to be removed after merging this fix. (unrecognized options due to removal of these options, no ssl suite run separately) > Handle authentication error on python thin client properly > -- > > Key: IGNITE-14240 > URL: https://issues.apache.org/jira/browse/IGNITE-14240 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, connect succeeded with invalid creds, only after first cache > operation error appears -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14240) Handle authentication error on python thin client properly
[ https://issues.apache.org/jira/browse/IGNITE-14240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290257#comment-17290257 ] Ivan Daschinskiy commented on IGNITE-14240: --- [~isapego] Patch is ready for review > Handle authentication error on python thin client properly > -- > > Key: IGNITE-14240 > URL: https://issues.apache.org/jira/browse/IGNITE-14240 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, connect succeeded with invalid creds, only after first cache > operation error appears -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14240) Handle authentication error on python thin client properly
[ https://issues.apache.org/jira/browse/IGNITE-14240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14240: - Assignee: Ivan Daschinskiy > Handle authentication error on python thin client properly > -- > > Key: IGNITE-14240 > URL: https://issues.apache.org/jira/browse/IGNITE-14240 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, connect succeeded with invalid creds, only after first cache > operation error appears -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14240) Handle authentication error on python thin client properly
[ https://issues.apache.org/jira/browse/IGNITE-14240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14240: -- Description: Currently, connect succeeded with invalid creds, only after first cache operation error appears > Handle authentication error on python thin client properly > -- > > Key: IGNITE-14240 > URL: https://issues.apache.org/jira/browse/IGNITE-14240 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Priority: Major > > Currently, connect succeeded with invalid creds, only after first cache > operation error appears -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14240) Handle authentication error on python thin client properly
Ivan Daschinskiy created IGNITE-14240: - Summary: Handle authentication error on python thin client properly Key: IGNITE-14240 URL: https://issues.apache.org/jira/browse/IGNITE-14240 Project: Ignite Issue Type: Bug Components: python, thin client Reporter: Ivan Daschinskiy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14186) Develop C module for python thin client to speedup hashcode calculation
[ https://issues.apache.org/jira/browse/IGNITE-14186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14186: -- Fix Version/s: python-0.4.0 > Develop C module for python thin client to speedup hashcode calculation > --- > > Key: IGNITE-14186 > URL: https://issues.apache.org/jira/browse/IGNITE-14186 > Project: Ignite > Issue Type: Improvement > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: python-0.4.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Pure python calculation of hashcode is very slow. It leads to inadequate > performance of simple operation. > For example, put object with 1Mb data takes 500ms. > After rewriting hashcode in C, operation tooks only 7ms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14186) Develop C module for python thin client to speedup hashcode calculation
[ https://issues.apache.org/jira/browse/IGNITE-14186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284811#comment-17284811 ] Ivan Daschinskiy commented on IGNITE-14186: --- [~isapego] Patch is ready for review > Develop C module for python thin client to speedup hashcode calculation > --- > > Key: IGNITE-14186 > URL: https://issues.apache.org/jira/browse/IGNITE-14186 > Project: Ignite > Issue Type: Improvement > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Pure python calculation of hashcode is very slow. It leads to inadequate > performance of simple operation. > For example, put object with 1Mb data takes 500ms. > After rewriting hashcode in C, operation tooks only 7ms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14186) Develop C module for python thin client to speedup hashcode calculation
[ https://issues.apache.org/jira/browse/IGNITE-14186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14186: - Assignee: Ivan Daschinskiy > Develop C module for python thin client to speedup hashcode calculation > --- > > Key: IGNITE-14186 > URL: https://issues.apache.org/jira/browse/IGNITE-14186 > Project: Ignite > Issue Type: Improvement > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > Pure python calculation of hashcode is very slow. It leads to inadequate > performance of simple operation. > For example, put object with 1Mb data takes 500ms. > After rewriting hashcode in C, operation tooks only 7ms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14186) Develop C module for python thin client to speedup hashcode calculation
Ivan Daschinskiy created IGNITE-14186: - Summary: Develop C module for python thin client to speedup hashcode calculation Key: IGNITE-14186 URL: https://issues.apache.org/jira/browse/IGNITE-14186 Project: Ignite Issue Type: Improvement Components: python, thin client Reporter: Ivan Daschinskiy Pure python calculation of hashcode is very slow. It leads to inadequate performance of simple operation. For example, put object with 1Mb data takes 500ms. After rewriting hashcode in C, operation tooks only 7ms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14167) Concurrency issues in reconnect. Invalid update strategy of partition update.
[ https://issues.apache.org/jira/browse/IGNITE-14167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284581#comment-17284581 ] Ivan Daschinskiy commented on IGNITE-14167: --- [~isapego] Hi, patch is ready for review > Concurrency issues in reconnect. Invalid update strategy of partition update. > - > > Key: IGNITE-14167 > URL: https://issues.apache.org/jira/browse/IGNITE-14167 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently the code in Connection class is not properly synchronized and > socket can be set to None while reconnecting and sending requests > simultaneously. > Also, reconnections attempt are to short (8 fibonacci sequence items) and > total only 33 > sec. > These issues lead to flaky tests for affinity suite. > *APPEND* Also, there is invalid update of affinity version (stale version > could be written) This lead to invalid partition update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14167) Concurrency issues in reconnect. Invalid update strategy of partition update.
[ https://issues.apache.org/jira/browse/IGNITE-14167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14167: -- Description: Currently the code in Connection class is not properly synchronized and socket can be set to None while reconnecting and sending requests simultaneously. Also, reconnections attempt are to short (8 fibonacci sequence items) and total only 33 sec. These issues lead to flaky tests for affinity suite. *APPEND* Also, there is invalid update of affinity version (stale version could be written) This lead to invalid partition update. was: Currently the code in Connection class is not properly synchronized and socket can be set to None while reconnecting and sending requests simultaneously. Also, reconnections attempt are to short (8 fibonacci sequence items) and total only 33 sec. These issues lead to flaky tests for affinity suite. > Concurrency issues in reconnect. Invalid update strategy of partition update. > - > > Key: IGNITE-14167 > URL: https://issues.apache.org/jira/browse/IGNITE-14167 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > Currently the code in Connection class is not properly synchronized and > socket can be set to None while reconnecting and sending requests > simultaneously. > Also, reconnections attempt are to short (8 fibonacci sequence items) and > total only 33 > sec. > These issues lead to flaky tests for affinity suite. > *APPEND* Also, there is invalid update of affinity version (stale version > could be written) This lead to invalid partition update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14167) Concurrency issues in reconnect. Invalid update strategy of partition update.
[ https://issues.apache.org/jira/browse/IGNITE-14167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14167: -- Summary: Concurrency issues in reconnect. Invalid update strategy of partition update. (was: Concurrency issues in reconnect and too short backoff strategy for reconnect timeout.) > Concurrency issues in reconnect. Invalid update strategy of partition update. > - > > Key: IGNITE-14167 > URL: https://issues.apache.org/jira/browse/IGNITE-14167 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > Currently the code in Connection class is not properly synchronized and > socket can be set to None while reconnecting and sending requests > simultaneously. > Also, reconnections attempt are to short (8 fibonacci sequence items) and > total only 33 > sec. > These issues lead to flaky tests for affinity suite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14167) Concurrency issues in reconnect and too short backoff strategy for reconnect timeout.
Ivan Daschinskiy created IGNITE-14167: - Summary: Concurrency issues in reconnect and too short backoff strategy for reconnect timeout. Key: IGNITE-14167 URL: https://issues.apache.org/jira/browse/IGNITE-14167 Project: Ignite Issue Type: Bug Components: python, thin client Reporter: Ivan Daschinskiy Currently the code in Connection class is not properly synchronized and socket can be set to None while reconnecting and sending requests simultaneously. Also, reconnections attempt are to short (8 fibonacci sequence items) and total only 33 sec. These issues lead to flaky tests for affinity suite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14167) Concurrency issues in reconnect and too short backoff strategy for reconnect timeout.
[ https://issues.apache.org/jira/browse/IGNITE-14167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14167: - Assignee: Ivan Daschinskiy > Concurrency issues in reconnect and too short backoff strategy for reconnect > timeout. > - > > Key: IGNITE-14167 > URL: https://issues.apache.org/jira/browse/IGNITE-14167 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > Currently the code in Connection class is not properly synchronized and > socket can be set to None while reconnecting and sending requests > simultaneously. > Also, reconnections attempt are to short (8 fibonacci sequence items) and > total only 33 > sec. > These issues lead to flaky tests for affinity suite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14154) Remove test test_unsupported_affinity_cache_operation_routed_to_random_node
[ https://issues.apache.org/jira/browse/IGNITE-14154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17282431#comment-17282431 ] Ivan Daschinskiy commented on IGNITE-14154: --- [~isapego] Could you review this change, please? > Remove test test_unsupported_affinity_cache_operation_routed_to_random_node > --- > > Key: IGNITE-14154 > URL: https://issues.apache.org/jira/browse/IGNITE-14154 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Currently, this test simply the same as > test_replicated_cache_operation_routed_to_random_node, but it required custom > affinity function, that is introduced only in 2.9.1. I suggest to remove it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14154) Remove test test_unsupported_affinity_cache_operation_routed_to_random_node
[ https://issues.apache.org/jira/browse/IGNITE-14154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14154: - Assignee: Ivan Daschinskiy > Remove test test_unsupported_affinity_cache_operation_routed_to_random_node > --- > > Key: IGNITE-14154 > URL: https://issues.apache.org/jira/browse/IGNITE-14154 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Currently, this test simply the same as > test_replicated_cache_operation_routed_to_random_node, but it required custom > affinity function, that is introduced only in 2.9.1. I suggest to remove it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14154) Remove test test_unsupported_affinity_cache_operation_routed_to_random_node
Ivan Daschinskiy created IGNITE-14154: - Summary: Remove test test_unsupported_affinity_cache_operation_routed_to_random_node Key: IGNITE-14154 URL: https://issues.apache.org/jira/browse/IGNITE-14154 Project: Ignite Issue Type: Test Reporter: Ivan Daschinskiy Currently, this test simply the same as test_replicated_cache_operation_routed_to_random_node, but it required custom affinity function, that is introduced only in 2.9.1. I suggest to remove it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13967) Refactor and improve performance of python thin client marshaller
[ https://issues.apache.org/jira/browse/IGNITE-13967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280608#comment-17280608 ] Ivan Daschinskiy commented on IGNITE-13967: --- [~isapego] Hi, patch is ready. Could you please review it? > Refactor and improve performance of python thin client marshaller > - > > Key: IGNITE-13967 > URL: https://issues.apache.org/jira/browse/IGNITE-13967 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Labels: python > Time Spent: 10m > Remaining Estimate: 0h > > Currently implemented serialization has questionable design and suffers from > some problems > 1. It is tightly coupled with Client object > 2. It doesn't use protocol feature that total length of message is in the > header, > thus it constantly load from Client some data instead of iteration over byte > array. > 3. It uses some tricky hacks and sometimes new connection is created when > deserializing object. > 4. It constantly allocates bytes (immutable data structure). > I suggest to rewrite serialization and deserialization: > 1. Pass to corresponding methods specific SerDe context + BytesIO > 2. Context can be sync and async and contains specific flags and methods for > loading/uploading binary object schemas > 3. Refactor Client in order to retrieve full packet from socket at once then > pass full packet futher. > These steps can significantly improve performance, reduce amount of > allocations and give > foundation for implementing asyncio version of client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14074) Add ability to skip affinity tests for testing with older ignite versions.
Ivan Daschinskiy created IGNITE-14074: - Summary: Add ability to skip affinity tests for testing with older ignite versions. Key: IGNITE-14074 URL: https://issues.apache.org/jira/browse/IGNITE-14074 Project: Ignite Issue Type: Task Components: python, thin client Reporter: Ivan Daschinskiy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14072) Remove copy-paste of response for different versions
[ https://issues.apache.org/jira/browse/IGNITE-14072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17272843#comment-17272843 ] Ivan Daschinskiy commented on IGNITE-14072: --- [~isapego] Could you please review this fix? > Remove copy-paste of response for different versions > > > Key: IGNITE-14072 > URL: https://issues.apache.org/jira/browse/IGNITE-14072 > Project: Ignite > Issue Type: Task > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently there are many common code in classed Response140 SqlResponse140 > Response130 and SqlResponse130. This should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14072) Remove copy-paste of response for different versions
[ https://issues.apache.org/jira/browse/IGNITE-14072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14072: - Assignee: Ivan Daschinskiy > Remove copy-paste of response for different versions > > > Key: IGNITE-14072 > URL: https://issues.apache.org/jira/browse/IGNITE-14072 > Project: Ignite > Issue Type: Task > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently there are many common code in classed Response140 SqlResponse140 > Response130 and SqlResponse130. This should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14072) Remove copy-paste of response for different versions
Ivan Daschinskiy created IGNITE-14072: - Summary: Remove copy-paste of response for different versions Key: IGNITE-14072 URL: https://issues.apache.org/jira/browse/IGNITE-14072 Project: Ignite Issue Type: Task Components: python, thin client Reporter: Ivan Daschinskiy Currently there are many common code in classed Response140 SqlResponse140 Response130 and SqlResponse130. This should be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14046) Update ducktape version to 0.8.2 in ignite-ducktape module
Ivan Daschinskiy created IGNITE-14046: - Summary: Update ducktape version to 0.8.2 in ignite-ducktape module Key: IGNITE-14046 URL: https://issues.apache.org/jira/browse/IGNITE-14046 Project: Ignite Issue Type: Task Reporter: Ivan Daschinskiy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14003) OOM on creating rebalance iterator while rebalancing cache with large values.
[ https://issues.apache.org/jira/browse/IGNITE-14003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14003: - Assignee: Ivan Daschinskiy > OOM on creating rebalance iterator while rebalancing cache with large values. > - > > Key: IGNITE-14003 > URL: https://issues.apache.org/jira/browse/IGNITE-14003 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.9, 2.8.1, 2.9.1 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Critical > Attachments: ReplicatedCacheRebalanceTest.java > > > Scenario > 1. Start replicated cache on ignite node, memory region approx 6 Gb, heap 1Gb > 2. Load significant amount of data to cache with values approx 200Kb (~20K kv > pairs) > 3. Start another node > First node (supplier) will crash while initializing rebalance iterator with > OOM > Main reason -- all values, to whon pointed from leaf of BTree, are all loaded > to buffer in BPlusTree#ForwardCursor. For replicated cache, 512 iterators for > each partition are created at once. > Reproducer is attached, run it with *-Xmx1G* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14003) OOM on creating rebalance iterator while rebalancing cache with large values.
[ https://issues.apache.org/jira/browse/IGNITE-14003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14003: -- Description: Scenario 1. Start replicated cache on ignite node, memory region approx 6 Gb, heap 1Gb 2. Load significant amount of data to cache with values approx 200Kb (~20K kv pairs) 3. Start another node First node (supplier) will crash while initializing rebalance iterator with OOM Main reason -- all values, to whon pointed from leaf of BTree, are all loaded to buffer in BPlusTree#ForwardCursor. For replicated cache, 512 iterators for each partition are created at once. Reproducer is attached, run it with *-Xmx1G* was: Scenario 1. Start replicated cache on ignite node, memory region approx 6 Gb, heap 1Gb 2. Load significant amount of data to cache with values approx 200Kb (~20K kv pairs) 3. Start another node First node (supplier) will crash while initializing rebalance iterator with OOM Main reason -- all values, to whon pointed from leaf of BTree, are all loaded to buffer in BPlusTree#ForwardCursor. For replicated cache, 512 iterators for each partition are created at once. Reproducer is attached. > OOM on creating rebalance iterator while rebalancing cache with large values. > - > > Key: IGNITE-14003 > URL: https://issues.apache.org/jira/browse/IGNITE-14003 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.9, 2.8.1, 2.9.1 >Reporter: Ivan Daschinskiy >Priority: Critical > Attachments: ReplicatedCacheRebalanceTest.java > > > Scenario > 1. Start replicated cache on ignite node, memory region approx 6 Gb, heap 1Gb > 2. Load significant amount of data to cache with values approx 200Kb (~20K kv > pairs) > 3. Start another node > First node (supplier) will crash while initializing rebalance iterator with > OOM > Main reason -- all values, to whon pointed from leaf of BTree, are all loaded > to buffer in BPlusTree#ForwardCursor. For replicated cache, 512 iterators for > each partition are created at once. > Reproducer is attached, run it with *-Xmx1G* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14003) OOM on creating rebalance iterator while rebalancing cache with large values.
[ https://issues.apache.org/jira/browse/IGNITE-14003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14003: -- Attachment: ReplicatedCacheRebalanceTest.java > OOM on creating rebalance iterator while rebalancing cache with large values. > - > > Key: IGNITE-14003 > URL: https://issues.apache.org/jira/browse/IGNITE-14003 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.9, 2.8.1, 2.9.1 >Reporter: Ivan Daschinskiy >Priority: Critical > Attachments: ReplicatedCacheRebalanceTest.java > > > Scenario > 1. Start replicated cache on ignite node, memory region approx 6 Gb, heap 1Gb > 2. Load significant amount of data to cache with values approx 200Kb (~20K kv > pairs) > 3. Start another node > First node (supplier) will crash while initializing rebalance iterator with > OOM > Main reason -- all values, to whon pointed from leaf of BTree, are all loaded > to buffer in BPlusTree#ForwardCursor. For replicated cache, 512 iterators for > each partition are created at once. > Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14003) OOM on creating rebalance iterator while rebalancing cache with large values.
Ivan Daschinskiy created IGNITE-14003: - Summary: OOM on creating rebalance iterator while rebalancing cache with large values. Key: IGNITE-14003 URL: https://issues.apache.org/jira/browse/IGNITE-14003 Project: Ignite Issue Type: Bug Affects Versions: 2.9.1, 2.8.1, 2.9 Reporter: Ivan Daschinskiy Scenario 1. Start replicated cache on ignite node, memory region approx 6 Gb, heap 1Gb 2. Load significant amount of data to cache with values approx 200Kb (~20K kv pairs) 3. Start another node First node (supplier) will crash while initializing rebalance iterator with OOM Main reason -- all values, to whon pointed from leaf of BTree, are all loaded to buffer in BPlusTree#ForwardCursor. For replicated cache, 512 iterators for each partition are created at once. Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13994) Rebalance huge cache for in-memory cluster
Ivan Daschinskiy created IGNITE-13994: - Summary: Rebalance huge cache for in-memory cluster Key: IGNITE-13994 URL: https://issues.apache.org/jira/browse/IGNITE-13994 Project: Ignite Issue Type: Test Reporter: Ivan Daschinskiy There are some evidence, that rebalancing huge cache without rebalance throttling can cause OOM on supplier. We need to cover this scenario. Scenario: 1. Start two nodes and 1 replicated cache with data region much more than heap. 2. Stop one of the node. 3. Load data to cache almost equal to size of data region. 4. Start node. Goal is to run experiments with parameters 1. Heap size 2. Cache size 3. Rebalance batch size. 4. Rebalance throttle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13994) Rebalance huge cache in the case of in-memory cluster
[ https://issues.apache.org/jira/browse/IGNITE-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13994: -- Summary: Rebalance huge cache in the case of in-memory cluster (was: Rebalance huge cache for in-memory cluster) > Rebalance huge cache in the case of in-memory cluster > - > > Key: IGNITE-13994 > URL: https://issues.apache.org/jira/browse/IGNITE-13994 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Priority: Major > Labels: IEP-56, ducktape > > There are some evidence, that rebalancing huge cache without rebalance > throttling can cause OOM on supplier. We need to cover this scenario. > Scenario: > 1. Start two nodes and 1 replicated cache with data region much more than > heap. > 2. Stop one of the node. > 3. Load data to cache almost equal to size of data region. > 4. Start node. > Goal is to run experiments with parameters > 1. Heap size > 2. Cache size > 3. Rebalance batch size. > 4. Rebalance throttle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13967) Refactor and improve performance of python thin client marshaller
[ https://issues.apache.org/jira/browse/IGNITE-13967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13967: -- Summary: Refactor and improve performance of python thin client marshaller (was: Refactor and imrpove performance of python thin client marshaller) > Refactor and improve performance of python thin client marshaller > - > > Key: IGNITE-13967 > URL: https://issues.apache.org/jira/browse/IGNITE-13967 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Labels: python > > Currently implemented serialization has questionable design and suffers from > some problems > 1. It is tightly coupled with Client object > 2. It doesn't use protocol feature that total length of message is in the > header, > thus it constantly load from Client some data instead of iteration over byte > array. > 3. It uses some tricky hacks and sometimes new connection is created when > deserializing object. > 4. It constantly allocates bytes (immutable data structure). > I suggest to rewrite serialization and deserialization: > 1. Pass to corresponding methods specific SerDe context + BytesIO > 2. Context can be sync and async and contains specific flags and methods for > loading/uploading binary object schemas > 3. Refactor Client in order to retrieve full packet from socket at once then > pass full packet futher. > These steps can significantly improve performance, reduce amount of > allocations and give > foundation for implementing asyncio version of client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13967) Refactor and imrpove performance of python thin client marshaller
Ivan Daschinskiy created IGNITE-13967: - Summary: Refactor and imrpove performance of python thin client marshaller Key: IGNITE-13967 URL: https://issues.apache.org/jira/browse/IGNITE-13967 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Currently implemented serialization has questionable design and suffers from some problems 1. It is tightly coupled with Client object 2. It doesn't use protocol feature that total length of message is in the header, thus it constantly load from Client some data instead of iteration over byte array. 3. It uses some tricky hacks and sometimes new connection is created when deserializing object. 4. It constantly allocates bytes (immutable data structure). I suggest to rewrite serialization and deserialization: 1. Pass to corresponding methods specific SerDe context + BytesIO 2. Context can be sync and async and contains specific flags and methods for loading/uploading binary object schemas 3. Refactor Client in order to retrieve full packet from socket at once then pass full packet futher. These steps can significantly improve performance, reduce amount of allocations and give foundation for implementing asyncio version of client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13911) asyncio version of python ignite thin client
[ https://issues.apache.org/jira/browse/IGNITE-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13911: -- Component/s: thin client > asyncio version of python ignite thin client > > > Key: IGNITE-13911 > URL: https://issues.apache.org/jira/browse/IGNITE-13911 > Project: Ignite > Issue Type: New Feature > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > Currently, asyncio is default event-loop and coroutine engine for python > 3.6+. This approach can drastically improve performance of IO-bound tasks. So > it is important to implement asyncio version of python ignite client. Old > synchronous version should remain and share common code with asyncio version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13604) Ducktests: make a flag to ignore @cluster decorator
[ https://issues.apache.org/jira/browse/IGNITE-13604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13604: -- Release Note: (was: Fixed in [d2924582|https://github.com/apache/ignite/commit/d2924582]) > Ducktests: make a flag to ignore @cluster decorator > --- > > Key: IGNITE-13604 > URL: https://issues.apache.org/jira/browse/IGNITE-13604 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Ivan Daschinskiy >Priority: Major > Labels: IEP-56, ducktape > > Ignore, setup number of nodes externally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13604) Ducktests: make a flag to ignore @cluster decorator
[ https://issues.apache.org/jira/browse/IGNITE-13604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy resolved IGNITE-13604. --- Release Note: Fixed in [d2924582|https://github.com/apache/ignite/commit/d2924582] Assignee: Ivan Daschinskiy Resolution: Fixed > Ducktests: make a flag to ignore @cluster decorator > --- > > Key: IGNITE-13604 > URL: https://issues.apache.org/jira/browse/IGNITE-13604 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Ivan Daschinskiy >Priority: Major > Labels: IEP-56, ducktape > > Ignore, setup number of nodes externally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13911) asyncio version of python ignite thin client
Ivan Daschinskiy created IGNITE-13911: - Summary: asyncio version of python ignite thin client Key: IGNITE-13911 URL: https://issues.apache.org/jira/browse/IGNITE-13911 Project: Ignite Issue Type: Improvement Components: python Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Currently, asyncio is default event-loop and coroutine engine for python 3.6+. This approach can drastically improve performance of IO-bound tasks. So it is important to implement asyncio version of python ignite client. Old synchronous version should remain and share common code with asyncio version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13911) asyncio version of python ignite thin client
[ https://issues.apache.org/jira/browse/IGNITE-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13911: -- Issue Type: New Feature (was: Improvement) > asyncio version of python ignite thin client > > > Key: IGNITE-13911 > URL: https://issues.apache.org/jira/browse/IGNITE-13911 > Project: Ignite > Issue Type: New Feature > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > Currently, asyncio is default event-loop and coroutine engine for python > 3.6+. This approach can drastically improve performance of IO-bound tasks. So > it is important to implement asyncio version of python ignite client. Old > synchronous version should remain and share common code with asyncio version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13903) Python thin client tests automation.
[ https://issues.apache.org/jira/browse/IGNITE-13903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254781#comment-17254781 ] Ivan Daschinskiy commented on IGNITE-13903: --- [~Pavlukhin] Great! Thank you for assitance > Python thin client tests automation. > > > Key: IGNITE-13903 > URL: https://issues.apache.org/jira/browse/IGNITE-13903 > Project: Ignite > Issue Type: Improvement > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Attachments: .asf.yaml > > > It would be nice to futher improve our development process of > python-thin-client > 1. Add docker-compose.yml to simplify local development > 2. Add tox.ini to simplify test running automation > 3. Integrate travis-ci build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13903) Python thin client tests automation.
[ https://issues.apache.org/jira/browse/IGNITE-13903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254620#comment-17254620 ] Ivan Daschinskiy commented on IGNITE-13903: --- [~Pavlukhin] I am ok, but I need some assistant. Could you please provide and attach to this jira correct yaml file for this particular repo? > Python thin client tests automation. > > > Key: IGNITE-13903 > URL: https://issues.apache.org/jira/browse/IGNITE-13903 > Project: Ignite > Issue Type: Improvement > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > It would be nice to futher improve our development process of > python-thin-client > 1. Add docker-compose.yml to simplify local development > 2. Add tox.ini to simplify test running automation > 3. Integrate travis-ci build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13903) Python thin client tests automation.
[ https://issues.apache.org/jira/browse/IGNITE-13903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254569#comment-17254569 ] Ivan Daschinskiy commented on IGNITE-13903: --- [~isapego] Hi, could you please review my patch? > Python thin client tests automation. > > > Key: IGNITE-13903 > URL: https://issues.apache.org/jira/browse/IGNITE-13903 > Project: Ignite > Issue Type: Improvement > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > It would be nice to futher improve our development process of > python-thin-client > 1. Add docker-compose.yml to simplify local development > 2. Add tox.ini to simplify test running automation > 3. Integrate travis-ci build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13903) Python thin client tests automation.
Ivan Daschinskiy created IGNITE-13903: - Summary: Python thin client tests automation. Key: IGNITE-13903 URL: https://issues.apache.org/jira/browse/IGNITE-13903 Project: Ignite Issue Type: Improvement Components: python Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy It would be nice to futher improve our development process of python-thin-client 1. Add docker-compose.yml to simplify local development 2. Add tox.ini to simplify test running automation 3. Integrate travis-ci build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13882) Support configurable install root and work root for ducktape
Ivan Daschinskiy created IGNITE-13882: - Summary: Support configurable install root and work root for ducktape Key: IGNITE-13882 URL: https://issues.apache.org/jira/browse/IGNITE-13882 Project: Ignite Issue Type: Test Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13882) Support configurable install root and work root for ducktape
[ https://issues.apache.org/jira/browse/IGNITE-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13882: -- Labels: IEP-56 ducktape (was: ducktape) > Support configurable install root and work root for ducktape > > > Key: IGNITE-13882 > URL: https://issues.apache.org/jira/browse/IGNITE-13882 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Labels: IEP-56, ducktape > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13872) Hardcoded retry timeout in ZookeeperClient
Ivan Daschinskiy created IGNITE-13872: - Summary: Hardcoded retry timeout in ZookeeperClient Key: IGNITE-13872 URL: https://issues.apache.org/jira/browse/IGNITE-13872 Project: Ignite Issue Type: Bug Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Currently, retry timeout is hardcoded (2000ms) in ZookeeperClient. We should calculate this timeout using some strategy, depending on session timeout. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.
[
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251078#comment-17251078
]
Ivan Daschinskiy edited comment on IGNITE-12901 at 12/17/20, 1:17 PM:
--
I suppose, that
[IGNITE-10306|https://issues.apache.org/jira/browse/IGNITE-10306] completely
resolve this issues. Approach with global per node update counter gives same
results (performance increase about 20%), as in mentioned solution. But that
solution is more general
was (Author: ivandasch):
I suppose, that
[IGNITE-10306|https://issues.apache.org/jira/browse/IGNITE-10306] completely
resolve this issues. Approach with global per node update counter gives same
results, as in mentioned solution. But that solution is more general
> SQL: Uncorrelated subquery should run only once.
>
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12901-subquery.patch
>
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer
> query) are executed on each nested loop iteration in the
> org.h2.command.dml.Select#isConditionMet method.
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
> * Test local query execution.
> */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM
> B)").getAll();
> }
> /**
> * @param enforceJoinOrder Enforce join order mode.
> * @param sql SQL query.
> * @param args Query parameters.
> * @return Results cursor.
> */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new
> SqlFieldsQuery(sql)
> .setSchema("TEST")
> .setLazy(true)
> .setEnforceJoinOrder(enforceJoinOrder)
> .setArgs(args), false);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.
[
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251078#comment-17251078
]
Ivan Daschinskiy edited comment on IGNITE-12901 at 12/17/20, 1:17 PM:
--
I suppose, that
[IGNITE-10306|https://issues.apache.org/jira/browse/IGNITE-10306] completely
resolve this issues. Approach with global per node update counter gives same
results, as in mentioned solution. But that solution is more general
was (Author: ivandasch):
I suppose, that
[IGNITE-10306|https://issues.apache.org/jira/browse/IGNITE-10306] completely
resolve this issues. Approach with global per node update counter give same
results, as in mentioned solution. But that solution is more general
> SQL: Uncorrelated subquery should run only once.
>
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12901-subquery.patch
>
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer
> query) are executed on each nested loop iteration in the
> org.h2.command.dml.Select#isConditionMet method.
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
> * Test local query execution.
> */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM
> B)").getAll();
> }
> /**
> * @param enforceJoinOrder Enforce join order mode.
> * @param sql SQL query.
> * @param args Query parameters.
> * @return Results cursor.
> */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new
> SqlFieldsQuery(sql)
> .setSchema("TEST")
> .setLazy(true)
> .setEnforceJoinOrder(enforceJoinOrder)
> .setArgs(args), false);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.
[
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy resolved IGNITE-12901.
---
Resolution: Implemented
> SQL: Uncorrelated subquery should run only once.
>
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12901-subquery.patch
>
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer
> query) are executed on each nested loop iteration in the
> org.h2.command.dml.Select#isConditionMet method.
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
> * Test local query execution.
> */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM
> B)").getAll();
> }
> /**
> * @param enforceJoinOrder Enforce join order mode.
> * @param sql SQL query.
> * @param args Query parameters.
> * @return Results cursor.
> */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new
> SqlFieldsQuery(sql)
> .setSchema("TEST")
> .setLazy(true)
> .setEnforceJoinOrder(enforceJoinOrder)
> .setArgs(args), false);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.
[
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251078#comment-17251078
]
Ivan Daschinskiy commented on IGNITE-12901:
---
I suppose, that
[IGNITE-10306|https://issues.apache.org/jira/browse/IGNITE-10306] completely
resolve this issues. Approach with global per node update counter give same
results, as in mentioned solution. But that solution is more general
> SQL: Uncorrelated subquery should run only once.
>
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12901-subquery.patch
>
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer
> query) are executed on each nested loop iteration in the
> org.h2.command.dml.Select#isConditionMet method.
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
> * Test local query execution.
> */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM
> B)").getAll();
> }
> /**
> * @param enforceJoinOrder Enforce join order mode.
> * @param sql SQL query.
> * @param args Query parameters.
> * @return Results cursor.
> */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new
> SqlFieldsQuery(sql)
> .setSchema("TEST")
> .setLazy(true)
> .setEnforceJoinOrder(enforceJoinOrder)
> .setArgs(args), false);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13572) Duplicates in select query during partition eviction for caches with 0 backups
[ https://issues.apache.org/jira/browse/IGNITE-13572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13572: -- Fix Version/s: 2.9.1 > Duplicates in select query during partition eviction for caches with 0 backups > -- > > Key: IGNITE-13572 > URL: https://issues.apache.org/jira/browse/IGNITE-13572 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9, 2.8.1 >Reporter: Ivan Daschinskiy >Assignee: Konstantin Sirotkin >Priority: Major > Fix For: 2.10, 2.9.1 > > Attachments: SqlPartitionEvictionTest.java > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Scenario: > # Start 2 nodes with indexed atomic partitioned cache with 0 backups. > # Load sufficient amout of data (or emulate slow removal from idx) > # Start another node. > # Perform SELECT * FROM . > Query result contains duplicates, result size is significantly bigger than > expected cache size. > Reproducer is attached. > Reproduced on 2.8.1, ongoing 2.9 and master -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13572) Duplicates in select query during partition eviction for caches with 0 backups
[jira] [Commented] (IGNITE-13572) Duplicates in select query during partition eviction for caches with 0 backups
[ https://issues.apache.org/jira/browse/IGNITE-13572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17238610#comment-17238610 ] Ivan Daschinskiy commented on IGNITE-13572: --- [~ksirotkin] No you have not. My be you forgot to push changes, but I suppose you are not subscribed to github notifications > Duplicates in select query during partition eviction for caches with 0 backups > -- > > Key: IGNITE-13572 > URL: https://issues.apache.org/jira/browse/IGNITE-13572 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9, 2.8.1 >Reporter: Ivan Daschinskiy >Assignee: Konstantin Sirotkin >Priority: Major > Fix For: 2.9.1 > > Attachments: SqlPartitionEvictionTest.java > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Scenario: > # Start 2 nodes with indexed atomic partitioned cache with 0 backups. > # Load sufficient amout of data (or emulate slow removal from idx) > # Start another node. > # Perform SELECT * FROM . > Query result contains duplicates, result size is significantly bigger than > expected cache size. > Reproducer is attached. > Reproduced on 2.8.1, ongoing 2.9 and master -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13572) Duplicates in select query during partition eviction for caches with 0 backups
[ https://issues.apache.org/jira/browse/IGNITE-13572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17238610#comment-17238610 ] Ivan Daschinskiy edited comment on IGNITE-13572 at 11/25/20, 9:00 AM: -- [~ksirotkin] No you have not. May be you forgot to push changes, but I suppose you are not subscribed to github notifications was (Author: ivandasch): [~ksirotkin] No you have not. My be you forgot to push changes, but I suppose you are not subscribed to github notifications > Duplicates in select query during partition eviction for caches with 0 backups > -- > > Key: IGNITE-13572 > URL: https://issues.apache.org/jira/browse/IGNITE-13572 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9, 2.8.1 >Reporter: Ivan Daschinskiy >Assignee: Konstantin Sirotkin >Priority: Major > Fix For: 2.9.1 > > Attachments: SqlPartitionEvictionTest.java > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Scenario: > # Start 2 nodes with indexed atomic partitioned cache with 0 backups. > # Load sufficient amout of data (or emulate slow removal from idx) > # Start another node. > # Perform SELECT * FROM . > Query result contains duplicates, result size is significantly bigger than > expected cache size. > Reproducer is attached. > Reproduced on 2.8.1, ongoing 2.9 and master -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13699) Support new metrics framework in ZookeeperDiscovery
[ https://issues.apache.org/jira/browse/IGNITE-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13699: -- Fix Version/s: 2.9.1 > Support new metrics framework in ZookeeperDiscovery > --- > > Key: IGNITE-13699 > URL: https://issues.apache.org/jira/browse/IGNITE-13699 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.10, 2.9.1 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13572) Duplicates in select query during partition eviction for caches with 0 backups
[ https://issues.apache.org/jira/browse/IGNITE-13572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17234607#comment-17234607 ] Ivan Daschinskiy commented on IGNITE-13572: --- [~ksirotkin] I have new ones. Please, fix them and rerun suite with test. > Duplicates in select query during partition eviction for caches with 0 backups > -- > > Key: IGNITE-13572 > URL: https://issues.apache.org/jira/browse/IGNITE-13572 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9, 2.8.1 >Reporter: Ivan Daschinskiy >Assignee: Konstantin Sirotkin >Priority: Major > Fix For: 2.9.1 > > Attachments: SqlPartitionEvictionTest.java > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Scenario: > # Start 2 nodes with indexed atomic partitioned cache with 0 backups. > # Load sufficient amout of data (or emulate slow removal from idx) > # Start another node. > # Perform SELECT * FROM . > Query result contains duplicates, result size is significantly bigger than > expected cache size. > Reproducer is attached. > Reproduced on 2.8.1, ongoing 2.9 and master -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13699) Support new metrics framework in ZookeeperDiscovery
[ https://issues.apache.org/jira/browse/IGNITE-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13699: -- Fix Version/s: 2.10 > Support new metrics framework in ZookeeperDiscovery > --- > > Key: IGNITE-13699 > URL: https://issues.apache.org/jira/browse/IGNITE-13699 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.10 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13699) Support new metrics framework in ZookeeperDiscovery
Ivan Daschinskiy created IGNITE-13699: - Summary: Support new metrics framework in ZookeeperDiscovery Key: IGNITE-13699 URL: https://issues.apache.org/jira/browse/IGNITE-13699 Project: Ignite Issue Type: Improvement Components: zookeeper Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13696) [ML] Tutorial examples fails
[
https://issues.apache.org/jira/browse/IGNITE-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230393#comment-17230393
]
Ivan Daschinskiy commented on IGNITE-13696:
---
I'm sorry, but I suppose this is just a
[MAE|https://en.wikipedia.org/wiki/Mean_squared_error] or smth like this.
> [ML] Tutorial examples fails
>
>
> Key: IGNITE-13696
> URL: https://issues.apache.org/jira/browse/IGNITE-13696
> Project: Ignite
> Issue Type: Bug
> Components: examples, ml
>Affects Versions: 2.9
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run Tutorial examples from repository or from binary release and
> meet error results. Looks like a bug
> org.apache.ignite.examples.ml.tutorial.Step_1_Read_and_Learn (all other
> tutorials have same issue)
> {code}
> >>> Trained model: if (x0 > 2.5000) then if (x1 > 2.5000) then if (x2 >
> >>> 0.5000) then if (x1 > 4.5000) then return 0. else if (x2 > 1.5000)
> >>> then return 0. else return 0. else return 0. else if (x2 >
> >>> 0.5000) then if (x2 > 3.5000) then if (x1 > 0.5000) then return 0.
> >>> else return 0. else if (x2 > 1.5000) then return 0. else return
> >>> 1. else if (x1 > 0.5000) then if (x1 > 1.5000) then return 0.
> >>> else return 0. else return 0. else if (x2 > 0.5000) then if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else return 1. else if (x2 > 3.5000) then return 0. else return
> >>> 1. else if (x2 > 1.5000) then if (x0 > 1.5000) then return 1.
> >>> else return 1. else if (x0 > 1.5000) then return 1. else return
> >>> 1. else if (x0 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else if (x1 > 1.5000) then return 0. else return 0. else if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then return 1. else return 1. else
> >>> return 1.
> >>> Accuracy 0.7117737003058104
> >>> Test Error 0.28822629969418956
> >>> Tutorial step 1 (read and learn) example completed.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13696) [ML] Tutorial examples fails
[
https://issues.apache.org/jira/browse/IGNITE-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230393#comment-17230393
]
Ivan Daschinskiy edited comment on IGNITE-13696 at 11/12/20, 7:04 AM:
--
I'm sorry, but I suppose this is just a
[MSE|https://en.wikipedia.org/wiki/Mean_squared_error] or smth like this.
was (Author: ivandasch):
I'm sorry, but I suppose this is just a
[MAE|https://en.wikipedia.org/wiki/Mean_squared_error] or smth like this.
> [ML] Tutorial examples fails
>
>
> Key: IGNITE-13696
> URL: https://issues.apache.org/jira/browse/IGNITE-13696
> Project: Ignite
> Issue Type: Bug
> Components: examples, ml
>Affects Versions: 2.9
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run Tutorial examples from repository or from binary release and
> meet error results. Looks like a bug
> org.apache.ignite.examples.ml.tutorial.Step_1_Read_and_Learn (all other
> tutorials have same issue)
> {code}
> >>> Trained model: if (x0 > 2.5000) then if (x1 > 2.5000) then if (x2 >
> >>> 0.5000) then if (x1 > 4.5000) then return 0. else if (x2 > 1.5000)
> >>> then return 0. else return 0. else return 0. else if (x2 >
> >>> 0.5000) then if (x2 > 3.5000) then if (x1 > 0.5000) then return 0.
> >>> else return 0. else if (x2 > 1.5000) then return 0. else return
> >>> 1. else if (x1 > 0.5000) then if (x1 > 1.5000) then return 0.
> >>> else return 0. else return 0. else if (x2 > 0.5000) then if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else return 1. else if (x2 > 3.5000) then return 0. else return
> >>> 1. else if (x2 > 1.5000) then if (x0 > 1.5000) then return 1.
> >>> else return 1. else if (x0 > 1.5000) then return 1. else return
> >>> 1. else if (x0 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else if (x1 > 1.5000) then return 0. else return 0. else if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then return 1. else return 1. else
> >>> return 1.
> >>> Accuracy 0.7117737003058104
> >>> Test Error 0.28822629969418956
> >>> Tutorial step 1 (read and learn) example completed.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
