[jira] [Updated] (IGNITE-7003) Ability to disable WAL (Non recoverable case)

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7003:
-
Description: 
1) WAL should be disabled by custom discovery message 
- without triggering exchange,
- without triggering checkpoint (since it's non recoverable case)

In case someone is trying to disable already disabled WAL he should be notified 
that WAL already disabled
Only cachegroups containing one cache can de disabled

2) WAL should be prepared to be enabled by custom discovery message with 
- triggering exchange, 
- disabling cache proxies,
- waiting for checkpoints at every node.

In case someone is trying to enable already enablling WAL he should be notified 
that enabling in progress.

3) WAL should be enabled by custom discovery message 
- without triggering exchange
but
- with enabling proxies 
once all nodes finished their checkpoints.

Failover:
On any failure during loading (while WAL disabled or enabling) we should be 
able to reactivate cluster without affected caches content.
Originating node fail should be covered (at WAL disabled and enabling cases)

API:
Public API should be located at IgniteCluster

  was:
1) WAL should be disabled by custom discovery message 
- without triggering exchange,
- without triggering checkpoint (since it's non recoverable case)

In case someone is trying to disable already disabled WAL he should be notified 
that WAL already disabled
Only cachegroups containing one cache can de disabled

2) WAL should be prepared to be enabled by custom discovery message with 
- triggering exchange, 
- disabling cache proxies,
- waiting for checkpoints at every node.

In case someone is trying to enable already enablling WAL he should be notified 
that enabling in progress.

3) WAL should be enabled by custom discovery message 
- without triggering exchange
but
- with enabling proxies 
once all nodes finished their checkpoints.

Failover:
On any failure during loading (while WAL disabled or enabling) we should be 
able to reactivate cluster without affected caches content.
Originating node fail should be covered (at WAL disabled and enabling cases)


> Ability to disable WAL (Non recoverable case)
> -
>
> Key: IGNITE-7003
> URL: https://issues.apache.org/jira/browse/IGNITE-7003
> Project: Ignite
>  Issue Type: Sub-task
>  Components: persistence
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
> Fix For: 2.4
>
>
> 1) WAL should be disabled by custom discovery message 
> - without triggering exchange,
> - without triggering checkpoint (since it's non recoverable case)
> In case someone is trying to disable already disabled WAL he should be 
> notified that WAL already disabled
> Only cachegroups containing one cache can de disabled
> 2) WAL should be prepared to be enabled by custom discovery message with 
> - triggering exchange, 
> - disabling cache proxies,
> - waiting for checkpoints at every node.
> In case someone is trying to enable already enablling WAL he should be 
> notified that enabling in progress.
> 3) WAL should be enabled by custom discovery message 
> - without triggering exchange
> but
> - with enabling proxies 
> once all nodes finished their checkpoints.
> Failover:
> On any failure during loading (while WAL disabled or enabling) we should be 
> able to reactivate cluster without affected caches content.
> Originating node fail should be covered (at WAL disabled and enabling cases)
> API:
> Public API should be located at IgniteCluster



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6272) .NET: Propagate multiple services deployment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6272:


Github user asfgit closed the pull request at:

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


> .NET: Propagate multiple services deployment
> 
>
> Key: IGNITE-6272
> URL: https://issues.apache.org/jira/browse/IGNITE-6272
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Denis Mekhanikov
>Assignee: Alexey Popov
>  Labels: .NET, newbie
> Fix For: 2.4
>
>
> Multiple services deployment support should be propagated to .NET:
> * {{IgniteServices.deployAll}}
> * {{IgniteServices.deployAllAsync}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6272) .NET: Propagate multiple services deployment

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6272:


Merged to master: {{1d906b330c28a1a4fbb7057a25d96bff3d7646a0}}.

> .NET: Propagate multiple services deployment
> 
>
> Key: IGNITE-6272
> URL: https://issues.apache.org/jira/browse/IGNITE-6272
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Denis Mekhanikov
>Assignee: Alexey Popov
>  Labels: .NET, newbie
> Fix For: 2.4
>
>
> Multiple services deployment support should be propagated to .NET:
> * {{IgniteServices.deployAll}}
> * {{IgniteServices.deployAllAsync}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6341) Use direct IO or libaio for file page store and WAL where applicable

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-6341:
--

Using direct IO for page store removes double memory overhead for pages in 
memory.

> Use direct IO or libaio for file page store and WAL where applicable
> 
>
> Key: IGNITE-6341
> URL: https://issues.apache.org/jira/browse/IGNITE-6341
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>
> Need try to use direct IO or libaio for WAL writer thread because once data 
> buffer is serialized, we can write it as disk pages (this will also make it 
> easier if we decide to open file as a block device).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6341) Use direct IO or libaio for file page store and WAL where applicable

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-6341:
-
Summary: Use direct IO or libaio for file page store and WAL where 
applicable  (was: WAL: Use direct IO or libaio for writer thread)

> Use direct IO or libaio for file page store and WAL where applicable
> 
>
> Key: IGNITE-6341
> URL: https://issues.apache.org/jira/browse/IGNITE-6341
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>
> Need try to use direct IO or libaio for WAL writer thread because once data 
> buffer is serialized, we can write it as disk pages (this will also make it 
> easier if we decide to open file as a block device).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7017) Reconsider WAL archive strategy

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7017:


 Summary: Reconsider WAL archive strategy
 Key: IGNITE-7017
 URL: https://issues.apache.org/jira/browse/IGNITE-7017
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.3
Reporter: Alexey Goncharuk
 Fix For: 2.4


Currently, we write WAL files in work directory and then copy them to the 
archive after the segment is closed. 
This was done to overcome XFS bug which leads to a double fsync cost 
immediately after file creation. This approach leads to excessive disk usage 
and can be optimized, especially for LOG_ONLY mode.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7016) Avoid fsync on WAL rollover in non-default mode

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7016:


 Summary: Avoid fsync on WAL rollover in non-default mode
 Key: IGNITE-7016
 URL: https://issues.apache.org/jira/browse/IGNITE-7016
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.3
Reporter: Alexey Goncharuk
 Fix For: 2.4






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-5938) Implement WAL logs compaction and compression after checkpoint

[Andrey Gura (JIRA)]

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

Andrey Gura resolved IGNITE-5938.
-
Resolution: Fixed

> Implement WAL logs compaction and compression after checkpoint
> --
>
> Key: IGNITE-5938
> URL: https://issues.apache.org/jira/browse/IGNITE-5938
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
> Fix For: 2.4
>
>
> Currently, we simply move WAL segments to archive when WAL segment is written 
> and delete when checkpoint history becomes too old. 
> Archived WAL segment contains physical delta records that are no longer 
> needed for rebalancing, so these records may be thrown away. In order to 
> optimize disk space and delta WAL rebalancing, we can do the following:
> 1) Clean the WAL segments from the physical records
> 2) Compress the cleaned segments (I expect this to be very effective since we 
> write full objects)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5938) Implement WAL logs compaction and compression after checkpoint

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-5938:
-

Merged to master branch.

> Implement WAL logs compaction and compression after checkpoint
> --
>
> Key: IGNITE-5938
> URL: https://issues.apache.org/jira/browse/IGNITE-5938
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
> Fix For: 2.4
>
>
> Currently, we simply move WAL segments to archive when WAL segment is written 
> and delete when checkpoint history becomes too old. 
> Archived WAL segment contains physical delta records that are no longer 
> needed for rebalancing, so these records may be thrown away. In order to 
> optimize disk space and delta WAL rebalancing, we can do the following:
> 1) Clean the WAL segments from the physical records
> 2) Compress the cleaned segments (I expect this to be very effective since we 
> write full objects)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6272) .NET: Propagate multiple services deployment

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-6272:
--

I double checked the binary compatibility should not be broken by a new field.

> .NET: Propagate multiple services deployment
> 
>
> Key: IGNITE-6272
> URL: https://issues.apache.org/jira/browse/IGNITE-6272
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Denis Mekhanikov
>Assignee: Alexey Popov
>  Labels: .NET, newbie
> Fix For: 2.4
>
>
> Multiple services deployment support should be propagated to .NET:
> * {{IgniteServices.deployAll}}
> * {{IgniteServices.deployAllAsync}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 11/24/17 3:58 PM:


When entry is updated, both 'invoke update' and get\put\remove metrics can be 
updated.
When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
If entry processor process(...) is called once, and multiple entries(perhaps on 
different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once.
Read-only 'invoke' operation is processor invocation without calling 
entry.setValue(...) (even entry.getValue() can not be called), processor can 
return non-null value.Also, cache might be empty while processor invocation.


was (Author: alexey kuznetsov):
When entry is updated, both 'invoke update' and get\put\remove metrics updated.
When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
If entry processor process(...) is called once, and multiple entries(perhaps on 
different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once.
Read-only 'invoke' operation is processor invocation without calling 
entry.setValue(...) (even entry.getValue() can not be called), processor still 
can return nin-null value.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 11/24/17 3:58 PM:


1)When entry is updated, both 'invoke update' and get\put\remove metrics can be 
updated.
2)When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
3)'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
4)If entry processor process(...) is called once, and multiple entries(perhaps 
on different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once.
5)Read-only 'invoke' operation is processor invocation without calling 
entry.setValue(...) (even entry.getValue() can not be called), processor can 
return non-null value.Also, cache might be empty while processor invocation.


was (Author: alexey kuznetsov):
When entry is updated, both 'invoke update' and get\put\remove metrics can be 
updated.
When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
If entry processor process(...) is called once, and multiple entries(perhaps on 
different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once.
Read-only 'invoke' operation is processor invocation without calling 
entry.setValue(...) (even entry.getValue() can not be called), processor can 
return non-null value.Also, cache might be empty while processor invocation.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7003) Ability to disable WAL (Non recoverable case)

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7003:
-
Description: 
1) WAL should be disabled by custom discovery message 
- without triggering exchange,
- without triggering checkpoint (since it's non recoverable case)

In case someone is trying to disable already disabled WAL he should be notified 
that WAL already disabled
Only cachegroups containing one cache can de disabled

2) WAL should be prepared to be enabled by custom discovery message with 
- triggering exchange, 
- disabling cache proxies,
- waiting for checkpoints at every node.

In case someone is trying to enable already enablling WAL he should be notified 
that enabling in progress.

3) WAL should be enabled by custom discovery message 
- without triggering exchange
but
- with enabling proxies 
once all nodes finished their checkpoints.

Failover:
On any failure during loading (while WAL disabled or enabling) we should be 
able to reactivate cluster without affected caches content.
Originating node fail should be covered (at WAL disabled and enabling cases)

  was:
1) WAL should be disabled by custom discovery message without 
- triggering exchange,
- triggering checkpoint (since it's non recoverable case)

In case someone is trying to disable already disabled WAL he should be notified 
that WAL already disabled
Only cachegroups containing one cache can de disabled

2) WAL should be prepared to be enabled by custom discovery message with 
- triggering exchange, 
- disabling cache proxies,
- waiting for checkpoints at every node.

In case someone is trying to enable already enablling WAL he should be notified 
that enabling in progress.

3) WAL should be enabled by custom discovery message 
- without triggering exchange
but
- with enabling proxies 
once all nodes finished their checkpoints.

Failover:
On any failure during loading (while WAL disabled or enabling) we should be 
able to reactivate cluster without affected caches content.
Originating node fail should be covered (at WAL disabled and enabling cases)


> Ability to disable WAL (Non recoverable case)
> -
>
> Key: IGNITE-7003
> URL: https://issues.apache.org/jira/browse/IGNITE-7003
> Project: Ignite
>  Issue Type: Sub-task
>  Components: persistence
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
> Fix For: 2.4
>
>
> 1) WAL should be disabled by custom discovery message 
> - without triggering exchange,
> - without triggering checkpoint (since it's non recoverable case)
> In case someone is trying to disable already disabled WAL he should be 
> notified that WAL already disabled
> Only cachegroups containing one cache can de disabled
> 2) WAL should be prepared to be enabled by custom discovery message with 
> - triggering exchange, 
> - disabling cache proxies,
> - waiting for checkpoints at every node.
> In case someone is trying to enable already enablling WAL he should be 
> notified that enabling in progress.
> 3) WAL should be enabled by custom discovery message 
> - without triggering exchange
> but
> - with enabling proxies 
> once all nodes finished their checkpoints.
> Failover:
> On any failure during loading (while WAL disabled or enabling) we should be 
> able to reactivate cluster without affected caches content.
> Originating node fail should be covered (at WAL disabled and enabling cases)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-7013) .NET: Ignite does not start on macOS

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7013 at 11/24/17 3:02 PM:
--

* {{jvm.dll}} is {{libjvm.dylib}} on macOs.
* lookup path is something like 
{{/Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/server/libjvm.dylib}}


was (Author: ptupitsyn):
{{jvm.dll}} is {{libjvm.dylib}} on macOs.

> .NET: Ignite does not start on macOS
> 
>
> Key: IGNITE-7013
> URL: https://issues.apache.org/jira/browse/IGNITE-7013
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Looks like dlopen code is incorrect for macOS:
> {code}
> Unhandled Exception: System.DllNotFoundException: Unable to load DLL 
> 'libcoreclr.so': The specified module or one of its dependencies could not be 
> found.
>  (Exception from HRESULT: 0x8007007E)
>at 
> Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String 
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String 
> simpleName)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at ignite_nuget_test.Program.Main(String[] args) in 
> /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17
> {code}
> Steps to reproduce:
> {code}
> git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git
> cd ignite-dotnetcore-demo
> dotnet run
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7013) .NET: Ignite does not start on macOS

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7013:


{{jvm.dll}} is {{libjvm.dylib}} on macOs.

> .NET: Ignite does not start on macOS
> 
>
> Key: IGNITE-7013
> URL: https://issues.apache.org/jira/browse/IGNITE-7013
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Looks like dlopen code is incorrect for macOS:
> {code}
> Unhandled Exception: System.DllNotFoundException: Unable to load DLL 
> 'libcoreclr.so': The specified module or one of its dependencies could not be 
> found.
>  (Exception from HRESULT: 0x8007007E)
>at 
> Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String 
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String 
> simpleName)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at ignite_nuget_test.Program.Main(String[] args) in 
> /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17
> {code}
> Steps to reproduce:
> {code}
> git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git
> cd ignite-dotnetcore-demo
> dotnet run
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6944) Fail to execute task with immutable list string

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-6944:
--

Changes look good to me

> Fail to execute task with immutable list string
> ---
>
> Key: IGNITE-6944
> URL: https://issues.apache.org/jira/browse/IGNITE-6944
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.3
>Reporter: Edmond Tsang
>Assignee: Andrey Gura
> Fix For: 2.4
>
> Attachments: BinaryMarshellerWithGuavaSelfTest.java, 
> TestClientWithGuava.java
>
>
> Exception occurs when executing task with immutable list of string due to not 
> able to find method readResolve/writeReplace for binary object.
> It appears this is caused by a side effect of Jira 
> https://issues.apache.org/jira/browse/IGNITE-6485 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7003) Ability to disable WAL (Non recoverable case)

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7003:
-
Fix Version/s: 2.4

> Ability to disable WAL (Non recoverable case)
> -
>
> Key: IGNITE-7003
> URL: https://issues.apache.org/jira/browse/IGNITE-7003
> Project: Ignite
>  Issue Type: Sub-task
>  Components: persistence
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
> Fix For: 2.4
>
>
> 1) WAL should be disabled by custom discovery message without 
> - triggering exchange,
> - triggering checkpoint (since it's non recoverable case)
> In case someone is trying to disable already disabled WAL he should be 
> notified that WAL already disabled
> Only cachegroups containing one cache can de disabled
> 2) WAL should be prepared to be enabled by custom discovery message with 
> - triggering exchange, 
> - disabling cache proxies,
> - waiting for checkpoints at every node.
> In case someone is trying to enable already enablling WAL he should be 
> notified that enabling in progress.
> 3) WAL should be enabled by custom discovery message 
> - without triggering exchange
> but
> - with enabling proxies 
> once all nodes finished their checkpoints.
> Failover:
> On any failure during loading (while WAL disabled or enabling) we should be 
> able to reactivate cluster without affected caches content.
> Originating node fail should be covered (at WAL disabled and enabling cases)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 11/24/17 2:44 PM:


When entry is updated, both 'invoke update' and get\put\remove metrics updated.
When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
If entry processor process(...) is called once, and multiple entries(perhaps on 
different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once.
Read-only 'invoke' operation is processor invocation without calling 
entry.setValue(...) (even entry.getValue() can not be called), processor still 
can return nin-null value.


was (Author: alexey kuznetsov):
When entry is updated, both 'invoke update' and get\put\remove metrics updated.
When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
If entry processor process(...) is called once, and multiple entries(perhaps on 
different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once.
Read-only 'invoke' operation is processor invocation without calling 
entry.setValue(...), processor still can return nin-null value.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6903) Implement new JMX metrics for Indexing

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov reassigned IGNITE-6903:
---

Assignee: Nikolay Izhikov

> Implement new JMX metrics for Indexing
> --
>
> Key: IGNITE-6903
> URL: https://issues.apache.org/jira/browse/IGNITE-6903
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Space occupied by indexes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 11/24/17 2:41 PM:


When entry is updated, both 'invoke update' and get\put\remove metrics updated.
When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
If entry processor process(...) is called once, and multiple entries(perhaps on 
different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once.
Read-only 'invoke' operation is processor invocation without calling 
entry.setValue(...), processor still can return nin-null value.


was (Author: alexey kuznetsov):
when entry is updated, both 'invoke update' and get\put\remove metrics updated.
when entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
'invoke * ' metrics incremented only when cache entry value is affected(read or 
updated) by entry processor(not just when entry processor is invoked).If entry 
processor is called once, and multiple entries(on different nodes) are 
affected, then local invoke metric is incremented only once, cluster global 
metric is incremented once.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6411) Add ability to disable WAL for ceratin caches in runtime

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6411:

Fix Version/s: 2.4

> Add ability to disable WAL for ceratin caches in runtime
> 
>
> Key: IGNITE-6411
> URL: https://issues.apache.org/jira/browse/IGNITE-6411
> Project: Ignite
>  Issue Type: Task
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Anton Vinogradov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently every cache update require write to WAL. When doing bulk data load 
> usually crash recovery is not needed. If something went wrong during data 
> load, we should simply purge all intermediate data on cache restart.
> It makes sense to add ability to disable WAL for ceratin caches. Depending on 
> restrictions of current architecture, it could be done on per-cache, 
> per-cache-group or per-memory-policy level.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6409) SQL: bypass H2 during index update

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6409:

Labels: performance  (was: iep-1 performance)

> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> Currently the only way to update standard user index is through H2 
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
> we have to construct a kind of H2 row which will be passed to index. This 
> operation might require unnecessary memory copying and deserializations. We 
> should try to find a way to bypass H2 stuff altogether and add data to 
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:
> 1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
> ({{InlineIndexHelper}}, {{H2*IO}}). 
> 2) We should remove all H2 stuff from there, and start using {{CacheDataRow}} 
> instead of {{SearchRow}}
> 3) Refactored classes should be moved to core module.
> 4) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when 
> it is really needed.
> 5) Two operations {{putNative}} and {{getNative}} should be added to 
> {{GridH2IndexBase}}. They should accept normal key-value objects instead of 
> H2 rows.
> 6) Finally, all index index update routines (cache put/get, {{CREATE INDEX}}) 
> should be moved to {{putNative}}/{{getNative}} methods.
> Note that IO classes should be reworked carefully to maintain backward 
> compatibility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6057) SQL: Full scan should be performed through data pages bypassing primary index

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6057:

Labels: performance  (was: iep-1 performance)

> SQL: Full scan should be performed through data pages bypassing primary index
> -
>
> Key: IGNITE-6057
> URL: https://issues.apache.org/jira/browse/IGNITE-6057
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
>
> Currently both SQL full scan and {{CREATE INDEX}} commands iterate through 
> primary index to get all existing values. Consider that we have 10 entries 
> per data page on average. In this case we will have to read the same data 
> page 10 times when reaching relevant keys in different parts of index tree. 
> This could be very inefficient on certain workloads.
> We should iterate over data pages directly instead. This way a page with 10 
> entries will be accessed only once. However, we should take cache groups in 
> count - if there are too many entries from other logical caches, this 
> approach could make situation even worse, unless we have a mechanism to skip 
> unnecessary entries (or the whole pages!) efficiently.
> Probably we should develop a cost-based model, which will take in count the 
> following statistics:
> 1) Average entry size. The longer the entry, the lesser the benefit. 
> Especially if overflow pages are used frequently. 
> 2) Cache groups. Ideally, we should estimate number of entries from all 
> logical caches. The more entries from other caches, the lesser the benefit.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7015) SQL: index should be updated only when relevant values changed

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7015:

Labels: iep-1 performance  (was: iep-1)

> SQL: index should be updated only when relevant values changed
> --
>
> Key: IGNITE-7015
> URL: https://issues.apache.org/jira/browse/IGNITE-7015
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> See {{GridH2Table.update}} method. Whenever value is updated, we propagate it 
> to all indexes. Consider the following case:
> 1) Old row is not null, so this is "update", not "create".
> 2) Link hasn't changed
> 3) Indexed fields haven't changed
> If all conditions are met, we can skip index update completely, as state 
> before and after will be the same. This is especially important when 
> persistence is enabled because currently we generate unnecessary dirty pages 
> what increases IO pressure.
> Suggested fix:
> 1) Iterate over index columns, skipping key and affinity columns (as they are 
> guaranteed to be the same);
> 2) Compare relevant index columns of both old and new rows
> 3) If all columns are equal, do nothing.
> Fields should be read through {{GridH2KeyValueRowOnheap#getValue}}, because 
> in this case we will re-use value cache transparently.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7014) SQL: in-place update should be allowed when indexing is enabled

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7014:

Labels: iep-1 performance  (was: iep-1)

> SQL: in-place update should be allowed when indexing is enabled
> ---
>
> Key: IGNITE-7014
> URL: https://issues.apache.org/jira/browse/IGNITE-7014
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> See {{IgniteCacheOffheapManagerImpl.canUpdateOldRow}} - if cache has at least 
> one query entity, in-place updates are not possible. This drastically reduces 
> performance of DML and regular update (cache API) operations. 
> We need to understand whether any explanation of this restriction exists. In 
> any case, in-place updates should be allowed for SQL-enabled caches.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7015) SQL: index should be updated only when relevant values changed

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-7015:

Labels: iep-1  (was: )

> SQL: index should be updated only when relevant values changed
> --
>
> Key: IGNITE-7015
> URL: https://issues.apache.org/jira/browse/IGNITE-7015
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>  Labels: iep-1
> Fix For: 2.4
>
>
> See {{GridH2Table.update}} method. Whenever value is updated, we propagate it 
> to all indexes. Consider the following case:
> 1) Old row is not null, so this is "update", not "create".
> 2) Link hasn't changed
> 3) Indexed fields haven't changed
> If all conditions are met, we can skip index update completely, as state 
> before and after will be the same. This is especially important when 
> persistence is enabled because currently we generate unnecessary dirty pages 
> what increases IO pressure.
> Suggested fix:
> 1) Iterate over index columns, skipping key and affinity columns (as they are 
> guaranteed to be the same);
> 2) Compare relevant index columns of both old and new rows
> 3) If all columns are equal, do nothing.
> Fields should be read through {{GridH2KeyValueRowOnheap#getValue}}, because 
> in this case we will re-use value cache transparently.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7015) SQL: index should be updated only when relevant values changed

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7015:
---

 Summary: SQL: index should be updated only when relevant values 
changed
 Key: IGNITE-7015
 URL: https://issues.apache.org/jira/browse/IGNITE-7015
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.4


See {{GridH2Table.update}} method. Whenever value is updated, we propagate it 
to all indexes. Consider the following case:
1) Old row is not null, so this is "update", not "create".
2) Link hasn't changed
3) Indexed fields haven't changed

If all conditions are met, we can skip index update completely, as state before 
and after will be the same. This is especially important when persistence is 
enabled because currently we generate unnecessary dirty pages what increases IO 
pressure.

Suggested fix:
1) Iterate over index columns, skipping key and affinity columns (as they are 
guaranteed to be the same);
2) Compare relevant index columns of both old and new rows
3) If all columns are equal, do nothing.

Fields should be read through {{GridH2KeyValueRowOnheap#getValue}}, because in 
this case we will re-use value cache transparently.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7014) SQL: in-place update should be allowed when indexing is enabled

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7014:
---

 Summary: SQL: in-place update should be allowed when indexing is 
enabled
 Key: IGNITE-7014
 URL: https://issues.apache.org/jira/browse/IGNITE-7014
 Project: Ignite
  Issue Type: Task
  Components: cache, sql
Reporter: Vladimir Ozerov
 Fix For: 2.4


See {{IgniteCacheOffheapManagerImpl.canUpdateOldRow}} - if cache has at least 
one query entity, in-place updates are not possible. This drastically reduces 
performance of DML and regular update (cache API) operations. 

We need to understand whether any explanation of this restriction exists. In 
any case, in-place updates should be allowed for SQL-enabled caches.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6989) .NET: Thin client: Group operation codes by purpose

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-6989 at 11/24/17 1:34 PM:
--

Proposed schema:
* 0,1,... - general-purpose operations (we don't have any?)
* 100, 101, ... - cache operations
* 200, ... - quries
* 300, ... - metadata operations


was (Author: ptupitsyn):
Proposed schema:
* 0,1,2,... - general-purpose operations, OP_CACHE_GET, OP_CACHE_DESTROY, etc
* 100, 101, ... - cache operations
* 200, ... - quries
* 300, ... - metadata operations

> .NET: Thin client: Group operation codes by purpose
> ---
>
> Key: IGNITE-6989
> URL: https://issues.apache.org/jira/browse/IGNITE-6989
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Currently operation codes are in random order. Let's group things by purpose: 
> cache operations, metadata, queries, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7013) .NET: Ignite does not start on macOS

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7013:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-7013 .NET: Fix startup on macOS (dlopen call)



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

$ git pull https://github.com/ptupitsyn/ignite ignite-7013

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

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


commit 071010551e3cde09e206c168408f13a3c15e615e
Author: Pavel Tupitsyn 
Date:   2017-11-24T13:06:10Z

IGNITE-7013 .NET: Ignite does not start on macOS




> .NET: Ignite does not start on macOS
> 
>
> Key: IGNITE-7013
> URL: https://issues.apache.org/jira/browse/IGNITE-7013
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Looks like dlopen code is incorrect for macOS:
> {code}
> Unhandled Exception: System.DllNotFoundException: Unable to load DLL 
> 'libcoreclr.so': The specified module or one of its dependencies could not be 
> found.
>  (Exception from HRESULT: 0x8007007E)
>at 
> Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String 
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String 
> simpleName)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at ignite_nuget_test.Program.Main(String[] args) in 
> /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17
> {code}
> Steps to reproduce:
> {code}
> git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git
> cd ignite-dotnetcore-demo
> dotnet run
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6990) .NET: Thin client: Remove OP_SQL_QUERY

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6990:


Turns out {{SqlQuery}} and {{SqlFieldsQuery}} are too different to sit on the 
same op code. In particular, {{SqlQuery}} requires {{string className}}, which 
does not fit at all with fields query.

Won't fix.

> .NET: Thin client: Remove OP_SQL_QUERY
> --
>
> Key: IGNITE-6990
> URL: https://issues.apache.org/jira/browse/IGNITE-6990
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> OP_SQL_QUERY is not necessary and can be implemented on the client side with 
> OP_SQL_FIELDS_QUERY.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6929) Preserve mvcc versions on index rebuild

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6929:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-6929



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

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

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

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


commit f6e982540e65ab17d439dba990794f35616a30dd
Author: sboikov 
Date:   2017-08-30T09:45:40Z

ignite-3478

commit 275a85db5cd6923b36126166ae99b15e876192be
Author: sboikov 
Date:   2017-08-31T07:44:07Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit b7b9089f0102b8cab9942a9c887d93e9f26cc7d2
Author: sboikov 
Date:   2017-08-31T09:00:36Z

disco cache cleanup

commit 855c2d45794c300d41e386b4e6fa40736cc3e40d
Author: sboikov 
Date:   2017-08-31T09:09:58Z

Merge branch 'ignite-3478-1' into ignite-3478

commit 08be7310a93d3ce455215b97cf8ab1a2c3f0ab31
Author: sboikov 
Date:   2017-08-31T09:52:23Z

ignite-3478

commit fce2e31f0fd2f4f6a9944422e40408a0c65cfe90
Author: sboikov 
Date:   2017-09-04T08:13:50Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit d3c049952384750c5543a9f88b383c033ef74096
Author: sboikov 
Date:   2017-09-04T08:52:11Z

ignite-3478

commit e71ce1937a18dd32448e92b1038dc48d4cb6f8ab
Author: sboikov 
Date:   2017-09-04T10:16:03Z

ignite-3478

commit 5fac5b0965e97f8951e16e10ca9229a2e78ddb0c
Author: sboikov 
Date:   2017-09-05T10:16:44Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java

commit 2e0c9c08e046e8d6af1b5358d9053eae999b1fb4
Author: sboikov 
Date:   2017-09-05T11:30:55Z

ignite-3478

commit e1e07ffdf2d711ba3e72f316f5a3970eff27372e
Author: sboikov 
Date:   2017-09-05T11:31:14Z

ignite-3478

commit cbada3934a386668da0b11d4de7d0f58a4d04dfe
Author: sboikov 
Date:   2017-09-05T11:49:49Z

ignite-3484

commit 5a82c68dcd1927bb6fded8b7def38c91ff6e145b
Author: sboikov 
Date:   2017-09-05T11:59:49Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit bc9134c94b7a738dc1664e96ca6eabb059f1c268
Author: sboikov 
Date:   2017-09-05T12:03:39Z

Merge branch 'ignite-3478' into ignite-3484

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/tree/AbstractDataInnerIO.java

commit b4bfcde78825c6517232e49d389bdb5de19f05a9
Author: sboikov 
Date:   2017-09-05T12:27:51Z

ignite-3484

commit 43834aaab9e2c3cd5fdd55289fdc4a9ff8ab6599
Author: sboikov 
Date:   2017-09-05T13:13:00Z

ignite-3478

commit d1b828095713fcadfa260cf94fef01b42a1b12fd
Author: sboikov 
Date:   2017-09-05T13:13:33Z

Merge branch 'ignite-3478' into ignite-3484

commit 6be6779b6336c36cd71eef0a25199a6a877ce6b5
Author: sboikov 
Date:   2017-09-05T13:47:11Z

ignite-3484

commit e3bba83256c1eb53c4b40fbd9ddba47fcf9d58d5
Author: sboikov 
Date:   2017-09-06T07:10:26Z

ignite-3484

commit dd0afb28466094b801506da8afa3601bfaebd853
Author: sboikov 
Date:   2017-09-06T07:30:04Z

ignite-3484

commit 27b87b413348b03986a463551db24b7726321732
Author: sboikov 
Date:   2017-09-06T08:19:18Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java

commit dcaf8801accd6ee089849a82b2ccd558aec81895
Author: sboikov 
Date:   2017-09-06T08:19:30Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java

commit c966451d0bf7059575de92bcfae43d72096ebce4
Author: sboikov 
Date:   2017-09-06T08:27:04Z

Merge branch 'ignite-3478' into ignite-3484

commit 91b9911731a387a3199ddbbc22704bc14af09995
Author: sboikov 

[jira] [Updated] (IGNITE-6057) SQL: Full scan should be performed through data pages bypassing primary index

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6057:

Labels: performance  (was: iep-1 performance)

> SQL: Full scan should be performed through data pages bypassing primary index
> -
>
> Key: IGNITE-6057
> URL: https://issues.apache.org/jira/browse/IGNITE-6057
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
>
> Currently both SQL full scan and {{CREATE INDEX}} commands iterate through 
> primary index to get all existing values. Consider that we have 10 entries 
> per data page on average. In this case we will have to read the same data 
> page 10 times when reaching relevant keys in different parts of index tree. 
> This could be very inefficient on certain workloads.
> We should iterate over data pages directly instead. This way a page with 10 
> entries will be accessed only once. However, we should take cache groups in 
> count - if there are too many entries from other logical caches, this 
> approach could make situation even worse, unless we have a mechanism to skip 
> unnecessary entries (or the whole pages!) efficiently.
> Probably we should develop a cost-based model, which will take in count the 
> following statistics:
> 1) Average entry size. The longer the entry, the lesser the benefit. 
> Especially if overflow pages are used frequently. 
> 2) Cache groups. Ideally, we should estimate number of entries from all 
> logical caches. The more entries from other caches, the lesser the benefit.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6057) SQL: Full scan should be performed through data pages bypassing primary index

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6057:

Labels: iep-1 performance  (was: performance)

> SQL: Full scan should be performed through data pages bypassing primary index
> -
>
> Key: IGNITE-6057
> URL: https://issues.apache.org/jira/browse/IGNITE-6057
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
>
> Currently both SQL full scan and {{CREATE INDEX}} commands iterate through 
> primary index to get all existing values. Consider that we have 10 entries 
> per data page on average. In this case we will have to read the same data 
> page 10 times when reaching relevant keys in different parts of index tree. 
> This could be very inefficient on certain workloads.
> We should iterate over data pages directly instead. This way a page with 10 
> entries will be accessed only once. However, we should take cache groups in 
> count - if there are too many entries from other logical caches, this 
> approach could make situation even worse, unless we have a mechanism to skip 
> unnecessary entries (or the whole pages!) efficiently.
> Probably we should develop a cost-based model, which will take in count the 
> following statistics:
> 1) Average entry size. The longer the entry, the lesser the benefit. 
> Especially if overflow pages are used frequently. 
> 2) Cache groups. Ideally, we should estimate number of entries from all 
> logical caches. The more entries from other caches, the lesser the benefit.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5885) .NET: Add x86 tests on TeamCity

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-5885:
--

Assignee: (was: Pavel Tupitsyn)

> .NET: Add x86 tests on TeamCity
> ---
>
> Key: IGNITE-5885
> URL: https://issues.apache.org/jira/browse/IGNITE-5885
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
>
> Just copy a configuration and change NUnit bitness.
> We should probably run only a subset of tests (introduce "BASIC_TEST" 
> category or something).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5885) .NET: Add x86 tests on TeamCity

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5885:
---
Fix Version/s: (was: 2.4)

> .NET: Add x86 tests on TeamCity
> ---
>
> Key: IGNITE-5885
> URL: https://issues.apache.org/jira/browse/IGNITE-5885
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> Just copy a configuration and change NUnit bitness.
> We should probably run only a subset of tests (introduce "BASIC_TEST" 
> category or something).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7013) .NET: Ignite does not start on macOS

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7013:


MacOS dlopen should look like this:

{code}
[DllImport("libSystem.dylib")]
internal static extern IntPtr dlopen(string filename, int flags);
{code}

> .NET: Ignite does not start on macOS
> 
>
> Key: IGNITE-7013
> URL: https://issues.apache.org/jira/browse/IGNITE-7013
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Looks like dlopen code is incorrect for macOS:
> {code}
> Unhandled Exception: System.DllNotFoundException: Unable to load DLL 
> 'libcoreclr.so': The specified module or one of its dependencies could not be 
> found.
>  (Exception from HRESULT: 0x8007007E)
>at 
> Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String 
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String 
> simpleName)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at ignite_nuget_test.Program.Main(String[] args) in 
> /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17
> {code}
> Steps to reproduce:
> {code}
> git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git
> cd ignite-dotnetcore-demo
> dotnet run
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7013) .NET: Ignite does not start on macOS

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7013:
--

 Summary: .NET: Ignite does not start on macOS
 Key: IGNITE-7013
 URL: https://issues.apache.org/jira/browse/IGNITE-7013
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.4


Looks like dlopen code is incorrect for macOS:

{code}
Unhandled Exception: System.DllNotFoundException: Unable to load DLL 
'libcoreclr.so': The specified module or one of its dependencies could not be 
found.
 (Exception from HRESULT: 0x8007007E)
   at 
Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String 
filename, Int32 flags)
   at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath)
   at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String 
simpleName)
   at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, 
ILogger log)
   at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
ILogger log)
   at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
   at ignite_nuget_test.Program.Main(String[] args) in 
/Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17
{code}

Steps to reproduce:
{code}
git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git
cd ignite-dotnetcore-demo
dotnet run
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6990) .NET: Thin client: Remove OP_SQL_QUERY

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6990:


We should add {{IsFieldsQuery}} flag to indicate whether simplified syntax of 
SqlQuery or full syntax of SqlFieldsQuery is used.

> .NET: Thin client: Remove OP_SQL_QUERY
> --
>
> Key: IGNITE-6990
> URL: https://issues.apache.org/jira/browse/IGNITE-6990
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> OP_SQL_QUERY is not necessary and can be implemented on the client side with 
> OP_SQL_FIELDS_QUERY.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6989) .NET: Thin client: Group operation codes by purpose

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6989:


Proposed schema:
* 0,1,2,... - general-purpose operations, OP_CACHE_GET, OP_CACHE_DESTROY, etc
* 100, 101, ... - cache operations
* 200, ... - quries
* 300, ... - metadata operations

> .NET: Thin client: Group operation codes by purpose
> ---
>
> Key: IGNITE-6989
> URL: https://issues.apache.org/jira/browse/IGNITE-6989
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Currently operation codes are in random order. Let's group things by purpose: 
> cache operations, metadata, queries, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7010) Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events

[Krzysztof Chmielewski (JIRA)]

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

Krzysztof Chmielewski commented on IGNITE-7010:
---

fixed with 
{code}
node.compute(node.cluster().forLocal()).runAsync(
// cache destroy Runnable
);
{code}

> Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events
> ---
>
> Key: IGNITE-7010
> URL: https://issues.apache.org/jira/browse/IGNITE-7010
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Krzysztof Chmielewski
>
> Ignite hangs trying to delete cache as a response to Ignite Event 
> EventType.EVT_NODE_LEFT.
> Code to reproduce this issue is available at 
> https://github.com/kristoffSC/IgniteHang
> Reproduce instructions:
> # Put break points in ServerStarter.java line 40 and 42.
> # Start ServerStarter as Java Application in Debug mode.
> # Start ClientStarter as Java Application. After ClientStarter ends, 
> ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
> Try skip to next line ({code}ignite.destroyCache("testCache"){code}) and then 
> try skip one more line. Ignite will hang at line 41.
> This "hang" prevents other nodes from connecting to this running/hanging 
> Ignite Server.
> Thread that stuck is "disco-event-worker". It waits on {code} return 
> stopFut.get() {code} in IgniteKernel.class at line 3146



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6988) .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-6988 at 11/24/17 10:43 AM:
---

Fixed in master: {{555fcebb2261e0ce3cfb1713a4322fad69505d2c}}.

Protocol doc updated: 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-9+Thin+Client+Protocol


was (Author: ptupitsyn):
Fixed in master: {{555fcebb2261e0ce3cfb1713a4322fad69505d2c}}.

> .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name
> ---
>
> Key: IGNITE-6988
> URL: https://issues.apache.org/jira/browse/IGNITE-6988
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> All cache operations take cacheId, not cache name. Fix this for 
> OP_CACHE_DESTROY.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-7010) Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events

[Krzysztof Chmielewski (JIRA)]

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

Krzysztof Chmielewski closed IGNITE-7010.
-

> Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events
> ---
>
> Key: IGNITE-7010
> URL: https://issues.apache.org/jira/browse/IGNITE-7010
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Krzysztof Chmielewski
>
> Ignite hangs trying to delete cache as a response to Ignite Event 
> EventType.EVT_NODE_LEFT.
> Code to reproduce this issue is available at 
> https://github.com/kristoffSC/IgniteHang
> Reproduce instructions:
> # Put break points in ServerStarter.java line 40 and 42.
> # Start ServerStarter as Java Application in Debug mode.
> # Start ClientStarter as Java Application. After ClientStarter ends, 
> ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
> Try skip to next line ({code}ignite.destroyCache("testCache"){code}) and then 
> try skip one more line. Ignite will hang at line 41.
> This "hang" prevents other nodes from connecting to this running/hanging 
> Ignite Server.
> Thread that stuck is "disco-event-worker". It waits on {code} return 
> stopFut.get() {code} in IgniteKernel.class at line 3146



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6988) .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-6988.

Resolution: Fixed

> .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name
> ---
>
> Key: IGNITE-6988
> URL: https://issues.apache.org/jira/browse/IGNITE-6988
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> All cache operations take cacheId, not cache name. Fix this for 
> OP_CACHE_DESTROY.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6988) .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6988:


Fixed in master: {{555fcebb2261e0ce3cfb1713a4322fad69505d2c}}.

> .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name
> ---
>
> Key: IGNITE-6988
> URL: https://issues.apache.org/jira/browse/IGNITE-6988
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> All cache operations take cacheId, not cache name. Fix this for 
> OP_CACHE_DESTROY.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 11/24/17 10:30 AM:
-

when entry is updated, both 'invoke update' and get\put\remove metrics updated.
when entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
'invoke * ' metrics incremented only when cache entry value is affected(read or 
updated) by entry processor(not just when entry processor is invoked).If entry 
processor is called once, and multiple entries(on different nodes) are 
affected, then local invoke metric is incremented only once, cluster global 
metric is incremented once.


was (Author: alexey kuznetsov):
when entry is updated, both 'invoke update' and get\put\remove metrics updated.
when entry processor is invoked, but cache entry isn't affected then invoke 
metric isn't incremented.
'invoke * ' metrics incremented only when cache entry value is affected(read or 
updated) by entry processor(not just when entry processor is invoked).If entry 
processor is called once, and multiple entries are affected, then local invoke 
metric is incremented only once, cluster global metric is incremented once.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6988) .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6988:
---
Summary: .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of 
name  (was: .NET: Thin client: OP_DESTROY_CACHE should take cacheId instead of 
name)

> .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name
> ---
>
> Key: IGNITE-6988
> URL: https://issues.apache.org/jira/browse/IGNITE-6988
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> All cache operations take cacheId, not cache name. Fix this for 
> OP_DESTROY_CACHE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6988) .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6988:
---
Description: All cache operations take cacheId, not cache name. Fix this 
for OP_CACHE_DESTROY.  (was: All cache operations take cacheId, not cache name. 
Fix this for OP_DESTROY_CACHE.)

> .NET: Thin client: OP_CACHE_DESTROY should take cacheId instead of name
> ---
>
> Key: IGNITE-6988
> URL: https://issues.apache.org/jira/browse/IGNITE-6988
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> All cache operations take cacheId, not cache name. Fix this for 
> OP_CACHE_DESTROY.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-7010) Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov resolved IGNITE-7010.
--
Resolution: Not A Bug

Synchronous cache.destroy() call in listener is delay current topology changing 
procedure until it has finished with no success of course.

> Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events
> ---
>
> Key: IGNITE-7010
> URL: https://issues.apache.org/jira/browse/IGNITE-7010
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Krzysztof Chmielewski
>
> Ignite hangs trying to delete cache as a response to Ignite Event 
> EventType.EVT_NODE_LEFT.
> Code to reproduce this issue is available at 
> https://github.com/kristoffSC/IgniteHang
> Reproduce instructions:
> # Put break points in ServerStarter.java line 40 and 42.
> # Start ServerStarter as Java Application in Debug mode.
> # Start ClientStarter as Java Application. After ClientStarter ends, 
> ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
> Try skip to next line ({code}ignite.destroyCache("testCache"){code}) and then 
> try skip one more line. Ignite will hang at line 41.
> This "hang" prevents other nodes from connecting to this running/hanging 
> Ignite Server.
> Thread that stuck is "disco-event-worker". It waits on {code} return 
> stopFut.get() {code} in IgniteKernel.class at line 3146



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5602) By bytes access to binary format

[Andrey Davydov (JIRA)]

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

Andrey Davydov commented on IGNITE-5602:


I'm sorry. I miss notification about you comment. No problem. Feel free to 
refactor as need. My patch is just proof of concept.

> By bytes access to binary format
> 
>
> Key: IGNITE-5602
> URL: https://issues.apache.org/jira/browse/IGNITE-5602
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.0
>Reporter: Vladislav Pyatkov
> Attachments: 
> 0001-Implement-streaming-API-to-BinaryObject.-See-IGNITE-.patch
>
>
> Need to avoid memory additional allocation when pass bytes to stream.
> Now we are doing only
> {code}
> BinaryObject get = (BinaryObject) cache.get(key);
> byte[] dataFromCache = get.field("data");
> System.out.write(dataFromCache, 0, dataFromCache.length);
> {code}
> But we want to write bytes to stream directly, without allocation additional 
> {{byte[]}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7012) Web console: investigate E2E tests

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-7012:


 Summary: Web console: investigate E2E tests
 Key: IGNITE-7012
 URL: https://issues.apache.org/jira/browse/IGNITE-7012
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Ilya Borisov
Assignee: Alexander Kalinin
Priority: Minor


Investigate what tools we can use to implement E2E tests and try some of them 
out. I think that testcafe will be a good start:
https://github.com/DevExpress/testcafe
https://github.com/DevExpress/testcafe-angular-selectors



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6891) Proper behavior on Persistence errors

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin reassigned IGNITE-6891:
---

Assignee: Dmitriy Sorokin

> Proper behavior on Persistence errors 
> --
>
> Key: IGNITE-6891
> URL: https://issues.apache.org/jira/browse/IGNITE-6891
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7
> Fix For: 2.4
>
>
> Node should be stopped anyway, what we can provide is user callback, 
> something like beforeNodeStop'.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7011) Web console: add more tests

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-7011:


 Summary: Web console: add more tests
 Key: IGNITE-7011
 URL: https://issues.apache.org/jira/browse/IGNITE-7011
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov
Priority: Minor


Web console does not have enough test coverage, let's fix that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session

[Jason Man (JIRA)]

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

Jason Man commented on IGNITE-6853:
---

PR available above with the fix.  Please review.  Thanks.

> Cassandra cache store does not clean prepared statements cache when remove 
> old cassandra session
> 
>
> Key: IGNITE-6853
> URL: https://issues.apache.org/jira/browse/IGNITE-6853
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
> Fix For: 2.4
>
>
> Cassandra cache store does not clean prepared statements cache when remove 
> old cassandra session which can lead to:
>  Prepared
> statement cluster error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute
> unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have
> used a PreparedStatement that was created with another Cluster instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6853:


GitHub user jasonman107 opened a pull request:

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

IGNITE-6853: Cassandra cache store does not clean prepared statements…

IGNITE-6853: Cassandra cache store does not clean prepared statements cache 
when remove old cassandra session

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

$ git pull https://github.com/jasonman107/ignite ignite-6853

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

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


commit a025adba87d7f4df8f8c9b13a9ceaf9eb80942b9
Author: Jason Man 
Date:   2017-11-24T08:52:57Z

IGNITE-6853: Cassandra cache store does not clean prepared statements cache 
when remove old cassandra session




> Cassandra cache store does not clean prepared statements cache when remove 
> old cassandra session
> 
>
> Key: IGNITE-6853
> URL: https://issues.apache.org/jira/browse/IGNITE-6853
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
> Fix For: 2.4
>
>
> Cassandra cache store does not clean prepared statements cache when remove 
> old cassandra session which can lead to:
>  Prepared
> statement cluster error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute
> unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have
> used a PreparedStatement that was created with another Cluster instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko edited comment on IGNITE-6999 at 11/24/17 8:54 AM:
-

Implemented quiet mode for Visor CMD in batch mode.
To enable add -quiet program argument.


was (Author: vsisko):
Implemented quiet mode for Visor CMD in batch mode.
To enable add -quier program argument.

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-6999:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

Implemented quiet mode for Visor CMD in batch mode.
To enable add -quier program argument.

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7010) Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events

[Krzysztof Chmielewski (JIRA)]

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

Krzysztof Chmielewski updated IGNITE-7010:
--
Description: 
Ignite hangs trying to delete cache as a response to Ignite Event 
EventType.EVT_NODE_LEFT.
Code to reproduce this issue is available at 
https://github.com/kristoffSC/IgniteHang

Reproduce instructions:
# Put break points in ServerStarter.java line 40 and 42.
# Start ServerStarter as Java Application in Debug mode.
# Start ClientStarter as Java Application. After ClientStarter ends, 
ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
Try skip to next line (ignite.destroyCache("testCache")) and then 
try skip one more line. Ignite will hang at line 41.

This "hang" prevents other nodes from connecting to this running/hanging Ignite 
Server.

Thread that stuck is "disco-event-worker". It waits on {code} return 
stopFut.get() {code} in IgniteKernel.class at line 3146


  was:
Ignite hangs trying to delete cache as a response to Ignite Event 
EventType.EVT_NODE_LEFT.
Code to reproduce this issue is available at 
https://github.com/kristoffSC/IgniteHang

Reproduce instructions:
# Put break points in ServerStarter.java line 40 and 42.
# Start ServerStarter as Java Application in Debug mode.
# Start ClientStarter as Java Application. After ClientStarter ends, 
ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
Try skip to next line (ignite.destroyCache("testCache")) and then try skip one 
more line. Ignite will hang at line 41.

This "hang" prevents other nodes from connecting to this running/hanging Ignite 
Server.

Thread that stuck is "disco-event-worker". It waits on {code} return 
stopFut.get() {code} in IgniteKernel.class at line 3146



> Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events
> ---
>
> Key: IGNITE-7010
> URL: https://issues.apache.org/jira/browse/IGNITE-7010
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Krzysztof Chmielewski
>
> Ignite hangs trying to delete cache as a response to Ignite Event 
> EventType.EVT_NODE_LEFT.
> Code to reproduce this issue is available at 
> https://github.com/kristoffSC/IgniteHang
> Reproduce instructions:
> # Put break points in ServerStarter.java line 40 and 42.
> # Start ServerStarter as Java Application in Debug mode.
> # Start ClientStarter as Java Application. After ClientStarter ends, 
> ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
> Try skip to next line (ignite.destroyCache("testCache")) and 
> then try skip one more line. Ignite will hang at line 41.
> This "hang" prevents other nodes from connecting to this running/hanging 
> Ignite Server.
> Thread that stuck is "disco-event-worker". It waits on {code} return 
> stopFut.get() {code} in IgniteKernel.class at line 3146



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7010) Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events

[Krzysztof Chmielewski (JIRA)]

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

Krzysztof Chmielewski updated IGNITE-7010:
--
Description: 
Ignite hangs trying to delete cache as a response to Ignite Event 
EventType.EVT_NODE_LEFT.
Code to reproduce this issue is available at 
https://github.com/kristoffSC/IgniteHang

Reproduce instructions:
# Put break points in ServerStarter.java line 40 and 42.
# Start ServerStarter as Java Application in Debug mode.
# Start ClientStarter as Java Application. After ClientStarter ends, 
ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
Try skip to next line ({code}ignite.destroyCache("testCache"){code}) and then 
try skip one more line. Ignite will hang at line 41.

This "hang" prevents other nodes from connecting to this running/hanging Ignite 
Server.

Thread that stuck is "disco-event-worker". It waits on {code} return 
stopFut.get() {code} in IgniteKernel.class at line 3146


  was:
Ignite hangs trying to delete cache as a response to Ignite Event 
EventType.EVT_NODE_LEFT.
Code to reproduce this issue is available at 
https://github.com/kristoffSC/IgniteHang

Reproduce instructions:
# Put break points in ServerStarter.java line 40 and 42.
# Start ServerStarter as Java Application in Debug mode.
# Start ClientStarter as Java Application. After ClientStarter ends, 
ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
Try skip to next line (ignite.destroyCache("testCache")) and then 
try skip one more line. Ignite will hang at line 41.

This "hang" prevents other nodes from connecting to this running/hanging Ignite 
Server.

Thread that stuck is "disco-event-worker". It waits on {code} return 
stopFut.get() {code} in IgniteKernel.class at line 3146



> Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events
> ---
>
> Key: IGNITE-7010
> URL: https://issues.apache.org/jira/browse/IGNITE-7010
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Krzysztof Chmielewski
>
> Ignite hangs trying to delete cache as a response to Ignite Event 
> EventType.EVT_NODE_LEFT.
> Code to reproduce this issue is available at 
> https://github.com/kristoffSC/IgniteHang
> Reproduce instructions:
> # Put break points in ServerStarter.java line 40 and 42.
> # Start ServerStarter as Java Application in Debug mode.
> # Start ClientStarter as Java Application. After ClientStarter ends, 
> ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
> Try skip to next line ({code}ignite.destroyCache("testCache"){code}) and then 
> try skip one more line. Ignite will hang at line 41.
> This "hang" prevents other nodes from connecting to this running/hanging 
> Ignite Server.
> Thread that stuck is "disco-event-worker". It waits on {code} return 
> stopFut.get() {code} in IgniteKernel.class at line 3146



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7010) Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events

[Krzysztof Chmielewski (JIRA)]

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

Krzysztof Chmielewski updated IGNITE-7010:
--
Description: 
Ignite hangs trying to delete cache as a response to Ignite Event 
EventType.EVT_NODE_LEFT.
Code to reproduce this issue is available at 
https://github.com/kristoffSC/IgniteHang

Reproduce instructions:
# Put break points in ServerStarter.java line 40 and 42.
# Start ServerStarter as Java Application in Debug mode.
# Start ClientStarter as Java Application. After ClientStarter ends, 
ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
Try skip to next line (ignite.destroyCache("testCache")) and then try skip one 
more line. Ignite will hang at line 41.

This "hang" prevents other nodes from connecting to this running/hanging Ignite 
Server.

Thread that stuck is "disco-event-worker". It waits on {code} return 
stopFut.get() {code} in IgniteKernel.class at line 3146


  was:
Ignite hangs trying to delete cache as a response to Ignite Event 
EventType.EVT_NODE_LEFT.
Code to reproduce this issue is available at 
https://github.com/kristoffSC/IgniteHang

Reproduce instructions:
# Put break points in ServerStarter.java line 40 and 42.
# Start ServerStarter as Java Application in Debug mode.
# Start ClientStarter as Java Application. After ClientStarter ends, 
ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
Try skip to next line (ignite.destroyCache("testCache");) and then try skip one 
more line. Ignite will hang at line 41.

This "hang" prevents other nodes from connecting to this running/hanging Ignite 
Server.

Thread that stuck is "disco-event-worker". It waits on {code} return 
stopFut.get() {code} in IgniteKernel.class at line 3146



> Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events
> ---
>
> Key: IGNITE-7010
> URL: https://issues.apache.org/jira/browse/IGNITE-7010
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Krzysztof Chmielewski
>
> Ignite hangs trying to delete cache as a response to Ignite Event 
> EventType.EVT_NODE_LEFT.
> Code to reproduce this issue is available at 
> https://github.com/kristoffSC/IgniteHang
> Reproduce instructions:
> # Put break points in ServerStarter.java line 40 and 42.
> # Start ServerStarter as Java Application in Debug mode.
> # Start ClientStarter as Java Application. After ClientStarter ends, 
> ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
> Try skip to next line (ignite.destroyCache("testCache")) and then try skip 
> one more line. Ignite will hang at line 41.
> This "hang" prevents other nodes from connecting to this running/hanging 
> Ignite Server.
> Thread that stuck is "disco-event-worker". It waits on {code} return 
> stopFut.get() {code} in IgniteKernel.class at line 3146



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7010) Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events

[Krzysztof Chmielewski (JIRA)]

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

Krzysztof Chmielewski updated IGNITE-7010:
--
Description: 
Ignite hangs trying to delete cache as a response to Ignite Event 
EventType.EVT_NODE_LEFT.
Code to reproduce this issue is available at 
https://github.com/kristoffSC/IgniteHang

Reproduce instructions:
# Put break points in ServerStarter.java line 40 and 42.
# Start ServerStarter as Java Application in Debug mode.
# Start ClientStarter as Java Application. After ClientStarter ends, 
ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
Try skip to next line (ignite.destroyCache("testCache");) and then try skip one 
more line. Ignite will hang at line 41.

This "hang" prevents other nodes from connecting to this running/hanging Ignite 
Server.

Thread that stuck is "disco-event-worker". It waits on {code} return 
stopFut.get() {code} in IgniteKernel.class at line 3146


  was:
Ignite hangs trying to delete cache as a response to Ignite Event 
EventType.EVT_NODE_LEFT.
Code to reproduce this issue is available at 
https://github.com/kristoffSC/IgniteHang

Reproduce instructions:
# Put break points in ServerStarter.java line 40 and 42.
## Start ServerStarter as Java Application in Debug mode.
### Start ClientStarter as Java Application. After ClientStarter ends, 
ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
Try skip to next line (ignite.destroyCache("testCache");) and then try skip one 
more line. Ignite will hang at line 41.

This "hang" prevents other nodes from connecting to this running/hanging Ignite 
Server.

Thread that stuck is "disco-event-worker". It waits on {code} return 
stopFut.get() {code} in IgniteKernel.class at line 3146



> Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events
> ---
>
> Key: IGNITE-7010
> URL: https://issues.apache.org/jira/browse/IGNITE-7010
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Krzysztof Chmielewski
>
> Ignite hangs trying to delete cache as a response to Ignite Event 
> EventType.EVT_NODE_LEFT.
> Code to reproduce this issue is available at 
> https://github.com/kristoffSC/IgniteHang
> Reproduce instructions:
> # Put break points in ServerStarter.java line 40 and 42.
> # Start ServerStarter as Java Application in Debug mode.
> # Start ClientStarter as Java Application. After ClientStarter ends, 
> ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
> Try skip to next line (ignite.destroyCache("testCache");) and then try skip 
> one more line. Ignite will hang at line 41.
> This "hang" prevents other nodes from connecting to this running/hanging 
> Ignite Server.
> Thread that stuck is "disco-event-worker". It waits on {code} return 
> stopFut.get() {code} in IgniteKernel.class at line 3146



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7010) Ignite hangs on cache destroy called from IgniteBiPredicate - Ignite Events

[Krzysztof Chmielewski (JIRA)]

Krzysztof Chmielewski created IGNITE-7010:
-

 Summary: Ignite hangs on cache destroy called from 
IgniteBiPredicate - Ignite Events
 Key: IGNITE-7010
 URL: https://issues.apache.org/jira/browse/IGNITE-7010
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Krzysztof Chmielewski


Ignite hangs trying to delete cache as a response to Ignite Event 
EventType.EVT_NODE_LEFT.
Code to reproduce this issue is available at 
https://github.com/kristoffSC/IgniteHang

Reproduce instructions:
# Put break points in ServerStarter.java line 40 and 42.
## Start ServerStarter as Java Application in Debug mode.
### Start ClientStarter as Java Application. After ClientStarter ends, 
ServerStarter detects EventType.EVT_NODE_LEFT and will stops at line 40 (BP). 
Try skip to next line (ignite.destroyCache("testCache");) and then try skip one 
more line. Ignite will hang at line 41.

This "hang" prevents other nodes from connecting to this running/hanging Ignite 
Server.

Thread that stuck is "disco-event-worker". It waits on {code} return 
stopFut.get() {code} in IgniteKernel.class at line 3146




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6702) Get rid of values deserialization in H2TreeIndex.getRowCount

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-6702 at 11/24/17 8:12 AM:
---

[~kirill.shirokov], my comments:
1) I did a number of changes in the code to better align it with our styling 
rules and general guidelines:
1.1) Variables should be abbreviated according to our abbreviation rules
1.2) It is better to avoid long chains of method calls on a single line because 
it makes debug and log analysis harder.
1.3) Semantically different lines should have blank line in betwee,
2) {{H2TreeIndex#filter}} - there was potential NPE because thread-local 
context could be {{null}}. To avoid that I moved cache filter logic to a common 
method used in several places.
3) {{H2TreeIndex#filter}} - TODOs are not allowed in the code. 
4) {{H2TreeIndex#filter}} - please avoid anonymous classes because according to 
our experience it may lead to unexpected issues with binary compatibility. It 
is better to rework it to top-level class or at least inner static class.
5) The most important - please confirm that we have enough tests for 
{{COUNT(*)}} with different cache modes ({{PARTITIONED}}, {{PARTITIONED}} with 
backups, {{REPLICATED}}, {{LOCAL}}, one nodes, several nodes). If no, let's 
create a set of tests covering all these scenarios.

The rest looks good to me.


was (Author: vozerov):
[~kirill.shirokov], my comments:
1) I did a number of changes in the code to better align it with our styling 
rules and general guidelines:
1.1) Variables should be abbreviated according to our abbreviation rules
1.2) It is better to avoid long chains of method calls on a single line because 
it makes debug and log analysis harder.
1.3) Semantically different lines should have blank line in betwee,
2) {{H2TreeIndex#filter}} - there was potential NPE because thread-locl context 
could be {{null}}. To avoid that I moved cache filter logic to a common method 
use in several places.
3) {{H2TreeIndex#filter}} - TODOs are not allowed in the code. 
4) {{H2TreeIndex#filter}} - please avoid anonymous classes because according to 
our experience it may lead to unexpected issues with binary compatibility. It 
is better to rework it to top-level class or at least inner static class.
5) The most important - please confirm that we have enough tests for 
{{COUNT(*)}} with different cache modes ({{PARTITIONED}}, {{PARTITIONED}} with 
backups, {{REPLICATED}}, {{LOCAL}}, one nodes, several nodes). If no, let's 
create a set of tests covering all these scenarios.

> Get rid of values deserialization in H2TreeIndex.getRowCount
> 
>
> Key: IGNITE-6702
> URL: https://issues.apache.org/jira/browse/IGNITE-6702
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Semen Boikov
>Assignee: Kirill Shirokov
>  Labels: performance
> Fix For: 2.4
>
>
> It seems H2TreeIndex.getRowCount is called for 'select count(*) from x' 
> queries, now it is implemented via BPlusTree.find(x, x) method which 
> deserializes all values. Actually values are not needed there, need implement 
> method on BPlusTree computing size without deserialization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)