[jira] [Created] (IGNITE-5907) Add validation to Basic screen for Off-heap size
Pavel Konstantinov created IGNITE-5907: -- Summary: Add validation to Basic screen for Off-heap size Key: IGNITE-5907 URL: https://issues.apache.org/jira/browse/IGNITE-5907 Project: Ignite Issue Type: Bug Affects Versions: 2.1 Reporter: Pavel Konstantinov Fix For: 2.2 Off-heap size must be greater then initial off-heap size -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5907) Web console: Add validation to Basic screen for Off-heap size
[ https://issues.apache.org/jira/browse/IGNITE-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-5907: --- Summary: Web console: Add validation to Basic screen for Off-heap size (was: Add validation to Basic screen for Off-heap size) > Web console: Add validation to Basic screen for Off-heap size > - > > Key: IGNITE-5907 > URL: https://issues.apache.org/jira/browse/IGNITE-5907 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Pavel Konstantinov > Fix For: 2.2 > > > Off-heap size must be greater then initial off-heap size -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5906) Web Console backend failed with error 11000
[ https://issues.apache.org/jira/browse/IGNITE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112116#comment-16112116 ] Andrey Novikov edited comment on IGNITE-5906 at 8/3/17 3:26 AM: Fixed race in activities merge operation. [~kuaw26], please confirm fix. was (Author: anovikov): Fixed race in activities merge operation. > Web Console backend failed with error 11000 > --- > > Key: IGNITE-5906 > URL: https://issues.apache.org/jira/browse/IGNITE-5906 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.2 >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5902) Refactor VisorCacheStopTask to support stopping several caches at once
[ https://issues.apache.org/jira/browse/IGNITE-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-5902: Assignee: Andrey Novikov (was: Alexey Kuznetsov) Please, review > Refactor VisorCacheStopTask to support stopping several caches at once > --- > > Key: IGNITE-5902 > URL: https://issues.apache.org/jira/browse/IGNITE-5902 > Project: Ignite > Issue Type: Improvement > Components: wizards >Affects Versions: 2.1 >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > Fix For: 2.2 > > > Stopping several caches at once much more faster then one-by-one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions
[
https://issues.apache.org/jira/browse/IGNITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110663#comment-16110663
]
Alexandr Fedotov edited comment on IGNITE-4172 at 8/2/17 8:15 PM:
--
Apart from the improvements introduced by
[IGNITE-5483|https://issues.apache.org/jira/browse/IGNITE-5483] the following
should be addressed:
1. {{java.time.LocalTime}}, {{java.time.LocalDate}},
{{java.time.LocalDateTime}} are not supported as cache values or keys.
2. {{java.time.LocalTime}} is stored as {{java.sql.Time}},
{{java.time.LocalDate}} as {{java.sql.Date}}, {{LocalDateTime}} as
{{Timestamp}}.
Having, for example, {{IgniteCache}} where {{Person}} has a
{{java.time.LocalDateTime}} field, trying to select that field with a query like
{code:sql}select locDateTime from Person{code}
will return {{java.sql.Timestamp}} value.
was (Author: asfedotov):
Apart from the improvements introduced by
[IGNITE-5483|https://issues.apache.org/jira/browse/IGNITE-5483] the following
should be addressed:
1. {{java.time.LocalTime}}, {{java.time.LocalDate}},
{{java.time.LocalDateTime}} are not supported as cache values or keys.
2. {{java.time.LocalTime}} is stored as {{java.sql.Time}},
{{java.time.LocalDate}} as {{java.sql.Date}}, {{LocalDateTime}} as
{{Timestamp}}.
Having, for example, {{IgniteCache}} where {{Person}} has a
{{java.time.LocalDateTime}} field, trying to select that field with a query like
{{select locDateTime from Person}} will return {{java.sql.Timestamp}} value.
> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
> Fix For: 2.2
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine.
> Next query can fails with error, if one of row localDateTimeField value has
> zero-time:
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method.
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions
[
https://issues.apache.org/jira/browse/IGNITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110663#comment-16110663
]
Alexandr Fedotov edited comment on IGNITE-4172 at 8/2/17 8:13 PM:
--
Apart from the improvements introduced by
[IGNITE-5483|https://issues.apache.org/jira/browse/IGNITE-5483] the following
should be addressed:
1. {{java.time.LocalTime}}, {{java.time.LocalDate}},
{{java.time.LocalDateTime}} are not supported as cache values or keys.
2. {{java.time.LocalTime}} is stored as {{java.sql.Time}},
{{java.time.LocalDate}} as {{java.sql.Date}}, {{LocalDateTime}} as
{{Timestamp}}.
Having, for example, {{IgniteCache}} where {{Person}} has a
{{java.time.LocalDateTime}} field, trying to select that field with a query like
{{select locDateTime from Person}} will return {{java.sql.Timestamp}} value.
was (Author: asfedotov):
Apart from the improvements introduced by
[IGNITE-5483|https://issues.apache.org/jira/browse/IGNITE-5483] the following
should be addressed:
1. {{java.time.LocalTime}}, {{java.time.LocalDate}},
{{java.time.LocalDateTime}} are not supported as cache values or keys.
2. {{java.time.LocalTime}} is stored as {{java.sql.Time}},
{{java.time.LocalDate}} as {{java.sql.Date}}, {{LocalDateTime}} as
{{Timestamp}}.
Having, for example, {{IgniteCache}} where {{Person}} has a
{{java.time.LocalDateTime}} field, trying to select that field with a query
like {{select locDateTime from Person}} will return {{java.sql.Timestamp}}
value.
> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
> Fix For: 2.2
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine.
> Next query can fails with error, if one of row localDateTimeField value has
> zero-time:
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method.
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions
[
https://issues.apache.org/jira/browse/IGNITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110663#comment-16110663
]
Alexandr Fedotov edited comment on IGNITE-4172 at 8/2/17 8:12 PM:
--
Apart from the improvements introduced by
[IGNITE-5483|https://issues.apache.org/jira/browse/IGNITE-5483] the following
should be addressed:
1. {{java.time.LocalTime}}, {{java.time.LocalDate}},
{{java.time.LocalDateTime}} are not supported as cache values or keys.
2. {{java.time.LocalTime}} is stored as {{java.sql.Time}},
{{java.time.LocalDate}} as {{java.sql.Date}}, {{LocalDateTime}} as
{{Timestamp}}.
Having, for example, {{IgniteCache}} where {{Person}} has a
{{java.time.LocalDateTime}} field, trying to select that field with a query
like {{select locDateTime from Person}} will return {{java.sql.Timestamp}}
value.
was (Author: asfedotov):
Apart from the improvements introduced by
[IGNITE-5483|https://issues.apache.org/jira/browse/IGNITE-5483] the following
should be addressed:
1. {{java.time.LocalTime}}, {{java.time.LocalDate}},
{{java.time.LocalDateTime}} are not supported as cache values or keys.
2. LocalDateTime is stored as Timestamp, which should be accounted when
applying a custom SQL functions. Probably that's a tradeoff for the moment.
> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
> Fix For: 2.2
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine.
> Next query can fails with error, if one of row localDateTimeField value has
> zero-time:
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method.
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5759) IgniteCache5 suite timed out by GridCachePartitionEvictionDuringReadThroughSelfTest.testPartitionRent
[
https://issues.apache.org/jira/browse/IGNITE-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111362#comment-16111362
]
ASF GitHub Bot commented on IGNITE-5759:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2373
> IgniteCache5 suite timed out by
> GridCachePartitionEvictionDuringReadThroughSelfTest.testPartitionRent
> -
>
> Key: IGNITE-5759
> URL: https://issues.apache.org/jira/browse/IGNITE-5759
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.2
>
> Attachments: threadDumpFromLogs.log
>
>
> http://ci.ignite.apache.org/viewLog.html?buildId=727951&buildTypeId=Ignite20Tests_IgniteCache5
> There is no 'Test has been timed out' message in logs.
> Last 'Starting test:' message was
> GridCachePartitionEvictionDuringReadThroughSelfTest#testPartitionRent
> Latest exception from working test was as follows;
> {noformat}
> [23:19:11]W: [org.apache.ignite:ignite-core] [2017-07-14
> 20:19:11,392][ERROR][tcp-comm-worker-#8980%distributed.GridCachePartitionEvictionDuringReadThroughSelfTest4%][TcpCommunicationSpi]
> TcpCommunicationSpi failed to establish connection to node, node will be
> dropped from cluster [rmtNode=TcpDiscoveryNode
> [id=a93fce57-6b2d-4947-8c23-8a677b93, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1500063443391, loc=false, ver=2.1.0#19700101-sha1:,
> isClient=false]]
> [23:19:11]W: [org.apache.ignite:ignite-core] class
> org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
> still alive?). Make sure that each ComputeTask and cache Transaction has a
> timeout set in order to prevent parties from waiting forever in case of
> network issues [nodeId=a93fce57-6b2d-4947-8c23-8a677b93,
> addrs=[/127.0.0.1:45273]]
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3173)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2757)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2649)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5900(TcpCommunicationSpi.java:245)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:4065)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3891)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [23:19:11]W: [org.apache.ignite:ignite-core]Suppressed:
> class org.apache.ignite.IgniteCheckedException: Failed to connect to address
> [addr=/127.0.0.1:45273, err=Connection refused]
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3178)
> [23:19:11]W: [org.apache.ignite:ignite-core]... 6
> more
> [23:19:11]W: [org.apache.ignite:ignite-core]Caused by:
> java.net.ConnectException: Connection refused
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:117)
> [23:19:11]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3024)
> [23:19:11]W: [org.apache.ignite:ignite-core]... 6
> more
> {noformat}
> and then
> {noformat}
> [23:19:11]W: [org.apache.ignite:ignite-core] [2017-07-14
> 20:19:11,895][WARN ][main][root] Interrupting threads started so far: 5
> [23:19:11] : [Step 4/5] [2017-07-14 20:1
[jira] [Assigned] (IGNITE-5886) Ignite SQL Getting Started
[
https://issues.apache.org/jira/browse/IGNITE-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akmal Chaudhri reassigned IGNITE-5886:
--
Assignee: Akmal Chaudhri
> Ignite SQL Getting Started
> ---
>
> Key: IGNITE-5886
> URL: https://issues.apache.org/jira/browse/IGNITE-5886
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Akmal Chaudhri
>Priority: Critical
> Fix For: 2.2
>
>
> The goal of the task is to create an Ignite SQL Getting Started with the
> following sections:
> * Connection to the cluster using JDBC and ODBC drivers. The
> content/description for both drivers will be the same. The only difference
> will be in the source code that can be shown in different tabs of "Code
> Sample" readme.io element. Take a look at the DDL doc [1] that incorporates
> the source code for Java API and JDBC.
> * SQL tables and indexes creation using DDL statements [1]. There should be
> at least two tables. Use the affinity collocation for them. {{CREATE TABLE}}
> command support {{AFFINITYKEY}} parameter that can be passed to {{WITH}}
> block.
> * Preload data using {{INSERT}} statements.
> * Show how to query data with {{SELECT}} statements including joins.
> * Show to update the data sets with {{UPDATE}} and {{DELETE}} statements.
> Here is the page to document (presently it's hidden and visible only for
> documentation contributors):
> https://apacheignite.readme.io/v2.1/docs/getting-started-sql
> Use JDBC thin driver [2] for the JDBC connectivity. The ODBC is well
> documented here [3] and we have a lot of examples for it in Ignite
> deliverables.
> Moreover, as a part of this activity, we will have the ready-to-use source
> code that should be shared on GitHub and mentioned in the documentation.
> [1] https://apacheignite.readme.io/v2.1/docs/distributed-ddl
> [2] https://apacheignite.readme.io/v2.1/docs/jdbc-driver#jdbc-thin-driver
> [3] https://apacheignite.readme.io/v2.1/docs/odbc-driver
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5732) Provide API to test compatibility with old releases
[
https://issues.apache.org/jira/browse/IGNITE-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1689#comment-1689
]
ASF GitHub Bot commented on IGNITE-5732:
GitHub user daradurvs opened a pull request:
https://github.com/apache/ignite/pull/2381
IGNITE-5732 Provide API to test compatibility with old releases
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/daradurvs/ignite ignite-5732
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2381.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2381
> Provide API to test compatibility with old releases
> ---
>
> Key: IGNITE-5732
> URL: https://issues.apache.org/jira/browse/IGNITE-5732
> Project: Ignite
> Issue Type: Test
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>
> Need to provide an opportunity to test compatibility with old releases.
> The main idea is the method {code}startGrid(ver){code} in the testing
> framework, which would start an instance via downloaded "jar" from the Maven
> repo.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5819) SQL: add support for TRUNCATE TABLE command.
[ https://issues.apache.org/jira/browse/IGNITE-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1682#comment-1682 ] Denis Magda commented on IGNITE-5819: - [~amashenkov], the command is supported by H2 and we should be able to support it too: http://www.h2database.com/html/grammar.html#truncate_table > SQL: add support for TRUNCATE TABLE command. > > > Key: IGNITE-5819 > URL: https://issues.apache.org/jira/browse/IGNITE-5819 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Andrew Mashenkov > Fix For: 2.3 > > > Add support for "TRUNCATE TABLE" command syntax. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5842) ODBC: Make sure ODBC driver works correctly with RazorSQL.
[
https://issues.apache.org/jira/browse/IGNITE-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-5842:
---
Assignee: Igor Sapego
> ODBC: Make sure ODBC driver works correctly with RazorSQL.
> --
>
> Key: IGNITE-5842
> URL: https://issues.apache.org/jira/browse/IGNITE-5842
> Project: Ignite
> Issue Type: Improvement
> Components: odbc
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: odbc
>
> Users often try to use ODBC driver to connect to Ignite with RazorSQL.
> However, it can't be used with our driver, as it tries to configure driver to
> act according to unsupported ODBC version. Here is the log:
> {noformat}
> razorsql12d8-1374 ENTER SQLAllocEnv
> HENV * 0x2FBEECB0
> razorsql12d8-1374 EXIT SQLAllocEnv with return code 0
> (SQL_SUCCESS)
> HENV * 0x2FBEECB0 ( 0x003DE650)
> razorsql12d8-1374 ENTER SQLAllocConnect
> HENV0x003DE650
> HDBC * 0x2FBEEC10
> razorsql12d8-1374 EXIT SQLAllocConnect with return code 0
> (SQL_SUCCESS)
> HENV0x003DE650
> HDBC * 0x2FBEEC10 ( 0x003DE6D0)
> razorsql12d8-1374 ENTER SQLSetConnectOption
> HDBC0x003DE6D0
> SQLINTEGER 103
> SQLPOINTER35
> razorsql12d8-1374 EXIT SQLSetConnectOption with return code 0
> (SQL_SUCCESS)
> HDBC0x003DE6D0
> SQLINTEGER 103
> SQLPOINTER35
> razorsql12d8-1374 ENTER SQLDriverConnectW
> HDBC0x003DE6D0
> HWND0x
> WCHAR * 0x6F861F7C [ -3] "**\ 0"
> SWORD -3
> WCHAR * 0x6F861F7C
> SWORD -3
> SWORD * 0x
> UWORD0
> razorsql12d8-1374 EXIT SQLDriverConnectW with return code -1
> (SQL_ERROR)
> HDBC0x003DE6D0
> HWND0x
> WCHAR * 0x6F861F7C [ -3] "**\ 0"
> SWORD -3
> WCHAR * 0x6F861F7C
> SWORD -3
> SWORD * 0x
> UWORD0
> DIAG [S1000] ODBC version is not supported. (0)
> DIAG [08001] Failed to establish connection with the host. (0)
> razorsql12d8-1374 ENTER SQLErrorW
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4
> SDWORD *0x2FBEEB3C
> WCHAR * 0x2FBEE6F4
> SWORD 300
> SWORD * 0x2FBEEB38
> razorsql12d8-1374 EXIT SQLErrorW with return code 0
> (SQL_SUCCESS)
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4 [ 5] "S1000"
> SDWORD *0x2FBEEB3C (0)
> WCHAR * 0x2FBEE6F4 [ 30] "ODBC version is not
> supported."
> SWORD 300
> SWORD * 0x2FBEEB38 (30)
> razorsql12d8-1374 ENTER SQLErrorW
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4
> SDWORD *0x2FBEEB3C
> WCHAR * 0x2FBEE6F4
> SWORD 300
> SWORD * 0x2FBEEB38
> razorsql12d8-1374 EXIT SQLErrorW with return code 0
> (SQL_SUCCESS)
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4 [ 5] "08001"
> SDWORD *0x2FBEEB3C (0)
> WCHAR * 0x2FBEE6F4 [ 45] "Failed to establish
> connection with the host."
> SWORD 300
> SWORD * 0x2FBEEB38 (45)
> razorsql
[jira] [Commented] (IGNITE-5899) Thin client: cache.Get for primitives
[
https://issues.apache.org/jira/browse/IGNITE-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1613#comment-1613
]
Pavel Tupitsyn commented on IGNITE-5899:
[~vozerov] fixed.
> Thin client: cache.Get for primitives
> -
>
> Key: IGNITE-5899
> URL: https://issues.apache.org/jira/browse/IGNITE-5899
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.2
>
>
> Implement {{cache.Get}} for primitive data types via thin client protocol.
> This will include:
> * New client type in {{SqlListenerNioListener}}
> * {{PlatformRequestHandler implements SqlListenerRequestHandler}},
> {{PlatformMessageParser implements SqlListenerMessageParser}}
> * Integration test in .NET (just because .NET is the first platform to adopt
> this; we could do tests in Java as well, but this is redundant for now)
> Support only primitive types for now to avoid dealing with bynary type
> metadata, schemas, compact footers, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-5871) IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed fails
[ https://issues.apache.org/jira/browse/IGNITE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov resolved IGNITE-5871. - Resolution: Fixed resolving this as a duplicate of IGNITE-5542 > IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed > fails > > > Key: IGNITE-5871 > URL: https://issues.apache.org/jira/browse/IGNITE-5871 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Sergey Chugunov > Labels: MakeTeamcityGreenAgain > Fix For: 2.2 > > > Success rate is 20%. > http://ci.ignite.apache.org/project.html?tab=testDetails&projectId=Ignite20Tests&testNameId=-720637123828878&page=10 > Seems that it was broken in build #179, where [~sboikov] had merged cache > groupd (ignite-5075) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5871) IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed fails
[ https://issues.apache.org/jira/browse/IGNITE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov reassigned IGNITE-5871: --- Assignee: Sergey Chugunov > IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed > fails > > > Key: IGNITE-5871 > URL: https://issues.apache.org/jira/browse/IGNITE-5871 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Sergey Chugunov > Labels: MakeTeamcityGreenAgain > Fix For: 2.2 > > > Success rate is 20%. > http://ci.ignite.apache.org/project.html?tab=testDetails&projectId=Ignite20Tests&testNameId=-720637123828878&page=10 > Seems that it was broken in build #179, where [~sboikov] had merged cache > groupd (ignite-5075) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5542) Assertion failure in IgniteBasic test IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
[ https://issues.apache.org/jira/browse/IGNITE-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-5542: - Fix Version/s: 2.2 > Assertion failure in IgniteBasic test > IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed > > - > > Key: IGNITE-5542 > URL: https://issues.apache.org/jira/browse/IGNITE-5542 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Pavlov >Assignee: Sergey Chugunov > Labels: MakeTeamcityGreenAgain, test-fail > Fix For: 2.2 > > > > http://ci.ignite.apache.org/viewLog.html?buildId=674131&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteBasic#testNameId-720637123828878 > org.apache.ignite.internal.processors.cache.IgniteCacheP2pUnmarshallingRebalanceErrorTest#testResponseMessageOnUnmarshallingFailed > assertion failed, > *stable reproducable locally* -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5809) SQL: Add precision and scale support for table fields.
[ https://issues.apache.org/jira/browse/IGNITE-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-5809: - Description: For now Ignite DDL doesn't support precision and scale for floating-point SQL fields. PFA test. was: PFA test. > SQL: Add precision and scale support for table fields. > -- > > Key: IGNITE-5809 > URL: https://issues.apache.org/jira/browse/IGNITE-5809 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Andrew Mashenkov > Fix For: 2.3 > > Attachments: DecimalPrecisionSqlTest.java > > > For now Ignite DDL doesn't support precision and scale for floating-point SQL > fields. > PFA test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5809) SQL: Add precision and scale support for table fields.
[ https://issues.apache.org/jira/browse/IGNITE-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-5809: - Description: PFA test. was:PFA test. > SQL: Add precision and scale support for table fields. > -- > > Key: IGNITE-5809 > URL: https://issues.apache.org/jira/browse/IGNITE-5809 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Andrew Mashenkov > Fix For: 2.3 > > Attachments: DecimalPrecisionSqlTest.java > > > PFA test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.
[ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4908: - Description: Design discussed with Alexander: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock was: Design discussed with Alexander: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock > Ignite.reentrantLock looks much slower than IgniteCache.lock. > - > > Key: IGNITE-4908 > URL: https://issues.apache.org/jira/browse/IGNITE-4908 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov > Fix For: 2.2 > > > Design discussed with Alexander: > 1) Lock > Entry Processor (sync) -> > add candidate. > returns "added candidate at first position" > retry failover -> > if already at first position -> return true > In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer > should be used). > 2) Unlock > Entry Processor (async) -> > remove candidate at first position > retry failover -> remove only if "candidate at first position" equals to > expected > listener -> > notify current "candidate at first position" it got lock > 3)Failover > 3.1) Originating node failed > Failed node listener -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related no failed node > retry failover not needed > listener -> > if "candidate at first position" removed -> > notify current "candidate at first position" it got lock > 3.2) Primary node failed > After rebalancing schedule Callable -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related to failed nodes > retry failover not needed > listener -> > notify current "candidate at first position" it got lock -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.
[ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4908: - Description: Design discussed with Alexander: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock was: Design discussed with Alexander: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock > Ignite.reentrantLock looks much slower than IgniteCache.lock. > - > > Key: IGNITE-4908 > URL: https://issues.apache.org/jira/browse/IGNITE-4908 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov > Fix For: 2.2 > > > Design discussed with Alexander: > 1) Lock > Entry Processor (sync) -> > add candidate. > returns "added candidate at first position" > retry failover -> > if already at first position -> return true > In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer > should be used). > 2) Unlock > Entry Processor (async) -> > remove candidate at first position > retry failover -> remove only if "candidate at first position" equals to > expected > listener -> > notify current "candidate at first position" it got lock > 3)Failover > 3.1) Originating node failed > Failed node listener -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related no failed node > retry failover not needed > listener -> > if "candidate at first position" removed -> > notify current "candidate at first position" it got lock > 3.2) Primary node failed > After rebalancing schedule Callable -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related to failed nodes > retry failover not needed > listener -> > notify current "candidate at first position" it got lock -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5618) .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration
[ https://issues.apache.org/jira/browse/IGNITE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110955#comment-16110955 ] Dmitriy Pavlov commented on IGNITE-5618: See also related discussion http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-5717-improvements-of-MemoryPolicy-default-size-td20264.html > .NET: Ignite fails with OOM on startup under x86 (32 bit) with default > configuration > > > Key: IGNITE-5618 > URL: https://issues.apache.org/jira/browse/IGNITE-5618 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.0 >Reporter: Pavel Tupitsyn >Priority: Blocker > Labels: .NET, MakeTeamcityGreenAgain > Fix For: 2.2 > > > Default MemoryPolicyConfiguration settings do not take process bitness into > account. We can't use 80% of RAM under 32-bit mode. > * Add a suite on TC which runs .NET tests on 32 bits -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.
[ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4908: - Fix Version/s: (was: 2.3) 2.2 > Ignite.reentrantLock looks much slower than IgniteCache.lock. > - > > Key: IGNITE-4908 > URL: https://issues.apache.org/jira/browse/IGNITE-4908 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov > Fix For: 2.2 > > > Design discussed with Alexander: > 1) Lock > Entry Processor (sync) -> > add candidate. > returns "added candidate at first position" > retry failover -> > if already at first position -> return true > In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer > should be used). > 2) Unlock > Entry Processor (async) -> > remove candidate at first position > retry failover -> remove only if "candidate at first position" equals to > expected > listener -> > notify current "candidate at first position" it got lock > 3)Failover > 3.1) Originating node failed > Failed node listener -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related no failed node > retry failover not needed > listener -> > if "candidate at first position" removed -> > notify current "candidate at first position" it got lock > 3.2) Primary node failed > After rebalancing schedule Callable -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related to failed nodes > retry failover not needed > listener -> > notify current "candidate at first position" it got lock -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.
[ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4908: - Description: Design discussed with Alexander: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock was: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock > Ignite.reentrantLock looks much slower than IgniteCache.lock. > - > > Key: IGNITE-4908 > URL: https://issues.apache.org/jira/browse/IGNITE-4908 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov > Fix For: 2.3 > > > Design discussed with Alexander: > 1) Lock > Entry Processor (sync) -> > add candidate. > returns "added candidate at first position" > retry failover -> > if already at first position -> return true > In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer > should be used). > 2) Unlock > Entry Processor (async) -> > remove candidate at first position > retry failover -> remove only if "candidate at first position" equals to > expected > listener -> > notify current "candidate at first position" it got lock > 3)Failover > 3.1) Originating node failed > Failed node listener -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related no failed node > retry failover not needed > listener -> > if "candidate at first position" removed -> > notify current "candidate at first position" it got lock > 3.2) Primary node failed > After rebalancing schedule Callable -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related to failed nodes > retry failover not needed > listener -> > notify current "candidate at first position" it got lock -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.
[ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4908: - Description: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock was: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock > Ignite.reentrantLock looks much slower than IgniteCache.lock. > - > > Key: IGNITE-4908 > URL: https://issues.apache.org/jira/browse/IGNITE-4908 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov > Fix For: 2.3 > > > 1) Lock > Entry Processor (sync) -> > add candidate. > returns "added candidate at first position" > retry failover -> > if already at first position -> return true > In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer > should be used). > > 2) Unlock > Entry Processor (async) -> > remove candidate at first position > retry failover -> remove only if "candidate at first position" equals to > expected > listener -> > notify current "candidate at first position" it got lock > > 3)Failover > 3.1) Originating node failed > Failed node listener -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related no failed node > retry failover not needed > listener -> > if "candidate at first position" removed -> > notify current "candidate at first position" it got > lock > > 3.2) Primary node failed > After rebalancing schedule Callable -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related to failed nodes > retry failover not needed > listener -> > notify current "candidate at first position" it got lock -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.
[ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4908: - Description: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock was: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock > Ignite.reentrantLock looks much slower than IgniteCache.lock. > - > > Key: IGNITE-4908 > URL: https://issues.apache.org/jira/browse/IGNITE-4908 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov > Fix For: 2.3 > > > 1) Lock > Entry Processor (sync) -> > add candidate. > returns "added candidate at first position" > retry failover -> > if already at first position -> return true > In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer > should be used). > 2) Unlock > Entry Processor (async) -> > remove candidate at first position > retry failover -> remove only if "candidate at first position" equals to > expected > listener -> > notify current "candidate at first position" it got lock > 3)Failover > 3.1) Originating node failed > Failed node listener -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related no failed node > retry failover not needed > listener -> > if "candidate at first position" removed -> > notify current "candidate at first position" it got lock > 3.2) Primary node failed > After rebalancing schedule Callable -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related to failed nodes > retry failover not needed > listener -> > notify current "candidate at first position" it got lock -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.
[ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-4908: - Description: 1) Lock Entry Processor (sync) -> add candidate. returns "added candidate at first position" retry failover -> if already at first position -> return true In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used). 2) Unlock Entry Processor (async) -> remove candidate at first position retry failover -> remove only if "candidate at first position" equals to expected listener -> notify current "candidate at first position" it got lock 3)Failover 3.1) Originating node failed Failed node listener -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related no failed node retry failover not needed listener -> if "candidate at first position" removed -> notify current "candidate at first position" it got lock 3.2) Primary node failed After rebalancing schedule Callable -> For each local(primary) lock -> Entry Processor (async) -> remove candidates related to failed nodes retry failover not needed listener -> notify current "candidate at first position" it got lock was: We should make a benchmark and investigate this issue. > Ignite.reentrantLock looks much slower than IgniteCache.lock. > - > > Key: IGNITE-4908 > URL: https://issues.apache.org/jira/browse/IGNITE-4908 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Alexander Menshikov > Fix For: 2.3 > > > 1) Lock > Entry Processor (sync) -> > add candidate. > returns "added candidate at first position" > retry failover -> > if already at first position -> return true > In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer > should be used). > > 2) Unlock > Entry Processor (async) -> > remove candidate at first position > retry failover -> remove only if "candidate at first position" equals to > expected > listener -> > notify current "candidate at first position" it got lock > > 3)Failover > 3.1) Originating node failed > Failed node listener -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related no failed node > retry failover not needed > listener -> > if "candidate at first position" removed -> > notify current "candidate at first position" it got lock > > > 3.2) Primary node failed > After rebalancing schedule Callable -> > For each local(primary) lock -> > Entry Processor (async) -> > remove candidates related to failed nodes > retry failover not needed > listener -> > notify current "candidate at first position" it got lock -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5899) Thin client: cache.Get for primitives
[
https://issues.apache.org/jira/browse/IGNITE-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110940#comment-16110940
]
Vladimir Ozerov commented on IGNITE-5899:
-
[~ptupitsyn], my comments:
1) Please rename all classes from {{Platform*}} to {{Client*}}, as it is not
about platforms at all.
2) Parser looks useless to me at the moment. We have clear separation of
concerns between parser and handler:
- Parser should construct request object with all necessary data inside. If
this is a GET request, then it should produce something like
{code}
class ClientGetRequest {
long reqId,
int cacheId;
Object key;
}
{code}
- Handler must process request and produce a response, e.g.:
{code}
class ClientGetResponse {
long reqId;
Object val;
}
{code}
> Thin client: cache.Get for primitives
> -
>
> Key: IGNITE-5899
> URL: https://issues.apache.org/jira/browse/IGNITE-5899
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.2
>
>
> Implement {{cache.Get}} for primitive data types via thin client protocol.
> This will include:
> * New client type in {{SqlListenerNioListener}}
> * {{PlatformRequestHandler implements SqlListenerRequestHandler}},
> {{PlatformMessageParser implements SqlListenerMessageParser}}
> * Integration test in .NET (just because .NET is the first platform to adopt
> this; we could do tests in Java as well, but this is redundant for now)
> Support only primitive types for now to avoid dealing with bynary type
> metadata, schemas, compact footers, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5126) JDBC thin driver: support batches
[ https://issues.apache.org/jira/browse/IGNITE-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110937#comment-16110937 ] Taras Ledkov commented on IGNITE-5126: -- Fixed. [Tests results|http://195.239.208.174/project.html?projectId=Ignite20Tests&tab=projectOverview&branch_Ignite20Tests=pull%2F2162%2Fhead] are OK. [~vozerov], please review the changes. > JDBC thin driver: support batches > -- > > Key: IGNITE-5126 > URL: https://issues.apache.org/jira/browse/IGNITE-5126 > Project: Ignite > Issue Type: New Feature > Components: jdbc >Affects Versions: 1.9 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > > Support batches operations for the thin JDBC driver. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5899) Thin client: cache.Get for primitives
[
https://issues.apache.org/jira/browse/IGNITE-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-5899:
---
Assignee: Pavel Tupitsyn (was: Vladimir Ozerov)
> Thin client: cache.Get for primitives
> -
>
> Key: IGNITE-5899
> URL: https://issues.apache.org/jira/browse/IGNITE-5899
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.2
>
>
> Implement {{cache.Get}} for primitive data types via thin client protocol.
> This will include:
> * New client type in {{SqlListenerNioListener}}
> * {{PlatformRequestHandler implements SqlListenerRequestHandler}},
> {{PlatformMessageParser implements SqlListenerMessageParser}}
> * Integration test in .NET (just because .NET is the first platform to adopt
> this; we could do tests in Java as well, but this is redundant for now)
> Support only primitive types for now to avoid dealing with bynary type
> metadata, schemas, compact footers, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-5715) Thread safety for transaction operations
[ https://issues.apache.org/jira/browse/IGNITE-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-5715. - Resolution: Fixed Fixed by IGNITE-5712 > Thread safety for transaction operations > > > Key: IGNITE-5715 > URL: https://issues.apache.org/jira/browse/IGNITE-5715 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Nikolay Izhikov > > Resume operation should succeed if transaction was suspended earlier. > Other transaction operations must throw exception if it tries to operate > thransaction, it doesn't own. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5498) Failures in GridNioSslSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov reassigned IGNITE-5498:
Assignee: (was: Semen Boikov)
> Failures in GridNioSslSelfTest
> --
>
> Key: IGNITE-5498
> URL: https://issues.apache.org/jira/browse/IGNITE-5498
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Vladimir Ozerov
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.2
>
>
> Affected tests:
> {{GridNioSslSelfTest.testConcurrentConnects}}
> {{GridNioSslSelfTest.testSimpleMessages}}
> {code}
> junit.framework.AssertionFailedError: Unexpected exception occurred while
> handling connection: class
> org.apache.ignite.internal.util.nio.GridNioException: An established
> connection was aborted by the software in your host machine
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.internal.util.nio.GridNioSelfTest$EchoListener.onDisconnected(GridNioSelfTest.java:1361)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onExceptionCaught(GridNioFilterChain.java:261)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedExceptionCaught(GridNioFilterAdapter.java:102)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onExceptionCaught(GridNioCodecFilter.java:80)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedExceptionCaught(GridNioFilterAdapter.java:102)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onExceptionCaught(GridNioSslFilter.java:241)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedExceptionCaught(GridNioFilterAdapter.java:102)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onExceptionCaught(GridNioServer.java:3188)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onExceptionCaught(GridNioFilterChain.java:160)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.close(GridNioServer.java:2437)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2199)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1968)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1669)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5498) Failures in GridNioSslSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110807#comment-16110807
]
Dmitriy Pavlov commented on IGNITE-5498:
[~gvvinblade] reproduced one more time,
http://ci.ignite.apache.org/viewLog.html?buildId=751981&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteBinarySImpleMapperBasic#testNameId-132030544235308877
Who is looking to this test now?
> Failures in GridNioSslSelfTest
> --
>
> Key: IGNITE-5498
> URL: https://issues.apache.org/jira/browse/IGNITE-5498
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.2
>
>
> Affected tests:
> {{GridNioSslSelfTest.testConcurrentConnects}}
> {{GridNioSslSelfTest.testSimpleMessages}}
> {code}
> junit.framework.AssertionFailedError: Unexpected exception occurred while
> handling connection: class
> org.apache.ignite.internal.util.nio.GridNioException: An established
> connection was aborted by the software in your host machine
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.internal.util.nio.GridNioSelfTest$EchoListener.onDisconnected(GridNioSelfTest.java:1361)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onExceptionCaught(GridNioFilterChain.java:261)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedExceptionCaught(GridNioFilterAdapter.java:102)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onExceptionCaught(GridNioCodecFilter.java:80)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedExceptionCaught(GridNioFilterAdapter.java:102)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onExceptionCaught(GridNioSslFilter.java:241)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedExceptionCaught(GridNioFilterAdapter.java:102)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onExceptionCaught(GridNioServer.java:3188)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onExceptionCaught(GridNioFilterChain.java:160)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.close(GridNioServer.java:2437)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2199)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1968)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1669)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5468) Need to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE on per query basis
[ https://issues.apache.org/jira/browse/IGNITE-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110806#comment-16110806 ] Vitaliy Biryukov commented on IGNITE-5468: --- [~amashenkov], Done. > Need to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE on per query basis > -- > > Key: IGNITE-5468 > URL: https://issues.apache.org/jira/browse/IGNITE-5468 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.0 >Reporter: Yakov Zhdanov >Assignee: Vitaliy Biryukov >Priority: Critical > Fix For: 2.2 > > > Currently this property can be set via sys property only thus changing it > will require restart of the cluster. I think it is better to set it on > perquery basis with some default that is configured via cache configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5355) Create task with release tools
[ https://issues.apache.org/jira/browse/IGNITE-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110805#comment-16110805 ] ASF GitHub Bot commented on IGNITE-5355: GitHub user achetaev opened a pull request: https://github.com/apache/ignite/pull/2379 IGNITE-5355 Implement class for generate Jira based release report You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5355 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2379.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2379 commit a6ad620cece5be02da4f8394a501f7c7fd76f165 Author: Aleksey Chetaev Date: 2017-06-01T15:00:21Z IGNITE-5355: Added new class to ignite-tools for generate release report commit 1aeee2062d48324712bc51c1b6cde9969d58cacc Author: Aleksey Chetaev Date: 2017-06-01T15:17:10Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite into ignite-5355 commit 42876c924e7ccbd84b3883acae21d069aa971b34 Author: Aleksey Chetaev Date: 2017-06-01T17:23:43Z IGNITE-5355 Add needed dependencies to tools/pom.xml commit dcb5cca3b923ad2c5fffcf85b24fe062b109d74c Author: Aleksey Chetaev Date: 2017-06-02T13:13:20Z IGNITE-5355 Implemet reports templates for customise reports withou code change commit 92d48295a2fe27cd348e5fce761f459cdc485064 Author: Aleksey Chetaev Date: 2017-06-05T18:04:48Z IGNITE-5355 Implement description for release readed from template commit c375699503772dee64509824d0c9b7826a351277 Author: Aleksey Chetaev Date: 2017-06-05T19:25:38Z Add reading report css from file commit 84f2cb3df386a6360d23d92de9ecf2ce106d3912 Author: Aleksey Chetaev Date: 2017-06-05T19:53:36Z IGNITE-5355 Fix error with css template commit 9b7b03422cf8163ebe7157f939fb0f95c5e3 Author: Aleksey Chetaev Date: 2017-07-06T10:38:13Z Fixed Release reporting tools commit c14507b7edc9798244e5a096c16f5713d7b3b8d2 Author: Aleksey Chetaev Date: 2017-08-02T12:22:42Z Add baseUrl link to json template for link generation commit e8032854dcd56d253d5c03e454a2f932320fd38c Author: Aleksey Chetaev Date: 2017-08-02T12:31:34Z IGNITE-5355 - Fix errors > Create task with release tools > -- > > Key: IGNITE-5355 > URL: https://issues.apache.org/jira/browse/IGNITE-5355 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Chetaev >Assignee: Aleksey Chetaev > > 1. Create task for auto-generate HTML formatted releases notes -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5355) Create task with release tools
[ https://issues.apache.org/jira/browse/IGNITE-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110802#comment-16110802 ] ASF GitHub Bot commented on IGNITE-5355: Github user achetaev closed the pull request at: https://github.com/apache/ignite/pull/2089 > Create task with release tools > -- > > Key: IGNITE-5355 > URL: https://issues.apache.org/jira/browse/IGNITE-5355 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Chetaev >Assignee: Aleksey Chetaev > > 1. Create task for auto-generate HTML formatted releases notes -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5648) NOT NULL constraint support for CREATE TABLE operator
[
https://issues.apache.org/jira/browse/IGNITE-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110781#comment-16110781
]
Vladimir Ozerov commented on IGNITE-5648:
-
[~skalashnikov], my comments:
1) {{org.apache.ignite.internal.processors.query.GridQueryProperty#validate}} -
docs say that exception is thrown if validation against some constraints has
failed. Why none implementations of this method check for {{notNull}} flag
then? Looks like this is a wrong abstraction. Instead, we should move this
logic to
{{org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl#validateKeyAndValue}}.
2) {{org.apache.ignite.internal.processors.query.GridQueryProperty#setValue}} -
there are duplicated null check in both implementations. Isn't it too late to
check for null when this method is called? This method is called from two
places - one in DML statement and one deep inside the cache. I think null check
must be performed only in DML processor as a separate routine, and should not
be called in indexing internals (H2RowDescriptor) for the sake of performance.
Makes sense?
3) {{QueryUtils}} - code style violations (too long strings, incorrect indents)
4) Note that neither key, not value as a whole can ever be null already.
5) {{QueryTypeDescriptorImpl}} - unused imports and fields
6) {{GridNearAtomicUpdateFuture}} and it's "single" brother - why do we skip
{{TRANSFORM}} case? {{EntryProcessor}} can easily produce invalid values, and
we must check them as well. Please confirm that it is covered in some other
place.
7) I am concerned about {{GridCacheContext#validateKeyAndValue}} performance.
We need to think on some quick exit path in case queries are not enabled for
cache (no {{QueryEntitiy}} in config), or there are no null-constrained
columns. Ideally it should be some volatile boolean flag which is checked
first.
> NOT NULL constraint support for CREATE TABLE operator
> -
>
> Key: IGNITE-5648
> URL: https://issues.apache.org/jira/browse/IGNITE-5648
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> This is an umbrella ticket intended to aggregate all the activities related
> to {{NOT NULL}} constraint support for {{CREATE TABLE}} commands.
> {code}
> CREATE TABLE legs(legid INT NOT NULL);
> {code}
> Ignite must prevent setting {{legid}} to {{null}} value.
> The feature has to be supported for:
> * ODBC and JDBC drivers.
> * Native APIs (Java, .NET, C++)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5490) Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize
[ https://issues.apache.org/jira/browse/IGNITE-5490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-5490: --- Description: With new 2.0 architecture, many caches can share one memory policy. Memory metrics allows to measure memory usage (loaded pages) for the whole policy. However, there's also a need to measure how much memory (or pages) is used by each cache. Before 2.0 such information was accessible with CacheMetrics#getOffHeapAllocatedSize, but current implemetation returns 0. We should either implement it or provide alternative metrics (e. g. approximate number of loaded pages per cache). Please note that if persistence is *disabled*, precise number of loaded pages per cache is not defined - one page can contain entries of different caches. was: With new 2.0 architecture, many caches can share one memory policy. Memory metrics allows to measure memory usage (loaded pages) for the whole policy. However, there's also a need to measure how much memory (or pages) is used by each cache. Before 2.0 such information was accessible with CacheMetrics#getOffHeapAllocatedSize, but current implemetation returns 0. We should either implement it or provide alternative metrics (e. g. approximate number of loaded pages per cache). Please note that precise number of loaded pages per cache is not defined - one page can contain entries of different caches. > Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize > --- > > Key: IGNITE-5490 > URL: https://issues.apache.org/jira/browse/IGNITE-5490 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.0 >Reporter: Ivan Rakov > > With new 2.0 architecture, many caches can share one memory policy. Memory > metrics allows to measure memory usage (loaded pages) for the whole policy. > However, there's also a need to measure how much memory (or pages) is used by > each cache. > Before 2.0 such information was accessible with > CacheMetrics#getOffHeapAllocatedSize, but current implemetation returns 0. > We should either implement it or provide alternative metrics (e. g. > approximate number of loaded pages per cache). Please note that if > persistence is *disabled*, precise number of loaded pages per cache is not > defined - one page can contain entries of different caches. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4551) Reconsider cache key/value peer class loading
[ https://issues.apache.org/jira/browse/IGNITE-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-4551: --- Labels: MakeTeamcityGreenAgain Muted_test (was: MakeTeamcityGreenAgain) > Reconsider cache key/value peer class loading > - > > Key: IGNITE-4551 > URL: https://issues.apache.org/jira/browse/IGNITE-4551 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Alexey Goncharuk >Assignee: Nikolay Tikhonov > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.2 > > > In new cache implementation after entry is written in offheap information > about key/value classloaders in lost (before classloader ids were stored in > swap/offheap see GridCacheMapEntry.swap in 'master'). > Need decide how it should work with new architecture (maybe single type per > cache can simplify implementation). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5897) Ignite Cache Full API Multi JVM: 7 test failed in master
[
https://issues.apache.org/jira/browse/IGNITE-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-5897:
---
Assignee: Nikolay Izhikov (was: Dmitriy Pavlov)
> Ignite Cache Full API Multi JVM: 7 test failed in master
>
>
> Key: IGNITE-5897
> URL: https://issues.apache.org/jira/browse/IGNITE-5897
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Nikolay Izhikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Failure on TC:
> http://ci.ignite.apache.org/viewLog.html?buildId=749671&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteCacheFullApiMultiJvm#testNameId-6305397409161667157
> org.apache.ignite.internal.processors.cache.multijvm (7)
> -
> GridCachePartitionedNearDisabledMultiJvmFullApiSelfTest.testTransformResourceInjection
>
> -
> GridCachePartitionedNearDisabledMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
>
> -
> GridCachePartitionedNearDisabledOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection
>
> - GridCacheReplicatedMultiJvmFullApiSelfTest.testTransformResourceInjection
> -
> GridCacheReplicatedMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection
>
> -
> GridCacheReplicatedNearOnlyMultiJvmFullApiSelfTest.testTransformResourceInjection
>
> -
> GridCacheReplicatedOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection
>
> Stable reproducible locally
> First failure changes:
> http://ci.ignite.apache.org/viewLog.html?buildId=727280&tab=buildChangesDiv&buildTypeId=Ignite20Tests_IgniteCacheFullApiMultiJvm
> {noformat}
> IGNITE-5753: CPP Memory leak fixed. Igor Sapego
> IGNITE-5444: Collections.singletonList is not properly serialized by binary
> marshaller. This closes #2217.andrey.mashenkov
> ignite-5722 Cache entries stay in onheap after scan query execution for
> OFFHEAP_TIRED cache with expiry policyAndrey Gura
> ignite-5489 Fixed possible connection leaks when loadPreviousValue set to
> truetikhonovnicolay
> IGNITE-4831: Add an option to disable MBeans. This closes #2265.
> andrey.mashenkov
> {noformat}
> Stacktrace:
> {noformat}
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] class
> org.apache.ignite.IgniteCheckedException: java.lang.NullPointerException
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:327)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:282)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.readThrough(GridCacheMapEntry.java:445)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:699)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet(GridCacheMapEntry.java:461)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:389)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1213)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:668)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1034)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:410)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:459)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:121)
> [2017-08-01 16:27:28,330][INFO ][Thread-4][jvm-fe4cadea] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHa
[jira] [Commented] (IGNITE-5468) Need to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE on per query basis
[ https://issues.apache.org/jira/browse/IGNITE-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110770#comment-16110770 ] Andrew Mashenkov commented on IGNITE-5468: -- [~VitaliyB] I've left a note in UpSource. > Need to set IGNITE_SQL_MERGE_TABLE_MAX_SIZE on per query basis > -- > > Key: IGNITE-5468 > URL: https://issues.apache.org/jira/browse/IGNITE-5468 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.0 >Reporter: Yakov Zhdanov >Assignee: Vitaliy Biryukov >Priority: Critical > Fix For: 2.2 > > > Currently this property can be set via sys property only thus changing it > will require restart of the cluster. I think it is better to set it on > perquery basis with some default that is configured via cache configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5490) Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize
[ https://issues.apache.org/jira/browse/IGNITE-5490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110764#comment-16110764 ] Ivan Rakov edited comment on IGNITE-5490 at 8/2/17 12:09 PM: - Also, under this ticket we should ensure that "Local Node Metrics" works correctly. Related discussion: http://apache-ignite-users.70518.x6.nabble.com/Off-Heap-and-Eviction-policy-questions-td15869.html was (Author: ivan.glukos): Also, under this ticket ew should ensure that "Local Node Metrics" works correctly. Related discussion: http://apache-ignite-users.70518.x6.nabble.com/Off-Heap-and-Eviction-policy-questions-td15869.html > Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize > --- > > Key: IGNITE-5490 > URL: https://issues.apache.org/jira/browse/IGNITE-5490 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.0 >Reporter: Ivan Rakov > > With new 2.0 architecture, many caches can share one memory policy. Memory > metrics allows to measure memory usage (loaded pages) for the whole policy. > However, there's also a need to measure how much memory (or pages) is used by > each cache. > Before 2.0 such information was accessible with > CacheMetrics#getOffHeapAllocatedSize, but current implemetation returns 0. > We should either implement it or provide alternative metrics (e. g. > approximate number of loaded pages per cache). Please note that precise > number of loaded pages per cache is not defined - one page can contain > entries of different caches. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5490) Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize
[ https://issues.apache.org/jira/browse/IGNITE-5490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110764#comment-16110764 ] Ivan Rakov commented on IGNITE-5490: Also, under this ticket ew should ensure that "Local Node Metrics" works correctly. Related discussion: http://apache-ignite-users.70518.x6.nabble.com/Off-Heap-and-Eviction-policy-questions-td15869.html > Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize > --- > > Key: IGNITE-5490 > URL: https://issues.apache.org/jira/browse/IGNITE-5490 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.0 >Reporter: Ivan Rakov > > With new 2.0 architecture, many caches can share one memory policy. Memory > metrics allows to measure memory usage (loaded pages) for the whole policy. > However, there's also a need to measure how much memory (or pages) is used by > each cache. > Before 2.0 such information was accessible with > CacheMetrics#getOffHeapAllocatedSize, but current implemetation returns 0. > We should either implement it or provide alternative metrics (e. g. > approximate number of loaded pages per cache). Please note that precise > number of loaded pages per cache is not defined - one page can contain > entries of different caches. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5648) NOT NULL constraint support for CREATE TABLE operator
[
https://issues.apache.org/jira/browse/IGNITE-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5648:
Issue Type: New Feature (was: Task)
> NOT NULL constraint support for CREATE TABLE operator
> -
>
> Key: IGNITE-5648
> URL: https://issues.apache.org/jira/browse/IGNITE-5648
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Sergey Kalashnikov
> Fix For: 2.3
>
>
> This is an umbrella ticket intended to aggregate all the activities related
> to {{NOT NULL}} constraint support for {{CREATE TABLE}} commands.
> {code}
> CREATE TABLE legs(legid INT NOT NULL);
> {code}
> Ignite must prevent setting {{legid}} to {{null}} value.
> The feature has to be supported for:
> * ODBC and JDBC drivers.
> * Native APIs (Java, .NET, C++)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5126) JDBC thin driver: support batches
[
https://issues.apache.org/jira/browse/IGNITE-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110755#comment-16110755
]
Vladimir Ozerov commented on IGNITE-5126:
-
[~tledkov-gridgain], my comments:
1) {{JdbcThinBatchSelfTest}} is not associated with any test suite.
2) {{JdbcQuery}} - missing {{toString}}
3) {{JdbcThinTcpIo.QUERY_BATCH_EXEC_MSG_INIT_CAP}} - strange heuristic. I would
rather take {{QUERY_EXEC_MSG_INIT_CAP * QUERY_COUNT}}
4 {{JdbcThinTcpIo.batchExecute}} - why do we copying queries from list to
array? We can simply use list in all places, it's not that better than array in
context of this task. Same goes for batch arguments - why do we copy them over
and over again?
5) Why does {{org.apache.ignite.internal.jdbc.thin.JdbcThinStatement#execute0}}
clears the batch? Is it specified anywhere that calls to methods like
{{executeQuery}} or {{executeUpdate}} must clear the batch?
> JDBC thin driver: support batches
> --
>
> Key: IGNITE-5126
> URL: https://issues.apache.org/jira/browse/IGNITE-5126
> Project: Ignite
> Issue Type: New Feature
> Components: jdbc
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> Support batches operations for the thin JDBC driver.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5542) Assertion failure in IgniteBasic test IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
[
https://issues.apache.org/jira/browse/IGNITE-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110739#comment-16110739
]
Sergey Chugunov edited comment on IGNITE-5542 at 8/2/17 11:30 AM:
--
[~sboikov], I've addressed both points:
* Removed unnecessary method and moved all checks to existing {{checkCache}}
method. I used it instead of suggested {{validateCacheGroupConfiguration}}
because the latter one is responsible for validating different caches within
the same cache group before sending join request; while the former does exactly
what I need: it compares remote cache configuration with local one.
* Additional test case was created.
I also merged latest changes from master to my branch and checked [TC
status|http://ci.ignite.apache.org/viewLog.html?buildId=751953]; it hasn't
shown any test failures related to my change.
Thanks,
Sergey.
was (Author: sergey-chugunov):
[~sboikov], I've addressed both points:
* Removed unnecessary method and moved all checks to existing {{checkCache}}
method. I used it instead of suggested {{validateCacheGroupConfiguration}}
because the latter one is responsible for validating different caches within
the same cache group; while the former does exactly what I need: it compares
remote cache configuration with local one.
* Additional test case was created.
I also merged latest changes from master to my branch and checked [TC
status|http://ci.ignite.apache.org/viewLog.html?buildId=751953]; it hasn't
shown any test failures related to my change.
Thanks,
Sergey.
> Assertion failure in IgniteBasic test
> IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
>
> -
>
> Key: IGNITE-5542
> URL: https://issues.apache.org/jira/browse/IGNITE-5542
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Sergey Chugunov
> Labels: MakeTeamcityGreenAgain, test-fail
>
>
> http://ci.ignite.apache.org/viewLog.html?buildId=674131&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteBasic#testNameId-720637123828878
> org.apache.ignite.internal.processors.cache.IgniteCacheP2pUnmarshallingRebalanceErrorTest#testResponseMessageOnUnmarshallingFailed
> assertion failed,
> *stable reproducable locally*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5542) Assertion failure in IgniteBasic test IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
[
https://issues.apache.org/jira/browse/IGNITE-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110739#comment-16110739
]
Sergey Chugunov edited comment on IGNITE-5542 at 8/2/17 11:30 AM:
--
[~sboikov], I've addressed both points:
* Removed unnecessary method and moved all checks to existing {{checkCache}}
method. I used it instead of suggested {{validateCacheGroupConfiguration}}
because the latter one is responsible for validating different caches within
the same cache group; while the former does exactly what I need: it compares
remote cache configuration with local one.
* Additional test case was created.
I also merged latest changes from master to my branch and checked [TC
status|http://ci.ignite.apache.org/viewLog.html?buildId=751953]; it hasn't
shown any test failures related to my change.
Thanks,
Sergey.
was (Author: sergey-chugunov):
[~sboikov], I've addressed both points:
* Removed unnecessary method and moved all checks to existing {{checkCache}}
method. I used it instead of proposed {{validateCacheGroupConfiguration}}
because the latter one is responsible for validating different caches within
the same cache group; while the former does exactly what I need: it compares
remote cache configuration with local one.
* Additional test case was created.
I also merged latest changes from master to my branch and checked [TC
status|http://ci.ignite.apache.org/viewLog.html?buildId=751953]; it hasn't
shown any test failures related to my change.
Thanks,
Sergey.
> Assertion failure in IgniteBasic test
> IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
>
> -
>
> Key: IGNITE-5542
> URL: https://issues.apache.org/jira/browse/IGNITE-5542
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Sergey Chugunov
> Labels: MakeTeamcityGreenAgain, test-fail
>
>
> http://ci.ignite.apache.org/viewLog.html?buildId=674131&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteBasic#testNameId-720637123828878
> org.apache.ignite.internal.processors.cache.IgniteCacheP2pUnmarshallingRebalanceErrorTest#testResponseMessageOnUnmarshallingFailed
> assertion failed,
> *stable reproducable locally*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5542) Assertion failure in IgniteBasic test IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
[
https://issues.apache.org/jira/browse/IGNITE-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110739#comment-16110739
]
Sergey Chugunov commented on IGNITE-5542:
-
[~sboikov], I've addressed both points:
* Removed unnecessary method and moved all checks to existing {{checkCache}}
method. I used it instead of proposed {{validateCacheGroupConfiguration}}
because the latter one is responsible for validating different caches within
the same cache group; while the former does exactly what I need: it compares
remote cache configuration with local one.
* Additional test case was created.
I also merged latest changes from master to my branch and checked [TC
status|http://ci.ignite.apache.org/viewLog.html?buildId=751953]; it hasn't
shown any test failures related to my change.
Thanks,
Sergey.
> Assertion failure in IgniteBasic test
> IgniteCacheP2pUnmarshallingRebalanceErrorTest.testResponseMessageOnUnmarshallingFailed
>
> -
>
> Key: IGNITE-5542
> URL: https://issues.apache.org/jira/browse/IGNITE-5542
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Sergey Chugunov
> Labels: MakeTeamcityGreenAgain, test-fail
>
>
> http://ci.ignite.apache.org/viewLog.html?buildId=674131&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteBasic#testNameId-720637123828878
> org.apache.ignite.internal.processors.cache.IgniteCacheP2pUnmarshallingRebalanceErrorTest#testResponseMessageOnUnmarshallingFailed
> assertion failed,
> *stable reproducable locally*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5655) Introduce pluggable string encoder/decoder
[
https://issues.apache.org/jira/browse/IGNITE-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-5655:
-
Description:
Currently binary marshaller encodes strings in UTF-8. However, sometimes it
makes sense to serialize strings with different encodings to save space. Let's
add global property to control String encoding and customize our binary
protocol to support it. For instance, we can add another flag
{{ENCODED_STRING}}, which will write strings as follows:
[flag][encoding_flag][str_len][str_bytes]
First implementation should set preferred encoding for strings in
BinaryConfiguration. This setting is optional, default encoding is UTF-8.
Currently, the same BinaryConfiguration is used for all cluster nodes, thus no
encoding clashes are possible.
was:
Currently binary marshaller encodes strings in UTF-8. However, sometimes it
makes sense to serialize strings with different encodings to save space. Let's
add global property to control String encoding and customize our binary
protocol to support it. For instance, we can add another flag
{{ENCODED_STRING}}, which will write strings as follows:
[flag][encoding_flag][str_len][str_bytes]
> Introduce pluggable string encoder/decoder
> --
>
> Key: IGNITE-5655
> URL: https://issues.apache.org/jira/browse/IGNITE-5655
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Andrey Kuznetsov
> Fix For: 2.2
>
>
> Currently binary marshaller encodes strings in UTF-8. However, sometimes it
> makes sense to serialize strings with different encodings to save space.
> Let's add global property to control String encoding and customize our binary
> protocol to support it. For instance, we can add another flag
> {{ENCODED_STRING}}, which will write strings as follows:
> [flag][encoding_flag][str_len][str_bytes]
> First implementation should set preferred encoding for strings in
> BinaryConfiguration. This setting is optional, default encoding is UTF-8.
> Currently, the same BinaryConfiguration is used for all cluster nodes, thus
> no encoding clashes are possible.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5890) Add estimated time to rebalance completion and time to rebalance start to MXBean
[ https://issues.apache.org/jira/browse/IGNITE-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-5890: -- Assignee: Dmitriy Govorukhin > Add estimated time to rebalance completion and time to rebalance start to > MXBean > > > Key: IGNITE-5890 > URL: https://issues.apache.org/jira/browse/IGNITE-5890 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Alexey Goncharuk >Assignee: Dmitriy Govorukhin > Fix For: 2.2 > > > We already have rebalance speed metrics on MXBean, would be nice to see time > to rebalance start (when delayed rebalancing is used) and estimated time to > rebalance completion. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5906) Web Console backend failed with error 11000
Alexey Kuznetsov created IGNITE-5906: Summary: Web Console backend failed with error 11000 Key: IGNITE-5906 URL: https://issues.apache.org/jira/browse/IGNITE-5906 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 2.2 Reporter: Alexey Kuznetsov Assignee: Andrey Novikov Fix For: 2.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5905) .NET: Thin client: cache.Get for primitives
Pavel Tupitsyn created IGNITE-5905:
--
Summary: .NET: Thin client: cache.Get for primitives
Key: IGNITE-5905
URL: https://issues.apache.org/jira/browse/IGNITE-5905
Project: Ignite
Issue Type: Task
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.2
IGNITE-5899 implements cache.Get on Java side and includes a simple raw socket
test.
Next step is to provide .NET thin client foundation, so that user can call
something like
{{Ignition.GetClient(ClientConfiguration).GetCache(string).Get(...)}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5899) Thin client: cache.Get for primitives
[
https://issues.apache.org/jira/browse/IGNITE-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-5899:
--
Assignee: Vladimir Ozerov (was: Pavel Tupitsyn)
> Thin client: cache.Get for primitives
> -
>
> Key: IGNITE-5899
> URL: https://issues.apache.org/jira/browse/IGNITE-5899
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Labels: .NET
> Fix For: 2.2
>
>
> Implement {{cache.Get}} for primitive data types via thin client protocol.
> This will include:
> * New client type in {{SqlListenerNioListener}}
> * {{PlatformRequestHandler implements SqlListenerRequestHandler}},
> {{PlatformMessageParser implements SqlListenerMessageParser}}
> * Integration test in .NET (just because .NET is the first platform to adopt
> this; we could do tests in Java as well, but this is redundant for now)
> Support only primitive types for now to avoid dealing with bynary type
> metadata, schemas, compact footers, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5899) Thin client: cache.Get for primitives
[
https://issues.apache.org/jira/browse/IGNITE-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110678#comment-16110678
]
Pavel Tupitsyn commented on IGNITE-5899:
Done, [~vozerov] please have a look.
> Thin client: cache.Get for primitives
> -
>
> Key: IGNITE-5899
> URL: https://issues.apache.org/jira/browse/IGNITE-5899
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.2
>
>
> Implement {{cache.Get}} for primitive data types via thin client protocol.
> This will include:
> * New client type in {{SqlListenerNioListener}}
> * {{PlatformRequestHandler implements SqlListenerRequestHandler}},
> {{PlatformMessageParser implements SqlListenerMessageParser}}
> * Integration test in .NET (just because .NET is the first platform to adopt
> this; we could do tests in Java as well, but this is redundant for now)
> Support only primitive types for now to avoid dealing with bynary type
> metadata, schemas, compact footers, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5899) Thin client: cache.Get for primitives
[
https://issues.apache.org/jira/browse/IGNITE-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110676#comment-16110676
]
ASF GitHub Bot commented on IGNITE-5899:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/2376
IGNITE-5899 Thin client: cache.Get for primitives
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5899
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2376.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2376
commit 25c16ecc1f3aac8379ae430572baceaf5116a827
Author: Pavel Tupitsyn
Date: 2017-08-02T10:23:06Z
IGNITE-5899 Thin client: cache.Get for primitives
> Thin client: cache.Get for primitives
> -
>
> Key: IGNITE-5899
> URL: https://issues.apache.org/jira/browse/IGNITE-5899
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.2
>
>
> Implement {{cache.Get}} for primitive data types via thin client protocol.
> This will include:
> * New client type in {{SqlListenerNioListener}}
> * {{PlatformRequestHandler implements SqlListenerRequestHandler}},
> {{PlatformMessageParser implements SqlListenerMessageParser}}
> * Integration test in .NET (just because .NET is the first platform to adopt
> this; we could do tests in Java as well, but this is redundant for now)
> Support only primitive types for now to avoid dealing with bynary type
> metadata, schemas, compact footers, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions
[
https://issues.apache.org/jira/browse/IGNITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110663#comment-16110663
]
Alexandr Fedotov edited comment on IGNITE-4172 at 8/2/17 10:14 AM:
---
Apart from the improvements introduced by
[IGNITE-5483|https://issues.apache.org/jira/browse/IGNITE-5483] the following
should be addressed:
1. {{java.time.LocalTime}}, {{java.time.LocalDate}},
{{java.time.LocalDateTime}} are not supported as cache values or keys.
2. LocalDateTime is stored as Timestamp, which should be accounted when
applying a custom SQL functions. Probably that's a tradeoff for the moment.
was (Author: asfedotov):
Apart from the improvements introduced by
[IGNITE-5483|https://issues.apache.org/jira/browse/IGNITE-5483] the following
should be addressed:
1. {{java.time.LocalTime}}, {{java.time.LocalDate}},
{{java.time.LocalDateTime}} are not supported as cache values or keys.
2. LocalDateTime is stored as Timestamp, which should be accounted when
applying a custom SQL functions.
> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
> Fix For: 2.2
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine.
> Next query can fails with error, if one of row localDateTimeField value has
> zero-time:
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method.
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions
[
https://issues.apache.org/jira/browse/IGNITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110663#comment-16110663
]
Alexandr Fedotov commented on IGNITE-4172:
--
Apart from the improvements introduced by
[IGNITE-5483|https://issues.apache.org/jira/browse/IGNITE-5483] the following
should be addressed:
1. {{java.time.LocalTime}}, {{java.time.LocalDate}},
{{java.time.LocalDateTime}} are not supported as cache values or keys.
2. LocalDateTime is stored as Timestamp, which should be accounted when
applying a custom SQL functions.
> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
> Fix For: 2.2
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine.
> Next query can fails with error, if one of row localDateTimeField value has
> zero-time:
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method.
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5572) DDL: Support ALTER TABLE ADD COLUMN
[
https://issues.apache.org/jira/browse/IGNITE-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110655#comment-16110655
]
Vladimir Ozerov commented on IGNITE-5572:
-
[~al.psc], prelimitar comments:
1) There is not need to restrict alter operation to {{PUBLIC}} schema only.
This restriction makes sense only for tables.
2) Let's remove support for {{BEFORE}} and {{AFTER}} statements. With current
implementation this is merely a cosmetic change for {{SELECT *}} query, it
doesn't affect any Ignite storage internals. Hence, no need to expose it to
users.
3) {{runDdlStatement}} - there is no need to have separate if-else branches
when there are one or more than one columns; this is a micro-optimization in
non-performance-sensitive place, which optimizes nothing.
4) We need to throw exceptions for unsupported futures [1]: {{NOT NULL}},
{{UNIQUE}}, {{VISIBLE}}, {{INVISIBLE}}, {{DEFAULT}}, {{AS}},
{{AUTO_INCREMENT}}, {{IDENTITY}}, {{SELECTIVITY}} , {{COMMENT}}, {{HASH}},
{{CHECK}}. I think we missed this piece for {{CREATE TABLE}} as well. Let's
create a common fix for both.
5) {{IgniteH2Indexing.dynamicAddColumn}} - we must re-create SQL script and
execute it over H2 engine in the same way we did that for other DDL commands.
Otherwise we are risking that some H2 internals will not reflect the changes,
or that improper locking will be applied.
[1] http://www.h2database.com/html/grammar.html#column_definition
> DDL: Support ALTER TABLE ADD COLUMN
> ---
>
> Key: IGNITE-5572
> URL: https://issues.apache.org/jira/browse/IGNITE-5572
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.2
>
>
> We should start gradual implementation of {{ALTER TABLE}} command. Let's
> start with the most simple part - {{ADD COLUMN}}. Proposed design:
> 1) Send a message over a ring, similar to how we do that for create index
> 2) On local node: update relevant QueryEntity, update data strcutrues in
> {{GridQueryProcessor}}, update {{IgniteH2Indexing}} data structures, execute
> {{ALTER TABLE}} command on H2 database (global table lock must be acquired).
> 3) Make sure that update to {{QueryEntity}} is properly saved if persistence
> is enabled.
> Feature should be covered with tests thoroughly:
> 1) Positive cases
> 2) Negative cases (no schema, no table, column already exists)
> 3) Test with concurrent SQL operations
> 4) Test with concurrent node restarts
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5896) Thin client protocol
[
https://issues.apache.org/jira/browse/IGNITE-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110646#comment-16110646
]
Pavel Tupitsyn edited comment on IGNITE-5896 at 8/2/17 9:56 AM:
Added {{uint32 requestId}} to the protocol, so that client can match response
in future multithreaded scenarios.
was (Author: ptupitsyn):
Added {{uint32}} requestId to the protocol, so that client can match response
in future multithreaded scenarios.
> Thin client protocol
>
>
> Key: IGNITE-5896
> URL: https://issues.apache.org/jira/browse/IGNITE-5896
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 2.2
>
>
> Implement a protocol for thin clients in other languages.
> This is an umbrella ticket for all related activities.
> *Overview:*
> * Client connects to a socket (according to {{SqlConnectorConfiguration}})
> * There is a new client type is {{SqlListenerNioListener}}
> * Ignite binary protocol is used for data exchange (BinaryMarshaller)
> * Protocol is stateless (though socket can be reused for multiple operations)
> *Socket request message format:*
> * {{uint32}} Message length
> * {{uint32}} Request id
> * {{byte}} Flags (compression, etc)
> * {{uint16}} Operation code (like CacheGet or MessagingSend)
> * Operation-specific data
> *Socket response message format:*
> * {{uint32}} Message length
> * {{uint32}} Request id (value from above)
> * {{byte}} Flags (success, compression, etc)
> * Operation-specific data or exception details
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5896) Thin client protocol
[
https://issues.apache.org/jira/browse/IGNITE-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110646#comment-16110646
]
Pavel Tupitsyn commented on IGNITE-5896:
Added {{uint32}} requestId to the protocol, so that client can match response
in future multithreaded scenarios.
> Thin client protocol
>
>
> Key: IGNITE-5896
> URL: https://issues.apache.org/jira/browse/IGNITE-5896
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 2.2
>
>
> Implement a protocol for thin clients in other languages.
> This is an umbrella ticket for all related activities.
> *Overview:*
> * Client connects to a socket (according to {{SqlConnectorConfiguration}})
> * There is a new client type is {{SqlListenerNioListener}}
> * Ignite binary protocol is used for data exchange (BinaryMarshaller)
> * Protocol is stateless (though socket can be reused for multiple operations)
> *Socket request message format:*
> * {{uint32}} Message length
> * {{uint32}} Request id
> * {{byte}} Flags (compression, etc)
> * {{uint16}} Operation code (like CacheGet or MessagingSend)
> * Operation-specific data
> *Socket response message format:*
> * {{uint32}} Message length
> * {{uint32}} Request id (value from above)
> * {{byte}} Flags (success, compression, etc)
> * Operation-specific data or exception details
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5896) Thin client protocol
[
https://issues.apache.org/jira/browse/IGNITE-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-5896:
---
Description:
Implement a protocol for thin clients in other languages.
This is an umbrella ticket for all related activities.
*Overview:*
* Client connects to a socket (according to {{SqlConnectorConfiguration}})
* There is a new client type is {{SqlListenerNioListener}}
* Ignite binary protocol is used for data exchange (BinaryMarshaller)
* Protocol is stateless (though socket can be reused for multiple operations)
*Socket request message format:*
* {{uint32}} Message length
* {{uint32}} Request id
* {{byte}} Flags (compression, etc)
* {{uint16}} Operation code (like CacheGet or MessagingSend)
* Operation-specific data
*Socket response message format:*
* {{uint32}} Message length
* {{uint32}} Request id (value from above)
* {{byte}} Flags (success, compression, etc)
* Operation-specific data or exception details
was:
Implement a protocol for thin clients in other languages.
This is an umbrella ticket for all related activities.
*Overview:*
* Client connects to a socket (according to {{SqlConnectorConfiguration}})
* There is a new client type is {{SqlListenerNioListener}}
* Ignite binary protocol is used for data exchange (BinaryMarshaller)
* Protocol is stateless (though socket can be reused for multiple operations)
*Socket request message format:*
* {{uint32}} Message length
* {{byte}} Flags (compression, etc)
* {{uint16}} Operation code (like CacheGet or MessagingSend)
* Operation-specific data
*Socket response message format:*
* {{uint32}} Message length
* {{byte}} Flags (success, compression, etc)
* Operation-specific data or exception details
> Thin client protocol
>
>
> Key: IGNITE-5896
> URL: https://issues.apache.org/jira/browse/IGNITE-5896
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 2.2
>
>
> Implement a protocol for thin clients in other languages.
> This is an umbrella ticket for all related activities.
> *Overview:*
> * Client connects to a socket (according to {{SqlConnectorConfiguration}})
> * There is a new client type is {{SqlListenerNioListener}}
> * Ignite binary protocol is used for data exchange (BinaryMarshaller)
> * Protocol is stateless (though socket can be reused for multiple operations)
> *Socket request message format:*
> * {{uint32}} Message length
> * {{uint32}} Request id
> * {{byte}} Flags (compression, etc)
> * {{uint16}} Operation code (like CacheGet or MessagingSend)
> * Operation-specific data
> *Socket response message format:*
> * {{uint32}} Message length
> * {{uint32}} Request id (value from above)
> * {{byte}} Flags (success, compression, etc)
> * Operation-specific data or exception details
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5678) Need to document and test supported and unsupported SQL features
[ https://issues.apache.org/jira/browse/IGNITE-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-5678: --- Assignee: (was: Vladimir Ozerov) > Need to document and test supported and unsupported SQL features > > > Key: IGNITE-5678 > URL: https://issues.apache.org/jira/browse/IGNITE-5678 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Reporter: Dmitriy Setrakyan >Priority: Critical > Fix For: 2.2 > > > We should provide supported and unsupported feature documentation, similar to > PostgreSQL: https://www.postgresql.org/docs/devel/static/features.html > We can do the following: > * Have a very detailed documented list of all the supported/unsupported > features in Ignite SQL engine. > * Once the list is created, ensure that we have sufficient test coverage for > all the supported features. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5608) SQL scripts execution capability
[ https://issues.apache.org/jira/browse/IGNITE-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5608: Issue Type: New Feature (was: Task) > SQL scripts execution capability > > > Key: IGNITE-5608 > URL: https://issues.apache.org/jira/browse/IGNITE-5608 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Denis Magda > > There should be a way to feed an SQL script to Ignite and execute it right > away. A script can consist of DDL command that will define cluster and SQL > configuration as well as of DML commands that, for instance, preload data > into Ignite. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5712) Context switching for optimistic transactions
[ https://issues.apache.org/jira/browse/IGNITE-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110603#comment-16110603 ] ASF GitHub Bot commented on IGNITE-5712: Github user nizhikov closed the pull request at: https://github.com/apache/ignite/pull/2334 > Context switching for optimistic transactions > - > > Key: IGNITE-5712 > URL: https://issues.apache.org/jira/browse/IGNITE-5712 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Alexey Kuznetsov >Assignee: Nikolay Izhikov > Fix For: 2.2 > > > Implement context switching between threads for optimistic transactions -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5904) .NET: Improve array access in IBinaryReader and IBinaryRawReader
[
https://issues.apache.org/jira/browse/IGNITE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-5904:
---
Description:
Currently the only way to access array fields in {{IBinaryReader}} and
{{IBinaryRawReader}} is copying them entirely into a new instance:
{code}
byte[] ReadByteArray();
{code}
This does not allow reusing existing array (array pooling) or reading only a
part of the data (random access), which may hurt performance in certain use
cases.
Many .NET APIs provide an approach where existing array is used with index and
offset ({{Array.Copy}}, {{Socket.Receive}}, etc).
We can do a similar thing for *arrays of fixed-size elements* (byte, int, etc):
{code}
int ReadByteArray(byte[] dest, int destOffset, int srcOffset, int count);
{code}
was:
Currently the only way to work with array fields is reading them entirely into
a new instance:
{code}
byte[] ReadByteArray();
{code}
This does not allow reusing existing array (array pooling) or reading only a
part of the data (random access).
Many .NET APIs provide an approach where existing array is used with index and
offset ({{Array.Copy}}, {{Socket.Receive}}, etc).
We can do a similar thing for *arrays of fixed-size elements* (byte, int, etc):
{code}
int ReadByteArray(byte[] dest, int destOffset, int srcOffset, int count);
{code}
> .NET: Improve array access in IBinaryReader and IBinaryRawReader
>
>
> Key: IGNITE-5904
> URL: https://issues.apache.org/jira/browse/IGNITE-5904
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
> Labels: .NET
>
> Currently the only way to access array fields in {{IBinaryReader}} and
> {{IBinaryRawReader}} is copying them entirely into a new instance:
> {code}
> byte[] ReadByteArray();
> {code}
> This does not allow reusing existing array (array pooling) or reading only a
> part of the data (random access), which may hurt performance in certain use
> cases.
> Many .NET APIs provide an approach where existing array is used with index
> and offset ({{Array.Copy}}, {{Socket.Receive}}, etc).
> We can do a similar thing for *arrays of fixed-size elements* (byte, int,
> etc):
> {code}
> int ReadByteArray(byte[] dest, int destOffset, int srcOffset, int count);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5904) .NET: Improve array access in IBinaryReader and IBinaryRawReader
[
https://issues.apache.org/jira/browse/IGNITE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-5904:
---
Description:
Currently the only way to work with array fields is reading them entirely into
a new instance:
{code}
byte[] ReadByteArray();
{code}
This does not allow reusing existing array (array pooling) or reading only a
part of the data (random access).
Many .NET APIs provide an approach where existing array is used with index and
offset ({{Array.Copy}}, {{Socket.Receive}}, etc).
We can do a similar thing for *arrays of fixed-size elements* (byte, int, etc):
{code}
int ReadByteArray(byte[] dest, int destOffset, int srcOffset, int count);
{code}
was:
Currently the only way to work with array fields is reading them entirely into
a new instance:
{code}
byte[] ReadByteArray();
{code}
This does not allow reusing existing array (array pooling) or reading only a
part of the data (random access).
Many .NET APIs provide an approach where existing array is used with index and
offset ({{Array.Copy}}, {{Socket.Receive}}, etc).
We can do a similar thing for *arrays of fixed-size elements*:
{code}
int ReadByteArray(byte[] dest, int destOffset, int srcOffset, int count);
{code}
> .NET: Improve array access in IBinaryReader and IBinaryRawReader
>
>
> Key: IGNITE-5904
> URL: https://issues.apache.org/jira/browse/IGNITE-5904
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
> Labels: .NET
>
> Currently the only way to work with array fields is reading them entirely
> into a new instance:
> {code}
> byte[] ReadByteArray();
> {code}
> This does not allow reusing existing array (array pooling) or reading only a
> part of the data (random access).
> Many .NET APIs provide an approach where existing array is used with index
> and offset ({{Array.Copy}}, {{Socket.Receive}}, etc).
> We can do a similar thing for *arrays of fixed-size elements* (byte, int,
> etc):
> {code}
> int ReadByteArray(byte[] dest, int destOffset, int srcOffset, int count);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5904) .NET: Improve array access in IBinaryReader and IBinaryRawReader
Pavel Tupitsyn created IGNITE-5904:
--
Summary: .NET: Improve array access in IBinaryReader and
IBinaryRawReader
Key: IGNITE-5904
URL: https://issues.apache.org/jira/browse/IGNITE-5904
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Currently the only way to work with array fields is reading them entirely into
a new instance:
{code}
byte[] ReadByteArray();
{code}
This does not allow reusing existing array (array pooling) or reading only a
part of the data (random access).
Many .NET APIs provide an approach where existing array is used with index and
offset ({{Array.Copy}}, {{Socket.Receive}}, etc).
We can do a similar thing for *arrays of fixed-size elements*:
{code}
int ReadByteArray(byte[] dest, int destOffset, int srcOffset, int count);
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5622) Streaming and batching for ODBC driver
[ https://issues.apache.org/jira/browse/IGNITE-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5622: Fix Version/s: (was: 2.2) > Streaming and batching for ODBC driver > -- > > Key: IGNITE-5622 > URL: https://issues.apache.org/jira/browse/IGNITE-5622 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Denis Magda > > Ignite ODBC driver has to support both streaming and batching mode is a > similar way it's done for JDBC: > http://apache-ignite-developers.2346864.n4.nabble.com/Batch-DML-queries-design-discussion-td12859.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5622) Streaming and batching for ODBC driver
[ https://issues.apache.org/jira/browse/IGNITE-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5622: Issue Type: New Feature (was: Task) > Streaming and batching for ODBC driver > -- > > Key: IGNITE-5622 > URL: https://issues.apache.org/jira/browse/IGNITE-5622 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Denis Magda > > Ignite ODBC driver has to support both streaming and batching mode is a > similar way it's done for JDBC: > http://apache-ignite-developers.2346864.n4.nabble.com/Batch-DML-queries-design-discussion-td12859.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4575) Implement in Ignite wrapper for enums based on H2 user value type
[ https://issues.apache.org/jira/browse/IGNITE-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4575: Labels: (was: important) > Implement in Ignite wrapper for enums based on H2 user value type > - > > Key: IGNITE-4575 > URL: https://issues.apache.org/jira/browse/IGNITE-4575 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Alexander Paschenko >Assignee: Sergey Kalashnikov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4575) Implement in Ignite wrapper for enums based on H2 user value type
[ https://issues.apache.org/jira/browse/IGNITE-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4575: Issue Type: New Feature (was: Task) > Implement in Ignite wrapper for enums based on H2 user value type > - > > Key: IGNITE-4575 > URL: https://issues.apache.org/jira/browse/IGNITE-4575 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Alexander Paschenko >Assignee: Sergey Kalashnikov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5738) Add support of batch requests for jdbc2
[ https://issues.apache.org/jira/browse/IGNITE-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5738: Fix Version/s: 2.2 > Add support of batch requests for jdbc2 > --- > > Key: IGNITE-5738 > URL: https://issues.apache.org/jira/browse/IGNITE-5738 > Project: Ignite > Issue Type: New Feature > Components: jdbc >Reporter: Evgenii Zhuravlev >Assignee: Sergey Kalashnikov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5738) Add support of batch requests for jdbc2
[ https://issues.apache.org/jira/browse/IGNITE-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5738: Issue Type: New Feature (was: Improvement) > Add support of batch requests for jdbc2 > --- > > Key: IGNITE-5738 > URL: https://issues.apache.org/jira/browse/IGNITE-5738 > Project: Ignite > Issue Type: New Feature > Components: jdbc >Reporter: Evgenii Zhuravlev >Assignee: Sergey Kalashnikov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5126) JDBC thin driver: support batches
[ https://issues.apache.org/jira/browse/IGNITE-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5126: Issue Type: New Feature (was: Task) > JDBC thin driver: support batches > -- > > Key: IGNITE-5126 > URL: https://issues.apache.org/jira/browse/IGNITE-5126 > Project: Ignite > Issue Type: New Feature > Components: jdbc >Affects Versions: 1.9 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > > Support batches operations for the thin JDBC driver. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5621) CPP: Support BINARY and VARBINARY types for C++
[
https://issues.apache.org/jira/browse/IGNITE-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5621:
Issue Type: New Feature (was: Task)
> CPP: Support BINARY and VARBINARY types for C++
> ---
>
> Key: IGNITE-5621
> URL: https://issues.apache.org/jira/browse/IGNITE-5621
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
> Labels: cpp
> Fix For: 2.2
>
>
> We need to add an ability for user to get columns of {{byte[]}} types using
> {{SqlFieldsQuery}} in C\+\+. Also, we need to add ability to add SQL
> parameters of type {{byte[]}} using C\+\+.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5211) Classes based constructor for QueryEntities
[
https://issues.apache.org/jira/browse/IGNITE-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16109039#comment-16109039
]
Taras Ledkov edited comment on IGNITE-5211 at 8/2/17 8:42 AM:
--
[Tests
results|http://195.239.208.174/project.html?projectId=Ignite20Tests&tab=projectOverview&branch_Ignite20Tests=pull%2F2371%2Fhead]
are OK with me.
[~vozerov], please review the changes.
was (Author: tledkov-gridgain):
Waits for [tests
results|http://195.239.208.174/project.html?projectId=Ignite20Tests&tab=projectOverview&branch_Ignite20Tests=pull%2F2371%2Fhead]
> Classes based constructor for QueryEntities
> ---
>
> Key: IGNITE-5211
> URL: https://issues.apache.org/jira/browse/IGNITE-5211
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.2
>
>
> We need to add constructor {{QueryEntity(Class keyType, Class valueType)}} to
> query entities class and deprecate {{CacheConfiguration.setIndexedTypes(…)}}
> method.
> Otherwise, there is no easy way for people who define SQL scheme with the
> annotations to do advanced settings like names of key and value objects,
> table name, etc.
> See this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/SQL-setting-key-field-name-for-types-registered-via-CacheConfiguration-setIndexedTypes-td17603.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5896) Thin client protocol
[
https://issues.apache.org/jira/browse/IGNITE-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110542#comment-16110542
]
Pavel Tupitsyn commented on IGNITE-5896:
Dev list discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Thin-client-protocol-message-format-td20300.html
> Thin client protocol
>
>
> Key: IGNITE-5896
> URL: https://issues.apache.org/jira/browse/IGNITE-5896
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 2.2
>
>
> Implement a protocol for thin clients in other languages.
> This is an umbrella ticket for all related activities.
> *Overview:*
> * Client connects to a socket (according to {{SqlConnectorConfiguration}})
> * There is a new client type is {{SqlListenerNioListener}}
> * Ignite binary protocol is used for data exchange (BinaryMarshaller)
> * Protocol is stateless (though socket can be reused for multiple operations)
> *Socket request message format:*
> * {{uint32}} Message length
> * {{byte}} Flags (compression, etc)
> * {{uint16}} Operation code (like CacheGet or MessagingSend)
> * Operation-specific data
> *Socket response message format:*
> * {{uint32}} Message length
> * {{byte}} Flags (success, compression, etc)
> * Operation-specific data or exception details
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5903) .NET: Add tests for CREATE/DROP table/index
Pavel Tupitsyn created IGNITE-5903:
--
Summary: .NET: Add tests for CREATE/DROP table/index
Key: IGNITE-5903
URL: https://issues.apache.org/jira/browse/IGNITE-5903
Project: Ignite
Issue Type: Improvement
Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
Fix For: 2.2
CREATE/DROP table/index functionality is available in .NET via {{QueryFields}},
no changes required. Add tests to make sure it works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110513#comment-16110513 ] Vladislav Pyatkov edited comment on IGNITE-5038 at 8/2/17 8:24 AM: --- I had prepared a benchmark which demonstrate a performance with custom class loader. Look at the result: [^results-compound-20170802.zip] PR with the benchmark source here: https://github.com/apache/ignite/pull/2375. was (Author: v.pyatkov): I had prepared a benchmark which demonstrate a performance with custom class loader. Look at the result: [~results-compound-20170802.zip] PR with the benchmark source here: https://github.com/apache/ignite/pull/2375. > BinaryMarshaller might need to use context class loader for deserialization > --- > > Key: IGNITE-5038 > URL: https://issues.apache.org/jira/browse/IGNITE-5038 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Vladislav Pyatkov > Labels: features > Fix For: 2.2 > > Attachments: results-compound-20170802.zip > > > There is a special use case discussed on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224 > According to the use case, BinaryMarshaller might need to try to deserialize > an object using a context class loader if it failed to do so with a custom > classloader (`IgniteConfiguration.getClassLoader()`) or the system one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5902) Refactor VisorCacheStopTask to support stopping several caches at once
Alexey Kuznetsov created IGNITE-5902: Summary: Refactor VisorCacheStopTask to support stopping several caches at once Key: IGNITE-5902 URL: https://issues.apache.org/jira/browse/IGNITE-5902 Project: Ignite Issue Type: Improvement Components: wizards Affects Versions: 2.1 Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.2 Stopping several caches at once much more faster then one-by-one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110513#comment-16110513 ] Vladislav Pyatkov commented on IGNITE-5038: --- I had prepared a benchmark which demonstrate a performance with custom class loader. Look at the result: [~results-compound-20170802.zip] PR with the benchmark source here: https://github.com/apache/ignite/pull/2375. > BinaryMarshaller might need to use context class loader for deserialization > --- > > Key: IGNITE-5038 > URL: https://issues.apache.org/jira/browse/IGNITE-5038 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Vladislav Pyatkov > Labels: features > Fix For: 2.2 > > Attachments: results-compound-20170802.zip > > > There is a special use case discussed on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224 > According to the use case, BinaryMarshaller might need to try to deserialize > an object using a context class loader if it failed to do so with a custom > classloader (`IgniteConfiguration.getClassLoader()`) or the system one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-5038: -- Attachment: results-compound-20170802.zip > BinaryMarshaller might need to use context class loader for deserialization > --- > > Key: IGNITE-5038 > URL: https://issues.apache.org/jira/browse/IGNITE-5038 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Vladislav Pyatkov > Labels: features > Fix For: 2.2 > > Attachments: results-compound-20170802.zip > > > There is a special use case discussed on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224 > According to the use case, BinaryMarshaller might need to try to deserialize > an object using a context class loader if it failed to do so with a custom > classloader (`IgniteConfiguration.getClassLoader()`) or the system one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
