[jira] [Updated] (IGNITE-4659) Migrate to webpack@2

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov updated IGNITE-4659:
-
Component/s: wizards

> Migrate to webpack@2
> 
>
> Key: IGNITE-4659
> URL: https://issues.apache.org/jira/browse/IGNITE-4659
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4659) Migrate to webpack@2

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-4659:


 Summary: Migrate to webpack@2
 Key: IGNITE-4659
 URL: https://issues.apache.org/jira/browse/IGNITE-4659
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4658) GridCacheProcessor.createMissingCaches() should be called in a separate thread

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4658:
---

 Summary: GridCacheProcessor.createMissingCaches() should be called 
in a separate thread
 Key: IGNITE-4658
 URL: https://issues.apache.org/jira/browse/IGNITE-4658
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 1.8
Reporter: Valentin Kulichenko


{{GridCacheProcessor.createMissingCaches()}} method is called during query 
execution if not all caches are created on the client. If this happen inside a 
transaction, query fails due to fact that cache can't be created within a 
transaction.

To work around this and improve usability, this method should start a separate 
thread where caches will be created, and synchronously join on this thread.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4633) Initiate DDL operation through custom discovery message

[Alexander Paschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15854988#comment-15854988
 ] 

Alexander Paschenko commented on IGNITE-4633:
-

INIT/ACK schema almost finished; main thing left is async notifications of 
coordinator about progress of subtasks. Overall ETA still is tomorrow.

> Initiate DDL operation through custom discovery message
> ---
>
> Key: IGNITE-4633
> URL: https://issues.apache.org/jira/browse/IGNITE-4633
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Design considerations:
> 1) Create generic DDL custom discovery message pair - {{INIT}} and {{ACK}} 
> messages - which will hold concrete DDL commands.
> 2) Originator must generate unique message ID to be able to track it later.
> 3) Coordinator calculates all participants through affinity API and adds them 
> to message.
> 4) {{INIT}} message goes through the ring and:performs some fast preliminary 
> checks if necessary and collects error; in particular it may verify whether 
> schema change is valid to allow for fail-fast client notification.;
> 5) If at least one error occurs during {{INIT}} stage, originator may throw 
> exception to the user.
> 6) {{ACK}} message schedules asynchronous execution of the command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15854808#comment-15854808
 ] 

Andrew Mashenkov commented on IGNITE-4106:
--

Found an issue. Local queries work incorrect with segmented index due to 
TwoStepQuery does not support local properly.
Need a few time to fix it.

> 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-4212) Ignite Benchmarking Simplification and Automation

[Oleg Ostanin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15854635#comment-15854635
 ] 

Oleg Ostanin commented on IGNITE-4212:
--

I fixed issue with missing file.

> 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: 2.0
>
> Attachments: 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] [Commented] (IGNITE-4629) Optimization: store value of indexed field in H2Tree

[Konstantin Dudkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15854289#comment-15854289
 ] 

Konstantin Dudkov commented on IGNITE-4629:
---

[PR 1500|https://github.com/apache/ignite/pull/1500]

> Optimization: store value of indexed field in H2Tree
> 
>
> Key: IGNITE-4629
> URL: https://issues.apache.org/jira/browse/IGNITE-4629
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Konstantin Dudkov
> Fix For: 2.0
>
>
> Currently we store only 'link' in H2Tree and to do comparison we read lock 
> data page and copy row data into GridH2Row. If indexed value is primitive 
> then it is possible to store this value in H2Tree, so get value for 
> comparison will be just Unsafe.getInt/getLong.
> Prototype is implemented in ignite-3477-idx. (branch is based on ignite-3477).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible

[Pavel Tupitsyn (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15854248#comment-15854248
 ] 

Pavel Tupitsyn commented on IGNITE-2703:


Callbacks implemented for all use cases.

> .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
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> 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.15#6346)

[jira] [Commented] (IGNITE-4629) Optimization: store value of indexed field in H2Tree

[Konstantin Dudkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15854243#comment-15854243
 ] 

Konstantin Dudkov commented on IGNITE-4629:
---

[TC 
tests|http://ci.ignite.apache.org/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1500%2Fhead]

> Optimization: store value of indexed field in H2Tree
> 
>
> Key: IGNITE-4629
> URL: https://issues.apache.org/jira/browse/IGNITE-4629
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Konstantin Dudkov
> Fix For: 2.0
>
>
> Currently we store only 'link' in H2Tree and to do comparison we read lock 
> data page and copy row data into GridH2Row. If indexed value is primitive 
> then it is possible to store this value in H2Tree, so get value for 
> comparison will be just Unsafe.getInt/getLong.
> Prototype is implemented in ignite-3477-idx. (branch is based on ignite-3477).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4302) Exchange binary metadata with discovery custom messages instead of system cache

[Sergey Chugunov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15854224#comment-15854224
 ] 

Sergey Chugunov commented on IGNITE-4302:
-

Adopted protocol to tolerate duplicate accepted messages as it turned out that 
current implementation of discovery protocol doesn't guarantee exactly once 
delivery of discovery messages.

Addressed an issue caused by metadata register requests are allowed to arrive 
before discovery even started.

> Exchange binary metadata with discovery custom messages instead of system 
> cache
> ---
>
> Key: IGNITE-4302
> URL: https://issues.apache.org/jira/browse/IGNITE-4302
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> h4. Notes
> See [IGNITE-4157|https://issues.apache.org/jira/browse/IGNITE-4157] for more 
> details about context.
> h4. Acceptance Criteria
> # Binary metadata cache is deleted.
> # Binary metadata exchange is performed using *DiscoveryCustomMessage* events.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4657) Cache entry eviction can be broken if store throws exception

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-4657:


 Summary: Cache entry eviction can be broken if store throws 
exception
 Key: IGNITE-4657
 URL: https://issues.apache.org/jira/browse/IGNITE-4657
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Semen Boikov
Assignee: Semen Boikov
 Fix For: 1.9


Fix for IGNITE-4465 (commit 22b7e76c00a77a06388bcef869f29d1a572a306a) 
introduced cache entry 'reservation' while entry is loaded from store. When 
entry is reserved it is not evicted from cache. But currently 'reserved' status 
is not cleared when cache store's methods throw exception, this should be fixed 
in GridcCacheAdaptergetAllAsync0: catch exception thrown from 
ctx.store().loadAll and do required cleanup.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (IGNITE-4655) Reduce heap usage on exchange.

[Alexei Scherbakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexei Scherbakov resolved IGNITE-4655.
---
Resolution: Won't Fix

Already fixed in master.

> Reduce heap usage on exchange.
> --
>
> Key: IGNITE-4655
> URL: https://issues.apache.org/jira/browse/IGNITE-4655
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Priority: Critical
> Fix For: 1.9
>
>
> Recently I've debugged heap overgrowth during an exchange on configuration 
> with large amount of caches.
> I found several problems:
> * GridDhtPartitionsExchangeFuture.msgs field is not cleared after exchange. 
> Easy fix.
> * GridDhtPartitionsSingleMessage.partCntrsBytes is serialized as object and 
> takes large amount of heap.Could be fixed by implementing more efficient 
> serialization.
> * BinaryMemoryAllocatorChunk heap buffer is not shrinked during exchange due 
> to large message size. WIth 128 threads in sys pool it may take up to 7G of 
> heap on exchange process(I observer 52M message size). This could be  fixed 
> by reducing max exchange message size.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3625) IGFS: Use common naming for IGFS meta and data caches.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3625:

Fix Version/s: (was: 1.9)
   2.0

> IGFS: Use common naming for IGFS meta and data caches.
> --
>
> Key: IGNITE-3625
> URL: https://issues.apache.org/jira/browse/IGNITE-3625
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently IGFS is configured by passing names of two caches: meta and data. 
> See {{FileSystemConfiguration.metaCacheName}} and 
> {{FileSystemConfiguration.dataCacheName}}.
> These two caches are considered internal then and are not accessible for the 
> user.
> We need to do the following during node startup:
> 1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
> or if it is configured as both meta and data cache for a single IGFS, then 
> throw an exception.
> Relevant code pieces:
> {{IgfsProcessor.validateLocalIgfsConfigurations}}
> {{IgfsProcessorSelfTest}}.
> 2) During node startup change the name of this cache to 
> {{igfs-IGFS_NAME-meta}} or {{igfs-IGFS_NAME-data}}. Change must be performed 
> both inside IGFS config and cache config.
> Relevant code pieces:
> {{CacheConfiguration.name}}
> {{FileSystemConfiguration.metaCacheName}}
> {{FileSystemConfiguration.dataCacheName}}
> {{IgfsUtils.prepareCacheConfiguration}} - where change will be done.
> 3) If any of new names caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-2356) IGFS client should be able to failover in case of server crash.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2356:

Fix Version/s: (was: 2.0)
   2.1

> IGFS client should be able to failover in case of server crash.
> ---
>
> Key: IGNITE-2356
> URL: https://issues.apache.org/jira/browse/IGNITE-2356
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> IGFS client (IgniteHadoopFileSystem) communicates IGFS over endpoint - either 
> TCP or shmem.
> Only single endpoint can be specified. As such, should the server went down, 
> IgntieHadoopFileSystem (either new or existing) is no longer operational. 
> We need to let user specify several endpoints and failover/balance between 
> them.
> Look at Hadoop HA first to get an ideas on how to configure multiple 
> addresses.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3625) IGFS: Use common naming for IGFS meta and data caches.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3625:

Fix Version/s: (was: 2.1)
   1.9

> IGFS: Use common naming for IGFS meta and data caches.
> --
>
> Key: IGNITE-3625
> URL: https://issues.apache.org/jira/browse/IGNITE-3625
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 1.9
>
>
> Currently IGFS is configured by passing names of two caches: meta and data. 
> See {{FileSystemConfiguration.metaCacheName}} and 
> {{FileSystemConfiguration.dataCacheName}}.
> These two caches are considered internal then and are not accessible for the 
> user.
> We need to do the following during node startup:
> 1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
> or if it is configured as both meta and data cache for a single IGFS, then 
> throw an exception.
> Relevant code pieces:
> {{IgfsProcessor.validateLocalIgfsConfigurations}}
> {{IgfsProcessorSelfTest}}.
> 2) During node startup change the name of this cache to 
> {{igfs-IGFS_NAME-meta}} or {{igfs-IGFS_NAME-data}}. Change must be performed 
> both inside IGFS config and cache config.
> Relevant code pieces:
> {{CacheConfiguration.name}}
> {{FileSystemConfiguration.metaCacheName}}
> {{FileSystemConfiguration.dataCacheName}}
> {{IgfsUtils.prepareCacheConfiguration}} - where change will be done.
> 3) If any of new names caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-2356) IGFS client should be able to failover in case of server crash.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2356:

Fix Version/s: (was: 2.1)
   2.0

> IGFS client should be able to failover in case of server crash.
> ---
>
> Key: IGNITE-2356
> URL: https://issues.apache.org/jira/browse/IGNITE-2356
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> IGFS client (IgniteHadoopFileSystem) communicates IGFS over endpoint - either 
> TCP or shmem.
> Only single endpoint can be specified. As such, should the server went down, 
> IgntieHadoopFileSystem (either new or existing) is no longer operational. 
> We need to let user specify several endpoints and failover/balance between 
> them.
> Look at Hadoop HA first to get an ideas on how to configure multiple 
> addresses.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-3562) Dependency to outdated Lucene 3.5.0

[Evgenii Zhuravlev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgenii Zhuravlev reassigned IGNITE-3562:
-

Assignee: Evgenii Zhuravlev

> Dependency to outdated Lucene 3.5.0
> ---
>
> Key: IGNITE-3562
> URL: https://issues.apache.org/jira/browse/IGNITE-3562
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
>Reporter: Alexander Veit
>Assignee: Evgenii Zhuravlev
>  Labels: jar-hell
> Fix For: 2.0
>
>
> Ignite 1.6.0 comes with Lucene 3.5.0 core as dependency, which dates back to 
> the year 2011.
> This makes it difficult to integrate with newer software.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-3579) Message type should be short.

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853897#comment-15853897
 ] 

Taras Ledkov commented on IGNITE-3579:
--

[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1501%2Fhead]

> Message type should be short.
> -
>
> Key: IGNITE-3579
> URL: https://issues.apache.org/jira/browse/IGNITE-3579
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Chandresh Pancholi
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
>
> Currently we encode internal messages with {{byte}}. It turns out that we 
> almost exhausted possible IDs. 
> We should change {{byte}} to {{short}} for message ID.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-3579) Message type should be short.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853893#comment-15853893
 ] 

ASF GitHub Bot commented on IGNITE-3579:


GitHub user tledkov-gridgain opened a pull request:

https://github.com/apache/ignite/pull/1501

IGNITE-3579 Change lenght of the message type from byte to short type



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-3579

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1501.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 #1501


commit c893da70a9757b16b0799adc8eaa29fa1b03d06e
Author: tledkov-gridgain 
Date:   2016-12-21T11:54:33Z

IGNITE-4399: IGFS: Merged IgfsSecondaryFileSystem and 
IgfsSecondaryFileSystemV2 interfaces. This closes #1346.

commit c5882a85f4e3a1f61723ac54fd92f087684df6da
Author: devozerov 
Date:   2016-12-26T11:15:42Z

Merge branch 'master' into ignite-2.0

commit 7e73d0223a3f09cbe0b7094a2c04bdf9d63ca9be
Author: devozerov 
Date:   2016-12-28T09:54:47Z

Merge branch 'master' into ignite-2.0

commit 7d82d6a06b5e9f1f8cd2909b865e37d46b8da03f
Author: devozerov 
Date:   2016-12-28T09:58:11Z

IGNITE-3875: Introduced separate thread pool for data streamer. This closes 
#1173. This closes #1383.

commit a61b0eaff1817d84c0659e8a7e095f29e22800e1
Author: tledkov-gridgain 
Date:   2016-12-28T11:09:38Z

IGNITE-4405: Hadoop: implemented "readLine" method for HadoopDataInStream 
and HadoopDirectDataInput classes. This closes #1358.

commit 2df39a80d80e2575be61a902ccd48615796fcde9
Author: tledkov-gridgain 
Date:   2016-12-28T13:47:24Z

IGNITE-3961: IGFS: Added IgfsSecondaryFileSystem.affintiy() method. This 
closes #1114. This closes #1252.

commit 2e691d80ea4870c3e7b5b127792b66c920f72c39
Author: tledkov-gridgain 
Date:   2016-12-29T08:00:01Z

IGNITE-4462: IGFS: removed grid name from HadoopIgfsEndpoint. This closes 
#1368.

commit a9b1fc2b3840d47d7c978d9296e8ae6bdeb10be5
Author: tledkov-gridgain 
Date:   2016-12-29T08:07:22Z

IGNITE-4459: Hadoop: weighted planned is default one from now on. This 
closes #1391.

commit 1f743465d6875ef48b1835d03a78a0dbaf339bf6
Author: tledkov-gridgain 
Date:   2016-12-29T08:14:10Z

IGNITE-4458: Hadoop: "striped" shuffle mode is default from now on. This 
closes #1390.

commit 6090ebdfcd0ea3840b0d32cb10197b43615e1e89
Author: devozerov 
Date:   2017-01-05T09:23:06Z

Merge branch 'master' into ignite-2.0

commit 77ca2e636c73e464f833f227c4894df0785ae9e2
Author: devozerov 
Date:   2017-01-16T13:07:49Z

Merge branch 'master' into ignite-2.0

commit d14e0727b3dd61ab5ec2957133d77dbc25e9ba68
Author: tledkov-gridgain 
Date:   2017-01-16T13:36:25Z

IGNITE-4428: Hadoop: moved HadoopMapReducePlanner and dependent classes to 
public space. This closes #1389. This closes #1394.

commit f1365421c299b754a10edf8b6f156aeeb5ff0ce1
Author: tledkov-gridgain 
Date:   2017-01-16T13:57:27Z

IGNITE-4503: Hadoop: added boundary checks to HadoopDirectDataInput. This 
closes # 1416.

commit e08b6ff48916edfab2dbd5d62092be5a1f819a2f
Author: Pavel Tupitsyn 
Date:   2017-01-19T10:34:59Z

Merge branch 'master' into ignite-2.0

commit 43adf8a3f09c6b29fe3e70f62dbc58251d8d7cb9
Author: Ivan Veselovskiy 
Date:   2017-01-19T11:34:23Z

IGNITE-4219: Hadoop: fixed serialization of long strings. This closes #1409.

commit 454b9769e72775c5f6b44a36f0eef84bcce13bd7
Author: devozerov 
Date:   2017-01-19T11:34:43Z

Merge remote-tracking branch 'origin/ignite-2.0' into ignite-2.0

commit 4cd332b781cf700b99402eed2363f988f6403602
Author: Sergey Chugunov 
Date:   2017-01-19T12:05:09Z

IGNITE-4157 Use  discovery custom messages instead of marshaller cache - 
Fixes #1271.

Signed-off-by: Alexey Goncharuk 

commit d0a6c57aa26bca64ef68370c0ebdb5ce45bcc765
Author: Pavel Tupitsyn 
Date:   2017-01-19T14:10:41Z

IGNITE-4441 Define plugin API in .NET

This closes #1362

commit 34a97833905a33bdb31b8e4580a576c2142313a7
Author: Alexey Goncharuk 
Date:   2017-01-19T15:04:23Z

IGNITE-4157 - Added mapping update listener stub

commit e8377167b7b8dd020a93d92c743e4541dcd000ed
Author: Pavel Tupitsyn 
Date:   2017-01-20T10:00:40Z

Merge branch 'master' into ignite-2.0

[jira] [Comment Edited] (IGNITE-4169) Data streamer mode for DML

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853884#comment-15853884
 ] 

Vladimir Ozerov edited comment on IGNITE-4169 at 2/6/17 11:55 AM:
--

[~al.psc], my comments:
1) {{JdbcConnection.ctor}} - we need sensible defaults for 
{{PROP_STREAMING_PER_NODE_BUF_SIZE}}, {{PROP_STREAMING_PER_NODE_PAR_OPS}}. They 
cannot be 0. Please re-use values from {{IgniteDataStreamer}}.
2) {{JdbcConnection.prepareStatement}} - if message cannot be processed in 
streaming manner, we agreed to throw an exception. Streaming mode is only for 
streaming.
3) {{JdbcStatement.addBatch(String}]} - let's add more info to error message, 
suggesting user to use {{PreparedStatement.addBatch()}}. Do the same for 
override in {{JdbcPreparedStatement.addBatch(String}]}.
4) {{JdbcPreparedStatement.executeBatch}} - operation must follow JDBC standard 
and return single int value per every executed statement.
5) {{IgniteQueryErrorCode}} - I would use {{UNSUPPORTED_OPERATION}} for both 
{{INVALID_STREAMING_STMT}} and {{CROSS_CACHE_STREAMING}} cases.
6) {{DataStreamerCacheUpdaters}} - as streamed updates, merges and removes are 
only possible if {{WHERE}} condition is specified on {{_key}} column, which is 
internal and should be normally used by users, I would drop support for 
anything except of {{INSERT}} for streaming mode. May be we should discuss it 
on the dev-list to get more opinions.
7) {{IgniteH2Indexing.createStreamer}} - in current implementation {{INSERT}} 
doesn't throw an exception if record already exists. I would add 
{{allowOverwrite}} property to JDBC properties to give usres control over this 
behavior.
8) {{JdbcConnection.getSchema}} - method should return cache name if schema is 
not set explicitly. Currently it will return empty string which is not 
symmetrical with {{setSchema}} method.


was (Author: vozerov):
[~al.psc], my comments:
1) {{JdbcConnection.ctor}} - we need sensible defaults for 
{{PROP_STREAMING_PER_NODE_BUF_SIZE}}, {{PROP_STREAMING_PER_NODE_PAR_OPS}}. They 
cannot be 0. Please re-use values from {{IgniteDataStreamer}}.
2) {{JdbcConnection.prepareStatement}} - if message cannot be processed in 
streaming manner, we agreed to throw an exception. Streaming mode is only for 
streaming.
3) {{JdbcStatement.addBatch(String}]} - let's add more info to error message, 
suggesting user to use {{PreparedStatement.addBatch()}}. Do the same for 
override in {{JdbcPreparedStatement.addBatch(String}]}.
4) {{JdbcPreparedStatement.executeBatch}} - operation must follow JDBC standard 
and return single int value per every executed statement.
5) {{IgniteQueryErrorCode}} - I would use {{UNSUPPORTED_OPERATION}} for both 
{{INVALID_STREAMING_STMT}} and {{CROSS_CACHE_STREAMING}} cases.
6) {{DataStreamerCacheUpdaters}} - as streamed updates, merges and removes are 
only possible if {{WHERE}} condition is specified on {{_key}} column, which is 
internal and should be normally used by users, I would drop support for 
anything except of {{INSERT}} for streaming mode. May be we should discuss it 
on the dev-list to get more opinions.
7) {{IgniteH2Indexing.createStreamer}} - in current implementation {{INSERT}} 
doesn't throw an exception if record already exists. I would add 
{{allowOverwrite}} property to JDBC properties to give usres control over this 
behavior.

> 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] [Commented] (IGNITE-4590) Lock/unlock operations are hanging when topology changed

[Semen Boikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853865#comment-15853865
 ] 

Semen Boikov commented on IGNITE-4590:
--

Reviewed, looks good.

Thanks!

> Lock/unlock operations are hanging when topology changed
> 
>
> Key: IGNITE-4590
> URL: https://issues.apache.org/jira/browse/IGNITE-4590
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Nikolay Tikhonov
>Assignee: Semen Boikov
>Priority: Critical
> Attachments: 4590-test.patch
>
>
> Lock/unlock operations are hanging when topology changed. See attached test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

[Vyacheslav Daradur (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853863#comment-15853863
 ] 

Vyacheslav Daradur commented on IGNITE-4374:


[~dmagda], [~yzhdanov]

Please review it again.

Current output:
{code}
[14:16:48] 
[14:16:48] Message queue limit is set to 0 which may lead to potential OOMEs 
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to 
message queues growth on sender and receiver sides.
[14:16:48] Security status [authentication=off, tls/ssl=off]
[14:16:51] Performance suggestions for grid  (fix if possible)
[14:16:51] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[14:16:51]   ^-- JVM heap size is greater than 30.5Gb, JVM will not use 
compressed oops
[14:16:51]   ^-- Enable server mode for JVM (add '-server' to JVM options)
[14:16:51]   ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options
[14:16:51]   ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to 
JVM options)"
[14:16:51]   ^-- Specify New I/O max total size (add 
'-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
[14:16:51]   ^-- Enable using thread-local allocation blocks (add 
'-XX:+UseTLAB' to JVM options)
[14:16:51]   ^-- Disable processing of calls to System.gc() (add 
'-XX:+DisableExplicitGC' to JVM options)
[14:16:51]   ^-- Set OS parameter: vm.dirty_writeback_centisecs=500
[14:16:51]   ^-- Set OS parameter: vm.dirty_expire_centisecs=500
[14:16:51]   ^-- Set OS parameter: vm.swappiness=10
[14:16:51]   ^-- Set OS parameter: vm.zone_reclaim_mode=0
[14:16:51]   ^-- Set OS parameter: vm.extra_free_kbytes=124
[14:16:51] Refer to this page for more performance suggestions: 
https://apacheignite.readme.io/docs/jvm-and-system-tuning
[14:16:51] 
[14:16:51] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[14:16:51] 
[14:16:51] Ignite node started OK (id=30a2111c)
[14:16:51] Topology snapshot [ver=1, servers=1, clients=0, CPUs=1, heap=1.0GB]
{code}

> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x32_not_optimized.png, x32_optimized.png, 
> x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs 
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options 
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly 
> set 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4656) Use dynamic caches for yardstick

[Oleg Ostanin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Ostanin reassigned IGNITE-4656:


Assignee: Oleg Ostanin

> Use dynamic caches for yardstick
> 
>
> Key: IGNITE-4656
> URL: https://issues.apache.org/jira/browse/IGNITE-4656
> Project: Ignite
>  Issue Type: Task
>  Components: yardstick
>Reporter: Sergey Kozlov
>Assignee: Oleg Ostanin
>
> At the moment Yardstick doesn't use dynamic caches and for load tests it is 
> significant lack.
> The simplest way to implement looks like to introduce two new options:
> 1. Number of dynamic caches created per thread and named 
> _thread_num_dyn_cache_N_
> 2. The name of a cache defined in Ignite Spring XML and its cache 
> configuration will be used for dynamic caches created by a thread.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4656) Use dynamic caches for yardstick

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-4656:
-

 Summary: Use dynamic caches for yardstick
 Key: IGNITE-4656
 URL: https://issues.apache.org/jira/browse/IGNITE-4656
 Project: Ignite
  Issue Type: Task
  Components: yardstick
Reporter: Sergey Kozlov


At the moment Yardstick doesn't use dynamic caches and for load tests it is 
significant lack.

The simplest way to implement looks like to introduce two new options:
1. Number of dynamic caches created per thread and named 
_thread_num_dyn_cache_N_
2. The name of a cache defined in Ignite Spring XML and its cache configuration 
will be used for dynamic caches created by a thread.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4472) Web Console: Implement usage tracing

[Dmitriy Shabalin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853821#comment-15853821
 ] 

Dmitriy Shabalin commented on IGNITE-4472:
--

[~vsisko] added some fixes
1) added description
2) check. all right, please confirm it
3) increased width
4) changed logic to save action. save url expression

> Web Console: Implement usage tracing
> 
>
> Key: IGNITE-4472
> URL: https://issues.apache.org/jira/browse/IGNITE-4472
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
> Fix For: 1.9
>
>
> We need to track some kind of "activity scores" for users.
> Activities:
> # Configuration
> # SQL
> # Demo
> And show that score on admin panel.
> May be this could be implemented by some library.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-4617) CPP: Implement Field-access methods for binary objects

[Igor Sapego (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853791#comment-15853791
 ] 

Igor Sapego edited comment on IGNITE-4617 at 2/6/17 10:21 AM:
--

As a first approach I'm going to try and get type metadata from Java by type ID 
(which we have access to) with, probably, some caching on C++ side for 
performance reasons.


was (Author: isapego):
As a first approach I'm going to try and get type matadata from Java by type ID 
(which we have access to) with, probably, some caching on C++ side for 
performance reasons.

> CPP: Implement Field-access methods for binary objects
> --
>
> Key: IGNITE-4617
> URL: https://issues.apache.org/jira/browse/IGNITE-4617
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 1.9
>
>
> Currently we have very limited implementation of binary objects that does not 
>  provide access to fields of the binary object. At least such methods as 
> {{HasField}} and {{GetField}} should be implemented.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-3196) Marshaling works wrong for the BigDecimals that have negative scale

[Pavel Tupitsyn (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853796#comment-15853796
 ] 

Pavel Tupitsyn commented on IGNITE-3196:


.NET changes look good to me.

> Marshaling works wrong for the BigDecimals that have negative scale
> ---
>
> Key: IGNITE-3196
> URL: https://issues.apache.org/jira/browse/IGNITE-3196
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> Current marshalling procedure of the {{BigDecimal}} assumes that the scale of 
> the {{BigDecimal}} value is always more than or equal to zero. However, scale 
> [can be 
> negative|https://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#scale()].
> This leads to invalid results if we try to marshal-unmarshal {{BigDecimal}} 
> that has a negative scale.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4617) CPP: Implement Field-access methods for binary objects

[Igor Sapego (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853791#comment-15853791
 ] 

Igor Sapego commented on IGNITE-4617:
-

As a first approach I'm going to try and get type matadata from Java by type ID 
(which we have access to) with, probably, some caching on C++ side for 
performance reasons.

> CPP: Implement Field-access methods for binary objects
> --
>
> Key: IGNITE-4617
> URL: https://issues.apache.org/jira/browse/IGNITE-4617
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 1.9
>
>
> Currently we have very limited implementation of binary objects that does not 
>  provide access to fields of the binary object. At least such methods as 
> {{HasField}} and {{GetField}} should be implemented.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-3429) org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov reassigned IGNITE-3429:


Assignee: Andrew Mashenkov

> 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: 2.0
>
>
> {{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] [Assigned] (IGNITE-4590) Lock/unlock operations are hanging when topology changed

[Semen Boikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov reassigned IGNITE-4590:


Assignee: Semen Boikov  (was: Nikolay Tikhonov)

> Lock/unlock operations are hanging when topology changed
> 
>
> Key: IGNITE-4590
> URL: https://issues.apache.org/jira/browse/IGNITE-4590
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Nikolay Tikhonov
>Assignee: Semen Boikov
>Priority: Critical
> Attachments: 4590-test.patch
>
>
> Lock/unlock operations are hanging when topology changed. See attached test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-3974) Process failing ZooKeeper tests.

[Stanilovsky Evgeny (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853726#comment-15853726
 ] 

Stanilovsky Evgeny commented on IGNITE-3974:


Vladimir seem`s its all ok here.

!2del_3974.png!

> Process failing ZooKeeper tests.
> 
>
> Key: IGNITE-3974
> URL: https://issues.apache.org/jira/browse/IGNITE-3974
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
> Attachments: 2del_3974.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3974) Process failing ZooKeeper tests.

[Stanilovsky Evgeny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanilovsky Evgeny updated IGNITE-3974:
---
Attachment: 2del_3974.png

> Process failing ZooKeeper tests.
> 
>
> Key: IGNITE-3974
> URL: https://issues.apache.org/jira/browse/IGNITE-3974
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
> Attachments: 2del_3974.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4629) Optimization: store value of indexed field in H2Tree

[Konstantin Dudkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853691#comment-15853691
 ] 

Konstantin Dudkov commented on IGNITE-4629:
---

I've done first implementation, running tests now.
[Review page 
(IG-CR-11)|http://reviews.ignite.apache.org/apache-ignite/review/IG-CR-11]

github branch: ignite-3477-idx2

> Optimization: store value of indexed field in H2Tree
> 
>
> Key: IGNITE-4629
> URL: https://issues.apache.org/jira/browse/IGNITE-4629
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Konstantin Dudkov
> Fix For: 2.0
>
>
> Currently we store only 'link' in H2Tree and to do comparison we read lock 
> data page and copy row data into GridH2Row. If indexed value is primitive 
> then it is possible to store this value in H2Tree, so get value for 
> comparison will be just Unsafe.getInt/getLong.
> Prototype is implemented in ignite-3477-idx. (branch is based on ignite-3477).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4395) Implement communication backpressure per policy - SYSTEM or PUBLIC

[Dmitry Karachentsev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853652#comment-15853652
 ] 

Dmitry Karachentsev commented on IGNITE-4395:
-

[review|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-89] 
[PR#1495|https://github.com/apache/ignite/pull/1495]


> Implement communication backpressure per policy - SYSTEM or PUBLIC
> --
>
> Key: IGNITE-4395
> URL: https://issues.apache.org/jira/browse/IGNITE-4395
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, compute
>Affects Versions: 1.7
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 1.9
>
>
> 1) Start two data nodes with some cache.
> 2) From one node in async mode post some big number of jobs to another. That 
> jobs do some cache operations.
> 3) Grid hangs almost immediately and all threads are sleeping except public 
> ones, they are waiting for response.
> This happens because all cache and job messages are queued on communication 
> and limited with default number (1024). It looks like jobs are waiting for 
> cache responses that could not be received due to this limit.
> Proper solution here is to have communication backpressure per policy -
> SYSTEM or PUBLIC, but not single point as it is now. It could be achieved
> with having two queues per communication session or (which looks a bit
> easier to implement) to have separate connections.
> [PR#1331|https://github.com/apache/ignite/pull/1331] with test that leads to 
> grid hang.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)