[jira] [Assigned] (IGNITE-3244) Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
[
https://issues.apache.org/jira/browse/IGNITE-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-3244:
Assignee: Denis Magda (was: Alexey Kuznetsov)
> Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
> ---
>
> Key: IGNITE-3244
> URL: https://issues.apache.org/jira/browse/IGNITE-3244
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.0
>
>
> If to put a custom object array into a cache like this one
> {code}
> TestObject[] arr = new TestObject[] {new TestObject(i)};
> cache.put(0, arr);
> {code}
> then it will be serialized as Object[] array in
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} method.
> This leads to the situation when object's array type is lost and on cache.get
> the code below produces {{ClassCastException}}
> {code}
> TestObject[] obj = cache.get(i);
> {code}
> The full test is already added into
> {{GridCacheBinaryObjectsAbstractSelfTest.testCustomArrays}}.
> To fix the issue we have to revisit logic of
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} and
> {{CacheObjectContext.unwrapBinary}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-3244) Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
[
https://issues.apache.org/jira/browse/IGNITE-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-3244:
Assignee: Alexey Kuznetsov (was: Denis Magda)
> Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
> ---
>
> Key: IGNITE-3244
> URL: https://issues.apache.org/jira/browse/IGNITE-3244
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.0
>
>
> If to put a custom object array into a cache like this one
> {code}
> TestObject[] arr = new TestObject[] {new TestObject(i)};
> cache.put(0, arr);
> {code}
> then it will be serialized as Object[] array in
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} method.
> This leads to the situation when object's array type is lost and on cache.get
> the code below produces {{ClassCastException}}
> {code}
> TestObject[] obj = cache.get(i);
> {code}
> The full test is already added into
> {{GridCacheBinaryObjectsAbstractSelfTest.testCustomArrays}}.
> To fix the issue we have to revisit logic of
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} and
> {{CacheObjectContext.unwrapBinary}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4492) Add MBean for StripedExecutor
[ https://issues.apache.org/jira/browse/IGNITE-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-4492: Assignee: Yakov Zhdanov (was: Alexey Kuznetsov) > Add MBean for StripedExecutor > - > > Key: IGNITE-4492 > URL: https://issues.apache.org/jira/browse/IGNITE-4492 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 1.9 >Reporter: Yakov Zhdanov >Assignee: Yakov Zhdanov >Priority: Minor > Labels: newbie > Fix For: 2.0 > > > # Add MBean interface and implementation as we have for > org.apache.ignite.internal.ThreadPoolMXBeanAdapter > # Register MBean together with other pools MBeans > # Unregister MBean on Ignite stop. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4226) Redis SET command should handle expirations
[ https://issues.apache.org/jira/browse/IGNITE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh reassigned IGNITE-4226: Assignee: Roman Shtykh > Redis SET command should handle expirations > --- > > Key: IGNITE-4226 > URL: https://issues.apache.org/jira/browse/IGNITE-4226 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 1.8 >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: redis > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (IGNITE-4590) Lock/unlock operations are hanging when topology changed
[ https://issues.apache.org/jira/browse/IGNITE-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-4590: - Comment: was deleted (was: Reviewed, looks good.) > Lock/unlock operations are hanging when topology changed > > > Key: IGNITE-4590 > URL: https://issues.apache.org/jira/browse/IGNITE-4590 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.8 >Reporter: Nikolay Tikhonov >Assignee: Semen Boikov >Priority: Critical > Fix For: 1.9 > > Attachments: 4590-test.patch > > > Lock/unlock operations are hanging when topology changed. See attached test. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4663) BinaryUtils.doReadObjectArray can not read array with platform-only element type
[
https://issues.apache.org/jira/browse/IGNITE-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857620#comment-15857620
]
Alexey Kuznetsov commented on IGNITE-4663:
--
why we need this flag? I hardly can understand in what cases we need to not
deserialize entities
> BinaryUtils.doReadObjectArray can not read array with platform-only element
> type
>
>
> Key: IGNITE-4663
> URL: https://issues.apache.org/jira/browse/IGNITE-4663
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{BinaryUtils.doReadObjectArray}} performs unnecessary class lookup when
> {{deserialize = false}}. When array elements are of platform-only type
> ({{platformId != 0}}), the class can never be resolved.
> * arrays of user-defined types are not supported for platforms
> * performance is suboptimal in binary mode (in Java and platforms)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-3244) Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
[
https://issues.apache.org/jira/browse/IGNITE-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857638#comment-15857638
]
ASF GitHub Bot commented on IGNITE-3244:
GitHub user voipp opened a pull request:
https://github.com/apache/ignite/pull/1505
IGNITE-3244 Custom arrays arent serialized properly
arrays type now considered while deserialization. After deserialization
you've got array of correct type
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/voipp/ignite IGNITE-3244
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/1505.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1505
commit f80a73cc8c416ad24053afa43f773f7f1e6e9dd6
Author: voipp
Date: 2017-02-06T16:10:11Z
IGNITE-3244 Custom arrays arent serialized properly
> Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
> ---
>
> Key: IGNITE-3244
> URL: https://issues.apache.org/jira/browse/IGNITE-3244
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.0
>
>
> If to put a custom object array into a cache like this one
> {code}
> TestObject[] arr = new TestObject[] {new TestObject(i)};
> cache.put(0, arr);
> {code}
> then it will be serialized as Object[] array in
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} method.
> This leads to the situation when object's array type is lost and on cache.get
> the code below produces {{ClassCastException}}
> {code}
> TestObject[] obj = cache.get(i);
> {code}
> The full test is already added into
> {{GridCacheBinaryObjectsAbstractSelfTest.testCustomArrays}}.
> To fix the issue we have to revisit logic of
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} and
> {{CacheObjectContext.unwrapBinary}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-3244) Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
[
https://issues.apache.org/jira/browse/IGNITE-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-3244:
Assignee: Denis Magda (was: Alexey Kuznetsov)
> Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
> ---
>
> Key: IGNITE-3244
> URL: https://issues.apache.org/jira/browse/IGNITE-3244
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.0
>
>
> If to put a custom object array into a cache like this one
> {code}
> TestObject[] arr = new TestObject[] {new TestObject(i)};
> cache.put(0, arr);
> {code}
> then it will be serialized as Object[] array in
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} method.
> This leads to the situation when object's array type is lost and on cache.get
> the code below produces {{ClassCastException}}
> {code}
> TestObject[] obj = cache.get(i);
> {code}
> The full test is already added into
> {{GridCacheBinaryObjectsAbstractSelfTest.testCustomArrays}}.
> To fix the issue we have to revisit logic of
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} and
> {{CacheObjectContext.unwrapBinary}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-3244) Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
[
https://issues.apache.org/jira/browse/IGNITE-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-3244:
Assignee: Alexey Kuznetsov (was: Denis Magda)
> Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
> ---
>
> Key: IGNITE-3244
> URL: https://issues.apache.org/jira/browse/IGNITE-3244
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.0
>
>
> If to put a custom object array into a cache like this one
> {code}
> TestObject[] arr = new TestObject[] {new TestObject(i)};
> cache.put(0, arr);
> {code}
> then it will be serialized as Object[] array in
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} method.
> This leads to the situation when object's array type is lost and on cache.get
> the code below produces {{ClassCastException}}
> {code}
> TestObject[] obj = cache.get(i);
> {code}
> The full test is already added into
> {{GridCacheBinaryObjectsAbstractSelfTest.testCustomArrays}}.
> To fix the issue we have to revisit logic of
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} and
> {{CacheObjectContext.unwrapBinary}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4492) Add MBean for StripedExecutor
[ https://issues.apache.org/jira/browse/IGNITE-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-4492: Assignee: Alexey Kuznetsov (was: Yakov Zhdanov) > Add MBean for StripedExecutor > - > > Key: IGNITE-4492 > URL: https://issues.apache.org/jira/browse/IGNITE-4492 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 1.9 >Reporter: Yakov Zhdanov >Assignee: Alexey Kuznetsov >Priority: Minor > Labels: newbie > Fix For: 2.0 > > > # Add MBean interface and implementation as we have for > org.apache.ignite.internal.ThreadPoolMXBeanAdapter > # Register MBean together with other pools MBeans > # Unregister MBean on Ignite stop. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4302) Exchange binary metadata with discovery custom messages instead of system cache
[ https://issues.apache.org/jira/browse/IGNITE-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857656#comment-15857656 ] ASF GitHub Bot commented on IGNITE-4302: GitHub user sergey-chugunov-1985 opened a pull request: https://github.com/apache/ignite/pull/1506 IGNITE-4302 binary metadata component refactored to use discovery-based protocol Metadata updates are exchanged using DiscoveryCustomMessage-based protocol instead of utility cache. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4302 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1506.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1506 commit fc5bf177ad1c81f8e59d9ba0cbf37b327b5a9e94 Author: Sergey Chugunov Date: 2017-01-19T13:53:34Z IGNITE-4302 implementation of DiscoveryCustomEvent-based binary metadata exchange component > Exchange binary metadata with discovery custom messages instead of system > cache > --- > > Key: IGNITE-4302 > URL: https://issues.apache.org/jira/browse/IGNITE-4302 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov > Fix For: 2.0 > > > h4. Notes > See [IGNITE-4157|https://issues.apache.org/jira/browse/IGNITE-4157] for more > details about context. > h4. Acceptance Criteria > # Binary metadata cache is deleted. > # Binary metadata exchange is performed using *DiscoveryCustomMessage* events. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4472) Web Console: Implement usage tracing
[ https://issues.apache.org/jira/browse/IGNITE-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857660#comment-15857660 ] Vasiliy Sisko commented on IGNITE-4472: --- Make Actions column and user column always showed. > Web Console: Implement usage tracing > > > Key: IGNITE-4472 > URL: https://issues.apache.org/jira/browse/IGNITE-4472 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Shabalin >Assignee: Dmitriy Shabalin > Fix For: 1.9 > > > We need to track some kind of "activity scores" for users. > Activities: > # Configuration > # SQL > # Demo > And show that score on admin panel. > May be this could be implemented by some library. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log
[
https://issues.apache.org/jira/browse/IGNITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857742#comment-15857742
]
Vyacheslav Daradur commented on IGNITE-4374:
[~dmagda]
Done.
Current output:
{code}
[11:54:40]
[11:54:41] Message queue limit is set to 0 which may lead to potential OOMEs
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
message queues growth on sender and receiver sides.
[11:54:41] Security status [authentication=off, tls/ssl=off]
[11:54:43] Performance suggestions for grid (fix if possible)
[11:54:43] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[11:54:43] ^-- JVM heap size is greater than 30.5Gb, JVM will not use
compressed oops
[11:54:43] ^-- Enable server mode for JVM (add '-server' to JVM options)
[11:54:43] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options)
[11:54:43] ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
JVM options)"
[11:54:43] ^-- Specify New I/O max total size (add
'-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
[11:54:43] ^-- Enable using thread-local allocation blocks (add
'-XX:+UseTLAB' to JVM options)
[11:54:43] ^-- Disable processing of calls to System.gc() (add
'-XX:+DisableExplicitGC' to JVM options)
[11:54:43] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs and vm.dirty_expire_centisecs parameters by
setting to 500)
[11:54:43] ^-- Reduce pages swapping ratio (set vm.swappiness=10)
[11:54:43] ^-- Adjust NUMA zones reclamation setting (set
vm.zone_reclaim_mode=0)
[11:54:43] ^-- Avoid direct reclaim and page allocation failures (set
vm.extra_free_kbytes to 124 or other value)
[11:54:43] Refer to this page for more performance suggestions:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
[11:54:43]
[11:54:43] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[11:54:43]
[11:54:43] Ignite node started OK (id=8bf18ef1)
[11:54:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=1, heap=1.0GB]
{code}
These lines are optionaly:
{code}
[11:59:07] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_expire_centisecs parameter by setting to 500)
or
[12:34:01] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs parameter by setting to 500)
or
[12:33:01] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs and vm.dirty_expire_centisecs parameters by
setting to 500)
{code}
[Latest ci.tests|http://ci.ignite.apache.org/viewQueued.html?itemId=449432]
> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x32_not_optimized.png, x32_optimized.png,
> x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly
> set
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-4668) Doesn't work "manual" yardsticks when ip of server/driver not equal ip of ethernet interface
Ilya Suntsov created IGNITE-4668: Summary: Doesn't work "manual" yardsticks when ip of server/driver not equal ip of ethernet interface Key: IGNITE-4668 URL: https://issues.apache.org/jira/browse/IGNITE-4668 Project: Ignite Issue Type: Bug Components: yardstick Affects Versions: 1.8 Reporter: Ilya Suntsov Fix For: 1.9 In scripts benchmark-manual-drivers-start.sh -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log
[
https://issues.apache.org/jira/browse/IGNITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-4374:
---
Comment: was deleted
(was: [~dmagda]
Done.
Current output:
{code}
[11:54:40]
[11:54:41] Message queue limit is set to 0 which may lead to potential OOMEs
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
message queues growth on sender and receiver sides.
[11:54:41] Security status [authentication=off, tls/ssl=off]
[11:54:43] Performance suggestions for grid (fix if possible)
[11:54:43] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[11:54:43] ^-- JVM heap size is greater than 30.5Gb, JVM will not use
compressed oops
[11:54:43] ^-- Enable server mode for JVM (add '-server' to JVM options)
[11:54:43] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options)
[11:54:43] ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
JVM options)"
[11:54:43] ^-- Specify New I/O max total size (add
'-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
[11:54:43] ^-- Enable using thread-local allocation blocks (add
'-XX:+UseTLAB' to JVM options)
[11:54:43] ^-- Disable processing of calls to System.gc() (add
'-XX:+DisableExplicitGC' to JVM options)
[11:54:43] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs and vm.dirty_expire_centisecs parameters by
setting to 500)
[11:54:43] ^-- Reduce pages swapping ratio (set vm.swappiness=10)
[11:54:43] ^-- Adjust NUMA zones reclamation setting (set
vm.zone_reclaim_mode=0)
[11:54:43] ^-- Avoid direct reclaim and page allocation failures (set
vm.extra_free_kbytes to 124 or other value)
[11:54:43] Refer to this page for more performance suggestions:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
[11:54:43]
[11:54:43] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[11:54:43]
[11:54:43] Ignite node started OK (id=8bf18ef1)
[11:54:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=1, heap=1.0GB]
{code}
These lines are optionaly:
{code}
[11:59:07] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_expire_centisecs parameter by setting to 500)
or
[12:34:01] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs parameter by setting to 500)
or
[12:33:01] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs and vm.dirty_expire_centisecs parameters by
setting to 500)
{code}
[Latest ci.tests|http://ci.ignite.apache.org/viewQueued.html?itemId=449432])
> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x32_not_optimized.png, x32_optimized.png,
> x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly
> set
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-2278) Rework all tooltips - add bullets where multilines text
[ https://issues.apache.org/jira/browse/IGNITE-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-2278: - Assignee: Andrey Novikov Fixed missed tips. > Rework all tooltips - add bullets where multilines text > --- > > Key: IGNITE-2278 > URL: https://issues.apache.org/jira/browse/IGNITE-2278 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > > We need to add bullets in tooltips where it make sense for better usability. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4668) Doesn't work "manual" yardsticks when ip of server/driver not equal ip of ethernet interface
[
https://issues.apache.org/jira/browse/IGNITE-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Suntsov updated IGNITE-4668:
-
Description:
In scripts benchmark-manual-servers-start.sh we are checking:
{noformat}
for host in "${hosts[@]}";
do
if [ "${host}" == "localhost" ] || [ "${host}" == "127.0.0.1" ];
then
srv_num=$((1 + $srv_num))
else
ip=$(hostname --ip-address)
host_name=$(hostname)
if [ "${host}" == "${ip}" ] || [ "${host}" == "${host_name}" ];
then
srv_num=$((1 + $srv_num))
fi
fi
done
{noformat}
in case when ip address of real host interface that we set as server address
not equal $(hostname --ip-address) servers doesn't start.
I think we should collect all interfaces ip in array and check if ip from
${hosts[@]} (SERVER_HOSTS) equal one of them.
was:In scripts benchmark-manual-drivers-start.sh
> Doesn't work "manual" yardsticks when ip of server/driver not equal ip of
> ethernet interface
> -
>
> Key: IGNITE-4668
> URL: https://issues.apache.org/jira/browse/IGNITE-4668
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 1.8
>Reporter: Ilya Suntsov
> Fix For: 1.9
>
>
> In scripts benchmark-manual-servers-start.sh we are checking:
> {noformat}
> for host in "${hosts[@]}";
> do
> if [ "${host}" == "localhost" ] || [ "${host}" == "127.0.0.1" ];
> then
> srv_num=$((1 + $srv_num))
> else
> ip=$(hostname --ip-address)
> host_name=$(hostname)
> if [ "${host}" == "${ip}" ] || [ "${host}" == "${host_name}"
> ]; then
> srv_num=$((1 + $srv_num))
> fi
> fi
> done
> {noformat}
> in case when ip address of real host interface that we set as server address
> not equal $(hostname --ip-address) servers doesn't start.
> I think we should collect all interfaces ip in array and check if ip from
> ${hosts[@]} (SERVER_HOSTS) equal one of them.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4619) .NET: TransactionScope documentation and example
[
https://issues.apache.org/jira/browse/IGNITE-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857774#comment-15857774
]
ASF GitHub Bot commented on IGNITE-4619:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/1492
> .NET: TransactionScope documentation and example
>
>
> Key: IGNITE-4619
> URL: https://issues.apache.org/jira/browse/IGNITE-4619
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 1.9
>
>
> Create documentation and example for {{TransactionScope}} support
> (IGNITE-3430).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4425) .NET: Support "ICollection.Contains" in LINQ
[
https://issues.apache.org/jira/browse/IGNITE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857776#comment-15857776
]
Pavel Tupitsyn commented on IGNITE-4425:
Please make sure that {{.NET Inspections}} suite passes:
http://ci.ignite.apache.org/viewLog.html?buildId=447948
> .NET: Support "ICollection.Contains" in LINQ
>
>
> Key: IGNITE-4425
> URL: https://issues.apache.org/jira/browse/IGNITE-4425
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
> Labels: .NET, LINQ
> Fix For: 2.0
>
>
> SQL supports IN queries
> https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations
> Example SQL:
> {code}
> new SqlFieldsQuery("select p.name from Person p where id in (?, ?)", 1, 3);
> {code}
> Add support in LINQ like this:
> {code}
> persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.Id))
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4284) Failed second client node join with continuous query and peer class loading enabled
[ https://issues.apache.org/jira/browse/IGNITE-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-4284: Component/s: cache > Failed second client node join with continuous query and peer class loading > enabled > --- > > Key: IGNITE-4284 > URL: https://issues.apache.org/jira/browse/IGNITE-4284 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: Dmitry Karachentsev >Assignee: Amelchev Nikita > Fix For: 2.0 > > > Steps to reproduce: > 1) Start server with cache and peer class loading enabled. > 2) Start client with peer class loading enabled. > 3) Start continuous query with custom event filter factory. > 4) Start second client -- Fail with NPE or AsserionError. > Test that reproduces error: > [PR#1267|https://github.com/apache/ignite/pull/1267] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4619) .NET: TransactionScope documentation and example
[
https://issues.apache.org/jira/browse/IGNITE-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857793#comment-15857793
]
Pavel Tupitsyn commented on IGNITE-4619:
Example merged to master.
> .NET: TransactionScope documentation and example
>
>
> Key: IGNITE-4619
> URL: https://issues.apache.org/jira/browse/IGNITE-4619
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 1.9
>
>
> Create documentation and example for {{TransactionScope}} support
> (IGNITE-3430).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4501) Improvement of connection in a cluster of new node
[
https://issues.apache.org/jira/browse/IGNITE-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Menshikov updated IGNITE-4501:
Component/s: messaging
> Improvement of connection in a cluster of new node
> --
>
> Key: IGNITE-4501
> URL: https://issues.apache.org/jira/browse/IGNITE-4501
> Project: Ignite
> Issue Type: Improvement
> Components: messaging
>Reporter: Vyacheslav Daradur
>Assignee: Alexander Menshikov
>
> h3. Main description:
> Cluster nodes connect a ring.
> For example: we have 6 nodes: A, B, C, D, E, F.
> They can connect a ring in any possible way: A-B-C-D-E-F-A, or A-F-B-E-C-D-A,
> etc.
> If some node leaves topology, adjacent nodes must reconnect.
> If nodes A, B, C are in same physical place, nodes D, E, F are in other
> place, and places lost connect each other, we will have many ways of
> reconnections.
> At best case, if we had a ring: A-B-CxD-E-FxA ('x' means disconnect) -- then
> we have only one reconnect (C
> will be connected to A or F will be connected to D -- depends on what part of
> the cluster was alive.
> Also, if we had a not ring: AxFxBxExCxDxA -- then we have a lot of
> reconnections (A to B, B to C, C to A -- in general n/2 reconnections, where
> n -- number of nodes).
> h3. Approach:
> It is necessary to develop approach of node insertion to the correct place
> for creation of the correct ring-topology.
> h3. Solutions:
> Main idea is a sorting according to latency.
> * group nodes in arcs on an ARC_ID. (manualy?)
> * implement NodeComparator (nodes on the same host : nodes on the same subnet
> : other nodes). We will use it when we connect a new node.
> * [dev list
> thread|http://mail-archives.apache.org/mod_mbox/ignite-dev/201612.mbox/%3CCAN+WSNyWYXSXEBpGErVt72zTgi2pTQzUWLv8JY=ke83-5-r...@mail.gmail.com%3E]
> Update Dec, 29 Yakov Zhdanov:
> # introduce CLUSTER_REGION_ID node attribute. This can be done by adding
> public static final constant to TcpDiscoverySpi.
> # Alter
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing#nextNode(java.util.Collection)
> to order basing on per node attribute value
> # Node comparison should be stable and consistent. E.g. if CLUSTER_REGION_IDs
> are equal then we should compare nodes' IDs. This way we have consistent
> order on all nodes in topology.
> # Also nextNode() has to group nodes on same host and in same subnet. This
> can be postponed and implemented after we have other points done.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4612) Minor code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Menshikov updated IGNITE-4612: Component/s: community > Minor code cleanup > -- > > Key: IGNITE-4612 > URL: https://issues.apache.org/jira/browse/IGNITE-4612 > Project: Ignite > Issue Type: Task > Components: community >Affects Versions: 1.8 >Reporter: Alexander Menshikov >Assignee: Alexander Menshikov >Priority: Trivial > Fix For: 1.9 > > > This issue about trivial code cleanup. > 1) Cleanup unused imports/variable/argument. > 2) Rename ignored exception to "ignored". > 3) ... > 4) PROFIT :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4669) .NET: Sort binary object fields
Pavel Tupitsyn created IGNITE-4669:
--
Summary: .NET: Sort binary object fields
Key: IGNITE-4669
URL: https://issues.apache.org/jira/browse/IGNITE-4669
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Fix For: 2.0
Make sure that fields are sorted by name in all cases:
* Reflective serializer
* {{IBinarizable}} serialization
* {{[Serializable]}} serialization
* Custom serializer
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log
[
https://issues.apache.org/jira/browse/IGNITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857821#comment-15857821
]
Vyacheslav Daradur commented on IGNITE-4374:
[~dmagda]
Done.
Current output:
{code}
[11:54:40]
[11:54:41] Message queue limit is set to 0 which may lead to potential OOMEs
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
message queues growth on sender and receiver sides.
[11:54:41] Security status [authentication=off, tls/ssl=off]
[11:54:43] Performance suggestions for grid (fix if possible)
[11:54:43] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[11:54:43] ^-- JVM heap size is greater than 30.5Gb, JVM will not use
compressed oops
[11:54:43] ^-- Enable server mode for JVM (add '-server' to JVM options)
[11:54:43] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options)
[11:54:43] ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
JVM options)"
[11:54:43] ^-- Specify New I/O max total size (add
'-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
[11:54:43] ^-- Enable the thread-local allocation blocks (add '-XX:+UseTLAB'
to JVM options)
[11:54:43] ^-- Disable processing of calls to System.gc() (add
'-XX:+DisableExplicitGC' to JVM options)
[11:54:43] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs and vm.dirty_expire_centisecs parameters by
setting to 500)
[11:54:43] ^-- Reduce pages swapping ratio (set vm.swappiness=10)
[11:54:43] ^-- Disable NUMA memory reclaim (set vm.zone_reclaim_mode=0)
[11:54:43] ^-- Avoid direct reclaim and page allocation failures (set
vm.extra_free_kbytes=124)
[11:54:43] Refer to this page for more performance suggestions:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
[11:54:43]
[11:54:43] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[11:54:43]
[11:54:43] Ignite node started OK (id=8bf18ef1)
[11:54:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=1, heap=1.0GB]
{code}
These lines are optionaly:
{code}
[11:59:07] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_expire_centisecs parameter by setting to 500)
or
[12:34:01] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs parameter by setting to 500)
or
[12:33:01] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs and vm.dirty_expire_centisecs parameters by
setting to 500)
{code}
bq. Avoid direct reclaim and page allocation failures (set vm.extra_free_kbytes
to 124 or other value).
We check equality to 124. If we write "or other value", we should change
the check.
[Latest ci.tests|http://ci.ignite.apache.org/viewQueued.html?itemId=449798]
> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x32_not_optimized.png, x32_optimized.png,
> x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly
> set
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4363) Inner properties mutation broken in SQL UPDATE
[
https://issues.apache.org/jira/browse/IGNITE-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4363:
Fix Version/s: (was: 1.9)
2.0
> Inner properties mutation broken in SQL UPDATE
> --
>
> Key: IGNITE-4363
> URL: https://issues.apache.org/jira/browse/IGNITE-4363
> Project: Ignite
> Issue Type: Bug
> Components: binary, SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Discovered in course of working on IGNITE-4340.
> Say, we have following type for cache values
> {code:java}
> static final class AllTypes implements Serializable {
> /**
> * Data Long.
> */
> @QuerySqlField
> Long longCol;
> /**
> * Inner type object.
> */
> @QuerySqlField
> InnerType innerTypeCol;
> /** */
> static final class InnerType implements Serializable {
> /** */
> @QuerySqlField
> Long innerLongCol;
> /** */
> @QuerySqlField
> String innerStrCol;
>}
> }
> {code}
> Queries like this fail for both optimized and binary marshaller:
> {code:sql}
> UPDATE AllTypes set innerLongCol = ?
> {code}
> For optimized, current DML implementation mutates existing inner property
> thus confusing DML statements re-run logic (query re-runs because engine sees
> value as concurrently modified, though the only change is its own, and
> ultimately fails). The solution is to clone inner objects and set new
> property values on them because we need to have old value pristine.
> For binary, current DML implementation does not honor properties hierarchy
> and, for above example, just sets {{innerLongCol}} field on {{AllTypes}}
> binary object and not its child {{InnerType}} object. Thus, index will be
> updated and SELECTs for that column will return correct value for that field,
> but inner state of target property {{innerTypeCol}} does not change, and
> {{AllTypes}} object gets its own odd field {{innerLongCol}} which it does not
> know how to do with (no metadata about it in type descriptor).
> The patch for both problems is ready and lying on my shelf waiting for 1.8
> release to happen to be applied. Then this will ultimately be fixed with the
> rest of known problems/improvements (Jira issues for them will follow).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IGNITE-4363) Inner properties mutation broken in SQL UPDATE
[
https://issues.apache.org/jira/browse/IGNITE-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-4363.
-
Resolution: Fixed
> Inner properties mutation broken in SQL UPDATE
> --
>
> Key: IGNITE-4363
> URL: https://issues.apache.org/jira/browse/IGNITE-4363
> Project: Ignite
> Issue Type: Bug
> Components: binary, SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Discovered in course of working on IGNITE-4340.
> Say, we have following type for cache values
> {code:java}
> static final class AllTypes implements Serializable {
> /**
> * Data Long.
> */
> @QuerySqlField
> Long longCol;
> /**
> * Inner type object.
> */
> @QuerySqlField
> InnerType innerTypeCol;
> /** */
> static final class InnerType implements Serializable {
> /** */
> @QuerySqlField
> Long innerLongCol;
> /** */
> @QuerySqlField
> String innerStrCol;
>}
> }
> {code}
> Queries like this fail for both optimized and binary marshaller:
> {code:sql}
> UPDATE AllTypes set innerLongCol = ?
> {code}
> For optimized, current DML implementation mutates existing inner property
> thus confusing DML statements re-run logic (query re-runs because engine sees
> value as concurrently modified, though the only change is its own, and
> ultimately fails). The solution is to clone inner objects and set new
> property values on them because we need to have old value pristine.
> For binary, current DML implementation does not honor properties hierarchy
> and, for above example, just sets {{innerLongCol}} field on {{AllTypes}}
> binary object and not its child {{InnerType}} object. Thus, index will be
> updated and SELECTs for that column will return correct value for that field,
> but inner state of target property {{innerTypeCol}} does not change, and
> {{AllTypes}} object gets its own odd field {{innerLongCol}} which it does not
> know how to do with (no metadata about it in type descriptor).
> The patch for both problems is ready and lying on my shelf waiting for 1.8
> release to happen to be applied. Then this will ultimately be fixed with the
> rest of known problems/improvements (Jira issues for them will follow).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4619) .NET: TransactionScope documentation and example
[
https://issues.apache.org/jira/browse/IGNITE-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857840#comment-15857840
]
Pavel Tupitsyn commented on IGNITE-4619:
[~dmagda]
1. If Ignite transaction is started before {{TransactionScope}}, then
{{TransactionScope}} does not manage Ignite transaction (does not commit or
revert it).
2. I've reworded this paragraph. We don't support {{Suppress}}, it is ignored.
3,4 done.
> .NET: TransactionScope documentation and example
>
>
> Key: IGNITE-4619
> URL: https://issues.apache.org/jira/browse/IGNITE-4619
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 1.9
>
>
> Create documentation and example for {{TransactionScope}} support
> (IGNITE-3430).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-3537) Add tests checking that data structures work inside user transactions
[ https://issues.apache.org/jira/browse/IGNITE-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim reassigned IGNITE-3537: - Assignee: Vadim (was: Semen Boikov) > Add tests checking that data structures work inside user transactions > - > > Key: IGNITE-3537 > URL: https://issues.apache.org/jira/browse/IGNITE-3537 > Project: Ignite > Issue Type: Task > Components: data structures >Reporter: Semen Boikov >Assignee: Vadim >Priority: Minor > Labels: newbie > > Need create tests to check that Ignite data structures work inside user > transaction. Now data structures should use independent transactions, test > should jus check that there are no exceptions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4619) .NET: TransactionScope documentation and example
[
https://issues.apache.org/jira/browse/IGNITE-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-4619:
--
Assignee: Denis Magda (was: Pavel Tupitsyn)
> .NET: TransactionScope documentation and example
>
>
> Key: IGNITE-4619
> URL: https://issues.apache.org/jira/browse/IGNITE-4619
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Denis Magda
> Labels: .NET
> Fix For: 1.9
>
>
> Create documentation and example for {{TransactionScope}} support
> (IGNITE-3430).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
[ https://issues.apache.org/jira/browse/IGNITE-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857848#comment-15857848 ] Maksim Kozlov commented on IGNITE-3878: --- [~yzhdanov], [~ntikhonov] could you review the code (in previous comment), please. > Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent > -- > > Key: IGNITE-3878 > URL: https://issues.apache.org/jira/browse/IGNITE-3878 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.7 >Reporter: Nikolay Tikhonov >Assignee: Maksim Kozlov >Priority: Minor > > In some cases useful know where (on primary or backup nodes) was invoked a > continuous query filter. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4409) UUID fields of the key class deserialized in a wrong way on INSERT.
[
https://issues.apache.org/jira/browse/IGNITE-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-4409:
---
Assignee: Alexander Paschenko
> UUID fields of the key class deserialized in a wrong way on INSERT.
> ---
>
> Key: IGNITE-4409
> URL: https://issues.apache.org/jira/browse/IGNITE-4409
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Consider the following case. There is a class which is used as Key on C++
> side. It contains 3 fields: String, Timestamp and UUID. There is also a value
> of the type Integer. Record of the cache is being inserted with
> {{SqlFieldsQuery}}:
> {noformat}
> INSERT INTO Integer (str, ts, guid, _val) VALUES (?, ?, ?, ?)
> {noformat}
> String, Timestamp and Integer values serialized and desirialized just fine,
> but UUID value is passed further just like byte array of 17 bytes, first of
> which is 10 (UUID type header in Binary format), so later it gets converted
> here:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at org.h2.value.ValueUuid.get(ValueUuid.java:68)
> at org.h2.value.Value.convertTo(Value.java:861)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.convert(DmlStatementsProcessor.java:637)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:868)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:745)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:286)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:159)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:189)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1266)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:812)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1777)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:749)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1205)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:837)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractTarget.inStreamOutObject(PlatformAbstractTarget.java:90)
> {noformat}
> Obviously enough, it gets deserialized wrong because of the header byte and
> as a result, we get wrong key instance in the cache.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4409) UUID fields of the key class deserialized in a wrong way on INSERT.
[
https://issues.apache.org/jira/browse/IGNITE-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4409:
Fix Version/s: (was: 2.0)
1.9
> UUID fields of the key class deserialized in a wrong way on INSERT.
> ---
>
> Key: IGNITE-4409
> URL: https://issues.apache.org/jira/browse/IGNITE-4409
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Igor Sapego
> Fix For: 1.9
>
>
> Consider the following case. There is a class which is used as Key on C++
> side. It contains 3 fields: String, Timestamp and UUID. There is also a value
> of the type Integer. Record of the cache is being inserted with
> {{SqlFieldsQuery}}:
> {noformat}
> INSERT INTO Integer (str, ts, guid, _val) VALUES (?, ?, ?, ?)
> {noformat}
> String, Timestamp and Integer values serialized and desirialized just fine,
> but UUID value is passed further just like byte array of 17 bytes, first of
> which is 10 (UUID type header in Binary format), so later it gets converted
> here:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at org.h2.value.ValueUuid.get(ValueUuid.java:68)
> at org.h2.value.Value.convertTo(Value.java:861)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.convert(DmlStatementsProcessor.java:637)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:868)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:745)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:286)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:159)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:189)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1266)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:812)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1777)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:749)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1205)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:837)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractTarget.inStreamOutObject(PlatformAbstractTarget.java:90)
> {noformat}
> Obviously enough, it gets deserialized wrong because of the header byte and
> as a result, we get wrong key instance in the cache.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4599) IgniteMarshallerCacheClientRequestsMappingOnMissTest.java will not compile
[
https://issues.apache.org/jira/browse/IGNITE-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Menshikov reassigned IGNITE-4599:
---
Assignee: Alexander Menshikov
> IgniteMarshallerCacheClientRequestsMappingOnMissTest.java will not compile
> --
>
> Key: IGNITE-4599
> URL: https://issues.apache.org/jira/browse/IGNITE-4599
> Project: Ignite
> Issue Type: Bug
>Reporter: Rohit Mohta
>Assignee: Alexander Menshikov
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> {noformat}
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteMarshallerCacheClientRequestsMappingOnMissTest.java:[149,23]
> unreported exception org.apache.ignite.IgniteCheckedException; must be
> caught or declared to be thrown
> [INFO] 1 error
> [INFO] -
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4599) IgniteMarshallerCacheClientRequestsMappingOnMissTest.java will not compile
[
https://issues.apache.org/jira/browse/IGNITE-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857889#comment-15857889
]
Alexander Menshikov commented on IGNITE-4599:
-
In the master branch there is no file you are talking about. With a similar
name I found the class "IgniteMarshallerCacheConcurrentReadWriteTest". But it
builds well on Java 1.8.
> IgniteMarshallerCacheClientRequestsMappingOnMissTest.java will not compile
> --
>
> Key: IGNITE-4599
> URL: https://issues.apache.org/jira/browse/IGNITE-4599
> Project: Ignite
> Issue Type: Bug
>Reporter: Rohit Mohta
>Assignee: Alexander Menshikov
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> {noformat}
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteMarshallerCacheClientRequestsMappingOnMissTest.java:[149,23]
> unreported exception org.apache.ignite.IgniteCheckedException; must be
> caught or declared to be thrown
> [INFO] 1 error
> [INFO] -
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IGNITE-4599) IgniteMarshallerCacheClientRequestsMappingOnMissTest.java will not compile
[
https://issues.apache.org/jira/browse/IGNITE-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Menshikov resolved IGNITE-4599.
-
Resolution: Invalid
> IgniteMarshallerCacheClientRequestsMappingOnMissTest.java will not compile
> --
>
> Key: IGNITE-4599
> URL: https://issues.apache.org/jira/browse/IGNITE-4599
> Project: Ignite
> Issue Type: Bug
>Reporter: Rohit Mohta
>Assignee: Alexander Menshikov
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> {noformat}
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteMarshallerCacheClientRequestsMappingOnMissTest.java:[149,23]
> unreported exception org.apache.ignite.IgniteCheckedException; must be
> caught or declared to be thrown
> [INFO] 1 error
> [INFO] -
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4663) BinaryUtils.doReadObjectArray can not read array with platform-only element type
[ https://issues.apache.org/jira/browse/IGNITE-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857921#comment-15857921 ] ASF GitHub Bot commented on IGNITE-4663: GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/1507 IGNITE-4663: skip class loading when deserialize == false You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4663 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1507.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1507 commit c893da70a9757b16b0799adc8eaa29fa1b03d06e Author: tledkov-gridgain Date: 2016-12-21T11:54:33Z IGNITE-4399: IGFS: Merged IgfsSecondaryFileSystem and IgfsSecondaryFileSystemV2 interfaces. This closes #1346. commit c5882a85f4e3a1f61723ac54fd92f087684df6da Author: devozerov Date: 2016-12-26T11:15:42Z Merge branch 'master' into ignite-2.0 commit 7e73d0223a3f09cbe0b7094a2c04bdf9d63ca9be Author: devozerov Date: 2016-12-28T09:54:47Z Merge branch 'master' into ignite-2.0 commit 7d82d6a06b5e9f1f8cd2909b865e37d46b8da03f Author: devozerov Date: 2016-12-28T09:58:11Z IGNITE-3875: Introduced separate thread pool for data streamer. This closes #1173. This closes #1383. commit a61b0eaff1817d84c0659e8a7e095f29e22800e1 Author: tledkov-gridgain Date: 2016-12-28T11:09:38Z IGNITE-4405: Hadoop: implemented "readLine" method for HadoopDataInStream and HadoopDirectDataInput classes. This closes #1358. commit 2df39a80d80e2575be61a902ccd48615796fcde9 Author: tledkov-gridgain Date: 2016-12-28T13:47:24Z IGNITE-3961: IGFS: Added IgfsSecondaryFileSystem.affintiy() method. This closes #1114. This closes #1252. commit 2e691d80ea4870c3e7b5b127792b66c920f72c39 Author: tledkov-gridgain Date: 2016-12-29T08:00:01Z IGNITE-4462: IGFS: removed grid name from HadoopIgfsEndpoint. This closes #1368. commit a9b1fc2b3840d47d7c978d9296e8ae6bdeb10be5 Author: tledkov-gridgain Date: 2016-12-29T08:07:22Z IGNITE-4459: Hadoop: weighted planned is default one from now on. This closes #1391. commit 1f743465d6875ef48b1835d03a78a0dbaf339bf6 Author: tledkov-gridgain Date: 2016-12-29T08:14:10Z IGNITE-4458: Hadoop: "striped" shuffle mode is default from now on. This closes #1390. commit 6090ebdfcd0ea3840b0d32cb10197b43615e1e89 Author: devozerov Date: 2017-01-05T09:23:06Z Merge branch 'master' into ignite-2.0 commit 77ca2e636c73e464f833f227c4894df0785ae9e2 Author: devozerov Date: 2017-01-16T13:07:49Z Merge branch 'master' into ignite-2.0 commit d14e0727b3dd61ab5ec2957133d77dbc25e9ba68 Author: tledkov-gridgain Date: 2017-01-16T13:36:25Z IGNITE-4428: Hadoop: moved HadoopMapReducePlanner and dependent classes to public space. This closes #1389. This closes #1394. commit f1365421c299b754a10edf8b6f156aeeb5ff0ce1 Author: tledkov-gridgain Date: 2017-01-16T13:57:27Z IGNITE-4503: Hadoop: added boundary checks to HadoopDirectDataInput. This closes # 1416. commit e08b6ff48916edfab2dbd5d62092be5a1f819a2f Author: Pavel Tupitsyn Date: 2017-01-19T10:34:59Z Merge branch 'master' into ignite-2.0 commit 43adf8a3f09c6b29fe3e70f62dbc58251d8d7cb9 Author: Ivan Veselovskiy Date: 2017-01-19T11:34:23Z IGNITE-4219: Hadoop: fixed serialization of long strings. This closes #1409. commit 454b9769e72775c5f6b44a36f0eef84bcce13bd7 Author: devozerov Date: 2017-01-19T11:34:43Z Merge remote-tracking branch 'origin/ignite-2.0' into ignite-2.0 commit 4cd332b781cf700b99402eed2363f988f6403602 Author: Sergey Chugunov Date: 2017-01-19T12:05:09Z IGNITE-4157 Use discovery custom messages instead of marshaller cache - Fixes #1271. Signed-off-by: Alexey Goncharuk commit d0a6c57aa26bca64ef68370c0ebdb5ce45bcc765 Author: Pavel Tupitsyn Date: 2017-01-19T14:10:41Z IGNITE-4441 Define plugin API in .NET This closes #1362 commit 34a97833905a33bdb31b8e4580a576c2142313a7 Author: Alexey Goncharuk Date: 2017-01-19T15:04:23Z IGNITE-4157 - Added mapping update listener stub commit e8377167b7b8dd020a93d92c743e4541dcd000ed Author: Pavel Tupitsyn Date: 2017-01-20T10:00:40Z Merge branch 'master' into ignite-2.0 commit 38cb67d45eb91e20ad4b92a490747534f5e8febb Author: Pavel Tupitsyn Date: 2017-01-20T13:09:57Z Merge branch 'master' into ignite-2.0 commit 82857d0cb6e2984a5359b822a9c903874414aa67 Author: Pavel Tupitsyn Date: 2017-01-23T10:12:12Z Merge branch 'master' into ignite-2.0 # Conflicts: # modules/hadoop/src/main/java/org/apache/ignite/internal/processors/hadoop/impl/v1/HadoopV1MapTask.java # modules/hadoop/src/main/java/org/apache/ignite/inte
[jira] [Assigned] (IGNITE-3471) Do not send previous value to client node for invoke() when possible
[
https://issues.apache.org/jira/browse/IGNITE-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Fedotov reassigned IGNITE-3471:
Assignee: Alexandr Fedotov
> Do not send previous value to client node for invoke() when possible
>
>
> Key: IGNITE-3471
> URL: https://issues.apache.org/jira/browse/IGNITE-3471
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 1.4
>Reporter: Alexey Goncharuk
>Assignee: Alexandr Fedotov
> Attachments: CacheEntryProcessorTxSelfTest.java
>
>
> Currently for invoke() or invokeAll() methods we send previous cache value to
> near node and apply EntryProcessor locally to get a return value. This can
> induce a significant overhead when cache value is much larger than entry
> processor result.
> For many cases this can be avoided, e.g.
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> tx.commit();
> }
> {code}
> Note that we need to add additional handling of such a case:
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> cache.get(key); // This should actually get the current cache value from
> primary node and apply an entry processor locally to get the updated value.
> tx.commit();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log
[
https://issues.apache.org/jira/browse/IGNITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857821#comment-15857821
]
Vyacheslav Daradur edited comment on IGNITE-4374 at 2/8/17 12:33 PM:
-
[~dmagda]
Done.
Current output:
{code}
[11:54:40]
[11:54:41] Message queue limit is set to 0 which may lead to potential OOMEs
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
message queues growth on sender and receiver sides.
[11:54:41] Security status [authentication=off, tls/ssl=off]
[11:54:43] Performance suggestions for grid (fix if possible)
[11:54:43] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[11:54:43] ^-- JVM heap size is greater than 30.5Gb, JVM will not use
compressed oops
[11:54:43] ^-- Enable server mode for JVM (add '-server' to JVM options)
[11:54:43] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options)
[11:54:43] ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
JVM options)"
[11:54:43] ^-- Specify New I/O max total size (add
'-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
[11:54:43] ^-- Enable the thread-local allocation blocks (add '-XX:+UseTLAB'
to JVM options)
[11:54:43] ^-- Disable processing of calls to System.gc() (add
'-XX:+DisableExplicitGC' to JVM options)
[11:54:43] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs and vm.dirty_expire_centisecs parameters by
setting to 500)
[11:54:43] ^-- Reduce pages swapping ratio (set vm.swappiness=10)
[11:54:43] ^-- Disable NUMA memory reclaim (set vm.zone_reclaim_mode=0)
[11:54:43] ^-- Avoid direct reclaim and page allocation failures (set
vm.extra_free_kbytes=124)
[11:54:43] Refer to this page for more performance suggestions:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
[11:54:43]
[11:54:43] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[11:54:43]
[11:54:43] Ignite node started OK (id=8bf18ef1)
[11:54:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=1, heap=1.0GB]
{code}
These lines are optionaly:
{code}
[11:59:07] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_expire_centisecs parameter by setting to 500)
or
[12:34:01] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs parameter by setting to 500)
or
[12:33:01] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs and vm.dirty_expire_centisecs parameters by
setting to 500)
{code}
bq. Avoid direct reclaim and page allocation failures (set vm.extra_free_kbytes
to 124 or other value).
We check equality to 124. If we write "or other value", we should change
the check and the article.
[Latest ci.tests|http://ci.ignite.apache.org/viewQueued.html?itemId=449798]
was (Author: daradurvs):
[~dmagda]
Done.
Current output:
{code}
[11:54:40]
[11:54:41] Message queue limit is set to 0 which may lead to potential OOMEs
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
message queues growth on sender and receiver sides.
[11:54:41] Security status [authentication=off, tls/ssl=off]
[11:54:43] Performance suggestions for grid (fix if possible)
[11:54:43] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[11:54:43] ^-- JVM heap size is greater than 30.5Gb, JVM will not use
compressed oops
[11:54:43] ^-- Enable server mode for JVM (add '-server' to JVM options)
[11:54:43] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options)
[11:54:43] ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
JVM options)"
[11:54:43] ^-- Specify New I/O max total size (add
'-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
[11:54:43] ^-- Enable the thread-local allocation blocks (add '-XX:+UseTLAB'
to JVM options)
[11:54:43] ^-- Disable processing of calls to System.gc() (add
'-XX:+DisableExplicitGC' to JVM options)
[11:54:43] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_writeback_centisecs and vm.dirty_expire_centisecs parameters by
setting to 500)
[11:54:43] ^-- Reduce pages swapping ratio (set vm.swappiness=10)
[11:54:43] ^-- Disable NUMA memory reclaim (set vm.zone_reclaim_mode=0)
[11:54:43] ^-- Avoid direct reclaim and page allocation failures (set
vm.extra_free_kbytes=124)
[11:54:43] Refer to this page for more performance suggestions:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
[11:54:43]
[11:54:43] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[11:54:43]
[11:54:43] Ignite node started OK (id=8bf18ef1)
[11:54:43] Topology snapshot [ver=1, servers=1, clients=0, CPUs=1, heap=1.0GB]
{code}
These lines are optionaly:
{code}
[11:59:07] ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_expire_centisecs parameter by setting to 500)
or
[12:34:01] ^-- Speed up flushing of dirty
[jira] [Commented] (IGNITE-4581) Async API: IgniteCache refactoring
[
https://issues.apache.org/jira/browse/IGNITE-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857951#comment-15857951
]
Taras Ledkov commented on IGNITE-4581:
--
Sure. I'm going to remove in the merging branch (e.g. branch for parent ticket
4475) because in needs to merge all platform related changes.
> Async API: IgniteCache refactoring
> ---
>
> Key: IGNITE-4581
> URL: https://issues.apache.org/jira/browse/IGNITE-4581
> Project: Ignite
> Issue Type: Sub-task
> Components: cache, general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{IgniteCache}} refactoring to simplify the async API.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4581) Async API: IgniteCache refactoring
[
https://issues.apache.org/jira/browse/IGNITE-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857951#comment-15857951
]
Taras Ledkov edited comment on IGNITE-4581 at 2/8/17 1:00 PM:
--
Sure. I'm going to remove the {{PlatformAsyncTarget.currentFuture()}} in the
merging branch (e.g. branch for parent ticket 4475) because in needs to merge
all platform related changes.
was (Author: tledkov-gridgain):
Sure. I'm going to remove in the merging branch (e.g. branch for parent ticket
4475) because in needs to merge all platform related changes.
> Async API: IgniteCache refactoring
> ---
>
> Key: IGNITE-4581
> URL: https://issues.apache.org/jira/browse/IGNITE-4581
> Project: Ignite
> Issue Type: Sub-task
> Components: cache, general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{IgniteCache}} refactoring to simplify the async API.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4663) BinaryUtils.doReadObjectArray can not read array with platform-only element type
[
https://issues.apache.org/jira/browse/IGNITE-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-4663:
---
Description:
{{BinaryUtils.doReadObjectArray}} performs unnecessary class lookup when
{{deserialize = false}}. When array elements are of platform-only type
({{platformId != 0}}), the class can never be resolved.
* arrays of user-defined types are not supported for platforms
* performance is suboptimal in binary mode (in Java and platforms)
Stack trace for platforms problem:
{{code}}
Java exception occurred
[class=org.apache.ignite.binary.BinaryInvalidTypeException, message=Unknown
pair [platformId= 0, typeId=3184265]]
> Apache.Ignite.Core.Common.JavaException : class
org.apache.ignite.binary.BinaryInvalidTypeException: Unknown pair [platformId=
0, typeId=3184265]
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:691)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1521)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1441)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadObjectArray(BinaryUtils.java:1884)
at
org.apache.ignite.internal.binary.BinaryUtils.unmarshal(BinaryUtils.java:1838)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readObjectDetached(BinaryReaderExImpl.java:1129)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:409)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:61)
{{code}}
was:
{{BinaryUtils.doReadObjectArray}} performs unnecessary class lookup when
{{deserialize = false}}. When array elements are of platform-only type
({{platformId != 0}}), the class can never be resolved.
* arrays of user-defined types are not supported for platforms
* performance is suboptimal in binary mode (in Java and platforms)
> BinaryUtils.doReadObjectArray can not read array with platform-only element
> type
>
>
> Key: IGNITE-4663
> URL: https://issues.apache.org/jira/browse/IGNITE-4663
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{BinaryUtils.doReadObjectArray}} performs unnecessary class lookup when
> {{deserialize = false}}. When array elements are of platform-only type
> ({{platformId != 0}}), the class can never be resolved.
> * arrays of user-defined types are not supported for platforms
> * performance is suboptimal in binary mode (in Java and platforms)
> Stack trace for platforms problem:
> {{code}}
> Java exception occurred
> [class=org.apache.ignite.binary.BinaryInvalidTypeException, message=Unknown
> pair [platformId= 0, typeId=3184265]]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.binary.BinaryInvalidTypeException: Unknown pair
> [platformId= 0, typeId=3184265]
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:691)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1521)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1441)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObjectArray(BinaryUtils.java:1884)
> at
> org.apache.ignite.internal.binary.BinaryUtils.unmarshal(BinaryUtils.java:1838)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readObjectDetached(BinaryReaderExImpl.java:1129)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:409)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:61)
> {{code}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4577) Ensure that certain interface addresses can be excluded form node attributes
[
https://issues.apache.org/jira/browse/IGNITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev reassigned IGNITE-4577:
-
Assignee: Evgenii Zhuravlev (was: Dmitry Karachentsev)
> Ensure that certain interface addresses can be excluded form node attributes
>
>
> Key: IGNITE-4577
> URL: https://issues.apache.org/jira/browse/IGNITE-4577
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Evgenii Zhuravlev
> Fix For: 2.0
>
>
> *Problem*
> Consider a case when node has some network interface which is not accessible
> from the outside (e.g. in Docker container). Ignite adds this address to
> attributes, which are shared with other nodes. Now if remote want to
> communicate with local node chances that he will try to establish connection
> with invalid address.
> In the worst case connection will be impossible. We use {{AddressResolver}}
> to handle this situation.
> However, it appears that {{AddressResolver}} cannot prevent certain address
> to appear in address list. As a result users may experience communication
> delays as we establish peer-to-peer connection in one thread, iterating over
> all available addresses.
> *Proposed solution*
> We need to examine what happens when address resolver is set. May be it is
> necessary to rethink how we handle returned object. E.g. {{null}} or empty
> collection might mean that this address should not be included into the list
> of address. However, it may break existing applications, so chances that
> other solution is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4663) BinaryUtils.doReadObjectArray can not read array with platform-only element type
[
https://issues.apache.org/jira/browse/IGNITE-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-4663:
---
Description:
{{BinaryUtils.doReadObjectArray}} performs unnecessary class lookup when
{{deserialize = false}}. When array elements are of platform-only type
({{platformId != 0}}), the class can never be resolved.
* arrays of user-defined types are not supported for platforms
* performance is suboptimal in binary mode (in Java and platforms)
Stack trace for platforms problem:
{code}
Java exception occurred
[class=org.apache.ignite.binary.BinaryInvalidTypeException, message=Unknown
pair [platformId= 0, typeId=3184265]]
> Apache.Ignite.Core.Common.JavaException : class
org.apache.ignite.binary.BinaryInvalidTypeException: Unknown pair [platformId=
0, typeId=3184265]
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:691)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1521)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1441)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadObjectArray(BinaryUtils.java:1884)
at
org.apache.ignite.internal.binary.BinaryUtils.unmarshal(BinaryUtils.java:1838)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readObjectDetached(BinaryReaderExImpl.java:1129)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:409)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:61)
{code}
was:
{{BinaryUtils.doReadObjectArray}} performs unnecessary class lookup when
{{deserialize = false}}. When array elements are of platform-only type
({{platformId != 0}}), the class can never be resolved.
* arrays of user-defined types are not supported for platforms
* performance is suboptimal in binary mode (in Java and platforms)
Stack trace for platforms problem:
{{code}}
Java exception occurred
[class=org.apache.ignite.binary.BinaryInvalidTypeException, message=Unknown
pair [platformId= 0, typeId=3184265]]
> Apache.Ignite.Core.Common.JavaException : class
org.apache.ignite.binary.BinaryInvalidTypeException: Unknown pair [platformId=
0, typeId=3184265]
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:691)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1521)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1441)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadObjectArray(BinaryUtils.java:1884)
at
org.apache.ignite.internal.binary.BinaryUtils.unmarshal(BinaryUtils.java:1838)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readObjectDetached(BinaryReaderExImpl.java:1129)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:409)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:61)
{{code}}
> BinaryUtils.doReadObjectArray can not read array with platform-only element
> type
>
>
> Key: IGNITE-4663
> URL: https://issues.apache.org/jira/browse/IGNITE-4663
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{BinaryUtils.doReadObjectArray}} performs unnecessary class lookup when
> {{deserialize = false}}. When array elements are of platform-only type
> ({{platformId != 0}}), the class can never be resolved.
> * arrays of user-defined types are not supported for platforms
> * performance is suboptimal in binary mode (in Java and platforms)
> Stack trace for platforms problem:
> {code}
> Java exception occurred
> [class=org.apache.ignite.binary.BinaryInvalidTypeException, message=Unknown
> pair [platformId= 0, typeId=3184265]]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.binary.BinaryInvalidTypeException: Unknown pair
> [platformId= 0, typeId=3184265]
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:691)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1521)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1441)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObjectArray(BinaryUtils.java:1884)
> at
> org.apache.ignite.internal.binary.BinaryUtils.unmarshal(BinaryUtils.java:1838)
> at
> org
[jira] [Assigned] (IGNITE-3387) NPE deploy ignite with mesos
[
https://issues.apache.org/jira/browse/IGNITE-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Menshikov reassigned IGNITE-3387:
---
Assignee: Alexander Menshikov
> NPE deploy ignite with mesos
>
>
> Key: IGNITE-3387
> URL: https://issues.apache.org/jira/browse/IGNITE-3387
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.7
>Reporter: Ilya Suntsov
>Assignee: Alexander Menshikov
> Fix For: 2.0
>
>
> I tried to use marathon to deploy ignite with mesos:
> {noformat}
> curl -X POST -H "Content-type: application/json" --data-binary @marathon.json
> http://192.168.2.106:8080/v2/apps/
> {noformat}
> where marathon.json contains:
> {noformat}
> "id": "ignition",
> "instances": 1,
> "cpus": 1,
> "mem": 512,
> "ports": [0],
> "uris": [
> "https://s3-us-west-2.amazonaws.com/mesos-1234/ignite-mesos-1.6.0.jar";
> ],
> "env": {
> "IGNITE_NODE_COUNT": "4",
> "MESOS_MASTER_URL": "zk://192.168.2.106:2181/mesos",
> "IGNITE_RUN_CPU_PER_NODE": "2",
> "IGNITE_MEMORY_PER_NODE": "2048",
> "IGNITE_VERSION":"6.6.6"
> },
> "cmd": "java -jar ignite-mesos-1.6.0.jar"
> {noformat}
> and got the following exception caused by wrong ignite version from
> marathon.json:
> {noformat}
> Exception in thread "Thread-11" java.lang.NullPointerException
> at
> org.apache.mesos.Protos$CommandInfo$URI$Builder.setValue(Protos.java:8069)
> at
> org.apache.ignite.mesos.IgniteScheduler.createTask(IgniteScheduler.java:128)
> at
> org.apache.ignite.mesos.IgniteScheduler.resourceOffers(IgniteScheduler.java:98)
> {noformat}
> I think we should return another exception/error to be clear what happened.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4663) BinaryUtils.doReadObjectArray can not read array with platform-only element type
[
https://issues.apache.org/jira/browse/IGNITE-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858012#comment-15858012
]
Taras Ledkov commented on IGNITE-4663:
--
[Tests
results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1507%2Fhead]
> BinaryUtils.doReadObjectArray can not read array with platform-only element
> type
>
>
> Key: IGNITE-4663
> URL: https://issues.apache.org/jira/browse/IGNITE-4663
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{BinaryUtils.doReadObjectArray}} performs unnecessary class lookup when
> {{deserialize = false}}. When array elements are of platform-only type
> ({{platformId != 0}}), the class can never be resolved.
> * arrays of user-defined types are not supported for platforms
> * performance is suboptimal in binary mode (in Java and platforms)
> Stack trace for platforms problem:
> {code}
> Java exception occurred
> [class=org.apache.ignite.binary.BinaryInvalidTypeException, message=Unknown
> pair [platformId= 0, typeId=3184265]]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.binary.BinaryInvalidTypeException: Unknown pair
> [platformId= 0, typeId=3184265]
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:691)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1521)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1441)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObjectArray(BinaryUtils.java:1884)
> at
> org.apache.ignite.internal.binary.BinaryUtils.unmarshal(BinaryUtils.java:1838)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readObjectDetached(BinaryReaderExImpl.java:1129)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:409)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:61)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4631) Node starts with incorrect QueryEntity configuration
[ https://issues.apache.org/jira/browse/IGNITE-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858027#comment-15858027 ] ASF GitHub Bot commented on IGNITE-4631: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1484 > Node starts with incorrect QueryEntity configuration > > > Key: IGNITE-4631 > URL: https://issues.apache.org/jira/browse/IGNITE-4631 > Project: Ignite > Issue Type: Bug > Components: SQL >Reporter: Sergey Kalashnikov >Assignee: Sergey Kalashnikov >Priority: Minor > Fix For: 1.9 > > Attachments: QueryEntityCaseMismatchTest.java > > > When QueryEntity.keyFields property is used to specify compound key fields, > it is possible to set the field names in wrong register. > The node would start normally, but for SQL queries requesting key fields the > resultset contains nulls in corresponding columns. > The query processor internally fails to tell the key field from value field > in this case. > Note that for optimized marshaller, the keyFields aren't taken into account > and queries return valid data. > I believe the node shall not start with such configuration at all. > See the attached test that reproduces the case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4631) Node starts with incorrect QueryEntity configuration
[
https://issues.apache.org/jira/browse/IGNITE-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858028#comment-15858028
]
Vladimir Ozerov edited comment on IGNITE-4631 at 2/8/17 2:13 PM:
-
[~skalashnikov],
Fix looks good. I performed several minor changes:
- Added field name to exception message
- Simplified test.
Please review these changes in {{master}}, commit {{46ff66e}}.
was (Author: vozerov):
[~skalashnikov],
Fix looks good. I performed several minor changes:
- Added field name to exception message
- Simplified test.
Please review this changes in {{master}}, commit {{46ff66e}}.
> Node starts with incorrect QueryEntity configuration
>
>
> Key: IGNITE-4631
> URL: https://issues.apache.org/jira/browse/IGNITE-4631
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
>Priority: Minor
> Fix For: 1.9
>
> Attachments: QueryEntityCaseMismatchTest.java
>
>
> When QueryEntity.keyFields property is used to specify compound key fields,
> it is possible to set the field names in wrong register.
> The node would start normally, but for SQL queries requesting key fields the
> resultset contains nulls in corresponding columns.
> The query processor internally fails to tell the key field from value field
> in this case.
> Note that for optimized marshaller, the keyFields aren't taken into account
> and queries return valid data.
> I believe the node shall not start with such configuration at all.
> See the attached test that reproduces the case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4663) BinaryUtils.doReadObjectArray can not read array with platform-only element type
[
https://issues.apache.org/jira/browse/IGNITE-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858033#comment-15858033
]
Pavel Tupitsyn commented on IGNITE-4663:
[~Alexey Kuznetsov] see https://apacheignite.readme.io/docs/binary-marshaller.
There are a lot of such use cases.
> BinaryUtils.doReadObjectArray can not read array with platform-only element
> type
>
>
> Key: IGNITE-4663
> URL: https://issues.apache.org/jira/browse/IGNITE-4663
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{BinaryUtils.doReadObjectArray}} performs unnecessary class lookup when
> {{deserialize = false}}. When array elements are of platform-only type
> ({{platformId != 0}}), the class can never be resolved.
> * arrays of user-defined types are not supported for platforms
> * performance is suboptimal in binary mode (in Java and platforms)
> Stack trace for platforms problem:
> {code}
> Java exception occurred
> [class=org.apache.ignite.binary.BinaryInvalidTypeException, message=Unknown
> pair [platformId= 0, typeId=3184265]]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.binary.BinaryInvalidTypeException: Unknown pair
> [platformId= 0, typeId=3184265]
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:691)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1521)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1441)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObjectArray(BinaryUtils.java:1884)
> at
> org.apache.ignite.internal.binary.BinaryUtils.unmarshal(BinaryUtils.java:1838)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readObjectDetached(BinaryReaderExImpl.java:1129)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:409)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:61)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4581) Async API: IgniteCache refactoring
[
https://issues.apache.org/jira/browse/IGNITE-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857951#comment-15857951
]
Taras Ledkov edited comment on IGNITE-4581 at 2/8/17 2:14 PM:
--
Fixed. Waits for TC [tests
results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1452%2Fhead]
was (Author: tledkov-gridgain):
Sure. I'm going to remove the {{PlatformAsyncTarget.currentFuture()}} in the
merging branch (e.g. branch for parent ticket 4475) because in needs to merge
all platform related changes.
> Async API: IgniteCache refactoring
> ---
>
> Key: IGNITE-4581
> URL: https://issues.apache.org/jira/browse/IGNITE-4581
> Project: Ignite
> Issue Type: Sub-task
> Components: cache, general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{IgniteCache}} refactoring to simplify the async API.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-4670) CPP: Implement LoadCache method
Igor Sapego created IGNITE-4670: --- Summary: CPP: Implement LoadCache method Key: IGNITE-4670 URL: https://issues.apache.org/jira/browse/IGNITE-4670 Project: Ignite Issue Type: Task Components: platforms Affects Versions: 1.8 Reporter: Igor Sapego Fix For: 1.9 Implement ability to load chace for C++ platform. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4671) FairAffinityFunction fails on node restart with backupFilter set and no backups
Dmitry Karachentsev created IGNITE-4671: --- Summary: FairAffinityFunction fails on node restart with backupFilter set and no backups Key: IGNITE-4671 URL: https://issues.apache.org/jira/browse/IGNITE-4671 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.8 Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev Fix For: 2.0 Setup: FairAffinityFunction with backup or affinity filter, number of cache backups is 0. On nodes restart fails on assertion in isAssignable() method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4670) CPP: Implement LoadCache method
[ https://issues.apache.org/jira/browse/IGNITE-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-4670: Description: Implement ability to load cache for C++ platform. (was: Implement ability to load chace for C++ platform.) > CPP: Implement LoadCache method > --- > > Key: IGNITE-4670 > URL: https://issues.apache.org/jira/browse/IGNITE-4670 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.8 >Reporter: Igor Sapego > Labels: cpp > Fix For: 1.9 > > > Implement ability to load cache for C++ platform. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4672) Optimization: for SQL indexes implement comparison using offheap pointer
Semen Boikov created IGNITE-4672: Summary: Optimization: for SQL indexes implement comparison using offheap pointer Key: IGNITE-4672 URL: https://issues.apache.org/jira/browse/IGNITE-4672 Project: Ignite Issue Type: Task Components: cache Reporter: Semen Boikov Assignee: Konstantin Dudkov Fix For: 2.0 Currently for objects comparison in sql indexes we copy full row data on heap, but when index is created on BinaryObject's field and object offheap address is known then it is possible do comparison withput on heap copy and object instantiation. Prototype is implemented in branch ignite-3477-offheap-cmp. Note: IGNITE-4629 partially fixes issue with comparison, but it is not possible to use this optimization in all cases. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible
[
https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858058#comment-15858058
]
Pavel Tupitsyn commented on IGNITE-2703:
Refactored {{IObjectReference}} handling to avoid copying fields and return
original instance from {{GetRealObject}}. This is important for {{Type}},
{{Module}}, {{Assembly}}, and other classes that should always result in the
same value.
> .NET: Dynamically registered classes must use binary serialization if possible
> --
>
> Key: IGNITE-2703
> URL: https://issues.apache.org/jira/browse/IGNITE-2703
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
> Labels: .net, breaking-api
> Fix For: 2.0
>
>
> At present we support dynamic class registration in .NET, but they are
> written using deafult .NET mechanism. This is counterintuitive for users and
> not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could
> be serialized through binary or not. If not - print a warning and fallback to
> .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is
> known to the cluster. If not - write full class name instead of type ID. Java
> already do that.
> 3) Last, to support backward compatibility we must be able to fallback to
> current mode with help of some boolean flag.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4490) Optimize DML for fast INSERT and MERGE
[
https://issues.apache.org/jira/browse/IGNITE-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858072#comment-15858072
]
Alexander Paschenko commented on IGNITE-4490:
-
[~vozerov]
No, this issue is not concerned with {{_key}} or {{_val}}. It's about any
columns and cases when the user provides values for them as literals (either in
query string or via statement params) and no additional computations needs to
be done to evaluate expressions and functions. As I wrote in my comment above:
{quote}
What has changed: when query contains no expressions, just constants and
parameters, and insert is done in rows based manner, then such query is
processed in a way similar to fast UPDATE and DELETE.
{quote}
> Optimize DML for fast INSERT and MERGE
> --
>
> Key: IGNITE-4490
> URL: https://issues.apache.org/jira/browse/IGNITE-4490
> Project: Ignite
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> It's possible to avoid any SQL querying and map some INSERT and MERGE
> statements to cache operations in a way similar to that of UPDATE and DELETE
> - i.e. don't make queries when there are no expressions to evaluate in the
> query and enhance update plans to perform direct cache operations when INSERT
> and MERGE affect columns {{_key}} and {{_val}} only.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4629) Optimization: store value of indexed field in H2Tree
[ https://issues.apache.org/jira/browse/IGNITE-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858088#comment-15858088 ] Semen Boikov commented on IGNITE-4629: -- Hi Konstantin, I reviewed changes and have one question: will new code work if index is created on, say, Integer field, but actual value of this field during cache put is null, please add such test. Thanks! > Optimization: store value of indexed field in H2Tree > > > Key: IGNITE-4629 > URL: https://issues.apache.org/jira/browse/IGNITE-4629 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Konstantin Dudkov > Fix For: 2.0 > > > Currently we store only 'link' in H2Tree and to do comparison we read lock > data page and copy row data into GridH2Row. If indexed value is primitive > then it is possible to store this value in H2Tree, so get value for > comparison will be just Unsafe.getInt/getLong. > Prototype is implemented in ignite-3477-idx. (branch is based on ignite-3477). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4673) Object array element type is written as a user type
Pavel Tupitsyn created IGNITE-4673:
--
Summary: Object array element type is written as a user type
Key: IGNITE-4673
URL: https://issues.apache.org/jira/browse/IGNITE-4673
Project: Ignite
Issue Type: Bug
Components: binary
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
Fix For: 2.0
{{BinaryWriterExImpl.doWriteObjectArray}} registers {{java.lang.Object}}
element type as a custom type instead of using {{OBJECT_TYPE_ID}}.
As a result, platforms (.NET, C++) can not understand such an array.
This is also suboptimal due to extra type registration and lookups.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible
[ https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858102#comment-15858102 ] Pavel Tupitsyn commented on IGNITE-2703: Another Java issue uncovered: IGNITE-4673 > .NET: Dynamically registered classes must use binary serialization if possible > -- > > Key: IGNITE-2703 > URL: https://issues.apache.org/jira/browse/IGNITE-2703 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn > Labels: .net, breaking-api > Fix For: 2.0 > > > At present we support dynamic class registration in .NET, but they are > written using deafult .NET mechanism. This is counterintuitive for users and > not consistent with Java, where such classes are written in binary form. > Proposed implementation plan: > 1) For each dynamically registered class we must understand whether it could > be serialized through binary or not. If not - print a warning and fallback to > .NET. > 2) Before writing a class we must ensure that it's [typeId -> name] pair is > known to the cluster. If not - write full class name instead of type ID. Java > already do that. > 3) Last, to support backward compatibility we must be able to fallback to > current mode with help of some boolean flag. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4673) Object array element type is written as a user type
[
https://issues.apache.org/jira/browse/IGNITE-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reassigned IGNITE-4673:
Assignee: Taras Ledkov
> Object array element type is written as a user type
> ---
>
> Key: IGNITE-4673
> URL: https://issues.apache.org/jira/browse/IGNITE-4673
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> {{BinaryWriterExImpl.doWriteObjectArray}} registers {{java.lang.Object}}
> element type as a custom type instead of using {{OBJECT_TYPE_ID}}.
> As a result, platforms (.NET, C++) can not understand such an array.
> This is also suboptimal due to extra type registration and lookups.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4302) Exchange binary metadata with discovery custom messages instead of system cache
[ https://issues.apache.org/jira/browse/IGNITE-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858134#comment-15858134 ] Sergey Chugunov commented on IGNITE-4302: - Identified and addressed some flaws in client node flow that might lead to lost updates on client side. Flaws were caused by the fact that on client side metadata updates may happen in two competitive ways: via discovery messaging and via communication messaging. Fixed two minor issues. > Exchange binary metadata with discovery custom messages instead of system > cache > --- > > Key: IGNITE-4302 > URL: https://issues.apache.org/jira/browse/IGNITE-4302 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov > Fix For: 2.0 > > > h4. Notes > See [IGNITE-4157|https://issues.apache.org/jira/browse/IGNITE-4157] for more > details about context. > h4. Acceptance Criteria > # Binary metadata cache is deleted. > # Binary metadata exchange is performed using *DiscoveryCustomMessage* events. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4526) Add Spark Shared RDD examples
[ https://issues.apache.org/jira/browse/IGNITE-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4526: - Fix Version/s: (was: 2.0) 1.9 > Add Spark Shared RDD examples > - > > Key: IGNITE-4526 > URL: https://issues.apache.org/jira/browse/IGNITE-4526 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Manish Mishra > Fix For: 1.9 > > Attachments: profiles.png, SuiteSnapShot.png > > > Spark Shared RDD functionality doesn't have its own examples. We need to add > an example that will do the following: > - First Spark Worker: creation of a shared RDD and filling it in with data. > - First Spark Worker: performing some native spark transformation with the > RDD. > - Second Spark Worker: connecting to the same shared RDD. > - Second Spark Worker: execution of SQL query using Spark API and Ignite API. > Show that Ignite's query executes faster. > The reason why the example should consist of two workers is to showcase one > of the main benefits of Ignite's RDDs - ability to share the state (RDD) amid > different Spark workers and processes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-3822) Update ignite-spark to 2.11 v2.0.0
[ https://issues.apache.org/jira/browse/IGNITE-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-3822: - Fix Version/s: (was: 2.0) 1.9 > Update ignite-spark to 2.11 v2.0.0 > -- > > Key: IGNITE-3822 > URL: https://issues.apache.org/jira/browse/IGNITE-3822 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Dovid Kopel >Assignee: Valentin Kulichenko > Labels: important > Fix For: 1.9 > > > Update ignite-spark to newest release version of Apache Spark: > https://mvnrepository.com/artifact/org.apache.spark/spark-core_2.11/2.0.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4159) Cloud Native Deployment of Apache Ignite using Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4159: - Fix Version/s: (was: 2.0) 1.9 > Cloud Native Deployment of Apache Ignite using Kubernetes > - > > Key: IGNITE-4159 > URL: https://issues.apache.org/jira/browse/IGNITE-4159 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Magda >Assignee: Denis Magda > Fix For: 1.9 > > > Kubernetes is an open-source system for automating deployment, scaling, and > management of containerized applications. > http://kubernetes.io > Apache Ignite perfectly fits the concepts implemented in Kubernetes which may > greatly simplify and automate the maintenance and scaling of Apache Ignite > clusters running under the supervision of Kubernetes. > Ignite won't be the first distributed storage that supports Kubernetes. There > are already a number of existed ones that being used: > https://github.com/kubernetes/kubernetes/tree/master/examples/storage/cassandra > https://github.com/pires/hazelcast-kubernetes > https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes > This is an umbrella ticket that incorporates all the works that have to be > done before Ignite officially claims that it can be launched under Kubernetes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4523) Allow distributed SQL query execution over explicit set of partitions
[ https://issues.apache.org/jira/browse/IGNITE-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858189#comment-15858189 ] ASF GitHub Bot commented on IGNITE-4523: GitHub user skalashnikov opened a pull request: https://github.com/apache/ignite/pull/1508 IGNITE-4523 Allow distributed SQL query execution over explicit set of partitions You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4523 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1508.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1508 commit 153d4a374fe6cf6c80eb895920ec279f483ab1d7 Author: ascherbakoff Date: 2017-01-06T15:56:07Z IGNITE-4523 WIP. commit 31c5e42e67fc958e77f3014c364a8e14b236bd8d Author: ascherbakoff Date: 2017-01-07T13:11:58Z IGNITE-4523 WIP. commit dea221c15b8e2136f35ab6ab0abacb3b658aa626 Author: Aleksei Scherbakov Date: 2017-01-10T17:30:10Z IGNITE-4523 WIP. commit 3238365c3c04fcd7db309650012f43aa26bd6a8d Author: Aleksei Scherbakov Date: 2017-01-10T17:30:34Z IGNITE-4523 WIP. commit 570cfd7457feb6d1bb95ef4dbae77d0c8d0c5e6c Author: Aleksei Scherbakov Date: 2017-01-10T17:32:31Z Merge branch 'master' of https://github.com/apache/ignite into ignite-4523 commit 1fe53872446c31da15ac7ab2fe101bb3988bd4e8 Author: ascherbakoff Date: 2017-01-10T20:50:14Z IGNITE-4523 Moved PartitionSet field to base class. commit b2eda3058463c4eceb0054052b66fbd13783df18 Author: Aleksei Scherbakov Date: 2017-01-11T16:22:25Z IGNITE-4523 Style cleanup. commit d48aa541733f0725a73bd09d6f136b81137c729a Author: Aleksei Scherbakov Date: 2017-01-11T16:30:36Z IGNITE-4523 Style cleanup. commit d8ee9edda9e74cc88ac5f756b7f59639ef4b9f3e Author: Aleksei Scherbakov Date: 2017-01-11T16:33:14Z Merge branch 'ignite-4523' of https://github.com/ascherbakoff/ignite into ignite-4523 commit f4992a0daed06f47dee7e21c5fc9aee5f3a79d6c Author: Aleksei Scherbakov Date: 2017-01-11T16:42:22Z IGNITE-4523 Style cleanup. commit 4f2843e3c4a212d605d1627c66de61ae8304d386 Author: Aleksei Scherbakov Date: 2017-01-11T16:49:57Z IGNITE-4523 Style cleanup. commit 901c0e69a3cf28807dbdc182fc76f0ba51c36855 Author: Aleksei Scherbakov Date: 2017-01-11T17:03:54Z IGNITE-4523 Style cleanup. commit 4dcfaad50aac20370a96acbc6e6d0768b8f90b7c Author: Aleksei Scherbakov Date: 2017-01-11T17:17:31Z IGNITE-4523 Style cleanup. commit 1945e63b684f4779a99ef32ca59df7650e03f358 Author: Aleksei Scherbakov Date: 2017-01-16T15:49:32Z IGNITE-4523 Public API is updated. commit 432c44f517bf25c14825328b233123f540fc4e03 Author: ascherbakoff Date: 2017-01-16T21:49:27Z IGNITE-4523 GridIntSet. commit af5cfddb483ef7f13c54eaf66fb1ca54c9063de9 Author: Aleksei Scherbakov Date: 2017-01-17T16:36:14Z IGNITE-4523 Working on integer set. commit 825adc6451dd8b3fe2bfa2be2a749eef7e27fa6b Author: ascherbakoff Date: 2017-01-17T20:54:49Z IGNITE-4523 Refactored to int[]. commit 24944785d46ff52dbd50672d6ee50854ae7b8bf9 Author: ascherbakoff Date: 2017-01-17T20:58:33Z IGNITE-4523 Refactored to int[]. commit 3299916e00f2d707c64844b506832f3aea98 Author: ascherbakoff Date: 2017-01-17T21:06:13Z IGNITE-4523 Refactored to int[]. commit defa40c5e456b8d67bec8379ee020a0df029ac1f Author: Aleksei Scherbakov Date: 2017-01-18T17:17:05Z IGNITE-4523 WIP commit e8874398a2b882af769c5777f19544b9db843dc4 Author: Aleksei Scherbakov Date: 2017-01-18T17:17:33Z IGNITE-4523 WIP commit 0491acb5c4ae50ea0c55a6af186a17937b1868ec Author: Aleksei Scherbakov Date: 2017-01-18T17:22:42Z IGNITE-4523 Add test to suite. commit 0f95f6902fa63d02b756eb970961a227a9c77f48 Author: ascherbakoff Date: 2017-01-18T21:01:10Z IGNITE-4523 Better API validation. commit f27e40c515336c037d5e0da6f9042c9a7839f2f8 Author: ascherbakoff Date: 2017-01-18T21:01:26Z IGNITE-4523 Better API validation. commit 904ebdd9a33f2e3eaa90ef6fa835ad134362e3c1 Author: ascherbakoff Date: 2017-01-18T21:08:04Z IGNITE-4523 Better API validation. commit da3a17ecd0f90b76058a5fef396c7822bdba5951 Author: Aleksei Scherbakov Date: 2017-01-19T16:42:34Z IGNITE-4523 Public API changes. commit f21b215540214d0fd95140db4388f54298d2aa3e Author: Aleksei Scherbakov Date: 2017-01-20T14:46:09Z IGNITE-4523 Fixing local query. commit 7311f6502506c66ada91614e1e090cfd86beb1a5 Author: Aleksei Scherbakov Date: 2017-02-01T16:57:46Z IGNITE-4523 Local scan query is working. commit 850411f6076d461e63e88b4b7f7460f8da75fa30 Author: Aleksei Scherbakov Date: 2017-02-02T17:35:00Z IGNITE-4523 Remote scan query is working. commit 380051e28173
[jira] [Commented] (IGNITE-4523) Allow distributed SQL query execution over explicit set of partitions
[ https://issues.apache.org/jira/browse/IGNITE-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858197#comment-15858197 ] Sergey Kalashnikov commented on IGNITE-4523: Added the check to forbid queries that have both partitions and distributed joins options set. Fixed some tests. New PR https://github.com/apache/ignite/pull/1508 > Allow distributed SQL query execution over explicit set of partitions > - > > Key: IGNITE-4523 > URL: https://issues.apache.org/jira/browse/IGNITE-4523 > Project: Ignite > Issue Type: Improvement > Components: cache, SQL >Affects Versions: 1.8 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov > Fix For: 1.9 > > > 3Currently distributed SQL query is executed on all nodes containing primary > partitions for a cache, sending map query requests on all nodes in grid. > Sometimes we know in advance which partitions hold a data for query, on > example, in case of custom affinity function. > Therefore it's possible to reduce number of nodes receiving map query request > by providing explicit set of partitions, which will give significant > performance advantage and traffic reduction in case of very large clusters. > Internally we already have such functionality, so the only necessary thing is > to provide public API for what. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4539) RocketMQ data streamer
[ https://issues.apache.org/jira/browse/IGNITE-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4539: - Fix Version/s: 1.9 > RocketMQ data streamer > -- > > Key: IGNITE-4539 > URL: https://issues.apache.org/jira/browse/IGNITE-4539 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Fix For: 1.9 > > > Streamer for RocketMQ (https://github.com/rocketmq) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4212) Ignite Benchmarking Simplification and Automation
[ https://issues.apache.org/jira/browse/IGNITE-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4212: - Fix Version/s: (was: 2.0) 1.9 > Ignite Benchmarking Simplification and Automation > - > > Key: IGNITE-4212 > URL: https://issues.apache.org/jira/browse/IGNITE-4212 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Oleg Ostanin > Fix For: 1.9 > > Attachments: README.txt > > > There is a plenty of useful Yardstick benchmarks located in ignite-yardstick > module that is used by the community to check Ignite performance across > deployments of different configurations. > However, it's not easy to start with the benchmarking process because the > user needs to download Ignite, build and set up benchmarks and only after > that run them. > The goal of this task is to simplify the process in the following way: > 1) ignite-yardstick benchmarks have to be pre-compiled and available with > every Ignite deliverable. > 2) every deliverable must contain an executable (bat or sh file) with a clear > instruction on how to start a specific benchmark from the console. > 3) the executable has to use some default yardstick configuration. The first > configuration should be intented for local execution (multicast IP finder) > and the second needs to be AWS oriented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-3387) NPE deploy ignite with mesos
[
https://issues.apache.org/jira/browse/IGNITE-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Menshikov reassigned IGNITE-3387:
---
Assignee: (was: Alexander Menshikov)
> NPE deploy ignite with mesos
>
>
> Key: IGNITE-3387
> URL: https://issues.apache.org/jira/browse/IGNITE-3387
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.7
>Reporter: Ilya Suntsov
> Fix For: 2.0
>
>
> I tried to use marathon to deploy ignite with mesos:
> {noformat}
> curl -X POST -H "Content-type: application/json" --data-binary @marathon.json
> http://192.168.2.106:8080/v2/apps/
> {noformat}
> where marathon.json contains:
> {noformat}
> "id": "ignition",
> "instances": 1,
> "cpus": 1,
> "mem": 512,
> "ports": [0],
> "uris": [
> "https://s3-us-west-2.amazonaws.com/mesos-1234/ignite-mesos-1.6.0.jar";
> ],
> "env": {
> "IGNITE_NODE_COUNT": "4",
> "MESOS_MASTER_URL": "zk://192.168.2.106:2181/mesos",
> "IGNITE_RUN_CPU_PER_NODE": "2",
> "IGNITE_MEMORY_PER_NODE": "2048",
> "IGNITE_VERSION":"6.6.6"
> },
> "cmd": "java -jar ignite-mesos-1.6.0.jar"
> {noformat}
> and got the following exception caused by wrong ignite version from
> marathon.json:
> {noformat}
> Exception in thread "Thread-11" java.lang.NullPointerException
> at
> org.apache.mesos.Protos$CommandInfo$URI$Builder.setValue(Protos.java:8069)
> at
> org.apache.ignite.mesos.IgniteScheduler.createTask(IgniteScheduler.java:128)
> at
> org.apache.ignite.mesos.IgniteScheduler.resourceOffers(IgniteScheduler.java:98)
> {noformat}
> I think we should return another exception/error to be clear what happened.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4631) Node starts with incorrect QueryEntity configuration
[ https://issues.apache.org/jira/browse/IGNITE-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858261#comment-15858261 ] Sergey Kalashnikov commented on IGNITE-4631: Vova, I have reviewed the changes you made. Thank you. > Node starts with incorrect QueryEntity configuration > > > Key: IGNITE-4631 > URL: https://issues.apache.org/jira/browse/IGNITE-4631 > Project: Ignite > Issue Type: Bug > Components: SQL >Reporter: Sergey Kalashnikov >Assignee: Sergey Kalashnikov >Priority: Minor > Fix For: 1.9 > > Attachments: QueryEntityCaseMismatchTest.java > > > When QueryEntity.keyFields property is used to specify compound key fields, > it is possible to set the field names in wrong register. > The node would start normally, but for SQL queries requesting key fields the > resultset contains nulls in corresponding columns. > The query processor internally fails to tell the key field from value field > in this case. > Note that for optimized marshaller, the keyFields aren't taken into account > and queries return valid data. > I believe the node shall not start with such configuration at all. > See the attached test that reproduces the case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log
[ https://issues.apache.org/jira/browse/IGNITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858282#comment-15858282 ] Denis Magda commented on IGNITE-4374: - [~yzhdanov], any comments from your side? Looks good to me for merge. > Ignite should validate JVM and OS configuration and output warning in log > - > > Key: IGNITE-4374 > URL: https://issues.apache.org/jira/browse/IGNITE-4374 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Yakov Zhdanov >Assignee: Vyacheslav Daradur > Attachments: x32_not_optimized.png, x32_optimized.png, > x64_not_optimized.png, x64_optimized.png > > > Currently we have GridPerformanceSuggestions that output suggestions to logs > on Ignite start on how Ignite can be improved. > I suggest to go a little bit deeper and validate more configuration options > and add validation for JVM and OS settings. > Ignite should output warning if: > * GC logging is not enabled > * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize) > * Heap size is greater than 30,5G and JVM cannot use compressed oops > * Any of the recommended OS setting described here > https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly > set -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4661) Optimizations: optimize PagesList.removeDataPage
[ https://issues.apache.org/jira/browse/IGNITE-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858300#comment-15858300 ] Igor Seliverstov commented on IGNITE-4661: -- First algorythm version is implemented, tests added, working on local benchmarks > Optimizations: optimize PagesList.removeDataPage > > > Key: IGNITE-4661 > URL: https://issues.apache.org/jira/browse/IGNITE-4661 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Semen Boikov >Assignee: Igor Seliverstov > Fix For: 2.0 > > > Optimization for new PageMemory approach (IGNITE-3477, branch ignite-3477). > Currently PagesList.removeDataPage requires linear search by page ID, need > check if it makes sense to change structure of PagesList's element from list > to hash table. > Here are links to proposed hash table alrorithm: > http://codecapsule.com/2013/11/11/robin-hood-hashing > http://codecapsule.com/2013/11/17/robin-hood-hashing-backward-shift-deletion/ > Note: with hash table approach 'take' from PagesList will require linear > search, so we'll also need some heuristic to make it more optimal. > For more details see: > IgniteCacheOffheapManagerImpl.update -> FreeListImpl.insertDataRow, > IgniteCacheOffheapManagerImpl.update -> FreeListImpl.removeDataRowByLink. > To check result of optimization IgnitePutRandomValueSizeBenchmark can be used. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4646) Try to unmarshall direct messages in striped pool
[
https://issues.apache.org/jira/browse/IGNITE-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858305#comment-15858305
]
Igor Seliverstov commented on IGNITE-4646:
--
Made changes after last tests fail, waiting for results
https://github.com/apache/ignite/pull/1499
http://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests_RunCache&branch_IgniteTests=pull%2F1499%2Fhead
> Try to unmarshall direct messages in striped pool
> -
>
> Key: IGNITE-4646
> URL: https://issues.apache.org/jira/browse/IGNITE-4646
> Project: Ignite
> Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.0
>
>
> During marshalling in NIO thread the following should be added to the write
> buffer and sent to peer:
> 1. chunk size - 16 bits (this probably puts limitation on max write buffer
> size of 64k or will require some changes to direct writer)
> 2. last chunk - 1 bit
> 3. pool policy - 8 bits
> Here is the scheme to explain how this should work.
> {noformat}
> [chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more
> space in write buffer
> [next chunk size] [last flag] [chunk data] <<-- we write next chunk once some
> space is available in write buffer, but we skip partition and policy flags
> and maybe others that should be sent only once.
> ...
> ...
> [next chunk size] [last flag] [chunk data] <<-- last flag is true here
> {noformat}
> Examples
> Write buffer - 64k
> Message - 84k
> # sender reserves space for chunk size
> # reserves space for policy and last chunk flag
> # marshalls message to buffer while it has free space (64k - SPACE will be
> written to buffer)
> # puts size and flags to reserved space in the beginning
> # sends buffer or part of it which makes some space available to further
> writes
> # reserves space for next chunk size and flags
> # marshalls message to buffer while it has free space (lets assume the rest
> of message fits)
> # puts size and last=true to the reserved space and sends
> Receiver:
> # reads chunk size, stores the target pool and partition
> # allocates heap buffer and copies chunk data to it from read buffer
> # once all message chunks are fully read message should be submitted to a
> pool where it will be unmarshalled and processed
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858311#comment-15858311 ] Igor Seliverstov commented on IGNITE-4645: -- Almost all tests passed (except unstable ones); Some cosmetic changes remaining > Best effort to avoid extra copying in binary marshaller > --- > > Key: IGNITE-4645 > URL: https://issues.apache.org/jira/browse/IGNITE-4645 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Yakov Zhdanov >Assignee: Igor Seliverstov > Fix For: 1.9 > > > If we marshal a class that contain only primitives then we can predict the > final byte array size and avoid copies to grow array and final trimming. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4003) Slow or faulty client can stall the whole cluster.
[
https://issues.apache.org/jira/browse/IGNITE-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858362#comment-15858362
]
Andrey Gura commented on IGNITE-4003:
-
Fixed failed tests from TCP communication suite. Waiting for TC.
> Slow or faulty client can stall the whole cluster.
> --
>
> Key: IGNITE-4003
> URL: https://issues.apache.org/jira/browse/IGNITE-4003
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.0
>
>
> Steps to reproduce:
> 1) Start two server nodes and some data to cache.
> 2) Start a client from Docker subnet, which is not visible from the outside.
> Client will join the cluster.
> 3) Try to put something to cache or start another node to force rabalance.
> Cluster is stuck at this moment. Root cause - servers are constantly trying
> to establish outgoing connection to the client, but fail as Docker subnet is
> not visible from the outside. It may stop virtually all cluster operations.
> Typical thread dump:
> {code}
> org.apache.ignite.IgniteCheckedException: Failed to send message (node may
> have left the grid or TCP connection cannot be established due to firewall
> issues) [node=TcpDiscoveryNode [id=a15d74c2-1ec2-4349-9640-aeacd70d8714,
> addrs=[127.0.0.1, 172.17.0.6], sockAddrs=[/127.0.0.1:0, /127.0.0.1:0,
> /172.17.0.6:0], discPort=0, order=7241, intOrder=3707,
> lastExchangeTime=1474096941045, loc=false, ver=1.5.23#20160526-sha1:259146da,
> isClient=true], topic=T4 [topic=TOPIC_CACHE,
> id1=949732fd-1360-3a58-8d9e-0ff6ea6182cc,
> id2=a15d74c2-1ec2-4349-9640-aeacd70d8714, id3=2], msg=GridContinuousMessage
> [type=MSG_EVT_NOTIFICATION, routineId=7e13c48e-6933-48b2-9f15-8d92007930db,
> data=null, futId=null], policy=2]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1347)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1227)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1198)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1180)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:841)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:800)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:787)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:343)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:250)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3476)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture$MiniFuture.onResult(GridDhtForceKeysFuture.java:548)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onResult(GridDhtForceKeysFuture.java:207)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.processForceKeyResponse(GridDhtPreloader.java:636)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.ac
[jira] [Commented] (IGNITE-3537) Add tests checking that data structures work inside user transactions
[ https://issues.apache.org/jira/browse/IGNITE-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858385#comment-15858385 ] ASF GitHub Bot commented on IGNITE-3537: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1441 > Add tests checking that data structures work inside user transactions > - > > Key: IGNITE-3537 > URL: https://issues.apache.org/jira/browse/IGNITE-3537 > Project: Ignite > Issue Type: Task > Components: data structures >Reporter: Semen Boikov >Assignee: Vadim Opolski >Priority: Minor > Labels: newbie > Fix For: 1.9 > > > Need create tests to check that Ignite data structures work inside user > transaction. Now data structures should use independent transactions, test > should jus check that there are no exceptions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4617) CPP: Implement Field-access methods for binary objects
[
https://issues.apache.org/jira/browse/IGNITE-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858392#comment-15858392
]
Igor Sapego commented on IGNITE-4617:
-
Checking pending metadata has helped. Now I only need to implement metadata
retrieval for the case when there is no local info about the type. Though this
case I can not test properly yet, as there are no such usecase for
{{BinaryObject}} in C++ yet.
> CPP: Implement Field-access methods for binary objects
> --
>
> Key: IGNITE-4617
> URL: https://issues.apache.org/jira/browse/IGNITE-4617
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: cpp
> Fix For: 1.9
>
>
> Currently we have very limited implementation of binary objects that does not
> provide access to fields of the binary object. At least such methods as
> {{HasField}} and {{GetField}} should be implemented.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4624) ScanQuery shows poor performance.
[ https://issues.apache.org/jira/browse/IGNITE-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-4624: Assignee: Andrew Mashenkov > ScanQuery shows poor performance. > - > > Key: IGNITE-4624 > URL: https://issues.apache.org/jira/browse/IGNITE-4624 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Attachments: > Change_keyIterator_to_entryIterator_for_local_scan_squery.patch, Demo.java > > > I've found that ScanQuery use cache KeySet iterator which make cache > peek\entry calls for getting value. > It is look like we can avoid this calls by using EntrySet iterator for > iterating over local partitions. > Start point is GridCacheQueryManager.onheapIterator(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4624) ScanQuery shows poor performance.
[ https://issues.apache.org/jira/browse/IGNITE-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858497#comment-15858497 ] ASF GitHub Bot commented on IGNITE-4624: GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/1509 IGNITE-4624: ScanQuery shows poor performance. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4624 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1509.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1509 commit 12e231609d3a8e65540374ab3227b746c957e5d2 Author: Andrey V. Mashenkov Date: 2017-01-30T15:29:42Z Fixed > ScanQuery shows poor performance. > - > > Key: IGNITE-4624 > URL: https://issues.apache.org/jira/browse/IGNITE-4624 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Attachments: > Change_keyIterator_to_entryIterator_for_local_scan_squery.patch, Demo.java > > > I've found that ScanQuery use cache KeySet iterator which make cache > peek\entry calls for getting value. > It is look like we can avoid this calls by using EntrySet iterator for > iterating over local partitions. > Start point is GridCacheQueryManager.onheapIterator(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4624) ScanQuery shows poor performance.
[ https://issues.apache.org/jira/browse/IGNITE-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-4624: Assignee: Alexey Goncharuk (was: Andrew Mashenkov) > ScanQuery shows poor performance. > - > > Key: IGNITE-4624 > URL: https://issues.apache.org/jira/browse/IGNITE-4624 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Alexey Goncharuk > Attachments: > Change_keyIterator_to_entryIterator_for_local_scan_squery.patch, Demo.java > > > I've found that ScanQuery use cache KeySet iterator which make cache > peek\entry calls for getting value. > It is look like we can avoid this calls by using EntrySet iterator for > iterating over local partitions. > Start point is GridCacheQueryManager.onheapIterator(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4674) Ignite Web Console: Support DML queries
Denis Magda created IGNITE-4674: --- Summary: Ignite Web Console: Support DML queries Key: IGNITE-4674 URL: https://issues.apache.org/jira/browse/IGNITE-4674 Project: Ignite Issue Type: Task Reporter: Denis Magda Assignee: Alexey Kuznetsov Priority: Critical Fix For: 1.9 Presently it's impossible to execute DML queries from the console. Let's enable this capability in 1.9. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-4527) Renew SQL Queries description on the site with SQL Grid information
[ https://issues.apache.org/jira/browse/IGNITE-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-4527. - Resolution: Fixed Thanks, looks good! > Renew SQL Queries description on the site with SQL Grid information > --- > > Key: IGNITE-4527 > URL: https://issues.apache.org/jira/browse/IGNITE-4527 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 1.9 > > Attachments: diagram_17.png > > > It’s time to update SQL queries use case page [1] to In-Memory SQL Grid one > preparing the content referring to the latest SQL Grid documentation [2]. > In general, the following has to be done: > - rename the page to "SQL Grid" > - enrich the page content by talking about DML and the ability to connect to > the cluster from any programming language if ODBC/JDBC is used. > In addition, we created a new banner for SQL Grid that needs to be added to > the banners carousel. It should be shown as the first one when > ignite.apache.org is opened. The banner is attached to the ticket. > [1] https://ignite.apache.org/features/sql.html > [2] https://apacheignite.readme.io/docs/sql-grid -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (IGNITE-4527) Renew SQL Queries description on the site with SQL Grid information
[ https://issues.apache.org/jira/browse/IGNITE-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-4527. --- > Renew SQL Queries description on the site with SQL Grid information > --- > > Key: IGNITE-4527 > URL: https://issues.apache.org/jira/browse/IGNITE-4527 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 1.9 > > Attachments: diagram_17.png > > > It’s time to update SQL queries use case page [1] to In-Memory SQL Grid one > preparing the content referring to the latest SQL Grid documentation [2]. > In general, the following has to be done: > - rename the page to "SQL Grid" > - enrich the page content by talking about DML and the ability to connect to > the cluster from any programming language if ODBC/JDBC is used. > In addition, we created a new banner for SQL Grid that needs to be added to > the banners carousel. It should be shown as the first one when > ignite.apache.org is opened. The banner is attached to the ticket. > [1] https://ignite.apache.org/features/sql.html > [2] https://apacheignite.readme.io/docs/sql-grid -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4226) Redis SET command should handle expirations
[ https://issues.apache.org/jira/browse/IGNITE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh updated IGNITE-4226: - Fix Version/s: 1.9 > Redis SET command should handle expirations > --- > > Key: IGNITE-4226 > URL: https://issues.apache.org/jira/browse/IGNITE-4226 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 1.8 >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: redis > Fix For: 1.9 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4226) Redis SET command should handle expirations
[ https://issues.apache.org/jira/browse/IGNITE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858895#comment-15858895 ] ASF GitHub Bot commented on IGNITE-4226: GitHub user shroman opened a pull request: https://github.com/apache/ignite/pull/1510 IGNITE-4226: Redis SET command to handle expirations. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shroman/ignite IGNITE-4226 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1510.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1510 commit 4642dbf8b47205cb15901f4a9deb6bc984959261 Author: shtykh_roman Date: 2017-02-09T02:27:31Z IGNITE-4226: Redis SET command to handle expirations. > Redis SET command should handle expirations > --- > > Key: IGNITE-4226 > URL: https://issues.apache.org/jira/browse/IGNITE-4226 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 1.8 >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: redis > Fix For: 1.9 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4226) Redis SET command should handle expirations
[ https://issues.apache.org/jira/browse/IGNITE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh updated IGNITE-4226: - Description: Handling EX and PX parameters of SET command. https://redis.io/commands/set > Redis SET command should handle expirations > --- > > Key: IGNITE-4226 > URL: https://issues.apache.org/jira/browse/IGNITE-4226 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 1.8 >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: redis > Fix For: 1.9 > > > Handling EX and PX parameters of SET command. > https://redis.io/commands/set -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4675) Make client node to fetch configuration from server (i.e. connect only by address:port)
Yakov Zhdanov created IGNITE-4675: - Summary: Make client node to fetch configuration from server (i.e. connect only by address:port) Key: IGNITE-4675 URL: https://issues.apache.org/jira/browse/IGNITE-4675 Project: Ignite Issue Type: Improvement Components: general Reporter: Yakov Zhdanov Fix For: 2.0 Now we need pretty verbose configuration for client to connect to the server topology. What if we add the very first step to our start procedure that will make client to connect to provided server's discovery and fetch the configuration and after that continue with ordinary start. This makes possible for client to connect having only address and port. So, we add Ignition.start(String address, int port); - the simplest overload One of the problem I see - server topology completely changes after client fetches and configuration becomes invalid for current server. In this case we can refetch - just put a loop to the new method. New method should also honor SSL settings, any stuff added by plugins, e.g. security. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4676) Clojure hangs if executed nested internal task with continuation
Alexey Kuznetsov created IGNITE-4676: Summary: Clojure hangs if executed nested internal task with continuation Key: IGNITE-4676 URL: https://issues.apache.org/jira/browse/IGNITE-4676 Project: Ignite Issue Type: Bug Components: compute Affects Versions: 1.8 Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 1.9 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4676) Clojure hangs if executed nested internal task with continuation
[
https://issues.apache.org/jira/browse/IGNITE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-4676:
-
Description:
Initially this bug found in following scenario.
Client send task T1 to node B via node A.
Node A sends closure ExeCallable to node B and add listener to taskFuture.
On node B ExeCallable executed internal task with one job with continuation.
Result of ExeCallable never returned to node A.
The problem isolated in GridJobWorker {{private static final
ThreadLocal HOLD }} variable - does not change its state in valid way
for internal tasks and never call {{finishJob()}} method.
> Clojure hangs if executed nested internal task with continuation
>
>
> Key: IGNITE-4676
> URL: https://issues.apache.org/jira/browse/IGNITE-4676
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 1.8
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>
> Initially this bug found in following scenario.
> Client send task T1 to node B via node A.
> Node A sends closure ExeCallable to node B and add listener to taskFuture.
> On node B ExeCallable executed internal task with one job with continuation.
> Result of ExeCallable never returned to node A.
> The problem isolated in GridJobWorker {{private static final
> ThreadLocal HOLD }} variable - does not change its state in valid
> way for internal tasks and never call {{finishJob()}} method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4676) Clojure hangs if executed nested internal task with continuation
[
https://issues.apache.org/jira/browse/IGNITE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-4676:
-
Description:
Initially this bug found in following scenario.
Client send task T1 to node B via node A.
Node A sends closure ExeCallable to node B and add listener to taskFuture.
On node B ExeCallable executed internal task with one job with continuation.
Result of ExeCallable never returned to node A.
The problem isolated in GridJobWorker
{code}private static final ThreadLocal HOLD{code}
variable does not change its state in valid way for internal tasks and never
call {{finishJob()}} method.
was:
Initially this bug found in following scenario.
Client send task T1 to node B via node A.
Node A sends closure ExeCallable to node B and add listener to taskFuture.
On node B ExeCallable executed internal task with one job with continuation.
Result of ExeCallable never returned to node A.
The problem isolated in GridJobWorker {{private static final
ThreadLocal HOLD }} variable - does not change its state in valid way
for internal tasks and never call {{finishJob()}} method.
> Clojure hangs if executed nested internal task with continuation
>
>
> Key: IGNITE-4676
> URL: https://issues.apache.org/jira/browse/IGNITE-4676
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 1.8
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>
> Initially this bug found in following scenario.
> Client send task T1 to node B via node A.
> Node A sends closure ExeCallable to node B and add listener to taskFuture.
> On node B ExeCallable executed internal task with one job with continuation.
> Result of ExeCallable never returned to node A.
> The problem isolated in GridJobWorker
> {code}private static final ThreadLocal HOLD{code}
> variable does not change its state in valid way for internal tasks and never
> call {{finishJob()}} method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4676) Closure hangs if executed nested internal task with continuation
[
https://issues.apache.org/jira/browse/IGNITE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-4676:
-
Summary: Closure hangs if executed nested internal task with continuation
(was: Clojure hangs if executed nested internal task with continuation)
> Closure hangs if executed nested internal task with continuation
>
>
> Key: IGNITE-4676
> URL: https://issues.apache.org/jira/browse/IGNITE-4676
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 1.8
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>
> Initially this bug found in following scenario.
> Client send task T1 to node B via node A.
> Node A sends closure ExeCallable to node B and add listener to taskFuture.
> On node B ExeCallable executed internal task with one job with continuation.
> Result of ExeCallable never returned to node A.
> The problem isolated in GridJobWorker
> {code}private static final ThreadLocal HOLD{code}
> variable does not change its state in valid way for internal tasks and never
> call {{finishJob()}} method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
