[jira] [Resolved] (IGNITE-2910) VisorNodeDataCollectorTask should collect info about offheap and swap keys per partitions
[ https://issues.apache.org/jira/browse/IGNITE-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-2910. -- Resolution: Fixed > VisorNodeDataCollectorTask should collect info about offheap and swap keys > per partitions > - > > Key: IGNITE-2910 > URL: https://issues.apache.org/jira/browse/IGNITE-2910 > Project: Ignite > Issue Type: Task > Components: visor >Affects Versions: 1.5.0.final >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > > For now only keys in heap is collected, but offheap and swap also should be > handled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2910) VisorNodeDataCollectorTask should collect info about offheap and swap keys per partitions
[ https://issues.apache.org/jira/browse/IGNITE-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-2910. Assignee: (was: Alexey Kuznetsov) Added. Merged to master. > VisorNodeDataCollectorTask should collect info about offheap and swap keys > per partitions > - > > Key: IGNITE-2910 > URL: https://issues.apache.org/jira/browse/IGNITE-2910 > Project: Ignite > Issue Type: Task > Components: visor >Affects Versions: 1.5.0.final >Reporter: Alexey Kuznetsov > Fix For: 1.6 > > > For now only keys in heap is collected, but offheap and swap also should be > handled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2910) VisorNodeDataCollectorTask should collect info about offheap and swap keys per partitions
Alexey Kuznetsov created IGNITE-2910: Summary: VisorNodeDataCollectorTask should collect info about offheap and swap keys per partitions Key: IGNITE-2910 URL: https://issues.apache.org/jira/browse/IGNITE-2910 Project: Ignite Issue Type: Task Components: visor Affects Versions: 1.5.0.final Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 1.6 For now only keys in heap is collected, but offheap and swap also should be handled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (IGNITE-2730) Ignite Events Source Streaming to Kafka
[
https://issues.apache.org/jira/browse/IGNITE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shtykh updated IGNITE-2730:
-
Comment: was deleted
(was: Denis, it's a valid concern, however we have _if (cacheName != null)_
check at the top of _start(...)_ not to create configurations again and again
for tasks because they are the same. And if an IgnitePredicate filter is not
_static_, it won't be initialized for multiple tasks. Also it (and the queue)
is used now with {{TaskRemoteFilter}} which is static too. Removing _static_
from {{TaskRemoteFilter}} will have the same effect I mentioned for the filter.
I think we have to leave it as it, or remove _if (cacheName != null)_ check and
share nothing but {{IgniteGrid}} singleton.
What do you think?)
> Ignite Events Source Streaming to Kafka
> ---
>
> Key: IGNITE-2730
> URL: https://issues.apache.org/jira/browse/IGNITE-2730
> Project: Ignite
> Issue Type: New Feature
> Components: streaming
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Labels: community
>
> Streaming specified Ignite events
> (https://apacheignite.readme.io/docs/events) to Kafka via Kafka Connect.
> It has to be added to org.apache.ignite.stream.kafka.connect package.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2730) Ignite Events Source Streaming to Kafka
[
https://issues.apache.org/jira/browse/IGNITE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217489#comment-15217489
]
Roman Shtykh commented on IGNITE-2730:
--
Denis, it's a valid concern, however we have _if (cacheName != null)_ check at
the top of _start(...)_ not to create configurations again and again for tasks
because they are the same. And if an IgnitePredicate filter is not _static_, it
won't be initialized for multiple tasks. Also it (and the queue) is used now
with {{TaskRemoteFilter}} which is static too. Removing _static_ from
{{TaskRemoteFilter}} will have the same effect I mentioned for the filter.
I think we have to leave it as it, or remove _if (cacheName != null)_ check and
share nothing but {{IgniteGrid}} singleton.
What do you think?
> Ignite Events Source Streaming to Kafka
> ---
>
> Key: IGNITE-2730
> URL: https://issues.apache.org/jira/browse/IGNITE-2730
> Project: Ignite
> Issue Type: New Feature
> Components: streaming
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Labels: community
>
> Streaming specified Ignite events
> (https://apacheignite.readme.io/docs/events) to Kafka via Kafka Connect.
> It has to be added to org.apache.ignite.stream.kafka.connect package.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2730) Ignite Events Source Streaming to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217356#comment-15217356 ] Denis Magda commented on IGNITE-2730: - Roman, thanks. I've left a couple of notes for "static" keyword usage. Sorry, didn't mention it before. > Ignite Events Source Streaming to Kafka > --- > > Key: IGNITE-2730 > URL: https://issues.apache.org/jira/browse/IGNITE-2730 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: community > > Streaming specified Ignite events > (https://apacheignite.readme.io/docs/events) to Kafka via Kafka Connect. > It has to be added to org.apache.ignite.stream.kafka.connect package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2730) Ignite Events Source Streaming to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217349#comment-15217349 ] Roman Shtykh commented on IGNITE-2730: -- Denis, Thank you again. I addressed the issues. Please see PR. > Ignite Events Source Streaming to Kafka > --- > > Key: IGNITE-2730 > URL: https://issues.apache.org/jira/browse/IGNITE-2730 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: community > > Streaming specified Ignite events > (https://apacheignite.readme.io/docs/events) to Kafka via Kafka Connect. > It has to be added to org.apache.ignite.stream.kafka.connect package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2909) Checking cache object type in runtime
[
https://issues.apache.org/jira/browse/IGNITE-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2909:
Labels: community important (was: )
> Checking cache object type in runtime
> -
>
> Key: IGNITE-2909
> URL: https://issues.apache.org/jira/browse/IGNITE-2909
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
>
> In some cases there is necessity to control a type of object that is being
> inserted into a cache.
> Presently this kind of check is accomplished at compile time only relying
> on Java Generics. However it doesn't prevent us from connecting to a
> cluster using a non-generic instance of a cache and put any kind of data in
> it. This may be not a harmful intention but rather a silly developer mistake.
> The following solutions is proposed:
> - if {{MutableConfiguration.setTypes(Class
> keyType, Class valueType)}} are defined and not equal to Object.class then
> on every cache modification operation (put, invoke, etc.) type of a key and
> value has to be checked before being inserted;
> - to support BinaryObjects we should introduce an additional method
> {{CacheConfiguration.setTypeNams(String keyType, String valueType)}} which
> will force checking of a key and value types the same way as above.
> Refer to the discussion on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Controlling-type-of-object-inserted-in-IgniteCache-td8128.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2909) Checking cache object type in runtime
Denis Magda created IGNITE-2909:
---
Summary: Checking cache object type in runtime
Key: IGNITE-2909
URL: https://issues.apache.org/jira/browse/IGNITE-2909
Project: Ignite
Issue Type: Improvement
Components: cache
Affects Versions: 1.5.0.final
Reporter: Denis Magda
Priority: Critical
Fix For: 1.6
In some cases there is necessity to control a type of object that is being
inserted into a cache.
Presently this kind of check is accomplished at compile time only relying
on Java Generics. However it doesn't prevent us from connecting to a
cluster using a non-generic instance of a cache and put any kind of data in
it. This may be not a harmful intention but rather a silly developer mistake.
The following solutions is proposed:
- if {{MutableConfiguration.setTypes(Class
keyType, Class valueType)}} are defined and not equal to Object.class then
on every cache modification operation (put, invoke, etc.) type of a key and
value has to be checked before being inserted;
- to support BinaryObjects we should introduce an additional method
{{CacheConfiguration.setTypeNams(String keyType, String valueType)}} which will
force checking of a key and value types the same way as above.
Refer to the discussion on the dev list:
http://apache-ignite-developers.2346864.n4.nabble.com/Controlling-type-of-object-inserted-in-IgniteCache-td8128.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2730) Ignite Events Source Streaming to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217325#comment-15217325 ] Denis Magda commented on IGNITE-2730: - Roman, 1. Done. Left a couple of more comments in the pull-request. 2. Got the idea. Ok, keep using JdkMarshaller then. > Ignite Events Source Streaming to Kafka > --- > > Key: IGNITE-2730 > URL: https://issues.apache.org/jira/browse/IGNITE-2730 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: community > > Streaming specified Ignite events > (https://apacheignite.readme.io/docs/events) to Kafka via Kafka Connect. > It has to be added to org.apache.ignite.stream.kafka.connect package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2854) Need to implement deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217090#comment-15217090
]
Andrey Gura edited comment on IGNITE-2854 at 3/30/16 12:15 AM:
---
At this moment search of the first deadlock (cycle in wait-for-graph)
implemented as {{DeadlockDetection}} class that used by {{IgniteTxManager}}.
Messaging implemented via {{GridIoManager}} and new {{TOPIC_TX}} topic. If
deadlock detected then detector prints out transaction IDs that involved into
deadlock and keys that cause of deadlock.
Need to extend current algorithm for finding all possible deadlocks for active
near transactions on current node. At the same time detection have to request
from remote nodes only transactions that contain the same keys as transactions
on the local node. It allows to reduce network traffic but increases possible
requests in cases when deadlock wasn't detected.
Also need to find out better way for reporting found deadlocks.
was (Author: agura):
At this moment search of the first deadlock (cycle in wait-for-graph)
implemented as `DeadlockDetection` class that used by `IgniteTxManager`.
Messaging implemented via `GridIoManager` and new `TOPIC_TX` topic. If deadlock
detected then detector prints out transaction IDs that involved into deadlock
and keys that cause of deadlock.
Need to extend current algorithm for finding all possible deadlocks for active
near transactions on current node. At the same time detection have to request
from remote nodes only transactions that contain the same keys as transactions
on the local node. It allows to reduce network traffic but increases possible
requests in cases when deadlock wasn't detected.
Also need to find out better way for reporting found deadlocks.
> Need to implement deadlock detection
>
>
> Key: IGNITE-2854
> URL: https://issues.apache.org/jira/browse/IGNITE-2854
> Project: Ignite
> Issue Type: New Feature
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Andrey Gura
> Fix For: 1.6
>
>
> Currently, if transactional deadlock occurred, there is no easy way to find
> out which locks were reordered.
> We need to add a mechanism that will collect information about awating
> candidates, analyze it and show guilty keys. Most likely this should be
> implemented with the help of custom discovery message.
> In addition we should automatically execute this mechanism if transaction
> times out and add information to timeout exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217090#comment-15217090 ] Andrey Gura commented on IGNITE-2854: - At this moment search of the first deadlock (cycle in wait-for-graph) implemented as `DeadlockDetection` class that used by `IgniteTxManager`. Messaging implemented via `GridIoManager` and new `TOPIC_TX` topic. If deadlock detected then detector prints out transaction IDs that involved into deadlock and keys that cause of deadlock. Need to extend current algorithm for finding all possible deadlocks for active near transactions on current node. At the same time detection have to request from remote nodes only transactions that contain the same keys as transactions on the local node. It allows to reduce network traffic but increases possible requests in cases when deadlock wasn't detected. Also need to find out better way for reporting found deadlocks. > Need to implement deadlock detection > > > Key: IGNITE-2854 > URL: https://issues.apache.org/jira/browse/IGNITE-2854 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko >Assignee: Andrey Gura > Fix For: 1.6 > > > Currently, if transactional deadlock occurred, there is no easy way to find > out which locks were reordered. > We need to add a mechanism that will collect information about awating > candidates, analyze it and show guilty keys. Most likely this should be > implemented with the help of custom discovery message. > In addition we should automatically execute this mechanism if transaction > times out and add information to timeout exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15216333#comment-15216333 ] Artem Shutak commented on IGNITE-2645: -- Fixed in a way suggested by Alexey. Added entry's versions consistency tests. TC look good (waiting for the rest non-cache related tests). > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2908) .NET: Missing IgniteConfiguration properties
[ https://issues.apache.org/jira/browse/IGNITE-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-2908: --- Description: Some important but easy to propagate properties are missing from IgniteConfiguration class: * TransactionConfiguration * AtomicConfiguration * UserAttributes * IsDaemon was: * TransactionConfiguration * AtomicConfiguration * UserAttributes > .NET: Missing IgniteConfiguration properties > > > Key: IGNITE-2908 > URL: https://issues.apache.org/jira/browse/IGNITE-2908 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Some important but easy to propagate properties are missing from > IgniteConfiguration class: > * TransactionConfiguration > * AtomicConfiguration > * UserAttributes > * IsDaemon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2908) .NET: Missing IgniteConfiguration properties
Pavel Tupitsyn created IGNITE-2908: -- Summary: .NET: Missing IgniteConfiguration properties Key: IGNITE-2908 URL: https://issues.apache.org/jira/browse/IGNITE-2908 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 1.6 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.6 * TransactionConfiguration * AtomicConfiguration * UserAttributes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2890) .NET: Add CacheConfiguration.NodeFilter
[ https://issues.apache.org/jira/browse/IGNITE-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-2890: --- Description: See ServiceConfiguration.NodeFilter * Caches start earlier than platform => need to pass pointer for static CacheConfigurations * For dynamic cache start, no need for pointers was:See ServiceConfiguration.NodeFilter, all interop is already in place > .NET: Add CacheConfiguration.NodeFilter > --- > > Key: IGNITE-2890 > URL: https://issues.apache.org/jira/browse/IGNITE-2890 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > > See ServiceConfiguration.NodeFilter > * Caches start earlier than platform => need to pass pointer for static > CacheConfigurations > * For dynamic cache start, no need for pointers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)
[
https://issues.apache.org/jira/browse/IGNITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15216087#comment-15216087
]
Sergi Vladykin commented on IGNITE-2906:
For the issue you've described you can use @QuerySqlField(name = "unique_id")
annotation. Probably the issue description is wrong.
Also you should provide respective unit tests in your patch.
> Embedded / child element types indexing/queryfields (non-flat)
> --
>
> Key: IGNITE-2906
> URL: https://issues.apache.org/jira/browse/IGNITE-2906
> Project: Ignite
> Issue Type: Improvement
> Components: cache, data structures, general, SQL
>Reporter: Krome Plasma
> Attachments: indexing.patch
>
>
> I've had discussion about this on Apache Ignite Users.
> http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
> The problem occurs when you want to index a non-primitive type that have same
> names of variables as the enclosing type, better described on forum above. As
> a short example:
> Let's say we want to index:
> public class Person
> {
> @QuerySqlField
> long id;
> @QuerySqlField
> PersonData personData;
> }
> public class PersonData
> {
> @QuerySqlField
> long id;
> }
> This will not work as it will detect indexes/query fields with same names for
> index Person.id and PersonData.id because the names are flattened to simply
> 'id'.
> I am attaching a simple patch that resolves this issue. We've been running
> this for (3 months now) and found no problems. However we are using
> annotations and not XML. I am not sure the patch completely solves the
> problem for XML based configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2907) GridServiceNotFoundException is not descriptive
Pavel Tupitsyn created IGNITE-2907: -- Summary: GridServiceNotFoundException is not descriptive Key: IGNITE-2907 URL: https://issues.apache.org/jira/browse/IGNITE-2907 Project: Ignite Issue Type: Bug Components: managed services Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Priority: Minor Fix For: 1.6 "Service node found" message does not make sense. * Message should be fixed * More details should be added (why is this situation possible, how to fix it) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2398) .NET: Change default mapper behavior.
[ https://issues.apache.org/jira/browse/IGNITE-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-2398: -- Assignee: (was: Pavel Tupitsyn) > .NET: Change default mapper behavior. > - > > Key: IGNITE-2398 > URL: https://issues.apache.org/jira/browse/IGNITE-2398 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Priority: Critical > Labels: important > Fix For: 1.6 > > > We need to mirror changes implemented in IGNITE-2191: > 1) Default mapper must use full class name (i.e. with package) > 2) Provide additional mapper implementation which will use simple names. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)
[
https://issues.apache.org/jira/browse/IGNITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krome Plasma updated IGNITE-2906:
-
Description:
I've had discussion about this on Apache Ignite Users.
http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
The problem occurs when you want to index a non-primitive type that have same
names of variables as the enclosing type, better described on forum above. As a
short example:
Let's say we want to index:
public class Person
{
@QuerySqlField
long id;
@QuerySqlField
PersonData personData;
}
public class PersonData
{
@QuerySqlField
long id;
}
This will not work as it will detect indexes/query fields with same names for
index Person.id and PersonData.id because the names are flattened to simply
'id'.
I am attaching a simple patch that resolves this issue. We've been running this
for (3 months now) and found no problems. However we are using annotations and
not XML. I am not sure the patch completely solves the problem for XML based
configuration.
was:
I've had discussion about this on Apache Ignite Users.
http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
The problem occurs when you want to index a non-primitive type that have same
names of variables as the encloding type, better described on forum above. As a
short example:
Let's say we want to index:
public class Person
{
@QuerySqlField
long id;
@QuerySqlField
PersonData personData;
}
public class PersonData
{
@QuerySqlField
long id;
}
This will not work as it will detect indexes/query fields with same names for
index Person.id and PersonData.id because the names are flattened to simply
'id'.
I am attaching a simple patch that resolves this issue. We've been running this
for (3 months now) and found no problems. However we are using annotations and
not XML. I am not sure the patch completely solves the problem for XML based
configuration.
> Embedded / child element types indexing/queryfields (non-flat)
> --
>
> Key: IGNITE-2906
> URL: https://issues.apache.org/jira/browse/IGNITE-2906
> Project: Ignite
> Issue Type: Improvement
> Components: cache, data structures, general, SQL
>Reporter: Krome Plasma
> Attachments: indexing.patch
>
>
> I've had discussion about this on Apache Ignite Users.
> http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
> The problem occurs when you want to index a non-primitive type that have same
> names of variables as the enclosing type, better described on forum above. As
> a short example:
> Let's say we want to index:
> public class Person
> {
> @QuerySqlField
> long id;
> @QuerySqlField
> PersonData personData;
> }
> public class PersonData
> {
> @QuerySqlField
> long id;
> }
> This will not work as it will detect indexes/query fields with same names for
> index Person.id and PersonData.id because the names are flattened to simply
> 'id'.
> I am attaching a simple patch that resolves this issue. We've been running
> this for (3 months now) and found no problems. However we are using
> annotations and not XML. I am not sure the patch completely solves the
> problem for XML based configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov closed IGNITE-708. --- > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Anton Vinogradov >Priority: Blocker > Labels: datagrid > Fix For: 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-708. - Resolution: Duplicate > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Anton Vinogradov >Priority: Blocker > Labels: datagrid > Fix For: 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-708: --- Assignee: Anton Vinogradov > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Anton Vinogradov >Priority: Blocker > Labels: datagrid > Fix For: 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)
[
https://issues.apache.org/jira/browse/IGNITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krome Plasma updated IGNITE-2906:
-
Description:
I've had discussion about this on Apache Ignite Users.
http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
The problem occurs when you want to index a non-primitive type that have same
names of variables as the encloding type, better described on forum above. As a
short example:
Let's say we want to index:
public class Person
{
@QuerySqlField
long id;
@QuerySqlField
PersonData personData;
}
public class PersonData
{
@QuerySqlField
long id;
}
This will not work as it will detect indexes/query fields with same names for
index Person.id and PersonData.id because the names are flattened to simply
'id'.
I am attaching a simple patch that resolves this issue. We've been running this
for (3 months now) and found no problems. However we are using annotations and
not XML. I am not sure the patch completely solves the problem for XML based
configuration.
was:
I've had discussion about this on Apache Ignite Users.
http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
The problem occurs when you want to index a non-primitive type that have same
names of variables as the encloding type, better described on forum above. As a
short example:
Let's say we want to index:
public class Person
{
@QuerySqlField
long id;
@QuerySqlField
PersonData personData;
}
public class PersonData
{
@QuerySqlField
long id;
}
This will not work as it will detect indexes/query fields with same names for
index Person.id and PersonData.id. As the names flatten.
I am attaching a simple patch that resolves this issue. We've been running this
for (3 months now) and found no problems. However we are using annotations and
not XML. I am not sure the patch completely solves the problem for XML based
configuration.
> Embedded / child element types indexing/queryfields (non-flat)
> --
>
> Key: IGNITE-2906
> URL: https://issues.apache.org/jira/browse/IGNITE-2906
> Project: Ignite
> Issue Type: Improvement
> Components: cache, data structures, general, SQL
>Reporter: Krome Plasma
> Attachments: indexing.patch
>
>
> I've had discussion about this on Apache Ignite Users.
> http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
> The problem occurs when you want to index a non-primitive type that have same
> names of variables as the encloding type, better described on forum above. As
> a short example:
> Let's say we want to index:
> public class Person
> {
> @QuerySqlField
> long id;
> @QuerySqlField
> PersonData personData;
> }
> public class PersonData
> {
> @QuerySqlField
> long id;
> }
> This will not work as it will detect indexes/query fields with same names for
> index Person.id and PersonData.id because the names are flattened to simply
> 'id'.
> I am attaching a simple patch that resolves this issue. We've been running
> this for (3 months now) and found no problems. However we are using
> annotations and not XML. I am not sure the patch completely solves the
> problem for XML based configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)
[
https://issues.apache.org/jira/browse/IGNITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krome Plasma updated IGNITE-2906:
-
Attachment: indexing.patch
> Embedded / child element types indexing/queryfields (non-flat)
> --
>
> Key: IGNITE-2906
> URL: https://issues.apache.org/jira/browse/IGNITE-2906
> Project: Ignite
> Issue Type: Improvement
> Components: cache, data structures, general, SQL
>Reporter: Krome Plasma
> Attachments: indexing.patch
>
>
> I've had discussion about this on Apache Ignite Users.
> http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
> The problem occurs when you want to index a non-primitive type that have same
> names of variables as the encloding type, better described on forum above. As
> a short example:
> Let's say we want to index:
> public class Person
> {
> @QuerySqlField
> long id;
> @QuerySqlField
> PersonData personData;
> }
> public class PersonData
> {
> @QuerySqlField
> long id;
> }
> This will not work as it will detect indexes/query fields with same names for
> index Person.id and PersonData.id. As the names flatten.
> I am attaching a simple patch that resolves this issue. We've been running
> this for (3 months now) and found no problems. However we are using
> annotations and not XML. I am not sure the patch completely solves the
> problem for XML based configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2863) Memory leak in GridUnsafeMap destruct method.
[ https://issues.apache.org/jira/browse/IGNITE-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krome Plasma updated IGNITE-2863: - Attachment: indexing.patch > Memory leak in GridUnsafeMap destruct method. > - > > Key: IGNITE-2863 > URL: https://issues.apache.org/jira/browse/IGNITE-2863 > Project: Ignite > Issue Type: Bug > Components: cache, general >Reporter: Krome Plasma >Assignee: Yakov Zhdanov > Fix For: 1.6 > > Attachments: memoryLeak.patch > > > There's a memory leak in GridUnsafeMap destruct method() for loop. > The loop's condition is wrong "binAddr < memCap" where offset + memCap should > be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)
Krome Plasma created IGNITE-2906:
Summary: Embedded / child element types indexing/queryfields
(non-flat)
Key: IGNITE-2906
URL: https://issues.apache.org/jira/browse/IGNITE-2906
Project: Ignite
Issue Type: Improvement
Components: cache, data structures, general, SQL
Reporter: Krome Plasma
I've had discussion about this on Apache Ignite Users.
http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
The problem occurs when you want to index a non-primitive type that have same
names of variables as the encloding type, better described on forum above. As a
short example:
Let's say we want to index:
public class Person
{
@QuerySqlField
long id;
@QuerySqlField
PersonData personData;
}
public class PersonData
{
@QuerySqlField
long id;
}
This will not work as it will detect indexes/query fields with same names for
index Person.id and PersonData.id. As the names flatten.
I am attaching a simple patch that resolves this issue. We've been running this
for (3 months now) and found no problems. However we are using annotations and
not XML. I am not sure the patch completely solves the problem for XML based
configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2863) Memory leak in GridUnsafeMap destruct method.
[ https://issues.apache.org/jira/browse/IGNITE-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krome Plasma updated IGNITE-2863: - Attachment: (was: indexing.patch) > Memory leak in GridUnsafeMap destruct method. > - > > Key: IGNITE-2863 > URL: https://issues.apache.org/jira/browse/IGNITE-2863 > Project: Ignite > Issue Type: Bug > Components: cache, general >Reporter: Krome Plasma >Assignee: Yakov Zhdanov > Fix For: 1.6 > > Attachments: memoryLeak.patch > > > There's a memory leak in GridUnsafeMap destruct method() for loop. > The loop's condition is wrong "binAddr < memCap" where offset + memCap should > be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2902) CPP: Make IgniteError subclass of the std::exception.
[
https://issues.apache.org/jira/browse/IGNITE-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215838#comment-15215838
]
ASF GitHub Bot commented on IGNITE-2902:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/582
> CPP: Make IgniteError subclass of the std::exception.
> -
>
> Key: IGNITE-2902
> URL: https://issues.apache.org/jira/browse/IGNITE-2902
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> IgniteError should implement std::exception so it can be catched by the
> following block:
> {code}
> try { ... }
> catch(std::exception&) {...}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2902) CPP: Make IgniteError subclass of the std::exception.
[
https://issues.apache.org/jira/browse/IGNITE-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2902.
---
> CPP: Make IgniteError subclass of the std::exception.
> -
>
> Key: IGNITE-2902
> URL: https://issues.apache.org/jira/browse/IGNITE-2902
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> IgniteError should implement std::exception so it can be catched by the
> following block:
> {code}
> try { ... }
> catch(std::exception&) {...}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2863) Memory leak in GridUnsafeMap destruct method.
[ https://issues.apache.org/jira/browse/IGNITE-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215822#comment-15215822 ] Krome Plasma commented on IGNITE-2863: -- No problem. Will post some other issues. > Memory leak in GridUnsafeMap destruct method. > - > > Key: IGNITE-2863 > URL: https://issues.apache.org/jira/browse/IGNITE-2863 > Project: Ignite > Issue Type: Bug > Components: cache, general >Reporter: Krome Plasma >Assignee: Yakov Zhdanov > Fix For: 1.6 > > Attachments: memoryLeak.patch > > > There's a memory leak in GridUnsafeMap destruct method() for loop. > The loop's condition is wrong "binAddr < memCap" where offset + memCap should > be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2004) Asynchronous execution of ContinuousQuery's remote filter & local list
[ https://issues.apache.org/jira/browse/IGNITE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215806#comment-15215806 ] Semen Boikov commented on IGNITE-2004: -- Reviewed, have some comments: - the major issue is that if filter is asynchronous then notification code should be called from the same thread which execute filter, otherwise in current implementation starvation is possible - please add tests verifying call order filter and listener - CacheContinuousQueryAsyncFilterListenerTest should really fail if lsitener and filter are not async - in CacheContinuousQueryAsyncFilterListenerTest pelase add check that continous query event for operation executed from listener/fitler is recevied > Asynchronous execution of ContinuousQuery's remote filter & local list > -- > > Key: IGNITE-2004 > URL: https://issues.apache.org/jira/browse/IGNITE-2004 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Denis Magda >Assignee: Nikolay Tikhonov > Labels: important > Fix For: 1.6 > > > Presently remote filters are executed synchronously an entry update. This > leads to the limitation when it's disallowed to perform cache related > operation in a filter body. > It's required to add the ability to execute remote filters asynchronously. > This will let to execute any kind of operations including cache operations > directly in the filter body. > The solution must be fault-tolerant. At least once execution of a filter in > case of a failure works fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2694) .NET: AnyCPU build
[ https://issues.apache.org/jira/browse/IGNITE-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215803#comment-15215803 ] Pavel Tupitsyn commented on IGNITE-2694: Makes sense. I brought back x86/x64 configurations for Core project and solution file, so old dev/build/test procedures can be kept in place, and there is no build time penalty during development in x64/x86 mode. > .NET: AnyCPU build > -- > > Key: IGNITE-2694 > URL: https://issues.apache.org/jira/browse/IGNITE-2694 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Currently we provide separate x86 & x64 binaries. NuGet is x64-only. > This is inconvenient both for us and the user. > The only thing that prevents AnyCPU is unmanaged "common" project. > But we load it dynamically from resources, and we may as well detect current > process platform (x64 or not) and load a proper unmanaged resource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2788) Mediator layer for Ignite to work with data via the Redis protocol
[ https://issues.apache.org/jira/browse/IGNITE-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215703#comment-15215703 ] Roman Shtykh commented on IGNITE-2788: -- Clean branch ignite-2788 is created for this task. > Mediator layer for Ignite to work with data via the Redis protocol > -- > > Key: IGNITE-2788 > URL: https://issues.apache.org/jira/browse/IGNITE-2788 > Project: Ignite > Issue Type: New Feature >Reporter: Roman Shtykh >Assignee: Roman Shtykh > > Introduce a mediator layer that works with the Redis clients/protocol but > uses Ignite grid for storage. > Needless to say, Redis is an extremely popular caching solution. Such API > will enable smooth migration to Ignite. > As a first phase we can start with most frequently used commands and enhance > gradually. > Redis commands http://redis.io/commands -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2887) .NET: Add platform interoperability documentation
[ https://issues.apache.org/jira/browse/IGNITE-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215700#comment-15215700 ] Pavel Tupitsyn commented on IGNITE-2887: Done: https://apacheignite-net.readme.io/docs/platform-interoperability > .NET: Add platform interoperability documentation > - > > Key: IGNITE-2887 > URL: https://issues.apache.org/jira/browse/IGNITE-2887 > Project: Ignite > Issue Type: Task > Components: documentation, platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Describe how to map between .NET and Java types (id mapper, name mapper) on > https://apacheignite-net.readme.io/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2905) Window processing support for IgniteStream
Roman Shtykh created IGNITE-2905: Summary: Window processing support for IgniteStream Key: IGNITE-2905 URL: https://issues.apache.org/jira/browse/IGNITE-2905 Project: Ignite Issue Type: Sub-task Components: streaming Reporter: Roman Shtykh Support for the following - Time-based window - Size-based window - Session-based window with aggregate functions like sum/min/max/etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2904) IgniteStream API Implementation
Roman Shtykh created IGNITE-2904: Summary: IgniteStream API Implementation Key: IGNITE-2904 URL: https://issues.apache.org/jira/browse/IGNITE-2904 Project: Ignite Issue Type: New Feature Components: streaming Reporter: Roman Shtykh API to handle cache as a stream. Data transmission has to be implemented via Reactive Streams interface. http://www.reactive-streams.org/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1071) IgniteCache.metrics() method returns local metrics
[
https://issues.apache.org/jira/browse/IGNITE-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov closed IGNITE-1071.
> IgniteCache.metrics() method returns local metrics
> --
>
> Key: IGNITE-1071
> URL: https://issues.apache.org/jira/browse/IGNITE-1071
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Minor
> Labels: Usability
> Fix For: 1.6
>
>
> To get metrics for the whole cluster user needs to use
> {{cache.metrics(ignite.cluster())}}, which is counterintuitive and
> inconsistent with other APIs. {{IgniteCache.metrics()}} w/o parameters should
> return metrics for the whole cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-1071) IgniteCache.metrics() method returns local metrics
[
https://issues.apache.org/jira/browse/IGNITE-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-1071.
--
Resolution: Fixed
Reviewed by Semen.
Merged to master.
> IgniteCache.metrics() method returns local metrics
> --
>
> Key: IGNITE-1071
> URL: https://issues.apache.org/jira/browse/IGNITE-1071
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Minor
> Labels: Usability
> Fix For: 1.6
>
>
> To get metrics for the whole cluster user needs to use
> {{cache.metrics(ignite.cluster())}}, which is counterintuitive and
> inconsistent with other APIs. {{IgniteCache.metrics()}} w/o parameters should
> return metrics for the whole cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2002) Data streamer does not work with peerClassLoadingEnabled
[ https://issues.apache.org/jira/browse/IGNITE-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2002: Fix Version/s: (was: 1.6) 1.7 > Data streamer does not work with peerClassLoadingEnabled > > > Key: IGNITE-2002 > URL: https://issues.apache.org/jira/browse/IGNITE-2002 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Priority: Critical > Fix For: 1.7 > > > Add to spring config, > run streamer tests or examples, there are exceptions in Java and flush hangs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2103) CPP: Simplify query examples.
[ https://issues.apache.org/jira/browse/IGNITE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2103: Fix Version/s: (was: 1.6) 1.7 > CPP: Simplify query examples. > - > > Key: IGNITE-2103 > URL: https://issues.apache.org/jira/browse/IGNITE-2103 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov > Fix For: 1.7 > > > Simply move IGNITE-2097 to CPP once it is ready. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2103) CPP: Simplify query examples.
[ https://issues.apache.org/jira/browse/IGNITE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2103: Description: Simply move IGNITE-2097 to CPP once it is ready. (was: Simply move IGNITE-2097 to .NET once it is ready.) > CPP: Simplify query examples. > - > > Key: IGNITE-2103 > URL: https://issues.apache.org/jira/browse/IGNITE-2103 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov > Fix For: 1.7 > > > Simply move IGNITE-2097 to CPP once it is ready. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2102) .NET: Simplify query examples
[ https://issues.apache.org/jira/browse/IGNITE-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2102: Fix Version/s: (was: 1.6) 1.7 > .NET: Simplify query examples > - > > Key: IGNITE-2102 > URL: https://issues.apache.org/jira/browse/IGNITE-2102 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov > Fix For: 1.7 > > > Simply move IGNITE-2097 to .NET once it is ready. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2897) ODBC: Multiple grids cannot start with default configuration due to port conflict.
[ https://issues.apache.org/jira/browse/IGNITE-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2897. --- > ODBC: Multiple grids cannot start with default configuration due to port > conflict. > -- > > Key: IGNITE-2897 > URL: https://issues.apache.org/jira/browse/IGNITE-2897 > Project: Ignite > Issue Type: Sub-task > Components: odbc >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > *Problem* > Currently each node has ODBC enabled by default. ODBC processor has a single > default port and each node tries to occupy it. As a result, second node > cannot start due to port conflict. > *Possible solutions* > 1) Do not start ODBC processor by default. > Cons: will require explicit config for ODBC users. > 2) Scan several ports until free port is found. > Cons: will require changes on client side. > Anything else? > I think that for now could go with the most easy and straightforward solution > - do not start ODBC processor by default. This way we merge ODBC faster. In > future releases we could easily make it start by default with normal port > scan. It should not affect compatibility anyhow. > Thoughts? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2730) Ignite Events Source Streaming to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215584#comment-15215584 ] Roman Shtykh commented on IGNITE-2730: -- Denis, 1. Thank you for the pointers on primary node check! I implemented this check in the similar manner. Please have a look. And you are absolutely right -- the current code is not sufficient to guarantee data safety in the queue. Let's treat it as a future work. 2. Using Ignite default marshaller would be nice, but what if the user access cache events in Kafka without Ignite instance (using Kafka client rather than Kafka Connect), like it is done in the tests (_checkDataDelivered(...)_)? It should not be necessarily _JdkMarshaller_, but we should consider having a de/serializer that can be used with Kafka Connect even without the knowledge of the grid. > Ignite Events Source Streaming to Kafka > --- > > Key: IGNITE-2730 > URL: https://issues.apache.org/jira/browse/IGNITE-2730 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: community > > Streaming specified Ignite events > (https://apacheignite.readme.io/docs/events) to Kafka via Kafka Connect. > It has to be added to org.apache.ignite.stream.kafka.connect package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2902) CPP: Make IgniteError subclass of the std::exception.
[
https://issues.apache.org/jira/browse/IGNITE-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2902:
Component/s: platforms
> CPP: Make IgniteError subclass of the std::exception.
> -
>
> Key: IGNITE-2902
> URL: https://issues.apache.org/jira/browse/IGNITE-2902
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> IgniteError should implement std::exception so it can be catched by the
> following block:
> {code}
> try { ... }
> catch(std::exception&) {...}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2902) CPP: Make IgniteError subclass of the std::exception.
[
https://issues.apache.org/jira/browse/IGNITE-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2902:
Component/s: (was: clients)
> CPP: Make IgniteError subclass of the std::exception.
> -
>
> Key: IGNITE-2902
> URL: https://issues.apache.org/jira/browse/IGNITE-2902
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> IgniteError should implement std::exception so it can be catched by the
> following block:
> {code}
> try { ... }
> catch(std::exception&) {...}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2900) CPP: Metadata update request causes Java Exception.
[
https://issues.apache.org/jira/browse/IGNITE-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215583#comment-15215583
]
ASF GitHub Bot commented on IGNITE-2900:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/581
> CPP: Metadata update request causes Java Exception.
> ---
>
> Key: IGNITE-2900
> URL: https://issues.apache.org/jira/browse/IGNITE-2900
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Call to the {{BinaryTypeUpdaterImpl::Update}} causes exception {{Not enough
> data to read the value [position=227, requiredBytes=4, remainingBytes=0]}}.
> Needs to be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2900) CPP: Metadata update request causes Java Exception.
[
https://issues.apache.org/jira/browse/IGNITE-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2900.
---
> CPP: Metadata update request causes Java Exception.
> ---
>
> Key: IGNITE-2900
> URL: https://issues.apache.org/jira/browse/IGNITE-2900
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Call to the {{BinaryTypeUpdaterImpl::Update}} causes exception {{Not enough
> data to read the value [position=227, requiredBytes=4, remainingBytes=0]}}.
> Needs to be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2550) .NET: Simplify examples configuration
[ https://issues.apache.org/jira/browse/IGNITE-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215582#comment-15215582 ] ASF GitHub Bot commented on IGNITE-2550: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/570 > .NET: Simplify examples configuration > - > > Key: IGNITE-2550 > URL: https://issues.apache.org/jira/browse/IGNITE-2550 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > We now have in-code configuration (IGNITE-1906), need to demonstrate it in > examples, and simplify them where possible. > 1) First, start all caches programmatically. This may reduce number of spring > configs. > 2) Second, see if we can benefit from full in-code config for some of the > examples (compute). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2550) .NET: Simplify examples configuration
[ https://issues.apache.org/jira/browse/IGNITE-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2550. --- > .NET: Simplify examples configuration > - > > Key: IGNITE-2550 > URL: https://issues.apache.org/jira/browse/IGNITE-2550 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > We now have in-code configuration (IGNITE-1906), need to demonstrate it in > examples, and simplify them where possible. > 1) First, start all caches programmatically. This may reduce number of spring > configs. > 2) Second, see if we can benefit from full in-code config for some of the > examples (compute). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
