[jira] [Resolved] (IGNITE-2800) Coordinator floods network with partitions' full map messages
[ https://issues.apache.org/jira/browse/IGNITE-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-2800. - Resolution: Duplicate IGNITE-2799 > Coordinator floods network with partitions' full map messages > - > > Key: IGNITE-2800 > URL: https://issues.apache.org/jira/browse/IGNITE-2800 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.6 > > > It is detected that the more machines in the cluster we have and the more > caches are started then the more outgoing traffic is produced by a > coordinator node. > As an example in the current deployment > - 30 nodes; > - 67 caches; > - caches are empty and the cluster is not used at all (idle). > the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast > each other node shows constant 10 Mbit/s usage of incoming traffic. > Most likely the reason is that the coordinator indefinitely sends partitions > full map for all the caches to all the nodes. This shouldn't happen. > Need to debug the reason of the issue and fix it. > Attached snapshots taken from the coordinator and on of cluster's nodes. > Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2800) Coordinator floods network with partitions' full map messages
[ https://issues.apache.org/jira/browse/IGNITE-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2800. --- > Coordinator floods network with partitions' full map messages > - > > Key: IGNITE-2800 > URL: https://issues.apache.org/jira/browse/IGNITE-2800 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.6 > > > It is detected that the more machines in the cluster we have and the more > caches are started then the more outgoing traffic is produced by a > coordinator node. > As an example in the current deployment > - 30 nodes; > - 67 caches; > - caches are empty and the cluster is not used at all (idle). > the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast > each other node shows constant 10 Mbit/s usage of incoming traffic. > Most likely the reason is that the coordinator indefinitely sends partitions > full map for all the caches to all the nodes. This shouldn't happen. > Need to debug the reason of the issue and fix it. > Attached snapshots taken from the coordinator and on of cluster's nodes. > Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2799) Coordinator floods network with partitions' full map messages
[ https://issues.apache.org/jira/browse/IGNITE-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-2799. - Resolution: Duplicate IGNITE-2801 > Coordinator floods network with partitions' full map messages > - > > Key: IGNITE-2799 > URL: https://issues.apache.org/jira/browse/IGNITE-2799 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.6 > > > It is detected that the more machines in the cluster we have and the more > caches are started then the more outgoing traffic is produced by a > coordinator node. > As an example in the current deployment > - 30 nodes; > - 67 caches; > - caches are empty and the cluster is not used at all (idle). > the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast > each other node shows constant 10 Mbit/s usage of incoming traffic. > Most likely the reason is that the coordinator indefinitely sends partitions > full map for all the caches to all the nodes. This shouldn't happen. > Need to debug the reason of the issue and fix it. > Attached snapshots taken from the coordinator and on of cluster's nodes. > Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2801) Coordinator floods network with partitions' full map messages
[ https://issues.apache.org/jira/browse/IGNITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2801. --- > Coordinator floods network with partitions' full map messages > - > > Key: IGNITE-2801 > URL: https://issues.apache.org/jira/browse/IGNITE-2801 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Critical > Labels: community, important > Fix For: 1.6 > > Attachments: basic_node.nps, basic_node.png, coordinator.nps, > coordinator.png > > > It is detected that the more machines in the cluster we have and the more > caches are started then the more outgoing traffic is produced by a > coordinator node. > As an example in the current deployment > - 30 nodes; > - 67 caches; > - caches are empty and the cluster is not used at all (idle). > the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast > each other node shows constant 10 Mbit/s usage of incoming traffic. > Most likely the reason is that the coordinator indefinitely sends partitions > full map for all the caches to all the nodes. This shouldn't happen. > Need to debug the reason of the issue and fix it. > Attached snapshots taken from the coordinator and on of cluster's nodes. > Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2799) Coordinator floods network with partitions' full map messages
[ https://issues.apache.org/jira/browse/IGNITE-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2799. --- > Coordinator floods network with partitions' full map messages > - > > Key: IGNITE-2799 > URL: https://issues.apache.org/jira/browse/IGNITE-2799 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.6 > > > It is detected that the more machines in the cluster we have and the more > caches are started then the more outgoing traffic is produced by a > coordinator node. > As an example in the current deployment > - 30 nodes; > - 67 caches; > - caches are empty and the cluster is not used at all (idle). > the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast > each other node shows constant 10 Mbit/s usage of incoming traffic. > Most likely the reason is that the coordinator indefinitely sends partitions > full map for all the caches to all the nodes. This shouldn't happen. > Need to debug the reason of the issue and fix it. > Attached snapshots taken from the coordinator and on of cluster's nodes. > Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2801) Coordinator floods network with partitions' full map messages
[ https://issues.apache.org/jira/browse/IGNITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-2801. - Resolution: Duplicate IGNITE-2799 > Coordinator floods network with partitions' full map messages > - > > Key: IGNITE-2801 > URL: https://issues.apache.org/jira/browse/IGNITE-2801 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Critical > Labels: community, important > Fix For: 1.6 > > Attachments: basic_node.nps, basic_node.png, coordinator.nps, > coordinator.png > > > It is detected that the more machines in the cluster we have and the more > caches are started then the more outgoing traffic is produced by a > coordinator node. > As an example in the current deployment > - 30 nodes; > - 67 caches; > - caches are empty and the cluster is not used at all (idle). > the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast > each other node shows constant 10 Mbit/s usage of incoming traffic. > Most likely the reason is that the coordinator indefinitely sends partitions > full map for all the caches to all the nodes. This shouldn't happen. > Need to debug the reason of the issue and fix it. > Attached snapshots taken from the coordinator and on of cluster's nodes. > Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2792) System caches should not use user-defined TransactionConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-2792: --- Assignee: Vladimir Ozerov (was: Semen Boikov) > System caches should not use user-defined TransactionConfiguration. > --- > > Key: IGNITE-2792 > URL: https://issues.apache.org/jira/browse/IGNITE-2792 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.6 > > > *Problem* > Currently if user set his custom TransactionConfiguration, it will be used > not only user public caches, but by internal Ignite caches as well. This > could lead to some bad situations, such a transaction timeouts, optimistic > exceptions, etc.. > *Proposed solution* > Ensure that transactional system caches do not use custom > TransactionConfiguraton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2792) System caches should not use user-defined TransactionConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-2792: --- Assignee: Dmitry Karachentsev (was: Vladimir Ozerov) > System caches should not use user-defined TransactionConfiguration. > --- > > Key: IGNITE-2792 > URL: https://issues.apache.org/jira/browse/IGNITE-2792 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Dmitry Karachentsev >Priority: Critical > Fix For: 1.6 > > > *Problem* > Currently if user set his custom TransactionConfiguration, it will be used > not only user public caches, but by internal Ignite caches as well. This > could lead to some bad situations, such a transaction timeouts, optimistic > exceptions, etc.. > *Proposed solution* > Ensure that transactional system caches do not use custom > TransactionConfiguraton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2798) 'Transaction has already been completed' in restart tests
[
https://issues.apache.org/jira/browse/IGNITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-2798:
---
Assignee: Dmitry Karachentsev
> 'Transaction has already been completed' in restart tests
> -
>
> Key: IGNITE-2798
> URL: https://issues.apache.org/jira/browse/IGNITE-2798
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
> Fix For: 1.6
>
>
> When running transaction tests with node restarts (e.g.
> {{IgniteCacheTxNearDisabledPutGetRestartTest}}, logs are flooded with
> exceptions like below. Need to check if it's an issue or not.
> {noformat}
> [18:03:18,760][WARN
> ][sys-#11142%distributed.IgniteCacheTxNearDisabledPutGetRestartTest2%][IgniteTxHandler]
> Received finish request for completed transaction (the message may be too
> late and transaction could have been DGCed by now) [commit=false,
> xid=GridCacheVersion [topVer=69142079, nodeOrderDrId=3,
> globalTime=1457661798754, order=1457662644887]]
> [18:03:18] (err) Failed to execute compound future reducer: Compound future
> listener []class org.apache.ignite.IgniteCheckedException: Transaction has
> been already completed.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:650)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:597)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:568)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:127)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:125)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1071) IgniteCache.metrics() method returns local metrics
[
https://issues.apache.org/jira/browse/IGNITE-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov reassigned IGNITE-1071:
Assignee: Anton Vinogradov
> IgniteCache.metrics() method returns local metrics
> --
>
> Key: IGNITE-1071
> URL: https://issues.apache.org/jira/browse/IGNITE-1071
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Minor
> Labels: Usability
> Fix For: 1.6
>
>
> To get metrics for the whole cluster user needs to use
> {{cache.metrics(ignite.cluster())}}, which is counterintuitive and
> inconsistent with other APIs. {{IgniteCache.metrics()}} w/o parameters should
> return metrics for the whole cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2764) LINQ plan caching
[ https://issues.apache.org/jira/browse/IGNITE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190687#comment-15190687 ] Pavel Tupitsyn commented on IGNITE-2764: Stopping this for now. > LINQ plan caching > - > > Key: IGNITE-2764 > URL: https://issues.apache.org/jira/browse/IGNITE-2764 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Investigate EF/NHibernate: how do they calculate cache key from expression > tree to cache query plan? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2663) ODBC: Add protocol version to protocol packet header.
[
https://issues.apache.org/jira/browse/IGNITE-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190701#comment-15190701
]
Igor Sapego commented on IGNITE-2663:
-
Vladimir, I agree it is not an advantage, I just explained why I implemented it
the way I did.
> ODBC: Add protocol version to protocol packet header.
> -
>
> Key: IGNITE-2663
> URL: https://issues.apache.org/jira/browse/IGNITE-2663
> Project: Ignite
> Issue Type: Sub-task
> Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Currently, there is no way for server to find out that ODBC driver uses
> incompatible protocol version. Consider adding {{protocolVersion}} field to
> ODBC protocol message header.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2404) TcpDiscoverySpi.setLocalPortRange set 0 doesn't work
[ https://issues.apache.org/jira/browse/IGNITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190707#comment-15190707 ] Ryan Zhao commented on IGNITE-2404: --- The doc on TcpCommunicationSpi.setLocalPortRange() saying that "If port range value is 0, then implementation will try bind only to the port provided by setLocalPort(int) method and fail if binding to this port did not succeed." So, I think it would be a right choice to treat localPortRange=0 as localPortRange=1. I will solve it. > TcpDiscoverySpi.setLocalPortRange set 0 doesn't work > - > > Key: IGNITE-2404 > URL: https://issues.apache.org/jira/browse/IGNITE-2404 > Project: Ignite > Issue Type: Bug >Reporter: Denis Magda > Labels: community, newbie > > Local port range set to 0 presently doesn't work at least for > TcpCommunicationSpi and TcpDiscoverySpi. However SPIs support it. > In my understanding the condition has to changed to the following one (from < > to <=). > x = port; x <= port + range -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2404) TcpDiscoverySpi.setLocalPortRange set 0 doesn't work
[ https://issues.apache.org/jira/browse/IGNITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Zhao reassigned IGNITE-2404: - Assignee: Ryan Zhao > TcpDiscoverySpi.setLocalPortRange set 0 doesn't work > - > > Key: IGNITE-2404 > URL: https://issues.apache.org/jira/browse/IGNITE-2404 > Project: Ignite > Issue Type: Bug >Reporter: Denis Magda >Assignee: Ryan Zhao > Labels: community, newbie > > Local port range set to 0 presently doesn't work at least for > TcpCommunicationSpi and TcpDiscoverySpi. However SPIs support it. > In my understanding the condition has to changed to the following one (from < > to <=). > x = port; x <= port + range -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2690) Format of uptime for metrics
[
https://issues.apache.org/jira/browse/IGNITE-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190732#comment-15190732
]
Denis Magda commented on IGNITE-2690:
-
[~alpert], thanks for the contribution! I've reviewed and merged your changes
into the master.
> Format of uptime for metrics
>
>
> Key: IGNITE-2690
> URL: https://issues.apache.org/jira/browse/IGNITE-2690
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Alper Tekinalp
>Priority: Trivial
> Labels: newbie
> Attachments: master_baa1312_IGNITE-2690.patch
>
>
> Milliseconds of uptime from metrics should be properly formatted (3 digits):
> {noformat}
> [16:35:08,994][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=fcc9d9ca, name=null, uptime=01:04:00:996]
> ...
> [16:36:09,011][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=fcc9d9ca, name=null, uptime=01:05:01:14]
> {noformat}
> :14 -> :014
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2694) .NET: AnyCPU build
[ https://issues.apache.org/jira/browse/IGNITE-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-2694: -- Assignee: Pavel Tupitsyn > .NET: AnyCPU build > -- > > Key: IGNITE-2694 > URL: https://issues.apache.org/jira/browse/IGNITE-2694 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Currently we provide separate x86 & x64 binaries. NuGet is x64-only. > This is inconvenient both for us and the user. > The only thing that prevents AnyCPU is unmanaged "common" project. > But we load it dynamically from resources, and we may as well detect current > process platform (x64 or not) and load a proper unmanaged resource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2690) Format of uptime for metrics
[
https://issues.apache.org/jira/browse/IGNITE-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda closed IGNITE-2690.
---
> Format of uptime for metrics
>
>
> Key: IGNITE-2690
> URL: https://issues.apache.org/jira/browse/IGNITE-2690
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Alper Tekinalp
>Priority: Trivial
> Labels: newbie
> Attachments: master_baa1312_IGNITE-2690.patch
>
>
> Milliseconds of uptime from metrics should be properly formatted (3 digits):
> {noformat}
> [16:35:08,994][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=fcc9d9ca, name=null, uptime=01:04:00:996]
> ...
> [16:36:09,011][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=fcc9d9ca, name=null, uptime=01:05:01:14]
> {noformat}
> :14 -> :014
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-642) Implement IgniteReentrantLock data structure
[
https://issues.apache.org/jira/browse/IGNITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190817#comment-15190817
]
Anton Vinogradov commented on IGNITE-642:
-
Yakov,
classnames.properties generates automatically during project build (using
org.apache.ignite.tools.classgen.ClassesGenerator),
but to have correct list during testing developer should:
1) run maven command:
mvn clean package -DskipTests
2) replace classnames.properties (at sources) with generated
classnames.properties (at target/classes/META-INF).
Manual addition of new classes to classnames.properties also possible but not
recomended.
P.s. It takes more that 20 minutes to investigate this but I have no clue where
can I publish this knowledge.
Yakov, can you suggest desired location of this knowledge?
> Implement IgniteReentrantLock data structure
>
>
> Key: IGNITE-642
> URL: https://issues.apache.org/jira/browse/IGNITE-642
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>
> We need to add {{IgniteReentrantLock}} data structure in addition to other
> data structures provided by Ignite. {{IgniteReentrantLock}} should have
> similar API to {{java.util.concurrent.locks.ReentrantLock}} 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 lock-owner
> identifier together with a queue of waiters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2796) NPE during rebalancing
[
https://issues.apache.org/jira/browse/IGNITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov reassigned IGNITE-2796:
Assignee: Anton Vinogradov
> NPE during rebalancing
> --
>
> Key: IGNITE-2796
> URL: https://issues.apache.org/jira/browse/IGNITE-2796
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, customer, important
> Fix For: 1.6
>
>
> This exception sometimes appear in logs when topology changes under load:
> {noformat}
> 2016-03-06T08:07:52,500 ERROR [sys-#47%null%] (Slf4jLogger.java:112) - Failed
> processing message [senderId=ad2315fd-237c-492c-a1c6-7ea69c7f3807,
> msg=GridDhtPartitionSupplyMessageV2 [updateSeq=35,
> topVer=AffinityTopologyVersion [topVer=1413, minorTopVer=0], missed=null,
> msgSize=0, size=1, parts=[718], super=GridCacheMessage [msgId=52249,
> depInfo=null, err=null, skipPrepare=false, cacheId=1762189895,
> cacheId=1762189895]]]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:971)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1100(GridDhtPartitionDemander.java:751)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:600)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:407)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:80)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1085)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2236)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1003)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:972)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_51]
> {noformat}
> It doesn't seem to break anything, but still has to be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2694) .NET: AnyCPU build
[ https://issues.apache.org/jira/browse/IGNITE-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190858#comment-15190858 ] ASF GitHub Bot commented on IGNITE-2694: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/546 IGNITE-2694 .NET: AnyCPU build You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-2694 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/546.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #546 commit 5f6bda9ce0bb280d9492f1e4cde618db2617cafe Author: Pavel Tupitsyn Date: 2016-03-11T10:36:33Z wip commit 578fdc986d7716b9477c708f40a755f8aa381721 Author: Pavel Tupitsyn Date: 2016-03-11T11:09:14Z wip commit 682b4ea1719bfa67eab250aa9407501e672ed4fb Author: Pavel Tupitsyn Date: 2016-03-11T11:13:56Z wip commit 3ff1be527f717b6b413533a34015e048835ee6e2 Author: Pavel Tupitsyn Date: 2016-03-11T11:23:42Z Fix DLL loading commit 7029a9cdaf6391d8e5ceac2c4e715672ff0db2b4 Author: Pavel Tupitsyn Date: 2016-03-11T11:41:37Z Update project/solution platforms commit 841f6ffc34e83a2417017c52762ab1dc38842bb3 Author: Pavel Tupitsyn Date: 2016-03-11T12:00:17Z Fix tests and examples > .NET: AnyCPU build > -- > > Key: IGNITE-2694 > URL: https://issues.apache.org/jira/browse/IGNITE-2694 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Currently we provide separate x86 & x64 binaries. NuGet is x64-only. > This is inconvenient both for us and the user. > The only thing that prevents AnyCPU is unmanaged "common" project. > But we load it dynamically from resources, and we may as well detect current > process platform (x64 or not) and load a proper unmanaged resource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2429) ODBC: Add examples.
[ https://issues.apache.org/jira/browse/IGNITE-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2429: Assignee: Igor Sapego (was: Vladimir Ozerov) > ODBC: Add examples. > --- > > Key: IGNITE-2429 > URL: https://issues.apache.org/jira/browse/IGNITE-2429 > Project: Ignite > Issue Type: Sub-task > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego > Fix For: 1.6 > > > We need to implement examples that will show how to use our ODBC driver. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2793) ODBC: Add support for Arrays.
[
https://issues.apache.org/jira/browse/IGNITE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2793:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-1786)
> ODBC: Add support for Arrays.
> -
>
> Key: IGNITE-2793
> URL: https://issues.apache.org/jira/browse/IGNITE-2793
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> Support for arrays should be added. We need to at least support byte arrays
> to match {{SQL_C_BINARY}} type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2793) ODBC: Add support for Arrays.
[
https://issues.apache.org/jira/browse/IGNITE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2793:
Fix Version/s: (was: 1.6)
1.7
> ODBC: Add support for Arrays.
> -
>
> Key: IGNITE-2793
> URL: https://issues.apache.org/jira/browse/IGNITE-2793
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.7
>
>
> Support for arrays should be added. We need to at least support byte arrays
> to match {{SQL_C_BINARY}} type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2794) ODBC: Make sure that SQL_C_BINARY type is supported.
[
https://issues.apache.org/jira/browse/IGNITE-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2794:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-1786)
> ODBC: Make sure that SQL_C_BINARY type is supported.
>
>
> Key: IGNITE-2794
> URL: https://issues.apache.org/jira/browse/IGNITE-2794
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> Need to make sure that any column can be fetched as {{SQL_C_BINARY}} type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2794) ODBC: Make sure that SQL_C_BINARY type is supported.
[
https://issues.apache.org/jira/browse/IGNITE-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2794:
Fix Version/s: (was: 1.6)
1.7
> ODBC: Make sure that SQL_C_BINARY type is supported.
>
>
> Key: IGNITE-2794
> URL: https://issues.apache.org/jira/browse/IGNITE-2794
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.7
>
>
> Need to make sure that any column can be fetched as {{SQL_C_BINARY}} type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2802) ODBC: Add support for address ranges.
Igor Sapego created IGNITE-2802: --- Summary: ODBC: Add support for address ranges. Key: IGNITE-2802 URL: https://issues.apache.org/jira/browse/IGNITE-2802 Project: Ignite Issue Type: Task Components: odbc Affects Versions: 1.5.0.final Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 1.7 We should add ability for user to input address range from which ODBC driver can choose a node to connect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2803) ODBC: Add SSL support.
Igor Sapego created IGNITE-2803: --- Summary: ODBC: Add SSL support. Key: IGNITE-2803 URL: https://issues.apache.org/jira/browse/IGNITE-2803 Project: Ignite Issue Type: Task Components: odbc Affects Versions: 1.5.0.final Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 1.7 Need to implement SSL support for the ODBC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2804) ODBC: Implement ODBC-related events.
Igor Sapego created IGNITE-2804: --- Summary: ODBC: Implement ODBC-related events. Key: IGNITE-2804 URL: https://issues.apache.org/jira/browse/IGNITE-2804 Project: Ignite Issue Type: Task Components: odbc Affects Versions: 1.5.0.final Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 1.7 We should implement ODBC-related events, e.g. OdbcConnect/OdbcDisconnect events. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2805) CPP: Implement transactions API for CPP client.
Igor Sapego created IGNITE-2805: --- Summary: CPP: Implement transactions API for CPP client. Key: IGNITE-2805 URL: https://issues.apache.org/jira/browse/IGNITE-2805 Project: Ignite Issue Type: Task Components: platforms Affects Versions: 1.5.0.final Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 1.6 We should implement Transactions API for Ignite C++. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2806) IGFS: re-create lock relaxed version
Ivan Veselovsky created IGNITE-2806: --- Summary: IGFS: re-create lock relaxed version Key: IGNITE-2806 URL: https://issues.apache.org/jira/browse/IGNITE-2806 Project: Ignite Issue Type: Bug Components: IGFS Affects Versions: 1.6 Reporter: Ivan Veselovsky Assignee: Ivan Veselovsky Fix For: 1.6 Earlier we had IGFS implementation that seemed to be fast, but was not absolutely correct in terms of synchronization logic. As now we suspect some problems with IGFS performance, we need to create such version of the implementation again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2644) ODBC: Add metrics.
[ https://issues.apache.org/jira/browse/IGNITE-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-2644: Issue Type: Task (was: Sub-task) Parent: (was: IGNITE-1786) > ODBC: Add metrics. > -- > > Key: IGNITE-2644 > URL: https://issues.apache.org/jira/browse/IGNITE-2644 > Project: Ignite > Issue Type: Task > Components: odbc >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Igor Sapego > Fix For: 1.7 > > > Let's plan this feature for further releases (e.g. 1.7). > We should add ODBC metrics. Several ideas on what to count: > 1) Currently connected clients > 2) Max connected clients > 3) Total connected clients > 4) SQL requests executed > 5) Records fetched > 6) Average processing time > Anything else? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2807) IGFS: re-create lock relaxed version
Ivan Veselovsky created IGNITE-2807: --- Summary: IGFS: re-create lock relaxed version Key: IGNITE-2807 URL: https://issues.apache.org/jira/browse/IGNITE-2807 Project: Ignite Issue Type: Bug Components: IGFS Affects Versions: 1.6 Reporter: Ivan Veselovsky Assignee: Ivan Veselovsky Fix For: 1.6 Earlier we had IGFS implementation that seemed to be fast, but was not absolutely correct in terms of synchronization logic. As now we suspect some problems with IGFS performance, we need to create such version of the implementation again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2808) IGFS: re-create lock relaxed version
Ivan Veselovsky created IGNITE-2808: --- Summary: IGFS: re-create lock relaxed version Key: IGNITE-2808 URL: https://issues.apache.org/jira/browse/IGNITE-2808 Project: Ignite Issue Type: Bug Components: IGFS Affects Versions: 1.6 Reporter: Ivan Veselovsky Assignee: Ivan Veselovsky Fix For: 1.6 Earlier we had IGFS implementation that seemed to be fast, but was not absolutely correct in terms of synchronization logic. As now we suspect some problems with IGFS performance, we need to create such version of the implementation again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2246) CPP: Implement Descriptors support for the ODBC driver.
[
https://issues.apache.org/jira/browse/IGNITE-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2246:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-1786)
> CPP: Implement Descriptors support for the ODBC driver.
> ---
>
> Key: IGNITE-2246
> URL: https://issues.apache.org/jira/browse/IGNITE-2246
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> This feature listed in the [ODBC Core Interface
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx]
> and should be implemented for our driver.
> This includes implementation of the following functions:
> - {{SQLCopyDesc}}
> - {{SQLGetDescField}}
> - {{SQLGetDescRec}}
> - {{SQLSetDescField}}
> - {{SQLSetDescRec}}
> Following header fields:
> - {{SQL_DESC_ALLOC_TYPE}}
> - {{SQL_DESC_ARRAY_SIZE}}
> - {{SQL_DESC_ARRAY_STATUS_PTR}}
> - {{SQL_DESC_BIND_OFFSET_PTR}}
> - {{SQL_DESC_BIND_TYPE}}
> - {{SQL_DESC_COUNT}}
> - {{SQL_DESC_ROWS_PROCESSED_PTR}}
> Following record fields:
> - {{SQL_DESC_BASE_COLUMN_NAME}}
> - {{SQL_DESC_CASE_SENSITIVE}}
> - {{SQL_DESC_CONCISE_TYPE}}
> - {{SQL_DESC_DATA_PTR}}
> - {{SQL_DESC_DATETIME_INTERVAL_ CODE}}
> - {{SQL_DESC_DATETIME_INTERVAL_ PRECISION}}
> - {{SQL_DESC_DISPLAY_SIZE}}
> - {{SQL_DESC_FIXED_PREC_SCALE}}
> - {{SQL_DESC_INDICATOR_PTR}}
> - {{SQL_DESC_LENGTH}}
> - {{SQL_DESC_LITERAL_PREFIX}}
> - {{SQL_DESC_LITERAL_SUFFIX}}
> - {{SQL_DESC_LOCAL_TYPE_NAME}}
> - {{SQL_DESC_NAME}}
> - {{SQL_DESC_NULLABLE}}
> - {{SQL_DESC_OCTET_LENGTH}}
> - {{SQL_DESC_OCTET_LENGTH_PTR}}
> - {{SQL_DESC_PARAMETER_TYPE}}
> - {{SQL_DESC_PRECISION}}
> - {{SQL_DESC_SCALE}}
> - {{SQL_DESC_SEARCHABLE}}
> - {{SQL_DESC_TYPE}}
> - {{SQL_DESC_TYPE_NAME}}
> - {{SQL_DESC_UNNAMED}}
> - {{SQL_DESC_UNSIGNED}}
> - {{SQL_DESC_UPDATABLE}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1680) CPP: Implement basic API for remote job execution
[ https://issues.apache.org/jira/browse/IGNITE-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-1680: Fix Version/s: 1.7 > CPP: Implement basic API for remote job execution > - > > Key: IGNITE-1680 > URL: https://issues.apache.org/jira/browse/IGNITE-1680 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Igor Sapego >Assignee: Igor Sapego > Fix For: 1.7 > > > Need to implement IgniteCompute class for C++ with one basic method > IgniteCompute::Call(...) which will provide basic remote job execution API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2244) CPP: Implement Connection attributes manipulation for the ODBC driver.
[
https://issues.apache.org/jira/browse/IGNITE-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2244:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-1786)
> CPP: Implement Connection attributes manipulation for the ODBC driver.
> --
>
> Key: IGNITE-2244
> URL: https://issues.apache.org/jira/browse/IGNITE-2244
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> This feature listed in the [ODBC Core Interface
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx]
> and should be implemented for our driver.
> The list of functions that should be implemented:
> - {{SQLGetConnectAttr}}
> - {{SQLSetConnectAttr}}
> The minimum list of attributes that should be supported:
> - {{SQL_ATTR_ACCESS_MODE}}
> - {{SQL_ATTR_ODBC_CURSORS}}
> - {{SQL_ATTR_QUIET_MODE}}
> - {{SQL_ATTR_TRACE}}
> - {{SQL_ATTR_TRACEFILE}}
> - {{SQL_ATTR_TRANSLATE_LIB}}
> - {{SQL_ATTR_TRANSLATE_OPTION}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2245) CPP: Implement Statement attributes manipulation for the ODBC driver.
[
https://issues.apache.org/jira/browse/IGNITE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2245:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-1786)
> CPP: Implement Statement attributes manipulation for the ODBC driver.
> -
>
> Key: IGNITE-2245
> URL: https://issues.apache.org/jira/browse/IGNITE-2245
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> This feature listed in the [ODBC Core Interface
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx]
> and should be implemented for our driver.
> The list of functions that should be implemented:
> - {{SQLGetStmtAttr}}
> - {{SQLSetStmtAttr}}
> The minimum list of attributes that should be supported:
> - {{SQL_ATTR_APP_PARAM_DESC}}
> - {{SQL_ATTR_APP_ROW_DESC}}
> - {{SQL_ATTR_IMP_PARAM_DESC}}
> - {{SQL_ATTR_IMP_ROW_DESC}}
> - {{SQL_ATTR_METADATA_ID}}
> - {{SQL_ATTR_NOSCAN}}
> - {{SQL_ATTR_PARAM_BIND_OFFSET_PTR}}
> - {{SQL_ATTR_PARAM_BIND_TYPE}}
> - {{SQL_ATTR_PARAM_OPERATION_PTR}}
> - {{SQL_ATTR_PARAM_STATUS_PTR}}
> - {{SQL_ATTR_PARAMS_PROCESSED_PTR}}
> - {{SQL_ATTR_PARAMSET_SIZE}}
> - {{SQL_ATTR_ROW_ARRAY_SIZE}}
> - {{SQL_ATTR_ROW_BIND_OFFSET_PTR}}
> - {{SQL_ATTR_ROW_BIND_TYPE}}
> - {{SQL_ATTR_ROW_STATUS_PTR}}
> - {{SQL_ATTR_ROWS_FETCHED_PTR}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2244) CPP: Implement Connection attributes manipulation for the ODBC driver.
[
https://issues.apache.org/jira/browse/IGNITE-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2244:
Fix Version/s: (was: 1.6)
1.7
> CPP: Implement Connection attributes manipulation for the ODBC driver.
> --
>
> Key: IGNITE-2244
> URL: https://issues.apache.org/jira/browse/IGNITE-2244
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.7
>
>
> This feature listed in the [ODBC Core Interface
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx]
> and should be implemented for our driver.
> The list of functions that should be implemented:
> - {{SQLGetConnectAttr}}
> - {{SQLSetConnectAttr}}
> The minimum list of attributes that should be supported:
> - {{SQL_ATTR_ACCESS_MODE}}
> - {{SQL_ATTR_ODBC_CURSORS}}
> - {{SQL_ATTR_QUIET_MODE}}
> - {{SQL_ATTR_TRACE}}
> - {{SQL_ATTR_TRACEFILE}}
> - {{SQL_ATTR_TRANSLATE_LIB}}
> - {{SQL_ATTR_TRANSLATE_OPTION}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2246) CPP: Implement Descriptors support for the ODBC driver.
[
https://issues.apache.org/jira/browse/IGNITE-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2246:
Fix Version/s: (was: 1.6)
1.7
> CPP: Implement Descriptors support for the ODBC driver.
> ---
>
> Key: IGNITE-2246
> URL: https://issues.apache.org/jira/browse/IGNITE-2246
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.7
>
>
> This feature listed in the [ODBC Core Interface
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx]
> and should be implemented for our driver.
> This includes implementation of the following functions:
> - {{SQLCopyDesc}}
> - {{SQLGetDescField}}
> - {{SQLGetDescRec}}
> - {{SQLSetDescField}}
> - {{SQLSetDescRec}}
> Following header fields:
> - {{SQL_DESC_ALLOC_TYPE}}
> - {{SQL_DESC_ARRAY_SIZE}}
> - {{SQL_DESC_ARRAY_STATUS_PTR}}
> - {{SQL_DESC_BIND_OFFSET_PTR}}
> - {{SQL_DESC_BIND_TYPE}}
> - {{SQL_DESC_COUNT}}
> - {{SQL_DESC_ROWS_PROCESSED_PTR}}
> Following record fields:
> - {{SQL_DESC_BASE_COLUMN_NAME}}
> - {{SQL_DESC_CASE_SENSITIVE}}
> - {{SQL_DESC_CONCISE_TYPE}}
> - {{SQL_DESC_DATA_PTR}}
> - {{SQL_DESC_DATETIME_INTERVAL_ CODE}}
> - {{SQL_DESC_DATETIME_INTERVAL_ PRECISION}}
> - {{SQL_DESC_DISPLAY_SIZE}}
> - {{SQL_DESC_FIXED_PREC_SCALE}}
> - {{SQL_DESC_INDICATOR_PTR}}
> - {{SQL_DESC_LENGTH}}
> - {{SQL_DESC_LITERAL_PREFIX}}
> - {{SQL_DESC_LITERAL_SUFFIX}}
> - {{SQL_DESC_LOCAL_TYPE_NAME}}
> - {{SQL_DESC_NAME}}
> - {{SQL_DESC_NULLABLE}}
> - {{SQL_DESC_OCTET_LENGTH}}
> - {{SQL_DESC_OCTET_LENGTH_PTR}}
> - {{SQL_DESC_PARAMETER_TYPE}}
> - {{SQL_DESC_PRECISION}}
> - {{SQL_DESC_SCALE}}
> - {{SQL_DESC_SEARCHABLE}}
> - {{SQL_DESC_TYPE}}
> - {{SQL_DESC_TYPE_NAME}}
> - {{SQL_DESC_UNNAMED}}
> - {{SQL_DESC_UNSIGNED}}
> - {{SQL_DESC_UPDATABLE}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2808) IGFS: re-create lock relaxed version
[ https://issues.apache.org/jira/browse/IGNITE-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Veselovsky resolved IGNITE-2808. - Resolution: Duplicate > IGFS: re-create lock relaxed version > > > Key: IGNITE-2808 > URL: https://issues.apache.org/jira/browse/IGNITE-2808 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Ivan Veselovsky > Fix For: 1.6 > > > Earlier we had IGFS implementation that seemed to be fast, but was not > absolutely correct in terms of synchronization logic. As now we suspect some > problems with IGFS performance, we need to create such version of the > implementation again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2245) CPP: Implement Statement attributes manipulation for the ODBC driver.
[
https://issues.apache.org/jira/browse/IGNITE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-2245:
Fix Version/s: (was: 1.6)
1.7
> CPP: Implement Statement attributes manipulation for the ODBC driver.
> -
>
> Key: IGNITE-2245
> URL: https://issues.apache.org/jira/browse/IGNITE-2245
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.7
>
>
> This feature listed in the [ODBC Core Interface
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx]
> and should be implemented for our driver.
> The list of functions that should be implemented:
> - {{SQLGetStmtAttr}}
> - {{SQLSetStmtAttr}}
> The minimum list of attributes that should be supported:
> - {{SQL_ATTR_APP_PARAM_DESC}}
> - {{SQL_ATTR_APP_ROW_DESC}}
> - {{SQL_ATTR_IMP_PARAM_DESC}}
> - {{SQL_ATTR_IMP_ROW_DESC}}
> - {{SQL_ATTR_METADATA_ID}}
> - {{SQL_ATTR_NOSCAN}}
> - {{SQL_ATTR_PARAM_BIND_OFFSET_PTR}}
> - {{SQL_ATTR_PARAM_BIND_TYPE}}
> - {{SQL_ATTR_PARAM_OPERATION_PTR}}
> - {{SQL_ATTR_PARAM_STATUS_PTR}}
> - {{SQL_ATTR_PARAMS_PROCESSED_PTR}}
> - {{SQL_ATTR_PARAMSET_SIZE}}
> - {{SQL_ATTR_ROW_ARRAY_SIZE}}
> - {{SQL_ATTR_ROW_BIND_OFFSET_PTR}}
> - {{SQL_ATTR_ROW_BIND_TYPE}}
> - {{SQL_ATTR_ROW_STATUS_PTR}}
> - {{SQL_ATTR_ROWS_FETCHED_PTR}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2807) IGFS: re-create lock relaxed version
[ https://issues.apache.org/jira/browse/IGNITE-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Veselovsky resolved IGNITE-2807. - Resolution: Duplicate > IGFS: re-create lock relaxed version > > > Key: IGNITE-2807 > URL: https://issues.apache.org/jira/browse/IGNITE-2807 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Ivan Veselovsky > Fix For: 1.6 > > > Earlier we had IGFS implementation that seemed to be fast, but was not > absolutely correct in terms of synchronization logic. As now we suspect some > problems with IGFS performance, we need to create such version of the > implementation again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2694) .NET: AnyCPU build
[ https://issues.apache.org/jira/browse/IGNITE-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191014#comment-15191014 ] Pavel Tupitsyn commented on IGNITE-2694: * AnyCPU added, x64 & x86 platforms removed from solution * common project is now being built with a pre-build event (because we need both platforms) * Examples and LINQPad samples fixed and tested * NuGet fixed and tested > .NET: AnyCPU build > -- > > Key: IGNITE-2694 > URL: https://issues.apache.org/jira/browse/IGNITE-2694 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Currently we provide separate x86 & x64 binaries. NuGet is x64-only. > This is inconvenient both for us and the user. > The only thing that prevents AnyCPU is unmanaged "common" project. > But we load it dynamically from resources, and we may as well detect current > process platform (x64 or not) and load a proper unmanaged resource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2759) Cache conflicts must honour "keepBinary" flag.
[
https://issues.apache.org/jira/browse/IGNITE-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2759.
---
> Cache conflicts must honour "keepBinary" flag.
> --
>
> Key: IGNITE-2759
> URL: https://issues.apache.org/jira/browse/IGNITE-2759
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Labels: community, customer, important
> Fix For: 1.6
>
>
> *Problem*
> {{GridCacheMapEntry}} deals with conflicts in some methods like {{innerSet}}.
> {{innerUpdate}}, etc.. When conflict occurs, we always deserialize
> keys/values what could lead to exceptions if there are no classes on the
> server.
> *Solution*
> Deserialize keys/values only if "keepBinary=false".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2694) .NET: AnyCPU build
[ https://issues.apache.org/jira/browse/IGNITE-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191014#comment-15191014 ] Pavel Tupitsyn edited comment on IGNITE-2694 at 3/11/16 2:45 PM: - * AnyCPU added, x64 & x86 platforms removed from solution * common project is now being built with a pre-build event (because we need both platforms) * Examples and LINQPad samples fixed and tested * NuGet fixed and tested * TC ok (temp config created) http://204.14.53.151/viewLog.html?buildId=207863 was (Author: ptupitsyn): * AnyCPU added, x64 & x86 platforms removed from solution * common project is now being built with a pre-build event (because we need both platforms) * Examples and LINQPad samples fixed and tested * NuGet fixed and tested > .NET: AnyCPU build > -- > > Key: IGNITE-2694 > URL: https://issues.apache.org/jira/browse/IGNITE-2694 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > Currently we provide separate x86 & x64 binaries. NuGet is x64-only. > This is inconvenient both for us and the user. > The only thing that prevents AnyCPU is unmanaged "common" project. > But we load it dynamically from resources, and we may as well detect current > process platform (x64 or not) and load a proper unmanaged resource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible.
[ https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191061#comment-15191061 ] Pavel Tupitsyn commented on IGNITE-2703: > we must understand whether it could be serialized through binary or not I can't imagine a case when a class CAN'T be serialized with reflective serializer, can you give an example? > to support backward compatibility we must be able to fallback to current > mode with help of some boolean flag. Do we need a flag? Can we just write all serializable classes in the old way, and use dynamic registration for non-serializable classes? > .NET: Dynamically registered classes must use binary serialization if > possible. > --- > > Key: IGNITE-2703 > URL: https://issues.apache.org/jira/browse/IGNITE-2703 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.6 > > > At present we support dynamic class registration in .NET, but they are > written using deafult .NET mechanism. This is counterintuitive for users and > not consistent with Java, where such classes are written in binary form. > Proposed implementation plan: > 1) For each dynamically registered class we must understand whether it could > be serialized through binary or not. If not - print a warning and fallback to > .NET. > 2) Before writing a class we must ensure that it's [typeId -> name] pair is > known to the cluster. If not - write full class name instead of type ID. Java > already do that. > 3) Last, to support backward compatibility we must be able to fallback to > current mode with help of some boolean flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2756) StreamVisitorExample returns empty result set
[
https://issues.apache.org/jira/browse/IGNITE-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasilisa Sidorova resolved IGNITE-2756.
Resolution: Fixed
> StreamVisitorExample returns empty result set
> -
>
> Key: IGNITE-2756
> URL: https://issues.apache.org/jira/browse/IGNITE-2756
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
>Reporter: Sergey Kozlov
>Assignee: Vasilisa Sidorova
>
> 1. Start {{ExampleNodeStartup}}
> 2. Start {{StreamVisitorExample}}
> {noformat}
> [15:31:22] Ignite node started OK (id=4395613e)
> [15:31:22] Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=7.1GB]
> Number of tuples streamed into Ignite: 50
> Number of tuples streamed into Ignite: 100
> ...
> Number of tuples streamed into Ignite: 950
> Number of tuples streamed into Ignite: 1000
> Top performing financial instruments:
> Query result set is empty.
> [15:31:47] Ignite node stopped OK [uptime=00:00:25:209]
> Process finished with exit code 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2404) TcpDiscoverySpi.setLocalPortRange set 0 doesn't work
[ https://issues.apache.org/jira/browse/IGNITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191072#comment-15191072 ] ASF GitHub Bot commented on IGNITE-2404: GitHub user ryanzz opened a pull request: https://github.com/apache/ignite/pull/549 IGNITE-2404 For TcpDiscoverySpi and TcpCommunicationSpi, if port range value is 0, then implementation will try bind only to the port provided by setLocalPort(int) method and fail if binding to this port did not succeed. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ryanzz/ignite ignite-2404 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/549.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #549 commit 7c6d33a49f8005d5dc66f10044efe8cfea9ad8be Author: Ryan Zhao Date: 2016-03-11T14:54:41Z fixed ignite-2404 > TcpDiscoverySpi.setLocalPortRange set 0 doesn't work > - > > Key: IGNITE-2404 > URL: https://issues.apache.org/jira/browse/IGNITE-2404 > Project: Ignite > Issue Type: Bug >Reporter: Denis Magda >Assignee: Ryan Zhao > Labels: community, newbie > > Local port range set to 0 presently doesn't work at least for > TcpCommunicationSpi and TcpDiscoverySpi. However SPIs support it. > In my understanding the condition has to changed to the following one (from < > to <=). > x = port; x <= port + range -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2796) NPE during rebalancing
[
https://issues.apache.org/jira/browse/IGNITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191180#comment-15191180
]
Anton Vinogradov commented on IGNITE-2796:
--
Val,
Could you please specify way of getting this exception?
> NPE during rebalancing
> --
>
> Key: IGNITE-2796
> URL: https://issues.apache.org/jira/browse/IGNITE-2796
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, customer, important
> Fix For: 1.6
>
>
> This exception sometimes appear in logs when topology changes under load:
> {noformat}
> 2016-03-06T08:07:52,500 ERROR [sys-#47%null%] (Slf4jLogger.java:112) - Failed
> processing message [senderId=ad2315fd-237c-492c-a1c6-7ea69c7f3807,
> msg=GridDhtPartitionSupplyMessageV2 [updateSeq=35,
> topVer=AffinityTopologyVersion [topVer=1413, minorTopVer=0], missed=null,
> msgSize=0, size=1, parts=[718], super=GridCacheMessage [msgId=52249,
> depInfo=null, err=null, skipPrepare=false, cacheId=1762189895,
> cacheId=1762189895]]]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:971)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1100(GridDhtPartitionDemander.java:751)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:600)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:407)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:80)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1085)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2236)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1003)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:972)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_51]
> {noformat}
> It doesn't seem to break anything, but still has to be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2807) IGFS: re-create lock relaxed version
[ https://issues.apache.org/jira/browse/IGNITE-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2807. --- > IGFS: re-create lock relaxed version > > > Key: IGNITE-2807 > URL: https://issues.apache.org/jira/browse/IGNITE-2807 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Ivan Veselovsky > Fix For: 1.6 > > > Earlier we had IGFS implementation that seemed to be fast, but was not > absolutely correct in terms of synchronization logic. As now we suspect some > problems with IGFS performance, we need to create such version of the > implementation again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2808) IGFS: re-create lock relaxed version
[ https://issues.apache.org/jira/browse/IGNITE-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2808. --- > IGFS: re-create lock relaxed version > > > Key: IGNITE-2808 > URL: https://issues.apache.org/jira/browse/IGNITE-2808 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Ivan Veselovsky > Fix For: 1.6 > > > Earlier we had IGFS implementation that seemed to be fast, but was not > absolutely correct in terms of synchronization logic. As now we suspect some > problems with IGFS performance, we need to create such version of the > implementation again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2809) Optimize IGFS performance.
Vladimir Ozerov created IGNITE-2809: --- Summary: Optimize IGFS performance. Key: IGNITE-2809 URL: https://issues.apache.org/jira/browse/IGNITE-2809 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Priority: Critical Fix For: 1.7 This is the umbrella ticket to host proposed IGFS performance improvements. Currently IGFS is struggling from some inefficiencies. It moves lots of unnecesary data over network. It has points of high contention - root and trash directories. It has less than efficient default cache properties, etc.. We need to take care about it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2810) IGFS: Stripe TRASH directory.
Vladimir Ozerov created IGNITE-2810:
---
Summary: IGFS: Stripe TRASH directory.
Key: IGNITE-2810
URL: https://issues.apache.org/jira/browse/IGNITE-2810
Project: Ignite
Issue Type: Task
Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Priority: Critical
Fix For: 1.7
*Problem*
Currently remove operation on IGFS performs soft-delete which essentially moves
a file/dir to a special hidden "TRASH" directory. Later on, special worker
inspects this directory and finally removes actual meta and data entities.
As *move* operation requires lock on parent directory, massive removes will
lead to high contention on TRASH key, yielding poor performance due to no
parallelization.
*Solution*
Let's stripe trash directory. That is, we will create several (e.g. 16) trash
directories. When entity is to be removed, we will pick random trash and move
entitty there.
Delete worker will have to inspect all these directories.
Note that each node will have to know maximum numbers of trash directories, so
it knows how to list it with little or no coordination with other nodes. To
achieve this we can expose "trashCount" property to
{{FileSystemConfiguration}}. Normally user will not change it. Each node will
set up a discovery listener which will track new nodes and will know maximum
amount of trashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2806) IGFS: re-create lock relaxed version
[ https://issues.apache.org/jira/browse/IGNITE-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191320#comment-15191320 ] Vladimir Ozerov commented on IGNITE-2806: - We should expose a boolean flag to configuration which will let user to choose consistency level - strict or relaxed. > IGFS: re-create lock relaxed version > > > Key: IGNITE-2806 > URL: https://issues.apache.org/jira/browse/IGNITE-2806 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Ivan Veselovsky > Fix For: 1.6 > > > Earlier we had IGFS implementation that seemed to be fast, but was not > absolutely correct in terms of synchronization logic. As now we suspect some > problems with IGFS performance, we need to create such version of the > implementation again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2806) IGFS: re-create lock relaxed version
[ https://issues.apache.org/jira/browse/IGNITE-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191324#comment-15191324 ] Vladimir Ozerov commented on IGNITE-2806: - Note that in future we will probably avaluate other ideas, e.g. use of ATOMIC cache. As such, it is worth considering use enum instead of boolean flag. On the other hand, we can use boolean flag for simplicity for now, and deprecate it in future if needed. > IGFS: re-create lock relaxed version > > > Key: IGNITE-2806 > URL: https://issues.apache.org/jira/browse/IGNITE-2806 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Ivan Veselovsky > Fix For: 1.6 > > > Earlier we had IGFS implementation that seemed to be fast, but was not > absolutely correct in terms of synchronization logic. As now we suspect some > problems with IGFS performance, we need to create such version of the > implementation again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2811) IGFS: Optimize properties handling.
Vladimir Ozerov created IGNITE-2811:
---
Summary: IGFS: Optimize properties handling.
Key: IGNITE-2811
URL: https://issues.apache.org/jira/browse/IGNITE-2811
Project: Ignite
Issue Type: Task
Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Fix For: 1.7
*Problem*
We have properties map which constantly duplicated over and over again inside
all {{IgfsFileInfo}} and {{IgfsListingEntry}}. This leads to substantial
network traffic and most of the time these properties are a kind of defaults.
*Porposed solution*
1) If properties are deafult, do not pass them directly, but pass a special
marker (e.g. boolean flag).
2) If well-known key is set (there ~3 such keys) pass only values without keys.
3) Investigate whether we need to store properties on {{IgfsListingEntry}}
level.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2812) IGFS: Some operations on DUAL file system could be passed directly to secondary fiel system.
Vladimir Ozerov created IGNITE-2812: --- Summary: IGFS: Some operations on DUAL file system could be passed directly to secondary fiel system. Key: IGNITE-2812 URL: https://issues.apache.org/jira/browse/IGNITE-2812 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Fix For: 1.7 *Problem* When working in DUAL mode, some operations delegate to secondary file system even if all necessary information is already in IGFS. Example: "list paths" operation. It has to consult to secondary file system because we are not sure that all existing entries exists in meta cache. As such, we always delegate to secondary file system. *Proposed solution* Probably we can route such operations directly to seconday FS without involving IGFS. This will save us several network trips. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2813) IGFS: Optimize metadata format.
Vladimir Ozerov created IGNITE-2813:
---
Summary: IGFS: Optimize metadata format.
Key: IGNITE-2813
URL: https://issues.apache.org/jira/browse/IGNITE-2813
Project: Ignite
Issue Type: Task
Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Fix For: 1.7
*Problem*
Currently our metadata appears to be too heavy.
Short summary of {{IgfsFIleInfo}}:
{{id}} - files and dirs
{{len}} - only files
{{blockSize}} - only files
{{props}} - files and dirs
{{lockId}} - only files
{{affKey}} - only files
{{fileMap}} - only files
{{accessTime}} - files and dirs
{{modificationTime}} - files and dirs
{{listing}} - only dirs
{{evictExclude}} - only files
The same applies to {{IgfsListingEntry}}
*Solution*
1) Split files and directories into separate classes. This will improve both
performance and maintainability of {{IgfsFileInfo}} class.
2) Investigate whether we need {{IgfsListingEntry}} at all. It looks like we
only need it for "listPaths" operation. Can we simply replace it with "String
-> IgniteUuid" map?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2814) IGFS: Optimize file meta update operations using entry processors.
Vladimir Ozerov created IGNITE-2814:
---
Summary: IGFS: Optimize file meta update operations using entry
processors.
Key: IGNITE-2814
URL: https://issues.apache.org/jira/browse/IGNITE-2814
Project: Ignite
Issue Type: Task
Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Priority: Critical
Fix For: 1.7
*Problem*
There are 3 operation types performed on files during write:
1) lock
2) unlock
3) length update
Some of there operations perform put/replace on cache to update meta. This is
less than efficient because we have to pass the file {{IgfsFileInfo}} which is
pretty heavy.
*Solution*
We must ensure that all these operations use light-weight entry processors
instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2815) IGFS: IgfsMetaManager.create() should not use "putIfAbsent" to create a file.
Vladimir Ozerov created IGNITE-2815: --- Summary: IGFS: IgfsMetaManager.create() should not use "putIfAbsent" to create a file. Key: IGNITE-2815 URL: https://issues.apache.org/jira/browse/IGNITE-2815 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Priority: Critical Fix For: 1.7 This is less than optimal approach. Instead, we should use entry processor which will accept file ID, block size and properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2816) IGFS: IgfsMetaManaget should not use "put" to update parent listing.
Vladimir Ozerov created IGNITE-2816: --- Summary: IGFS: IgfsMetaManaget should not use "put" to update parent listing. Key: IGNITE-2816 URL: https://issues.apache.org/jira/browse/IGNITE-2816 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Priority: Critical Fix For: 1.7 Lightweight entry processor must be used instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2817) IGFS: "update*" oeprations in IgfsMetaManager should not use "put" operations.
Vladimir Ozerov created IGNITE-2817:
---
Summary: IGFS: "update*" oeprations in IgfsMetaManager should not
use "put" operations.
Key: IGNITE-2817
URL: https://issues.apache.org/jira/browse/IGNITE-2817
Project: Ignite
Issue Type: Task
Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Priority: Critical
Fix For: 1.7
*Problem*
There are several "update*" methods in {{IgfsMetaManager}} which perform some
minor operations like properties or access time updates. And they use "put" or
"putIfAbsent" for this, which is less than optimal.
*Solution*
Use entry processors instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2818) IGFS: Ensure that "dual" operations use efficient entry processors.
Vladimir Ozerov created IGNITE-2818: --- Summary: IGFS: Ensure that "dual" operations use efficient entry processors. Key: IGNITE-2818 URL: https://issues.apache.org/jira/browse/IGNITE-2818 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Priority: Critical Fix For: 1.7 This should be done once all "put"s are replaced with entry processors for PRIMARY mode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2819) IGFS: Aggressively cache secondayr file systme metadata to minimize amount of direct FS calls.
Vladimir Ozerov created IGNITE-2819: --- Summary: IGFS: Aggressively cache secondayr file systme metadata to minimize amount of direct FS calls. Key: IGNITE-2819 URL: https://issues.apache.org/jira/browse/IGNITE-2819 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Priority: Critical Fix For: 1.7 We call secondary file system inside TXes too often to get some metadata. Instead, when we access any file/dir in DUAL mode for the first time, we should cache all available metadata from the secondary file system, so that subsequent calls do not require it any more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2758) IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar doesn't contain any classes
[
https://issues.apache.org/jira/browse/IGNITE-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasilisa Sidorova resolved IGNITE-2758.
Resolution: Fixed
> IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar doesn't contain any
> classes
>
>
> Key: IGNITE-2758
> URL: https://issues.apache.org/jira/browse/IGNITE-2758
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vasilisa Sidorova
>Priority: Blocker
> Labels: community, customer, important
> Fix For: 1.6
>
>
> To observe the issue do this:
> * Build the fabric ZIP file.
> * Go to {{ignite-aws}} module folder.
> * Unzip {{aws-java-sdk-1.10.29.jar}}.
> * JAR file contains only pom.xml, no classes.
> We need to make sure that all required AWS SDK components are included. At
> least we need these ones:
> * aws-java-sdk-core
> * aws-java-sdk-s3
> * joda-time
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2758) IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar doesn't contain any classes
[
https://issues.apache.org/jira/browse/IGNITE-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasilisa Sidorova closed IGNITE-2758.
--
Assignee: (was: Vasilisa Sidorova)
> IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar doesn't contain any
> classes
>
>
> Key: IGNITE-2758
> URL: https://issues.apache.org/jira/browse/IGNITE-2758
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Priority: Blocker
> Labels: community, customer, important
> Fix For: 1.6
>
>
> To observe the issue do this:
> * Build the fabric ZIP file.
> * Go to {{ignite-aws}} module folder.
> * Unzip {{aws-java-sdk-1.10.29.jar}}.
> * JAR file contains only pom.xml, no classes.
> We need to make sure that all required AWS SDK components are included. At
> least we need these ones:
> * aws-java-sdk-core
> * aws-java-sdk-s3
> * joda-time
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2756) StreamVisitorExample returns empty result set
[
https://issues.apache.org/jira/browse/IGNITE-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasilisa Sidorova closed IGNITE-2756.
--
Assignee: (was: Vasilisa Sidorova)
> StreamVisitorExample returns empty result set
> -
>
> Key: IGNITE-2756
> URL: https://issues.apache.org/jira/browse/IGNITE-2756
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
>Reporter: Sergey Kozlov
>
> 1. Start {{ExampleNodeStartup}}
> 2. Start {{StreamVisitorExample}}
> {noformat}
> [15:31:22] Ignite node started OK (id=4395613e)
> [15:31:22] Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=7.1GB]
> Number of tuples streamed into Ignite: 50
> Number of tuples streamed into Ignite: 100
> ...
> Number of tuples streamed into Ignite: 950
> Number of tuples streamed into Ignite: 1000
> Top performing financial instruments:
> Query result set is empty.
> [15:31:47] Ignite node stopped OK [uptime=00:00:25:209]
> Process finished with exit code 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2820) IGFS: Ensure that all participating IDs are locked right after TX start.
Vladimir Ozerov created IGNITE-2820: --- Summary: IGFS: Ensure that all participating IDs are locked right after TX start. Key: IGNITE-2820 URL: https://issues.apache.org/jira/browse/IGNITE-2820 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Priority: Critical Fix For: 1.7 *Problem* Sometimes we have to create new entries during some operation on metadata. If we do not lock this ID along with other participating IDs right after TX start, subsequent cache operation on this ID will result in network calls to block this key on other nodes. *Solution* Create potentially new key before entering TX and lock it with other keys. This should decrease number of network calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2796) NPE during rebalancing
[
https://issues.apache.org/jira/browse/IGNITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191420#comment-15191420
]
Valentin Kulichenko commented on IGNITE-2796:
-
Not really, I just saw this in the logs provided by user. All I know is that
there were 32 nodes started in parallel with around 20 caches.
It seems to me that this code is incorrect:
{code}
Collection parts = remaining.get(nodeId).get2();
if (parts != null) {
...
}
{code}
>From what I see, {{parts}} can never be null, but the map value can easily be.
>It actually looks like collection of integers was used as a map value and at
>some point was replaced with the tuple, but the check was not changed.
I may be missing something, of course.
> NPE during rebalancing
> --
>
> Key: IGNITE-2796
> URL: https://issues.apache.org/jira/browse/IGNITE-2796
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, customer, important
> Fix For: 1.6
>
>
> This exception sometimes appear in logs when topology changes under load:
> {noformat}
> 2016-03-06T08:07:52,500 ERROR [sys-#47%null%] (Slf4jLogger.java:112) - Failed
> processing message [senderId=ad2315fd-237c-492c-a1c6-7ea69c7f3807,
> msg=GridDhtPartitionSupplyMessageV2 [updateSeq=35,
> topVer=AffinityTopologyVersion [topVer=1413, minorTopVer=0], missed=null,
> msgSize=0, size=1, parts=[718], super=GridCacheMessage [msgId=52249,
> depInfo=null, err=null, skipPrepare=false, cacheId=1762189895,
> cacheId=1762189895]]]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:971)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1100(GridDhtPartitionDemander.java:751)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:600)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:407)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335)
> ~[ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:80)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1085)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2236)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1003)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:972)
> [ignite-core-1.5.5.jar:1.5.5]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_51]
> {noformat}
> It doesn't seem to break anything, but still has to be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2821) Design and implement keepBinary flag for IgniteRDD
Alexey Goncharuk created IGNITE-2821: Summary: Design and implement keepBinary flag for IgniteRDD Key: IGNITE-2821 URL: https://issues.apache.org/jira/browse/IGNITE-2821 Project: Ignite Issue Type: Bug Components: Ignite RDD Affects Versions: 1.5.0.final Reporter: Alexey Goncharuk Currently it is impossible to use BinaryObjects without class definitions in IgniteRDD because it impossible to set withKeepBinary flag, which leads to object deserialization attempt on each RDD access. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
