[jira] [Created] (IGNITE-4667) Throw exception on starting client cache when indexed types cannot be loaded
Dmitry Karachentsev created IGNITE-4667: --- Summary: Throw exception on starting client cache when indexed types cannot be loaded Key: IGNITE-4667 URL: https://issues.apache.org/jira/browse/IGNITE-4667 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.8 Reporter: Dmitry Karachentsev Assume following situation: 1. Server node configured cache indexed types with classes that client node doesn't have. 2. Start server. 3. Start client. Client successfully connected. 4. Try to get cache on client node. 5. Was thrown exception in GridQueryProcessor and request for cache on client node hangs forever. If on some reason cache couldn't be initialized, exception must be thrown on Ignite.cache() operation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-3422) No way to control object initialization during deserialization/unmarshalling
[
https://issues.apache.org/jira/browse/IGNITE-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-3422:
---
Component/s: general
> No way to control object initialization during deserialization/unmarshalling
> -
>
> Key: IGNITE-3422
> URL: https://issues.apache.org/jira/browse/IGNITE-3422
> Project: Ignite
> Issue Type: Improvement
> Components: binary, general
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Vyacheslav Daradur
>
> Presently there is no way to control instantiation of a {{BinaryObject}} that
> is being deserialized. The object is created using
> {{BinaryClassDescriptor#newInstance}} all the time.
> It makes sense to add {{BinaryConfiguration.setInitializationFactory()}}
> method that will provide with such support.
> Use case and details are provided in this discussion
> http://apache-ignite-users.70518.x6.nabble.com/Properly-Immutable-Keys-values-with-Binary-objects-tp6082.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-3422) No way to control object initialization during deserialization/unmarshalling
[
https://issues.apache.org/jira/browse/IGNITE-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-3422:
---
Component/s: binary
> No way to control object initialization during deserialization/unmarshalling
> -
>
> Key: IGNITE-3422
> URL: https://issues.apache.org/jira/browse/IGNITE-3422
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Vyacheslav Daradur
>
> Presently there is no way to control instantiation of a {{BinaryObject}} that
> is being deserialized. The object is created using
> {{BinaryClassDescriptor#newInstance}} all the time.
> It makes sense to add {{BinaryConfiguration.setInitializationFactory()}}
> method that will provide with such support.
> Use case and details are provided in this discussion
> http://apache-ignite-users.70518.x6.nabble.com/Properly-Immutable-Keys-values-with-Binary-objects-tp6082.html
--
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=15856819#comment-15856819
]
Vyacheslav Daradur edited comment on IGNITE-4374 at 2/8/17 7:38 AM:
[~dmagda],
What about dot at the end at the existing suggestions?
WIll i add?
{code}
"Disable collision resolution (remove 'collisionSpi' from configuration)"
"Disable checkpoints (remove 'checkpointSpi' from configuration)"
"Disable local jobs marshalling (set 'marshalLocalJobs' to false)"
"Disable grid events (remove 'includeEventTypes' from configuration)"
"Use default binary marshaller (do not set 'marshaller' explicitly)"
{code}
was (Author: daradurvs):
[~dmagda],
What about dots on the end at the existing suggestions?
WIll i add?
{code}
"Disable collision resolution (remove 'collisionSpi' from configuration)"
"Disable checkpoints (remove 'checkpointSpi' from configuration)"
"Disable local jobs marshalling (set 'marshalLocalJobs' to false)"
"Disable grid events (remove 'includeEventTypes' from configuration)"
"Use default binary marshaller (do not set 'marshaller' explicitly)"
{code}
> 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-4666) Web console: Refactor clone dialog service to custom input service
[ https://issues.apache.org/jira/browse/IGNITE-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-4666: - Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) Refactored Clone service to Input. > Web console: Refactor clone dialog service to custom input service > -- > > Key: IGNITE-4666 > URL: https://issues.apache.org/jira/browse/IGNITE-4666 > Project: Ignite > Issue Type: Task >Affects Versions: 1.8 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4665) Make near readers update async by default
[ https://issues.apache.org/jira/browse/IGNITE-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yakov Zhdanov updated IGNITE-4665: -- Description: Currently when we do cache updates in FULL_SYNC mode we update near readers (near cache entries) synchronously. This is quite big drawback in design, I think. I get each near reader update at cost of 1 extra backup update. I think everyone understands that partitioned cache easily turns to replicated once near readers number increases. In TX cache cost of such updates doubles. I do not see any benefit on updating near entries in sync way. Outdated reads can still be possible if I don't read from primary or in TX context. So, what I suggest: 1. introduce CacheWriteSynchronizationMode.DHT_SYNC (leave PRIMARY_SYNC as default). 2. Near entries are updated in async way 2.1 in atomic mode together with backup updates 2.2 in TX mode after tx is committed on primary. I would also suggest to exclude near readers from lock acquisition/release steps. Only force updates. Updates order will be ensured by single primary node and per-partition striping. 3. Near readers do not respond to primary. Once primary fails near readers get invalidated, if primary is alive then communication recovery ensures that message will be delivered to near. Here is the discussion on dev list - http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-0-Make-near-readers-update-async-by-default-tp14133.html was: Currently when we do cache updates in FULL_SYNC mode we update near readers (near cache entries) synchronously. This is quite big drawback in design, I think. I get each near reader update at cost of 1 extra backup update. I think everyone understands that partitioned cache easily turns to replicated once near readers number increases. In TX cache cost of such updates doubles. I do not see any benefit on updating near entries in sync way. Outdated reads can still be possible if I don't read from primary or in TX context. So, what I suggest: 1. introduce CacheWriteSynchronizationMode.DHT_SYNC (leave PRIMARY_SYNC as default). 2. Near entries are updated in async way 2.1 in atomic mode together with backup updates 2.2 in TX mode after tx is committed on primary. I would also suggest to exclude near readers from lock acquisition/release steps. Only force updates. Updates order will be ensured by single primary node and per-partition striping. 3. Near readers do not respond to primary. Once primary fails near readers get invalidated, if primary is alive then communication recovery ensures that message will be delivered to near. > Make near readers update async by default > - > > Key: IGNITE-4665 > URL: https://issues.apache.org/jira/browse/IGNITE-4665 > Project: Ignite > Issue Type: Improvement >Reporter: Yakov Zhdanov >Priority: Minor > Fix For: 2.0 > > > Currently when we do cache updates in FULL_SYNC mode we update near readers > (near cache entries) synchronously. This is quite big drawback in design, I > think. I get each near reader update at cost of 1 extra backup update. I > think everyone understands that partitioned cache easily turns to replicated > once near readers number increases. In TX cache cost of such updates doubles. > I do not see any benefit on updating near entries in sync way. Outdated reads > can still be possible if I don't read from primary or in TX context. > So, what I suggest: > 1. introduce CacheWriteSynchronizationMode.DHT_SYNC (leave PRIMARY_SYNC as > default). > 2. Near entries are updated in async way > 2.1 in atomic mode together with backup updates > 2.2 in TX mode after tx is committed on primary. I would also suggest to > exclude near readers from lock acquisition/release steps. Only force updates. > Updates order will be ensured by single primary node and per-partition > striping. > 3. Near readers do not respond to primary. Once primary fails near readers > get invalidated, if primary is alive then communication recovery ensures that > message will be delivered to near. > Here is the discussion on dev list - > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-0-Make-near-readers-update-async-by-default-tp14133.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4666) Web console: Refactor clone dialog service to custom input service
Vasiliy Sisko created IGNITE-4666: - Summary: Web console: Refactor clone dialog service to custom input service Key: IGNITE-4666 URL: https://issues.apache.org/jira/browse/IGNITE-4666 Project: Ignite Issue Type: Task Affects Versions: 1.8 Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4665) Make near readers update async by default
Yakov Zhdanov created IGNITE-4665: - Summary: Make near readers update async by default Key: IGNITE-4665 URL: https://issues.apache.org/jira/browse/IGNITE-4665 Project: Ignite Issue Type: Improvement Reporter: Yakov Zhdanov Priority: Minor Fix For: 2.0 Currently when we do cache updates in FULL_SYNC mode we update near readers (near cache entries) synchronously. This is quite big drawback in design, I think. I get each near reader update at cost of 1 extra backup update. I think everyone understands that partitioned cache easily turns to replicated once near readers number increases. In TX cache cost of such updates doubles. I do not see any benefit on updating near entries in sync way. Outdated reads can still be possible if I don't read from primary or in TX context. So, what I suggest: 1. introduce CacheWriteSynchronizationMode.DHT_SYNC (leave PRIMARY_SYNC as default). 2. Near entries are updated in async way 2.1 in atomic mode together with backup updates 2.2 in TX mode after tx is committed on primary. I would also suggest to exclude near readers from lock acquisition/release steps. Only force updates. Updates order will be ensured by single primary node and per-partition striping. 3. Near readers do not respond to primary. Once primary fails near readers get invalidated, if primary is alive then communication recovery ensures that message will be delivered to near. -- 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=15857050#comment-15857050
]
Denis Magda commented on IGNITE-4619:
-
[~ptupitsyn],
Here is a couple of comments from my side.
1. Referring to this code
{code}
// When Ignite tx is started manually, it won't be enlisted in TransactionScope.
cache[1] = 0;
using (var tx = transactions.TxStart())
{
using (new TransactionScope())
{
cache[1] = 2;
} // Revert transaction scope: does not affect Ignite tx.
tx.Commit(); // Commit manual tx.
}
cache.Get(1); // returns 2.
{code}
Did you want to say that the value {{cache[1] = 2;}} will be assigned before
the transaction is committed with {{ tx.Commit();}}? Does it mean that
{{cache[1] = 2;}} assignment happens all the time even if you don't call
{{TransactionScope.complete()}}?
2. How do we technically support TransactionScopeOption.Suppress for nested
transactions? I thought that as soon as you start one Ignite transaction using
TransactionScope or Ignite APIs there is no way to put values out of existing
transaction context unless update the cache from a separate Thread.
3. What will be the default transaction isolation level and concurrency mode if
a transaction scope is created with {{new TransactionScope()}} constructor?
Please document this.
4. How can I change the concurrency mode (pessimistic & optimistic)? Please
document this.
The example looks good to me!
> .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] [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 ] Denis Magda updated IGNITE-4374: Comment: was deleted (was: Yes, let's add them there as well.) > 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-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=15856938#comment-15856938 ] Denis Magda commented on IGNITE-4374: - Yes, let's add them there as well. > 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] [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=15856819#comment-15856819
]
Vyacheslav Daradur edited comment on IGNITE-4374 at 2/7/17 9:27 PM:
[~dmagda],
What about dots on the end at the existing suggestions?
WIll i add?
{code}
"Disable collision resolution (remove 'collisionSpi' from configuration)"
"Disable checkpoints (remove 'checkpointSpi' from configuration)"
"Disable local jobs marshalling (set 'marshalLocalJobs' to false)"
"Disable grid events (remove 'includeEventTypes' from configuration)"
"Use default binary marshaller (do not set 'marshaller' explicitly)"
{code}
was (Author: daradurvs):
[~dmagda],
How about dots on the end at the existing suggestions?
WIll i add?
{code}
"Disable collision resolution (remove 'collisionSpi' from configuration)"
"Disable checkpoints (remove 'checkpointSpi' from configuration)"
"Disable local jobs marshalling (set 'marshalLocalJobs' to false)"
"Disable grid events (remove 'includeEventTypes' from configuration)"
"Use default binary marshaller (do not set 'marshaller' explicitly)"
{code}
> 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-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=15856819#comment-15856819
]
Vyacheslav Daradur commented on IGNITE-4374:
[~dmagda],
How about dots on the end at the existing suggestions?
WIll i add?
{code}
"Disable collision resolution (remove 'collisionSpi' from configuration)"
"Disable checkpoints (remove 'checkpointSpi' from configuration)"
"Disable local jobs marshalling (set 'marshalLocalJobs' to false)"
"Disable grid events (remove 'includeEventTypes' from configuration)"
"Use default binary marshaller (do not set 'marshaller' explicitly)"
{code}
> 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-3422) No way to control object initialization during deserialization/unmarshalling
[
https://issues.apache.org/jira/browse/IGNITE-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur reassigned IGNITE-3422:
--
Assignee: Vyacheslav Daradur
> No way to control object initialization during deserialization/unmarshalling
> -
>
> Key: IGNITE-3422
> URL: https://issues.apache.org/jira/browse/IGNITE-3422
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Vyacheslav Daradur
>
> Presently there is no way to control instantiation of a {{BinaryObject}} that
> is being deserialized. The object is created using
> {{BinaryClassDescriptor#newInstance}} all the time.
> It makes sense to add {{BinaryConfiguration.setInitializationFactory()}}
> method that will provide with such support.
> Use case and details are provided in this discussion
> http://apache-ignite-users.70518.x6.nabble.com/Properly-Immutable-Keys-values-with-Binary-objects-tp6082.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions
[ https://issues.apache.org/jira/browse/IGNITE-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856711#comment-15856711 ] Andrew Mashenkov commented on IGNITE-4106: -- [~sergi.vladykin], I've done. Would you please review a PR? > SQL: parallelize sql queries over cache local partitions > > > Key: IGNITE-4106 > URL: https://issues.apache.org/jira/browse/IGNITE-4106 > Project: Ignite > Issue Type: Improvement > Components: SQL >Affects Versions: 1.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Labels: performance > Fix For: 1.9 > > Attachments: 1node-4thread.jfr, 4node-1thread.jfr > > > If we run SQL query on cache partitioned over several cluster nodes, it will > be split into several queries running in parallel. But really we will have > one thread per query on each node. > So, for now, to improve SQL query performance we need to run more Ignite > instances or split caches manually. > It seems to be better to split local SQL queries over cache partitions, so we > would be able to parallelize SQL query on every single node and utilize CPU > more efficiently. -- 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=15856619#comment-15856619
]
Andrey Gura commented on IGNITE-4003:
-
Merged master branch to my changes. Most tests are fixed but still there are a
few issues related with paired connections. Fix in progress.
> 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
>
[jira] [Commented] (IGNITE-4633) Initiate DDL operation through custom discovery message
[
https://issues.apache.org/jira/browse/IGNITE-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856617#comment-15856617
]
Alexander Paschenko commented on IGNITE-4633:
-
Skeleton is done, but have to debug what's been implemented (make sure that all
ring/comm messages pass right) and make few fixes architecture wise; ETA is
tomorrow
> Initiate DDL operation through custom discovery message
> ---
>
> Key: IGNITE-4633
> URL: https://issues.apache.org/jira/browse/IGNITE-4633
> Project: Ignite
> Issue Type: Sub-task
> Components: SQL
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Design considerations:
> 1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}}
> messages - which will hold concrete DDL commands.
> 2) Originator must generate unique message ID to be able to track it later.
> 3) Coordinator calculates all participants through affinity API and adds them
> to message.
> 4) {{INIT}} message goes through the ring and:performs some fast preliminary
> checks if necessary and collects error; in particular it may verify whether
> schema change is valid to allow for fail-fast client notification.;
> 5) If at least one error occurs during {{INIT}} stage, originator may throw
> exception to the user.
> 6) {{ACK}} message schedules asynchronous execution of the command.
--
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=15856561#comment-15856561
]
Denis Magda commented on IGNITE-4374:
-
[~daradurvs]
Please address these notes:
* Add dot (.) to the end of every sentence.
* Rephrase this sentence {{Enable the thread-local allocation blocks (add
'-XX:+UseTLAB' to JVM options).}}
* The OS suggestions below need to be clarified in a similar form you did for
JVM ones:
{{Speed up flushing of dirty pages by OS (alter vm.dirty_writeback_centisecs
and vm.dirty_expire_centisecs paramteres by setting to 500).}}
{{Reduce pages swapping ratio (set vm.swappiness=10).}}
{{Adjust NUMA zones reclamation setting (set vm.zone_reclaim_mode=0).}}
{{Avoid direct reclaim and page allocation failures (set vm.extra_free_kbytes
to 124 or other value).}}
> 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-4664) Add lifecycle and injection support for TopologyValidator
[ https://issues.apache.org/jira/browse/IGNITE-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856545#comment-15856545 ] Alexei Scherbakov commented on IGNITE-4664: --- Implemented. Working on advanced test for buffed up TopologyValidator > Add lifecycle and injection support for TopologyValidator > - > > Key: IGNITE-4664 > URL: https://issues.apache.org/jira/browse/IGNITE-4664 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.6 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov > Fix For: 1.9 > > > It's might be useful to have TopologyValidator be aware of lifecycle and > provide resource injection support. > This'll help to implement more complex validation logic. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4212) Ignite Benchmarking Simplification and Automation
[ https://issues.apache.org/jira/browse/IGNITE-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856401#comment-15856401 ] Oleg Ostanin commented on IGNITE-4212: -- [~dmagda] You need to configure ssh key-based authentication to localhost because Yardstick works this way - scripts run another scripts by ssh commands. There is a patch available to fix it. > 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: 2.0 > > 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] [Commented] (IGNITE-4035) SQL: Avoid excessive calls of deterministic functions on same arguments
[
https://issues.apache.org/jira/browse/IGNITE-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856353#comment-15856353
]
Sergey Kalashnikov commented on IGNITE-4035:
To my mind, the best way of addressing this is to introduce the optimization
into H2 itself.
As for Ignite:
1) We can optimize it by replacing specific nodes (subtrees actually) in the
expression tree
of H2 prepared sql statement with references to equivalent nodes that we have
already visited and cached.
But currently the prepared statement tree is only traversed during query split
to form map/reduce queries.
In case of local queries, introducing expression tree traversal seems too much
of overhead for the sake of single optimization.
In case of two step query, the optimized expression tree will be transformed
back to sql text in order to be sent
to server node for execution and this will effectively erase the aforementioned
optimization.
2) Alternatively, we can consider transforming the initial query by adding
subquery as follows:
From:
SELECT AVG(datediff('s',ts1,ts2)), MIN(datediff('s',ts1,ts2)),
MAX(datediff('s',ts1,ts2)) FROM TABLE
To:
SELECT AVG(Y), MIN(Y), MAX(Y) FROM (SELECT DATEDIFF('s', ts1, ts2) AS Y FROM
TABLE)
This seems feasible for the case of TwoStepQuery since tree traversal is
already there.
Still such logic seems heavier than theoretical fix in H2.
> SQL: Avoid excessive calls of deterministic functions on same arguments
> ---
>
> Key: IGNITE-4035
> URL: https://issues.apache.org/jira/browse/IGNITE-4035
> Project: Ignite
> Issue Type: Task
> Components: SQL
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Sergey Kalashnikov
> Labels: performance
> Fix For: 2.0
>
>
> In sql query example below, heavy "datediff" deterministic function will be
> called 4 times per row. I'd expected function was called once per row.
> Example:
> {noformat}
> Select
> avg(datediff('s',ts1,ts2)) as avg_diff,
> min(datediff('s',ts1,ts2)) as min_diff,
> max(datediff('s',ts1,ts2)) as max_diff
> From table
> {noformat}
--
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=15856349#comment-15856349
]
Igor Sapego commented on IGNITE-4617:
-
There is an issue I'm currently working on. Let's say we are putting value of
some type in cache for the first time. In this case we do not yet have it's
metadata stored, but we already provide user a {{BinaryObject}} instance of
the type to calculate hash code if he provides custom
{{BinaryIdentityResolver}} implementation. So if user tries to get internal
fields as a {{BinaryObject}} they'd got an exception.
Currently I'm going to check metadata which is pending for update. For now it
seems to me like this is going to fix an issue.
> 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] [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=15856275#comment-15856275
]
Pavel Tupitsyn commented on IGNITE-4425:
[~GuruStron], looks good to me in general. Some minor things:
* {{ParameterExpression is not supported for 'Contains' clauses.}} - as I
understand, this happens only when {{Contains}} argument comes from
{{CompiledQuery}} delegate parameter. So we can be more descriptive by saying
something like {{'Contains' clause coming from compiled query parameter is not
supported.}}
* Let's extract Contains handling from {{VisitSubQuery}} to a separate method
* {{subQueryModel.ResultOperators.First()}} is called twice and cast to
{{ContainsResultOperator}}
* {{GetInvalues}} can be made static
* We can pass {{inValues}} to {{AppendInParameters}} directly and filter for
nulls right there. Also, enumerable null check seems to be redundant there.
* Unused imports in {{CacheQueryExpressionVisitor}}
> .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] [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=15856239#comment-15856239 ] Sergey Chugunov commented on IGNITE-4302: - Added documentation, prepared code changes to be published to world. > 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] [Assigned] (IGNITE-1178) NPE in GridCacheProcessor.onKernalStop()
[
https://issues.apache.org/jira/browse/IGNITE-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-1178:
Assignee: Alexey Kuznetsov
> NPE in GridCacheProcessor.onKernalStop()
>
>
> Key: IGNITE-1178
> URL: https://issues.apache.org/jira/browse/IGNITE-1178
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> If user start node with incorrectly configured cache type metadata for
> JdbcPojoStore NPE is raised in onKernalStop. See attached stacktrace:
> {code}
> org.apache.ignite.IgniteCheckedException: Failed to initialize property
> 'exceptionOid' for key class 'class
> org.apache.ignite.examples.algofusion.ExceptionMasterKey' and value class
> 'class org.apache.ignite.examples.algofusion.ExceptionMaster'. Make sure
> that one of these classes contains respective getter method or field.
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.buildClassProperty(GridQueryProcessor.java:1342)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.processClassMeta(GridQueryProcessor.java:1148)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.initializeCache(GridQueryProcessor.java:149)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:249)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:922)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:779)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:829)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1538)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1405)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:931)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at org.apache.ignite.examples.algofusion.AlgoDB.main(AlgoDB.java:89)
> [15:45:29,007][ERROR][main][IgniteKernal] Failed to pre-stop processor:
> GridProcessorAdapter []
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.GridCacheEventManager.isRecordable(GridCacheEventManager.java:342)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1089)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:896)
> at
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:1706)
> at
> org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1650)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:852)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1538)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1405)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:931)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at org.apache.ignite.examples.algofusion.AlgoDB.main(AlgoDB.java:89)
> [15:45:29] Ignite node stopped wih ERRORS [uptime=00:00:02:515]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (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
]
Pavel Tupitsyn reopened IGNITE-4363:
Looks like .NET tests are broken by this commit:
http://ci.ignite.apache.org/viewLog.html?buildId=442967
[~al.psc] can you please have a look?
Also, I do not see a pull request here, can you please link it to the ticket?
> 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: 1.9
>
>
> 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] [Updated] (IGNITE-2110) Replace workarond for local node flag in TcpDiscoveryNode with better solution
[
https://issues.apache.org/jira/browse/IGNITE-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-2110:
-
Description:
We should get rid of this workaround in
GridDhtAffinityAssignmentResponse#finishUnmarshal
{code:java}
// TODO IGNITE-10: setting 'local' for nodes not needed when
IGNITE-10 is implemented.
int assignments = affAssignment.size();
for (int n = 0; n < assignments; n++) {
List nodes = affAssignment.get(n);
int size = nodes.size();
for (int i = 0; i < size; i++) {
ClusterNode node = nodes.get(i);
if (node instanceof TcpDiscoveryNode)
((TcpDiscoveryNode)node).local(node.id().equals(ctx.localNodeId()));
}
}
{code}
by designing new solution for TcpDiscoveryNode.local transient flag
was:
We should get read of this workaround in
GridDhtAffinityAssignmentResponse#finishUnmarshal
{code:java}
// TODO IGNITE-10: setting 'local' for nodes not needed when
IGNITE-10 is implemented.
int assignments = affAssignment.size();
for (int n = 0; n < assignments; n++) {
List nodes = affAssignment.get(n);
int size = nodes.size();
for (int i = 0; i < size; i++) {
ClusterNode node = nodes.get(i);
if (node instanceof TcpDiscoveryNode)
((TcpDiscoveryNode)node).local(node.id().equals(ctx.localNodeId()));
}
}
{code}
by designing new solution for TcpDiscoveryNode.local transient flag
> Replace workarond for local node flag in TcpDiscoveryNode with better solution
> --
>
> Key: IGNITE-2110
> URL: https://issues.apache.org/jira/browse/IGNITE-2110
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ershov
>Priority: Minor
> Fix For: 2.0
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> We should get rid of this workaround in
> GridDhtAffinityAssignmentResponse#finishUnmarshal
> {code:java}
> // TODO IGNITE-10: setting 'local' for nodes not needed when
> IGNITE-10 is implemented.
> int assignments = affAssignment.size();
> for (int n = 0; n < assignments; n++) {
> List nodes = affAssignment.get(n);
> int size = nodes.size();
> for (int i = 0; i < size; i++) {
> ClusterNode node = nodes.get(i);
> if (node instanceof TcpDiscoveryNode)
>
> ((TcpDiscoveryNode)node).local(node.id().equals(ctx.localNodeId()));
> }
> }
> {code}
> by designing new solution for TcpDiscoveryNode.local transient flag
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Kozlov updated IGNITE-2422:
--
Component/s: binary
> Unable to deserialize BinaryObjectBuilder
> -
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
> Labels: important
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead
> to the errors at deserialization stage.
> After a brief investigation I see that this happens because neither
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}
> presents in {{META-INF/classnames.properties}} file.
> If you try to update
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by
> building the project from scratch and copying-pasting generated content from
> built {{classnames.properties}}, then you will still see that there are still
> no entries for {{org.apache.ignite.binary.BinaryObjectBuilder}} nor
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes
> by some reason.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-4664) Add lifecycle and injection support for TopologyValidator
Alexei Scherbakov created IGNITE-4664: - Summary: Add lifecycle and injection support for TopologyValidator Key: IGNITE-4664 URL: https://issues.apache.org/jira/browse/IGNITE-4664 Project: Ignite Issue Type: Improvement Affects Versions: 1.6 Reporter: Alexei Scherbakov Assignee: Alexei Scherbakov Fix For: 1.9 It's might be useful to have TopologyValidator be aware of lifecycle and provide resource injection support. This'll help to implement more complex validation logic. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4637) Implement DDL operation completion protocol
[
https://issues.apache.org/jira/browse/IGNITE-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko updated IGNITE-4637:
Description:
*Normal flow*
1) When participating node completed operation, it sends
{{PARTICIPANT_FINISHED}} message to coordinator.
2) When coordinator collected responses from all participants, it notifies
originator with {{FINISHED}} request.
3) Originator responds coordinator with {{FINISHED_ACK}} message.
4) Coordinator responds to all peers with {{PARTICIPANT_FINISHED_ACK}} message.
*Originator leave*
1) Coordinator marks originator as "notified", and sends
{{PARTICIPANT_FINISHED_ACK}} message to participants after all
{{PARTICIPANT_FINISHED}} are collected.
*Participant leave*
1) Coordinator marks participant as "finished" and no longer waits for any
responses from it.
*Coordinator leave*
1) The oldest node among remaining participants is elected as new coordinator.
2) Coordinator *polls* explicitly operation state from participants with
{{IS_PARTICIPANT_FINISHED}} message.
3) Participants re-send {{PARTICIPANT_FINISHED}} message to new coordinator.
4) If all participant nodes have left, originator feature is completed with
error.
was:
*Normal flow*
1) When participating node completed operation, it sends
{{PARTICIPANT_FINISHED}} message to coordinator.
2) When coordinator collected responses from all participants, it notifies
originator with {{FINISHED}} request.
3) Originator responds coordinator with {{FINISHED_ACK}} message.
4) Coordinator responds to all originators with {{PARTICIPANT_FINISHED_ACK}}
message.
*Originator leave*
1) Coordinator marks originator as "notified", and sends
{{PARTICIPANT_FINISHED_ACK}} message to participants after all
{{PARTICIPANT_FINISHED}} are collected.
*Participant leave*
1) Coordinator marks participant as "finished" and no longer waits for any
responses from it.
*Coordinator leave*
1) The oldest node among remaining participants is elected as new coordinator.
2) Coordinator *polls* explicitly operation state from participants with
{{IS_PARTICIPANT_FINISHED}} message.
3) Participants re-send {{PARTICIPANT_FINISHED}} message to new coordinator.
4) If all participant nodes have left, originator feature is completed with
error.
> Implement DDL operation completion protocol
> ---
>
> Key: IGNITE-4637
> URL: https://issues.apache.org/jira/browse/IGNITE-4637
> Project: Ignite
> Issue Type: Sub-task
> Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> *Normal flow*
> 1) When participating node completed operation, it sends
> {{PARTICIPANT_FINISHED}} message to coordinator.
> 2) When coordinator collected responses from all participants, it notifies
> originator with {{FINISHED}} request.
> 3) Originator responds coordinator with {{FINISHED_ACK}} message.
> 4) Coordinator responds to all peers with {{PARTICIPANT_FINISHED_ACK}}
> message.
> *Originator leave*
> 1) Coordinator marks originator as "notified", and sends
> {{PARTICIPANT_FINISHED_ACK}} message to participants after all
> {{PARTICIPANT_FINISHED}} are collected.
> *Participant leave*
> 1) Coordinator marks participant as "finished" and no longer waits for any
> responses from it.
> *Coordinator leave*
> 1) The oldest node among remaining participants is elected as new coordinator.
> 2) Coordinator *polls* explicitly operation state from participants with
> {{IS_PARTICIPANT_FINISHED}} message.
> 3) Participants re-send {{PARTICIPANT_FINISHED}} message to new coordinator.
> 4) If all participant nodes have left, originator feature is completed with
> error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (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 updated IGNITE-4492: - Component/s: compute > 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] [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
]
Vladimir Ozerov updated IGNITE-4663:
Priority: Major (was: Critical)
> 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] [Assigned] (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
]
Vladimir Ozerov reassigned IGNITE-4663:
---
Assignee: Taras Ledkov
> 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
>Priority: Critical
> 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-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=15855780#comment-15855780 ] Pavel Tupitsyn commented on IGNITE-2703: All done, fixing minor failures in existing tests due to changed behavior. Uncovered an issue: IGNITE-4663, we are blocked here. > .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] [Created] (IGNITE-4663) BinaryUtils.doReadObjectArray can not read array with platform-only element type
Pavel Tupitsyn created IGNITE-4663:
--
Summary: 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
Priority: Critical
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] [Created] (IGNITE-4662) Server stores cache data on-heap if client has near cache
Semen Boikov created IGNITE-4662: Summary: Server stores cache data on-heap if client has near cache Key: IGNITE-4662 URL: https://issues.apache.org/jira/browse/IGNITE-4662 Project: Ignite Issue Type: Task Components: cache Reporter: Semen Boikov Fix For: 2.0 Currenlty if client has near cache then server does not move data from onheap to offheap (this is needed since information about near cache nodes - 'readers' - is stored only in on-heap entry). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4661) Optimizations: optimize PagesList.removeDataPage
[ https://issues.apache.org/jira/browse/IGNITE-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-4661: Assignee: Igor Seliverstov > 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] [Created] (IGNITE-4661) Optimizations: optimize PagesList.removeDataPage
Semen Boikov created IGNITE-4661: Summary: 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 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] [Created] (IGNITE-4660) Add DML capabilities to legacy JDBC driver
Alexander Paschenko created IGNITE-4660: --- Summary: Add DML capabilities to legacy JDBC driver Key: IGNITE-4660 URL: https://issues.apache.org/jira/browse/IGNITE-4660 Project: Ignite Issue Type: Improvement Components: jdbc-driver, SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.0 Legacy Ignite JDBC driver lacks DML capabilities, but it turns out that there still are plenty of its users who need DML too, so we should de-deprecate it and enable updating operations in it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
