[jira] [Commented] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ
[
https://issues.apache.org/jira/browse/IGNITE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874177#comment-15874177
]
Maksim Kozlov commented on IGNITE-533:
--
Ok :) thanks review Roman.
> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-3481) Implement lazy query execution in H2.
[ https://issues.apache.org/jira/browse/IGNITE-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-3481: - Component/s: SQL > Implement lazy query execution in H2. > - > > Key: IGNITE-3481 > URL: https://issues.apache.org/jira/browse/IGNITE-3481 > Project: Ignite > Issue Type: Improvement > Components: SQL >Reporter: Sergi Vladykin > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4611) Write IgniteUuid with BinaryMarshaller
[
https://issues.apache.org/jira/browse/IGNITE-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874195#comment-15874195
]
Pavel Tupitsyn commented on IGNITE-4611:
Looks good, merged to {{ignite-2.0}}.
> Write IgniteUuid with BinaryMarshaller
> --
>
> Key: IGNITE-4611
> URL: https://issues.apache.org/jira/browse/IGNITE-4611
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> Currently {{IgniteUuid}} is written with {{OptimizedMarshaller}}
> (it is not included in {{BinaryContext.BINARYLIZABLE_SYS_CLSS}}).
> This prevents it from being read on other platforms (.NET, C++).
> Use {{BinaryMarshaller}} instead.
> Dev list thread:
> http://apache-ignite-developers.2346864.n4.nabble.com/Write-IgniteUuid-with-BinaryMarshaller-td13971.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4717) Cache size hangs on cache clear
[
https://issues.apache.org/jira/browse/IGNITE-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov reassigned IGNITE-4717:
--
Assignee: Andrey Novikov
> Cache size hangs on cache clear
> ---
>
> Key: IGNITE-4717
> URL: https://issues.apache.org/jira/browse/IGNITE-4717
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.9
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
> Fix For: 1.9
>
>
> * Run two nodes with load
> * Clear ten or more caches by sending VisorCacheClearTask at one moment
> * In thread dump I found locked threads in management pool
> {code}
> "mgmt-#78%tester%" Id=133 WAITING on
> org.apache.ignite.internal.ComputeTaskInternalFuture@23edc803
> at sun.misc.Unsafe.park(Native Method)
> - waiting on
> org.apache.ignite.internal.ComputeTaskInternalFuture@23edc803
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:161)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.size(GridCacheAdapter.java:3717)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-1264) Resource SPI
[ https://issues.apache.org/jira/browse/IGNITE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-1264: Assignee: Alexey Kuznetsov > Resource SPI > > > Key: IGNITE-1264 > URL: https://issues.apache.org/jira/browse/IGNITE-1264 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Andrey Kornev >Assignee: Alexey Kuznetsov > > As a user I'd like to be able to customize how resource injection is done by > Ignite: for example, I'd like to be able to process any custom annotations on > my application's class after its deserialization on a remote node. > Ideally, Ignite should expose an SPI that would be delegated to at specific > points of the dependency injection logic (as currently implemented in the > GridResourceProcessor class). > Once implemented, this feature would allow to make the injector support > pluggable: Spring, Guice, Dagger, whatever... Ultimately it'd be great to > replace all injection-related Ignite annotations by the standard javax.inject > API. > For references, here's the nabble thread: > http://apache-ignite-developers.2346864.n4.nabble.com/Resource-SPI-proposal-td2318.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4722) CacheRandomOperation benchmark: preloading as separate benchmarl with ability to load in a loop
Ksenia Rybakova created IGNITE-4722: --- Summary: CacheRandomOperation benchmark: preloading as separate benchmarl with ability to load in a loop Key: IGNITE-4722 URL: https://issues.apache.org/jira/browse/IGNITE-4722 Project: Ignite Issue Type: Improvement Components: yardstick Reporter: Ksenia Rybakova Fix For: 1.8 We need an ability to perform preloading (streaming) test for quite long time (2 hours or even more). Currently this might be done only by setting preloading amount parameter to some really big value. This requires lot of memory and many nodes in the cluster. This is not always possible due to hardware limits. Suggest moving preloading from CacheRandomOperation benchmark to a separate one and add ability to perform it in a loop during predefined time. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-817) [Test] Disabled tests of GridCacheOffHeapTest
[ https://issues.apache.org/jira/browse/IGNITE-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-817: Fix Version/s: 2.0 > [Test] Disabled tests of GridCacheOffHeapTest > - > > Key: IGNITE-817 > URL: https://issues.apache.org/jira/browse/IGNITE-817 > Project: Ignite > Issue Type: Bug > Components: yardstick >Reporter: Artem Shutak >Assignee: Alexander Menshikov > Labels: Muted_test > Fix For: 2.0 > > > GridCacheOffHeapTest had next disabled tests (they have to be fixed or > deleted): > - testOffHeapPartitionedPerformance > - testOffHeapPartitionedPerformanceMultithreaded > - testOffHeapReplicatedPerformance > - testOnHeapPartitionedPerformance > - testOnHeapPartitionedPerformanceMultithreaded > - testOnHeapReplicatedPerformance > - testOnHeapReplicatedPerformanceMultithreaded -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4577) Ensure that certain interface addresses can be excluded form node attributes
[
https://issues.apache.org/jira/browse/IGNITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874255#comment-15874255
]
Evgenii Zhuravlev commented on IGNITE-4577:
---
Added sorting for all interface addresses using information about virtual
interfaces
> Ensure that certain interface addresses can be excluded form node attributes
>
>
> Key: IGNITE-4577
> URL: https://issues.apache.org/jira/browse/IGNITE-4577
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Evgenii Zhuravlev
> Fix For: 2.0
>
>
> *Problem*
> Consider a case when node has some network interface which is not accessible
> from the outside (e.g. in Docker container). Ignite adds this address to
> attributes, which are shared with other nodes. Now if remote want to
> communicate with local node chances that he will try to establish connection
> with invalid address.
> In the worst case connection will be impossible. We use {{AddressResolver}}
> to handle this situation.
> However, it appears that {{AddressResolver}} cannot prevent certain address
> to appear in address list. As a result users may experience communication
> delays as we establish peer-to-peer connection in one thread, iterating over
> all available addresses.
> *Proposed solution*
> We need to examine what happens when address resolver is set. May be it is
> necessary to rethink how we handle returned object. E.g. {{null}} or empty
> collection might mean that this address should not be included into the list
> of address. However, it may break existing applications, so chances that
> other solution is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4577) Ensure that certain interface addresses can be excluded form node attributes
[
https://issues.apache.org/jira/browse/IGNITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874255#comment-15874255
]
Evgenii Zhuravlev edited comment on IGNITE-4577 at 2/20/17 9:32 AM:
Added sorting for all interface addresses using information about virtual
interfaces
was (Author: ezhuravl):
Added sorting for all interface addresses using information about virtual
interfaces
> Ensure that certain interface addresses can be excluded form node attributes
>
>
> Key: IGNITE-4577
> URL: https://issues.apache.org/jira/browse/IGNITE-4577
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Evgenii Zhuravlev
> Fix For: 2.0
>
>
> *Problem*
> Consider a case when node has some network interface which is not accessible
> from the outside (e.g. in Docker container). Ignite adds this address to
> attributes, which are shared with other nodes. Now if remote want to
> communicate with local node chances that he will try to establish connection
> with invalid address.
> In the worst case connection will be impossible. We use {{AddressResolver}}
> to handle this situation.
> However, it appears that {{AddressResolver}} cannot prevent certain address
> to appear in address list. As a result users may experience communication
> delays as we establish peer-to-peer connection in one thread, iterating over
> all available addresses.
> *Proposed solution*
> We need to examine what happens when address resolver is set. May be it is
> necessary to rethink how we handle returned object. E.g. {{null}} or empty
> collection might mean that this address should not be included into the list
> of address. However, it may break existing applications, so chances that
> other solution is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IGNITE-4481) Creating the scripts
[ https://issues.apache.org/jira/browse/IGNITE-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ostanin resolved IGNITE-4481. -- Resolution: Fixed Fix Version/s: (was: 2.0) 1.9 > Creating the scripts > > > Key: IGNITE-4481 > URL: https://issues.apache.org/jira/browse/IGNITE-4481 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin > Fix For: 1.9 > > > The goal of this subtask is to resolve this part of original task: > 1. Every deliverable must contain an executable (bat or sh file) with a clear > instruction on how to start a specific benchmark from the console. > 2. For local runs (drivers and servers point out on localhost) ssh connection > must not be used -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-4478) Fixing documentation and resolving lack of usability
[ https://issues.apache.org/jira/browse/IGNITE-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ostanin resolved IGNITE-4478. -- Resolution: Fixed Fix Version/s: (was: 2.0) 1.9 > Fixing documentation and resolving lack of usability > > > Key: IGNITE-4478 > URL: https://issues.apache.org/jira/browse/IGNITE-4478 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin > Fix For: 1.9 > > > 1. Change old version of README.txt. > 2. Add DEVNOTES.txt to the Ignite-Yardstick source files. > 3. Add sample configuration file to benchmarks/config to add availability to > run something out of the box. > 4. Change Yardstick framework version to run benchmarks without ssh connect > to localhost -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-4482) Setting up the configuration
[ https://issues.apache.org/jira/browse/IGNITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ostanin resolved IGNITE-4482. -- Resolution: Fixed Fix Version/s: (was: 2.0) 1.9 > Setting up the configuration > > > Key: IGNITE-4482 > URL: https://issues.apache.org/jira/browse/IGNITE-4482 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin > Fix For: 1.9 > > > The goal of this subtask is to resolve the last part of original task: > The executable has to use some default yardstick configuration. The first > configuration should be intented for local execution (multicast IP finder) > and the second needs to be AWS oriented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-4212) Ignite Benchmarking Simplification and Automation
[ https://issues.apache.org/jira/browse/IGNITE-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ostanin resolved IGNITE-4212. -- Resolution: Fixed > Ignite Benchmarking Simplification and Automation > - > > Key: IGNITE-4212 > URL: https://issues.apache.org/jira/browse/IGNITE-4212 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Oleg Ostanin > Fix For: 1.9 > > Attachments: benchmark-remote.properties, > benchmark-remote-sample.properties, DEVNOTES.txt, ignite-remote-config.xml, > README.txt > > > There is a plenty of useful Yardstick benchmarks located in ignite-yardstick > module that is used by the community to check Ignite performance across > deployments of different configurations. > However, it's not easy to start with the benchmarking process because the > user needs to download Ignite, build and set up benchmarks and only after > that run them. > The goal of this task is to simplify the process in the following way: > 1) ignite-yardstick benchmarks have to be pre-compiled and available with > every Ignite deliverable. > 2) every deliverable must contain an executable (bat or sh file) with a clear > instruction on how to start a specific benchmark from the console. > 3) the executable has to use some default yardstick configuration. The first > configuration should be intented for local execution (multicast IP finder) > and the second needs to be AWS oriented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4723) .NET: Support REGEXP_LIKE in LINQ
Pavel Tupitsyn created IGNITE-4723:
--
Summary: .NET: Support REGEXP_LIKE in LINQ
Key: IGNITE-4723
URL: https://issues.apache.org/jira/browse/IGNITE-4723
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Fix For: 2.0
{{REGEXP_REPLACE}} H2 function is supported in LINQ via {{Regex.Replace}}, see
{{MethodVisitor}}.
Add mapping for {{REGEXP_LIKE}} via {{Regex.IsMatch}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-817) [Test] Disabled tests of GridCacheOffHeapTest
[ https://issues.apache.org/jira/browse/IGNITE-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874283#comment-15874283 ] Anton Vinogradov commented on IGNITE-817: - [~sharpler], Changes merged to master, Thanks for contribution! > [Test] Disabled tests of GridCacheOffHeapTest > - > > Key: IGNITE-817 > URL: https://issues.apache.org/jira/browse/IGNITE-817 > Project: Ignite > Issue Type: Bug > Components: yardstick >Reporter: Artem Shutak >Assignee: Alexander Menshikov > Labels: Muted_test > Fix For: 2.0 > > > GridCacheOffHeapTest had next disabled tests (they have to be fixed or > deleted): > - testOffHeapPartitionedPerformance > - testOffHeapPartitionedPerformanceMultithreaded > - testOffHeapReplicatedPerformance > - testOnHeapPartitionedPerformance > - testOnHeapPartitionedPerformanceMultithreaded > - testOnHeapReplicatedPerformance > - testOnHeapReplicatedPerformanceMultithreaded -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4724) AVG function always returns double type instead of the argument type
Sergey Kozlov created IGNITE-4724: - Summary: AVG function always returns double type instead of the argument type Key: IGNITE-4724 URL: https://issues.apache.org/jira/browse/IGNITE-4724 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.9 Reporter: Sergey Kozlov Fix For: 1.9 For H2: SELECT AVG(intCol) FROM cache_part_2 AS part_2 WHERE (10*shortCol/100) > longCol -[472] For Ignite: SELECT AVG(intCol) FROM AllTypes AS part_2 WHERE (10*shortCol/100) > longCol +[472.2307692307692] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-4169) Data streamer mode for DML
[ https://issues.apache.org/jira/browse/IGNITE-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4169. - Resolution: Fixed > Data streamer mode for DML > -- > > Key: IGNITE-4169 > URL: https://issues.apache.org/jira/browse/IGNITE-4169 > Project: Ignite > Issue Type: New Feature > Components: SQL >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Assignee: Alexander Paschenko > Fix For: 1.9 > > > SQL INSERT and MERGE are supposed to support data streamer mode which should > be turned on by JDBC connection string param. > Note: particular details of usage means and implementation of this mode, as > well as urgency of this feature are yet to be discussed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4725) Document streaming mode for JDBC driver
Vladimir Ozerov created IGNITE-4725:
---
Summary: Document streaming mode for JDBC driver
Key: IGNITE-4725
URL: https://issues.apache.org/jira/browse/IGNITE-4725
Project: Ignite
Issue Type: Task
Components: documentation, SQL
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 1.9
SQL streaming was added to {{AI 1.9}}. We need to document it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4619) .NET: TransactionScope documentation and example
[
https://issues.apache.org/jira/browse/IGNITE-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4619:
Component/s: documentation
> .NET: TransactionScope documentation and example
>
>
> Key: IGNITE-4619
> URL: https://issues.apache.org/jira/browse/IGNITE-4619
> Project: Ignite
> Issue Type: Task
> Components: documentation, platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Prachi Garg
> Labels: .NET
> Fix For: 1.9
>
>
> Create documentation and example for {{TransactionScope}} support
> (IGNITE-3430).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4724) AVG function always returns double type instead of the argument type
[ https://issues.apache.org/jira/browse/IGNITE-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4724: Fix Version/s: (was: 1.9) 2.0 > AVG function always returns double type instead of the argument type > > > Key: IGNITE-4724 > URL: https://issues.apache.org/jira/browse/IGNITE-4724 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.9 >Reporter: Sergey Kozlov > Fix For: 2.0 > > > For H2: > SELECT AVG(intCol) FROM cache_part_2 AS part_2 WHERE (10*shortCol/100) > > longCol > -[472] > For Ignite: > SELECT AVG(intCol) FROM AllTypes AS part_2 WHERE (10*shortCol/100) > longCol > +[472.2307692307692] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4724) AVG function always returns double type instead of the argument type
[ https://issues.apache.org/jira/browse/IGNITE-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874335#comment-15874335 ] Vladimir Ozerov commented on IGNITE-4724: - Moved to AI 2.0 because it is old problem, doesn't fit to 1.9 schedule. > AVG function always returns double type instead of the argument type > > > Key: IGNITE-4724 > URL: https://issues.apache.org/jira/browse/IGNITE-4724 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.9 >Reporter: Sergey Kozlov > Fix For: 2.0 > > > For H2: > SELECT AVG(intCol) FROM cache_part_2 AS part_2 WHERE (10*shortCol/100) > > longCol > -[472] > For Ignite: > SELECT AVG(intCol) FROM AllTypes AS part_2 WHERE (10*shortCol/100) > longCol > +[472.2307692307692] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (IGNITE-3429) org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller
[
https://issues.apache.org/jira/browse/IGNITE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reopened IGNITE-3429:
--
> org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller
> -
>
> Key: IGNITE-3429
> URL: https://issues.apache.org/jira/browse/IGNITE-3429
> Project: Ignite
> Issue Type: Bug
> Components: cache, Hibernate L2 cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 1.9
>
>
> {{org.hibernate.cache.spi.CacheKey}} is a class used as a key for all entries
> in the Hibernate L2 cache. This class contains {{type}} field and custom
> {{equals}} logic where the type is used as a helper and does not participate
> in comparison. Instances of the same type are producing different hash codes
> in different JVMs, which actually breaks comparison when binary format is
> used, where byte arrays are compared.
> The issue is described in more detail here:
> http://stackoverflow.com/questions/38132263/apache-ignite-as-hibernate-l2-cache-storing-duplicate-entities
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-3422) No way to control object initialization during deserialization/unmarshalling
[
https://issues.apache.org/jira/browse/IGNITE-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874371#comment-15874371
]
Vladimir Ozerov commented on IGNITE-3422:
-
[~daradurvs],
Is it correct that special constructor will be called only in case object
implements {{Binarylizable}} interface? This logic looks over-restricted to me,
because in order to properly initialize {{final}} fields user will have to
implement {{readBinary}} and {{writeBinary}} methods, what looks strange as you
will have to write two routines - constructor and {{writeBinary}}.
All in all, we have a kind of consistency problem here. In .NET custom write is
implemented as separate method, while read is implemented as special
constructor. In Java we follow {{Externalizable}} ideas where both read and
write happen in separate methods. If we add another constructor which also
perform reads, then we will split read logic between two methods - {{ctor}} and
{{readBinary}}. This looks overcomplicated to me. Moreover, this doesn't fit
well to {{BinarySerializer}} interface.
[~dmagda],
Do you really think we need this? Honestly, I've never see any serious demand
for this feature from user side.
> No way to control object initialization during deserialization/unmarshalling
> -
>
> Key: IGNITE-3422
> URL: https://issues.apache.org/jira/browse/IGNITE-3422
> Project: Ignite
> Issue Type: Improvement
> Components: binary, general
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Vyacheslav Daradur
>
> Presently there is no way to control instantiation of a {{BinaryObject}} that
> is being deserialized. The object is created using
> {{BinaryClassDescriptor#newInstance}} all the time.
> It makes sense to add {{BinaryConfiguration.setInitializationFactory()}}
> method that will provide with such support.
> Use case and details are provided in this discussion
> http://apache-ignite-users.70518.x6.nabble.com/Properly-Immutable-Keys-values-with-Binary-objects-tp6082.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-3422) No way to control object initialization during deserialization/unmarshalling
[
https://issues.apache.org/jira/browse/IGNITE-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3422:
Fix Version/s: 2.0
> No way to control object initialization during deserialization/unmarshalling
> -
>
> Key: IGNITE-3422
> URL: https://issues.apache.org/jira/browse/IGNITE-3422
> Project: Ignite
> Issue Type: Improvement
> Components: binary, general
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> Presently there is no way to control instantiation of a {{BinaryObject}} that
> is being deserialized. The object is created using
> {{BinaryClassDescriptor#newInstance}} all the time.
> It makes sense to add {{BinaryConfiguration.setInitializationFactory()}}
> method that will provide with such support.
> Use case and details are provided in this discussion
> http://apache-ignite-users.70518.x6.nabble.com/Properly-Immutable-Keys-values-with-Binary-objects-tp6082.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4409) UUID fields of the key class deserialized in a wrong way on INSERT.
[
https://issues.apache.org/jira/browse/IGNITE-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874384#comment-15874384
]
ASF GitHub Bot commented on IGNITE-4409:
GitHub user alexpaschenko opened a pull request:
https://github.com/apache/ignite/pull/1554
IGNITE-4409 UUID literals handling.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4409
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/1554.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 #1554
commit 3fd684390016483cd67af5f3b05b477b8fdf540a
Author: Alexander Paschenko
Date: 2017-02-20T11:07:12Z
IGNITE-4409 UUID literals handling.
> UUID fields of the key class deserialized in a wrong way on INSERT.
> ---
>
> Key: IGNITE-4409
> URL: https://issues.apache.org/jira/browse/IGNITE-4409
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Consider the following case. There is a class which is used as Key on C++
> side. It contains 3 fields: String, Timestamp and UUID. There is also a value
> of the type Integer. Record of the cache is being inserted with
> {{SqlFieldsQuery}}:
> {noformat}
> INSERT INTO Integer (str, ts, guid, _val) VALUES (?, ?, ?, ?)
> {noformat}
> String, Timestamp and Integer values serialized and desirialized just fine,
> but UUID value is passed further just like byte array of 17 bytes, first of
> which is 10 (UUID type header in Binary format), so later it gets converted
> here:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at org.h2.value.ValueUuid.get(ValueUuid.java:68)
> at org.h2.value.Value.convertTo(Value.java:861)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.convert(DmlStatementsProcessor.java:637)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:868)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:745)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:286)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:159)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:189)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1266)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:812)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1777)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:749)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1205)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:837)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractTarget.inStreamOutObject(PlatformAbstractTarget.java:90)
> {noformat}
> Obviously enough, it gets deserialized wrong because of the header byte and
> as a result, we get wrong key instance in the cache.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874409#comment-15874409 ] ASF GitHub Bot commented on IGNITE-4157: Github user sergey-chugunov-1985 closed the pull request at: https://github.com/apache/ignite/pull/1447 > Use discovery custom messages instead of marshaller cache > - > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4726) SQL: benchmark DML operations
Vladimir Ozerov created IGNITE-4726:
---
Summary: SQL: benchmark DML operations
Key: IGNITE-4726
URL: https://issues.apache.org/jira/browse/IGNITE-4726
Project: Ignite
Issue Type: Task
Components: SQL
Reporter: Vladimir Ozerov
Fix For: 2.0
We need to create benchmarks for DML operations similar to our cache benchmarks
and compare common cases. Results of cache API benchmarks can be used as
baseline for us.
Preliminray list of benchmarks:
1) INSERT + DELETE (vs {{IgniteCache.put}} + {{IgniteCache.remove}})
2) Simple MERGE (vs {{IgniteCache.put}})
3) Simple UPDATE (vs {{IgniteCache.invoke}})
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (IGNITE-4717) Cache size hangs on cache clear
[
https://issues.apache.org/jira/browse/IGNITE-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov closed IGNITE-4717.
--
> Cache size hangs on cache clear
> ---
>
> Key: IGNITE-4717
> URL: https://issues.apache.org/jira/browse/IGNITE-4717
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.9
>Reporter: Andrey Novikov
> Fix For: 1.9
>
>
> * Run two nodes with load
> * Clear ten or more caches by sending VisorCacheClearTask at one moment
> * In thread dump I found locked threads in management pool
> {code}
> "mgmt-#78%tester%" Id=133 WAITING on
> org.apache.ignite.internal.ComputeTaskInternalFuture@23edc803
> at sun.misc.Unsafe.park(Native Method)
> - waiting on
> org.apache.ignite.internal.ComputeTaskInternalFuture@23edc803
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:161)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.size(GridCacheAdapter.java:3717)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller
[
https://issues.apache.org/jira/browse/IGNITE-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874419#comment-15874419
]
Vladimir Ozerov commented on IGNITE-4645:
-
[~gvvinblade],
We still have additional lookup on the hot path - if object is not of fixed
size, you call {{writer.marshal(obj)}}, what will lead to the second lookup of
the same descriptor.
> Best effort to avoid extra copying in binary marshaller
> ---
>
> Key: IGNITE-4645
> URL: https://issues.apache.org/jira/browse/IGNITE-4645
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 1.9
>
>
> If we marshal a class that contain only primitives then we can predict the
> final byte array size and avoid copies to grow array and final trimming.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4695) Write primitive fields before during binary object marshalling
[ https://issues.apache.org/jira/browse/IGNITE-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4695: Fix Version/s: 2.0 > Write primitive fields before during binary object marshalling > -- > > Key: IGNITE-4695 > URL: https://issues.apache.org/jira/browse/IGNITE-4695 > Project: Ignite > Issue Type: Improvement > Components: binary >Reporter: Igor Seliverstov > Fix For: 2.0 > > > Now serializing objects we sort fields on the basis of their names. To prvide > better performance it makes sense to change this behavior. > The main idea to provide an ability of streaming deserialization putting > primitive fields at the start of the result array in fixed order at the > serialization time. > This way everything what we need to deserialize the object is just read its > fields in the same order without getting their positions from footer. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4645: Fix Version/s: (was: 1.9) 2.0 > Best effort to avoid extra copying in binary marshaller > --- > > Key: IGNITE-4645 > URL: https://issues.apache.org/jira/browse/IGNITE-4645 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Yakov Zhdanov >Assignee: Igor Seliverstov > Fix For: 2.0 > > > If we marshal a class that contain only primitives then we can predict the > final byte array size and avoid copies to grow array and final trimming. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874421#comment-15874421 ] Vladimir Ozerov commented on IGNITE-4645: - Moved to 2.0 as it doesn't fit 1.9 schedule. > Best effort to avoid extra copying in binary marshaller > --- > > Key: IGNITE-4645 > URL: https://issues.apache.org/jira/browse/IGNITE-4645 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Yakov Zhdanov >Assignee: Igor Seliverstov > Fix For: 2.0 > > > If we marshal a class that contain only primitives then we can predict the > final byte array size and avoid copies to grow array and final trimming. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-2160) Ignition.start() is blocked if there are no server nodes
[
https://issues.apache.org/jira/browse/IGNITE-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874422#comment-15874422
]
Vladimir Ozerov commented on IGNITE-2160:
-
[~vkulichenko], got it, agree.
> 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
> Fix For: 2.0
>
>
> 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.15#6346)
[jira] [Commented] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874436#comment-15874436
]
Vladimir Ozerov commented on IGNITE-2422:
-
[~dreamx], I am not sure if the fix is correct. Passing either
{{BinaryObject[]}} or {{BinaryObjectBuilder[]}} to builder should be
semantically equal to passing {{Object[]}} to normal object. As you set
component type ID to {{BInaryObject}} I suspect we will not be able to
deserialize root object correctly.
Let's add more tests ensuring that object can be deserialized into it's
original form after setting {{BinaryObjectBuilder[]}} to one of it's fields.
> Unable to deserialize BinaryObjectBuilder
> -
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
> Labels: important
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead
> to the errors at deserialization stage.
> After a brief investigation I see that this happens because neither
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}
> presents in {{META-INF/classnames.properties}} file.
> If you try to update
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by
> building the project from scratch and copying-pasting generated content from
> built {{classnames.properties}}, then you will still see that there are still
> no entries for {{org.apache.ignite.binary.BinaryObjectBuilder}} nor
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes
> by some reason.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874439#comment-15874439 ] Vyacheslav Daradur commented on IGNITE-4211: Hello [~rmohta]. Do you do this task? > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Rohit Mohta > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-4211: --- Comment: was deleted (was: Hello [~rmohta]. Do you do this task?) > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Rohit Mohta > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-3987) ODBC: Improve error output when query parsing failed.
[ https://issues.apache.org/jira/browse/IGNITE-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874523#comment-15874523 ] Igor Sapego commented on IGNITE-3987: - [~vozerov], I added blocking Java ticket. > ODBC: Improve error output when query parsing failed. > - > > Key: IGNITE-3987 > URL: https://issues.apache.org/jira/browse/IGNITE-3987 > Project: Ignite > Issue Type: Task > Components: odbc >Affects Versions: 1.7 >Reporter: Vladimir Ozerov >Assignee: Igor Sapego >Priority: Minor > Fix For: 2.0 > > > Currently if an error occurred we only prints the top-level message, like > "Failed to parse query ...". The problem is that we do not explain users why > exactly it failed. > Looks like we need to add more info on Java side when sending error response. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows
Vica Abramova created IGNITE-4727: - Summary: Web Console: Fix the position of tooltips in modal windows Key: IGNITE-4727 URL: https://issues.apache.org/jira/browse/IGNITE-4727 Project: Ignite Issue Type: Bug Components: UI, wizards Reporter: Vica Abramova Tooltips (in modal windows) should not go beyond the modal windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows
[ https://issues.apache.org/jira/browse/IGNITE-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vica Abramova updated IGNITE-4727: -- Priority: Minor (was: Major) > Web Console: Fix the position of tooltips in modal windows > -- > > Key: IGNITE-4727 > URL: https://issues.apache.org/jira/browse/IGNITE-4727 > Project: Ignite > Issue Type: Bug > Components: UI, wizards >Reporter: Vica Abramova >Priority: Minor > Attachments: tooltips.png > > > Tooltips (in modal windows) should not go beyond the modal windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows
[ https://issues.apache.org/jira/browse/IGNITE-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vica Abramova updated IGNITE-4727: -- Attachment: tooltips.png > Web Console: Fix the position of tooltips in modal windows > -- > > Key: IGNITE-4727 > URL: https://issues.apache.org/jira/browse/IGNITE-4727 > Project: Ignite > Issue Type: Bug > Components: UI, wizards >Reporter: Vica Abramova > Attachments: tooltips.png > > > Tooltips (in modal windows) should not go beyond the modal windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ
[
https://issues.apache.org/jira/browse/IGNITE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874557#comment-15874557
]
Maksim Kozlov commented on IGNITE-533:
--
[~roman_s] all fixed.
> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-4728) Web Console: Remember the screen from which user has left the previous session.
Vica Abramova created IGNITE-4728: - Summary: Web Console: Remember the screen from which user has left the previous session. Key: IGNITE-4728 URL: https://issues.apache.org/jira/browse/IGNITE-4728 Project: Ignite Issue Type: Task Components: UI, wizards Reporter: Vica Abramova -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-1624) [Test failed] Ignite SPI: TcpClientDiscoverySpiSelfTest.testJoinError failed
[
https://issues.apache.org/jira/browse/IGNITE-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874605#comment-15874605
]
Alexander Menshikov commented on IGNITE-1624:
-
I try to fix test. But can't reproduce problem. I added reps in a loop and ran
test local 10 minutes. There aren't problem. After that I set 1500 reps and ran
on CI (my local machine can do 1900 reps in 5 minutes) and got timeout, but not
the origin problem from issue.
Anyone have any ideas on how to reproduce the problem?
> [Test failed] Ignite SPI: TcpClientDiscoverySpiSelfTest.testJoinError failed
> -
>
> Key: IGNITE-1624
> URL: https://issues.apache.org/jira/browse/IGNITE-1624
> Project: Ignite
> Issue Type: Test
>Reporter: Andrey Gura
>Assignee: Alexander Menshikov
>Priority: Critical
> Labels: Muted_test
> Fix For: 2.0
>
>
> The following test periodically fail on TC:
> * {{TcpClientDiscoverySpiSelfTest.testJoinError}}
> * {{TcpClientDiscoverySpiFailureTimeoutSelfTest.testJoinError}}
> {noformat}
> [18:07:52,332][ERROR][test-runner][IgniteKernal%client-0] Got exception while
> starting (will rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1488)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:908)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:526)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:724)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:708)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.startClientNodes(TcpClientDiscoverySpiSelfTest.java:1850)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testJoinError(TcpClientDiscoverySpiSelfTest.java:1085)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1665)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:111)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1603)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000,
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false,
> clientReconnectDisabled=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:666)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1485)
> ... 17 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Join process timed
> out, did not receive response for join request (consider increasing
> 'joinTimeout' configuration property) [joinTimeout=8000,
> sock=Socket[addr=/127.0.0.1,port=47500,localport=43551]]
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1324)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [18:07:52,357][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1488)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:908)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
> at org.apache.i
[jira] [Commented] (IGNITE-3469) Get rid of deprecated APIs and entities
[
https://issues.apache.org/jira/browse/IGNITE-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874652#comment-15874652
]
Taras Ledkov commented on IGNITE-3469:
--
The list of the deprecated class / methods / properties:
- two methods {{IgniteCluster.mapKeyToNode}} - the removing is simple because
its are used rare;
- {{IgniteCache.randomEntry}} - the removing is simple because it is used rare;
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- {{CacheTypeMetadata}};
- Classes related with {{AffinityNodeHashResolver}};
- Backup filters for affinity functions;
- {{RandomEvictionPolicy}};
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {{transactionManagerLookupClassName}} and
{rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{FileSystemConfiguration}} properties:
-- {{fragmentizerLocalWritesRatio}};
-- {{trashPurgeTimeout}};
-- {{dualModePutExecutorService}};
-- {{dualModePutExecutorServiceShutdown}};
-- {{dualModeMaxPendingPutsSize}};
- {{IgniteConfiguration}} properties:
-- {{nodeId}};
-- {{DFLT_PUBLIC_KEEP_ALIVE_TIME}};
-- {{DFLT_PUBLIC_THREADPOOL_QUEUE_CAP}};
-- {{DFLT_SYSTEM_MAX_THREAD_CNT}};
-- {{DFLT_SYSTEM_KEEP_ALIVE_TIME}};
-- {{DFLT_UTILITY_KEEP_ALIVE_TIME}};
-- {{DFLT_SYSTEM_THREADPOOL_QUEUE_CAP}};
- {{TransactionConfiguration}} properties:
-- {{txSerializableEnabled}};
-- {{txManagerLookupClassName}};
- Several methods at the {{IgfsPath}} class: empty constructor, {{root()}} and
{{isSame}} methods;
-
> Get rid of deprecated APIs and entities
> ---
>
> Key: IGNITE-3469
> URL: https://issues.apache.org/jira/browse/IGNITE-3469
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Goncharuk
> Labels: important
> Fix For: 2.0
>
>
> There are more than 220 deprecated elements in Ignite code kept for the sake
> of backward compatibility. We need to cleanup the code for Ignite 2.0 release.
> 2.0 migration guide has to be updated if needed:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4501) Improvement of connection in a cluster of new node
[
https://issues.apache.org/jira/browse/IGNITE-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874651#comment-15874651
]
Yakov Zhdanov commented on IGNITE-4501:
---
Alexander, I reviewed the changes. Please see my comments on github PR.
I think it is safe to release it in 2.0.
Thanks!
> Improvement of connection in a cluster of new node
> --
>
> Key: IGNITE-4501
> URL: https://issues.apache.org/jira/browse/IGNITE-4501
> Project: Ignite
> Issue Type: Improvement
> Components: messaging
>Affects Versions: 1.8
>Reporter: Vyacheslav Daradur
>Assignee: Alexander Menshikov
> Fix For: 2.0
>
>
> h3. Main description:
> Cluster nodes connect a ring.
> For example: we have 6 nodes: A, B, C, D, E, F.
> They can connect a ring in any possible way: A-B-C-D-E-F-A, or A-F-B-E-C-D-A,
> etc.
> If some node leaves topology, adjacent nodes must reconnect.
> If nodes A, B, C are in same physical place, nodes D, E, F are in other
> place, and places lost connect each other, we will have many ways of
> reconnections.
> At best case, if we had a ring: A-B-CxD-E-FxA ('x' means disconnect) -- then
> we have only one reconnect (C
> will be connected to A or F will be connected to D -- depends on what part of
> the cluster was alive.
> Also, if we had a not ring: AxFxBxExCxDxA -- then we have a lot of
> reconnections (A to B, B to C, C to A -- in general n/2 reconnections, where
> n -- number of nodes).
> h3. Approach:
> It is necessary to develop approach of node insertion to the correct place
> for creation of the correct ring-topology.
> h3. Solutions:
> Main idea is a sorting according to latency.
> * group nodes in arcs on an ARC_ID. (manualy?)
> * implement NodeComparator (nodes on the same host : nodes on the same subnet
> : other nodes). We will use it when we connect a new node.
> * [dev list
> thread|http://mail-archives.apache.org/mod_mbox/ignite-dev/201612.mbox/%3CCAN+WSNyWYXSXEBpGErVt72zTgi2pTQzUWLv8JY=ke83-5-r...@mail.gmail.com%3E]
> Update Dec, 29 Yakov Zhdanov:
> # introduce CLUSTER_REGION_ID node attribute. This can be done by adding
> public static final constant to TcpDiscoverySpi.
> # Alter
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing#nextNode(java.util.Collection)
> to order basing on per node attribute value
> # Node comparison should be stable and consistent. E.g. if CLUSTER_REGION_IDs
> are equal then we should compare nodes' IDs. This way we have consistent
> order on all nodes in topology.
> # Also nextNode() has to group nodes on same host and in same subnet. This
> can be postponed and implemented after we have other points done.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IGNITE-4409) UUID fields of the key class deserialized in a wrong way on INSERT.
[
https://issues.apache.org/jira/browse/IGNITE-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-4409.
-
Resolution: Fixed
> UUID fields of the key class deserialized in a wrong way on INSERT.
> ---
>
> Key: IGNITE-4409
> URL: https://issues.apache.org/jira/browse/IGNITE-4409
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Consider the following case. There is a class which is used as Key on C++
> side. It contains 3 fields: String, Timestamp and UUID. There is also a value
> of the type Integer. Record of the cache is being inserted with
> {{SqlFieldsQuery}}:
> {noformat}
> INSERT INTO Integer (str, ts, guid, _val) VALUES (?, ?, ?, ?)
> {noformat}
> String, Timestamp and Integer values serialized and desirialized just fine,
> but UUID value is passed further just like byte array of 17 bytes, first of
> which is 10 (UUID type header in Binary format), so later it gets converted
> here:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at org.h2.value.ValueUuid.get(ValueUuid.java:68)
> at org.h2.value.Value.convertTo(Value.java:861)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.convert(DmlStatementsProcessor.java:637)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.rowToKeyValue(DmlStatementsProcessor.java:868)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:745)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:286)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:159)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:189)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1266)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:812)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1777)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:749)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1205)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:837)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractTarget.inStreamOutObject(PlatformAbstractTarget.java:90)
> {noformat}
> Obviously enough, it gets deserialized wrong because of the header byte and
> as a result, we get wrong key instance in the cache.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4635) Implement single-threaded DDL worker
[ https://issues.apache.org/jira/browse/IGNITE-4635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Paschenko reassigned IGNITE-4635: --- Assignee: Alexander Paschenko > Implement single-threaded DDL worker > > > Key: IGNITE-4635 > URL: https://issues.apache.org/jira/browse/IGNITE-4635 > Project: Ignite > Issue Type: Sub-task > Components: SQL >Reporter: Vladimir Ozerov >Assignee: Alexander Paschenko > Fix For: 2.0 > > > All DDL statement must be performed from within separate worker thread. This > worker thread should listen for discovery events (JOIN, LEAVE, FAIL, CUSTOM) > and act accordingly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-3469) Get rid of deprecated APIs and entities
[
https://issues.apache.org/jira/browse/IGNITE-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874652#comment-15874652
]
Taras Ledkov edited comment on IGNITE-3469 at 2/20/17 3:24 PM:
---
The list of the deprecated class / methods / properties:
- two methods {{IgniteCluster.mapKeyToNode}} - the removing is simple because
its are used rare;
- {{IgniteCache.randomEntry}} - the removing is simple because it is used rare;
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- {{CacheTypeMetadata}};
- Classes related with {{AffinityNodeHashResolver}};
- Backup filters for affinity functions;
- {{RandomEvictionPolicy}};
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {{transactionManagerLookupClassName}} and
{rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{FileSystemConfiguration}} properties:
-- {{fragmentizerLocalWritesRatio}};
-- {{trashPurgeTimeout}};
-- {{dualModePutExecutorService}};
-- {{dualModePutExecutorServiceShutdown}};
-- {{dualModeMaxPendingPutsSize}};
- {{IgniteConfiguration}} properties:
-- {{nodeId}};
-- {{DFLT_PUBLIC_KEEP_ALIVE_TIME}};
-- {{DFLT_PUBLIC_THREADPOOL_QUEUE_CAP}};
-- {{DFLT_SYSTEM_MAX_THREAD_CNT}};
-- {{DFLT_SYSTEM_KEEP_ALIVE_TIME}};
-- {{DFLT_UTILITY_KEEP_ALIVE_TIME}};
-- {{DFLT_SYSTEM_THREADPOOL_QUEUE_CAP}};
- {{TransactionConfiguration}} properties:
-- {{txSerializableEnabled}};
-- {{txManagerLookupClassName}};
- Several methods at the {{IgfsPath}} class: empty constructor, {{root()}} and
{{isSame}} methods;
- Classes are retated to the {{GridSslContextFactory}};
-
was (Author: tledkov-gridgain):
The list of the deprecated class / methods / properties:
- two methods {{IgniteCluster.mapKeyToNode}} - the removing is simple because
its are used rare;
- {{IgniteCache.randomEntry}} - the removing is simple because it is used rare;
- The system flags:
-- {{IGNITE_BINARY_SORT_OBJECT_FIELDS}};
-- {{IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES}};
-- {{IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT}} - not used in the projects now.
- {{CacheTypeMetadata}};
- Classes related with {{AffinityNodeHashResolver}};
- Backup filters for affinity functions;
- {{RandomEvictionPolicy}};
- {{ContinuousQuery.setRemoteFilter}};
- {{CacheStore.sessionEnd}};
- {{CacheAbstractJdbcStore.translateFields}};
- {{CacheJdbcPojoStoreFactory.setDataSource}};
- {{CacheConfiguration}} properties: {{transactionManagerLookupClassName}} and
{rebalanceThreadPoolSize}};
- {{ConnectorConfiguration.sslContextFactory}} property;
- {{FileSystemConfiguration}} properties:
-- {{fragmentizerLocalWritesRatio}};
-- {{trashPurgeTimeout}};
-- {{dualModePutExecutorService}};
-- {{dualModePutExecutorServiceShutdown}};
-- {{dualModeMaxPendingPutsSize}};
- {{IgniteConfiguration}} properties:
-- {{nodeId}};
-- {{DFLT_PUBLIC_KEEP_ALIVE_TIME}};
-- {{DFLT_PUBLIC_THREADPOOL_QUEUE_CAP}};
-- {{DFLT_SYSTEM_MAX_THREAD_CNT}};
-- {{DFLT_SYSTEM_KEEP_ALIVE_TIME}};
-- {{DFLT_UTILITY_KEEP_ALIVE_TIME}};
-- {{DFLT_SYSTEM_THREADPOOL_QUEUE_CAP}};
- {{TransactionConfiguration}} properties:
-- {{txSerializableEnabled}};
-- {{txManagerLookupClassName}};
- Several methods at the {{IgfsPath}} class: empty constructor, {{root()}} and
{{isSame}} methods;
-
> Get rid of deprecated APIs and entities
> ---
>
> Key: IGNITE-3469
> URL: https://issues.apache.org/jira/browse/IGNITE-3469
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Goncharuk
> Labels: important
> Fix For: 2.0
>
>
> There are more than 220 deprecated elements in Ignite code kept for the sake
> of backward compatibility. We need to cleanup the code for Ignite 2.0 release.
> 2.0 migration guide has to be updated if needed:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
[
https://issues.apache.org/jira/browse/IGNITE-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874704#comment-15874704
]
Nikolay Tikhonov commented on IGNITE-3878:
--
[~dreamx]
Thank you for your contribution. We glad see you in Apache Ignite community.
{{CacheEntryAsyncListener3}} has {{@IgniteAsyncCallback}} annotation due this
listeners have different semantics (more details see javadoc for the
annotation) and this case should be tested. Let's refactored this test that it
works for all cases (without any {{if}}).
Also your changes don't work correctly for filter. For each an update, filter
invoked on primary and backup nodes. In current implementation
CacheQueryEntryEvent#isBackup method for this cases always return {{false}}.
Need to fix it and add tests on it.
> Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
> --
>
> Key: IGNITE-3878
> URL: https://issues.apache.org/jira/browse/IGNITE-3878
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Maksim Kozlov
>Priority: Minor
>
> In some cases useful know where (on primary or backup nodes) was invoked a
> continuous query filter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
[
https://issues.apache.org/jira/browse/IGNITE-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874761#comment-15874761
]
Nikolay Tikhonov commented on IGNITE-3878:
--
Also, please, pay attention that {{cntPrimary}} and {{cntBackup}} variables can
be updated from many threads. Better way using atomic primitive from
java.util.concurrent.
> Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
> --
>
> Key: IGNITE-3878
> URL: https://issues.apache.org/jira/browse/IGNITE-3878
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Maksim Kozlov
>Priority: Minor
>
> In some cases useful know where (on primary or backup nodes) was invoked a
> continuous query filter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (IGNITE-2940) .NET: Plugin system
[ https://issues.apache.org/jira/browse/IGNITE-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reopened IGNITE-2940: > .NET: Plugin system > --- > > Key: IGNITE-2940 > URL: https://issues.apache.org/jira/browse/IGNITE-2940 > Project: Ignite > Issue Type: New Feature > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net > Fix For: 2.0 > > > Implement a plugin system to allow extending Ignite functionality by third > parties. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4729) Async operation support in platform plugins
Pavel Tupitsyn created IGNITE-4729:
--
Summary: Async operation support in platform plugins
Key: IGNITE-4729
URL: https://issues.apache.org/jira/browse/IGNITE-4729
Project: Ignite
Issue Type: Sub-task
Components: platforms
Reporter: Pavel Tupitsyn
Fix For: 2.0
Expose a set of async operations on {{IPlatformTarget}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4729) Async operation support in platform plugins
[
https://issues.apache.org/jira/browse/IGNITE-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-4729:
--
Assignee: Pavel Tupitsyn
> Async operation support in platform plugins
> ---
>
> Key: IGNITE-4729
> URL: https://issues.apache.org/jira/browse/IGNITE-4729
> Project: Ignite
> Issue Type: Sub-task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.0
>
>
> Expose a set of async operations on {{IPlatformTarget}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4215) Introduce global identity resolver for binary objects.
[ https://issues.apache.org/jira/browse/IGNITE-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-4215: -- Assignee: Vyacheslav Daradur > Introduce global identity resolver for binary objects. > -- > > Key: IGNITE-4215 > URL: https://issues.apache.org/jira/browse/IGNITE-4215 > Project: Ignite > Issue Type: Task > Components: binary >Affects Versions: 1.7 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > Currently identity resolver can only be set on per-type level. We need to > introduce it on global level as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4215) Introduce global identity resolver for binary objects.
[ https://issues.apache.org/jira/browse/IGNITE-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-4215: -- Assignee: (was: Vyacheslav Daradur) > Introduce global identity resolver for binary objects. > -- > > Key: IGNITE-4215 > URL: https://issues.apache.org/jira/browse/IGNITE-4215 > Project: Ignite > Issue Type: Task > Components: binary >Affects Versions: 1.7 >Reporter: Vladimir Ozerov > Fix For: 2.0 > > > Currently identity resolver can only be set on per-type level. We need to > introduce it on global level as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4730) .NET: Propagate IgniteConfiguration.OdbcConfiguration
Pavel Tupitsyn created IGNITE-4730:
--
Summary: .NET: Propagate IgniteConfiguration.OdbcConfiguration
Key: IGNITE-4730
URL: https://issues.apache.org/jira/browse/IGNITE-4730
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Fix For: 2.1
ODBC can be enabled via {{IgniteConfiguration.odbcConfiguration}} in Java.
Propagate this property to .NET.
https://apacheignite.readme.io/docs/odbc-driver
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions
[ https://issues.apache.org/jira/browse/IGNITE-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874918#comment-15874918 ] ASF GitHub Bot commented on IGNITE-4106: Github user AMashenkov closed the pull request at: https://github.com/apache/ignite/pull/1278 > SQL: parallelize sql queries over cache local partitions > > > Key: IGNITE-4106 > URL: https://issues.apache.org/jira/browse/IGNITE-4106 > Project: Ignite > Issue Type: Improvement > Components: SQL >Affects Versions: 1.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Labels: performance > Fix For: 1.9 > > Attachments: 1node-4thread.jfr, 4node-1thread.jfr > > > If we run SQL query on cache partitioned over several cluster nodes, it will > be split into several queries running in parallel. But really we will have > one thread per query on each node. > So, for now, to improve SQL query performance we need to run more Ignite > instances or split caches manually. > It seems to be better to split local SQL queries over cache partitions, so we > would be able to parallelize SQL query on every single node and utilize CPU > more efficiently. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions
[ https://issues.apache.org/jira/browse/IGNITE-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874980#comment-15874980 ] Andrew Mashenkov commented on IGNITE-4106: -- Minor API fix: qryParallelismLevel can be set on per cache base. Allow REPLICATED cache to be used with segmented PARTITIONED in one query. Tests added. Sync-ed with master. > SQL: parallelize sql queries over cache local partitions > > > Key: IGNITE-4106 > URL: https://issues.apache.org/jira/browse/IGNITE-4106 > Project: Ignite > Issue Type: Improvement > Components: SQL >Affects Versions: 1.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Labels: performance > Fix For: 1.9 > > Attachments: 1node-4thread.jfr, 4node-1thread.jfr > > > If we run SQL query on cache partitioned over several cluster nodes, it will > be split into several queries running in parallel. But really we will have > one thread per query on each node. > So, for now, to improve SQL query performance we need to run more Ignite > instances or split caches manually. > It seems to be better to split local SQL queries over cache partitions, so we > would be able to parallelize SQL query on every single node and utilize CPU > more efficiently. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4720) Sporadically fails for Hadoop
[ https://issues.apache.org/jira/browse/IGNITE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874981#comment-15874981 ] Ivan Veselovsky commented on IGNITE-4720: - 1) localized the problem to only one test (aggregatewordcount). 2) have proven that igfs:// does not play any role there: the test fails in the same way even with file:// file system. > Sporadically fails for Hadoop > - > > Key: IGNITE-4720 > URL: https://issues.apache.org/jira/browse/IGNITE-4720 > Project: Ignite > Issue Type: Bug > Components: hadoop >Affects Versions: 1.8 >Reporter: Irina Zaporozhtseva >Assignee: Ivan Veselovsky > Fix For: 1.9 > > > hadoop example aggregatewordcount under apache ignite hadoop edition grid > with 4 nodes for hadoop-2_6_4 and hadoop-2_7_2: > aggregatewordcount returns 999712 instead of 100 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions
[ https://issues.apache.org/jira/browse/IGNITE-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875007#comment-15875007 ] ASF GitHub Bot commented on IGNITE-4106: GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/1556 IGNITE-4106: SQL: parallelize sql queries over cache local partitions Merged with IGNITE-1.9. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4106-1.9 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1556.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 #1556 commit 608032b900a51a7fba99e383c0fe0d8a37558cbb Author: AMRepo Date: 2017-02-20T18:24:29Z Implemented. commit b7c5ae313fa7c4cc6765e2f3ce8eb30d46c93f10 Author: AMRepo Date: 2017-02-20T19:53:33Z Merge remote-tracking branch 'apache/ignite-1.9' into ignite-4106-1.9 # Conflicts: # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GridH2IndexBase.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridReduceQueryExecutor.java # modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/msg/GridH2QueryRequest.java # modules/indexing/src/test/java/org/apache/ignite/internal/processors/query/IgniteSqlSplitterSelfTest.java > SQL: parallelize sql queries over cache local partitions > > > Key: IGNITE-4106 > URL: https://issues.apache.org/jira/browse/IGNITE-4106 > Project: Ignite > Issue Type: Improvement > Components: SQL >Affects Versions: 1.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Labels: performance > Fix For: 1.9 > > Attachments: 1node-4thread.jfr, 4node-1thread.jfr > > > If we run SQL query on cache partitioned over several cluster nodes, it will > be split into several queries running in parallel. But really we will have > one thread per query on each node. > So, for now, to improve SQL query performance we need to run more Ignite > instances or split caches manually. > It seems to be better to split local SQL queries over cache partitions, so we > would be able to parallelize SQL query on every single node and utilize CPU > more efficiently. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4725) Document streaming mode for JDBC driver
[
https://issues.apache.org/jira/browse/IGNITE-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875147#comment-15875147
]
Denis Magda commented on IGNITE-4725:
-
Please assign the ticket to me for review.
> Document streaming mode for JDBC driver
> ---
>
> Key: IGNITE-4725
> URL: https://issues.apache.org/jira/browse/IGNITE-4725
> Project: Ignite
> Issue Type: Task
> Components: documentation, SQL
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.9
>
>
> SQL streaming was added to {{AI 1.9}}. We need to document it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ
[
https://issues.apache.org/jira/browse/IGNITE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875281#comment-15875281
]
Roman Shtykh commented on IGNITE-533:
-
[~dreamx] Great, thanks! Please see some additional comments.
> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4539) RocketMQ data streamer
[ https://issues.apache.org/jira/browse/IGNITE-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh updated IGNITE-4539: - Fix Version/s: (was: 1.9) 2.0 > RocketMQ data streamer > -- > > Key: IGNITE-4539 > URL: https://issues.apache.org/jira/browse/IGNITE-4539 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Fix For: 2.0 > > > Streamer for RocketMQ (https://github.com/rocketmq) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4539) RocketMQ data streamer
[ https://issues.apache.org/jira/browse/IGNITE-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875322#comment-15875322 ] Roman Shtykh commented on IGNITE-4539: -- RocketMQ's first Apache license release is done now. This integration goes for Apache Ignite 2.0. > RocketMQ data streamer > -- > > Key: IGNITE-4539 > URL: https://issues.apache.org/jira/browse/IGNITE-4539 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Fix For: 2.0 > > > Streamer for RocketMQ (https://github.com/rocketmq) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4539) RocketMQ data streamer
[ https://issues.apache.org/jira/browse/IGNITE-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875322#comment-15875322 ] Roman Shtykh edited comment on IGNITE-4539 at 2/21/17 3:48 AM: --- RocketMQ's first Apache license release is done today. This integration goes for Apache Ignite 2.0. was (Author: roman_s): RocketMQ's first Apache license release is done now. This integration goes for Apache Ignite 2.0. > RocketMQ data streamer > -- > > Key: IGNITE-4539 > URL: https://issues.apache.org/jira/browse/IGNITE-4539 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Fix For: 2.0 > > > Streamer for RocketMQ (https://github.com/rocketmq) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4226) Redis SET command should handle expirations
[
https://issues.apache.org/jira/browse/IGNITE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875519#comment-15875519
]
Andrey Novikov commented on IGNITE-4226:
Hi [~roman_s],
{{setExpire}} look dirty and contains many duplicated code, non-informative
error messages. I don't think that we receive performance drop if we iterate
over list of 5-10 items twice.
> Redis SET command should handle expirations
> ---
>
> Key: IGNITE-4226
> URL: https://issues.apache.org/jira/browse/IGNITE-4226
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 1.8
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Labels: redis
> Fix For: 2.0
>
>
> Handling EX and PX parameters of SET command.
> https://redis.io/commands/set
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[ https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryabov Dmitrii updated IGNITE-602: -- Attachment: master_3f4ebad9bd_ignite-602.patch > [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by > infinite recursion > > > Key: IGNITE-602 > URL: https://issues.apache.org/jira/browse/IGNITE-602 > Project: Ignite > Issue Type: Bug >Reporter: Artem Shutak >Assignee: Ryabov Dmitrii > Labels: Muted_test > Attachments: master_3f4ebad9bd_ignite-602.patch > > > See test > org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention > and related TODO in same source file. > Also take a look at > http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring > Test should be unmuted on TC after fix. > see GG-5000. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
