[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286061#comment-15286061 ] Igor Rudyak commented on IGNITE-1371: - Guys, I commited all the latest changes related to performance improvements and load tests infrastructure bootstrap for AWS. Also merged them with "upstream" and pushed to "ignite-1371" branch: https://github.com/irudyak/ignite/tree/ignite-1371 Will add documentation for load tests infrastructure boostrap in AWS a bit later. > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Fix For: 1.6 > > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3139) .NET: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286037#comment-15286037
]
Denis Magda commented on IGNITE-3139:
-
Pavel, modified the code on Java side slightly and pushed changes into
ignite-3098 branch. Left comments in your PR regarding what have to be updated
on .Net side.
> .NET: UTF-16 surrogate symbols are not serialized properly
> --
>
> Key: IGNITE-3139
> URL: https://issues.apache.org/jira/browse/IGNITE-3139
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> .Net serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3140) C++: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286028#comment-15286028
]
Denis Magda commented on IGNITE-3140:
-
Igor,
The new serialization algorithm on Java side serializes all symbols that are
bigger than 0x07FF in 3 bytes.
It means that if there is a valid surrogate pair in a String like this one
{{0xD801, 0xDC37}} then the new algorithm will use 6 bytes to code it while
basic UTF-8 coders/decoders will use only 4 bytes. C++ side won't be able to
properly deserialize {{0xD801, 0xDC37}} on its side because it will be encoded
in 6 bytes.
Try to serialize this String on C++ side. It should be encoded in 4 bytes while
the new Java algorithm encodes it in 6 bytes.
{noformat}
str = new String(new char[] {0xD801, 0xDC37});
{noformat}
> C++: UTF-16 surrogate symbols are not serialized properly
> -
>
> Key: IGNITE-3140
> URL: https://issues.apache.org/jira/browse/IGNITE-3140
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> C++ serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-3144) Refactor Schema Import Utility. Split for two modules: schema-import and schema-import-db
[ https://issues.apache.org/jira/browse/IGNITE-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-3144. -- Resolution: Fixed Fixed build. > Refactor Schema Import Utility. Split for two modules: schema-import and > schema-import-db > - > > Key: IGNITE-3144 > URL: https://issues.apache.org/jira/browse/IGNITE-3144 > Project: Ignite > Issue Type: Task > Components: build >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > > In order to reuse same code from Schema Import and Web console we need to > refactor ignite-schema-import module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3130) .NET: TcpDiscoverySpi missing properties
[ https://issues.apache.org/jira/browse/IGNITE-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15285990#comment-15285990 ] ASF GitHub Bot commented on IGNITE-3130: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/715 > .NET: TcpDiscoverySpi missing properties > > > Key: IGNITE-3130 > URL: https://issues.apache.org/jira/browse/IGNITE-3130 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > localPort, localAddress, etc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3112) .NET: Allow merging Spring XML config with .NET config
[ https://issues.apache.org/jira/browse/IGNITE-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15285992#comment-15285992 ] ASF GitHub Bot commented on IGNITE-3112: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/706 > .NET: Allow merging Spring XML config with .NET config > -- > > Key: IGNITE-3112 > URL: https://issues.apache.org/jira/browse/IGNITE-3112 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.6 > > > Currently we ignore most IgniteConfiguration properties if SpringConfigUrl is > set. > So if there is even one property not propagated to .NET, user has to switch > completely to Spring XML, which may be quite tragic, especially for query > entity configurations. > Instead, we can merge configs on the top level: > First, we load Spring XML. Then we apply non-null .NET properties on top of > it. > Primitive properties should be made nullable underneath to track whether user > has set them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3118) .NET: CacheConfiguration.EvictionPolicy
[ https://issues.apache.org/jira/browse/IGNITE-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15285991#comment-15285991 ] ASF GitHub Bot commented on IGNITE-3118: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/710 > .NET: CacheConfiguration.EvictionPolicy > --- > > Key: IGNITE-3118 > URL: https://issues.apache.org/jira/browse/IGNITE-3118 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > Propagate CacheConfiguration.EvictionPolicy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3115) List of ODBC minor issues
[
https://issues.apache.org/jira/browse/IGNITE-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15285993#comment-15285993
]
ASF GitHub Bot commented on IGNITE-3115:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/714
> List of ODBC minor issues
> -
>
> Key: IGNITE-3115
> URL: https://issues.apache.org/jira/browse/IGNITE-3115
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 1.6
> Environment: Ubuntu 14.04, Win7
>Reporter: Vasilisa Sidorova
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 1.6
>
>
> There is the list of minor issues for ODBC feature:
> 1. Win7:
> 1.1 install_amd64.cmd ODBC driver installator:
> 1.1.1 The final script output always is "32-bit driver can not be
> found: """. It's not necessary to find 32-bit driver. Please, fix it
> 1.2.1 It's possible to write path to the folder into registry. Please,
> add path-to-file validation into the script
> 1.2 Win Administrative Tools GUI:
> 1.2.1 DNS settings for Apache Ignite ODBC driver should be disabled (as
> this is not implemented yet)
> 1.3 Documentation:
> 1.3.1 Please, add information that odbc should be building individual
> into "Building binaries:" part of the IGNITE_HOME/platforms/cpp/DEVNOTES.txt
> 1.3.2 Please relocate instruction "Most likely you will need OS
> administrator privileges to execute these scripts." before run install script
> in the "Installing ODBC driver on Windows" part of the
> IGNITE_HOME/platforms/cpp/odbc/README.txt
> 2. Ubuntu - documentation:
> 2.1 It will be more user-friendly to mention that path to libignite-odbc.so
> should be in the LD_LIBRARY_PATH environment variable in the "Running
> examples on Linux" part of the IGNITE_HOME/platforms/cpp/examples/README.txt
> 2.2 The command
> {noformat}
> * libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> {noformat}
> is absent in the "Running examples on Linux" part of the
> IGNITE_HOME/platforms/cpp/examples/README.txt
> 3. Please, make the same changes in the documentation on the readme.io
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (IGNITE-3144) Refactor Schema Import Utility. Split for two modules: schema-import and schema-import-db
[
https://issues.apache.org/jira/browse/IGNITE-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov reopened IGNITE-3144:
Assignee: Alexey Kuznetsov (was: Pavel Konstantinov)
got this when click Load Schemas
{code}
ьрщ 17, 2016 10:34:21 AM org.apache.ignite.schema.ui.MessageBox errorDialog
SEVERE: Failed to get schemas list from database.
java.lang.NoClassDefFoundError: org/apache/ignite/schema/parser/DbMetadataReader
at
org.apache.ignite.schema.ui.SchemaImportApp.connect(SchemaImportApp.java:414)
at
org.apache.ignite.schema.ui.SchemaImportApp.access$000(SchemaImportApp.java:97)
at
org.apache.ignite.schema.ui.SchemaImportApp$3.call(SchemaImportApp.java:520)
at
org.apache.ignite.schema.ui.SchemaImportApp$3.call(SchemaImportApp.java:515)
at javafx.concurrent.Task$TaskCallable.call(Task.java:1259)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException:
org.apache.ignite.schema.parser.DbMetadataReader
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 11 more
{code}
> Refactor Schema Import Utility. Split for two modules: schema-import and
> schema-import-db
> -
>
> Key: IGNITE-3144
> URL: https://issues.apache.org/jira/browse/IGNITE-3144
> Project: Ignite
> Issue Type: Task
> Components: build
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 1.6
>
>
> In order to reuse same code from Schema Import and Web console we need to
> refactor ignite-schema-import module.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Rudyak updated IGNITE-1371: Fix Version/s: 1.6 > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Fix For: 1.6 > > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3145) Display in metadata list cache schema name instead of cache name if schema present in cache configuration
Pavel Konstantinov created IGNITE-3145: -- Summary: Display in metadata list cache schema name instead of cache name if schema present in cache configuration Key: IGNITE-3145 URL: https://issues.apache.org/jira/browse/IGNITE-3145 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov Assignee: Andrey Novikov Priority: Minor Currently we display cache name, but sort alphabetically considering cache schema name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3140) C++: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15285021#comment-15285021
]
Igor Sapego commented on IGNITE-3140:
-
Denis,
C++ uses UTF-8 encoding right now and as long as Java and .NET nodes would
write strings in UTF-8 we are not going to have any problems with
deserialization. On the C++ side we just copy those received string bytes
without performing any complex processing and use it as string. As long as it
is valid UTF-8 data (and in our Binary protocol it is) everything is going to
work just fine.
> C++: UTF-16 surrogate symbols are not serialized properly
> -
>
> Key: IGNITE-3140
> URL: https://issues.apache.org/jira/browse/IGNITE-3140
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> C++ serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3140) C++: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284919#comment-15284919
]
Denis Magda commented on IGNITE-3140:
-
Igor,
In case of heterogeneous cluster (Java and C++ nodes) C++ side won't be able to
properly deserialize surrogate symbols from a String serialized on Java side if
the new algo (from IGNITE-3098) is used. This is the reason why we should
rewrite strings serialization on logic on C++ side as well.
> C++: UTF-16 surrogate symbols are not serialized properly
> -
>
> Key: IGNITE-3140
> URL: https://issues.apache.org/jira/browse/IGNITE-3140
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> C++ serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284714#comment-15284714 ] Konstantin Boudnik commented on IGNITE-1371: I believe it is a very good idea! But..., I would suggest to have the separation done as a follow up JIRA. This is really an improvement to provide for the pluggable compression modules. Clearly, a feature could be improved endlessly, but in the interest of progressing forward and avoiding bit-rot it would make sense to make smaller, reservable steps. While it won't always be perfect, smaller consequent improvements are superior to a single feature, that accounts for everything at once. So, if current implementation is good, let's get it in and work on the compression separation in the next iteration. [~irudyak], could you please create a new ticket for that? Thanks! > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284675#comment-15284675 ] Alexey Kuznetsov commented on IGNITE-1371: -- In general I'm OK with current implementation except one thing - I'm not really like that ignite-cassandra requires Kryo as third-party dependency. It is possible to refactor serializers to be pluggable? And introduce one more module, with name "ignite-cassandra-kryo"? What do you think? > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2528) Deadlocks caused by Ignite.close()
[
https://issues.apache.org/jira/browse/IGNITE-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284665#comment-15284665
]
Alexei Scherbakov commented on IGNITE-2528:
---
Created a reproducer.
> Deadlocks caused by Ignite.close()
> --
>
> Key: IGNITE-2528
> URL: https://issues.apache.org/jira/browse/IGNITE-2528
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
> Fix For: 1.7
>
>
> If to start stopping an Ignite instance and execute {{cluster.nodes()}} from
> an {{EntryProcessor}} or some other place of the code that holds a lock on
> cache's gateway then this can lead to the deadlock:
> Ignite.close:
> - holds kernel.gateway lock;
> - tries to get a gateway lock on cache A;
> Entry.processor is called for cache A:
> - a gateway lock is acquired for cache A;
> - calling {{cluster.nodes()}};
> - trying to acquire kernel's gateway lock.
> To fix this deadlock we can do the following:
> - introduce a volatile variable that has to be set to 'true' when a node is
> being stopped;
> - check this variable before acquiring kernel's gateway.
> Also probably it makes sense to try to use try lock here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-3120) LINQ Provider
[ https://issues.apache.org/jira/browse/IGNITE-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-3120: -- Assignee: Pavel Tupitsyn > LINQ Provider > - > > Key: IGNITE-3120 > URL: https://issues.apache.org/jira/browse/IGNITE-3120 > Project: Ignite > Issue Type: Sub-task > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3129) All config samples should contain C#, app.config and Spring XML tabs
[ https://issues.apache.org/jira/browse/IGNITE-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-3129. Resolution: Done > All config samples should contain C#, app.config and Spring XML tabs > > > Key: IGNITE-3129 > URL: https://issues.apache.org/jira/browse/IGNITE-3129 > Project: Ignite > Issue Type: Sub-task > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3129) All config samples should contain C#, app.config and Spring XML tabs
[ https://issues.apache.org/jira/browse/IGNITE-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-3129. -- > All config samples should contain C#, app.config and Spring XML tabs > > > Key: IGNITE-3129 > URL: https://issues.apache.org/jira/browse/IGNITE-3129 > Project: Ignite > Issue Type: Sub-task > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3140) C++: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284659#comment-15284659
]
Igor Sapego commented on IGNITE-3140:
-
We do not deal with the UTF-16 in C++ code. We expect user to provide us
strings in a valid UTF-8 format.
Added test with malformed UTF-8 string where we are expecting an exception.
> C++: UTF-16 surrogate symbols are not serialized properly
> -
>
> Key: IGNITE-3140
> URL: https://issues.apache.org/jira/browse/IGNITE-3140
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> C++ serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-3129) All config samples should contain C#, app.config and Spring XML tabs
[ https://issues.apache.org/jira/browse/IGNITE-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-3129: -- Assignee: Pavel Tupitsyn > All config samples should contain C#, app.config and Spring XML tabs > > > Key: IGNITE-3129 > URL: https://issues.apache.org/jira/browse/IGNITE-3129 > Project: Ignite > Issue Type: Sub-task > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3121) Atomics
[ https://issues.apache.org/jira/browse/IGNITE-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-3121. Resolution: Done > Atomics > --- > > Key: IGNITE-3121 > URL: https://issues.apache.org/jira/browse/IGNITE-3121 > Project: Ignite > Issue Type: Sub-task > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3121) Atomics
[ https://issues.apache.org/jira/browse/IGNITE-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-3121: -- Assignee: Pavel Tupitsyn > Atomics > --- > > Key: IGNITE-3121 > URL: https://issues.apache.org/jira/browse/IGNITE-3121 > Project: Ignite > Issue Type: Sub-task > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3128) Eviction Policy Configuration
[ https://issues.apache.org/jira/browse/IGNITE-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-3128. Resolution: Done > Eviction Policy Configuration > - > > Key: IGNITE-3128 > URL: https://issues.apache.org/jira/browse/IGNITE-3128 > Project: Ignite > Issue Type: Sub-task > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3128) Eviction Policy Configuration
[ https://issues.apache.org/jira/browse/IGNITE-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-3128. -- > Eviction Policy Configuration > - > > Key: IGNITE-3128 > URL: https://issues.apache.org/jira/browse/IGNITE-3128 > Project: Ignite > Issue Type: Sub-task > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2231) 'Put' cache event treats entry created at lock acquisition time as old value
[
https://issues.apache.org/jira/browse/IGNITE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2231:
Fix Version/s: (was: 1.6)
1.7
> 'Put' cache event treats entry created at lock acquisition time as old value
>
>
> Key: IGNITE-2231
> URL: https://issues.apache.org/jira/browse/IGNITE-2231
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: wmz7year
> Labels: important
> Fix For: 1.7
>
> Attachments: EventsProcessingTest.java
>
>
> Subscribe for EVT_CACHE_OBJECT_PUT event on one node and perform 'put'
> operations from the other to an empty transnational cache.
> The subscriber will receive a notification saying that there was an old value
> for a key at the time the new was being inserted. In fact the was no an old
> value, the entry with a {{null}} as a value was generated as a part of
> implicit lock acquisition.
> This snippet of the code in {{GridCacheMapEntry}} generates a wrong event
> (innerSet function)
> {noformat}
> if (evt && newVer != null &&
> cctx.events().isRecordable(EVT_CACHE_OBJECT_PUT)) {
> CacheObject evtOld = cctx.unwrapTemporary(old);
> cctx.events().addEvent(partition(),
> key,
> evtNodeId,
> tx == null ? null : tx.xid(),
> newVer,
> EVT_CACHE_OBJECT_PUT,
> val,
> val != null,
> evtOld,
> evtOld != null || hasValueUnlocked(),
> subjId, null, taskName,
> keepBinary);
> }
> {noformat}
> Attached the test that lets reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3139) .NET: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284616#comment-15284616
]
Pavel Tupitsyn commented on IGNITE-3139:
https://github.com/apache/ignite/pull/721
> .NET: UTF-16 surrogate symbols are not serialized properly
> --
>
> Key: IGNITE-3139
> URL: https://issues.apache.org/jira/browse/IGNITE-3139
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> .Net serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-878) Large GC if load data to the cache using datastreamer
[ https://issues.apache.org/jira/browse/IGNITE-878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-878: --- Fix Version/s: (was: 1.6) 1.7 > Large GC if load data to the cache using datastreamer > -- > > Key: IGNITE-878 > URL: https://issues.apache.org/jira/browse/IGNITE-878 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: sprint-4 >Reporter: Pavel Konstantinov >Assignee: Sergi Vladykin > Fix For: 1.7 > > Attachments: #_IGNITE-878_GC_using_on_data_streaming_test.patch, > ig-878.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1081) Create integration for OrientDB
[ https://issues.apache.org/jira/browse/IGNITE-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-1081: Fix Version/s: (was: 1.6) 1.7 > Create integration for OrientDB > --- > > Key: IGNITE-1081 > URL: https://issues.apache.org/jira/browse/IGNITE-1081 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: sprint-7 >Reporter: Alexey Kuznetsov >Assignee: Gianfranco Murador >Priority: Minor > Labels: newbie > Fix For: 1.7 > > > Create integration for OrientDB > Create integration for OrientDB https://github.com/orientechnologies/orientdb > OHazelcastPlugin can be used as start point: > https://github.com/orientechnologies/orientdb/blob/master/distributed/src/main/java/com/orientechnologies/orient/server/hazelcast/OHazelcastPlugin.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1232) Support distributed SQL JOIN
[ https://issues.apache.org/jira/browse/IGNITE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-1232: Fix Version/s: (was: 1.6) 1.7 > Support distributed SQL JOIN > - > > Key: IGNITE-1232 > URL: https://issues.apache.org/jira/browse/IGNITE-1232 > Project: Ignite > Issue Type: Improvement >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin > Fix For: 1.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1238) Joining node should be discarded in case discovery exchange data can't be deserialized
[
https://issues.apache.org/jira/browse/IGNITE-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-1238:
Fix Version/s: (was: 1.6)
1.7
> Joining node should be discarded in case discovery exchange data can't be
> deserialized
> --
>
> Key: IGNITE-1238
> URL: https://issues.apache.org/jira/browse/IGNITE-1238
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Raúl Kripalani
>Priority: Critical
> Fix For: 1.7
>
>
> Currently a node will join even if unmarshalling fails (see
> {{TcpDiscoverySpi.onExchange()}} method, which can cause unexpected
> behaviour. For example, a continuous query listener is not deployed on some
> nodes in topology. Everything works, but some updates are lost. We should
> discard the node in this case and give a good error message to user with
> information on how to fix it properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2394) Cache loading from storage is called on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2394:
Fix Version/s: (was: 1.6)
1.7
> Cache loading from storage is called on client nodes
>
>
> Key: IGNITE-2394
> URL: https://issues.apache.org/jira/browse/IGNITE-2394
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alper Tekinalp
>Priority: Critical
> Labels: newbie
> Fix For: 1.7
>
> Attachments: LocalLoadTest.java, master_186c860_IGNITE-2394.patch,
> master_baa1312_IGNITE-2394.patch
>
>
> If to call cache.loadCache(...) then the loading from a storage will happen
> on all the nodes including client nodes.
> However, client nodes must be filtered out.
> If to be more precise at least this place of the code has to be modified
> {noformat}
> IgniteInternalFuture globalLoadCacheAsync(@Nullable
> IgniteBiPredicate p, @Nullable Object... args)
> throws IgniteCheckedException {
> ClusterGroup nodes =
> ctx.kernalContext().grid().cluster().forCacheNodes(ctx.name());
> {noformat}
> where forDataNodes() has to be used instead of forCacheNodes().
> Also additional tests have to be added.
> Discussion on the user list:
> http://apache-ignite-users.70518.x6.nabble.com/Loadcache-behavior-tp2571.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2294) Implement SQL DML (insert, update, delete) cluses.
[ https://issues.apache.org/jira/browse/IGNITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2294: Fix Version/s: (was: 1.6) 1.7 > Implement SQL DML (insert, update, delete) cluses. > -- > > Key: IGNITE-2294 > URL: https://issues.apache.org/jira/browse/IGNITE-2294 > Project: Ignite > Issue Type: Wish >Reporter: Sergi Vladykin > Fix For: 1.7 > > > We need to add parsing for all the listed SQL commands and translate them > into respective cache operations (putIfAbstent, put, remove). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1495) Cache SQL query metadata index's fields have wrong register.
[ https://issues.apache.org/jira/browse/IGNITE-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-1495: Fix Version/s: (was: 1.6) 1.7 > Cache SQL query metadata index's fields have wrong register. > > > Key: IGNITE-1495 > URL: https://issues.apache.org/jira/browse/IGNITE-1495 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.5.0.final >Reporter: Vasiliy Sisko >Assignee: Sergi Vladykin > Fix For: 1.7 > > Attachments: #_IGNITE-1495_Test_for_index_s_fields.patch > > > Index's fields should have register how in table fields (In upper case). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2539) NPE at RendezvousAffinityFunction
[ https://issues.apache.org/jira/browse/IGNITE-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2539: Fix Version/s: (was: 1.6) 1.7 > NPE at RendezvousAffinityFunction > - > > Key: IGNITE-2539 > URL: https://issues.apache.org/jira/browse/IGNITE-2539 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ershov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 1.7 > > Attachments: ignite.log > > Original Estimate: 4h > Remaining Estimate: 4h > > RendezvousAffinityFunction#assignPartition throws NPE, probably due to > simultaneous topology change and cache stop. We should write a test and fix > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2396) Dynamic cache changes are not tracked by service processor
[ https://issues.apache.org/jira/browse/IGNITE-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2396: Fix Version/s: (was: 1.6) 1.7 > Dynamic cache changes are not tracked by service processor > -- > > Key: IGNITE-2396 > URL: https://issues.apache.org/jira/browse/IGNITE-2396 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk > Labels: community > Fix For: 1.7 > > > Currently service processor handles only discovery node join/leave/fail > events. Now consider the following two scenarios: > - > - N nodes are started. Topology version is (N, 0) > - A dynamic cache is created. Topology version is (N, 1) > - An affinity singleton service is deployed. > On step (3), when assignment is calculated, service processor uses topology > version (N, 0) (see > org.apache.ignite.internal.processors.service.GridServiceProcessor.DeploymentListener#onDeployment). > As a result, no affinity nodes are returned for assignment and service is > not deployed. > - > - N nodes are started. Topology version is (N, 0) > - An affinity singleton service is deployed. > - A dynamic cache is created. Topology version is (N, 1) > On step (3) custom discovery event is generated, but it is not handled by > service processor, so no reassignment logic is triggered and service is not > deployed. > Proposed solution is as follows: > - Use a correct topology version for service deployment > (ctx.discovery().topologyVersionEx()). > - Event listener should handle custom events that trigger dynamic cache > start and stop. > - Additionally need to investigate whether reassignment logic should be in > any way synchronized with the partition exchange future completion. > org.apache.ignite.internal.processors.service.IgniteServiceDynamicCachesSelfTest > is added to master. Need to add it to the services test suite once the fix > is implemented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2546) Need to introduce transformers to SCAN queries
[
https://issues.apache.org/jira/browse/IGNITE-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2546:
Fix Version/s: (was: 1.6)
1.7
> Need to introduce transformers to SCAN queries
> --
>
> Key: IGNITE-2546
> URL: https://issues.apache.org/jira/browse/IGNITE-2546
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.7
>
>
> Need to add new method to {{IgniteCache}} API:
> {code}
> public QueryCursor query(Query qry, IgniteClosure
> transformer);
> {code}
> For {{SqlFieldsQuery}} we should throw {{UnsupportedOperationException}}, but
> for all other types of query proper support should be implemented.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2483) Cache metrics functionality for client nodes should be developed.
[ https://issues.apache.org/jira/browse/IGNITE-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2483: Fix Version/s: (was: 1.6) 1.7 > Cache metrics functionality for client nodes should be developed. > - > > Key: IGNITE-2483 > URL: https://issues.apache.org/jira/browse/IGNITE-2483 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Alexey Goncharuk > Labels: community > Fix For: 1.7 > > > User list discussion: > http://apache-ignite-users.70518.x6.nabble.com/Is-there-a-way-to-get-cache-metrics-for-all-the-nodes-in-cluster-combined-td2674.html > Currently there are at least three issues with cache metrics: > # When metrics are acquired on client, average put times are always zero. > This happens because timings are calculated on the client, but puts are > counted on servers. > # Size and keySize are always zero even if cache is not empty. > # Default metrics() method that doesn't take a cluster group provides metrics > for local node only. So if it's called on client, they are always empty. It > should calculate metrics for the whole cluster instead. > Also looks like this code is very undertested. Coverage should be > significantly improved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2560) Support injections in entry processors
[ https://issues.apache.org/jira/browse/IGNITE-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2560: Fix Version/s: (was: 1.6) 1.7 > Support injections in entry processors > -- > > Key: IGNITE-2560 > URL: https://issues.apache.org/jira/browse/IGNITE-2560 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Valentin Kulichenko >Assignee: Alexey Stelmak > Fix For: 1.7 > > > Currently resources are not injected in entry processor, which is not > consistent with other functionality, like closures, jobs, listeners, etc. > To avoid performance degradation we should introspect the class only once, > cache this information and do not try to inject if there are no annotations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2893) Atomic structures should not use transactions
[
https://issues.apache.org/jira/browse/IGNITE-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2893:
Fix Version/s: (was: 1.6)
1.7
> Atomic structures should not use transactions
> -
>
> Key: IGNITE-2893
> URL: https://issues.apache.org/jira/browse/IGNITE-2893
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Edouard Chevalier
> Labels: newbie
> Fix For: 1.7
>
>
> Currently atomic structures like {{AtomicReference}}, {{AtomicLong}} and
> others use transactional caches and explicit transactions under the hood.
> This seems redundant, because can be replaced with atomic cache and
> {{invoke}} operations with {{EntryProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2949) Replace JCache API dependency with Geronimo
[ https://issues.apache.org/jira/browse/IGNITE-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2949: Fix Version/s: (was: 1.6) 1.7 > Replace JCache API dependency with Geronimo > --- > > Key: IGNITE-2949 > URL: https://issues.apache.org/jira/browse/IGNITE-2949 > Project: Ignite > Issue Type: Task > Components: build >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Critical > Fix For: 1.7 > > > All JCache dependencies should be replaced with this one: > http://search.maven.org/#artifactdetails%7Corg.apache.geronimo.specs%7Cgeronimo-jcache_1.0_spec%7C1.0-alpha-1%7Cbundle -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2899:
Fix Version/s: (was: 1.6)
1.7
> BinaryObject is deserialized before getting passed to CacheInterceptor
> --
>
> Key: IGNITE-2899
> URL: https://issues.apache.org/jira/browse/IGNITE-2899
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
> Fix For: 1.7
>
> Attachments: BinaryInterceptorIssue.java,
> BinaryInterceptorNoTypeIssue.java
>
>
> If {{CacheInterceptor}} is configured for a cache that stores
> {{BinaryObjects}} then the objects are always deserialized before being
> passed to the interceptor body.
> Refer to BinaryInterceptorIssue test attached to the ticket to reproduce the
> following stack trace
> {noformat}
> java.lang.ClassCastException:
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidObject cannot be
> cast to org.apache.ignite.binary.BinaryObject
> at
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidationInterceptor.onBeforePut(BinaryInterceptorIssue.java:49)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2309)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2044)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1314)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:457)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.access$1400(GridNearAtomicUpdateFuture.java:72)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.map(GridNearAtomicUpdateFuture.java:931)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:283)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1006)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1004)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:737)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsync0(GridDhtAtomicCache.java:1004)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:465)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2491)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put(GridDhtAtomicCache.java:440)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2170)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1127)
> at
> org.apache.ignite.examples.tests.BinaryInterceptorIssue.main(BinaryInterceptorIssue.java:37)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Exception in thread "main"
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [1]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1577)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1931)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1134)
> at
> org.apache.ignite.examples.tests.BinaryInterceptorIssue.main(BinaryInterceptorIssue.java:37)
>
[jira] [Updated] (IGNITE-3004) Implement config variations test for ContinuousQueries
[ https://issues.apache.org/jira/browse/IGNITE-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Tikhonov updated IGNITE-3004: - Fix Version/s: (was: 1.6) 1.7 > Implement config variations test for ContinuousQueries > -- > > Key: IGNITE-3004 > URL: https://issues.apache.org/jira/browse/IGNITE-3004 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Nikolay Tikhonov >Priority: Blocker > Fix For: 1.7 > > > Need implement test for continuous qeries with configuration variations. > Make sure these points are covered (in addition to nodes number/cache modes > and configuration paramers variaions): > - different key/values types (see > IgniteConfigVariationsAbstractTest.runInAllDataModes) > - keepBinary mode > - with/without filters > - ContinuousQuery API and IgniteCache.registerCacheEntryListener > - async/sync listener and filter > - all cache update operations > - CacheEntryListenerConfiguration.isSynchronous true/false -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3056) Service implementation class is required even if it's not expected to be deployed on current node
[
https://issues.apache.org/jira/browse/IGNITE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-3056:
Fix Version/s: (was: 1.6)
1.7
> Service implementation class is required even if it's not expected to be
> deployed on current node
> -
>
> Key: IGNITE-3056
> URL: https://issues.apache.org/jira/browse/IGNITE-3056
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Artem Shutak
> Labels: community, customer, important
> Fix For: 1.7
>
>
> Currently the service instance is deserialized as part of
> {{GridServiceDeployment}} and {{GridServiceAssignment}} classes. Need to
> check if it's possible to deserialize only node filter first, and then
> deserialize the service itself only if needed. This will allow to use cluster
> groups with services and deploy the classes accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3040) Implement config variations test for IgniteMessaging
[ https://issues.apache.org/jira/browse/IGNITE-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3040: Fix Version/s: (was: 1.6) 1.7 > Implement config variations test for IgniteMessaging > > > Key: IGNITE-3040 > URL: https://issues.apache.org/jira/browse/IGNITE-3040 > Project: Ignite > Issue Type: Test > Components: messaging >Reporter: Semen Boikov >Assignee: Vladislav Pyatkov > Fix For: 1.7 > > > Need implement configuration variations test for IgniteMessaging (use > IgniteComputeConfigVariationsFullApiTest developed in IGNITE-3019 as example). > Test should cover following cases: > - all supported marshaller (Optimized, Binary, JDK) > - different data types for message topics, messages (see > IgniteConfigVariationsAbstractTest.runInAllDataModes) > - single server node > - multiple servers, multiple clients, send message from server->client, > client->client, client->server > - true/false for IgniteConfiguration.peerClassLoadingEnabled > - all 'sendXXX' method from IgniteMessaging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2997) Failed to get field because type ID of passed object differs from type ID this BinaryField
[
https://issues.apache.org/jira/browse/IGNITE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284504#comment-15284504
]
Denis Magda commented on IGNITE-2997:
-
Reproduced only in cases when there are several indexed types configured for a
cache.
> Failed to get field because type ID of passed object differs from type ID
> this BinaryField
> --
>
> Key: IGNITE-2997
> URL: https://issues.apache.org/jira/browse/IGNITE-2997
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Vladislav Pyatkov
> Attachments: Main2.java
>
>
> I have got this exception when had been developing cache load benchmark.
> This exception reproduced in configuration of cache:
> {code}
>
>
>
>
>
>
>
>
> java.lang.Integer
> org.apache.ignite.yardstick.cache.model.Organization
> java.lang.Integer
> org.apache.ignite.yardstick.cache.model.Person
>
>
>
> {code}
> {noformat}
> [18:00:39,708][ERROR][benchmark-worker-43][GridDhtAtomicCache]
> Unexpected exception during cache update
> class org.apache.ignite.binary.BinaryObjectException: Failed to get field
> because type ID of passed object differs from type ID this BinaryField
> belongs to [expected=-865473396, actual=1199651114]
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:92)
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:79)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$BinaryProperty.fieldValue(GridQueryProcessor.java:2051)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$BinaryProperty.value(GridQueryProcessor.java:2011)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.columnValue(IgniteH2Indexing.java:2498)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:289)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.compareRows(GridH2IndexBase.java:116)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:248)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:49)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1350)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1346)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2102)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
>
[jira] [Assigned] (IGNITE-2744) Optimize "unwindEvict" call in GridCacheIoManager.processMessage().
[ https://issues.apache.org/jira/browse/IGNITE-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh reassigned IGNITE-2744: Assignee: Semen Boikov (was: Ilya Lantukh) > Optimize "unwindEvict" call in GridCacheIoManager.processMessage(). > --- > > Key: IGNITE-2744 > URL: https://issues.apache.org/jira/browse/IGNITE-2744 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Semen Boikov >Priority: Critical > Labels: performance > Fix For: 1.6 > > > We call this method on every (!!!) received cache message. This call is > pretty heavy as it iterates over all caches. > We need to optimize it. E.g., check evicts only for the cache to which > received message belongs. And iterate over the whole set only if we know for > sure that several caches are affected (e.g. due to cross-cache TX). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak closed IGNITE-2921.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2969) Optimistic transactions support in deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura updated IGNITE-2969: Fix Version/s: (was: 1.6) 1.7 > Optimistic transactions support in deadlock detection > - > > Key: IGNITE-2969 > URL: https://issues.apache.org/jira/browse/IGNITE-2969 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrey Gura >Assignee: Andrey Gura > Fix For: 1.7 > > > Deadlock detection doesn't support optimistic transactions now. It should be > implemented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3144) Refactor Schema Import Utility. Split for two modules: schema-import and schema-import-db
[ https://issues.apache.org/jira/browse/IGNITE-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-3144. -- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Please test that Schema Import Utility works as expected in branch ignite-3144. An additional jar should appear: ignite-schema-import-db.jar > Refactor Schema Import Utility. Split for two modules: schema-import and > schema-import-db > - > > Key: IGNITE-3144 > URL: https://issues.apache.org/jira/browse/IGNITE-3144 > Project: Ignite > Issue Type: Task > Components: build >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov > Fix For: 1.6 > > > In order to reuse same code from Schema Import and Web console we need to > refactor ignite-schema-import module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov updated IGNITE-2921:
-
Assignee: Artem Shutak (was: Semen Boikov)
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2744) Optimize "unwindEvict" call in GridCacheIoManager.processMessage().
[ https://issues.apache.org/jira/browse/IGNITE-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-2744: - Assignee: Ilya Lantukh (was: Semen Boikov) > Optimize "unwindEvict" call in GridCacheIoManager.processMessage(). > --- > > Key: IGNITE-2744 > URL: https://issues.apache.org/jira/browse/IGNITE-2744 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Ilya Lantukh >Priority: Critical > Labels: performance > Fix For: 1.6 > > > We call this method on every (!!!) received cache message. This call is > pretty heavy as it iterates over all caches. > We need to optimize it. E.g., check evicts only for the cache to which > received message belongs. And iterate over the whole set only if we know for > sure that several caches are affected (e.g. due to cross-cache TX). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1223) Use Gson instead of net.sf.json-lib:json-lib:2.4
[ https://issues.apache.org/jira/browse/IGNITE-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-1223: - Fix Version/s: (was: 1.6) 1.7 > Use Gson instead of net.sf.json-lib:json-lib:2.4 > > > Key: IGNITE-1223 > URL: https://issues.apache.org/jira/browse/IGNITE-1223 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Evdokimov > Fix For: 1.7 > > Attachments: master_ae11e9b_ignite-1223.patch > > > Gson faster then "net.sf.json-lib:json-lib:2.4" 4 times. (Serialization of > GridRestCommand#NODE responce 2 times take 1,45 seconds with Gson and 5,8 > seconds with json-lib. Also json-lib cannot work with gridgain-style getters > and setters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2435) Integration with Mesos doesn't work with limited access to internet
[ https://issues.apache.org/jira/browse/IGNITE-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Tikhonov resolved IGNITE-2435. -- Resolution: Fixed > Integration with Mesos doesn't work with limited access to internet > --- > > Key: IGNITE-2435 > URL: https://issues.apache.org/jira/browse/IGNITE-2435 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.5.0.final >Reporter: Nikolay Tikhonov >Assignee: Nikolay Tikhonov > Fix For: 1.6 > > > Ignite Mesos integration doesn't work behind a firewall. Need to make all > external resources will customizable and avoid unnecessary accesses to web. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2435) Integration with Mesos doesn't work with limited access to internet
[ https://issues.apache.org/jira/browse/IGNITE-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Tikhonov closed IGNITE-2435. > Integration with Mesos doesn't work with limited access to internet > --- > > Key: IGNITE-2435 > URL: https://issues.apache.org/jira/browse/IGNITE-2435 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.5.0.final >Reporter: Nikolay Tikhonov >Assignee: Nikolay Tikhonov > Fix For: 1.6 > > > Ignite Mesos integration doesn't work behind a firewall. Need to make all > external resources will customizable and avoid unnecessary accesses to web. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1123) Instability and broken topology when multiple server and client nodes are restarted
[
https://issues.apache.org/jira/browse/IGNITE-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284450#comment-15284450
]
Lev commented on IGNITE-1123:
-
thanks, I will try that.
> Instability and broken topology when multiple server and client nodes are
> restarted
> ---
>
> Key: IGNITE-1123
> URL: https://issues.apache.org/jira/browse/IGNITE-1123
> Project: Ignite
> Issue Type: Sub-task
> Components: clients, general
>Affects Versions: sprint-7
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Labels: Muted_test
>
> The bug is always reproduced with
> TcpDiscoveryMultiThreadedTest.testMultiThreadedClientsServersRestart.
> The test starts multiple servers and clients and then restarts them from
> multiple thread. At some point it will lead to one or all of the following:
> 1) Broken topology on a client side:
> {noformat}
> java.lang.AssertionError: TcpDiscoveryNodeAddFinishedMessage
> [nodeId=70576075-b528-43f4-b490-33d079dc7007,
> super=TcpDiscoveryAbstractMessage [sndNodeId=null,
> id=8f7e19c8e41-10b88275-1868-4faf-9ae0-d61d627b1001,
> verifierNodeId=10b88275-1868-4faf-9ae0-d61d627b1001, topVer=89, pendingIdx=0,
> isClient=false]]
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.updateTopologyHistory(ClientImpl.java:589)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.access$2500(ClientImpl.java:48)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1370)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1227)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processClientReconnectMessage(ClientImpl.java:1552)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1235)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1197)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> 2) Clients segmentation that is not properly processed by
> GridCachePartionExchangeManager and that leads to the test hang:
> {noformat}
> Still waiting for initial partition map exchange
> [fut=GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false,
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=60b736c0-a2ad-4465-a3c1-7656e1fa9006, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:0], discPort=0, order=255, intOrder=0, loc=true,
> ver=1.4.1#19700101-sha1:, isClient=true], topVer=255,
> nodeId8=60b736c0, msg=null, type=NODE_JOINED, tstamp=1436877471568],
> rcvdIds=GridConcurrentHashSet
> [elements=[7098ffd9-f81b-40bf-9b9e-b0935d394007,
> 30b30924-a9e7-45fb-9aeb-361bbb482003, 00d7e953-ce8b-45e0-a1f3-be7a6dea1000,
> 301559de-a129-4b85-852f-f8325649f003, 7078cd7a-e6b9-4bed-b829-a2e792a0c007,
> 20de002e-7e98-4e55-b25f-d873e25db002, 00c444ad-b221-4695-9a6d-5ea529779000,
> 40dc3691-7b20-41d7-a436-65ad27f74004, 308f0e4a-507a-4da6-b086-bdecc08e1003,
> 20b1d488-7aa1-41d7-ac0b-e8730002, 00da0ab2-9441-4cc2-b787-c34dcf6a2000,
> 4096e7dd-e3fe-4704-9d11-3b267430e004, 1059ba84-4ca7-4d8f-9563-b90334d48001]],
> rmtIds=[30b30924-a9e7-45fb-9aeb-361bbb482003,
> 20de002e-7e98-4e55-b25f-d873e25db002, 4096e7dd-e3fe-4704-9d11-3b267430e004,
> 00c444ad-b221-4695-9a6d-5ea529779000], exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=255, minorTopVer=0], nodeId=60b736c0,
> evt=NODE_JOINED], init=true, ready=false, replied=false, added=true,
> initFut=GridFutureAdapter [resFlag=2, res=true, startTime=1436877471578,
> endTime=1436877471578, ignoreInterrupts=false, lsnr=null, state=DONE],
> topSnapshot=null, lastVer=null, partReleaseFut=null, skipPreload=true,
> clientOnlyExchange=true, oldest=20de002e-7e98-4e55-b25f-d873e25db002,
> oldestOrder=254, evtLatch=0, remaining=[], super=GridFutureAdapter
> [resFlag=0, res=null, startTime=1436877471578, endTime=0,
> ignoreInterrupts=false, lsnr=null, state=INIT]]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3098) UTF-16 surrogate pairs are not properly serialized by BinaryMarshaller
[
https://issues.apache.org/jira/browse/IGNITE-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-3098:
Description:
BinaryMarshaller is unable to properly serialize surrogate symbols (read here
[1] paragraph "invalid code points") because it relies on
{{String.getBytes("UTF-8")}} method [2].
However Optimized and JDK marshalers can properly handle this symbols since
they rely on {{ObjectOutputStream.writeUTF()}} method.
[1] https://en.wikipedia.org/wiki/UTF-8
[2] https://community.oracle.com/thread/1164397?start=0=0
was:
BinaryMarshaller is unable to properly serialize surrogate symbols (read here
[1] paragraph "invalid code points") because it relies on
String.getBytes("UTF-8") method [2].
However Optimized and JDK marshalers can properly handle this symbols since
they rely on {{ObjectOutputStream.writeUTF()}} method.
[1] https://en.wikipedia.org/wiki/UTF-8
[2] https://community.oracle.com/thread/1164397?start=0=0
> UTF-16 surrogate pairs are not properly serialized by BinaryMarshaller
> --
>
> Key: IGNITE-3098
> URL: https://issues.apache.org/jira/browse/IGNITE-3098
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
> Labels: important
> Attachments: StringTest.java
>
>
> BinaryMarshaller is unable to properly serialize surrogate symbols (read here
> [1] paragraph "invalid code points") because it relies on
> {{String.getBytes("UTF-8")}} method [2].
> However Optimized and JDK marshalers can properly handle this symbols since
> they rely on {{ObjectOutputStream.writeUTF()}} method.
> [1] https://en.wikipedia.org/wiki/UTF-8
> [2] https://community.oracle.com/thread/1164397?start=0=0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3144) Refactor Schema Import Utility. Split for two modules: schema-import and schema-import-db
Alexey Kuznetsov created IGNITE-3144: Summary: Refactor Schema Import Utility. Split for two modules: schema-import and schema-import-db Key: IGNITE-3144 URL: https://issues.apache.org/jira/browse/IGNITE-3144 Project: Ignite Issue Type: Task Components: build Affects Versions: 1.6 Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 1.6 In order to reuse same code from Schema Import and Web console we need to refactor ignite-schema-import module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1123) Instability and broken topology when multiple server and client nodes are restarted
[
https://issues.apache.org/jira/browse/IGNITE-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284421#comment-15284421
]
Lev commented on IGNITE-1123:
-
Any update on this issue, will it be fixed anytime soon?
> Instability and broken topology when multiple server and client nodes are
> restarted
> ---
>
> Key: IGNITE-1123
> URL: https://issues.apache.org/jira/browse/IGNITE-1123
> Project: Ignite
> Issue Type: Sub-task
> Components: clients, general
>Affects Versions: sprint-7
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Labels: Muted_test
>
> The bug is always reproduced with
> TcpDiscoveryMultiThreadedTest.testMultiThreadedClientsServersRestart.
> The test starts multiple servers and clients and then restarts them from
> multiple thread. At some point it will lead to one or all of the following:
> 1) Broken topology on a client side:
> {noformat}
> java.lang.AssertionError: TcpDiscoveryNodeAddFinishedMessage
> [nodeId=70576075-b528-43f4-b490-33d079dc7007,
> super=TcpDiscoveryAbstractMessage [sndNodeId=null,
> id=8f7e19c8e41-10b88275-1868-4faf-9ae0-d61d627b1001,
> verifierNodeId=10b88275-1868-4faf-9ae0-d61d627b1001, topVer=89, pendingIdx=0,
> isClient=false]]
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.updateTopologyHistory(ClientImpl.java:589)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.access$2500(ClientImpl.java:48)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1370)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1227)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processClientReconnectMessage(ClientImpl.java:1552)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1235)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1197)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> 2) Clients segmentation that is not properly processed by
> GridCachePartionExchangeManager and that leads to the test hang:
> {noformat}
> Still waiting for initial partition map exchange
> [fut=GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false,
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=60b736c0-a2ad-4465-a3c1-7656e1fa9006, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:0], discPort=0, order=255, intOrder=0, loc=true,
> ver=1.4.1#19700101-sha1:, isClient=true], topVer=255,
> nodeId8=60b736c0, msg=null, type=NODE_JOINED, tstamp=1436877471568],
> rcvdIds=GridConcurrentHashSet
> [elements=[7098ffd9-f81b-40bf-9b9e-b0935d394007,
> 30b30924-a9e7-45fb-9aeb-361bbb482003, 00d7e953-ce8b-45e0-a1f3-be7a6dea1000,
> 301559de-a129-4b85-852f-f8325649f003, 7078cd7a-e6b9-4bed-b829-a2e792a0c007,
> 20de002e-7e98-4e55-b25f-d873e25db002, 00c444ad-b221-4695-9a6d-5ea529779000,
> 40dc3691-7b20-41d7-a436-65ad27f74004, 308f0e4a-507a-4da6-b086-bdecc08e1003,
> 20b1d488-7aa1-41d7-ac0b-e8730002, 00da0ab2-9441-4cc2-b787-c34dcf6a2000,
> 4096e7dd-e3fe-4704-9d11-3b267430e004, 1059ba84-4ca7-4d8f-9563-b90334d48001]],
> rmtIds=[30b30924-a9e7-45fb-9aeb-361bbb482003,
> 20de002e-7e98-4e55-b25f-d873e25db002, 4096e7dd-e3fe-4704-9d11-3b267430e004,
> 00c444ad-b221-4695-9a6d-5ea529779000], exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=255, minorTopVer=0], nodeId=60b736c0,
> evt=NODE_JOINED], init=true, ready=false, replied=false, added=true,
> initFut=GridFutureAdapter [resFlag=2, res=true, startTime=1436877471578,
> endTime=1436877471578, ignoreInterrupts=false, lsnr=null, state=DONE],
> topSnapshot=null, lastVer=null, partReleaseFut=null, skipPreload=true,
> clientOnlyExchange=true, oldest=20de002e-7e98-4e55-b25f-d873e25db002,
> oldestOrder=254, evtLatch=0, remaining=[], super=GridFutureAdapter
> [resFlag=0, res=null, startTime=1436877471578, endTime=0,
> ignoreInterrupts=false, lsnr=null, state=INIT]]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2382) Force client mode in JDBC driver and provide default configuration file
[ https://issues.apache.org/jira/browse/IGNITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura closed IGNITE-2382. --- Assignee: (was: Andrey Gura) > Force client mode in JDBC driver and provide default configuration file > --- > > Key: IGNITE-2382 > URL: https://issues.apache.org/jira/browse/IGNITE-2382 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Gura >Priority: Minor > Fix For: 1.6 > > > # There is no reason to start server node during creation JDBC connection. So > client mode should be forced. > # If user didn't specify any configuration file in JDBC URL then default > configuration file should be used. > # Remove multicast IP finder from example because it is default IP finder. > Also need sample step-by-step guide with a sample configuration. This > configuration should include a couple of data types, like Person and > Organization, define indexes for them, etc. > This guide should include: > # Start Ignite Servers > # Populate data - should have example with configuration. > # Query data using JDBC driver - example code and, if needed, configuration > to support it. > See laso discussion here: > http://apache-ignite-developers.2346864.n4.nabble.com/What-is-jdbc-ignite-cfg-td5573.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3143) Implement support for executing Visor tasks via REST HTTP
[ https://issues.apache.org/jira/browse/IGNITE-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-3143. Assignee: (was: Alexey Kuznetsov) > Implement support for executing Visor tasks via REST HTTP > - > > Key: IGNITE-3143 > URL: https://issues.apache.org/jira/browse/IGNITE-3143 > Project: Ignite > Issue Type: Task > Components: clients >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov > Fix For: 1.6 > > > In order to execute Visor tasks via REST HTTP we need to implement special > JSON-to-Java and Java-to-JSON transformation logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3143) Implement support for executing Visor tasks via REST HTTP
[ https://issues.apache.org/jira/browse/IGNITE-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-3143. -- Resolution: Fixed Reviewed with Semyon. TC passed. Merged into ignite-1.6. > Implement support for executing Visor tasks via REST HTTP > - > > Key: IGNITE-3143 > URL: https://issues.apache.org/jira/browse/IGNITE-3143 > Project: Ignite > Issue Type: Task > Components: clients >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > > In order to execute Visor tasks via REST HTTP we need to implement special > JSON-to-Java and Java-to-JSON transformation logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3143) Implement support for executing Visor tasks via REST HTTP
Alexey Kuznetsov created IGNITE-3143: Summary: Implement support for executing Visor tasks via REST HTTP Key: IGNITE-3143 URL: https://issues.apache.org/jira/browse/IGNITE-3143 Project: Ignite Issue Type: Task Components: clients Affects Versions: 1.6 Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 1.6 In order to execute Visor tasks via REST HTTP we need to implement special JSON-to-Java and Java-to-JSON transformation logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2655) AffinityFunction: primary and backup copies in different locations
[
https://issues.apache.org/jira/browse/IGNITE-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-2655:
-
Assignee: Vladislav Pyatkov
> AffinityFunction: primary and backup copies in different locations
> --
>
> Key: IGNITE-2655
> URL: https://issues.apache.org/jira/browse/IGNITE-2655
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vladislav Pyatkov
>Priority: Critical
> Labels: important
> Fix For: 1.7
>
>
> There is a use case when primary and backup copies have to be located in
> different racks, building, cities, etc.
> A simple scenario is the following. When nodes are started they will have
> either "rack1" or "rack2" value in their attributes list and we will enforce
> that the backups won't be selected among the nodes with the same attribute.
> It should be possible to filter out backups using IP addresses as well.
> Presently rendezvous and fair affinity function has {{backupFilter}} that
> will work perfectly for the scenario above but only for cases when number of
> backups for a cache is equal to 1.
> In case when the number of backups is bigger than one {{backupFilter}} will
> only guarantee that the primary is located in different location but will NOT
> guarantee that all the backups are spread out across different locations as
> well.
> So we need to provide an API that will allow to spread the primary and ALL
> backups copies across different locations.
> The proposal is to introduce {{AffinityBackupFilter}} with the following
> method
> {{AffinityBackupFilter.isAssignable(Node n, List assigned)}}
> Where n - potential backup to check, assigned - list of current partition
> holders, 1st is primary
> {{AffinityBackupFilter}} will be set using
> {{affinity.setAffinityBackupFilter}}.
> {{Affinity.setBackupFilter}} has to be deprecated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3142) When remote filter is set, event is not send, if primary node has left grid.
[
https://issues.apache.org/jira/browse/IGNITE-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-3142:
--
Description:
If you try to start one server node and another then. After update of topology,
you can stop the first node and get the exception:
{noformat}
[12:25:25] (err) Failed to execute compound future reducer:
GridNearTxFinishFuture [futId=fbe41e8b451-b79beebc-da21-4cfc-a83e-e1cb4b34151b,
tx=GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl
[mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
[val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null, affKeyFieldName=null,
isEnum=false]], val2=[Ljava.lang.Object;@4807a494]], ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true,
entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
ver=GridCacheVersion [topVer=74870619, time=1463390725860, order=1463390656382,
nodeOrder=3], hash=887264644, extras=null, flags=0]]], prepared=0,
locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab, locMapped=false,
expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
serReadVer=null, xidVer=GridCacheVersion [topVer=74870619, time=1463390725845,
order=1463390656380, nodeOrder=3]]], explicitLock=false, dhtVer=null,
last=false, near=false, clientFirst=false,
node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], nearLocallyMapped=false,
colocatedLocallyMapped=false, needCheckBackup=false, hasRemoteLocks=false,
thread=sys-#20%null%, mappings=IgniteTxMappingsSingleImpl
[mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
[val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null, affKeyFieldName=null,
isEnum=false]], val2=[Ljava.lang.Object;@4807a494]], ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true,
entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
ver=GridCacheVersion [topVer=74870619, time=1463390725860, order=1463390656382,
nodeOrder=3], hash=887264644, extras=null, flags=0]]], prepared=0,
locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab, locMapped=false,
expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
serReadVer=null, xidVer=GridCacheVersion [topVer=74870619, time=1463390725845,
order=1463390656380, nodeOrder=3]]], explicitLock=false, dhtVer=null,
last=false, near=false, clientFirst=false,
node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], super=GridDhtTxLocalAdapter
[nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true],
super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=74870619,
time=1463390725845, order=1463390656380, nodeOrder=3], writeVer=null,
implicit=true, loc=true, threadId=32, startTime=1463390725843,
nodeId=df815072-615a-49d4-92e1-2842369ea15a, startVer=GridCacheVersion
[topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
endVer=null, isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0,
sysInvalidate=false, sys=true, plc=5, commitVer=GridCacheVersion
[topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
finalizing=NONE, preparing=false, invalidParts=null, state=PREPARED,
timedOut=false, topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1],
duration=50ms, onePhaseCommit=true], size=1]]], commit=true,
mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
[entries=[IgniteTxEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[typeId=887264644], hasValBytes=true], cacheId=-2100569601, partId=-1,
txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[jira] [Updated] (IGNITE-3142) When remote filter is set, event is not send, if primary node has left grid.
[
https://issues.apache.org/jira/browse/IGNITE-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-3142:
--
Summary: When remote filter is set, event is not send, if primary node has
left grid. (was: Do not send event when primary node has left grid.)
> When remote filter is set, event is not send, if primary node has left grid.
>
>
> Key: IGNITE-3142
> URL: https://issues.apache.org/jira/browse/IGNITE-3142
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
> Attachments: Ignite-Events - Copy.zip
>
>
> If you try to start one server node and another then. After update of
> topology, you can stop the first node and get the exception:
> {noformat}
> [12:25:25] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=fbe41e8b451-b79beebc-da21-4cfc-a83e-e1cb4b34151b, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
> [entries=[IgniteTxEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], cacheId=-2100569601, partId=-1,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], cacheId=-2100569601],
> val=[op=TRANSFORM, val=null], prevVal=[op=NOOP, val=null],
> entryProcessorsCol=[IgniteBiTuple [val1=MetadataProcessor
> [newMeta=BinaryMetadata [typeId=887264644,
> typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null,
> affKeyFieldName=null, isEnum=false]], val2=[Ljava.lang.Object;@4807a494]],
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
> ver=GridCacheVersion [topVer=74870619, time=1463390725860,
> order=1463390656382, nodeOrder=3], hash=887264644, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3]]], explicitLock=false,
> dhtVer=null, last=false, near=false, clientFirst=false,
> node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], nearLocallyMapped=false,
> colocatedLocallyMapped=false, needCheckBackup=false, hasRemoteLocks=false,
> thread=sys-#20%null%, mappings=IgniteTxMappingsSingleImpl
> [mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
> [key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
> hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
> hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
> prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
> [val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
> typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null,
> affKeyFieldName=null, isEnum=false]], val2=[Ljava.lang.Object;@4807a494]],
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
> ver=GridCacheVersion [topVer=74870619, time=1463390725860,
> order=1463390656382, nodeOrder=3], hash=887264644, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3]]], explicitLock=false,
> dhtVer=null, last=false, near=false, clientFirst=false,
> node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
> depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true],
> super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3], writeVer=null,
> implicit=true, loc=true, threadId=32, startTime=1463390725843,
> nodeId=df815072-615a-49d4-92e1-2842369ea15a, startVer=GridCacheVersion
> [topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
> endVer=null,
[jira] [Updated] (IGNITE-3139) .NET: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-3139:
---
Summary: .NET: UTF-16 surrogate symbols are not serialized properly (was:
.Net: UTF-16 surrogate symbols are not serialized properly)
> .NET: UTF-16 surrogate symbols are not serialized properly
> --
>
> Key: IGNITE-3139
> URL: https://issues.apache.org/jira/browse/IGNITE-3139
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> .Net serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3110) Incorrect error messages on SQL page
[ https://issues.apache.org/jira/browse/IGNITE-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-3110. -- Assignee: (was: Pavel Konstantinov) Tested. > Incorrect error messages on SQL page > > > Key: IGNITE-3110 > URL: https://issues.apache.org/jira/browse/IGNITE-3110 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov > Fix For: 1.6 > > Attachments: ig-3110.png > > > please ping me for help to reproduce this issue with my own demo grid -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2382) Force client mode in JDBC driver and provide default configuration file
[ https://issues.apache.org/jira/browse/IGNITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284373#comment-15284373 ] Semen Boikov commented on IGNITE-2382: -- Reviewed, good to merge. > Force client mode in JDBC driver and provide default configuration file > --- > > Key: IGNITE-2382 > URL: https://issues.apache.org/jira/browse/IGNITE-2382 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Gura >Assignee: Andrey Gura >Priority: Minor > Fix For: 1.6 > > > # There is no reason to start server node during creation JDBC connection. So > client mode should be forced. > # If user didn't specify any configuration file in JDBC URL then default > configuration file should be used. > # Remove multicast IP finder from example because it is default IP finder. > Also need sample step-by-step guide with a sample configuration. This > configuration should include a couple of data types, like Person and > Organization, define indexes for them, etc. > This guide should include: > # Start Ignite Servers > # Populate data - should have example with configuration. > # Query data using JDBC driver - example code and, if needed, configuration > to support it. > See laso discussion here: > http://apache-ignite-developers.2346864.n4.nabble.com/What-is-jdbc-ignite-cfg-td5573.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3115) List of ODBC minor issues
[
https://issues.apache.org/jira/browse/IGNITE-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284371#comment-15284371
]
Igor Sapego commented on IGNITE-3115:
-
Vladimir, here is the pull request - https://github.com/apache/ignite/pull/714.
I have no idea why did not git picked it up.
> List of ODBC minor issues
> -
>
> Key: IGNITE-3115
> URL: https://issues.apache.org/jira/browse/IGNITE-3115
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 1.6
> Environment: Ubuntu 14.04, Win7
>Reporter: Vasilisa Sidorova
>Assignee: Igor Sapego
>Priority: Minor
> Fix For: 1.6
>
>
> There is the list of minor issues for ODBC feature:
> 1. Win7:
> 1.1 install_amd64.cmd ODBC driver installator:
> 1.1.1 The final script output always is "32-bit driver can not be
> found: """. It's not necessary to find 32-bit driver. Please, fix it
> 1.2.1 It's possible to write path to the folder into registry. Please,
> add path-to-file validation into the script
> 1.2 Win Administrative Tools GUI:
> 1.2.1 DNS settings for Apache Ignite ODBC driver should be disabled (as
> this is not implemented yet)
> 1.3 Documentation:
> 1.3.1 Please, add information that odbc should be building individual
> into "Building binaries:" part of the IGNITE_HOME/platforms/cpp/DEVNOTES.txt
> 1.3.2 Please relocate instruction "Most likely you will need OS
> administrator privileges to execute these scripts." before run install script
> in the "Installing ODBC driver on Windows" part of the
> IGNITE_HOME/platforms/cpp/odbc/README.txt
> 2. Ubuntu - documentation:
> 2.1 It will be more user-friendly to mention that path to libignite-odbc.so
> should be in the LD_LIBRARY_PATH environment variable in the "Running
> examples on Linux" part of the IGNITE_HOME/platforms/cpp/examples/README.txt
> 2.2 The command
> {noformat}
> * libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> {noformat}
> is absent in the "Running examples on Linux" part of the
> IGNITE_HOME/platforms/cpp/examples/README.txt
> 3. Please, make the same changes in the documentation on the readme.io
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3142) Do not send event when primary node has left grid.
[
https://issues.apache.org/jira/browse/IGNITE-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-3142:
--
Attachment: (was: Ignite-Events - Copy.zip)
> Do not send event when primary node has left grid.
> --
>
> Key: IGNITE-3142
> URL: https://issues.apache.org/jira/browse/IGNITE-3142
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
> Attachments: Ignite-Events - Copy.zip
>
>
> If you try to start one server node and another then. After update of
> topology, you can stop the first node and get the exception:
> {noformat}
> [12:25:25] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=fbe41e8b451-b79beebc-da21-4cfc-a83e-e1cb4b34151b, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
> [entries=[IgniteTxEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], cacheId=-2100569601, partId=-1,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], cacheId=-2100569601],
> val=[op=TRANSFORM, val=null], prevVal=[op=NOOP, val=null],
> entryProcessorsCol=[IgniteBiTuple [val1=MetadataProcessor
> [newMeta=BinaryMetadata [typeId=887264644,
> typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null,
> affKeyFieldName=null, isEnum=false]], val2=[Ljava.lang.Object;@4807a494]],
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
> ver=GridCacheVersion [topVer=74870619, time=1463390725860,
> order=1463390656382, nodeOrder=3], hash=887264644, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3]]], explicitLock=false,
> dhtVer=null, last=false, near=false, clientFirst=false,
> node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], nearLocallyMapped=false,
> colocatedLocallyMapped=false, needCheckBackup=false, hasRemoteLocks=false,
> thread=sys-#20%null%, mappings=IgniteTxMappingsSingleImpl
> [mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
> [key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
> hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
> hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
> prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
> [val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
> typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null,
> affKeyFieldName=null, isEnum=false]], val2=[Ljava.lang.Object;@4807a494]],
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
> ver=GridCacheVersion [topVer=74870619, time=1463390725860,
> order=1463390656382, nodeOrder=3], hash=887264644, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3]]], explicitLock=false,
> dhtVer=null, last=false, near=false, clientFirst=false,
> node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
> depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true],
> super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3], writeVer=null,
> implicit=true, loc=true, threadId=32, startTime=1463390725843,
> nodeId=df815072-615a-49d4-92e1-2842369ea15a, startVer=GridCacheVersion
> [topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
> endVer=null, isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0,
> sysInvalidate=false, sys=true, plc=5, commitVer=GridCacheVersion
> [topVer=74870619,
[jira] [Updated] (IGNITE-3142) Do not send event when primary node has left grid.
[
https://issues.apache.org/jira/browse/IGNITE-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-3142:
--
Attachment: Ignite-Events - Copy.zip
> Do not send event when primary node has left grid.
> --
>
> Key: IGNITE-3142
> URL: https://issues.apache.org/jira/browse/IGNITE-3142
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
> Attachments: Ignite-Events - Copy.zip
>
>
> If you try to start one server node and another then. After update of
> topology, you can stop the first node and get the exception:
> {noformat}
> [12:25:25] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=fbe41e8b451-b79beebc-da21-4cfc-a83e-e1cb4b34151b, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
> [entries=[IgniteTxEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], cacheId=-2100569601, partId=-1,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], cacheId=-2100569601],
> val=[op=TRANSFORM, val=null], prevVal=[op=NOOP, val=null],
> entryProcessorsCol=[IgniteBiTuple [val1=MetadataProcessor
> [newMeta=BinaryMetadata [typeId=887264644,
> typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null,
> affKeyFieldName=null, isEnum=false]], val2=[Ljava.lang.Object;@4807a494]],
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
> ver=GridCacheVersion [topVer=74870619, time=1463390725860,
> order=1463390656382, nodeOrder=3], hash=887264644, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3]]], explicitLock=false,
> dhtVer=null, last=false, near=false, clientFirst=false,
> node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], nearLocallyMapped=false,
> colocatedLocallyMapped=false, needCheckBackup=false, hasRemoteLocks=false,
> thread=sys-#20%null%, mappings=IgniteTxMappingsSingleImpl
> [mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
> [key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
> hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
> hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
> prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
> [val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
> typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null,
> affKeyFieldName=null, isEnum=false]], val2=[Ljava.lang.Object;@4807a494]],
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
> ver=GridCacheVersion [topVer=74870619, time=1463390725860,
> order=1463390656382, nodeOrder=3], hash=887264644, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3]]], explicitLock=false,
> dhtVer=null, last=false, near=false, clientFirst=false,
> node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
> depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true],
> super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3], writeVer=null,
> implicit=true, loc=true, threadId=32, startTime=1463390725843,
> nodeId=df815072-615a-49d4-92e1-2842369ea15a, startVer=GridCacheVersion
> [topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
> endVer=null, isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0,
> sysInvalidate=false, sys=true, plc=5, commitVer=GridCacheVersion
> [topVer=74870619, time=1463390725845,
[jira] [Updated] (IGNITE-3142) Do not send event when primary node has left grid.
[
https://issues.apache.org/jira/browse/IGNITE-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-3142:
--
Description:
If you try to start one server node and another then. After update of topology,
you can stop the first node and get the exception:
{noformat}
[12:25:25] (err) Failed to execute compound future reducer:
GridNearTxFinishFuture [futId=fbe41e8b451-b79beebc-da21-4cfc-a83e-e1cb4b34151b,
tx=GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl
[mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
[val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null, affKeyFieldName=null,
isEnum=false]], val2=[Ljava.lang.Object;@4807a494]], ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true,
entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
ver=GridCacheVersion [topVer=74870619, time=1463390725860, order=1463390656382,
nodeOrder=3], hash=887264644, extras=null, flags=0]]], prepared=0,
locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab, locMapped=false,
expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
serReadVer=null, xidVer=GridCacheVersion [topVer=74870619, time=1463390725845,
order=1463390656380, nodeOrder=3]]], explicitLock=false, dhtVer=null,
last=false, near=false, clientFirst=false,
node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], nearLocallyMapped=false,
colocatedLocallyMapped=false, needCheckBackup=false, hasRemoteLocks=false,
thread=sys-#20%null%, mappings=IgniteTxMappingsSingleImpl
[mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
[val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null, affKeyFieldName=null,
isEnum=false]], val2=[Ljava.lang.Object;@4807a494]], ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true,
entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
ver=GridCacheVersion [topVer=74870619, time=1463390725860, order=1463390656382,
nodeOrder=3], hash=887264644, extras=null, flags=0]]], prepared=0,
locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab, locMapped=false,
expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
serReadVer=null, xidVer=GridCacheVersion [topVer=74870619, time=1463390725845,
order=1463390656380, nodeOrder=3]]], explicitLock=false, dhtVer=null,
last=false, near=false, clientFirst=false,
node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], super=GridDhtTxLocalAdapter
[nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true],
super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=74870619,
time=1463390725845, order=1463390656380, nodeOrder=3], writeVer=null,
implicit=true, loc=true, threadId=32, startTime=1463390725843,
nodeId=df815072-615a-49d4-92e1-2842369ea15a, startVer=GridCacheVersion
[topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
endVer=null, isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0,
sysInvalidate=false, sys=true, plc=5, commitVer=GridCacheVersion
[topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
finalizing=NONE, preparing=false, invalidParts=null, state=PREPARED,
timedOut=false, topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1],
duration=50ms, onePhaseCommit=true], size=1]]], commit=true,
mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
[entries=[IgniteTxEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[typeId=887264644], hasValBytes=true], cacheId=-2100569601, partId=-1,
txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[jira] [Updated] (IGNITE-3142) Do not send event when primary node has left grid.
[
https://issues.apache.org/jira/browse/IGNITE-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-3142:
--
Attachment: Ignite-Events - Copy.zip
> Do not send event when primary node has left grid.
> --
>
> Key: IGNITE-3142
> URL: https://issues.apache.org/jira/browse/IGNITE-3142
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
> Attachments: Ignite-Events - Copy.zip
>
>
> If you try to start one server node and another then. After update of
> topology, you can stop the first node and get the exception:
> {noformat}
> [12:25:25] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=fbe41e8b451-b79beebc-da21-4cfc-a83e-e1cb4b34151b, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
> [entries=[IgniteTxEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], cacheId=-2100569601, partId=-1,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], cacheId=-2100569601],
> val=[op=TRANSFORM, val=null], prevVal=[op=NOOP, val=null],
> entryProcessorsCol=[IgniteBiTuple [val1=MetadataProcessor
> [newMeta=BinaryMetadata [typeId=887264644,
> typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null,
> affKeyFieldName=null, isEnum=false]], val2=[Ljava.lang.Object;@4807a494]],
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
> ver=GridCacheVersion [topVer=74870619, time=1463390725860,
> order=1463390656382, nodeOrder=3], hash=887264644, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3]]], explicitLock=false,
> dhtVer=null, last=false, near=false, clientFirst=false,
> node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], nearLocallyMapped=false,
> colocatedLocallyMapped=false, needCheckBackup=false, hasRemoteLocks=false,
> thread=sys-#20%null%, mappings=IgniteTxMappingsSingleImpl
> [mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
> [key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
> hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
> hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
> prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
> [val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
> typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null,
> affKeyFieldName=null, isEnum=false]], val2=[Ljava.lang.Object;@4807a494]],
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
> [typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
> ver=GridCacheVersion [topVer=74870619, time=1463390725860,
> order=1463390656382, nodeOrder=3], hash=887264644, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3]]], explicitLock=false,
> dhtVer=null, last=false, near=false, clientFirst=false,
> node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
> depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true],
> super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=74870619,
> time=1463390725845, order=1463390656380, nodeOrder=3], writeVer=null,
> implicit=true, loc=true, threadId=32, startTime=1463390725843,
> nodeId=df815072-615a-49d4-92e1-2842369ea15a, startVer=GridCacheVersion
> [topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
> endVer=null, isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0,
> sysInvalidate=false, sys=true, plc=5, commitVer=GridCacheVersion
> [topVer=74870619, time=1463390725845,
[jira] [Created] (IGNITE-3142) Do not send event when primary node has left grid.
Vladislav Pyatkov created IGNITE-3142:
-
Summary: Do not send event when primary node has left grid.
Key: IGNITE-3142
URL: https://issues.apache.org/jira/browse/IGNITE-3142
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
If you try to start one server node and another then. After update of topology,
you can stop the first node and get the exception:
{noformat}
[12:25:25] (err) Failed to execute compound future reducer:
GridNearTxFinishFuture [futId=fbe41e8b451-b79beebc-da21-4cfc-a83e-e1cb4b34151b,
tx=GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl
[mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
[val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null, affKeyFieldName=null,
isEnum=false]], val2=[Ljava.lang.Object;@4807a494]], ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true,
entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
ver=GridCacheVersion [topVer=74870619, time=1463390725860, order=1463390656382,
nodeOrder=3], hash=887264644, extras=null, flags=0]]], prepared=0,
locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab, locMapped=false,
expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
serReadVer=null, xidVer=GridCacheVersion [topVer=74870619, time=1463390725845,
order=1463390656380, nodeOrder=3]]], explicitLock=false, dhtVer=null,
last=false, near=false, clientFirst=false,
node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], nearLocallyMapped=false,
colocatedLocallyMapped=false, needCheckBackup=false, hasRemoteLocks=false,
thread=sys-#20%null%, mappings=IgniteTxMappingsSingleImpl
[mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
[key=KeyCacheObjectImpl [val=BinaryMetadataKey [typeId=887264644],
hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
prevVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
[val1=MetadataProcessor [newMeta=BinaryMetadata [typeId=887264644,
typeName=org.jsr166.ConcurrentLinkedDeque8, fields=null, affKeyFieldName=null,
isEnum=false]], val2=[Ljava.lang.Object;@4807a494]], ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true,
entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[typeId=887264644], hasValBytes=true], val=null, startVer=1463390656382,
ver=GridCacheVersion [topVer=74870619, time=1463390725860, order=1463390656382,
nodeOrder=3], hash=887264644, extras=null, flags=0]]], prepared=0,
locked=false, nodeId=5f3be800-b89a-419b-8d7e-ba5adbb36fab, locMapped=false,
expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
serReadVer=null, xidVer=GridCacheVersion [topVer=74870619, time=1463390725845,
order=1463390656380, nodeOrder=3]]], explicitLock=false, dhtVer=null,
last=false, near=false, clientFirst=false,
node=5f3be800-b89a-419b-8d7e-ba5adbb36fab]], super=GridDhtTxLocalAdapter
[nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true],
super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=74870619,
time=1463390725845, order=1463390656380, nodeOrder=3], writeVer=null,
implicit=true, loc=true, threadId=32, startTime=1463390725843,
nodeId=df815072-615a-49d4-92e1-2842369ea15a, startVer=GridCacheVersion
[topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
endVer=null, isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0,
sysInvalidate=false, sys=true, plc=5, commitVer=GridCacheVersion
[topVer=74870619, time=1463390725845, order=1463390656380, nodeOrder=3],
finalizing=NONE, preparing=false, invalidParts=null, state=PREPARED,
timedOut=false, topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1],
duration=50ms, onePhaseCommit=true], size=1]]], commit=true,
mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
[entries=[IgniteTxEntry [key=KeyCacheObjectImpl [val=BinaryMetadataKey
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284309#comment-15284309
]
Semen Boikov commented on IGNITE-2921:
--
Reviewed, did some minor changes, good to merge.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Semen Boikov
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3139) .Net: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3139:
Fix Version/s: 1.6
> .Net: UTF-16 surrogate symbols are not serialized properly
> --
>
> Key: IGNITE-3139
> URL: https://issues.apache.org/jira/browse/IGNITE-3139
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> .Net serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3140) C++: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3140:
Component/s: platforms
> C++: UTF-16 surrogate symbols are not serialized properly
> -
>
> Key: IGNITE-3140
> URL: https://issues.apache.org/jira/browse/IGNITE-3140
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> C++ serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3140) C++: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3140:
Fix Version/s: 1.6
> C++: UTF-16 surrogate symbols are not serialized properly
> -
>
> Key: IGNITE-3140
> URL: https://issues.apache.org/jira/browse/IGNITE-3140
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> C++ serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3139) .Net: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3139:
Component/s: platforms
> .Net: UTF-16 surrogate symbols are not serialized properly
> --
>
> Key: IGNITE-3139
> URL: https://issues.apache.org/jira/browse/IGNITE-3139
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> .Net serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3112) .NET: Allow merging Spring XML config with .NET config
[ https://issues.apache.org/jira/browse/IGNITE-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3112. --- > .NET: Allow merging Spring XML config with .NET config > -- > > Key: IGNITE-3112 > URL: https://issues.apache.org/jira/browse/IGNITE-3112 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.6 > > > Currently we ignore most IgniteConfiguration properties if SpringConfigUrl is > set. > So if there is even one property not propagated to .NET, user has to switch > completely to Spring XML, which may be quite tragic, especially for query > entity configurations. > Instead, we can merge configs on the top level: > First, we load Spring XML. Then we apply non-null .NET properties on top of > it. > Primitive properties should be made nullable underneath to track whether user > has set them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3141) IgnitePartitionedLockSelfTest fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov updated IGNITE-3141:
-
Assignee: Yakov Zhdanov
> IgnitePartitionedLockSelfTest fails on TC
> -
>
> Key: IGNITE-3141
> URL: https://issues.apache.org/jira/browse/IGNITE-3141
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Semen Boikov
>Assignee: Yakov Zhdanov
>Priority: Critical
> Fix For: 1.7
>
>
> IgnitePartitionedLockSelfTest fails from time to time on TC.
> Example of failed run:
> http://149.202.210.143:8111/viewLog.html?buildId=243004=buildResultsDiv=IgniteTests_IgniteBinaryObjectsDataStrucutures
> IgnitePartitionedLockSelfTest.testConditionAwaitUninterruptibly. Hang:
> {noformat}
> Thread
> [name="test-runner-#116519%partitioned.IgnitePartitionedLockSelfTest%",
> id=155625, state=WAITING, blockCnt=0, waitCnt=6]
> Lock [object=o.a.i.i.util.future.GridCompoundFuture@4b9dffc6,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at
> o.a.i.i.processors.cache.datastructures.IgniteLockAbstractSelfTest.testConditionAwaitUninterruptibly(IgniteLockAbstractSelfTest.java:1233)
> at
> o.a.i.i.processors.cache.datastructures.IgniteLockAbstractSelfTest.testConditionAwaitUninterruptibly(IgniteLockAbstractSelfTest.java:1158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
> at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> IgnitePartitionedLockSelfTest.testConditionInterruptAwait
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.cache.datastructures.IgniteLockAbstractSelfTest.testConditionInterruptAwait(IgniteLockAbstractSelfTest.java:1260)
> at
> org.apache.ignite.internal.processors.cache.datastructures.IgniteLockAbstractSelfTest.testConditionInterruptAwait(IgniteLockAbstractSelfTest.java:1247)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
> {noformat}
> IgnitePartitionedLockSelfTest.testHasConditionQueuedThreads:
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.cache.datastructures.IgniteLockAbstractSelfTest.testHasConditionQueuedThreads(IgniteLockAbstractSelfTest.java:1416)
>
[jira] [Created] (IGNITE-3141) IgnitePartitionedLockSelfTest fails on TC
Semen Boikov created IGNITE-3141:
Summary: IgnitePartitionedLockSelfTest fails on TC
Key: IGNITE-3141
URL: https://issues.apache.org/jira/browse/IGNITE-3141
Project: Ignite
Issue Type: Bug
Components: data structures
Reporter: Semen Boikov
Priority: Critical
Fix For: 1.7
IgnitePartitionedLockSelfTest fails from time to time on TC.
Example of failed run:
http://149.202.210.143:8111/viewLog.html?buildId=243004=buildResultsDiv=IgniteTests_IgniteBinaryObjectsDataStrucutures
IgnitePartitionedLockSelfTest.testConditionAwaitUninterruptibly. Hang:
{noformat}
Thread [name="test-runner-#116519%partitioned.IgnitePartitionedLockSelfTest%",
id=155625, state=WAITING, blockCnt=0, waitCnt=6]
Lock [object=o.a.i.i.util.future.GridCompoundFuture@4b9dffc6,
ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
at
o.a.i.i.processors.cache.datastructures.IgniteLockAbstractSelfTest.testConditionAwaitUninterruptibly(IgniteLockAbstractSelfTest.java:1233)
at
o.a.i.i.processors.cache.datastructures.IgniteLockAbstractSelfTest.testConditionAwaitUninterruptibly(IgniteLockAbstractSelfTest.java:1158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
at
o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at
o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
at java.lang.Thread.run(Thread.java:745)
{noformat}
IgnitePartitionedLockSelfTest.testConditionInterruptAwait
{noformat}
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertFalse(Assert.java:39)
at junit.framework.Assert.assertFalse(Assert.java:47)
at junit.framework.TestCase.assertFalse(TestCase.java:219)
at
org.apache.ignite.internal.processors.cache.datastructures.IgniteLockAbstractSelfTest.testConditionInterruptAwait(IgniteLockAbstractSelfTest.java:1260)
at
org.apache.ignite.internal.processors.cache.datastructures.IgniteLockAbstractSelfTest.testConditionInterruptAwait(IgniteLockAbstractSelfTest.java:1247)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
{noformat}
IgnitePartitionedLockSelfTest.testHasConditionQueuedThreads:
{noformat}
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertFalse(Assert.java:39)
at junit.framework.Assert.assertFalse(Assert.java:47)
at junit.framework.TestCase.assertFalse(TestCase.java:219)
at
org.apache.ignite.internal.processors.cache.datastructures.IgniteLockAbstractSelfTest.testHasConditionQueuedThreads(IgniteLockAbstractSelfTest.java:1416)
at
org.apache.ignite.internal.processors.cache.datastructures.IgniteLockAbstractSelfTest.testHasConditionQueuedThreads(IgniteLockAbstractSelfTest.java:1403)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
[jira] [Closed] (IGNITE-3118) .NET: CacheConfiguration.EvictionPolicy
[ https://issues.apache.org/jira/browse/IGNITE-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3118. --- > .NET: CacheConfiguration.EvictionPolicy > --- > > Key: IGNITE-3118 > URL: https://issues.apache.org/jira/browse/IGNITE-3118 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > Propagate CacheConfiguration.EvictionPolicy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3130) .NET: TcpDiscoverySpi missing properties
[ https://issues.apache.org/jira/browse/IGNITE-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3130. --- > .NET: TcpDiscoverySpi missing properties > > > Key: IGNITE-3130 > URL: https://issues.apache.org/jira/browse/IGNITE-3130 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > localPort, localAddress, etc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3140) C++: UTF-16 surrogate symbols are not serialized properly
Denis Magda created IGNITE-3140:
---
Summary: C++: UTF-16 surrogate symbols are not serialized properly
Key: IGNITE-3140
URL: https://issues.apache.org/jira/browse/IGNITE-3140
Project: Ignite
Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Denis Magda
There is an issue with serialization of a surrogate symbol with
{{BinaryMarshaller}}. On Java side String's serialization logic was improved to
support all the cases. Refer to IGNITE-3098.
C++ serialization logic has to be updated as well. Please refer to the
algorithm located in ignite-3098 branch in the following places:
- {{BinaryUtils.utf8BytesToStr}} - serialization
- {{BinaryUtils.strToUtf8Bytes}} - deserialization
-
{{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3140) C++: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-3140:
Assignee: Igor Sapego
> C++: UTF-16 surrogate symbols are not serialized properly
> -
>
> Key: IGNITE-3140
> URL: https://issues.apache.org/jira/browse/IGNITE-3140
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Igor Sapego
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> C++ serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3139) .Net: UTF-16 surrogate symbols are not serialized properly
[
https://issues.apache.org/jira/browse/IGNITE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-3139:
Affects Version/s: 1.5.0.final
> .Net: UTF-16 surrogate symbols are not serialized properly
> --
>
> Key: IGNITE-3139
> URL: https://issues.apache.org/jira/browse/IGNITE-3139
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
>
> There is an issue with serialization of a surrogate symbol with
> {{BinaryMarshaller}}. On Java side String's serialization logic was improved
> to support all the cases. Refer to IGNITE-3098.
> .Net serialization logic has to be updated as well. Please refer to the
> algorithm located in ignite-3098 branch in the following places:
> - {{BinaryUtils.utf8BytesToStr}} - serialization
> - {{BinaryUtils.strToUtf8Bytes}} - deserialization
> -
> {{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
> controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3139) .Net: UTF-16 surrogate symbols are not serialized properly
Denis Magda created IGNITE-3139:
---
Summary: .Net: UTF-16 surrogate symbols are not serialized properly
Key: IGNITE-3139
URL: https://issues.apache.org/jira/browse/IGNITE-3139
Project: Ignite
Issue Type: Bug
Reporter: Denis Magda
Assignee: Pavel Tupitsyn
There is an issue with serialization of a surrogate symbol with
{{BinaryMarshaller}}. On Java side String's serialization logic was improved to
support all the cases. Refer to IGNITE-3098.
.Net serialization logic has to be updated as well. Please refer to the
algorithm located in ignite-3098 branch in the following places:
- {{BinaryUtils.utf8BytesToStr}} - serialization
- {{BinaryUtils.strToUtf8Bytes}} - deserialization
-
{{IgniteSystemProperties.IGNITE_BINARY_MARSHALLER_USE_STRING_SERIALIZATION_VER_2}}
controls which version of serialization logic to use (old or new).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2047) Improvements for Ignite Web Console for next releases
[ https://issues.apache.org/jira/browse/IGNITE-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-2047: --- Summary: Improvements for Ignite Web Console for next releases (was: Improvements for Ignite Web Console for next release) > Improvements for Ignite Web Console for next releases > - > > Key: IGNITE-2047 > URL: https://issues.apache.org/jira/browse/IGNITE-2047 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Konstantinov > Fix For: 1.7 > > > This is a parent ticket for future improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2047) Improvements for Ignite Web Console for next release
[ https://issues.apache.org/jira/browse/IGNITE-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-2047: --- Summary: Improvements for Ignite Web Console for next release (was: Improvements for Ignite Web Console for 1.6) > Improvements for Ignite Web Console for next release > > > Key: IGNITE-2047 > URL: https://issues.apache.org/jira/browse/IGNITE-2047 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Konstantinov > Fix For: 1.7 > > > This is a parent ticket for future improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3090) Memory leak in IgniteH2Indexing prepared statements cache
[
https://issues.apache.org/jira/browse/IGNITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov closed IGNITE-3090.
> Memory leak in IgniteH2Indexing prepared statements cache
> --
>
> Key: IGNITE-3090
> URL: https://issues.apache.org/jira/browse/IGNITE-3090
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
> Labels: community, important
> Fix For: 1.6
>
>
> IgniteH2Indexing caches prepared statements in {{stmtCache}} that uses
> Threads as keys. Under they high load when there are many Threads the cache
> can grow significantly. Plus if a Thread is terminated its prepared
> statements are not get cleaned introducing a memory leak.
> A special background Thread should be introduced that will iterate over
> {{stmCache}} performing the following:
> - cleaning records for terminated Threads;
> - cleaning records of the Threads that were not used for a long time. A
> special configuration parameter can be set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-3134) Unexpected EVT_CACHE_ENTRY_EVICTED events in OFFHEAP_TIERED mode
[
https://issues.apache.org/jira/browse/IGNITE-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov resolved IGNITE-3134.
---
Resolution: Won't Fix
Eviction policy configuration doesn't make sense for OFFHEAP_TIERED mode
> Unexpected EVT_CACHE_ENTRY_EVICTED events in OFFHEAP_TIERED mode
>
>
> Key: IGNITE-3134
> URL: https://issues.apache.org/jira/browse/IGNITE-3134
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.7
>
>
> EVT_CACHE_ENTRY_EVICTED event is triggered on any cache operation in this
> mode.
> Code sample:
> {code}
> IgnitePredicate lsnr = new IgnitePredicate() {
> @Override public boolean apply(CacheEvent evt) {
> counter.incrementAndGet();
> return true; // Return true to continue listening.
> }
> };
> CacheConfiguration cfg = new CacheConfiguration<>();
> cfg.setMemoryMode(CacheMemoryMode.OFFHEAP_TIERED);
> cfg.setEvictionPolicy(new FifoEvictionPolicy<>(1));
> IgniteCache test = ignite.getOrCreateCache(cfg);
> // Register event listener for all local task execution events.
> ignite.events().localListen(lsnr, EVT_CACHE_ENTRY_EVICTED);
> test.put("1", "1");
> test.put("2", "2");
> test.put("3", "3");
> Object o = test.get("2");
> System.out.println(counter.get());
> {code}
> will print 4
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3134) Unexpected EVT_CACHE_ENTRY_EVICTED events in OFFHEAP_TIERED mode
[
https://issues.apache.org/jira/browse/IGNITE-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov closed IGNITE-3134.
-
> Unexpected EVT_CACHE_ENTRY_EVICTED events in OFFHEAP_TIERED mode
>
>
> Key: IGNITE-3134
> URL: https://issues.apache.org/jira/browse/IGNITE-3134
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.7
>
>
> EVT_CACHE_ENTRY_EVICTED event is triggered on any cache operation in this
> mode.
> Code sample:
> {code}
> IgnitePredicate lsnr = new IgnitePredicate() {
> @Override public boolean apply(CacheEvent evt) {
> counter.incrementAndGet();
> return true; // Return true to continue listening.
> }
> };
> CacheConfiguration cfg = new CacheConfiguration<>();
> cfg.setMemoryMode(CacheMemoryMode.OFFHEAP_TIERED);
> cfg.setEvictionPolicy(new FifoEvictionPolicy<>(1));
> IgniteCache test = ignite.getOrCreateCache(cfg);
> // Register event listener for all local task execution events.
> ignite.events().localListen(lsnr, EVT_CACHE_ENTRY_EVICTED);
> test.put("1", "1");
> test.put("2", "2");
> test.put("3", "3");
> Object o = test.get("2");
> System.out.println(counter.get());
> {code}
> will print 4
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3138) IgniteDataStreamer: failures are not shown on the streaming side
Denis Magda created IGNITE-3138: --- Summary: IgniteDataStreamer: failures are not shown on the streaming side Key: IGNITE-3138 URL: https://issues.apache.org/jira/browse/IGNITE-3138 Project: Ignite Issue Type: Bug Reporter: Denis Magda If an exception happens during the streaming, the side that streams the data won't printed out anything in its logs even if IGNITE_QUIET set to false. This makes it's inconvenient to see whether there an issue happened during the streaming or not. Suggested improvements: - print out errors that happened during the streaming on the streaming side; - give an ability to register a callback that will be executed in case of error so that the user code can decide whether it makes sense to proceed with the streaming or not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2528) Deadlocks caused by Ignite.close()
[
https://issues.apache.org/jira/browse/IGNITE-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov reassigned IGNITE-2528:
-
Assignee: Alexei Scherbakov (was: Denis Magda)
> Deadlocks caused by Ignite.close()
> --
>
> Key: IGNITE-2528
> URL: https://issues.apache.org/jira/browse/IGNITE-2528
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
> Fix For: 1.7
>
>
> If to start stopping an Ignite instance and execute {{cluster.nodes()}} from
> an {{EntryProcessor}} or some other place of the code that holds a lock on
> cache's gateway then this can lead to the deadlock:
> Ignite.close:
> - holds kernel.gateway lock;
> - tries to get a gateway lock on cache A;
> Entry.processor is called for cache A:
> - a gateway lock is acquired for cache A;
> - calling {{cluster.nodes()}};
> - trying to acquire kernel's gateway lock.
> To fix this deadlock we can do the following:
> - introduce a volatile variable that has to be set to 'true' when a node is
> being stopped;
> - check this variable before acquiring kernel's gateway.
> Also probably it makes sense to try to use try lock here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3137) IgniteDataStreamer silently hangs if exception happens on a remote side
[ https://issues.apache.org/jira/browse/IGNITE-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3137: Attachment: CacheDataStreamerExample.java ExampleNodeStartup.java To reproduce: - Start ExampleNodeStartup - Start modified CacheDataStreamerExample > IgniteDataStreamer silently hangs if exception happens on a remote side > --- > > Key: IGNITE-3137 > URL: https://issues.apache.org/jira/browse/IGNITE-3137 > Project: Ignite > Issue Type: Bug >Reporter: Denis Magda > Fix For: 1.7 > > Attachments: CacheDataStreamerExample.java, ExampleNodeStartup.java > > > If an exception happens on a remote side during the streaming > IgniteDataStreamer can either not receive an ack for a sent batch or not > process an error response properly on a streaming side. > This will lead to the situation that the side that does streaming will hang > indefinitely. > Attaching a simple code that reproduces the issue. Please note that exception > can be of other kind. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3137) IgniteDataStreamer silently hangs if exception happens on a remote side
Denis Magda created IGNITE-3137: --- Summary: IgniteDataStreamer silently hangs if exception happens on a remote side Key: IGNITE-3137 URL: https://issues.apache.org/jira/browse/IGNITE-3137 Project: Ignite Issue Type: Bug Reporter: Denis Magda Fix For: 1.7 If an exception happens on a remote side during the streaming IgniteDataStreamer can either not receive an ack for a sent batch or not process an error response properly on a streaming side. This will lead to the situation that the side that does streaming will hang indefinitely. Attaching a simple code that reproduces the issue. Please note that exception can be of other kind. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3116) Cancel force key futures when node stops
[ https://issues.apache.org/jira/browse/IGNITE-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov closed IGNITE-3116. Assignee: (was: Semen Boikov) > Cancel force key futures when node stops > > > Key: IGNITE-3116 > URL: https://issues.apache.org/jira/browse/IGNITE-3116 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov > Fix For: 1.6 > > > When node stops need cancel GridDhtForceKeysFutures (like all others cache > futures) to prevent potential hangs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3116) Cancel force key futures when node stops
[ https://issues.apache.org/jira/browse/IGNITE-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov resolved IGNITE-3116. -- Resolution: Fixed Fix Version/s: (was: 1.7) 1.6 Fixed in ignite-1.6 (commit db8a9b2). > Cancel force key futures when node stops > > > Key: IGNITE-3116 > URL: https://issues.apache.org/jira/browse/IGNITE-3116 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 1.6 > > > When node stops need cancel GridDhtForceKeysFutures (like all others cache > futures) to prevent potential hangs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
