[jira] [Created] (IGNITE-1813) Need to add metrics for data structures
Valentin Kulichenko created IGNITE-1813:
---
Summary: Need to add metrics for data structures
Key: IGNITE-1813
URL: https://issues.apache.org/jira/browse/IGNITE-1813
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Valentin Kulichenko
All data structures (queues, sets, atomics, etc.) are based on internal caches,
therefore there is no way to get metrics for this caches.
We should create an interface that will contain metrics suitable for data
structures and add {{metrics()}} method to all data structures that will return
the instance of this interface for a particular data structure.
Here is the corresponding user@ thread:
http://apache-ignite-users.70518.x6.nabble.com/Queue-stats-td1727.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1886) NPE in H2 when running query with subselects
Valentin Kulichenko created IGNITE-1886:
---
Summary: NPE in H2 when running query with subselects
Key: IGNITE-1886
URL: https://issues.apache.org/jira/browse/IGNITE-1886
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 1.5
Test reproducing the issue is attached. NPE is thrown as a result (see below).
Corresponding user@ thread:
http://apache-ignite-users.70518.x6.nabble.com/Does-Ignite-support-nested-SQL-Queries-td1714.html
{noformat}
Exception in thread "main" javax.cache.CacheException: class
org.apache.ignite.IgniteException: Failed to parse query: SELECT a.* FROM
(SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id FROM "UserCache".user
u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE WHEN og.goodid < 5 THEN
100 ELSE og.goodid END id FROM userorder ug, "OrderGoodCache".ordergood og
WHERE ug.id = og.orderid) b WHERE a.id = b.id
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:636)
at
org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:70)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: class org.apache.ignite.IgniteException: Failed to parse query:
SELECT a.* FROM (SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id FROM
"UserCache".user u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE WHEN
og.goodid < 5 THEN 100 ELSE og.goodid END id FROM userorder ug,
"OrderGoodCache".ordergood og WHERE ug.id = og.orderid) b WHERE a.id = b.id
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:641)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:627)
... 6 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to parse
query: SELECT a.* FROM (SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id
FROM "UserCache".user u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE
WHEN og.goodid < 5 THEN 100 ELSE og.goodid END id FROM userorder ug,
"OrderGoodCache".ordergood og WHERE ug.id = og.orderid) b WHERE a.id = b.id
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1510)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:634)
... 7 more
Caused by: javax.cache.CacheException: Failed to parse query: SELECT a.* FROM
(SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id FROM "UserCache".user
u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE WHEN og.goodid < 5 THEN
100 ELSE og.goodid END id FROM userorder ug, "OrderGoodCache".ordergood og
WHERE ug.id = og.orderid) b WHERE a.id = b.id
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:938)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:636)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:634)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1492)
... 8 more
Caused by: org.h2.jdbc.JdbcSQLException: General error:
"java.lang.NullPointerException" [5-175]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:332)
at org.h2.message.DbException.get(DbException.java:161)
at org.h2.message.DbException.convert(DbException.java:284)
at org.h2.message.DbException.toSQLException(DbException.java:257)
at org.h2.message.TraceObject.logAndConvert(TraceObject.java:368)
at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:270)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:935)
... 12 more
Caused by: java.lang.NullPointerException
at org.h2.expression.Function.getCost(Function.java:2391)
at org.h2.expression.Comparison.getCost(Comparison.java:480)
at org.h2.expression.ConditionAndOr.optimize(ConditionAndOr.java:133)
at org.h2.expression.ConditionAndOr.optimize(ConditionAndOr.java:131)
at org.h2.command.dml.Select.prepare(Select.java:813)
at
[jira] [Updated] (IGNITE-1840) Exception in eviction manager on startup
[
https://issues.apache.org/jira/browse/IGNITE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1840:
Fix Version/s: 1.5
> Exception in eviction manager on startup
>
>
> Key: IGNITE-1840
> URL: https://issues.apache.org/jira/browse/IGNITE-1840
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.5
>
>
> It's rarely reproduced and looks like a race condition on startup. In some
> cases eviction backup worker start to work too early which leads to this
> exception on first iterations:
> {noformat}
> Exception in thread "cache-eviction-backup-worker-#40%null%"
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:423)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.primaryPartitions(GridAffinityAssignmentCache.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryPartitions(GridCacheAffinityManager.java:352)
> at
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager$BackupWorker.body(GridCacheEvictionManager.java:1478)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1840) Exception in eviction manager on startup
[
https://issues.apache.org/jira/browse/IGNITE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko reassigned IGNITE-1840:
---
Assignee: Valentin Kulichenko
> Exception in eviction manager on startup
>
>
> Key: IGNITE-1840
> URL: https://issues.apache.org/jira/browse/IGNITE-1840
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.5
>
>
> It's rarely reproduced and looks like a race condition on startup. In some
> cases eviction backup worker start to work too early which leads to this
> exception on first iterations:
> {noformat}
> Exception in thread "cache-eviction-backup-worker-#40%null%"
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:423)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.primaryPartitions(GridAffinityAssignmentCache.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryPartitions(GridCacheAffinityManager.java:352)
> at
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager$BackupWorker.body(GridCacheEvictionManager.java:1478)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1864) Cannot configure jndiNames for CacheJndiTmLookup
[ https://issues.apache.org/jira/browse/IGNITE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko reassigned IGNITE-1864: --- Assignee: Valentin Kulichenko > Cannot configure jndiNames for CacheJndiTmLookup > - > > Key: IGNITE-1864 > URL: https://issues.apache.org/jira/browse/IGNITE-1864 > Project: Ignite > Issue Type: Bug >Reporter: Yakov Zhdanov >Assignee: Valentin Kulichenko > Fix For: 1.6 > > > Since user have an ability to configure only lookup class name via > org.apache.ignite.configuration.TransactionConfiguration#getTxManagerLookupClassName, > he lacks ability to properly configure all of its properties. > This seems to be a general problem for this approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1926) Implement IgfsSecondaryFileSystem using java.io.File API
[ https://issues.apache.org/jira/browse/IGNITE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1926: Component/s: newbie > Implement IgfsSecondaryFileSystem using java.io.File API > > > Key: IGNITE-1926 > URL: https://issues.apache.org/jira/browse/IGNITE-1926 > Project: Ignite > Issue Type: Improvement > Components: IGFS, newbie >Reporter: Valentin Kulichenko > Labels: newbie > > This will allow to persist IGFS data on the local disk. Currently we have > only Hadoop-based implementation. > Corresponding user thread: > http://apache-ignite-users.70518.x6.nabble.com/IGFS-backed-by-persistence-on-physical-filesystem-td1882.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1926) Implement IgfsSecondaryFileSystem using java.io.File API
Valentin Kulichenko created IGNITE-1926: --- Summary: Implement IgfsSecondaryFileSystem using java.io.File API Key: IGNITE-1926 URL: https://issues.apache.org/jira/browse/IGNITE-1926 Project: Ignite Issue Type: Improvement Components: IGFS Reporter: Valentin Kulichenko This will allow to persist IGFS data on the local disk. Currently we have only Hadoop-based implementation. Corresponding user thread: http://apache-ignite-users.70518.x6.nabble.com/IGFS-backed-by-persistence-on-physical-filesystem-td1882.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1926) Implement IgfsSecondaryFileSystem using java.io.File API
[ https://issues.apache.org/jira/browse/IGNITE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1926: Labels: newbie (was: ) > Implement IgfsSecondaryFileSystem using java.io.File API > > > Key: IGNITE-1926 > URL: https://issues.apache.org/jira/browse/IGNITE-1926 > Project: Ignite > Issue Type: Improvement > Components: IGFS >Reporter: Valentin Kulichenko > Labels: newbie > > This will allow to persist IGFS data on the local disk. Currently we have > only Hadoop-based implementation. > Corresponding user thread: > http://apache-ignite-users.70518.x6.nabble.com/IGFS-backed-by-persistence-on-physical-filesystem-td1882.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1897) Add failover to write-behind cache store
Valentin Kulichenko created IGNITE-1897: --- Summary: Add failover to write-behind cache store Key: IGNITE-1897 URL: https://issues.apache.org/jira/browse/IGNITE-1897 Project: Ignite Issue Type: Improvement Components: cache Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko Priority: Critical Fix For: 1.6 Currently there is a possibility of losing database updates if primary node fails. We should maintain updates queue on backup node as well and flush it if needed. The implementation should be similar to what is done with continuous queries in scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1897) Add failover to write-behind cache store
[ https://issues.apache.org/jira/browse/IGNITE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1897: Description: Currently there is a possibility of losing database updates if primary node fails. We should maintain updates queue on backup node as well and flush it if needed. The implementation should be similar to what is done with continuous queries in scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426 Corresponding user@ thread: http://apache-ignite-users.70518.x6.nabble.com/Write-behind-question-td1936.html was: Currently there is a possibility of losing database updates if primary node fails. We should maintain updates queue on backup node as well and flush it if needed. The implementation should be similar to what is done with continuous queries in scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426 > Add failover to write-behind cache store > > > Key: IGNITE-1897 > URL: https://issues.apache.org/jira/browse/IGNITE-1897 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Critical > Fix For: 1.6 > > > Currently there is a possibility of losing database updates if primary node > fails. We should maintain updates queue on backup node as well and flush it > if needed. > The implementation should be similar to what is done with continuous queries > in scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426 > Corresponding user@ thread: > http://apache-ignite-users.70518.x6.nabble.com/Write-behind-question-td1936.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1864) Cannot configure jndiNames for CacheJndiTmLookup
[
https://issues.apache.org/jira/browse/IGNITE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14997672#comment-14997672
]
Valentin Kulichenko commented on IGNITE-1864:
-
I think we should deprecate {{CacheTmLookup}} interface with its
implementations and {{txManagerLookupClassName}} configuration property. We can
use JCache factory instead:
{code}
TransactionConfiguration.setTxManagerFactory(Factory
factory)
{code}
> Cannot configure jndiNames for CacheJndiTmLookup
> -
>
> Key: IGNITE-1864
> URL: https://issues.apache.org/jira/browse/IGNITE-1864
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Yakov Zhdanov
>Assignee: Valentin Kulichenko
> Fix For: 1.6
>
>
> Since user have an ability to configure only lookup class name via
> org.apache.ignite.configuration.TransactionConfiguration#getTxManagerLookupClassName,
> he lacks ability to properly configure all of its properties.
> This seems to be a general problem for this approach
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1864) Cannot configure jndiNames for CacheJndiTmLookup
[ https://issues.apache.org/jira/browse/IGNITE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1864: Priority: Critical (was: Major) > Cannot configure jndiNames for CacheJndiTmLookup > - > > Key: IGNITE-1864 > URL: https://issues.apache.org/jira/browse/IGNITE-1864 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Yakov Zhdanov >Assignee: Valentin Kulichenko >Priority: Critical > Fix For: 1.6 > > > Since user have an ability to configure only lookup class name via > org.apache.ignite.configuration.TransactionConfiguration#getTxManagerLookupClassName, > he lacks ability to properly configure all of its properties. > This seems to be a general problem for this approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1840) Exception on startup
Valentin Kulichenko created IGNITE-1840:
---
Summary: Exception on startup
Key: IGNITE-1840
URL: https://issues.apache.org/jira/browse/IGNITE-1840
Project: Ignite
Issue Type: Bug
Reporter: Valentin Kulichenko
It's rarely reproduced and looks like a race condition on startup. In some
cases eviction backup worker start to work too early which leads to this
exception on first iterations:
{noformat}
Exception in thread "cache-eviction-backup-worker-#40%null%"
java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:423)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.primaryPartitions(GridAffinityAssignmentCache.java:397)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryPartitions(GridCacheAffinityManager.java:352)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager$BackupWorker.body(GridCacheEvictionManager.java:1478)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1840) Exception in eviction manager on startup
[
https://issues.apache.org/jira/browse/IGNITE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1840:
Affects Version/s: ignite-1.4
> Exception in eviction manager on startup
>
>
> Key: IGNITE-1840
> URL: https://issues.apache.org/jira/browse/IGNITE-1840
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Valentin Kulichenko
>
> It's rarely reproduced and looks like a race condition on startup. In some
> cases eviction backup worker start to work too early which leads to this
> exception on first iterations:
> {noformat}
> Exception in thread "cache-eviction-backup-worker-#40%null%"
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:423)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.primaryPartitions(GridAffinityAssignmentCache.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryPartitions(GridCacheAffinityManager.java:352)
> at
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager$BackupWorker.body(GridCacheEvictionManager.java:1478)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1840) Exception in eviction manager on startup
[
https://issues.apache.org/jira/browse/IGNITE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1840:
Component/s: cache
> Exception in eviction manager on startup
>
>
> Key: IGNITE-1840
> URL: https://issues.apache.org/jira/browse/IGNITE-1840
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Valentin Kulichenko
>
> It's rarely reproduced and looks like a race condition on startup. In some
> cases eviction backup worker start to work too early which leads to this
> exception on first iterations:
> {noformat}
> Exception in thread "cache-eviction-backup-worker-#40%null%"
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:423)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.primaryPartitions(GridAffinityAssignmentCache.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryPartitions(GridCacheAffinityManager.java:352)
> at
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager$BackupWorker.body(GridCacheEvictionManager.java:1478)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1559) Need to improve tests, javadoc and documentation of UriDeploymentHttpScanner.
[ https://issues.apache.org/jira/browse/IGNITE-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-1559. --- > Need to improve tests, javadoc and documentation of UriDeploymentHttpScanner. > - > > Key: IGNITE-1559 > URL: https://issues.apache.org/jira/browse/IGNITE-1559 > Project: Ignite > Issue Type: Task >Reporter: Artem Shutak >Assignee: Valentin Kulichenko >Priority: Critical > Fix For: 1.5 > > > Need to improve tests, javadoc and documentation of UriDeploymentHttpScanner. > It's not possible to understand from current javadoc of > UriDeploymentHttpScanner how it works. > There's only one simple test in GridHttpDeploymentSelfTest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1622) clear() method works incorrectly with near caches
[
https://issues.apache.org/jira/browse/IGNITE-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-1622.
---
> clear() method works incorrectly with near caches
> -
>
> Key: IGNITE-1622
> URL: https://issues.apache.org/jira/browse/IGNITE-1622
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: user-request
> Fix For: 1.5
>
>
> Currently {{IgniteCache.clear()}} method doesn't clear server nodes if there
> are near entries. Instead it should clear all caches, including near and
> readers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1622) clear() method works incorrectly with near caches
[
https://issues.apache.org/jira/browse/IGNITE-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14959812#comment-14959812
]
Valentin Kulichenko commented on IGNITE-1622:
-
Thanks Alex, this was a JavaDoc issue.
PR is merged to master.
> clear() method works incorrectly with near caches
> -
>
> Key: IGNITE-1622
> URL: https://issues.apache.org/jira/browse/IGNITE-1622
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: user-request
> Fix For: 1.5
>
>
> Currently {{IgniteCache.clear()}} method doesn't clear server nodes if there
> are near entries. Instead it should clear all caches, including near and
> readers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1726) Node doesn't fail if SSL configuration is incorrect
Valentin Kulichenko created IGNITE-1726: --- Summary: Node doesn't fail if SSL configuration is incorrect Key: IGNITE-1726 URL: https://issues.apache.org/jira/browse/IGNITE-1726 Project: Ignite Issue Type: Bug Components: general Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko Currently if two nodes start - one with SSL enable and another with SSL disabled - they both start successfully, but with order 1, i.e., as parts of different topologies. We should detect this misconfiguration and throw an exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1727) Shmem library can't be loaded by different class loaders within one JVM
Valentin Kulichenko created IGNITE-1727:
---
Summary: Shmem library can't be loaded by different class loaders
within one JVM
Key: IGNITE-1727
URL: https://issues.apache.org/jira/browse/IGNITE-1727
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
This can happen, for example, when an application is redeployed in an app
server.
{noformat}
16:41:55,042 WARN [org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi]
(ignite-#40%rest-fsb-grid%) Failed to load native IPC library:
[java.lang.UnsatisfiedLinkError: no igniteshmem-1.4.1 in java.library.path,
java.lang.UnsatisfiedLinkError: Native Library
/tmp/adrien/libigniteshmem-1.4.1.so already loaded in another classloader,
java.lang.IllegalStateException: Failed to find resource with specified class
loader [rsrc=META-INF/native/linux/libigniteshmem.so, clsLdr=ModuleClassLoader
for Module
"deployment.sport-assemblies-ss-ear-0.0.1.ear.sport-ss-ejb-0.0.1.jar:main" from
Service Module Loader], java.lang.IllegalStateException: Failed to find
resource with specified class loader [rsrc=META-INF/native/libigniteshmem.so,
clsLdr=ModuleClassLoader for Module
"deployment.sport-assemblies-ss-ear-0.0.1.ear.sport-ss-ejb-0.0.1.jar:main" from
Service Module Loader]]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1122) Cache put hangs if key hashCode is implemented incorrectly
[
https://issues.apache.org/jira/browse/IGNITE-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1122:
Fix Version/s: (was: 1.5)
> Cache put hangs if key hashCode is implemented incorrectly
> --
>
> Key: IGNITE-1122
> URL: https://issues.apache.org/jira/browse/IGNITE-1122
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Labels: Usability
>
> If key {{hashCode()}} returns inconsistent result (e.g., user used
> {{Enum.hashCode()}} in his implementation), the exception below is thrown on
> a server node and put operation hangs.
> {code}
> SEVERE: Future execution resulted in error: GridEmbeddedFuture
> [embedded=GridFinishedFuture [resFlag=2, startTime=1436797251202]]
> class org.apache.ignite.IgniteCheckedException: Creating partition which does
> not belong [part=118, topVer=AffinityTopologyVersion [topVer=5,
> minorTopVer=4], this.topVer=AffinityTopologyVersion [topVer=5, minorTopVer=4]]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6753)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:124)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:851)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:848)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:241)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:204)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:525)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$000(GridDhtTransactionalCacheAdapter.java:52)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:96)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:94)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:532)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:240)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:158)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:48)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:690)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:58)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:653)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
> [part=118, msg=Creating partition which does not belong [part=118,
> topVer=AffinityTopologyVersion [topVer=5, minorTopVer=4],
> this.topVer=AffinityTopologyVersion [topVer=5, minorTopVer=4]]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:527)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:496)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.onAdded(GridDhtPartitionTopologyImpl.java:580)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.(GridDhtCacheEntry.java:79)
> at
>
[jira] [Created] (IGNITE-1622) clear() method works incorrectly with near caches
Valentin Kulichenko created IGNITE-1622:
---
Summary: clear() method works incorrectly with near caches
Key: IGNITE-1622
URL: https://issues.apache.org/jira/browse/IGNITE-1622
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
Fix For: ignite-1.5
Currently {{IgniteCache.clear()}} method doesn't clear server nodes if there
are near entries. Instead it should clear all caches, including near and
readers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-638) Implement IgniteSemaphore data structure
[
https://issues.apache.org/jira/browse/IGNITE-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951199#comment-14951199
]
Valentin Kulichenko commented on IGNITE-638:
Hi Vladislav,
I looked through the code and here are my comments:
# I don't see a single test for the new functionality. Please provide good
coverage including multi-node tests with restarts.
# Example doesn't compile on line 56. Also I think it's a bit too complicated.
It's main purpose is to show how to use the API, so it needs to be as simple as
possible.
# {{GridCacheSemaphoreState.isFair()}} will always return {{false}}, because
the constructor that sets it is never used. I believe it's a bug.
# You throw an exception if initial number of permits is negative. Java
semaphore allows it and I think we should be consistent.
# Method names should not be abbreviated. E.g.,
{{GridCacheSemaphoreState.getCnt()}} should be
{{GridCacheSemaphoreState.getCount()}}.
# Braces are not always used according to guidelines [1]. For example, see
{{DataStructuresProcessor}}, lines 1319-1325.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-BracesandIdentation
> Implement IgniteSemaphore data structure
>
>
> Key: IGNITE-638
> URL: https://issues.apache.org/jira/browse/IGNITE-638
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Affects Versions: sprint-9
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
> Labels: features, newbie
> Fix For: 1.5
>
>
> We need to add {{IgniteSemaphore}} data structure in addition to other data
> structures provided by Ignite. {{IgniteSemaphore}} should have similar API to
> {{java.util.concurrent.IgniteSemaphore}} class in JDK.
> As an example, you can see how
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
> is implemented in
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
> class.
> In general we need to have an entity in ATOMIC cache storing number of
> permits and allow user threads to block whenever no more permits are
> available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1886) NPE in H2 when running query with subselects
[
https://issues.apache.org/jira/browse/IGNITE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1886:
Attachment: QueryTest.java
Test is attached.
> NPE in H2 when running query with subselects
>
>
> Key: IGNITE-1886
> URL: https://issues.apache.org/jira/browse/IGNITE-1886
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Sergi Vladykin
>Priority: Critical
> Fix For: 1.5
>
> Attachments: QueryTest.java
>
>
> Test reproducing the issue is attached. NPE is thrown as a result (see below).
> Corresponding user@ thread:
> http://apache-ignite-users.70518.x6.nabble.com/Does-Ignite-support-nested-SQL-Queries-td1714.html
> {noformat}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteException: Failed to parse query: SELECT a.* FROM
> (SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id FROM
> "UserCache".user u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE WHEN
> og.goodid < 5 THEN 100 ELSE og.goodid END id FROM userorder ug,
> "OrderGoodCache".ordergood og WHERE ug.id = og.orderid) b WHERE a.id = b.id
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:636)
> at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:70)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: class org.apache.ignite.IgniteException: Failed to parse query:
> SELECT a.* FROM (SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id FROM
> "UserCache".user u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE WHEN
> og.goodid < 5 THEN 100 ELSE og.goodid END id FROM userorder ug,
> "OrderGoodCache".ordergood og WHERE ug.id = og.orderid) b WHERE a.id = b.id
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:641)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:627)
> ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to parse
> query: SELECT a.* FROM (SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END
> id FROM "UserCache".user u, userorder ug WHERE u.id = ug.usrid) a, (SELECT
> CASE WHEN og.goodid < 5 THEN 100 ELSE og.goodid END id FROM userorder ug,
> "OrderGoodCache".ordergood og WHERE ug.id = og.orderid) b WHERE a.id = b.id
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1510)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:634)
> ... 7 more
> Caused by: javax.cache.CacheException: Failed to parse query: SELECT a.* FROM
> (SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id FROM
> "UserCache".user u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE WHEN
> og.goodid < 5 THEN 100 ELSE og.goodid END id FROM userorder ug,
> "OrderGoodCache".ordergood og WHERE ug.id = og.orderid) b WHERE a.id = b.id
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:938)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:636)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:634)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1492)
> ... 8 more
> Caused by: org.h2.jdbc.JdbcSQLException: General error:
> "java.lang.NullPointerException" [5-175]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:332)
> at org.h2.message.DbException.get(DbException.java:161)
> at org.h2.message.DbException.convert(DbException.java:284)
> at org.h2.message.DbException.toSQLException(DbException.java:257)
> at org.h2.message.TraceObject.logAndConvert(TraceObject.java:368)
> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:270)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:935)
> ... 12 more
> Caused by: java.lang.NullPointerException
> at
[jira] [Commented] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode
[
https://issues.apache.org/jira/browse/IGNITE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712436#comment-14712436
]
Valentin Kulichenko commented on IGNITE-1250:
-
Andrey,
Here are my comments/questions:
* How will the driver be configured if both old URL with host:port and cfg path
in Properties are provided? Is it valid? Should we throw an exception in this
case?
* What is the purpose of {{JdbcConnectionValidationTask}}? I assume it makes
sense to use it only for local caches in case of {{nodeId}} is set. But it
checks all nodes which looks suspicious.
* {{JdbcResultSet.getTypedValue(String colLb, ClassT cls)}} uses {{indexOf}}
to find the field index. I don't like that we iterate each time we call
{{getXXX()}} method. Instead we can lazily create a corresponding hash map and
use it afterwards. Note that we can reuse it for all executions within one
prepared statement and in this case it can give improvement. What do you think?
* Removal delay in {{JdbcQueryTask}} should be customizable via system property.
* User should be able to provide all parameters of {{SqlFieldsQuery}}. Now
{{collocated}} and {{local}} are missing.
* When {{nodeId}} is provided, we should verify that it's a server node
(probably should be done in {{isValid()}} method).
* I don't like that we schedule cursor removal in case of client execution (no
{{nodeId}} is provided). Why don't we just remove the cursor on result set
closure?
* Need to make sure that when statement is closed, all result sets created by
this statement are closed too. Similarly, connection should close its
statements.
* The replacement of cursor on line 139 of {{JdbcQueryTask}} causes serious
issue: you try to take new iterator from {{QueryCursor}} which is wrong.
Moreover, it's not supported by {{QueryCursor}} and, as far as I understand,
you will get exception if there are more than two pages in result set. Please
add tests and fix properly.
* {{JdbcResultSet.next()}} iterates through fields to check types. But the same
is done in {{JdbcQueryTask}}, so it looks obsolete. Please check.
* {{UUID}} used to identify the cursor comes from the statement. So for
prepared statement it will be the same for different executions. Can it cause
issues?
* {{JdbcUtils.typeName()}} and {{JdbcUtils.type()}} methods miss
{{java.sql.Date}} type.
* I don't think we should convert user objects to strings. If user queries
objects (e.g., _VAL field), he will need to have classes anyway. So no reason
to convert them.
Migrate JDBC driver from Java client to Ignite node in client mode
--
Key: IGNITE-1250
URL: https://issues.apache.org/jira/browse/IGNITE-1250
Project: Ignite
Issue Type: Improvement
Reporter: Andrey Gura
Assignee: Valentin Kulichenko
Fix For: ignite-1.4
JDBC driver is still based on legacy Java client which is deprecated, not
supported and much slower than native query API.
Needs to replace thin client with an embedded client node.
See also:
http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-driver-td2177.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode
[ https://issues.apache.org/jira/browse/IGNITE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1250: Assignee: Andrey Gura (was: Valentin Kulichenko) Migrate JDBC driver from Java client to Ignite node in client mode -- Key: IGNITE-1250 URL: https://issues.apache.org/jira/browse/IGNITE-1250 Project: Ignite Issue Type: Improvement Reporter: Andrey Gura Assignee: Andrey Gura Fix For: ignite-1.4 JDBC driver is still based on legacy Java client which is deprecated, not supported and much slower than native query API. Needs to replace thin client with an embedded client node. See also: http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-driver-td2177.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-940) Need to expose SQL metadata to public API
[
https://issues.apache.org/jira/browse/IGNITE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-940:
---
Fix Version/s: ignite-1.4
Need to expose SQL metadata to public API
-
Key: IGNITE-940
URL: https://issues.apache.org/jira/browse/IGNITE-940
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: sprint-5
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
Labels: Usability, user-request
Fix For: ignite-1.4
This is the request from one of our users.
We already have {{GridCacheSqlMetadata}} and {{GridCacheSqlIndexMetadata}}
interfaces and {{GridCacheQueryManager.sqlMetadata()}} method.
Need to move interfaces to public package and add a new method on
{{IgniteCache}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-940) Need to expose SQL metadata to public API
[
https://issues.apache.org/jira/browse/IGNITE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko reassigned IGNITE-940:
--
Assignee: Valentin Kulichenko
Need to expose SQL metadata to public API
-
Key: IGNITE-940
URL: https://issues.apache.org/jira/browse/IGNITE-940
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: sprint-5
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
Labels: Usability, user-request
Fix For: ignite-1.4
This is the request from one of our users.
We already have {{GridCacheSqlMetadata}} and {{GridCacheSqlIndexMetadata}}
interfaces and {{GridCacheQueryManager.sqlMetadata()}} method.
Need to move interfaces to public package and add a new method on
{{IgniteCache}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1238) Joining node should be discarded in case discovery exchange data can't be deserialized
[
https://issues.apache.org/jira/browse/IGNITE-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14724382#comment-14724382
]
Valentin Kulichenko commented on IGNITE-1238:
-
Hi Raul,
I haven't started yet, so feel free to pick it up. Let me know if you need any
help.
> Joining node should be discarded in case discovery exchange data can't be
> deserialized
> --
>
> Key: IGNITE-1238
> URL: https://issues.apache.org/jira/browse/IGNITE-1238
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: ignite-1.4
>
>
> Currently a node will join even if unmarshalling fails (see
> {{TcpDiscoverySpi.onExchange()}} method, which can cause unexpected
> behaviour. For example, a continuous query listener is not deployed on some
> nodes in topology. Everything works, but some updates are lost. We should
> discard the node in this case and give a good error message to user with
> information on how to fix it properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1153) Improve stop node message
[ https://issues.apache.org/jira/browse/IGNITE-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14724843#comment-14724843 ] Valentin Kulichenko commented on IGNITE-1153: - Ken, See my comment on GitHub. > Improve stop node message > - > > Key: IGNITE-1153 > URL: https://issues.apache.org/jira/browse/IGNITE-1153 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: sprint-1 >Reporter: Alexey Kuznetsov >Assignee: kcheng.mvp >Priority: Trivial > Labels: newbie > Fix For: ignite-1.4 > > > When node stopped it prints to log: > [15:03:07] Ignite node stopped OK [uptime=00:00:52:597] > But in case when several nodes run in same JVM it will be useful to see node > name that was stopped. > So message could look like: > [15:03:07] Ignite node stopped OK [name=n1, uptime=00:00:52:597] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode
[ https://issues.apache.org/jira/browse/IGNITE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1250: Assignee: Andrey Gura (was: Valentin Kulichenko) > Migrate JDBC driver from Java client to Ignite node in client mode > -- > > Key: IGNITE-1250 > URL: https://issues.apache.org/jira/browse/IGNITE-1250 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Gura >Assignee: Andrey Gura > Fix For: ignite-1.4 > > > JDBC driver is still based on legacy Java client which is deprecated, not > supported and much slower than native query API. > Needs to replace thin client with an embedded client node. > See also: > http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-driver-td2177.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode
[ https://issues.apache.org/jira/browse/IGNITE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14724850#comment-14724850 ] Valentin Kulichenko commented on IGNITE-1250: - * If configuration path is ignored, warning should be printed out in log. * I think we should simplify and get rid of all tasks, at least in case of client execution (this is how the driver will be used in 99% cases). Move the code to separate methods and call it either from task (if needed) or directly from driver classes. * We don't need to fix old version - it's deprecated (BTW, this should be mentioned in docs). It just needs to work like it worked earlier for compatibility. All fixes go for the new version. I would fix everything in this ticket - there is nothing really complicated. * I will think about user objects. Let's fix the rest first. > Migrate JDBC driver from Java client to Ignite node in client mode > -- > > Key: IGNITE-1250 > URL: https://issues.apache.org/jira/browse/IGNITE-1250 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Gura >Assignee: Valentin Kulichenko > Fix For: ignite-1.4 > > > JDBC driver is still based on legacy Java client which is deprecated, not > supported and much slower than native query API. > Needs to replace thin client with an embedded client node. > See also: > http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-driver-td2177.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1238) Joining node should be discarded in case discovery exchange data can't be deserialized
[
https://issues.apache.org/jira/browse/IGNITE-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731442#comment-14731442
]
Valentin Kulichenko commented on IGNITE-1238:
-
Raul, you can use scenario described here to reproduce the issue:
https://issues.apache.org/jira/browse/IGNITE-1205. Just replace Visor with an
ordinary node started with {{ignite.sh}} (i.e., without additional classes on
classpath). This node will join topology, but it should not be able to do this.
> Joining node should be discarded in case discovery exchange data can't be
> deserialized
> --
>
> Key: IGNITE-1238
> URL: https://issues.apache.org/jira/browse/IGNITE-1238
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Raúl Kripalani
>Priority: Critical
> Fix For: ignite-1.4
>
>
> Currently a node will join even if unmarshalling fails (see
> {{TcpDiscoverySpi.onExchange()}} method, which can cause unexpected
> behaviour. For example, a continuous query listener is not deployed on some
> nodes in topology. Everything works, but some updates are lost. We should
> discard the node in this case and give a good error message to user with
> information on how to fix it properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1016) Add excludeNeighbors and backupFilter to FairAffinityFunction
[
https://issues.apache.org/jira/browse/IGNITE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1016:
Assignee: Andrey Gura (was: Valentin Kulichenko)
> Add excludeNeighbors and backupFilter to FairAffinityFunction
> -
>
> Key: IGNITE-1016
> URL: https://issues.apache.org/jira/browse/IGNITE-1016
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Andrey Gura
> Labels: Usability
> Fix For: ignite-1.4
>
> Attachments: ignite-1016.patch, ignite-1016.patch
>
>
> These properties are currently available only for
> {{RendezvousAffinityFunction}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1019) Resources are not injected on cache store factory
[
https://issues.apache.org/jira/browse/IGNITE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-1019.
---
> Resources are not injected on cache store factory
> -
>
> Key: IGNITE-1019
> URL: https://issues.apache.org/jira/browse/IGNITE-1019
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Labels: Usability
> Fix For: ignite-1.4
>
> Attachments: IGNITE-1019.patch
>
>
> Cache store factory may need to have access to some resources located in
> Spring app context or node local map. Currently this is not possible because
> {{@GridInstanceResource}}, {{@SpringApplicationContextResource}} and other
> annotations are not processed for factories, only for created objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-1047) Make warning text more informative
[
https://issues.apache.org/jira/browse/IGNITE-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko resolved IGNITE-1047.
-
Resolution: Fixed
Fixed in 1.4 and master.
> Make warning text more informative
> --
>
> Key: IGNITE-1047
> URL: https://issues.apache.org/jira/browse/IGNITE-1047
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: sprint-6
>Reporter: Pavel Konstantinov
>Assignee: Valentin Kulichenko
>Priority: Trivial
> Fix For: ignite-1.4
>
>
> {code}
> [11:05:17,023][WARNING][ignite-#8%pub-tester%][MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,032][WARNING][ignite-#9%pub-tester%][MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,037][WARNING][ignite-#9%pub-tester%][MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,043][WARNING][ignite-#10%pub-tester%]MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,047][WARNING][ignite-#10%pub-tester%]MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,058][WARNING][ignite-#11%pub-tester%]MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,064][WARNING][ignite-#11%pub-tester%]MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> {code}
> And may be also we need throttling here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1047) Make warning text more informative
[
https://issues.apache.org/jira/browse/IGNITE-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-1047.
---
> Make warning text more informative
> --
>
> Key: IGNITE-1047
> URL: https://issues.apache.org/jira/browse/IGNITE-1047
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: sprint-6
>Reporter: Pavel Konstantinov
>Assignee: Valentin Kulichenko
>Priority: Trivial
> Fix For: ignite-1.4
>
>
> {code}
> [11:05:17,023][WARNING][ignite-#8%pub-tester%][MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,032][WARNING][ignite-#9%pub-tester%][MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,037][WARNING][ignite-#9%pub-tester%][MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,043][WARNING][ignite-#10%pub-tester%]MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,047][WARNING][ignite-#10%pub-tester%]MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,058][WARNING][ignite-#11%pub-tester%]MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> [11:05:17,064][WARNING][ignite-#11%pub-tester%]MarshallerContextImpl] class
> o.a.i.i.processors.cache.GridCacheTryPutFailedException: null
> {code}
> And may be also we need throttling here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1370) StreamTupleExtractor should allow extracting multiple tuples from a single event
[
https://issues.apache.org/jira/browse/IGNITE-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731640#comment-14731640
]
Valentin Kulichenko commented on IGNITE-1370:
-
Raul,
I looked at your changes. They look good, but I think we should throw an
exception if both single and multiple extractors are set, because only multiple
will be used.
Also it looks like multiple extractor supports all cases, so single can be
deprecated. What do you think?
> StreamTupleExtractor should allow extracting multiple tuples from a single
> event
>
>
> Key: IGNITE-1370
> URL: https://issues.apache.org/jira/browse/IGNITE-1370
> Project: Ignite
> Issue Type: Improvement
> Components: streaming
>Affects Versions: ignite-1.4
>Reporter: Raúl Kripalani
>Assignee: Raúl Kripalani
>
> Currently the {{StreamTupleExtractor}} interface contains a single method:
> {code}
> public Map.Entry extract(T msg);
> {code}
> Which only allows extracting a single Entry from an incoming event.
> In real life, it could be that an event contains multiple entries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1378) Continuous processor doesn't remove message listener if continuous query failed to start
Valentin Kulichenko created IGNITE-1378:
---
Summary: Continuous processor doesn't remove message listener if
continuous query failed to start
Key: IGNITE-1378
URL: https://issues.apache.org/jira/browse/IGNITE-1378
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
Fix For: ignite-1.4
{{GridContinuousProcessor.startRoutine(..)}} method adds message listener on
line 538 and never removes it if handler registration fails (e.g., due to
marshalling issues). Need to fix exception handling in this method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-884) Cache store usability issues
[
https://issues.apache.org/jira/browse/IGNITE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-884:
---
Fix Version/s: (was: ignite-1.4)
ignite-1.5
> Cache store usability issues
>
>
> Key: IGNITE-884
> URL: https://issues.apache.org/jira/browse/IGNITE-884
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: ignite-1.5
>
>
> * Need to validate read/write-through configuration. Currently, when cache
> store is configured, but {{readThrough}} and {{writeThrough}} flags on
> {{CacheConfiguration}} are switched off, the store will never be called,
> which is confusing. This case should be validated and proper warning should
> be printed out on startup (we can't throw an exception here because in some
> cases store implements only {{loadCache}} method and is not used for
> read/write-through).
> * Since cache store is instantiated by Ignite via factory, but not by Spring,
> user can't use Spring auto-wiring which is very common in Spring apps. Need
> to create utility method which will instantiate an instance with a factory
> and properly initialize it. All factory calls (store, expiry policy, ...)
> should be replaced with this utility method.
> To manually enable autowiring this code can be used:
> {code}
> appCtx.getAutowireCapableBeanFactory().autowireBean(obj);
> {code}
> ({{appCtx}} is Spring's {{ApplicationContext}})
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-940) Need to expose SQL metadata to public API
[
https://issues.apache.org/jira/browse/IGNITE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-940:
---
Fix Version/s: (was: ignite-1.4)
ignite-1.5
> Need to expose SQL metadata to public API
> -
>
> Key: IGNITE-940
> URL: https://issues.apache.org/jira/browse/IGNITE-940
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: sprint-5
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: Usability, user-request
> Fix For: ignite-1.5
>
>
> This is the request from one of our users.
> We already have {{GridCacheSqlMetadata}} and {{GridCacheSqlIndexMetadata}}
> interfaces and {{GridCacheQueryManager.sqlMetadata()}} method.
> Need to move interfaces to public package and add a new method on
> {{IgniteCache}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-995) Nodes on one host doesn't discover each other if IP finder doesn't explicitly provide port
[ https://issues.apache.org/jira/browse/IGNITE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-995: --- Fix Version/s: (was: ignite-1.4) ignite-1.5 > Nodes on one host doesn't discover each other if IP finder doesn't explicitly > provide port > -- > > Key: IGNITE-995 > URL: https://issues.apache.org/jira/browse/IGNITE-995 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: sprint-4 >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko > Labels: Usability > Fix For: ignite-1.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1016) Add excludeNeighbors and backupFilter to FairAffinityFunction
[
https://issues.apache.org/jira/browse/IGNITE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1016:
Assignee: Andrey Gura (was: Valentin Kulichenko)
> Add excludeNeighbors and backupFilter to FairAffinityFunction
> -
>
> Key: IGNITE-1016
> URL: https://issues.apache.org/jira/browse/IGNITE-1016
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Andrey Gura
> Labels: Usability
> Fix For: ignite-1.4
>
> Attachments: ignite-1016.patch, ignite-1016.patch
>
>
> These properties are currently available only for
> {{RendezvousAffinityFunction}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1404) Any distributed cache operation should throw CacheServerNotFoundException if there are no server nodes
Valentin Kulichenko created IGNITE-1404:
---
Summary: Any distributed cache operation should throw
CacheServerNotFoundException if there are no server nodes
Key: IGNITE-1404
URL: https://issues.apache.org/jira/browse/IGNITE-1404
Project: Ignite
Issue Type: Improvement
Components: cache
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
Fix For: ignite-1.4
Currently the behavior is inconsistent. E.g., {{remove()}} method throws an
exception, but {{clear()}} does not. Need to check all distributed operations
and make them throw the exception when appropriate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode
[ https://issues.apache.org/jira/browse/IGNITE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1250: Priority: Blocker (was: Major) > Migrate JDBC driver from Java client to Ignite node in client mode > -- > > Key: IGNITE-1250 > URL: https://issues.apache.org/jira/browse/IGNITE-1250 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Gura >Assignee: Valentin Kulichenko >Priority: Blocker > Fix For: ignite-1.4 > > > JDBC driver is still based on legacy Java client which is deprecated, not > supported and much slower than native query API. > Needs to replace thin client with an embedded client node. > See also: > http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-driver-td2177.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1402) Logging uses root logger in some cases
Valentin Kulichenko created IGNITE-1402:
---
Summary: Logging uses root logger in some cases
Key: IGNITE-1402
URL: https://issues.apache.org/jira/browse/IGNITE-1402
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
Fix For: ignite-1.4
{{GridKernalContext.log()}} method returns root logger which should not be used
by any of Ignite classes. This can cause the following scenario:
# User configures logger with DEBUG level as default and INFO level for
{{org.apache.ignite}} package.
# Ignite class takes logger using {{GridKernalContext.log()}} and checks if
debug is enabled. It will get true regardless of the settings for Ignite
package.
There are places in code that uses {{GridKernalContext.log()}} method
incorrectly, so it should be removed. We should always use
{{GridKernalContext.log(Class cls)}} properly specifying the category.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-1402) Logging uses root logger in some cases
[
https://issues.apache.org/jira/browse/IGNITE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko resolved IGNITE-1402.
-
Resolution: Fixed
Fixed in ignite-1.4
> Logging uses root logger in some cases
> --
>
> Key: IGNITE-1402
> URL: https://issues.apache.org/jira/browse/IGNITE-1402
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: user-request
> Fix For: ignite-1.4
>
>
> {{GridKernalContext.log()}} method returns root logger which should not be
> used by any of Ignite classes. This can cause the following scenario:
> # User configures logger with DEBUG level as default and INFO level for
> {{org.apache.ignite}} package.
> # Ignite class takes logger using {{GridKernalContext.log()}} and checks if
> debug is enabled. It will get true regardless of the settings for Ignite
> package.
> There are places in code that uses {{GridKernalContext.log()}} method
> incorrectly, so it should be removed. We should always use
> {{GridKernalContext.log(Class cls)}} properly specifying the category.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1402) Logging uses root logger in some cases
[
https://issues.apache.org/jira/browse/IGNITE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-1402.
---
> Logging uses root logger in some cases
> --
>
> Key: IGNITE-1402
> URL: https://issues.apache.org/jira/browse/IGNITE-1402
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: user-request
> Fix For: ignite-1.4
>
>
> {{GridKernalContext.log()}} method returns root logger which should not be
> used by any of Ignite classes. This can cause the following scenario:
> # User configures logger with DEBUG level as default and INFO level for
> {{org.apache.ignite}} package.
> # Ignite class takes logger using {{GridKernalContext.log()}} and checks if
> debug is enabled. It will get true regardless of the settings for Ignite
> package.
> There are places in code that uses {{GridKernalContext.log()}} method
> incorrectly, so it should be removed. We should always use
> {{GridKernalContext.log(Class cls)}} properly specifying the category.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode
[ https://issues.apache.org/jira/browse/IGNITE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-1250. --- > Migrate JDBC driver from Java client to Ignite node in client mode > -- > > Key: IGNITE-1250 > URL: https://issues.apache.org/jira/browse/IGNITE-1250 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Gura >Assignee: Valentin Kulichenko >Priority: Blocker > Fix For: ignite-1.4 > > > JDBC driver is still based on legacy Java client which is deprecated, not > supported and much slower than native query API. > Needs to replace thin client with an embedded client node. > See also: > http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-driver-td2177.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1378) Continuous processor doesn't remove message listener if continuous query failed to start
[
https://issues.apache.org/jira/browse/IGNITE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko resolved IGNITE-1378.
-
Resolution: Fixed
Fixed in ignite-1.4
> Continuous processor doesn't remove message listener if continuous query
> failed to start
>
>
> Key: IGNITE-1378
> URL: https://issues.apache.org/jira/browse/IGNITE-1378
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Fix For: ignite-1.4
>
>
> {{GridContinuousProcessor.startRoutine(..)}} method adds message listener on
> line 538 and never removes it if handler registration fails (e.g., due to
> marshalling issues). Need to fix exception handling in this method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-967) Internal thread locals are not always cleaned
[
https://issues.apache.org/jira/browse/IGNITE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-967:
---
Fix Version/s: ignite-1.5
> Internal thread locals are not always cleaned
> -
>
> Key: IGNITE-967
> URL: https://issues.apache.org/jira/browse/IGNITE-967
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: ignite-1.5
>
>
> One of our users reported that he sees warnings in Tomcat's log when the
> application that's running Ignite in embedded mode is undeployed:
> {code}
> SEVERE: The web application [/XXX] created a ThreadLocal with key of type
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1] (value
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a
> value of type [java.lang.Integer] (value [0]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> {code}
> There is also the similar warning for {{GridToStringBuilder.threadCache}}.
> While it's usually OK not to clean thread locals on standalone node, in app
> server it can cause a memory leak.
> To avoid such issues I suggest to add a special step after all test suites
> that will check thread locals in test runner thread. If we have this check in
> CI, we will fix it once and for always.
> Thread local values can be introspected through {{Thread.threadLocals}}
> variable. It would also be a good idea to check Tomcat's sources on how it's
> done there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-967) Internal thread locals are not always cleaned
[
https://issues.apache.org/jira/browse/IGNITE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko reassigned IGNITE-967:
--
Assignee: Valentin Kulichenko
> Internal thread locals are not always cleaned
> -
>
> Key: IGNITE-967
> URL: https://issues.apache.org/jira/browse/IGNITE-967
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: ignite-1.5
>
>
> One of our users reported that he sees warnings in Tomcat's log when the
> application that's running Ignite in embedded mode is undeployed:
> {code}
> SEVERE: The web application [/XXX] created a ThreadLocal with key of type
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1] (value
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a
> value of type [java.lang.Integer] (value [0]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> {code}
> There is also the similar warning for {{GridToStringBuilder.threadCache}}.
> While it's usually OK not to clean thread locals on standalone node, in app
> server it can cause a memory leak.
> To avoid such issues I suggest to add a special step after all test suites
> that will check thread locals in test runner thread. If we have this check in
> CI, we will fix it once and for always.
> Thread local values can be introspected through {{Thread.threadLocals}}
> variable. It would also be a good idea to check Tomcat's sources on how it's
> done there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1016) Add excludeNeighbors and backupFilter to FairAffinityFunction
[
https://issues.apache.org/jira/browse/IGNITE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14738193#comment-14738193
]
Valentin Kulichenko commented on IGNITE-1016:
-
Alexey,
I believe you're better person to review this. Can you take a look?
> Add excludeNeighbors and backupFilter to FairAffinityFunction
> -
>
> Key: IGNITE-1016
> URL: https://issues.apache.org/jira/browse/IGNITE-1016
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Alexey Goncharuk
> Labels: Usability
> Fix For: ignite-1.4
>
> Attachments: ignite-1016.patch, ignite-1016.patch
>
>
> These properties are currently available only for
> {{RendezvousAffinityFunction}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-967) Internal thread locals are not always cleaned
[
https://issues.apache.org/jira/browse/IGNITE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-967:
---
Priority: Blocker (was: Major)
> Internal thread locals are not always cleaned
> -
>
> Key: IGNITE-967
> URL: https://issues.apache.org/jira/browse/IGNITE-967
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Fix For: ignite-1.5
>
>
> One of our users reported that he sees warnings in Tomcat's log when the
> application that's running Ignite in embedded mode is undeployed:
> {code}
> SEVERE: The web application [/XXX] created a ThreadLocal with key of type
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1] (value
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a
> value of type [java.lang.Integer] (value [0]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> {code}
> There is also the similar warning for {{GridToStringBuilder.threadCache}}.
> While it's usually OK not to clean thread locals on standalone node, in app
> server it can cause a memory leak.
> To avoid such issues I suggest to add a special step after all test suites
> that will check thread locals in test runner thread. If we have this check in
> CI, we will fix it once and for always.
> Thread local values can be introspected through {{Thread.threadLocals}}
> variable. It would also be a good idea to check Tomcat's sources on how it's
> done there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1523) Need to always serialize user objects with configured marshaller
[
https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1523:
Summary: Need to always serialize user objects with configured marshaller
(was: Need to make marshaller in discovery pluggable)
> Need to always serialize user objects with configured marshaller
>
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: user-request
> Fix For: ignite-1.5
>
>
> Currently we always use {{JdkMarshaller}}. It can be useful to use a custom
> one. Need to add {{TcpDiscoverySpi.setMarshaller()}} method to allow this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-940) Need to expose SQL metadata to public API
[
https://issues.apache.org/jira/browse/IGNITE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-940:
---
Priority: Minor (was: Trivial)
> Need to expose SQL metadata to public API
> -
>
> Key: IGNITE-940
> URL: https://issues.apache.org/jira/browse/IGNITE-940
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: sprint-5
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Minor
> Labels: Usability, user-request
> Fix For: ignite-1.5
>
>
> This is the request from one of our users.
> We already have {{GridCacheSqlMetadata}} and {{GridCacheSqlIndexMetadata}}
> interfaces and {{GridCacheQueryManager.sqlMetadata()}} method.
> Need to move interfaces to public package and add a new method on
> {{IgniteCache}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-995) Nodes on one host doesn't discover each other if IP finder doesn't explicitly provide port
[ https://issues.apache.org/jira/browse/IGNITE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-995: --- Priority: Trivial (was: Major) > Nodes on one host doesn't discover each other if IP finder doesn't explicitly > provide port > -- > > Key: IGNITE-995 > URL: https://issues.apache.org/jira/browse/IGNITE-995 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: sprint-4 >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Trivial > Labels: Usability > Fix For: ignite-1.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1523) Need to always serialize user objects with configured marshaller
[
https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1523:
Description: Currently some components (at least discovery) use
{{JdkMarshaller}} for all objects. (was: Currently we always use
{{JdkMarshaller}}. It can be useful to use a custom one. Need to add
{{TcpDiscoverySpi.setMarshaller()}} method to allow this.)
> Need to always serialize user objects with configured marshaller
>
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: user-request
> Fix For: ignite-1.5
>
>
> Currently some components (at least discovery) use {{JdkMarshaller}} for all
> objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1559) Need to improve tests, javadoc and documentation of UriDeploymentHttpScanner.
[ https://issues.apache.org/jira/browse/IGNITE-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936070#comment-14936070 ] Valentin Kulichenko commented on IGNITE-1559: - Artem, I moved the article here: https://apacheignite.readme.io/docs/deployment-spi. I also made several fixes there. Can you please go through it and fix javadoc accordingly? I will merge after that. > Need to improve tests, javadoc and documentation of UriDeploymentHttpScanner. > - > > Key: IGNITE-1559 > URL: https://issues.apache.org/jira/browse/IGNITE-1559 > Project: Ignite > Issue Type: Task >Reporter: Artem Shutak >Assignee: Valentin Kulichenko > Fix For: ignite-1.5 > > > Need to improve tests, javadoc and documentation of UriDeploymentHttpScanner. > It's not possible to understand from current javadoc of > UriDeploymentHttpScanner how it works. > There's only one simple test in GridHttpDeploymentSelfTest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1272) PortableMarshaller: issues when different class loaders are used
[
https://issues.apache.org/jira/browse/IGNITE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1272:
Assignee: Denis Magda (was: Valentin Kulichenko)
> PortableMarshaller: issues when different class loaders are used
>
>
> Key: IGNITE-1272
> URL: https://issues.apache.org/jira/browse/IGNITE-1272
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: ignite-1.5
>
> Attachments: ignite-1272.patch
>
>
> The reason is that a loader is not passed to required places when needed.
> Reproduced with the following tests:
> - {{IgniteCacheAbstractExecutionContextTest.testUserClassLoader()}} fails
> with PortableMarshaller enabled.
> - {{GridDeploymentMessageCountSelfTest.testCacheValueDeploymentOnPut()}}
> Another issue is when {{PortableContext}} returns {{PortableClassDescriptor}}
> by type id. Returned descriptor has a constructor which already has been
> loaded with another class loader. Fix is not trivial and issue is reproduced
> with {{GridP2PRemoteClassLoadersSelfTest}}
> Look for corresponding TODOs in the code.
> Unmute tests when fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1272) PortableMarshaller: issues when different class loaders are used
[
https://issues.apache.org/jira/browse/IGNITE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936153#comment-14936153
]
Valentin Kulichenko commented on IGNITE-1272:
-
Denis,
I'm not sure I understood the purpose of {{descriptorLoadingFailover(...)}}
method. Can you please provide details? Also why you get the descriptor from
the {{userTypes}} map, but return it only if was loaded by default loader? Why
do we need it in this map then?
Thanks!
> PortableMarshaller: issues when different class loaders are used
>
>
> Key: IGNITE-1272
> URL: https://issues.apache.org/jira/browse/IGNITE-1272
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Fix For: ignite-1.5
>
> Attachments: ignite-1272.patch
>
>
> The reason is that a loader is not passed to required places when needed.
> Reproduced with the following tests:
> - {{IgniteCacheAbstractExecutionContextTest.testUserClassLoader()}} fails
> with PortableMarshaller enabled.
> - {{GridDeploymentMessageCountSelfTest.testCacheValueDeploymentOnPut()}}
> Another issue is when {{PortableContext}} returns {{PortableClassDescriptor}}
> by type id. Returned descriptor has a constructor which already has been
> loaded with another class loader. Fix is not trivial and issue is reproduced
> with {{GridP2PRemoteClassLoadersSelfTest}}
> Look for corresponding TODOs in the code.
> Unmute tests when fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1574) Exception is not rethrown if entry processor fails during commit
Valentin Kulichenko created IGNITE-1574: --- Summary: Exception is not rethrown if entry processor fails during commit Key: IGNITE-1574 URL: https://issues.apache.org/jira/browse/IGNITE-1574 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Fix For: ignite-1.5 See user@ thread: http://apache-ignite-users.70518.x6.nabble.com/CacheEntryProcessor-failing-on-transactional-cache-td1501.html Entry processor fails during commit, transaction is correctly rolled back, but the exception is not rethrown to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1575) NPE when cache is started concurrently with the node stop
Valentin Kulichenko created IGNITE-1575:
---
Summary: NPE when cache is started concurrently with the node stop
Key: IGNITE-1575
URL: https://issues.apache.org/jira/browse/IGNITE-1575
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Valentin Kulichenko
Priority: Minor
Fix For: ignite-1.5
It's not causing any harm, but it's possible to get the NPE below during the
node stop.
{noformat}
57724 [main] ERROR IgniteKernal%t1-1 - Got exception while starting (will
rollback startup routine).
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onKernalStart0(CacheContinuousQueryManager.java:91)
at
org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.onKernalStart(GridCacheManagerAdapter.java:97)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:1058)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:833)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:829)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1549)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1416)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:916)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
at org.apache.ignite.Ignition.start(Ignition.java:321)
.. application stack frames ...
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1575) NPE when cache is started concurrently with the node stop
[
https://issues.apache.org/jira/browse/IGNITE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1575:
Labels: usability (was: )
> NPE when cache is started concurrently with the node stop
> -
>
> Key: IGNITE-1575
> URL: https://issues.apache.org/jira/browse/IGNITE-1575
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Priority: Minor
> Labels: usability
> Fix For: ignite-1.5
>
>
> It's not causing any harm, but it's possible to get the NPE below during the
> node stop.
> {noformat}
> 57724 [main] ERROR IgniteKernal%t1-1 - Got exception while starting (will
> rollback startup routine).
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onKernalStart0(CacheContinuousQueryManager.java:91)
> at
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.onKernalStart(GridCacheManagerAdapter.java:97)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:1058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:833)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:829)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1549)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1416)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:916)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> .. application stack frames ...
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1246) Exception in thread "main" javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: Failed to validate cache configuration. Cache store factory is not
[
https://issues.apache.org/jira/browse/IGNITE-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1246:
Assignee: kcheng.mvp (was: Valentin Kulichenko)
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to validate cache
> configuration. Cache store factory is not serializable. Cache name: XXX
> ---
>
> Key: IGNITE-1246
> URL: https://issues.apache.org/jira/browse/IGNITE-1246
> Project: Ignite
> Issue Type: Bug
>Reporter: kcheng.mvp
>Assignee: kcheng.mvp
> Labels: user-request
> Attachments: ignite-01.png, ignite-02.png
>
>
> Here is my configuration
> {code:xml}
>
> class="org.springframework.jdbc.datasource.DriverManagerDataSource">
>value="oracle.jdbc.driver.OracleDriver" />
> value="jdbc:oracle:thin:@//192.168.2.39:1521/db" />
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration" scope="prototype">
>
>
>
>
>
>
>class="javax.cache.configuration.FactoryBuilder$SingletonFactory">
>
>class="org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStore">
>ref="dataSource"/>
>
>
>
>
>
> {code}
> When I try to load data to the cache I got the exception.
> here is he stack from client node
> {code}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to validate cache
> configuration. Cache store factory is not serializable. Cache name:
> T_HTLPRO_PRICEPLAN
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1581)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2311)
> at
> org.apache.ignite.IgniteSpringBean.getOrCreateCache(IgniteSpringBean.java:246)
> at com.fangcang.cache.client.Grid.getCacheByCfg(Grid.java:30)
> at com.fangcang.cache.client.InitLoader.main(InitLoader.java:16)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to validate
> cache configuration. Cache store factory is not serializable. Cache name:
> T_HTLPRO_PRICEPLAN
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.checkSerializable(GridCacheProcessor.java:3038)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:1958)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:1927)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2306)
> ... 3 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> serialize object:
> javax.cache.configuration.FactoryBuilder$SingletonFactory@55dfebeb
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal(JdkMarshaller.java:78)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.marshal(AbstractMarshaller.java:51)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.checkSerializable(GridCacheProcessor.java:3034)
> ... 6 more
> Caused by: java.io.NotSerializableException:
> org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStore
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal(JdkMarshaller.java:73)
> ... 8 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1122) Cache put hangs if key hashCode is implemented incorrectly
[
https://issues.apache.org/jira/browse/IGNITE-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1122:
Priority: Blocker (was: Major)
> Cache put hangs if key hashCode is implemented incorrectly
> --
>
> Key: IGNITE-1122
> URL: https://issues.apache.org/jira/browse/IGNITE-1122
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: Usability
> Fix For: ignite-1.5
>
>
> If key {{hashCode()}} returns inconsistent result (e.g., user used
> {{Enum.hashCode()}} in his implementation), the exception below is thrown on
> a server node and put operation hangs.
> {code}
> SEVERE: Future execution resulted in error: GridEmbeddedFuture
> [embedded=GridFinishedFuture [resFlag=2, startTime=1436797251202]]
> class org.apache.ignite.IgniteCheckedException: Creating partition which does
> not belong [part=118, topVer=AffinityTopologyVersion [topVer=5,
> minorTopVer=4], this.topVer=AffinityTopologyVersion [topVer=5, minorTopVer=4]]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6753)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:124)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:851)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:848)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:241)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:204)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:525)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$000(GridDhtTransactionalCacheAdapter.java:52)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:96)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:94)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:532)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:240)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:158)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:48)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:690)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:58)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:653)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
> [part=118, msg=Creating partition which does not belong [part=118,
> topVer=AffinityTopologyVersion [topVer=5, minorTopVer=4],
> this.topVer=AffinityTopologyVersion [topVer=5, minorTopVer=4]]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:527)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:496)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.onAdded(GridDhtPartitionTopologyImpl.java:580)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.(GridDhtCacheEntry.java:79)
> at
>
[jira] [Commented] (IGNITE-1526) IBM JDK is not fully supported by the platfrom
[
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909374#comment-14909374
]
Valentin Kulichenko commented on IGNITE-1526:
-
Denis,
Are you saying that setting {{serialVersionUID}} for all serializable classes
will fix the issue? If so, this is definitely *much* easier than switching to
portable marshaller everywhere. And it's always a good idea to get rid of
anonymous serializable classes anyway :)
Our {{ClassesGenerator}} class that generates {{classnames.properties}} file
checks each serializable class for {{serialVersionUID}}, but now it skips
anonymous classes (see {{!cls.getSimpleName().isEmpty()}} on line 213).
Removing this {{if}} will show the list of classes that need to be reworked.
> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Andrey Gura
>Priority: Blocker
> Fix For: ignite-1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some
> functionality still doesn't work. As an example
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi]
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
> at
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
> at
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
> at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(ServerImpl.java:3258)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essMessage(ServerImpl.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.b
> ody(ServerImpl.java:5206)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
>
[jira] [Created] (IGNITE-1532) IgniteCache.put() should load value from store if interceptor is used and CacheConfiguration.isLoadPreviousValue() == true
Valentin Kulichenko created IGNITE-1532: --- Summary: IgniteCache.put() should load value from store if interceptor is used and CacheConfiguration.isLoadPreviousValue() == true Key: IGNITE-1532 URL: https://issues.apache.org/jira/browse/IGNITE-1532 Project: Ignite Issue Type: Bug Reporter: Valentin Kulichenko Priority: Critical Fix For: ignite-1.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1522) Cache entry listener is executed on a joining node
[ https://issues.apache.org/jira/browse/IGNITE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko resolved IGNITE-1522. - Resolution: Fixed Fixed in 1.4 > Cache entry listener is executed on a joining node > -- > > Key: IGNITE-1522 > URL: https://issues.apache.org/jira/browse/IGNITE-1522 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Blocker > Fix For: ignite-1.4 > > > Scenario is the following: > # Start first node. > # Register cache entry listener. Its configuration is added to cache > configuration (required by JCache). > # Start second node. > # As a result entry listener configuration is serialized as a part of cache > configuration, which is wrong. Moreover, it's executed on this new node. > Need to make listener configurations transient. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1522) Cache entry listener is executed on a joining node
[ https://issues.apache.org/jira/browse/IGNITE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-1522. --- > Cache entry listener is executed on a joining node > -- > > Key: IGNITE-1522 > URL: https://issues.apache.org/jira/browse/IGNITE-1522 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Blocker > Fix For: ignite-1.4 > > > Scenario is the following: > # Start first node. > # Register cache entry listener. Its configuration is added to cache > configuration (required by JCache). > # Start second node. > # As a result entry listener configuration is serialized as a part of cache > configuration, which is wrong. Moreover, it's executed on this new node. > Need to make listener configurations transient. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1523) Need to make marshaller in discovery pluggable
[
https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1523:
Fix Version/s: (was: ignite-1.4)
ignite-1.5
> Need to make marshaller in discovery pluggable
> --
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: user-request
> Fix For: ignite-1.5
>
>
> Currently we always use {{JdkMarshaller}}. It can be useful to use a custom
> one. Need to add {{TcpDiscoverySpi.setMarshaller()}} method to allow this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1542) MetaDataEnabled flag is partially ignored when set in PortableTypeConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907409#comment-14907409
]
Valentin Kulichenko commented on IGNITE-1542:
-
Denis,
We can't do this. We now save metadata for any registered classes because it
can potentially contain affinity key field name. Otherwise collocation can be
broken if metadata is disabled. But fields info is still not collected in this
case, there are tests for this: {{GridPortableMetaDataDisabledSelfTest}}.
> MetaDataEnabled flag is partially ignored when set in
> PortableTypeConfiguration
> ---
>
> Key: IGNITE-1542
> URL: https://issues.apache.org/jira/browse/IGNITE-1542
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Fix For: ignite-1.5
>
>
> Define a type using {{PortableTypeConfiguration}} and disable meta data for
> the type by setting {{metaDataEnabled}} flag to false.
> Then set this portable type configuration in {{PortableMarshaller's}}
> configuration list and start a node.
> Despite of the fact that the metadata is disable for the type it will be
> added to the metadata handler.
> The fix is trivial.
> Change last line of {{PortableContext.registerUserType()}} to:
> {noformat}
> if (metadataenabled)
> metaHnd.addMeta(id, new PortableMetaDataImpl(typeName, fieldsMeta,
> affKeyFieldName));
> {noformat}
> Add tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1552) Table function doesn't work properly in SQL query
Valentin Kulichenko created IGNITE-1552: --- Summary: Table function doesn't work properly in SQL query Key: IGNITE-1552 URL: https://issues.apache.org/jira/browse/IGNITE-1552 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Assignee: Sergi Vladykin Priority: Critical Fix For: ignite-1.5 IN operator replacement query described in [1] doesn't seem to work properly. Test reproducing the issue is attached. [1]https://apacheignite.readme.io/docs/sql-queries#performance-and-usability-considerations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1552) Table function doesn't work properly in SQL query
[ https://issues.apache.org/jira/browse/IGNITE-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1552: Attachment: QueryInStatementTest.java > Table function doesn't work properly in SQL query > - > > Key: IGNITE-1552 > URL: https://issues.apache.org/jira/browse/IGNITE-1552 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Sergi Vladykin >Priority: Critical > Labels: user-request > Fix For: ignite-1.5 > > Attachments: QueryInStatementTest.java > > > IN operator replacement query described in [1] doesn't seem to work properly. > Test reproducing the issue is attached. > [1] > https://apacheignite.readme.io/docs/sql-queries#performance-and-usability-considerations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1552) Table function doesn't work properly in SQL query
[ https://issues.apache.org/jira/browse/IGNITE-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1552: Description: IN operator replacement query described in [1] doesn't seem to work properly. Test reproducing the issue is attached. [1] https://apacheignite.readme.io/docs/sql-queries#performance-and-usability-considerations was: IN operator replacement query described in [1] doesn't seem to work properly. Test reproducing the issue is attached. [1]https://apacheignite.readme.io/docs/sql-queries#performance-and-usability-considerations > Table function doesn't work properly in SQL query > - > > Key: IGNITE-1552 > URL: https://issues.apache.org/jira/browse/IGNITE-1552 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Sergi Vladykin >Priority: Critical > Labels: user-request > Fix For: ignite-1.5 > > > IN operator replacement query described in [1] doesn't seem to work properly. > Test reproducing the issue is attached. > [1] > https://apacheignite.readme.io/docs/sql-queries#performance-and-usability-considerations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1522) Cache entry listener is executed on a joining node
Valentin Kulichenko created IGNITE-1522: --- Summary: Cache entry listener is executed on a joining node Key: IGNITE-1522 URL: https://issues.apache.org/jira/browse/IGNITE-1522 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko Priority: Blocker Fix For: ignite-1.4 Scenario is the following: # Start first node. # Register cache entry listener. Its configuration is added to cache configuration (required by JCache). # Start second node. # As a result entry listener configuration is serialized as a part of cache configuration, which is wrong. Moreover, it's executed on this new node. Need to make listener configurations transient. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1523) Need to make marshaller in discovery pluggable
Valentin Kulichenko created IGNITE-1523:
---
Summary: Need to make marshaller in discovery pluggable
Key: IGNITE-1523
URL: https://issues.apache.org/jira/browse/IGNITE-1523
Project: Ignite
Issue Type: Improvement
Components: general
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
Fix For: ignite-1.4
Currently we always use {{JdkMarshaller}}. It can be useful to use a custom
one. Need to add {{TcpDiscoverySpi.setMarshaller()}} method to allow this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1536) Duplicate notification in continuous query
Valentin Kulichenko created IGNITE-1536:
---
Summary: Duplicate notification in continuous query
Key: IGNITE-1536
URL: https://issues.apache.org/jira/browse/IGNITE-1536
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
Fix For: ignite-1.4
Scenario is the following:
# Start first node with a {{REPLICATED}} cache.
# Execute non-local continuous query.
# Start second node.
# Do several puts for different keys.
Some of the notifications are duplicated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1536) Duplicate notification in continuous query
[
https://issues.apache.org/jira/browse/IGNITE-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1536:
Labels: user-request (was: )
> Duplicate notification in continuous query
> --
>
> Key: IGNITE-1536
> URL: https://issues.apache.org/jira/browse/IGNITE-1536
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: user-request
> Fix For: ignite-1.4
>
>
> Scenario is the following:
> # Start first node with a {{REPLICATED}} cache.
> # Execute non-local continuous query.
> # Start second node.
> # Do several puts for different keys.
> Some of the notifications are duplicated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1538) Query performance is 2 times slower in OFFHEAP_TIERED mode
[ https://issues.apache.org/jira/browse/IGNITE-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1538: Labels: performance user-request (was: user-request) > Query performance is 2 times slower in OFFHEAP_TIERED mode > -- > > Key: IGNITE-1538 > URL: https://issues.apache.org/jira/browse/IGNITE-1538 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Critical > Labels: performance, user-request > Fix For: ignite-1.5 > > > Corresponding user@ thread: > http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-td1352.html > Need to run benchmarks and investigate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2098) Need to check that Java Proxy is properly (de)serialized with binary marshaller
Valentin Kulichenko created IGNITE-2098:
---
Summary: Need to check that Java Proxy is properly (de)serialized
with binary marshaller
Key: IGNITE-2098
URL: https://issues.apache.org/jira/browse/IGNITE-2098
Project: Ignite
Issue Type: Test
Components: general
Reporter: Valentin Kulichenko
Fix For: 1.5
Need to create test similar to {{OptimizedMarshallerTest.testProxy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2100) Queries do not work with binary marshaller and Externalizable objects
Valentin Kulichenko created IGNITE-2100:
---
Summary: Queries do not work with binary marshaller and
Externalizable objects
Key: IGNITE-2100
URL: https://issues.apache.org/jira/browse/IGNITE-2100
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 1.5
If new binary marshaller is used and model classes implement {{Externalizable}}
(which is often the case when user migrates from 1.4 to 1.5), queries stop
working and return nulls instead of all field values.
At least, we need to properly document it and throw an exception so that user
is aware about the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2099) Binary marshaller writes any map as a HashMap
Valentin Kulichenko created IGNITE-2099: --- Summary: 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 Reporter: Valentin Kulichenko 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] [Updated] (IGNITE-2030) ignite.bat file does not work when JAVA_HOME contains parethensis
[ https://issues.apache.org/jira/browse/IGNITE-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2030: Fix Version/s: (was: 1.7) 1.5 > ignite.bat file does not work when JAVA_HOME contains parethensis > - > > Key: IGNITE-2030 > URL: https://issues.apache.org/jira/browse/IGNITE-2030 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: ignite-1.4 >Reporter: Denis Magda > Fix For: 1.5 > > > When starting ignite.bat with a folder which contains parenthesis, the > launcher will fail: > For example, JAVA_HOME=C:\Program Files (x86)\jdk1.7.0_76\ > Program Files (x86) > Error (happens @ parseargs.bat script): > \Java\jre1.8.0_25\bin\java.exe" -cp > C:\ignite\gridgain-enterprise-fabric-7.5.0\g > ridgain-enterprise-fabric-7.5.0\libs\*;C:\ignite\gridgain-enterprise-fabric-7.5. > 0\gridgain-enterprise-fabric-7.5.0\libs\ignite-indexing\*;C:\ignite\gridgain-ent > erprise-fabric-7.5.0\gridgain-enterprise-fabric-7.5.0\libs\ignite-spring\*;C:\ig > nite\gridgain-enterprise-fabric-7.5.0\gridgain-enterprise-fabric-7.5.0\libs\lice > nses\* org.apache.ignite.startup.cmdline.CommandLineTransformer "`) was > unexpect > ed at this time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2030) ignite.bat file does not work when JAVA_HOME contains parethensis
[ https://issues.apache.org/jira/browse/IGNITE-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2030: Fix Version/s: (was: 1.6) 1.7 > ignite.bat file does not work when JAVA_HOME contains parethensis > - > > Key: IGNITE-2030 > URL: https://issues.apache.org/jira/browse/IGNITE-2030 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: ignite-1.4 >Reporter: Denis Magda > Fix For: 1.5 > > > When starting ignite.bat with a folder which contains parenthesis, the > launcher will fail: > For example, JAVA_HOME=C:\Program Files (x86)\jdk1.7.0_76\ > Program Files (x86) > Error (happens @ parseargs.bat script): > \Java\jre1.8.0_25\bin\java.exe" -cp > C:\ignite\gridgain-enterprise-fabric-7.5.0\g > ridgain-enterprise-fabric-7.5.0\libs\*;C:\ignite\gridgain-enterprise-fabric-7.5. > 0\gridgain-enterprise-fabric-7.5.0\libs\ignite-indexing\*;C:\ignite\gridgain-ent > erprise-fabric-7.5.0\gridgain-enterprise-fabric-7.5.0\libs\ignite-spring\*;C:\ig > nite\gridgain-enterprise-fabric-7.5.0\gridgain-enterprise-fabric-7.5.0\libs\lice > nses\* org.apache.ignite.startup.cmdline.CommandLineTransformer "`) was > unexpect > ed at this time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2087) Ignite CacheManager ignores provided class loader
[
https://issues.apache.org/jira/browse/IGNITE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2087:
Assignee: (was: Valentin Kulichenko)
> Ignite CacheManager ignores provided class loader
> -
>
> Key: IGNITE-2087
> URL: https://issues.apache.org/jira/browse/IGNITE-2087
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
>
> {{CacheManager}} should delegate the provided class loader to
> {{IgniteConfiguration.setClassLoader()}}. Currently it's ignored.
> user@ thread:
> http://apache-ignite-users.70518.x6.nabble.com/Help-with-integrating-Ignite-as-JCache-with-JBoss-EAP-6-4-td2134.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2087) Ignite CacheManager ignores provided class loader
Valentin Kulichenko created IGNITE-2087:
---
Summary: Ignite CacheManager ignores provided class loader
Key: IGNITE-2087
URL: https://issues.apache.org/jira/browse/IGNITE-2087
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
Fix For: 1.5
{{CacheManager}} should delegate the provided class loader to
{{IgniteConfiguration.setClassLoader()}}. Currently it's ignored.
user@ thread:
http://apache-ignite-users.70518.x6.nabble.com/Help-with-integrating-Ignite-as-JCache-with-JBoss-EAP-6-4-td2134.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2087) Ignite CacheManager ignores provided class loader
[
https://issues.apache.org/jira/browse/IGNITE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2087:
Fix Version/s: (was: 1.5)
1.6
> Ignite CacheManager ignores provided class loader
> -
>
> Key: IGNITE-2087
> URL: https://issues.apache.org/jira/browse/IGNITE-2087
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
>
> {{CacheManager}} should delegate the provided class loader to
> {{IgniteConfiguration.setClassLoader()}}. Currently it's ignored.
> user@ thread:
> http://apache-ignite-users.70518.x6.nabble.com/Help-with-integrating-Ignite-as-JCache-with-JBoss-EAP-6-4-td2134.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2083) EntryProcessor is called twice on primary node in transactional cache
Valentin Kulichenko created IGNITE-2083:
---
Summary: EntryProcessor is called twice on primary node in
transactional cache
Key: IGNITE-2083
URL: https://issues.apache.org/jira/browse/IGNITE-2083
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 1.6
Issue is described in details here:
http://apache-ignite-developers.2346864.n4.nabble.com/EntryProcessor-invoked-twice-td5494.html
Looks like that this can be optimized, at least for {{REPEATABLE_READ}}
transactions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2087) Ignite CacheManager ignores provided class loader
[
https://issues.apache.org/jira/browse/IGNITE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15046258#comment-15046258
]
Valentin Kulichenko commented on IGNITE-2087:
-
We can also add optional {{gridName}} property. If it's provided,
{{CacheManager}} will try to use existing Ignite instance instead of starting
the new one. This way user will have an option to use JCache API without Spring.
> Ignite CacheManager ignores provided class loader
> -
>
> Key: IGNITE-2087
> URL: https://issues.apache.org/jira/browse/IGNITE-2087
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
>
> {{CacheManager}} should delegate the provided class loader to
> {{IgniteConfiguration.setClassLoader()}}. Currently it's ignored.
> user@ thread:
> http://apache-ignite-users.70518.x6.nabble.com/Help-with-integrating-Ignite-as-JCache-with-JBoss-EAP-6-4-td2134.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2095) SpringCacheManager doesn't support withKeepBinary() flag
Valentin Kulichenko created IGNITE-2095:
---
Summary: SpringCacheManager doesn't support withKeepBinary() flag
Key: IGNITE-2095
URL: https://issues.apache.org/jira/browse/IGNITE-2095
Project: Ignite
Issue Type: Bug
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
Fix For: 1.5
Currently {{SpringCacheManager}} doesn't allow to switch to
{{withKeepBinary()}} cache.
SO thread:
http://stackoverflow.com/questions/34049172/ignite-and-spring-with-multiple-class-loaders/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2105) DirectMessageWriter cannot write nested collections.
[ https://issues.apache.org/jira/browse/IGNITE-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko reassigned IGNITE-2105: --- Assignee: Valentin Kulichenko > DirectMessageWriter cannot write nested collections. > > > Key: IGNITE-2105 > URL: https://issues.apache.org/jira/browse/IGNITE-2105 > Project: Ignite > Issue Type: Bug > Components: 1.4 >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Valentin Kulichenko >Priority: Critical > Fix For: 1.5 > > > Steps to reproduce: > 1) Run GridMessageCollectionTest in ignite-1.5 branch > 2) Observe class-cast exception. > The problem is caused by DirectByteBufferStreamImplV2 which is re-used across > all nested objects. > This class is stateful. When nested collection is written, instead of writing > collection element it writes element of another collection which is upper in > call stack. > Looks pretty critical for me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2105) DirectMessageWriter cannot write nested collections.
[ https://issues.apache.org/jira/browse/IGNITE-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2105: Priority: Blocker (was: Critical) > DirectMessageWriter cannot write nested collections. > > > Key: IGNITE-2105 > URL: https://issues.apache.org/jira/browse/IGNITE-2105 > Project: Ignite > Issue Type: Bug > Components: 1.4 >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Valentin Kulichenko >Priority: Blocker > Fix For: 1.5 > > > Steps to reproduce: > 1) Run GridMessageCollectionTest in ignite-1.5 branch > 2) Observe class-cast exception. > The problem is caused by DirectByteBufferStreamImplV2 which is re-used across > all nested objects. > This class is stateful. When nested collection is written, instead of writing > collection element it writes element of another collection which is upper in > call stack. > Looks pretty critical for me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2160) Ignition.start() is blocked if there are no server nodes
Valentin Kulichenko created IGNITE-2160:
---
Summary: Ignition.start() is blocked if there are no server nodes
Key: IGNITE-2160
URL: https://issues.apache.org/jira/browse/IGNITE-2160
Project: Ignite
Issue Type: Bug
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 1.6
A node (server or client) should always start without blocking the thread that
called {{Ignition.start()}}. Current behavior is confusing and undesirable -
e.g., if a node is embedded into web application, the whole application startup
process is stuck.
Additionally, if there are no servers, client node should throw
{{IgniteClientDisconnectedException}} on all API calls. It already works this
way if all servers leave while client is running.
@dev list discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Client-connect-quot-hangs-quot-td5765.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2105) DirectMessageWriter cannot write nested collections.
[ https://issues.apache.org/jira/browse/IGNITE-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko resolved IGNITE-2105. - Resolution: Fixed Merged into ignite-1.5 > DirectMessageWriter cannot write nested collections. > > > Key: IGNITE-2105 > URL: https://issues.apache.org/jira/browse/IGNITE-2105 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Valentin Kulichenko >Priority: Blocker > Fix For: 1.5 > > > Steps to reproduce: > 1) Run GridMessageCollectionTest in ignite-1.5 branch > 2) Observe class-cast exception. > The problem is caused by DirectByteBufferStreamImplV2 which is re-used across > all nested objects. > This class is stateful. When nested collection is written, instead of writing > collection element it writes element of another collection which is upper in > call stack. > Looks pretty critical for me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2095) SpringCacheManager doesn't support withKeepBinary() flag
[
https://issues.apache.org/jira/browse/IGNITE-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko resolved IGNITE-2095.
-
Resolution: Won't Fix
Adding this to Spring Caching doesn't make much sense, because switching
{{withKeepBinary}} flag on will force user to work with Ignite's
{{BinaryObject}}, which eliminates advantages of cache abstraction. In this
case it's easier to fully switch to Ignite API.
> SpringCacheManager doesn't support withKeepBinary() flag
>
>
> Key: IGNITE-2095
> URL: https://issues.apache.org/jira/browse/IGNITE-2095
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.5
>
>
> Currently {{SpringCacheManager}} doesn't allow to switch to
> {{withKeepBinary()}} cache.
> SO thread:
> http://stackoverflow.com/questions/34049172/ignite-and-spring-with-multiple-class-loaders/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2096) AtomicConfiguration and CollectionConfiguration should be properly checked for consistency
[
https://issues.apache.org/jira/browse/IGNITE-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2096:
Fix Version/s: (was: 1.5)
1.6
> AtomicConfiguration and CollectionConfiguration should be properly checked
> for consistency
> --
>
> Key: IGNITE-2096
> URL: https://issues.apache.org/jira/browse/IGNITE-2096
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.6
>
>
> Currently {{AtomicConfiguration}} and {{CollectionConfiguration}} are mapped
> to system caches configuration and consistency is checked like for any other
> cache. This leads to unintuitive errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2105) DirectMessageWriter cannot write nested collections.
[ https://issues.apache.org/jira/browse/IGNITE-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-2105. --- > DirectMessageWriter cannot write nested collections. > > > Key: IGNITE-2105 > URL: https://issues.apache.org/jira/browse/IGNITE-2105 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Valentin Kulichenko >Priority: Blocker > Fix For: 1.5 > > > Steps to reproduce: > 1) Run GridMessageCollectionTest in ignite-1.5 branch > 2) Observe class-cast exception. > The problem is caused by DirectByteBufferStreamImplV2 which is re-used across > all nested objects. > This class is stateful. When nested collection is written, instead of writing > collection element it writes element of another collection which is upper in > call stack. > Looks pretty critical for me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2095) SpringCacheManager doesn't support withKeepBinary() flag
[
https://issues.apache.org/jira/browse/IGNITE-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-2095.
---
> SpringCacheManager doesn't support withKeepBinary() flag
>
>
> Key: IGNITE-2095
> URL: https://issues.apache.org/jira/browse/IGNITE-2095
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.5
>
>
> Currently {{SpringCacheManager}} doesn't allow to switch to
> {{withKeepBinary()}} cache.
> SO thread:
> http://stackoverflow.com/questions/34049172/ignite-and-spring-with-multiple-class-loaders/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2004) Asynchronous execution of ContinuousQuery's remote filter
[ https://issues.apache.org/jira/browse/IGNITE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko reassigned IGNITE-2004: --- Assignee: Valentin Kulichenko > Asynchronous execution of ContinuousQuery's remote filter > - > > Key: IGNITE-2004 > URL: https://issues.apache.org/jira/browse/IGNITE-2004 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Denis Magda >Assignee: Valentin Kulichenko > Fix For: 1.6 > > > Presently remote filters are executed synchronously an entry update. This > leads to the limitation when it's disallowed to perform cache related > operation in a filter body. > It's required to add the ability to execute remote filters asynchronously. > This will let to execute any kind of operations including cache operations > directly in the filter body. > The solution must be fault-tolerant. At least once execution of a filter in > case of a failure works fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
