[jira] [Commented] (IGNITE-3894) Web console: On import of database Java class/field's names should be valid Java names
[ https://issues.apache.org/jira/browse/IGNITE-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631872#comment-15631872 ] Vasiliy Sisko commented on IGNITE-3894: --- Already implemented and merged > Web console: On import of database Java class/field's names should be valid > Java names > -- > > Key: IGNITE-3894 > URL: https://issues.apache.org/jira/browse/IGNITE-3894 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.8 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 1.8 > > > We should process: > # java keywords > # H2 sql keywords > # Not valid java identifiers (for example starting with number) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-4078) Web console: pie chart is not refreshed in corner case
[ https://issues.apache.org/jira/browse/IGNITE-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko resolved IGNITE-4078. --- Resolution: Fixed Already implemented and merged. > Web console: pie chart is not refreshed in corner case > -- > > Key: IGNITE-4078 > URL: https://issues.apache.org/jira/browse/IGNITE-4078 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: IGNITE-4078.png > > > # execute SCAN > # open pie chart - you should see 'scan is not supported' > # write a valid query and Execute > Observed - no pie chart was painted, only legend is visible (see attachment) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3894) Web console: On import of database Java class/field's names should be valid Java names
[ https://issues.apache.org/jira/browse/IGNITE-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko closed IGNITE-3894. - > Web console: On import of database Java class/field's names should be valid > Java names > -- > > Key: IGNITE-3894 > URL: https://issues.apache.org/jira/browse/IGNITE-3894 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.8 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 1.8 > > > We should process: > # java keywords > # H2 sql keywords > # Not valid java identifiers (for example starting with number) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3877) Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as blockSize
[ https://issues.apache.org/jira/browse/IGNITE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-3877: --- Assignee: Vladimir Ozerov (was: Ivan Veselovsky) > Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as > blockSize > - > > Key: IGNITE-3877 > URL: https://issues.apache.org/jira/browse/IGNITE-3877 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Vladimir Ozerov > Fix For: 1.8 > > > During Metrics tests repairing test > org.apache.ignite.igfs.Hadoop1DualAbstractTest#testMetricsBlock revealed the > following problem: > org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem#convert(org.apache.ignite.igfs.IgfsFile) > method treats groupBlockSize as blockSize for Hadoop FileStatus. > groupBlockSize can be several times larger than blockSize, so blockSize in > status gets different to that in original IgfsFile . > changing file.groupBlockSize() to file.blockSize() fixes problem in metrics > tests, but creates problems in Hadoop tests that are bound to splits > calculation, since split calculation related to blockSizes. > Need to > 1) clarify if the treatment of groupBlcokSize was intentional. > 2) fix either metrics tests or Hadoop tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3877) Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as blockSize
[ https://issues.apache.org/jira/browse/IGNITE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3877: Assignee: Ivan Veselovsky (was: Vladimir Ozerov) > Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as > blockSize > - > > Key: IGNITE-3877 > URL: https://issues.apache.org/jira/browse/IGNITE-3877 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Ivan Veselovsky > Fix For: 1.8 > > > During Metrics tests repairing test > org.apache.ignite.igfs.Hadoop1DualAbstractTest#testMetricsBlock revealed the > following problem: > org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem#convert(org.apache.ignite.igfs.IgfsFile) > method treats groupBlockSize as blockSize for Hadoop FileStatus. > groupBlockSize can be several times larger than blockSize, so blockSize in > status gets different to that in original IgfsFile . > changing file.groupBlockSize() to file.blockSize() fixes problem in metrics > tests, but creates problems in Hadoop tests that are bound to splits > calculation, since split calculation related to blockSizes. > Need to > 1) clarify if the treatment of groupBlcokSize was intentional. > 2) fix either metrics tests or Hadoop tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (IGNITE-4078) Web console: pie chart is not refreshed in corner case
[ https://issues.apache.org/jira/browse/IGNITE-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reopened IGNITE-4078: --- > Web console: pie chart is not refreshed in corner case > -- > > Key: IGNITE-4078 > URL: https://issues.apache.org/jira/browse/IGNITE-4078 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: IGNITE-4078.png > > > # execute SCAN > # open pie chart - you should see 'scan is not supported' > # write a valid query and Execute > Observed - no pie chart was painted, only legend is visible (see attachment) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (IGNITE-4078) Web console: pie chart is not refreshed in corner case
[ https://issues.apache.org/jira/browse/IGNITE-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-4078: -- Comment: was deleted (was: Already implemented and merged.) > Web console: pie chart is not refreshed in corner case > -- > > Key: IGNITE-4078 > URL: https://issues.apache.org/jira/browse/IGNITE-4078 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: IGNITE-4078.png > > > # execute SCAN > # open pie chart - you should see 'scan is not supported' > # write a valid query and Execute > Observed - no pie chart was painted, only legend is visible (see attachment) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-4163) Wrong SQL generated by org.apache.ignite.cache.store.jdbc.dialect.BasicJdbcDialect#loadCacheSelectRangeQuery
[
https://issues.apache.org/jira/browse/IGNITE-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko reassigned IGNITE-4163:
-
Assignee: Vasiliy Sisko
> Wrong SQL generated by
> org.apache.ignite.cache.store.jdbc.dialect.BasicJdbcDialect#loadCacheSelectRangeQuery
>
>
> Key: IGNITE-4163
> URL: https://issues.apache.org/jira/browse/IGNITE-4163
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.7
>Reporter: Anghel Botos
>Assignee: Vasiliy Sisko
>
> The SQL statement generated by
> org.apache.ignite.cache.store.jdbc.dialect.BasicJdbcDialect#loadCacheSelectRangeQuery
> looks like this:
> {{SELECT KEY_COLUMN_1,KEY_COLUMN_2 FROM (SELECT KEY_COLUMN_1,KEY_COLUMN_2,
> ROWNUM() AS rn FROM SOME_TABLE ORDER BY KEY_COLUMN_1,KEY_COLUMN_2) WHERE
> mod(rn, ?) = 0}}
> For Oracle this is incorrect, as Oracle does not have a {{ROWNUM()}}
> function. For the above query the following error is thrown: {{ORA-00923:
> FROM keyword not found where expected}}
> Regarding row numbering Oracle has:
> * a {{ROWNUM}} pseudocolumn, in which case the query should have {{ROWNUM AS
> rn}}
> * a {{ROW_NUMBER()}} function, in which case the query would become more
> complicated. See
> https://docs.oracle.com/database/121/SQLRF/functions170.htm#SQLRF06100 for
> more details about {{ROW_NUMBER()}}
> Please make the neccessary adjustments to either {{BasicJdbcDialect}} or
> {{OracleDialect}} so that a correct query is produced.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-4139) .NET: improve the getting started guide
[ https://issues.apache.org/jira/browse/IGNITE-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632024#comment-15632024 ] Pavel Tupitsyn commented on IGNITE-4139: Looks good, thanks. > .NET: improve the getting started guide > --- > > Key: IGNITE-4139 > URL: https://issues.apache.org/jira/browse/IGNITE-4139 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Reporter: Denis Magda >Assignee: Pavel Tupitsyn > Fix For: 1.8 > > > The current guide > (https://apacheignite-net.readme.io/v1.7/docs/getting-started-2) is based on > the fact that you need to build a binary from sources. > We should demonstrate how it can be done with > ‘modules/platforms/dotnet/bin/Apache.Ignite.exe’ that is already available. > Next, we should showcase how we can change a configuration for this > Apache.Ignite.exe and refer to additional libs/dlls (aka assemblies). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4124) .NET: inconvenient to debug SQL issue from VisualStudio output
[ https://issues.apache.org/jira/browse/IGNITE-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632026#comment-15632026 ] Pavel Tupitsyn commented on IGNITE-4124: Looks good, thanks. > .NET: inconvenient to debug SQL issue from VisualStudio output > -- > > Key: IGNITE-4124 > URL: https://issues.apache.org/jira/browse/IGNITE-4124 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Reporter: Denis Magda >Assignee: Pavel Tupitsyn > Fix For: 1.8 > > > It's difficult or not clear how to debug wrong SQL queries from Visual > Studio. The output simply says that the query can't be parsed. > Let's try to improve the user experience here somehow. If it's possible to > get more details from Java stack trace it would be perfect. If there are some > existed VisualStudio hints then let's document them on this page > https://apacheignite-net.readme.io/docs/sql-queries -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4164) Add support for parallel loading of caches using custom SQL load queries in org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore#loadCache
[
https://issues.apache.org/jira/browse/IGNITE-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632037#comment-15632037
]
Alexey Kuznetsov commented on IGNITE-4164:
--
I think it will be very hard to implement.
But {{CacheAbstractJdbcStore}} already can process custom SQL queries in
parallel.
You could do it from user code like this:
{code}
cache.loadCache(null,
"someKeyClass", "select * from SomeTable where id < 1",
"someKeyClass", "select * from SomeTable where id >= 1 and id < 2",
.
"someKeyClass", "select * from SomeTable where id >= X and id < ")
{code}
All listed queries will be executed in parallel.
You may build such list of queries as array and pass it to
{{cache.loadCache()}} because
{{cache.loadCache()}} required second argument as {{Object ...args}}
If this work for you, please close this issue as {{Won't Fix}}.
> Add support for parallel loading of caches using custom SQL load queries in
> org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore#loadCache
> ---
>
> Key: IGNITE-4164
> URL: https://issues.apache.org/jira/browse/IGNITE-4164
> Project: Ignite
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 1.7
>Reporter: Anghel Botos
>
> Please add support for parallel loading of caches using custom SQL load
> queries in
> org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore#loadCache. For the
> moment this is not possible, as the current implementation performs the load
> for each entity type in the cache using a single
> {{LoadCacheCustomQueryWorker}}, as opposed to the the approach that is used
> when no custom SQL queries are provided for the load, where for each entity
> type, the load is distributed across several threads based on some ranges.
> While it may not be possible to support parralel load with any custom SQL
> query (as this would mean that Ignite would have to somehow understand the
> meaning of that custom query), it would still be a significant improvement if
> it would be possible to have the parallel load when providing a custom
> {{WHERE}} clause for each entity type (instead of a full custom query).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-4166) Web console: Add missed properties of POJO store configuration.
Vasiliy Sisko created IGNITE-4166: - Summary: Web console: Add missed properties of POJO store configuration. Key: IGNITE-4166 URL: https://issues.apache.org/jira/browse/IGNITE-4166 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 1.8 Reporter: Vasiliy Sisko Fix For: 1.8 Now configured only Dialect property. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4164) Add support for parallel loading of caches using custom SQL load queries in org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore#loadCache
[
https://issues.apache.org/jira/browse/IGNITE-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632164#comment-15632164
]
Anghel Botos commented on IGNITE-4164:
--
Indeed, it did not occur to me that I could pass several custom queries for
each individual key class. I will try out your suggestion and if everything
works out fine I will close the issue as {{Won't Fix}}
> Add support for parallel loading of caches using custom SQL load queries in
> org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore#loadCache
> ---
>
> Key: IGNITE-4164
> URL: https://issues.apache.org/jira/browse/IGNITE-4164
> Project: Ignite
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 1.7
>Reporter: Anghel Botos
>
> Please add support for parallel loading of caches using custom SQL load
> queries in
> org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore#loadCache. For the
> moment this is not possible, as the current implementation performs the load
> for each entity type in the cache using a single
> {{LoadCacheCustomQueryWorker}}, as opposed to the the approach that is used
> when no custom SQL queries are provided for the load, where for each entity
> type, the load is distributed across several threads based on some ranges.
> While it may not be possible to support parralel load with any custom SQL
> query (as this would mean that Ignite would have to somehow understand the
> meaning of that custom query), it would still be a significant improvement if
> it would be possible to have the parallel load when providing a custom
> {{WHERE}} clause for each entity type (instead of a full custom query).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-4155) Minor issues wth IgniteSemaphoreExample and HIbernateL2CacheExample
[
https://issues.apache.org/jira/browse/IGNITE-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632178#comment-15632178
]
ASF GitHub Bot commented on IGNITE-4155:
GitHub user sergey-chugunov-1985 opened a pull request:
https://github.com/apache/ignite/pull/1205
IGNITE-4155 minor fixes to examples
IgniteSemaphoreExample was fixed: it is possible to rerun example without
restarting cluster.
Errors in logs of HibernateL2CacheExample were fixed.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4155
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/1205.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 #1205
commit 3ccee5c8bffdbd27129a57ae3bdf52479ae5a817
Author: Sergey Chugunov
Date: 2016-10-31T14:33:43Z
IGNITE-4155 minor fixes to examples
> Minor issues wth IgniteSemaphoreExample and HIbernateL2CacheExample
> ---
>
> Key: IGNITE-4155
> URL: https://issues.apache.org/jira/browse/IGNITE-4155
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Minor
> Labels: newbie
>
> IgniteSemaphoreExample finishes fine for the first run but hangs on the
> second unless ignite cluster is restarted.
> HibernateL2CacheExample logs errors like this during run:
> {code}
> [17:14:25,147][ERROR][main][SchemaExport] HHH000389: Unsuccessful: alter
> table Post drop constraint FK_m7j5gwmpa7dklv5bnc41ertmi
> [17:14:25,147][ERROR][main][SchemaExport] Table "POST" not found; SQL
> statement:
> alter table Post drop constraint FK_m7j5gwmpa7dklv5bnc41ertmi [42102-191]
> {code}
> Errors don't prevent example from finishing but may lead to a confusion that
> something works improperly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3074) Optimize DHT atomic update future.
[ https://issues.apache.org/jira/browse/IGNITE-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632187#comment-15632187 ] Semen Boikov commented on IGNITE-3074: -- Hi Konstantin, Here are my comments: - looks like for GridDhtAtomicSingleUpdateFuture there can be only one ContinuousQueryClosure - please get rid of duplicated addWriteEntry/addNearWriteEntries methods Thanks! > Optimize DHT atomic update future. > -- > > Key: IGNITE-3074 > URL: https://issues.apache.org/jira/browse/IGNITE-3074 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Konstantin Dudkov > Labels: performance > Fix For: 1.8 > > > Current implementation of GridDhtAtomicUpdateFuture is less than optimal. > First of all, It allocates lots of collections. > We could improve that in several ways: > 1) Better encapsulate logic around DHT future/request/response, so that > collections are not exposed through methods directly. > 2) Implement specialized version for update with a single key (the most > common case). > Once done, we will be able to easily add single DHT request/response for more > efficient IO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3075) Implement single key-value pair DHT request/response for ATOMIC cache.
[ https://issues.apache.org/jira/browse/IGNITE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632259#comment-15632259 ] Semen Boikov commented on IGNITE-3075: -- Hi Konstantin, Here are my comments: - now forceTransformBackups mode is not supported, so GridDhtAtomicSingleUpdateTransformRequest is not needed - GridDhtAtomicSingleUpdateRequest.updateCntrs - there can be only one update counter - GridDhtAtomicSingleUpdateRequest now it have both 'keepBinary' and 'flags' fields, let's keep only 'flags' - in GridDhtAtomicSingleUpdateRequest there can be only 'near' or only 'regular' key/val pair - let's remove ttl, conflict fields from GridDhtAtomicSingleUpdateRequest (use regualr request if there are non-default values for these fields) - GridDhtAtomicSingleUpdateRequest.keys() creates collection, now I see only one call of 'GridDhtAtomicSingleUpdateRequest .keys()', try to get rid of this method Thanks! > Implement single key-value pair DHT request/response for ATOMIC cache. > -- > > Key: IGNITE-3075 > URL: https://issues.apache.org/jira/browse/IGNITE-3075 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Konstantin Dudkov > Labels: performance > Fix For: 1.8 > > > Need to implement specialized light-weight version of DHT request/response to > make the most common case - single KV update - more performant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3075) Implement single key-value pair DHT request/response for ATOMIC cache.
[
https://issues.apache.org/jira/browse/IGNITE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632286#comment-15632286
]
Vladimir Ozerov commented on IGNITE-3075:
-
>From what I remember about my old attempt to refactor that, good approach to
>deal with collection is to replace them with separate size and get-by-index
>methods (as our collections are Lists in this case):
Before:
{code}
Collection keys();
{code}
After:
{code}
int keysCount();
K key(int idx);
{code}
> Implement single key-value pair DHT request/response for ATOMIC cache.
> --
>
> Key: IGNITE-3075
> URL: https://issues.apache.org/jira/browse/IGNITE-3075
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Konstantin Dudkov
> Labels: performance
> Fix For: 1.8
>
>
> Need to implement specialized light-weight version of DHT request/response to
> make the most common case - single KV update - more performant.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-4163) Wrong SQL generated by org.apache.ignite.cache.store.jdbc.dialect.BasicJdbcDialect#loadCacheSelectRangeQuery
[
https://issues.apache.org/jira/browse/IGNITE-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko updated IGNITE-4163:
--
Attachment: IGNITE_4163_Oracle_specific_for_load_range_query_.patch
Implemented Oracle specific query for select range query.
> Wrong SQL generated by
> org.apache.ignite.cache.store.jdbc.dialect.BasicJdbcDialect#loadCacheSelectRangeQuery
>
>
> Key: IGNITE-4163
> URL: https://issues.apache.org/jira/browse/IGNITE-4163
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.7
>Reporter: Anghel Botos
>Assignee: Vasiliy Sisko
> Attachments: IGNITE_4163_Oracle_specific_for_load_range_query_.patch
>
>
> The SQL statement generated by
> org.apache.ignite.cache.store.jdbc.dialect.BasicJdbcDialect#loadCacheSelectRangeQuery
> looks like this:
> {{SELECT KEY_COLUMN_1,KEY_COLUMN_2 FROM (SELECT KEY_COLUMN_1,KEY_COLUMN_2,
> ROWNUM() AS rn FROM SOME_TABLE ORDER BY KEY_COLUMN_1,KEY_COLUMN_2) WHERE
> mod(rn, ?) = 0}}
> For Oracle this is incorrect, as Oracle does not have a {{ROWNUM()}}
> function. For the above query the following error is thrown: {{ORA-00923:
> FROM keyword not found where expected}}
> Regarding row numbering Oracle has:
> * a {{ROWNUM}} pseudocolumn, in which case the query should have {{ROWNUM AS
> rn}}
> * a {{ROW_NUMBER()}} function, in which case the query would become more
> complicated. See
> https://docs.oracle.com/database/121/SQLRF/functions170.htm#SQLRF06100 for
> more details about {{ROW_NUMBER()}}
> Please make the neccessary adjustments to either {{BasicJdbcDialect}} or
> {{OracleDialect}} so that a correct query is produced.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-4167) Add an option to avoid printing out sensitive data into logs
Semen Boikov created IGNITE-4167: Summary: Add an option to avoid printing out sensitive data into logs Key: IGNITE-4167 URL: https://issues.apache.org/jira/browse/IGNITE-4167 Project: Ignite Issue Type: Improvement Reporter: Denis Kholodov We are seeing sensitive cache data being output in ignite debug logging. I've tracked it down to at least two places: 1. GridToStringBuilder uses reflection to print all fields in cache objects that are not annotated with @GridToStringExclude 2. GridCacheMapEntry does a direct toString() call on the value objects in a debug log As a fabric platform, we won't always have control over the object classes being added to/retrieved from the cache. We must always assume that all keys and values are sensitive and should not be outputted in logs except in local debugging situations. To this end, we need a configuration option (turned OFF by default) that allows keys/values to be written to log messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4168) Cross-schema DML queries do not work as expected
[ https://issues.apache.org/jira/browse/IGNITE-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Paschenko updated IGNITE-4168: Summary: Cross-schema DML queries do not work as expected (was: Cross-schema DML queries do not work) > Cross-schema DML queries do not work as expected > > > Key: IGNITE-4168 > URL: https://issues.apache.org/jira/browse/IGNITE-4168 > Project: Ignite > Issue Type: Bug > Components: SQL >Reporter: Alexander Paschenko >Assignee: Alexander Paschenko > Fix For: 1.8 > > > When a DML query has schema (i.e. cache name) specified, it is ignored and > cache operations get carried out against the cache the 'query' method was > called upon which clearly is not right. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4168) Cross-schema DML queries do not work
Alexander Paschenko created IGNITE-4168: --- Summary: Cross-schema DML queries do not work Key: IGNITE-4168 URL: https://issues.apache.org/jira/browse/IGNITE-4168 Project: Ignite Issue Type: Bug Components: SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 When a DML query has schema (i.e. cache name) specified, it is ignored and cache operations get carried out against the cache the 'query' method was called upon which clearly is not right. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4169) Data streamer mode for DML
Alexander Paschenko created IGNITE-4169: --- Summary: Data streamer mode for DML Key: IGNITE-4169 URL: https://issues.apache.org/jira/browse/IGNITE-4169 Project: Ignite Issue Type: New Feature Components: SQL Reporter: Alexander Paschenko SQL INSERT and MERGE are supposed to support data streamer mode which should be turned on by JDBC connection string param. Note: particular details of usage means and implementation of this mode, as well as urgency of this feature are yet to be discussed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4169) Data streamer mode for DML
[ https://issues.apache.org/jira/browse/IGNITE-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4169: Issue Type: Sub-task (was: New Feature) Parent: IGNITE-2294 > Data streamer mode for DML > -- > > Key: IGNITE-4169 > URL: https://issues.apache.org/jira/browse/IGNITE-4169 > Project: Ignite > Issue Type: Sub-task > Components: SQL >Reporter: Alexander Paschenko > > SQL INSERT and MERGE are supposed to support data streamer mode which should > be turned on by JDBC connection string param. > Note: particular details of usage means and implementation of this mode, as > well as urgency of this feature are yet to be discussed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4168) Cross-schema DML queries do not work as expected
[ https://issues.apache.org/jira/browse/IGNITE-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4168: Issue Type: Sub-task (was: Bug) Parent: IGNITE-2294 > Cross-schema DML queries do not work as expected > > > Key: IGNITE-4168 > URL: https://issues.apache.org/jira/browse/IGNITE-4168 > Project: Ignite > Issue Type: Sub-task > Components: SQL >Reporter: Alexander Paschenko >Assignee: Alexander Paschenko > Fix For: 1.8 > > > When a DML query has schema (i.e. cache name) specified, it is ignored and > cache operations get carried out against the cache the 'query' method was > called upon which clearly is not right. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3830) Introduce benchmarks for DML operations
[ https://issues.apache.org/jira/browse/IGNITE-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Paschenko updated IGNITE-3830: Issue Type: Sub-task (was: Task) Parent: IGNITE-2294 > Introduce benchmarks for DML operations > --- > > Key: IGNITE-3830 > URL: https://issues.apache.org/jira/browse/IGNITE-3830 > Project: Ignite > Issue Type: Sub-task > Components: SQL, yardstick >Reporter: Alexander Paschenko >Assignee: Sergi Vladykin > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3830) Introduce benchmarks for DML operations
[ https://issues.apache.org/jira/browse/IGNITE-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Paschenko updated IGNITE-3830: Fix Version/s: 1.8 > Introduce benchmarks for DML operations > --- > > Key: IGNITE-3830 > URL: https://issues.apache.org/jira/browse/IGNITE-3830 > Project: Ignite > Issue Type: Sub-task > Components: SQL, yardstick >Reporter: Alexander Paschenko >Assignee: Sergi Vladykin > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4170) DML: Add tests for different identity resolvers
Vladimir Ozerov created IGNITE-4170: --- Summary: DML: Add tests for different identity resolvers Key: IGNITE-4170 URL: https://issues.apache.org/jira/browse/IGNITE-4170 Project: Ignite Issue Type: Sub-task Components: SQL Affects Versions: 1.7 Reporter: Vladimir Ozerov Assignee: Alexander Paschenko Priority: Minor Fix For: 1.8 We need to have separate tests for different modes: 1) When array-based identity is set; 2) When field-based identity is set; 3) When no identity is set and array-based is used as default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4171) DML: Print warning when no identity is set for type.
Vladimir Ozerov created IGNITE-4171: --- Summary: DML: Print warning when no identity is set for type. Key: IGNITE-4171 URL: https://issues.apache.org/jira/browse/IGNITE-4171 Project: Ignite Issue Type: Sub-task Components: SQL Affects Versions: 1.7 Reporter: Vladimir Ozerov Assignee: Alexander Paschenko Priority: Minor Fix For: 1.8 When no identity for type is set, we should do the following: 1) Pick array-based identity instance and use it for hash code generation 2) Print a warning, once per type, that array-based identity was used automatically, and resulting hash code unlikely to match hash function of a real type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3891) Enable writing hostname, rather than ipaddress for zookeeper discovery
[ https://issues.apache.org/jira/browse/IGNITE-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura closed IGNITE-3891. --- > Enable writing hostname, rather than ipaddress for zookeeper discovery > -- > > Key: IGNITE-3891 > URL: https://issues.apache.org/jira/browse/IGNITE-3891 > Project: Ignite > Issue Type: Improvement > Components: ignite-zookeeper >Affects Versions: 1.7 > Environment: docker >Reporter: John Watson > > We are using ignite in docker, with zookeeper discovery. We need to be able > to use the hostname, rather than the ip address, since the container-visible > ip address is not externally usable. > We would like an option in the TcpDiscoveryZookeeperIpFinder to use the > hostname, rather than ipaddress. This change would impact line 231, where > currently the ip address is being written. We suggest adding an option to the > class to use the hostname, rather than the ip address. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3891) Enable writing hostname, rather than ipaddress for zookeeper discovery
[
https://issues.apache.org/jira/browse/IGNITE-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura resolved IGNITE-3891.
-
Resolution: Won't Fix
{{AddressResolver}} should be used in this case.
> Enable writing hostname, rather than ipaddress for zookeeper discovery
> --
>
> Key: IGNITE-3891
> URL: https://issues.apache.org/jira/browse/IGNITE-3891
> Project: Ignite
> Issue Type: Improvement
> Components: ignite-zookeeper
>Affects Versions: 1.7
> Environment: docker
>Reporter: John Watson
>
> We are using ignite in docker, with zookeeper discovery. We need to be able
> to use the hostname, rather than the ip address, since the container-visible
> ip address is not externally usable.
> We would like an option in the TcpDiscoveryZookeeperIpFinder to use the
> hostname, rather than ipaddress. This change would impact line 231, where
> currently the ip address is being written. We suggest adding an option to the
> class to use the hostname, rather than the ip address.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-4126) .NET: add Swap SPI wrappers and/or default implementations
[ https://issues.apache.org/jira/browse/IGNITE-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632577#comment-15632577 ] ASF GitHub Bot commented on IGNITE-4126: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/1206 IGNITE-4126 .NET: add Swap SPI wrappers and/or default implementations You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-4126 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1206.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 #1206 commit a4c63ae113931615e940ada2411ebce32dba5db8 Author: iveselovskiy Date: 2016-09-30T07:45:13Z IGNITE-3998: IGFS: Enabled IgfsAbstractSelfTest.testCreateConsistencyMultithreaded. This closes #1129. commit a12298c0baf19407f3110ba3c4f0aab88b67946d Author: Igor Sapego Date: 2016-09-30T08:00:51Z IGNITE-3868: ODBC: Fixed connection string parsing. This closes #1051. commit 5e7ef8644ad824b87d4797e59133eb783ff8b098 Author: vozerov-gridgain Date: 2016-10-03T07:37:25Z Merge branch 'ignite-1.6.9' into ignite-1.6.10 commit 59b46d3e6ea073d054ca2262d676b055a74bbb1f Author: vozerov-gridgain Date: 2016-10-03T07:40:04Z IGNITE-2881: Fixed SPI queries. commit 0b66d2d7b695cf370a4b8a717844ad67742c6090 Author: sboikov Date: 2016-10-03T09:04:03Z ignite-3601 Do not check version on commit for read-only serializable transactions. commit 9f211e413332931f0fb1190744ddd7c7f38fd213 Author: tledkov-gridgain Date: 2016-10-03T09:26:12Z IGNITE-3645: IGFS: Local secondary: Implemented update() operation. This closes #1003. commit fa698d6fcfde0006423ef009337dbef58ac62515 Author: vozerov-gridgain Date: 2016-10-03T10:33:12Z Fixed TcpDiscoverySnapshotHistoryTest intermittent failures caused by multicast IP finder. commit bba019fd5076412ca43c10a32fd300b6031ccd0b Author: vozerov-gridgain Date: 2016-10-03T14:25:20Z IGNITE-3980: Processed failing tests in query suites. This closes #1137. commit a92f20b5cc75e6b80b2731da0192723526b0c1dc Author: vozerov-gridgain Date: 2016-10-04T11:10:26Z IGNITE-3597: Removed static work directory. commit 23461b8d33922772ef8e7217e9e87b3f3b0b37b1 Author: vozerov-gridgain Date: 2016-10-06T07:14:59Z IGNITE-4001: Timeouts for threads in Ignite pools. This closes #1130. commit b94b0aeae4c42b1d35128c6b1de97e3fa318d497 Author: tledkov-gridgain Date: 2016-10-06T07:22:50Z IGNITE-3163 IGFS: Added working directory support to IgniteHadoopIgfsSecondaryFileSystem. This closes #1030. This closes #1058. This closes #1132. commit e6317e01fa8a0de03e15dcdd84a575c6b06ce701 Author: vozerov-gridgain Date: 2016-10-06T09:03:48Z IGNITE-3593 .NET: IgniteConfiguration.WorkDirectory has no effect. This closes #903. This closes #1145. commit 952be8b995050b34379006dd6e739da3fe3b49e3 Author: Dmitriy Govorukhin Date: 2016-10-07T12:00:09Z Squashed commit of the following: commit 566881b695b8bc00e618fe9a9b4c86a8fd563cc1 Author: sboikov Date: Fri Oct 7 13:08:38 2016 +0300 minor commit 7fe88a1cb21f794ee55a176ab36d895cbf916528 Author: Dmitriy Govorukhin Date: Thu Oct 6 11:11:24 2016 +0300 ignite-update-notifier fix after review (cherry picked from commit a10d2ff) commit f2de749f958a3b18dc479f8a5517d7bf9362b933 Author: Dmitriy Govorukhin Date: Tue Oct 4 12:12:08 2016 +0300 ignite-2079-2 optimize import and change url path (cherry picked from commit 830a3cf) commit 0d1be85ad55b0aa91224690d6c112ae92e8bc0a9 Author: Dmitriy Govorukhin Date: Thu Sep 29 19:54:54 2016 +0300 update-notifier remove parse xml, now parse like properties (cherry picked from commit 9ecaa29) commit e43bca6fb4528a7fc0dcb804a74fca1c59d7468b Author: Dmitriy Govorukhin Date: Tue Sep 27 17:07:21 2016 +0300 remove dom parser (cherry picked from commit d1653b2) commit b9c776a8423471706ecb1dc6176b38f23e799077 Author: Anton Vinogradov Date: 2016-10-10T08:52:57Z IGNITE-3235 Failed to initialize primitive boolean cache property of superclass commit f9a0676fad7fd6c23e3c91c10d7e0412ccb27c06 Author: vozerov-gridgain Date: 2016-10-11T07:23:01Z IGNITE-4041: Created separate processor for thread pools and refactored IO manager. This closes #1150. commit 9a6cfce659df40b0a4624f19fd91c217b74bafea Author: nikolay_tikhonov Date: 2016-10-11T10:59:57Z IGNITE-4014 Fixed "Transaction hangs if entry processor failed during serialization". This closes #1148. commit 1938a17b01fac1e08c30011180bbcc3ed7374d83 Author: An
[jira] [Commented] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.
[ https://issues.apache.org/jira/browse/IGNITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632593#comment-15632593 ] Igor Sapego commented on IGNITE-3921: - Denis, Thanks a lot for your help! For the Unix systems we ship our driver in sources so user can compile it for any Driver Manager he wants to use (ibm_db2, unixODBC, generic). We have mostly tested it with unixODBC though. I agree that it should be mentioned and I'm going to add such a mention. > ODBC: Add documentation for the PDO interoperability. > - > > Key: IGNITE-3921 > URL: https://issues.apache.org/jira/browse/IGNITE-3921 > Project: Ignite > Issue Type: Task > Components: documentation, odbc >Affects Versions: 1.7 >Reporter: Igor Sapego >Assignee: Igor Sapego > Labels: documentation, odbc > Fix For: 1.8 > > > We have checked our ODBC driver for the compatibility with the PDO. Now we > need to document it for our users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.
[ https://issues.apache.org/jira/browse/IGNITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632593#comment-15632593 ] Igor Sapego edited comment on IGNITE-3921 at 11/3/16 12:31 PM: --- Denis, Thanks a lot for your help! For Unix systems we ship our driver in sources so user can compile it for any Driver Manager he wants to use (ibm_db2, unixODBC, generic). We have mostly tested it with unixODBC though. I agree that it should be mentioned and I'm going to add such a mention. was (Author: isapego): Denis, Thanks a lot for your help! For the Unix systems we ship our driver in sources so user can compile it for any Driver Manager he wants to use (ibm_db2, unixODBC, generic). We have mostly tested it with unixODBC though. I agree that it should be mentioned and I'm going to add such a mention. > ODBC: Add documentation for the PDO interoperability. > - > > Key: IGNITE-3921 > URL: https://issues.apache.org/jira/browse/IGNITE-3921 > Project: Ignite > Issue Type: Task > Components: documentation, odbc >Affects Versions: 1.7 >Reporter: Igor Sapego >Assignee: Igor Sapego > Labels: documentation, odbc > Fix For: 1.8 > > > We have checked our ODBC driver for the compatibility with the PDO. Now we > need to document it for our users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4172) SQL: support ISO-8601 date time format
Andrew Mashenkov created IGNITE-4172: Summary: SQL: support ISO-8601 date time format Key: IGNITE-4172 URL: https://issues.apache.org/jira/browse/IGNITE-4172 Project: Ignite Issue Type: Bug Affects Versions: 1.7, 1.6 Reporter: Andrew Mashenkov Fix For: 1.8 It seems H2 do not support ISO-8601 short time format "HH:mm". We need workaround here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4173) IgniteSemaphore with failoverSafe enabled doesn't release permits in case permits owner node left topology
Andrey Gura created IGNITE-4173:
---
Summary: IgniteSemaphore with failoverSafe enabled doesn't release
permits in case permits owner node left topology
Key: IGNITE-4173
URL: https://issues.apache.org/jira/browse/IGNITE-4173
Project: Ignite
Issue Type: Bug
Affects Versions: 1.7
Reporter: Andrey Gura
{{IgniteSemaphore}} with {{failoverSafe}} enabled doesn't release permits in
case permits owner node left topology.
See reproducer in test class {{SemaphoreFailoverSafeReleasePermitsTest}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-4173) IgniteSemaphore with failoverSafe enabled doesn't release permits in case permits owner node left topology
[
https://issues.apache.org/jira/browse/IGNITE-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-4173:
Fix Version/s: 1.8
> IgniteSemaphore with failoverSafe enabled doesn't release permits in case
> permits owner node left topology
> --
>
> Key: IGNITE-4173
> URL: https://issues.apache.org/jira/browse/IGNITE-4173
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Andrey Gura
> Fix For: 1.8
>
>
> {{IgniteSemaphore}} with {{failoverSafe}} enabled doesn't release permits in
> case permits owner node left topology.
> See reproducer in test class {{SemaphoreFailoverSafeReleasePermitsTest}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3074) Optimize DHT atomic update future.
[ https://issues.apache.org/jira/browse/IGNITE-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632629#comment-15632629 ] Konstantin Dudkov commented on IGNITE-3074: --- Semen, Thanks for your comments. I've done reword according to your comments, please take a look. > Optimize DHT atomic update future. > -- > > Key: IGNITE-3074 > URL: https://issues.apache.org/jira/browse/IGNITE-3074 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Konstantin Dudkov > Labels: performance > Fix For: 1.8 > > > Current implementation of GridDhtAtomicUpdateFuture is less than optimal. > First of all, It allocates lots of collections. > We could improve that in several ways: > 1) Better encapsulate logic around DHT future/request/response, so that > collections are not exposed through methods directly. > 2) Implement specialized version for update with a single key (the most > common case). > Once done, we will be able to easily add single DHT request/response for more > efficient IO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3999) Support case insensitive search in SQL
[
https://issues.apache.org/jira/browse/IGNITE-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amir Akhmedov reassigned IGNITE-3999:
-
Assignee: Amir Akhmedov
> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
> Fix For: 1.8
>
>
> Currently case insensitive search is possible only with the help of
> {{lower()}} function:
> {code}
> select name from MyValue where lower(name) = 'abc_5'
> {code}
> But this will always be a full scan, even if {{name}} field is indexed.
> We need to correctly support {{VARCHAR_IGNORECASE}} H2 type in Ignite and add
> a respective property to {{@QuerySqlField}} annotation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-4133) .NET: documentation and example for IBinaryObject and IBinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-4133.
Resolution: Fixed
> .NET: documentation and example for IBinaryObject and IBinaryObjectBuilder
> --
>
> Key: IGNITE-4133
> URL: https://issues.apache.org/jira/browse/IGNITE-4133
> Project: Ignite
> Issue Type: Sub-task
> Components: platforms
>Reporter: Denis Magda
> Fix For: 1.8
>
>
> There is no documentation on readme.io and example that would describe and
> show how to use {{IBinaryObject}} and {{IBinaryObjectBuilder}}.
> - the documentation can be take from Java
> https://apacheignite.readme.io/docs/binary-marshaller#binaryobject-cache-api
> - example should be similar to Java's {{CacheClientBinaryPutGetExample}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-4133) .NET: documentation and example for IBinaryObject and IBinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628210#comment-15628210
]
Pavel Tupitsyn edited comment on IGNITE-4133 at 11/3/16 2:56 PM:
-
Example already created as part of IGNITE-3630 (did not get into a release
yet), see Datagrid\BinaryModeExample.cs.
was (Author: ptupitsyn):
Example already created as part of IGNITE-3630 (did not get into a release yet).
> .NET: documentation and example for IBinaryObject and IBinaryObjectBuilder
> --
>
> Key: IGNITE-4133
> URL: https://issues.apache.org/jira/browse/IGNITE-4133
> Project: Ignite
> Issue Type: Sub-task
> Components: platforms
>Reporter: Denis Magda
> Fix For: 1.8
>
>
> There is no documentation on readme.io and example that would describe and
> show how to use {{IBinaryObject}} and {{IBinaryObjectBuilder}}.
> - the documentation can be take from Java
> https://apacheignite.readme.io/docs/binary-marshaller#binaryobject-cache-api
> - example should be similar to Java's {{CacheClientBinaryPutGetExample}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3999) Support case insensitive search in SQL
[
https://issues.apache.org/jira/browse/IGNITE-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632998#comment-15632998
]
Amir Akhmedov commented on IGNITE-3999:
---
[~vkulichenko], I have a concern on this ticket, can you please advise what
will be the correct way to solve it. As of today, fields are defined as
{{setFields(LinkedHashMap fields)}}, with introduction of case
insensitive property need to create a new POJO e.g. {{QueryField(String type,
boolean caseInsensitive)}}. So, to keep backward compatibility we can introduce
a new method e.g. {{setQueryFields(LinkedHashMap fields)}},
in my opinion it looks like counter-intuitive with existing {{setFields}}
method. Another possible way, this change can be done with changing the generic
type of {{setFields}} (which will not be backward competible) and released in
Ignite 2.0.
Please advise on this, or maybe you have an alternative solutions?
Thanks!
> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
> Fix For: 1.8
>
>
> Currently case insensitive search is possible only with the help of
> {{lower()}} function:
> {code}
> select name from MyValue where lower(name) = 'abc_5'
> {code}
> But this will always be a full scan, even if {{name}} field is indexed.
> We need to correctly support {{VARCHAR_IGNORECASE}} H2 type in Ignite and add
> a respective property to {{@QuerySqlField}} annotation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-4132) .NET: Binary configuration related improvements
[ https://issues.apache.org/jira/browse/IGNITE-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-4132: -- Assignee: Pavel Tupitsyn > .NET: Binary configuration related improvements > --- > > Key: IGNITE-4132 > URL: https://issues.apache.org/jira/browse/IGNITE-4132 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Reporter: Denis Magda >Assignee: Pavel Tupitsyn > Fix For: 1.8 > > > - If you register an object in BinaryConfiguration in C# code using object’s > type name then it must be a full name like typeof(Account).FullName. Document > this. > - https://apacheignite-net.readme.io/docs/serialization#ibinarizable . No > example on how to register the class in App.config file -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4174) binary meta cache throws exception on sending compute
Yakov Zhdanov created IGNITE-4174:
-
Summary: binary meta cache throws exception on sending compute
Key: IGNITE-4174
URL: https://issues.apache.org/jira/browse/IGNITE-4174
Project: Ignite
Issue Type: Bug
Components: binary
Affects Versions: 1.8
Reporter: Yakov Zhdanov
{noformat}
/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java
-org.apache.ignite.examples.datagrid.ClientReconnectExample
[19:29:11]__
[19:29:11] / _/ ___/ |/ / _/_ __/ __/
[19:29:11] _/ // (7 7// / / / / _/
[19:29:11] /___/\___/_/|_/___/ /_/ /___/
[19:29:11]
[19:29:11] ver. 1.7.0#20160801-sha1:383273e3
[19:29:11] 2016 Copyright(C) Apache Software Foundation
[19:29:11]
[19:29:11] Ignite documentation: http://ignite.apache.org
[19:29:11]
[19:29:11] Quiet mode.
[19:29:11] ^-- Logging to file
'/Users/yzhdanov/projects/apache-ignite-fabric-1.7.0-bin/work/log/ignite-9ed7b39d.log'
[19:29:11] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
"-v" to ignite.{sh|bat}
[19:29:11]
[19:29:11] OS: Mac OS X 10.12.1 x86_64
[19:29:11] VM information: Java(TM) SE Runtime Environment 1.7.0_40-b43 Oracle
Corporation Java HotSpot(TM) 64-Bit Server VM 24.0-b56
[19:29:11] Initial heap size is 256MB (should be no less than 512MB, use
-Xms512m -Xmx512m).
[19:29:11] Configured plugins:
[19:29:11] ^-- None
[19:29:11]
[19:29:11] Security status [authentication=off, tls/ssl=off]
[19:29:13] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[19:29:13]
[19:29:13] Ignite node started OK (id=9ed7b39d, grid=server1)
[19:29:13] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, heap=3.6GB]
[19:29:13]__
[19:29:13] / _/ ___/ |/ / _/_ __/ __/
[19:29:13] _/ // (7 7// / / / / _/
[19:29:13] /___/\___/_/|_/___/ /_/ /___/
[19:29:13]
[19:29:13] ver. 1.7.0#20160801-sha1:383273e3
[19:29:13] 2016 Copyright(C) Apache Software Foundation
[19:29:13]
[19:29:13] Ignite documentation: http://ignite.apache.org
[19:29:13]
[19:29:13] Quiet mode.
[19:29:13] ^-- Logging to file
'/Users/yzhdanov/projects/apache-ignite-fabric-1.7.0-bin/work/log/ignite-17162cf1.log'
[19:29:13] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
"-v" to ignite.{sh|bat}
[19:29:13]
[19:29:13] OS: Mac OS X 10.12.1 x86_64
[19:29:13] VM information: Java(TM) SE Runtime Environment 1.7.0_40-b43 Oracle
Corporation Java HotSpot(TM) 64-Bit Server VM 24.0-b56
[19:29:13] Initial heap size is 256MB (should be no less than 512MB, use
-Xms512m -Xmx512m).
[19:29:13] Configured plugins:
[19:29:13] ^-- None
[19:29:13]
[19:29:13] Security status [authentication=off, tls/ssl=off]
[19:29:13] Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=3.6GB]
[19:29:13] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[19:29:13]
[19:29:13] Ignite node started OK (id=17162cf1, grid=client1)
[19:29:13] Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=3.6GB]
[19:29:13]__
[19:29:13] / _/ ___/ |/ / _/_ __/ __/
[19:29:13] _/ // (7 7// / / / / _/
[19:29:13] /___/\___/_/|_/___/ /_/ /___/
[19:29:13]
[19:29:13] ver. 1.7.0#20160801-sha1:383273e3
[19:29:13] 2016 Copyright(C) Apache Software Foundation
[19:29:13]
[19:29:13] Ignite documentation: http://ignite.apache.org
[19:29:13]
[19:29:13] Quiet mode.
[19:29:13] ^-- Logging to file
'/Users/yzhdanov/projects/apache-ignite-fabric-1.7.0-bin/work/log/ignite-8394d1e6.log'
[19:29:13] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
"-v" to ignite.{sh|bat}
[19:29:13]
[19:29:13] OS: Mac OS X 10.12.1 x86_64
[19:29:13] VM information: Java(TM) SE Runtime Environment 1.7.0_40-b43 Oracle
Corporation Java HotSpot(TM) 64-Bit Server VM 24.0-b56
[19:29:13] Initial heap size is 256MB (should be no less than 512MB, use
-Xms512m -Xmx512m).
[19:29:13] Configured plugins:
[19:29:13] ^-- None
[19:29:13]
[19:29:13] Security status [authentication=off, tls/ssl=off]
[19:29:13] Topology snapshot [ver=3, servers=2, clients=1, CPUs=8, heap=3.6GB]
[19:29:13] Topology snapshot [ver=3, servers=2, clients=1, CPUs=8, heap=3.6GB]
[19:29:13] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[19:29:13]
[19:29:13] Ignite node started OK (id=8394d1e6, grid=server2)
[19:29:13] Topology snapshot [ver=3, servers=2, clients=1, CPUs=8, heap=3.6GB]
[19:29:13] Topology snapshot [ver=4, servers=1, clients=1, CPUs=8, heap=3.6GB]
[19:29:13] Topology snapshot [ver=4, servers=1, clients=1, CPUs=8, heap=3.6GB]
[19:29:13] Ignite node stopped OK [name=server1, uptime=00:00:00:823]
[19:29:13] Failed to connect to any address from IP finder (will retry to join
topology every 2 secs): [/127.0.0.1:47500, /127.0.0.1:47501, /127.0.0.1:47502,
/127.0.0.1:47503, /127.0.0.1:47504, /127.0.0.1:47505, /12
[jira] [Updated] (IGNITE-4174) binary meta cache throws exception on sending compute
[
https://issues.apache.org/jira/browse/IGNITE-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov updated IGNITE-4174:
--
Attachment: CacheDeadlockExample.java
> binary meta cache throws exception on sending compute
> -
>
> Key: IGNITE-4174
> URL: https://issues.apache.org/jira/browse/IGNITE-4174
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.8
>Reporter: Yakov Zhdanov
> Attachments: CacheDeadlockExample.java
>
>
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java
> -org.apache.ignite.examples.datagrid.ClientReconnectExample
> [19:29:11]__
> [19:29:11] / _/ ___/ |/ / _/_ __/ __/
> [19:29:11] _/ // (7 7// / / / / _/
> [19:29:11] /___/\___/_/|_/___/ /_/ /___/
> [19:29:11]
> [19:29:11] ver. 1.7.0#20160801-sha1:383273e3
> [19:29:11] 2016 Copyright(C) Apache Software Foundation
> [19:29:11]
> [19:29:11] Ignite documentation: http://ignite.apache.org
> [19:29:11]
> [19:29:11] Quiet mode.
> [19:29:11] ^-- Logging to file
> '/Users/yzhdanov/projects/apache-ignite-fabric-1.7.0-bin/work/log/ignite-9ed7b39d.log'
> [19:29:11] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
> "-v" to ignite.{sh|bat}
> [19:29:11]
> [19:29:11] OS: Mac OS X 10.12.1 x86_64
> [19:29:11] VM information: Java(TM) SE Runtime Environment 1.7.0_40-b43
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 24.0-b56
> [19:29:11] Initial heap size is 256MB (should be no less than 512MB, use
> -Xms512m -Xmx512m).
> [19:29:11] Configured plugins:
> [19:29:11] ^-- None
> [19:29:11]
> [19:29:11] Security status [authentication=off, tls/ssl=off]
> [19:29:13] To start Console Management & Monitoring run
> ignitevisorcmd.{sh|bat}
> [19:29:13]
> [19:29:13] Ignite node started OK (id=9ed7b39d, grid=server1)
> [19:29:13] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, heap=3.6GB]
> [19:29:13]__
> [19:29:13] / _/ ___/ |/ / _/_ __/ __/
> [19:29:13] _/ // (7 7// / / / / _/
> [19:29:13] /___/\___/_/|_/___/ /_/ /___/
> [19:29:13]
> [19:29:13] ver. 1.7.0#20160801-sha1:383273e3
> [19:29:13] 2016 Copyright(C) Apache Software Foundation
> [19:29:13]
> [19:29:13] Ignite documentation: http://ignite.apache.org
> [19:29:13]
> [19:29:13] Quiet mode.
> [19:29:13] ^-- Logging to file
> '/Users/yzhdanov/projects/apache-ignite-fabric-1.7.0-bin/work/log/ignite-17162cf1.log'
> [19:29:13] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
> "-v" to ignite.{sh|bat}
> [19:29:13]
> [19:29:13] OS: Mac OS X 10.12.1 x86_64
> [19:29:13] VM information: Java(TM) SE Runtime Environment 1.7.0_40-b43
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 24.0-b56
> [19:29:13] Initial heap size is 256MB (should be no less than 512MB, use
> -Xms512m -Xmx512m).
> [19:29:13] Configured plugins:
> [19:29:13] ^-- None
> [19:29:13]
> [19:29:13] Security status [authentication=off, tls/ssl=off]
> [19:29:13] Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=3.6GB]
> [19:29:13] To start Console Management & Monitoring run
> ignitevisorcmd.{sh|bat}
> [19:29:13]
> [19:29:13] Ignite node started OK (id=17162cf1, grid=client1)
> [19:29:13] Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=3.6GB]
> [19:29:13]__
> [19:29:13] / _/ ___/ |/ / _/_ __/ __/
> [19:29:13] _/ // (7 7// / / / / _/
> [19:29:13] /___/\___/_/|_/___/ /_/ /___/
> [19:29:13]
> [19:29:13] ver. 1.7.0#20160801-sha1:383273e3
> [19:29:13] 2016 Copyright(C) Apache Software Foundation
> [19:29:13]
> [19:29:13] Ignite documentation: http://ignite.apache.org
> [19:29:13]
> [19:29:13] Quiet mode.
> [19:29:13] ^-- Logging to file
> '/Users/yzhdanov/projects/apache-ignite-fabric-1.7.0-bin/work/log/ignite-8394d1e6.log'
> [19:29:13] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
> "-v" to ignite.{sh|bat}
> [19:29:13]
> [19:29:13] OS: Mac OS X 10.12.1 x86_64
> [19:29:13] VM information: Java(TM) SE Runtime Environment 1.7.0_40-b43
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 24.0-b56
> [19:29:13] Initial heap size is 256MB (should be no less than 512MB, use
> -Xms512m -Xmx512m).
> [19:29:13] Configured plugins:
> [19:29:13] ^-- None
> [19:29:13]
> [19:29:13] Security status [authentication=off, tls/ssl=off]
> [19:29:13] Topology snapshot [ver=3, servers=2, clients=1, CPUs=8, heap=3.6GB]
> [19:29:13] Topology snapshot [ver=3, servers=2, clients=1, CPUs=8, heap=3.6GB]
> [19:29:13] To start Console Management & Monitoring run
> ignitevisorcmd.{sh|bat}
> [19:29:13]
> [19:29:13] Ignite node started OK (id=8394d1e6, grid=server2)
> [19:29:13] Topology snapshot [ver=3, servers=2, clients=1, CPUs=8
[jira] [Commented] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.
[
https://issues.apache.org/jira/browse/IGNITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633230#comment-15633230
]
Igor Sapego commented on IGNITE-3921:
-
Denis,
I'm not sure, why cache configuration must contain {{QueryEntiry}}? It does not
seem like a necessary thing.
> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
> Issue Type: Task
> Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we
> need to document it for our users.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.
[
https://issues.apache.org/jira/browse/IGNITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633313#comment-15633313
]
Denis Magda commented on IGNITE-3921:
-
{{QueryEntity}} is required if SELECTS, UPDATES or INSERTS are used with the
usage of specific fields names. Please talk to [~al.psc] and [~vozerov] to get
more clarifications.
> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
> Issue Type: Task
> Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we
> need to document it for our users.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (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:all-tabpanel ] Andrew Mashenkov updated IGNITE-4172: - Summary: SQL: Add support for Java 8 Time API classes in date\time functions (was: SQL: support ISO-8601 date time format) > 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 >Affects Versions: 1.6, 1.7 >Reporter: Andrew Mashenkov > Fix For: 1.8 > > > It seems H2 do not support ISO-8601 short time format "HH:mm". We need > workaround here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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:all-tabpanel
]
Andrew Mashenkov updated IGNITE-4172:
-
Description:
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;
It seems H2 do not support ISO-8601 short time format "HH:mm". We need
workaround here.
was:It seems H2 do not support ISO-8601 short time format "HH:mm". We need
workaround here.
> 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
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
> Fix For: 1.8
>
>
> 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;
> It seems H2 do not support ISO-8601 short time format "HH:mm". We need
> workaround here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (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:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-4172:
Assignee: Andrew Mashenkov
> 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
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 1.8
>
>
> 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;
> It seems H2 do not support ISO-8601 short time format "HH:mm". We need
> workaround here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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=15633582#comment-15633582
]
Andrew Mashenkov commented on IGNITE-4172:
--
H2 converts object to Timestamp right before provide it to DateDiff function as
an argument.
I've found that H2 does not support LocalDateTime class and try it as a String
when converting to Timestamp.
But LocalDateTime.toString() method can return result in different format.
Short time format is used for object with zero-time setted. H2 parser does not
support shot time format and throws an error.
E.g.
Object with zero-time toString() returns smth like this: 2016-11-01T00:00
But with non-zero-time: 2016-11-01T22:07:19.547
> 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
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 1.8
>
>
> 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;
> It seems H2 do not support ISO-8601 short time format "HH:mm". We need
> workaround here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.
[
https://issues.apache.org/jira/browse/IGNITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633579#comment-15633579
]
Igor Sapego edited comment on IGNITE-3921 at 11/3/16 5:37 PM:
--
I know, I just thought that we can use annotations instead. On the second
thought I see that if user wants to use PHP it could be more convenient for
them to just specify {{QueryEntity}} in cache without writing any Java code.
was (Author: isapego):
I know, I just thought that we can use annotations instead. On the second
thought I see that if user wants to use PHP it could be more convenient for
them to just specify{{QueryEntity}} in cache without writing any Java code.
> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
> Issue Type: Task
> Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we
> need to document it for our users.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.
[ https://issues.apache.org/jira/browse/IGNITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633579#comment-15633579 ] Igor Sapego edited comment on IGNITE-3921 at 11/3/16 5:36 PM: -- I know, I just thought that we can use annotations instead. On the second thought I see that if user wants to use PHP it could be more convenient for them to just specify `QueryEntity` in cache without writing any Java code. was (Author: isapego): I know, I just thought that we can use annotations instead. On the second thought I see that if user wants to use PHP it could me more convenient for them to just specify `QueryEntity` in cache without writing any Java code. > ODBC: Add documentation for the PDO interoperability. > - > > Key: IGNITE-3921 > URL: https://issues.apache.org/jira/browse/IGNITE-3921 > Project: Ignite > Issue Type: Task > Components: documentation, odbc >Affects Versions: 1.7 >Reporter: Igor Sapego >Assignee: Igor Sapego > Labels: documentation, odbc > Fix For: 1.8 > > > We have checked our ODBC driver for the compatibility with the PDO. Now we > need to document it for our users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.
[
https://issues.apache.org/jira/browse/IGNITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633579#comment-15633579
]
Igor Sapego edited comment on IGNITE-3921 at 11/3/16 5:37 PM:
--
I know, I just thought that we can use annotations instead. On the second
thought I see that if user wants to use PHP it could be more convenient for
them to just specify{{QueryEntity}} in cache without writing any Java code.
was (Author: isapego):
I know, I just thought that we can use annotations instead. On the second
thought I see that if user wants to use PHP it could be more convenient for
them to just specify `QueryEntity` in cache without writing any Java code.
> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
> Issue Type: Task
> Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we
> need to document it for our users.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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=15633591#comment-15633591
]
Andrew Mashenkov commented on IGNITE-4172:
--
It seems it can be fixed in IgniteH2Indexing,wrap method. We can substitute
LocalDateTime instance with Timestamp.
But Reflection should be used to prevent compatibility issues with Java7.
> 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
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 1.8
>
>
> 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;
> It seems H2 do not support ISO-8601 short time format "HH:mm". We need
> workaround here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.
[ https://issues.apache.org/jira/browse/IGNITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633579#comment-15633579 ] Igor Sapego commented on IGNITE-3921: - I know, I just thought that we can use annotations instead. On the second thought I see that if user wants to use PHP it could me more convenient for them to just specify `QueryEntity` in cache without writing any Java code. > ODBC: Add documentation for the PDO interoperability. > - > > Key: IGNITE-3921 > URL: https://issues.apache.org/jira/browse/IGNITE-3921 > Project: Ignite > Issue Type: Task > Components: documentation, odbc >Affects Versions: 1.7 >Reporter: Igor Sapego >Assignee: Igor Sapego > Labels: documentation, odbc > Fix For: 1.8 > > > We have checked our ODBC driver for the compatibility with the PDO. Now we > need to document it for our users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15633694#comment-15633694
]
ASF GitHub Bot commented on IGNITE-4172:
GitHub user AMashenkov opened a pull request:
https://github.com/apache/ignite/pull/1208
IGNITE-4172: SQL: Add support for Java 8 Time API classes in date\time
functions
Prototype implemented
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4172
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/1208.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 #1208
> 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
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 1.8
>
>
> 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;
> It seems H2 do not support ISO-8601 short time format "HH:mm". We need
> workaround here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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=15633739#comment-15633739
]
ASF GitHub Bot commented on IGNITE-4172:
Github user AMashenkov closed the pull request at:
https://github.com/apache/ignite/pull/1208
> 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
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 1.8
>
>
> 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;
> It seems H2 do not support ISO-8601 short time format "HH:mm". We need
> workaround here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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=15633753#comment-15633753
]
ASF GitHub Bot commented on IGNITE-4172:
GitHub user AMashenkov opened a pull request:
https://github.com/apache/ignite/pull/1209
IGNITE-4172: SQL: Add support for Java 8 Time API classes in date\time
functions
prototype
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4172
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/1209.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 #1209
> 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
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 1.8
>
>
> 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;
> It seems H2 do not support ISO-8601 short time format "HH:mm". We need
> workaround here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633793#comment-15633793 ] Sergey Chugunov commented on IGNITE-4157: - h5. Design proposal for mapping refactoring h6. Storing mapping locally instead of using cache Instead using marshaller cache for typeId->typeName mapping each node has it's own local copy of mapping in, for instance, ConcurrentHashMap. Each time when a node wants to use new class and therefore to create new mapping it notifies other nodes using DiscoveryCustomMessage; every other node updates its local mapping upon receiving this notification. As DCMs are guaranteed to be delivered to all nodes in the cluster it is possible to keep these local mappings in sync across the cluster. When a node joins the cluster it can obtain current state of mapping using existing collectDiscoveryData/onDiscoveryDataReceived methods in GridCacheProcessor class. h6. Extended mapping API Right now marshaller mapping API is very simple and allows only to register or get a single class name under/by a single typeId. This restriction has implications on .NET platform and described in IGNITE-2703. To get rid of this restriction I'm going to add additional byte parameter to registerClass and getClass methods indicating for which platform class is registered or requested. This should allow platforms other than Java to use typeId<->typeName mapping. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.
[ https://issues.apache.org/jira/browse/IGNITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633795#comment-15633795 ] Denis Magda commented on IGNITE-3921: - Yeap, this is the point. The user hasn't been forced to write a single line of the code in Java. There should be a way to configure everything from XML. > ODBC: Add documentation for the PDO interoperability. > - > > Key: IGNITE-3921 > URL: https://issues.apache.org/jira/browse/IGNITE-3921 > Project: Ignite > Issue Type: Task > Components: documentation, odbc >Affects Versions: 1.7 >Reporter: Igor Sapego >Assignee: Igor Sapego > Labels: documentation, odbc > Fix For: 1.8 > > > We have checked our ODBC driver for the compatibility with the PDO. Now we > need to document it for our users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633793#comment-15633793 ] Sergey Chugunov edited comment on IGNITE-4157 at 11/3/16 6:45 PM: -- h3. Design proposal for mapping refactoring h4. Storing mapping locally instead of using cache Instead using marshaller cache for typeId->typeName mapping each node has it's own local copy of mapping in, for instance, ConcurrentHashMap. Each time when a node wants to use new class and therefore to create new mapping it notifies other nodes using DiscoveryCustomMessage; every other node updates its local mapping upon receiving this notification. As DCMs are guaranteed to be delivered to all nodes in the cluster it is possible to keep these local mappings in sync across the cluster. When a node joins the cluster it can obtain current state of mapping using existing collectDiscoveryData/onDiscoveryDataReceived methods in GridCacheProcessor class. h4. Extended mapping API Right now marshaller mapping API is very simple and allows only to register or get a single class name under/by a single typeId. This restriction has implications on .NET platform and described in IGNITE-2703. To get rid of this restriction I'm going to add additional byte parameter to registerClass and getClass methods indicating for which platform class is registered or requested. This should allow platforms other than Java to use typeId<->typeName mapping. was (Author: sergey-chugunov): h4. Design proposal for mapping refactoring h5. Storing mapping locally instead of using cache Instead using marshaller cache for typeId->typeName mapping each node has it's own local copy of mapping in, for instance, ConcurrentHashMap. Each time when a node wants to use new class and therefore to create new mapping it notifies other nodes using DiscoveryCustomMessage; every other node updates its local mapping upon receiving this notification. As DCMs are guaranteed to be delivered to all nodes in the cluster it is possible to keep these local mappings in sync across the cluster. When a node joins the cluster it can obtain current state of mapping using existing collectDiscoveryData/onDiscoveryDataReceived methods in GridCacheProcessor class. h5. Extended mapping API Right now marshaller mapping API is very simple and allows only to register or get a single class name under/by a single typeId. This restriction has implications on .NET platform and described in IGNITE-2703. To get rid of this restriction I'm going to add additional byte parameter to registerClass and getClass methods indicating for which platform class is registered or requested. This should allow platforms other than Java to use typeId<->typeName mapping. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633793#comment-15633793 ] Sergey Chugunov edited comment on IGNITE-4157 at 11/3/16 6:45 PM: -- h4. Design proposal for mapping refactoring h5. Storing mapping locally instead of using cache Instead using marshaller cache for typeId->typeName mapping each node has it's own local copy of mapping in, for instance, ConcurrentHashMap. Each time when a node wants to use new class and therefore to create new mapping it notifies other nodes using DiscoveryCustomMessage; every other node updates its local mapping upon receiving this notification. As DCMs are guaranteed to be delivered to all nodes in the cluster it is possible to keep these local mappings in sync across the cluster. When a node joins the cluster it can obtain current state of mapping using existing collectDiscoveryData/onDiscoveryDataReceived methods in GridCacheProcessor class. h5. Extended mapping API Right now marshaller mapping API is very simple and allows only to register or get a single class name under/by a single typeId. This restriction has implications on .NET platform and described in IGNITE-2703. To get rid of this restriction I'm going to add additional byte parameter to registerClass and getClass methods indicating for which platform class is registered or requested. This should allow platforms other than Java to use typeId<->typeName mapping. was (Author: sergey-chugunov): h5. Design proposal for mapping refactoring h6. Storing mapping locally instead of using cache Instead using marshaller cache for typeId->typeName mapping each node has it's own local copy of mapping in, for instance, ConcurrentHashMap. Each time when a node wants to use new class and therefore to create new mapping it notifies other nodes using DiscoveryCustomMessage; every other node updates its local mapping upon receiving this notification. As DCMs are guaranteed to be delivered to all nodes in the cluster it is possible to keep these local mappings in sync across the cluster. When a node joins the cluster it can obtain current state of mapping using existing collectDiscoveryData/onDiscoveryDataReceived methods in GridCacheProcessor class. h6. Extended mapping API Right now marshaller mapping API is very simple and allows only to register or get a single class name under/by a single typeId. This restriction has implications on .NET platform and described in IGNITE-2703. To get rid of this restriction I'm going to add additional byte parameter to registerClass and getClass methods indicating for which platform class is registered or requested. This should allow platforms other than Java to use typeId<->typeName mapping. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4175) SQL: Jdbc resultset wasNull() method should return true on NULL String fields
Andrew Mashenkov created IGNITE-4175: Summary: SQL: Jdbc resultset wasNull() method should return true on NULL String fields Key: IGNITE-4175 URL: https://issues.apache.org/jira/browse/IGNITE-4175 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.7, 1.6 Reporter: Andrew Mashenkov Startpoints are org.apache.ignite.internal.jdbc.JdbcResultSet class and org.apache.ignite.internal.jdbc2.JdbcResultSet class -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4175) SQL: JdbcResultSet class wasNull() method should return true on NULL String fields
[ https://issues.apache.org/jira/browse/IGNITE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-4175: - Summary: SQL: JdbcResultSet class wasNull() method should return true on NULL String fields (was: SQL: Jdbc resultset wasNull() method should return true on NULL String fields) > SQL: JdbcResultSet class wasNull() method should return true on NULL String > fields > -- > > Key: IGNITE-4175 > URL: https://issues.apache.org/jira/browse/IGNITE-4175 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.6, 1.7 >Reporter: Andrew Mashenkov > Labels: newbie > > Startpoints are org.apache.ignite.internal.jdbc.JdbcResultSet class > and org.apache.ignite.internal.jdbc2.JdbcResultSet class -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-4175) SQL: JdbcResultSet class wasNull() method should return true on NULL String fields
[ https://issues.apache.org/jira/browse/IGNITE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-4175: Assignee: Andrew Mashenkov > SQL: JdbcResultSet class wasNull() method should return true on NULL String > fields > -- > > Key: IGNITE-4175 > URL: https://issues.apache.org/jira/browse/IGNITE-4175 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.6, 1.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Labels: newbie > > Startpoints are org.apache.ignite.internal.jdbc.JdbcResultSet class > and org.apache.ignite.internal.jdbc2.JdbcResultSet class -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4176) IgniteQueue not functioning as expected after remove().
C Saternos created IGNITE-4176: -- Summary: IgniteQueue not functioning as expected after remove(). Key: IGNITE-4176 URL: https://issues.apache.org/jira/browse/IGNITE-4176 Project: Ignite Issue Type: Bug Components: data structures Affects Versions: 1.7 Reporter: C Saternos After removing an item from an IgniteQueue, the next item on the queue can be viewed using peek(). However, poll() or take() does not retrieve the item. When iterating through the remaining items in the queue, it appears that 1/2 of them are missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4175) SQL: JdbcResultSet class wasNull() method should return true on NULL String fields
[ https://issues.apache.org/jira/browse/IGNITE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633903#comment-15633903 ] ASF GitHub Bot commented on IGNITE-4175: GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/1210 IGNITE-4175: SQL: JdbcResultSet class wasNull() method should return true on column NULL value. JdbcResultSet.wasNull() method should return null on column NULL value, if column value is null String. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4175 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1210.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 #1210 commit 76b89dc43d8902dc8532f43ea0a631fb441fe10f Author: Andrey V. Mashenkov Date: 2016-11-03T19:10:41Z Trivial fix. JdbcResultSet.wasNull() method should return null on column NULL value. > SQL: JdbcResultSet class wasNull() method should return true on NULL String > fields > -- > > Key: IGNITE-4175 > URL: https://issues.apache.org/jira/browse/IGNITE-4175 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.6, 1.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Labels: newbie > > Startpoints are org.apache.ignite.internal.jdbc.JdbcResultSet class > and org.apache.ignite.internal.jdbc2.JdbcResultSet class -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4176) IgniteQueue not functioning as expected after remove().
[ https://issues.apache.org/jira/browse/IGNITE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C Saternos updated IGNITE-4176: --- Attachment: WhereDidItGo.java pom.xml The pom.xml attached shows components. The Java source file replicates the problem. > IgniteQueue not functioning as expected after remove(). > --- > > Key: IGNITE-4176 > URL: https://issues.apache.org/jira/browse/IGNITE-4176 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 1.7 >Reporter: C Saternos > Attachments: WhereDidItGo.java, pom.xml > > > After removing an item from an IgniteQueue, the next item on the queue can be > viewed using peek(). However, poll() or take() does not retrieve the item. > When iterating through the remaining items in the queue, it appears that 1/2 > of them are missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4176) IgniteQueue not functioning as expected after remove().
[ https://issues.apache.org/jira/browse/IGNITE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633909#comment-15633909 ] C Saternos commented on IGNITE-4176: BTW - apologies if this is not contributed correctly. I have not participated in Apache open source projects before, but I thought the problem was significant enough to warrant your attention. No offense intended. > IgniteQueue not functioning as expected after remove(). > --- > > Key: IGNITE-4176 > URL: https://issues.apache.org/jira/browse/IGNITE-4176 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 1.7 >Reporter: C Saternos > Attachments: WhereDidItGo.java, pom.xml > > > After removing an item from an IgniteQueue, the next item on the queue can be > viewed using peek(). However, poll() or take() does not retrieve the item. > When iterating through the remaining items in the queue, it appears that 1/2 > of them are missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3891) Enable writing hostname, rather than ipaddress for zookeeper discovery
[ https://issues.apache.org/jira/browse/IGNITE-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15634866#comment-15634866 ] ASF GitHub Bot commented on IGNITE-3891: Github user shroman closed the pull request at: https://github.com/apache/ignite/pull/1191 > Enable writing hostname, rather than ipaddress for zookeeper discovery > -- > > Key: IGNITE-3891 > URL: https://issues.apache.org/jira/browse/IGNITE-3891 > Project: Ignite > Issue Type: Improvement > Components: ignite-zookeeper >Affects Versions: 1.7 > Environment: docker >Reporter: John Watson > > We are using ignite in docker, with zookeeper discovery. We need to be able > to use the hostname, rather than the ip address, since the container-visible > ip address is not externally usable. > We would like an option in the TcpDiscoveryZookeeperIpFinder to use the > hostname, rather than ipaddress. This change would impact line 231, where > currently the ip address is being written. We suggest adding an option to the > class to use the hostname, rather than the ip address. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4163) Wrong SQL generated by org.apache.ignite.cache.store.jdbc.dialect.BasicJdbcDialect#loadCacheSelectRangeQuery
[
https://issues.apache.org/jira/browse/IGNITE-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635385#comment-15635385
]
Anghel Botos commented on IGNITE-4163:
--
Hi,
After trying out the patched dialect and playing around with it, I'm back with
some more information on this. While the query is correct now from a syntactic
point of view, it does not produce the expected results. As explained on
http://www.oracle.com/technetwork/issue-archive/2006/06-sep/o56asktom-086197.html
, *A ROWNUM value is assigned to a row after it passes the predicate phase of
the query but before the query does any sorting or aggregation*, so having
ROWNUM as part of the sorted sub-query will produce the wrong values in the
{{rn}} column (because it's values are assigned before the ordering).
Assume we have a table with two key columns, with the following values:
||KC1|| KC2||
|2|2|
|2|1|
|1|3|
|1|2|
|1|1|
Then {{SELECT KC1, KC2, ROWNUM AS rn FROM MY_TABLE}} yields:
||KC1|| KC2||RN||
|2|2|1|
|2|1|2|
|1|3|3|
|1|2|4|
|1|1|5|
The sub-query as it would be produced by the patched dialect would be {{SELECT
KC1, KC2, ROWNUM AS rn FROM MY_TABLE ORDER BY KC1, KC2}}. Executing this query,
one obtains:
||KC1|| KC2||RN||
|1|1|5|
|1|2|4|
|1|3|3|
|2|1|2|
|2|2|1|
This is wrong, we need to have {{ROWNUM}} added to the result set after the
ordering has been performed, so it needs to go in the outer query to have
something like this: {{SELECT KC1, KC2, ROWNUM AS rn FROM (SELECT KC1, KC2 FROM
MY_TABLE ORDER BY KC1, KC2)}}. Executing the query one gets the following
results:
||KC1|| KC2||RN||
|1|1|1|
|1|2|2|
|1|3|3|
|2|1|4|
|2|2|5|
Now we need to apply the condition {{WHERE mod(RN,
parallelLoadCacheMinThreshold)=0}}, but for some odd reason this results in
{{ORA-00904: "RN": invalid identifier}}. Since we anyway want to not have the
{{RN}} column in the output result set, we can wrap the entire query from above
into another {{SELECT}}, having a final query that looks like this: {{SELECT
KC1, KC2 FROM (SELECT KC1, KC2, ROWNUM AS rn FROM (SELECT KC1, KC2 FROM
MY_TABLE ORDER BY KC1, KC2)) WHERE mod(rn, 2)=0}} (I used
{{parallelLoadCacheMinThreshold=2}} just as an example, as in reality it should
be larger in order to actually benefit from the parallel loading). Executing
the query one obtains the following results:
||KC1|| KC2||
|1|2|
|2|1|
Which are *correct*.
> Wrong SQL generated by
> org.apache.ignite.cache.store.jdbc.dialect.BasicJdbcDialect#loadCacheSelectRangeQuery
>
>
> Key: IGNITE-4163
> URL: https://issues.apache.org/jira/browse/IGNITE-4163
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.7
>Reporter: Anghel Botos
>Assignee: Alexey Kuznetsov
> Attachments: IGNITE_4163_Oracle_specific_for_load_range_query_.patch
>
>
> The SQL statement generated by
> org.apache.ignite.cache.store.jdbc.dialect.BasicJdbcDialect#loadCacheSelectRangeQuery
> looks like this:
> {{SELECT KEY_COLUMN_1,KEY_COLUMN_2 FROM (SELECT KEY_COLUMN_1,KEY_COLUMN_2,
> ROWNUM() AS rn FROM SOME_TABLE ORDER BY KEY_COLUMN_1,KEY_COLUMN_2) WHERE
> mod(rn, ?) = 0}}
> For Oracle this is incorrect, as Oracle does not have a {{ROWNUM()}}
> function. For the above query the following error is thrown: {{ORA-00923:
> FROM keyword not found where expected}}
> Regarding row numbering Oracle has:
> * a {{ROWNUM}} pseudocolumn, in which case the query should have {{ROWNUM AS
> rn}}
> * a {{ROW_NUMBER()}} function, in which case the query would become more
> complicated. See
> https://docs.oracle.com/database/121/SQLRF/functions170.htm#SQLRF06100 for
> more details about {{ROW_NUMBER()}}
> Please make the neccessary adjustments to either {{BasicJdbcDialect}} or
> {{OracleDialect}} so that a correct query is produced.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2417) peerClassLoading causes high memory usage on simple cache operations
[
https://issues.apache.org/jira/browse/IGNITE-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov updated IGNITE-2417:
-
Fix Version/s: (was: 1.8)
1.9
> peerClassLoading causes high memory usage on simple cache operations
>
>
> Key: IGNITE-2417
> URL: https://issues.apache.org/jira/browse/IGNITE-2417
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Semen Boikov
>Priority: Blocker
> Labels: performance
> Fix For: 1.9
>
> Attachments: CacheMemoryUsageSelfTest.java, myrecording.zip
>
>
> Issue surfaced in .NET, but this code can be easily ported to Java. Only one
> node is started.
> Without peerClassLoading, Java heap usage is aroung 2GB with this code. With
> peerClassLoading, heap goes to the max and then there is OutOfMemoryException.
> {code}
> var cfg = new GridConfiguration
> {
> SpringConfigUrl = @"example-cache.xml",
> JvmOptions = new List { "-Xms1024m", "-Xmx8192m" },
> };
> using (var grid = GridFactory.Start(cfg))
> {
> var cache = grid.GetOrCreateCache("cache_put_get");
> cache.Clear();
> var obj = string.Join("", Enumerable.Range(0, 5 * 1024));
> const int iterations = 100 * 1000;
> for (var i = 0; i < iterations; i++)
> cache.Put(i.ToString(), obj);
> }
> {code}
> Config file:
> {code}
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:util="http://www.springframework.org/schema/util";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">
>
>
>
> 127.0.0.1:47500..47501
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2309) Implement security permissions checks for create/destory cache operations
[ https://issues.apache.org/jira/browse/IGNITE-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-2309: - Fix Version/s: (was: 1.8) 1.9 > Implement security permissions checks for create/destory cache operations > - > > Key: IGNITE-2309 > URL: https://issues.apache.org/jira/browse/IGNITE-2309 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Critical > Fix For: 1.9 > > > Currenctly there is no security checks for create/destroy cache operations > (need to add these checks on client and servers). There are some releated > changes in ignite-961-permissions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2309) Implement security permissions checks for create/destory cache operations
[ https://issues.apache.org/jira/browse/IGNITE-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-2309: - Assignee: (was: Semen Boikov) > Implement security permissions checks for create/destory cache operations > - > > Key: IGNITE-2309 > URL: https://issues.apache.org/jira/browse/IGNITE-2309 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Priority: Critical > Fix For: 1.9 > > > Currenctly there is no security checks for create/destroy cache operations > (need to add these checks on client and servers). There are some releated > changes in ignite-961-permissions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3211) "Failed to reinitialize local partitions", "Failed to wait for completion of partition map exchange" errors during failover test
[
https://issues.apache.org/jira/browse/IGNITE-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov updated IGNITE-3211:
-
Fix Version/s: (was: 1.8)
1.9
> "Failed to reinitialize local partitions", "Failed to wait for completion of
> partition map exchange" errors during failover test
>
>
> Key: IGNITE-3211
> URL: https://issues.apache.org/jira/browse/IGNITE-3211
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 1.9
>
>
> "Failed to reinitialize local partitions (preloading will be stopped)" and
> "Failed to wait for completion of partition map exchange (preloading will not
> start)" errors occured during failover load test. Complete stack trace see
> below.
> Load config:
> - 1 client, 20 servers (5 servers per 1 host)
> - warmup 60
> - duration 66h
> - preload 5M
> - key range 10M
> - operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL
> PUT_IF_ABSENT REPLACE
> - backups count 3
> - 3 servers restart every 15 min with 30 sec step, pause between stop and
> start 5min
> {noformat}
> [08:32:21,002][ERROR][exchange-worker-#83%null%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=39,
> minorTopVer=1], nodeId=20ddc8b7, evt=DISCOVERY_CUSTOM_EVT]
> class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:506)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:297)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.toString(IgniteTxLocalAdapter.java:3743)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.toString(GridDhtTxLocalAdapter.java:868)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.toString(GridDhtTxLocal.java:703)
> at java.lang.String.valueOf(String.java:2849)
> at java.lang.StringBuilder.append(StringBuilder.java:128)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpPendingObjects(GridCachePartitionExchangeManager.java:1172)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpDebugInfo(GridCachePartitionExchangeManager.java:1150)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.dumpPendingObjects(GridDhtPartitionsExchangeFuture.java:894)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:715)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:472)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1333)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:506)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:364)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxStateImpl.toString(IgniteTxStateImpl.java:443)
> at java.lang.String.valueOf(String.java:2849)
> at
> org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:474)
> ... 15 more
> Caused by: java.util.ConcurrentModificationException
> at
> java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:394)
> at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:413)
> at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:412)
> at java.util.AbstractMap.toString(AbstractMap.java:518)
> at java.lang.String.valueOf(St
[jira] [Updated] (IGNITE-3212) Servers get stuck with the warning "Failed to wait for initial partition map exchange" during falover test
[
https://issues.apache.org/jira/browse/IGNITE-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov updated IGNITE-3212:
-
Fix Version/s: (was: 1.8)
1.9
> Servers get stuck with the warning "Failed to wait for initial partition map
> exchange" during falover test
> --
>
> Key: IGNITE-3212
> URL: https://issues.apache.org/jira/browse/IGNITE-3212
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 1.9
>
>
> Servers being restarted during failover test get stuck after some time with
> the warning "Failed to wait for initial partition map exchange".
> {noformat}
> [08:44:41,303][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Added new node to topology: TcpDiscoveryNode
> [id=db557f04-43b7-4e28-ae0d-d4dcf4139c89, addrs=
> [10.20.0.222, 127.0.0.1], sockAddrs=[fosters-222/10.20.0.222:47503,
> /10.20.0.222:47503, /127.0.0.1:47503], discPort=47503, order=44, intOrder=32,
> lastExchangeTime=1464
> 363880917, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:44:41,304][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Topology snapshot [ver=44, servers=19, clients=1, CPUs=64, heap=160.0GB]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Added new node to topology: TcpDiscoveryNode
> [id=6fae61a7-c1c1-40e5-8ad0-8bf5d6c86eb7, addrs=
> [10.20.0.223, 127.0.0.1], sockAddrs=[fosters-223/10.20.0.223:47503,
> /10.20.0.223:47503, /127.0.0.1:47503], discPort=47503, order=45, intOrder=33,
> lastExchangeTime=1464
> 363910999, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Topology snapshot [ver=45, servers=20, clients=1, CPUs=64, heap=170.0GB]
> [08:45:19,942][INFO ][ignite-update-notifier-timer][GridUpdateNotifier]
> Update status is not available.
> [08:46:20,370][WARN ][main][GridCachePartitionExchangeManager] Failed to wait
> for initial partition map exchange. Possible reasons are:
> ^-- Transactions in deadlock.
> ^-- Long running transactions (ignore if this is the case).
> ^-- Unreleased explicit locks.
> [08:48:30,375][WARN ][main][GridCachePartitionExchangeManager] Still waiting
> for initial partition map exchange ...
> {noformat}
> "Failed to wait for partition release future" warnings are on other nodes.
> {noformat}
> [08:09:45,822][WARN
> ][exchange-worker-#82%null%][GridDhtPartitionsExchangeFuture] Failed to wait
> for partition release future [topVer=AffinityTopologyVersion [topVer=29,
> minorTopVer=0], node=cab5d0e0-7365-4774-8f99-d9f131c5d896]. Dumping pending
> objects that might be the cause:
> [08:09:45,822][WARN
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Ready
> affinity version: AffinityTopologyVersion [topVer=28, minorTopVer=1]
> [08:09:45,826][WARN
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Last exchange
> future: GridDhtPartitionsExchangeFuture ...
> {noformat}
> Load config:
> - 1 client, 20 servers (5 servers per 1 host)
> - warmup 60
> - duration 66h
> - preload 5M
> - key range 10M
> - operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL
> PUT_IF_ABSENT REPLACE
> - backups count 3
> - 3 servers restart every 15 min with 30 sec step, pause between stop and
> start 5min
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3955) IgniteCache.invokeAll returns empty result set in ATOMIC cache
[
https://issues.apache.org/jira/browse/IGNITE-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov updated IGNITE-3955:
-
Assignee: Konstantin Dudkov (was: Semen Boikov)
> IgniteCache.invokeAll returns empty result set in ATOMIC cache
> --
>
> Key: IGNITE-3955
> URL: https://issues.apache.org/jira/browse/IGNITE-3955
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Assignee: Konstantin Dudkov
> Fix For: 1.8
>
>
> When entry processor is invoked from multiple threads, result set is
> sometimes empty.
> This happens with ATOMIC cache, but not with TRANSACTIONAL.
> To reproduce, paste the following into GridCacheAbstractFullApiSelfTest.java:
> {code}
> public void testInvokeAllMultithreaded() throws Exception {
> final IgniteCache cache = jcache();
> final int threadCnt = 4;
> final int cnt = 9;
> final Set keys = Collections.singleton("myKey");
> GridTestUtils.runMultiThreaded(new Runnable() {
> @Override public void run() {
> for (int i = 0; i < cnt; i++) {
> final Map> res =
> cache.invokeAll(keys, new CacheEntryProcessor Integer, Integer>() {
> @Override
> public Integer process(MutableEntry Integer> entry,
> Object... objects) throws
> EntryProcessorException {
> Integer val = entry.getValue();
> if (val == null)
> val = 0;
> val++;
> entry.setValue(val);
> return val;
> }
> });
> assertEquals(1, res.size());
> }
> }
> }, threadCnt, "testInvokeAllMultithreaded");
> assertEquals(cnt*threadCnt, (int)cache.get("myKey"));
> }
> {code}
> Run this test as part of GridCacheAtomicFullApiSelfTest.java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-3336) Improve Ignite troubleshooting logging
[ https://issues.apache.org/jira/browse/IGNITE-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov resolved IGNITE-3336. -- Resolution: Fixed > Improve Ignite troubleshooting logging > -- > > Key: IGNITE-3336 > URL: https://issues.apache.org/jira/browse/IGNITE-3336 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 1.8 > > > Currently there is method IgniteKernal.dumpDebugInfo which dumps important > troubleshooting information. Currently Ignite dumps this information when > partition exchange process hangs. In addition need add some background logic > which will check that there are no hanging operations (tx, atomic updates) > and dump debug info if there are any. > In addition need improve debug logging for cache operations: e.g. if I know > id of hanging tx it should be possible to grep logs by this id and find out > all steps of tx execution, maybe need add several levels of details for tx > execution to avoid too much logging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3299) Cache remove can be lost in ATOMIC cache with OFFHEAP_TIERED memory mode
[
https://issues.apache.org/jira/browse/IGNITE-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov updated IGNITE-3299:
-
Fix Version/s: (was: 1.8)
1.9
> Cache remove can be lost in ATOMIC cache with OFFHEAP_TIERED memory mode
>
>
> Key: IGNITE-3299
> URL: https://issues.apache.org/jira/browse/IGNITE-3299
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
> Fix For: 1.9
>
>
> Added test reproducing issue (IgniteCacheConcurrentPutGetRemove).
> 1. There is an issue with 'deferredDelete' implementation - entry marked as
> 'deleted' can be evicted from cache, after this information about remove is
> lost (note: this can be reproduced not only in OFFHEAP_TIERED, but also in
> ONHEAP_TIERED mode with eviction policy, also this can also cause lost update
> in transactional cache on changing topology).
> 2. Looks like condition for removing from offheap in
> GridCacheMapEntry.innerUpdate is not correct:
> {noformat}
> if (op != GridCacheOperation.UPDATE && cctx.offheapTiered() &&
> hasValPtr) {
> boolean rmv = cctx.swap().removeOffheap(key);
> {noformat}
> It is possible that value was put in offheap, but 'hasValPtr' is false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3722) Cached in a file text must be written with UTF-8 charset, not default
[ https://issues.apache.org/jira/browse/IGNITE-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3722: - Assignee: (was: Semen Boikov) > Cached in a file text must be written with UTF-8 charset, not default > - > > Key: IGNITE-3722 > URL: https://issues.apache.org/jira/browse/IGNITE-3722 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: Dmitry Karachentsev > Fix For: 1.8 > > > Writing/reading text files in default charset is error prone and UTF-8 must > be set explicitly. > F.e. > org.apache.ignite.internal.MarshallerContextImpl#className() and > org.apache.ignite.internal.MarshallerContextImpl.ContinuousQueryListener#onUpdated() > InputStreamReader() and OutputStreamWriter() must have charset set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3406) Interceptor and continuous query can get incorrect old value during rebalancing
[
https://issues.apache.org/jira/browse/IGNITE-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov updated IGNITE-3406:
-
Assignee: (was: Semen Boikov)
> Interceptor and continuous query can get incorrect old value during
> rebalancing
> ---
>
> Key: IGNITE-3406
> URL: https://issues.apache.org/jira/browse/IGNITE-3406
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
> Fix For: 1.8
>
>
> During the rebalancing the old value passed to interceptor or continuous
> query can't be wrong due to scenarios described below.
> Scenario 1.
> # New node joins.
> # Update request arrives to the new node before the entry for the same key is
> rebalanced to this node.
> # Listeners are notified with {{null}} old value.
> In this case we should use {{GridDhtForceKeysRequest}} to get the old value.
> Scenario 2.
> # Entry is updated on primary node.
> # New backup node joins and the entry with already updated value is
> rebalanced from the primary node.
> # Update request arrives to this new backup node.
> # Listeners are notified with the old value which is the same as new value.
> In this case we should send the old value with the update request in case
> there is ongoing rebalancing and cache has interceptor configured or
> continuous queries registered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3615) Failed test: IgniteCacheQueryNodeRestartDistributedJoinSelfTest.testRestartsBroadcast
[ https://issues.apache.org/jira/browse/IGNITE-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3615: - Fix Version/s: (was: 1.8) 1.9 > Failed test: > IgniteCacheQueryNodeRestartDistributedJoinSelfTest.testRestartsBroadcast > - > > Key: IGNITE-3615 > URL: https://issues.apache.org/jira/browse/IGNITE-3615 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Semen Boikov > Fix For: 1.9 > > Attachments: thread_dump.txt > > > Test hanged. Logs with stack trace is in attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1666) Fallback for full scan query does not work
[
https://issues.apache.org/jira/browse/IGNITE-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov updated IGNITE-1666:
-
Fix Version/s: (was: 1.8)
1.9
> Fallback for full scan query does not work
> --
>
> Key: IGNITE-1666
> URL: https://issues.apache.org/jira/browse/IGNITE-1666
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Andrey Gura
>Assignee: Semen Boikov
> Fix For: 1.9
>
>
> Fallback for full scan query doesn't work.
> Steps to reproduce (all in one thread):
> 1. Start N nodes, create cache and populate some entries to cache.
> 2. Stop some node.
> 3. Get iterator on the cache and fetch all entries one by one.
> 4. Repeat from step 2.
> On some iteration scan query fails with exception:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Query execution failed: GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1614)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:181)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.init(CacheWeakQueryIteratorsHolder.java:228)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:180)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.doTest(CacheIteratorWhileRemovalSelfTest.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.testFullScanIterator(CacheIteratorWhileRemovalSelfTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> Caused by: class org.apache.ignite.IgniteCheckedException: Query execution
> failed: GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
> clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.checkError(GridCacheQueryFutureAdapter.java:267)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.internalIterator(GridCacheQueryFutureAdapter.java:276)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:171)
> ... 14 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null], nodeId=203d0a36-8587-4a32-aa51-3332d126d002]
> at
> org.apache.ignite.internal.
[jira] [Updated] (IGNITE-1887) REST-HTTP change queryId generation from sequence to random.
[ https://issues.apache.org/jira/browse/IGNITE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-1887: - Assignee: (was: Semen Boikov) > REST-HTTP change queryId generation from sequence to random. > > > Key: IGNITE-1887 > URL: https://issues.apache.org/jira/browse/IGNITE-1887 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Novikov >Priority: Minor > Fix For: 1.8 > > > First problem: > 1. client1 execute query and get queryId = 1. > 2. node where query was executed is restarted (queryId generator > initialized to zero). > 3. client2 execute some query and also get queryId=1. > 4. client1 fetch next page for queryId=1 and GETS results of client2. > Second problem: > As queryId is generated sequentially it is very easy to brute force and > some client could get data of other clients too easy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-2698: - Fix Version/s: (was: 1.8) 1.9 > CacheKeyConfiguration is used only with BinaryMarshaller > > > Key: IGNITE-2698 > URL: https://issues.apache.org/jira/browse/IGNITE-2698 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 1.9 > > > Now if CacheKeyConfiguration is specified it is used only with > BinaryMarshaller. Need to take it into account with others marshallers as > well or update documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3336) Improve Ignite troubleshooting logging
[ https://issues.apache.org/jira/browse/IGNITE-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3336: - Assignee: (was: Semen Boikov) > Improve Ignite troubleshooting logging > -- > > Key: IGNITE-3336 > URL: https://issues.apache.org/jira/browse/IGNITE-3336 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Semen Boikov > Fix For: 1.8 > > > Currently there is method IgniteKernal.dumpDebugInfo which dumps important > troubleshooting information. Currently Ignite dumps this information when > partition exchange process hangs. In addition need add some background logic > which will check that there are no hanging operations (tx, atomic updates) > and dump debug info if there are any. > In addition need improve debug logging for cache operations: e.g. if I know > id of hanging tx it should be possible to grep logs by this id and find out > all steps of tx execution, maybe need add several levels of details for tx > execution to avoid too much logging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
