[jira] [Closed] (IGNITE-2282) Check that generated Docker file is valid and could be used by users
[ https://issues.apache.org/jira/browse/IGNITE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-2282. -- > Check that generated Docker file is valid and could be used by users > > > Key: IGNITE-2282 > URL: https://issues.apache.org/jira/browse/IGNITE-2282 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Alexey Kuznetsov > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2282) Check that generated Docker file is valid and could be used by users
[ https://issues.apache.org/jira/browse/IGNITE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov resolved IGNITE-2282. Resolution: Fixed Assignee: (was: Pavel Konstantinov) Tested. > Check that generated Docker file is valid and could be used by users > > > Key: IGNITE-2282 > URL: https://issues.apache.org/jira/browse/IGNITE-2282 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Alexey Kuznetsov > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2061) CPP: Implement obtaining of diagnostic information for ODBC driver.
[
https://issues.apache.org/jira/browse/IGNITE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2061:
Issue Type: Sub-task (was: Task)
Parent: IGNITE-1786
> CPP: Implement obtaining of diagnostic information for ODBC driver.
> ---
>
> Key: IGNITE-2061
> URL: https://issues.apache.org/jira/browse/IGNITE-2061
> Project: Ignite
> Issue Type: Sub-task
> Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> These API functions used by user to retrieve diagnostic information, such as
> error or warning messages.
> Here is the list of functions that need to be supported:
> - {{SQLGetDiagField}}
> - {{SQLGetDiagRec}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2371) ODBC driver does not return any data with SQLColumns and SQLTables calls.
Igor Sapego created IGNITE-2371:
---
Summary: ODBC driver does not return any data with SQLColumns and
SQLTables calls.
Key: IGNITE-2371
URL: https://issues.apache.org/jira/browse/IGNITE-2371
Project: Ignite
Issue Type: Sub-task
Components: odbc
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 1.6
When Tableau calls {{SQLColumns}} or {{SQLTables}} there is no data in result
set even though values which Tableau uses are returned by previous calls to
ODBC functions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2223) CPP: ODBC queries sometimes return wrong types for columns in metadata.
[ https://issues.apache.org/jira/browse/IGNITE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-2223: Issue Type: Sub-task (was: Bug) Parent: IGNITE-1786 > CPP: ODBC queries sometimes return wrong types for columns in metadata. > --- > > Key: IGNITE-2223 > URL: https://issues.apache.org/jira/browse/IGNITE-2223 > Project: Ignite > Issue Type: Sub-task > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego > Fix For: 1.6 > > > Some SQL queries return wrong types in metadata. For example, if query result > set has column of type "Decimal" it will be transferred as "Long" instead. As > a result, value can not be read in the application data buffer during row > fetch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2372) GridCacheAbstractDataStructuresFailoverSelfTest.testQueueConstant* fail sometimes
Artem Shutak created IGNITE-2372: Summary: GridCacheAbstractDataStructuresFailoverSelfTest.testQueueConstant* fail sometimes Key: IGNITE-2372 URL: https://issues.apache.org/jira/browse/IGNITE-2372 Project: Ignite Issue Type: Bug Reporter: Artem Shutak Assignee: Denis Magda Fix For: 1.6 The following tests fail on TC sometimes: - GridCachePartitionedDataStructuresFailoverSelfTest.testQueueConstantMultipleTopologyChange - GridCachePartitionedOffheapDataStructuresFailoverSelfTest.testQueueConstantMultipleTopologyChange TC build: http://ci.ignite.apache.org/viewLog.html?buildId=95910=buildResultsDiv=IgniteTests_IgniteDataStrucutures Test testQueueConstantMultipleTopologyChange failed on my laptop too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2032) Filters passed to ScanQuery are not redeployed when originating from a client node
[ https://issues.apache.org/jira/browse/IGNITE-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-2032: -- Assignee: Semen Boikov (was: Alexey Goncharuk) > Filters passed to ScanQuery are not redeployed when originating from a client > node > -- > > Key: IGNITE-2032 > URL: https://issues.apache.org/jira/browse/IGNITE-2032 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: ignite-1.4 >Reporter: Denis Magda >Assignee: Semen Boikov >Priority: Critical > Labels: important > Fix For: 1.6 > > Attachments: ScanQueryFailure.java, test-config.xml > > > The following case doesn't work: > - start a standalone server node with peer class loading enabled; > - start a client node, populate a cache with data, perform a scan query using > a filter; > - since the server doesn't have the filter in its classpath it will load it > from the client. Everything works fine here; > - stop the client, the server will undeploy the filter. No issue here so far; > - modify the filter a bit and start the client one more time. The server > won't deploy the new version of the filter and will be using the old > regardless of the fact that it was undeployed before according to the logs. > The server can be started using ignite.bat and test-config.xml (attached). > The source of the client is located in attached ScanQueryFailure.java. > BTW, everything works fine if to use the server mode instead of the client > one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2165) CPP: Tableau displays textual data in wrong locale.
[ https://issues.apache.org/jira/browse/IGNITE-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-2165: Issue Type: Sub-task (was: Bug) Parent: IGNITE-1786 > CPP: Tableau displays textual data in wrong locale. > --- > > Key: IGNITE-2165 > URL: https://issues.apache.org/jira/browse/IGNITE-2165 > Project: Ignite > Issue Type: Sub-task > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego > Fix For: 1.6 > > Attachments: screenshot-1.png > > > By some reason Tableau displays strings in wrong locale when using our ODBC > driver. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2163) CPP: ODBC driver supported version should be upgraded to 3.x
[ https://issues.apache.org/jira/browse/IGNITE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-2163: Issue Type: Sub-task (was: Task) Parent: IGNITE-1786 > CPP: ODBC driver supported version should be upgraded to 3.x > > > Key: IGNITE-2163 > URL: https://issues.apache.org/jira/browse/IGNITE-2163 > Project: Ignite > Issue Type: Sub-task > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego > Fix For: 1.6 > > > Currently our implementation of the ODBC driver states that it supports ODBC > standard version 2.0. It seems that many features that Tablue uses are not > supported in this version of the ODBC. So we need to set our version to 3.x > and make sure it works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2368) Performance optimization for an IgnitCache.query execution.
[ https://issues.apache.org/jira/browse/IGNITE-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ershov reassigned IGNITE-2368: --- Assignee: Yakov Zhdanov > Performance optimization for an IgnitCache.query execution. > --- > > Key: IGNITE-2368 > URL: https://issues.apache.org/jira/browse/IGNITE-2368 > Project: Ignite > Issue Type: Improvement > Components: SQL >Affects Versions: ignite-1.4 >Reporter: Vladimir Ershov >Assignee: Yakov Zhdanov > Labels: optimization > Original Estimate: 24h > Remaining Estimate: 24h > > Current solution of an sql query executed from client node for replicated > cache could be improved. > As for now we split initial query into map and reduce steps on a client > node, but it would be more effective just to send initial query to a data > node and execute it there without splitting since cache is replicated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2230) CPP: Implement "Bind offset" feature for the ODBC driver.
[ https://issues.apache.org/jira/browse/IGNITE-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-2230: Issue Type: Sub-task (was: Task) Parent: IGNITE-1786 > CPP: Implement "Bind offset" feature for the ODBC driver. > - > > Key: IGNITE-2230 > URL: https://issues.apache.org/jira/browse/IGNITE-2230 > Project: Ignite > Issue Type: Sub-task > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego > Fix For: 1.6 > > > This feature listed in the [ODBC Core Interface > Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx] > and should be implemented for our driver. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2062) CPP: Implement support of Linux OS family for the ODBC driver.
[ https://issues.apache.org/jira/browse/IGNITE-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-2062: Issue Type: Sub-task (was: Task) Parent: IGNITE-1786 > CPP: Implement support of Linux OS family for the ODBC driver. > -- > > Key: IGNITE-2062 > URL: https://issues.apache.org/jira/browse/IGNITE-2062 > Project: Ignite > Issue Type: Sub-task > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego > Fix For: 1.6 > > > ODBC driver should be buildable and usable on the Linux-based OS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2371) ODBC driver does not return any data with SQLColumns and SQLTables calls.
[
https://issues.apache.org/jira/browse/IGNITE-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096105#comment-15096105
]
Igor Sapego commented on IGNITE-2371:
-
An issue caused by quotation marks around the schema that should be removed
before cache lookup. The other issue is two part table names in format
{{"schema".table}} which should also be parsed in an appropriate way to extract
table name and schema.
> ODBC driver does not return any data with SQLColumns and SQLTables calls.
> -
>
> Key: IGNITE-2371
> URL: https://issues.apache.org/jira/browse/IGNITE-2371
> Project: Ignite
> Issue Type: Sub-task
> Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> When Tableau calls {{SQLColumns}} or {{SQLTables}} there is no data in result
> set even though values which Tableau uses are returned by previous calls to
> ODBC functions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2371) ODBC driver does not return any data with SQLColumns and SQLTables calls.
[
https://issues.apache.org/jira/browse/IGNITE-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego resolved IGNITE-2371.
-
Resolution: Fixed
Merged to parent development branch.
> ODBC driver does not return any data with SQLColumns and SQLTables calls.
> -
>
> Key: IGNITE-2371
> URL: https://issues.apache.org/jira/browse/IGNITE-2371
> Project: Ignite
> Issue Type: Sub-task
> Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> When Tableau calls {{SQLColumns}} or {{SQLTables}} there is no data in result
> set even though values which Tableau uses are returned by previous calls to
> ODBC functions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2210) Cannot query annotated methods when BinaryMarshaller is set.
[ https://issues.apache.org/jira/browse/IGNITE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096147#comment-15096147 ] Denis Magda commented on IGNITE-2210: - I'm not sure that it makes sense to consider [2] since indexed methods are usually created for cases when we want to get a particular value at particular point of time and a value returned by the method at time A can differ from a value returned at time B. As one more solution we can try to deserialize and object on the server side and execute a method. Yes it will require to have a class on the servers classpath. If we are not able to deserialize the value then we can throw exception from [1]. > Cannot query annotated methods when BinaryMarshaller is set. > > > Key: IGNITE-2210 > URL: https://issues.apache.org/jira/browse/IGNITE-2210 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Critical > Fix For: 1.6 > > > Because it is impossible to call method from object in binary form. Several > solutions could be applied here: > 1) Throw exception when method annotation is found and BinaryMarshaller is > set. > 2) Or call this method and record it as a field to the object. > Sample test: > IgniteCacheAbstractFieldsQuerySelfTest.testMethodAnnotationWithoutGet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2328) Object class is lost after cache.get if object implements Map
[ https://issues.apache.org/jira/browse/IGNITE-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-2328. -- Resolution: Fixed Fixed in ignite-2099 > Object class is lost after cache.get if object implements Map > - > > Key: IGNITE-2328 > URL: https://issues.apache.org/jira/browse/IGNITE-2328 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 1.6 > > > Added test (IgniteCacheStoreCollectionTest): put in cache object implementing > Map, cache get returns HashMap instead of original object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2099) Binary marshaller writes any map as a HashMap
[ https://issues.apache.org/jira/browse/IGNITE-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096204#comment-15096204 ] Alexey Goncharuk commented on IGNITE-2099: -- Fixed map/collection type unwraps. > Binary marshaller writes any map as a HashMap > - > > Key: IGNITE-2099 > URL: https://issues.apache.org/jira/browse/IGNITE-2099 > Project: Ignite > Issue Type: Bug > Components: general, interop >Reporter: Valentin Kulichenko >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.5 > > > Bug is described and discussed in this user@ thread: > http://apache-ignite-users.70518.x6.nabble.com/Serialization-issue-with-Ignite-1-5-built-from-master-357d791-td2149.html > In general, we need to make sure that binary marshaller fully supports Java > serialization and behaves consistently with optimized marshaller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2365) Cache inconsistency: concurrent preloading from a storage when OFF HEAP is used
[
https://issues.apache.org/jira/browse/IGNITE-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk resolved IGNITE-2365.
--
Resolution: Fixed
> Cache inconsistency: concurrent preloading from a storage when OFF HEAP is
> used
> ---
>
> Key: IGNITE-2365
> URL: https://issues.apache.org/jira/browse/IGNITE-2365
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Alexey Goncharuk
>Priority: Blocker
> Labels: important
> Fix For: 1.6
>
> Attachments: TwoNodesEviction.java
>
>
> Start two server nodes in parallel using {{TwoNodesEviction}} example
> attached.
> Both nodes start preloading the full set of data from an underlying storage
> considering that in a cache only data for which a node is primary will reside.
> However the node that joins the topology later will have much more entries in
> the on-heap part of the cache than expected ignoring eviction policy settings.
> If to disable the eviction policy and off-heap then the example works fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2099) Binary marshaller writes any map as a HashMap
[ https://issues.apache.org/jira/browse/IGNITE-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-2099. -- > Binary marshaller writes any map as a HashMap > - > > Key: IGNITE-2099 > URL: https://issues.apache.org/jira/browse/IGNITE-2099 > Project: Ignite > Issue Type: Bug > Components: general, interop >Reporter: Valentin Kulichenko >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.5 > > > Bug is described and discussed in this user@ thread: > http://apache-ignite-users.70518.x6.nabble.com/Serialization-issue-with-Ignite-1-5-built-from-master-357d791-td2149.html > In general, we need to make sure that binary marshaller fully supports Java > serialization and behaves consistently with optimized marshaller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2365) Cache inconsistency: concurrent preloading from a storage when OFF HEAP is used
[
https://issues.apache.org/jira/browse/IGNITE-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096203#comment-15096203
]
Alexey Goncharuk commented on IGNITE-2365:
--
The issue was caused by the missed eviction policy notification during
preloading in the case when entry was not loaded.
> Cache inconsistency: concurrent preloading from a storage when OFF HEAP is
> used
> ---
>
> Key: IGNITE-2365
> URL: https://issues.apache.org/jira/browse/IGNITE-2365
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Alexey Goncharuk
>Priority: Blocker
> Labels: important
> Fix For: 1.6
>
> Attachments: TwoNodesEviction.java
>
>
> Start two server nodes in parallel using {{TwoNodesEviction}} example
> attached.
> Both nodes start preloading the full set of data from an underlying storage
> considering that in a cache only data for which a node is primary will reside.
> However the node that joins the topology later will have much more entries in
> the on-heap part of the cache than expected ignoring eviction policy settings.
> If to disable the eviction policy and off-heap then the example works fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2375) Expiration is not set when value is loaded from store
[ https://issues.apache.org/jira/browse/IGNITE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-2375: -- Assignee: Semen Boikov > Expiration is not set when value is loaded from store > - > > Key: IGNITE-2375 > URL: https://issues.apache.org/jira/browse/IGNITE-2375 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Semen Boikov > Fix For: 1.6 > > Attachments: ExpireTest.java > > > Discussed on the user@ forum: > http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html > Test reproducing the issue is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2350) Make IGNITE_UPDATE_NOTIFIER per cluster setting
[ https://issues.apache.org/jira/browse/IGNITE-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov resolved IGNITE-2350. -- Resolution: Fixed Assignee: Sergey Kozlov (was: Semen Boikov) During implementation we found that approach with utility cache is not reliable (e.g. when daemon or client node starts first utility cache is not available). I implemented passing update notifier status in discovery data (commit 7175a42). Sergey, could you please verify this fix? Thanks > Make IGNITE_UPDATE_NOTIFIER per cluster setting > --- > > Key: IGNITE-2350 > URL: https://issues.apache.org/jira/browse/IGNITE-2350 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Sergey Kozlov >Priority: Critical > Labels: important > Fix For: 1.6 > > > We need to refactor update notification behavior to make it more transparent. > # The first node (topVer=1) should behave in accordance to its local settings > # The first node should set cluster-wide default which should survive its > (first node) exit. > # Further nodes should ignore local setting and respect cluster wide value > set on cluster start -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15097647#comment-15097647
]
Roman Shtykh commented on IGNITE-429:
-
Anton, thank you! Very good point on IGNITE_TUPLE_FIELD.
In 2, do you mean I have to check the cache is empty before the test data is
streamed via Storm? Why?
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Roman Shtykh
> Fix For: 1.6
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2375) Expiration is not set when value is loaded from store
[ https://issues.apache.org/jira/browse/IGNITE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-2375: - Fix Version/s: (was: 1.6) > Expiration is not set when value is loaded from store > - > > Key: IGNITE-2375 > URL: https://issues.apache.org/jira/browse/IGNITE-2375 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Semen Boikov > Attachments: ExpireTest.java > > > Discussed on the user@ forum: > http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html > Test reproducing the issue is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2375) Expiration is not set when value is loaded from store
Valentin Kulichenko created IGNITE-2375: --- Summary: Expiration is not set when value is loaded from store Key: IGNITE-2375 URL: https://issues.apache.org/jira/browse/IGNITE-2375 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Fix For: 1.6 Discussed on the user@ forum: http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html Test reproducing the issue is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2374) Expiration is not set when value is loaded from store
Valentin Kulichenko created IGNITE-2374: --- Summary: Expiration is not set when value is loaded from store Key: IGNITE-2374 URL: https://issues.apache.org/jira/browse/IGNITE-2374 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Fix For: 1.6 Discussed on the user@ forum: http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html Test reproducing the issue is attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2346) Rework java code generation of DataSource
[ https://issues.apache.org/jira/browse/IGNITE-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15093867#comment-15093867 ] Vasiliy Sisko edited comment on IGNITE-2346 at 1/14/16 3:03 AM: In Java configuration builder Implemented generation of data source as separated singleton bean. Data source generates for POJO store and BLOB store factory. For BLOB store implemented second variant of connection by URL. Fixed generation of code in Java and XML for BLOB and Hibernate store. was (Author: vsisko): Implemented generation of datasourse as separated singleton bean. Fixed generation of data source for not jdbc pojo store factory Left: Database specific of datasoruce. > Rework java code generation of DataSource > - > > Key: IGNITE-2346 > URL: https://issues.apache.org/jira/browse/IGNITE-2346 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Alexey Kuznetsov >Assignee: Vasiliy Sisko > Fix For: 1.6 > > > Current code generation create datasource for each cache. > This should be refactored to single method that should be reused. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2346) Rework java code generation of DataSource
[ https://issues.apache.org/jira/browse/IGNITE-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko resolved IGNITE-2346. --- Resolution: Fixed Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Rework java code generation of DataSource > - > > Key: IGNITE-2346 > URL: https://issues.apache.org/jira/browse/IGNITE-2346 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov > Fix For: 1.6 > > > Current code generation create datasource for each cache. > This should be refactored to single method that should be reused. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2375) Expiration is not set when value is loaded from store
[ https://issues.apache.org/jira/browse/IGNITE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2375: Attachment: ExpireTest.java > Expiration is not set when value is loaded from store > - > > Key: IGNITE-2375 > URL: https://issues.apache.org/jira/browse/IGNITE-2375 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko > Fix For: 1.6 > > Attachments: ExpireTest.java > > > Discussed on the user@ forum: > http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html > Test reproducing the issue is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (IGNITE-2347) Rework demo for load metadata
[ https://issues.apache.org/jira/browse/IGNITE-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reopened IGNITE-2347: Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) 1) Next should be unavailable in case of h2.jar is missing. 2) Also please show error message inside dialog in case of no one jdbc-driver was found (currently the dialog is closes and error appears in the right top corner of the screen) > Rework demo for load metadata > - > > Key: IGNITE-2347 > URL: https://issues.apache.org/jira/browse/IGNITE-2347 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > > # Add button "Load from demo database" > # Add "Remove demo types" option -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2347) Rework demo for load metadata
[ https://issues.apache.org/jira/browse/IGNITE-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15097562#comment-15097562 ] Pavel Konstantinov edited comment on IGNITE-2347 at 1/14/16 4:20 AM: - 1) 'Next' should be unavailable in case of h2.jar is missing. 2) Also please show error message inside dialog in case of no one jdbc-driver was found (currently the dialog is closes and error appears in the right top corner of the screen) was (Author: pkonstantinov): 1) Next should be unavailable in case of h2.jar is missing. 2) Also please show error message inside dialog in case of no one jdbc-driver was found (currently the dialog is closes and error appears in the right top corner of the screen) > Rework demo for load metadata > - > > Key: IGNITE-2347 > URL: https://issues.apache.org/jira/browse/IGNITE-2347 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > > # Add button "Load from demo database" > # Add "Remove demo types" option -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2347) Rework demo for load metadata
[ https://issues.apache.org/jira/browse/IGNITE-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-2347. -- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Load metadata demo was reworked and simplified. Now user could click on special button "Load from demo database". Also after user load demo metadata this button will show dropdown with menu item "Remove generated demo metadata". > Rework demo for load metadata > - > > Key: IGNITE-2347 > URL: https://issues.apache.org/jira/browse/IGNITE-2347 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov > Fix For: 1.6 > > > # Add button "Load from demo database" > # Add "Remove demo types" option -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2324) .NET: Code analysis
[ https://issues.apache.org/jira/browse/IGNITE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094094#comment-15094094 ] Pavel Tupitsyn edited comment on IGNITE-2324 at 1/13/16 4:22 PM: - Findings: * SonarQube is too complicated to set up on TC, skip it for now * .FxCop file is an old and inconvenient way of setting up analysis, not compatible with VS2012+ built-in analyzer. We should configure rule set in .ruleset file. * ReSharper inspections are built-in on TC TODO: * Set up .ruleset file with relevant rules * Enable analysis on build so that VS shows warnings during development * Run separate step on TC with /p:CodeAnalysisTreatWarningsAsErrors that will fail in case of analysis issues * Add ReSharper inspections step was (Author: ptupitsyn): Findings: * SonarQube is too complicated to set up on TC, skip it for now * .FxCop file is an old and inconvenient way of setting up analysis, not compatible with VS2010+ built-in analyzer. Instead, we should configure rule set in .ruleset file. * ReSharper inspections are built-in on TC TODO: * Get rid of fxcop file * Set up .ruleset file with relevant rules * Enable analysis on build so that VS shows warnings during development * Run separate step on TC with /p:CodeAnalysisTreatWarningsAsErrors that will fail in case of analysis issues * Add ReSharper inspections step > .NET: Code analysis > --- > > Key: IGNITE-2324 > URL: https://issues.apache.org/jira/browse/IGNITE-2324 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > * Investigate code analysis tools (FxCop, SonarQube, etc) > * Set up a step on TeamCity > * Set up visual studio to check on build > * Modify code (adjust inspections/suppressions) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2373) Revisit server side error handling logic
Alexey Kuznetsov created IGNITE-2373:
Summary: Revisit server side error handling logic
Key: IGNITE-2373
URL: https://issues.apache.org/jira/browse/IGNITE-2373
Project: Ignite
Issue Type: Sub-task
Components: wizards
Affects Versions: 1.5
Reporter: Alexey Kuznetsov
Assignee: Andrey Novikov
Fix For: 1.6
We have in /routes 14 times
{code}
send(err)
{code}
and 27 times
{code}
send(err.message)
{code}
It seems for me that we should always use send(err)
And also I think we could introduce a couple of utility functions to reduce
boilerplate code like this
{code}
if (err)
return res.status(500).send(err.message);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2373) Revisit server side error handling logic
[
https://issues.apache.org/jira/browse/IGNITE-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-2373:
-
Description:
We have in /routes 14 times
{code}
send(err)
{code}
and 27 times
{code}
send(err.message)
{code}
It seems for me that we should always use send(err)
And also I think we could introduce a couple of utility functions to reduce
boilerplate code like this
{code}
if (err)
return res.status(500).send(err.message);
{code}
was:
We have in /routes 14 times
{code}
send(err)
{code}
and 27 times
{code}
send(err.message)
{code}
It seems for me that we should always use send(err)
And also I think we could introduce a couple of utility functions to reduce
boilerplate code like this
{code}
if (err)
return res.status(500).send(err.message);
{code}
> Revisit server side error handling logic
>
>
> Key: IGNITE-2373
> URL: https://issues.apache.org/jira/browse/IGNITE-2373
> Project: Ignite
> Issue Type: Sub-task
> Components: wizards
>Affects Versions: 1.5
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 1.6
>
>
> We have in /routes 14 times
> {code}
> send(err)
> {code}
> and 27 times
> {code}
> send(err.message)
> {code}
> It seems for me that we should always use send(err)
> And also I think we could introduce a couple of utility functions to reduce
> boilerplate code like this
> {code}
> if (err)
> return res.status(500).send(err.message);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2191) Binary marshaller: support user classes with the same simple name
[ https://issues.apache.org/jira/browse/IGNITE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096242#comment-15096242 ] Artem Shutak commented on IGNITE-2191: -- I didn't see new failed tests in queries related to changes described above. Also, I played with queries by yourself. So I don't expect big problems with queries. > Binary marshaller: support user classes with the same simple name > - > > Key: IGNITE-2191 > URL: https://issues.apache.org/jira/browse/IGNITE-2191 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Denis Magda >Assignee: Artem Shutak >Priority: Critical > Labels: important > Fix For: 1.6 > > > Presently the user won't be able to use across the cluster object that have a > single simple name. > As an example if the user has 'org.comp.MyObject' and > 'org.apache.comp.MyObject' then he won't be able to have them both in a > cluster because marshalling mechanism supports uniqueness at simple name > level only. > There are several reasons for that: > - interoperability with other platforms; > - queries that use simple name is their 'where' clause. > In general according to the API as a workaround the user can implement its > own BinaryIdMapper returning a precise id for every class. However there is a > bug in BinaryContext that passes simple name rather than a full name to a > BinaryIdMapper implementation. BinaryIdMapper must be fixed as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096340#comment-15096340
]
Anton Vinogradov commented on IGNITE-429:
-
Roman I've made minor fixes:
https://github.com/avinogradovgg/ignite/commit/3beab7debdfaa7ac6962ed4bdd33e40fea5f067e
Also,
1) Seems that IGNITE_TUPLE_FIELD should be configurable.
2) Cache content should be cheched before and after test.
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Roman Shtykh
> Fix For: 1.6
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2191) Binary marshaller: support user classes with the same simple name
[
https://issues.apache.org/jira/browse/IGNITE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096662#comment-15096662
]
Artem Shutak commented on IGNITE-2191:
--
Found that BinaryIdMapper has the following contact:
{code}
/**
* Gets type ID for provided class name.
*
* If {@code 0} is returned, hash code of class simple name will be used.
*
* @param clsName Class name.
* @return Type ID.
*/
public int typeId(String clsName);
{code}
So, If a user uses a custom implementation for id mapper we have to delegate a
calculation of typeId to BinarySimpleNameIdMapper if the custom implementation
returns 'zero'.
> Binary marshaller: support user classes with the same simple name
> -
>
> Key: IGNITE-2191
> URL: https://issues.apache.org/jira/browse/IGNITE-2191
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Critical
> Labels: important
> Fix For: 1.6
>
>
> Presently the user won't be able to use across the cluster object that have a
> single simple name.
> As an example if the user has 'org.comp.MyObject' and
> 'org.apache.comp.MyObject' then he won't be able to have them both in a
> cluster because marshalling mechanism supports uniqueness at simple name
> level only.
> There are several reasons for that:
> - interoperability with other platforms;
> - queries that use simple name is their 'where' clause.
> In general according to the API as a workaround the user can implement its
> own BinaryIdMapper returning a precise id for every class. However there is a
> bug in BinaryContext that passes simple name rather than a full name to a
> BinaryIdMapper implementation. BinaryIdMapper must be fixed as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2191) Binary marshaller: support user classes with the same simple name
[
https://issues.apache.org/jira/browse/IGNITE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096662#comment-15096662
]
Artem Shutak edited comment on IGNITE-2191 at 1/13/16 5:49 PM:
---
Found that BinaryIdMapper has the following contract:
{code}
/**
* Gets type ID for provided class name.
*
* If {@code 0} is returned, hash code of class simple name will be used.
*
* @param clsName Class name.
* @return Type ID.
*/
public int typeId(String clsName);
{code}
So, If a user uses a custom implementation for id mapper we have to delegate a
calculation of typeId to BinarySimpleNameIdMapper if the custom implementation
returns 'zero'.
was (Author: ashutak):
Found that BinaryIdMapper has the following contact:
{code}
/**
* Gets type ID for provided class name.
*
* If {@code 0} is returned, hash code of class simple name will be used.
*
* @param clsName Class name.
* @return Type ID.
*/
public int typeId(String clsName);
{code}
So, If a user uses a custom implementation for id mapper we have to delegate a
calculation of typeId to BinarySimpleNameIdMapper if the custom implementation
returns 'zero'.
> Binary marshaller: support user classes with the same simple name
> -
>
> Key: IGNITE-2191
> URL: https://issues.apache.org/jira/browse/IGNITE-2191
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Critical
> Labels: important
> Fix For: 1.6
>
>
> Presently the user won't be able to use across the cluster object that have a
> single simple name.
> As an example if the user has 'org.comp.MyObject' and
> 'org.apache.comp.MyObject' then he won't be able to have them both in a
> cluster because marshalling mechanism supports uniqueness at simple name
> level only.
> There are several reasons for that:
> - interoperability with other platforms;
> - queries that use simple name is their 'where' clause.
> In general according to the API as a workaround the user can implement its
> own BinaryIdMapper returning a precise id for every class. However there is a
> bug in BinaryContext that passes simple name rather than a full name to a
> BinaryIdMapper implementation. BinaryIdMapper must be fixed as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
