[jira] [Commented] (IGNITE-2190) ScanQuery without a filter triggers object's deserialization on the server side

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2190:


GitHub user nizhikov opened a pull request:

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

IGNITE-2190:

* Added GridCacheEmptyScanQueryTest to reproduce bug described in task
* Test succeed for a OptimizedMarshaller but fails for a BinaryMarshaller
* Minor fixes in IgniteProcessProxy and GridAbstractTest for a possibility 
to modify separate jvm grid classpath
* Added ignite-2190-1.0.jar to binary dependencies(source can be obtained 
from https://github.com/nizhikov/ignite-2190-binary)

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

$ git pull https://github.com/nizhikov/ignite ignite-2190

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

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


commit 1857a95185266e256b269897e577cae18db7a577
Author: Ижиков Николай Владимирович 
Date:   2017-05-16T05:57:02Z

IGNITE-2190:

* Added GridCacheEmptyScanQueryTest to reproduce bug described in task
* Test succeed for a OptimizedMarshaller but fails for a BinaryMarshaller
* Minor fixes in IgniteProcessProxy and GridAbstractTest for a possibility 
to modify separate jvm grid classpath
* Added ignite-2190-1.0.jar to binary dependencies(source can be obtained 
from https://github.com/nizhikov/ignite-2190-binary)




> ScanQuery without a filter triggers object's deserialization on the server 
> side
> ---
>
> Key: IGNITE-2190
> URL: https://issues.apache.org/jira/browse/IGNITE-2190
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: newbie
> Fix For: 2.1
>
> Attachments: ScanQueryBug.java
>
>
> The issue is reproduced on version 1.4 where legacy PortableMarshaller is 
> used. However, I'm quiet sure that the issue happens when BinaryMarshaller is 
> used as well in 1.5.
> 1) Start a server using ignite.sh/bat
> 2) Create a simple app, that uses binary or portable marshaller, creates a 
> cache dynamically and executes a ScanQuery like below
> {{int size=employees1.query(new ScanQuery()).getAll().size();}}
> 3) As you see the query doesn't use any filters. However on the server side 
> some filter is still being checked 
> {{org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.checkPredicate(GridCacheQueryManager.java:963)}}
>  which makes the server to deserialize a value.
> According to the stack trace there is some internal filter that triggered 
> checkPredicate function - 
> filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b.
> {noformat}
> [11:05:22,725][SEVERE][ignite-#25%sys-null%][GridCacheDistributedQueryManager]
>   Failed to run query [qry=GridCacheQueryInfo [loc=false, 
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
> clause=null, filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b, 
> part=null, incMeta=false, metrics=null, pageSize=1024, timeout=0, 
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
> subjId=c6aeb542-1693-4b5f-89db-96db50e3435f, taskHash=0], locFut=null, 
> sndId=c6aeb542-1693-4b5f-89db-96db50e3435f, reqId=14, incMeta=false, 
> all=false], node=209c237a-9e33-4d05-abe4-bbc14f93c439]
> class org.apache.ignite.IgniteCheckedException: 
> **.SubMessageB
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$CachedResult.iterator(GridCacheQueryManager.java:2784)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1376)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:226)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:105)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:103)
> at 
> 

[jira] [Updated] (IGNITE-5229) Specify caches when using Redis protocol

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5229:
-
Description: 
Currently there's no way to switch caches -- all requests go to 'default'.

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.

> Specify caches when using Redis protocol
> 
>
> Key: IGNITE-5229
> URL: https://issues.apache.org/jira/browse/IGNITE-5229
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> Currently there's no way to switch caches -- all requests go to 'default'.
> As an idea, we can use {{CONFIG SET parameter value}} to set the current 
> cache, save it in {{GridRestProcessor}} and use it until the user switches to 
> another one.



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

[jira] [Created] (IGNITE-5229) Specify caches when using Redis protocol

[Roman Shtykh (JIRA)]

Roman Shtykh created IGNITE-5229:


 Summary: Specify caches when using Redis protocol
 Key: IGNITE-5229
 URL: https://issues.apache.org/jira/browse/IGNITE-5229
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Roman Shtykh
Assignee: Roman Shtykh






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

[jira] [Created] (IGNITE-5228) Console: Failed to collect events in process of log command

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-5228:
-

 Summary: Console: Failed to collect events in process of log 
command
 Key: IGNITE-5228
 URL: https://issues.apache.org/jira/browse/IGNITE-5228
 Project: Ignite
  Issue Type: Bug
Reporter: Vasiliy Sisko


# Run node and connect Visor console.
# Start logging by command: log -l -f=1.txt

On node exception is thrown.
{code}
class org.apache.ignite.IgniteException: Failed to query events because default 
no-op event storage SPI is used. Consider configuring MemoryEventStorageSpi or 
another EventStorageSpi implementation via 
IgniteConfiguration.setEventStorageSpi() configuration property.
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:949)
at 
org.apache.ignite.internal.IgniteEventsImpl.localQuery(IgniteEventsImpl.java:251)
at 
org.apache.ignite.internal.visor.node.VisorNodeEventsCollectorTask$VisorNodeEventsCollectorJob.run(VisorNodeEventsCollectorTask.java:176)
at 
org.apache.ignite.internal.visor.node.VisorNodeEventsCollectorTask$VisorNodeEventsCollectorJob.run(VisorNodeEventsCollectorTask.java:72)
at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
at 
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6621)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:560)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1114)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1907)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1257)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:885)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:114)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:802)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to query 
events because default no-op event storage SPI is used. Consider configuring 
MemoryEventStorageSpi or another EventStorageSpi implementation via 
IgniteConfiguration.setEventStorageSpi() configuration property.
at 
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.localEvents(GridEventStorageManager.java:913)
at 
org.apache.ignite.internal.IgniteEventsImpl.localQuery(IgniteEventsImpl.java:248)
... 17 more
{code}



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

[jira] [Updated] (IGNITE-5114) Parallalel plus/multiply matrix algorithms.

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5114:

Fix Version/s: 2.1

> Parallalel plus/multiply matrix algorithms.
> ---
>
> Key: IGNITE-5114
> URL: https://issues.apache.org/jira/browse/IGNITE-5114
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.1
>
>
> We need design and implement parallel(distributed?) versions of matrix 
> plus/multiply algorithms because current implementation is implemented by 
> definition. Those implementations is really slow.



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

[jira] [Commented] (IGNITE-1456) CPP: Implement Cache.Rebalance()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1456:


GitHub user vinx13 opened a pull request:

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

IGNITE-1456: CPP: Implements Cache.Rebalance()



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

$ git pull https://github.com/vinx13/ignite ignite-1456

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

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


commit 0bb53d8e8e908dad703b2c612bbfca8313ee80cb
Author: Wuwei Lin 
Date:   2017-05-16T01:36:25Z

CPP: Implements Cache.Rebalance()




> CPP: Implement Cache.Rebalance()
> 
>
> Key: IGNITE-1456
> URL: https://issues.apache.org/jira/browse/IGNITE-1456
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Wuwei Lin
>  Labels: cpp
>




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

[jira] [Assigned] (IGNITE-1456) CPP: Implement Cache.Rebalance()

[Wuwei Lin (JIRA)]

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

Wuwei Lin reassigned IGNITE-1456:
-

Assignee: Wuwei Lin

> CPP: Implement Cache.Rebalance()
> 
>
> Key: IGNITE-1456
> URL: https://issues.apache.org/jira/browse/IGNITE-1456
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Wuwei Lin
>  Labels: cpp
>




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

[jira] [Updated] (IGNITE-5182) Document Job Stealing API Usage

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5182:

Description: 
There is no documentation for job stealing capabilities on readme.io:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/collision/jobstealing/JobStealingCollisionSpi.html

Let's add it do this doc saying that it's "late load balancing technique".:
https://apacheignite.readme.io/docs/load-balancing

The other load balancing algorithms described there are for "early load 
balancing".

T discussion that spotted the gap:
http://stackoverflow.com/questions/43846316/one-task-per-node-only-in-apache-ignite/

  was:
There is no documentation for job stealing capabilities on readme.io:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/collision/jobstealing/JobStealingCollisionSpi.html

Let's add it do this doc or create a new page:
https://apacheignite.readme.io/docs/job-scheduling

Discussion that spotted the gap:
http://stackoverflow.com/questions/43846316/one-task-per-node-only-in-apache-ignite/


> Document Job Stealing API Usage
> ---
>
> Key: IGNITE-5182
> URL: https://issues.apache.org/jira/browse/IGNITE-5182
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.1
>
>
> There is no documentation for job stealing capabilities on readme.io:
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/collision/jobstealing/JobStealingCollisionSpi.html
> Let's add it do this doc saying that it's "late load balancing technique".:
> https://apacheignite.readme.io/docs/load-balancing
> The other load balancing algorithms described there are for "early load 
> balancing".
> T discussion that spotted the gap:
> http://stackoverflow.com/questions/43846316/one-task-per-node-only-in-apache-ignite/



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

[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4052:
-

[~pgarg], please review and apply the edits suggested by Vadim in readme.io for 
Mesos Deployment page:
https://dash.readme.io/project/apacheignite/v2.0/suggested

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Prachi Garg
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



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

[jira] [Closed] (IGNITE-5178) Simplify ML Grid build and release process

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-5178.
---

> Simplify ML Grid build and release process
> --
>
> Key: IGNITE-5178
> URL: https://issues.apache.org/jira/browse/IGNITE-5178
> Project: Ignite
>  Issue Type: Task
>  Components: ml
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Yury Babak
>Priority: Critical
> Fix For: 2.1
>
>
> ML component is Java 8 based which significantly complicated Apache Ignite 
> build and release procedure. We need to try to find a way to simplify the 
> release of the module in 2.1.
> Has to be discussed with [~avinogradov], [~skozlov] and [~dmagda]



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

[jira] [Commented] (IGNITE-5131) Hadoop: update asm library to a version that can parse 1.8 bytecode

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-5131:
-

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

> Hadoop: update asm library to a version that can parse 1.8 bytecode
> ---
>
> Key: IGNITE-5131
> URL: https://issues.apache.org/jira/browse/IGNITE-5131
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Minor
>
> This question indicates, that asm bytecode parser 4.2 cannot parse 1.8 
> bytecode:
> http://stackoverflow.com/questions/34318028/apache-ignite-failed-to-load-job-class-class-org-apache-ignite-internal-proces
> {code}
>  
>  org.ow2.asm
>  asm-all
>  4.2
>  
> {code}
> Consider to update asm lib to newer version that understands 1.8 bytecode 
> version, (likely 5.2 ? 
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.ow2.asm%22%20AND%20a%3A%22asm-all%22
>  )



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

[jira] [Commented] (IGNITE-5225) TcpCommunicationSpi.createTcpClient can cause OOME.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-5225:
--

Looks like it is cause by IGNITE-4577 changes.

> TcpCommunicationSpi.createTcpClient can cause OOME.
> ---
>
> Key: IGNITE-5225
> URL: https://issues.apache.org/jira/browse/IGNITE-5225
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.1
>
>
> TcpCommunicationSpi.filterReachable method doesn't shutdown executor 
> correctly that causes OOME.
> Possible reason is that user uses host name that can't be resolved somewhere 
> in configuration.
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
> message to remote node: TcpDiscoveryNode 
> [id=edcb71b0-bd61-455a-8742-ade1653b0701, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.162.115.12, 127.0.
> 0.1], sockAddrs=[0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, 
> mydomain.com/10.162.115.12:0], discPort=0, order=25, intOrder=25, 
> lastExchangeTime=1494183620982, loc=false, ver=,
>  isClient=true]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2368)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2304)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1283)
> ... 34 more
> Caused by: class org.apache.ignite.IgniteCheckedException: 
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7228)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2515)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2340)
> ... 36 more
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at 
> org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1884)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2775)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2587)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2479)
> ... 37 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.reachable(IgniteUtils.java:2091)
> at 
> org.apache.ignite.internal.util.IgniteUtils$18.run(IgniteUtils.java:1873)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)



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

[jira] [Commented] (IGNITE-4831) Add an option to disable MBeans

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4831:


GitHub user rfqu opened a pull request:

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

IGNITE-4831 fixed (Add an option to disable MBeans). Option IGNITE_DI…

…SABLE_MBEANS added.

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

$ git pull https://github.com/rfqu/ignite ignite-4831

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

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


commit 8123b84a9b7d5322455dc67187b2d2f6673f61ab
Author: rfqu 
Date:   2017-05-15T16:19:32Z

IGNITE-4831 fixed (Add an option to disable MBeans). Option 
IGNITE_DISABLE_MBEANS added.




> Add an option to disable MBeans
> ---
>
> Key: IGNITE-4831
> URL: https://issues.apache.org/jira/browse/IGNITE-4831
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>
> There are multiple MBeans registered by Ignite and there is no way to avoid 
> their registration (in case they're not allowed for security reasons for 
> example). We should have a system property that will disable MBeans.
> In addition, if MBean registration throws a {{RuntimeException}}, this 
> exception is not properly handled. For example, if it happens during cache 
> creation, {{createCache}} method hangs forever.



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

[jira] [Commented] (IGNITE-4831) Add an option to disable MBeans

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4831:


Github user rfqu closed the pull request at:

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


> Add an option to disable MBeans
> ---
>
> Key: IGNITE-4831
> URL: https://issues.apache.org/jira/browse/IGNITE-4831
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>
> There are multiple MBeans registered by Ignite and there is no way to avoid 
> their registration (in case they're not allowed for security reasons for 
> example). We should have a system property that will disable MBeans.
> In addition, if MBean registration throws a {{RuntimeException}}, this 
> exception is not properly handled. For example, if it happens during cache 
> creation, {{createCache}} method hangs forever.



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

[jira] [Comment Edited] (IGNITE-5208) C++ Segfault on Put

[Igor Sapego (JIRA)]

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

Igor Sapego edited comment on IGNITE-5208 at 5/15/17 4:30 PM:
--

[~tghosgor], thank you for report and for your help. I'm going to submit patch 
in few hours and hopefully it's going to be in master in few days. Your patch 
looks correct - you may use it as a fix for now.


was (Author: isapego):
[~tghosgor], thank you for report and for your help. I'm going to submit patch 
in few hours and hopefully it's going to be in master in few days. Your patch 
looks very right - you may use it as a fix for now.

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places.



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

[jira] [Commented] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR commented on IGNITE-5208:
--

[~isapego] Thanks for the verification. It has survived multiple runs of UTs so 
far, we will be continuing with this patch then. 

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places.



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

[jira] [Commented] (IGNITE-4831) Add an option to disable MBeans

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4831:


GitHub user rfqu opened a pull request:

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

IGNITE-4831 fixed (Add an option to disable MBeans). Option IGNITE_DI…

…SABLE_MBEANS added.

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

$ git pull https://github.com/rfqu/ignite ignite-4831

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

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


commit 8123b84a9b7d5322455dc67187b2d2f6673f61ab
Author: rfqu 
Date:   2017-05-15T16:19:32Z

IGNITE-4831 fixed (Add an option to disable MBeans). Option 
IGNITE_DISABLE_MBEANS added.




> Add an option to disable MBeans
> ---
>
> Key: IGNITE-4831
> URL: https://issues.apache.org/jira/browse/IGNITE-4831
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>
> There are multiple MBeans registered by Ignite and there is no way to avoid 
> their registration (in case they're not allowed for security reasons for 
> example). We should have a system property that will disable MBeans.
> In addition, if MBean registration throws a {{RuntimeException}}, this 
> exception is not properly handled. For example, if it happens during cache 
> creation, {{createCache}} method hangs forever.



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

[jira] [Updated] (IGNITE-5225) TcpCommunicationSpi.createTcpClient can cause OOME.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5225:
-
Description: 
TcpCommunicationSpi.filterReachable method doesn't shutdown executor correctly 
that causes OOME.
Possible reason is that user uses host name that can't be resolved somewhere in 
configuration.

Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
message to remote node: TcpDiscoveryNode 
[id=edcb71b0-bd61-455a-8742-ade1653b0701, addrs=[0:0:0:0:0:0:0:1%lo, 
10.162.115.12, 127.0.
0.1], sockAddrs=[0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, 
mydomain.com/10.162.115.12:0], discPort=0, order=25, intOrder=25, 
lastExchangeTime=1494183620982, loc=false, ver=,
 isClient=true]
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2368)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2304)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1283)
... 34 more
Caused by: class org.apache.ignite.IgniteCheckedException: 
java.lang.NullPointerException
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7228)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2515)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2340)
... 36 more
Caused by: java.util.concurrent.ExecutionException: 
java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1884)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2775)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2587)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2479)
... 37 more
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.util.IgniteUtils.reachable(IgniteUtils.java:2091)
at 
org.apache.ignite.internal.util.IgniteUtils$18.run(IgniteUtils.java:1873)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)


  was:
TcpCommunicationSpi.filterReachable method doesn't shutdown executor correctly 
that causes OOME.
Possible reason is that user uses host name that can't be resolved somewhere in 
configuration.

Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
message to remote node: TcpDiscoveryNode 
[id=edcb71b0-bd61-455a-8742-ade1653b0701, addrs=[0:0:0:0:0:0:0:1%lo, 
10.162.115.12, 127.0.
0.1], sockAddrs=[0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, 
mydomain.com/10.162.115.12:0], discPort=0, order=25, intOrder=25, 
lastExchangeTime=1494183620982, loc=false, ver=1.8.5#20170331-sha1:2d3377c0,
 isClient=true]
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2368)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2304)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1283)
... 34 more
Caused by: class org.apache.ignite.IgniteCheckedException: 
java.lang.NullPointerException
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7228)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2515)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2340)
... 36 more
Caused by: java.util.concurrent.ExecutionException: 
java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1884)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2775)
at 

[jira] [Commented] (IGNITE-5208) C++ Segfault on Put

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5208:
-

[~tghosgor], thank you for report and for your help. I'm going to submit patch 
in few hours and hopefully it's going to be in master in few days. Your patch 
looks very right - you may use it as a fix for now.

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places.



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

[jira] [Updated] (IGNITE-5225) TcpCommunicationSpi.createTcpClient can cause OOME.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5225:
-
Description: 
TcpCommunicationSpi.filterReachable method doesn't shutdown executor correctly 
that causes OOME.
Possible reason is that user uses host name that can't be resolved somewhere in 
configuration.

Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
message to remote node: TcpDiscoveryNode 
[id=edcb71b0-bd61-455a-8742-ade1653b0701, addrs=[0:0:0:0:0:0:0:1%lo, 
10.162.115.12, 127.0.
0.1], sockAddrs=[0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, 
mydomain.com/10.162.115.12:0], discPort=0, order=25, intOrder=25, 
lastExchangeTime=1494183620982, loc=false, ver=1.8.5#20170331-sha1:2d3377c0,
 isClient=true]
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2368)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2304)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1283)
... 34 more
Caused by: class org.apache.ignite.IgniteCheckedException: 
java.lang.NullPointerException
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7228)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2515)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2340)
... 36 more
Caused by: java.util.concurrent.ExecutionException: 
java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1884)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2775)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2587)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2479)
... 37 more
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.util.IgniteUtils.reachable(IgniteUtils.java:2091)
at 
org.apache.ignite.internal.util.IgniteUtils$18.run(IgniteUtils.java:1873)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)


  was:
TcpCommunicationSpi.filterReachable method doesn't shutdown executor correctly 
that causes OOME.
Possible reason is that user uses host name that can't be resolved somewhere in 
configuration.

Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
message to remote node: TcpDiscoveryNode 
[id=edcb71b0-bd61-455a-8742-ade1653b0701, addrs=[0:0:0:0:0:0:0:1%lo, 
10.162.115.12, 127.0.
0.1], sockAddrs=[0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, 
ny4gets6p.jc.jefco.com/10.162.115.12:0], discPort=0, order=25, intOrder=25, 
lastExchangeTime=1494183620982, loc=false, ver=1.8.5#20170331-sha1:2d3377c0,
 isClient=true]
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2368)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2304)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1283)
... 34 more
Caused by: class org.apache.ignite.IgniteCheckedException: 
java.lang.NullPointerException
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7228)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2515)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2340)
... 36 more
Caused by: java.util.concurrent.ExecutionException: 
java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1884)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2775)
at 

[jira] [Comment Edited] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR edited comment on IGNITE-5208 at 5/15/17 3:56 PM:
---

This seemed to solve it for me:
{code:none}
diff -Naur "/tmp/apache-ignite-2.0.0 
(original)/binary/src/impl/binary/binary_type_manager.cpp" 
/tmp/apache-ignite-2.0.0/binary/src/impl/binary/binary_type_manager.cpp
--- "/tmp/apache-ignite-2.0.0 
(original)/binary/src/impl/binary/binary_type_manager.cpp"2017-04-30 
12:27:20.0 +0300
+++ /tmp/apache-ignite-2.0.0/binary/src/impl/binary/binary_type_manager.cpp 
2017-05-15 14:57:14.0 +0300
@@ -48,11 +48,11 @@
 
 SharedPointer 
BinaryTypeManager::GetHandler(const std::string& typeName, int32_t typeId)
 {
-std::map& snapshots0 = *snapshots.Get();
-
 { // Locking scope.
 CsLockGuard guard(cs);
 
+std::map& snapshots0 = *snapshots.Get();
+
 std::map::iterator it = 
snapshots0.find(typeId);
 if (it != snapshots0.end())
 return SharedPointer(new 
BinaryTypeHandler(it->second));
@@ -65,7 +65,7 @@
 
 void BinaryTypeManager::SubmitHandler(BinaryTypeHandler& hnd)
 {
-// If this is the very first write of a class or difference 
exists, 
+// If this is the very first write of a class or difference 
exists,
 // we need to enqueue it for write.
 if (hnd.HasUpdate())
 {
@@ -152,6 +152,8 @@
 
 SPSnap BinaryTypeManager::GetMeta(int32_t typeId)
 {
+CsLockGuard guard(cs);
+
 std::map::iterator it = 
snapshots.Get()->find(typeId);
 
 if (it != snapshots.Get()->end() && it->second.Get())
@@ -175,4 +177,4 @@
 }
 }
 }
-}
\ No newline at end of file
+}
{code}

The problem was that shared pointer's data was deleted whilst a reference to it 
was obtained outside the lock. Converting the reference to an actual copy of 
shared pointer can also solve the issue but in my tests lock seems to protect 
the shared pointer anyway so far.

I am not sure about the lock I added in `GetMeta` is really needed though.


was (Author: tghosgor):
This seemed to solve it for me:
{code:none}
diff -Naur "/tmp/apache-ignite-2.0.0 
(original)/binary/src/impl/binary/binary_type_manager.cpp" 
/tmp/apache-ignite-2.0.0/binary/src/impl/binary/binary_type_manager.cpp
--- "/tmp/apache-ignite-2.0.0 
(original)/binary/src/impl/binary/binary_type_manager.cpp"2017-04-30 
12:27:20.0 +0300
+++ /tmp/apache-ignite-2.0.0/binary/src/impl/binary/binary_type_manager.cpp 
2017-05-15 14:57:14.0 +0300
@@ -48,11 +48,11 @@
 
 SharedPointer 
BinaryTypeManager::GetHandler(const std::string& typeName, int32_t typeId)
 {
-std::map& snapshots0 = *snapshots.Get();
-
 { // Locking scope.
 CsLockGuard guard(cs);
 
+std::map& snapshots0 = *snapshots.Get();
+
 std::map::iterator it = 
snapshots0.find(typeId);
 if (it != snapshots0.end())
 return SharedPointer(new 
BinaryTypeHandler(it->second));
@@ -65,7 +65,7 @@
 
 void BinaryTypeManager::SubmitHandler(BinaryTypeHandler& hnd)
 {
-// If this is the very first write of a class or difference 
exists, 
+// If this is the very first write of a class or difference 
exists,
 // we need to enqueue it for write.
 if (hnd.HasUpdate())
 {
@@ -152,6 +152,8 @@
 
 SPSnap BinaryTypeManager::GetMeta(int32_t typeId)
 {
+CsLockGuard guard(cs);
+
 std::map::iterator it = 
snapshots.Get()->find(typeId);
 
 if (it != snapshots.Get()->end() && it->second.Get())
@@ -175,4 +177,4 @@
 }
 }
 }
-}
\ No newline at end of file
+}
{code}

I am not sure about the lock in `GetMeta` though.

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same 

[jira] [Commented] (IGNITE-5208) C++ Segfault on Put

[JIRA]

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

Tolga HOŞGÖR commented on IGNITE-5208:
--

This seemed to solve it for me:
{code:none}
diff -Naur "/tmp/apache-ignite-2.0.0 
(original)/binary/src/impl/binary/binary_type_manager.cpp" 
/tmp/apache-ignite-2.0.0/binary/src/impl/binary/binary_type_manager.cpp
--- "/tmp/apache-ignite-2.0.0 
(original)/binary/src/impl/binary/binary_type_manager.cpp"2017-04-30 
12:27:20.0 +0300
+++ /tmp/apache-ignite-2.0.0/binary/src/impl/binary/binary_type_manager.cpp 
2017-05-15 14:57:14.0 +0300
@@ -48,11 +48,11 @@
 
 SharedPointer 
BinaryTypeManager::GetHandler(const std::string& typeName, int32_t typeId)
 {
-std::map& snapshots0 = *snapshots.Get();
-
 { // Locking scope.
 CsLockGuard guard(cs);
 
+std::map& snapshots0 = *snapshots.Get();
+
 std::map::iterator it = 
snapshots0.find(typeId);
 if (it != snapshots0.end())
 return SharedPointer(new 
BinaryTypeHandler(it->second));
@@ -65,7 +65,7 @@
 
 void BinaryTypeManager::SubmitHandler(BinaryTypeHandler& hnd)
 {
-// If this is the very first write of a class or difference 
exists, 
+// If this is the very first write of a class or difference 
exists,
 // we need to enqueue it for write.
 if (hnd.HasUpdate())
 {
@@ -152,6 +152,8 @@
 
 SPSnap BinaryTypeManager::GetMeta(int32_t typeId)
 {
+CsLockGuard guard(cs);
+
 std::map::iterator it = 
snapshots.Get()->find(typeId);
 
 if (it != snapshots.Get()->end() && it->second.Get())
@@ -175,4 +177,4 @@
 }
 }
 }
-}
\ No newline at end of file
+}
{code}

I am not sure about the lock in `GetMeta` though.

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  

[jira] [Comment Edited] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-5097 at 5/15/17 3:27 PM:
-

[~isapego] how is it solved in Java? Do we always know collection size before 
hand?
.NET will have the same problem in *some* cases (lazy collections). I guess we 
shoud just use varlen when possible, and reserve 4 bytes otherwise.


was (Author: ptupitsyn):
[~isapego] how is it solved in Java? Do we always know collection size before 
hand?
.NET will have the same problem in *some* cases. I guess we shoud just use 
varlen when possible, and reserve 4 bytes otherwise.

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



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

[jira] [Commented] (IGNITE-5208) C++ Segfault on Put

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5208:
-

The issue seems to be caused by concurrent {{map}} access in 
{{BinaryTypeManager}}, not with the {{SharedPointer}} class. This also explains 
why crash only happens in the beginning - once all type metadata is in cache 
there no more concurrent changing of that {{map}} object. Working on resolving 
the issue.

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places.



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

[jira] [Commented] (IGNITE-5225) TcpCommunicationSpi.createTcpClient can cause OOME.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5225:


GitHub user AMashenkov opened a pull request:

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

IGNITE-5225: Fixed thread pools incorrect shutdown.



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

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

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

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


commit 66cef22366a8129f54a4839792a4b24e8014c00c
Author: Andrey V. Mashenkov 
Date:   2017-05-15T14:39:52Z

IGNITE-5225: Fixed thread pools incorrect shutdown.




> TcpCommunicationSpi.createTcpClient can cause OOME.
> ---
>
> Key: IGNITE-5225
> URL: https://issues.apache.org/jira/browse/IGNITE-5225
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.1
>
>
> TcpCommunicationSpi.filterReachable method doesn't shutdown executor 
> correctly that causes OOME.
> Possible reason is that user uses host name that can't be resolved somewhere 
> in configuration.
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
> message to remote node: TcpDiscoveryNode 
> [id=edcb71b0-bd61-455a-8742-ade1653b0701, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.162.115.12, 127.0.
> 0.1], sockAddrs=[0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, 
> ny4gets6p.jc.jefco.com/10.162.115.12:0], discPort=0, order=25, intOrder=25, 
> lastExchangeTime=1494183620982, loc=false, ver=1.8.5#20170331-sha1:2d3377c0,
>  isClient=true]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2368)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2304)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1283)
> ... 34 more
> Caused by: class org.apache.ignite.IgniteCheckedException: 
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7228)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2515)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2340)
> ... 36 more
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at 
> org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1884)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2775)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2587)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2479)
> ... 37 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.reachable(IgniteUtils.java:2091)
> at 
> org.apache.ignite.internal.util.IgniteUtils$18.run(IgniteUtils.java:1873)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)



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

[jira] [Commented] (IGNITE-4842) IgniteCache.containsKey() may return false if entry is not in local backup yet on atomic cache

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev commented on IGNITE-4842:
-

Hi Semen,

I've fixed it, please check.

Thanks!

> IgniteCache.containsKey() may return false if entry is not in local backup 
> yet on atomic cache
> --
>
> Key: IGNITE-4842
> URL: https://issues.apache.org/jira/browse/IGNITE-4842
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 2.1
>
>
> Reproducer is in [PR#1641|https://github.com/apache/ignite/pull/1641]



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

[jira] [Assigned] (IGNITE-5227) StackOverflowError in GridCacheMapEntry#checkOwnerChanged()

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-5227:


Assignee: Alexey Goncharuk

> StackOverflowError in GridCacheMapEntry#checkOwnerChanged()
> ---
>
> Key: IGNITE-5227
> URL: https://issues.apache.org/jira/browse/IGNITE-5227
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.1
>
>
> A simple test reproducing this error:
> {code}
> /**
>  * @throws Exception if failed.
>  */
> public void testBatchUnlock() throws Exception {
> startGrid(0);
> try {
> final CountDownLatch releaseLatch = new CountDownLatch(1);
> IgniteInternalFuture fut = GridTestUtils.runAsync(new 
> Callable() {
> @Override public Object call() throws Exception {
> IgniteCache cache = grid(0).cache(null);
> Lock lock = cache.lock("key");
> try {
> lock.lock();
> releaseLatch.await();
> }
> finally {
> lock.unlock();
> }
> return null;
> }
> });
> Map putMap = new LinkedHashMap<>();
> putMap.put("key", "trigger");
> for (int i = 0; i < 10_000; i++)
> putMap.put("key-" + i, "value");
> IgniteCache asyncCache = 
> grid(0).cache(null).withAsync();
> asyncCache.putAll(putMap);
> IgniteFuture resFut = asyncCache.future();
> Thread.sleep(1000);
> releaseLatch.countDown();
> fut.get();
> resFut.get();
> }
> finally {
> stopAllGrids();
> }
> {code}
> We should replace a recursive call with a simple iteration over the linked 
> list.



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

[jira] [Created] (IGNITE-5227) StackOverflowError in GridCacheMapEntry#checkOwnerChanged()

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-5227:


 Summary: StackOverflowError in 
GridCacheMapEntry#checkOwnerChanged()
 Key: IGNITE-5227
 URL: https://issues.apache.org/jira/browse/IGNITE-5227
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Alexey Goncharuk
Priority: Critical
 Fix For: 2.1


A simple test reproducing this error:
{code}
/**
 * @throws Exception if failed.
 */
public void testBatchUnlock() throws Exception {
startGrid(0);

try {
final CountDownLatch releaseLatch = new CountDownLatch(1);

IgniteInternalFuture fut = GridTestUtils.runAsync(new 
Callable() {
@Override public Object call() throws Exception {
IgniteCache cache = grid(0).cache(null);

Lock lock = cache.lock("key");

try {
lock.lock();

releaseLatch.await();
}
finally {
lock.unlock();
}

return null;
}
});

Map putMap = new LinkedHashMap<>();

putMap.put("key", "trigger");

for (int i = 0; i < 10_000; i++)
putMap.put("key-" + i, "value");

IgniteCache asyncCache = 
grid(0).cache(null).withAsync();

asyncCache.putAll(putMap);

IgniteFuture resFut = asyncCache.future();

Thread.sleep(1000);

releaseLatch.countDown();

fut.get();

resFut.get();
}
finally {
stopAllGrids();
}
{code}
We should replace a recursive call with a simple iteration over the linked list.



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

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5097:
-

Hi, guys,
There is an issue with implementation for Collections, Maps and Arrays of 
objects - in C++ length of these types implemented in 3 steps:
1. Open writing session;
2. Write objects one by one;
3. Close session.

As you can see, the length of the of these types is unknown upon session 
opening. Previously we were just reserving 4 bytes for length and were writing 
it on session closing. Now we can't know how much bytes to reserve, as the 
length field is now of a variable length.

[~daradurvs], [~vozerov], [~ptupitsyn], what do you guys think? Do we really 
need this optimisation for map/collection/object array?

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



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

[jira] [Commented] (IGNITE-5153) CPP: BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5153:
-

There is an issue with implementation for Collections, Maps and Arrays of 
objects - in C++ length of these types implemented in 3 steps:
1. Open writing session;
2. Write objects one by one;
3. Close session.

As you can see, the length of the of these types is unknown upon session 
opening. Previously we were just reserving 4 bytes for length and were writing 
it on session closing. Now we can't know how much bytes to reserve, as the 
length field is now of a variable length.

> CPP: BinaryMarshaller should write ints in "varint" encoding where it makes 
> sense
> -
>
> Key: IGNITE-5153
> URL: https://issues.apache.org/jira/browse/IGNITE-5153
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vyacheslav Daradur
>Assignee: Igor Sapego
> Fix For: 2.1
>
>
> Need to implement IGNITE-5097



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

[jira] [Comment Edited] (IGNITE-5155) Need to improve stats dump on exchange timeout

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny edited comment on IGNITE-5155 at 5/15/17 2:04 PM:
-

Semen told that he already realize more of listed enhancements.


was (Author: zstan):
Semen told that he already realize more of listed enhacements.

> Need to improve stats dump on exchange timeout
> --
>
> Key: IGNITE-5155
> URL: https://issues.apache.org/jira/browse/IGNITE-5155
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Stanilovsky Evgeny
> Fix For: 2.1
>
>
> Currently, on large topologies info dumped on "Failed to wait for partition 
> map exchange" 
> (org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java:1713)
>  floods the log and we need to reduce information dumped.
> 1. Reduce output for exchange futures that are already done. Keep event, 
> topology version, servers count, clients count (more?)
> 2. Do not dump the whole communication stats, but send message to exchange 
> coordinator, ask for its status and for number of messages received and for 
> acked messages from local node.
> 3. we can think of sending new message from cache node to coordinator that 
> may be a sign of a problem on that node (e.g. unreleased tx locks or still 
> renting partitions) and coordinator may include this info to a status thus 
> every Ignite node may point to a problem node in the logs.



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

[jira] [Commented] (IGNITE-5155) Need to improve stats dump on exchange timeout

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny commented on IGNITE-5155:


Semen told that he already realize more of listed enhacements.

> Need to improve stats dump on exchange timeout
> --
>
> Key: IGNITE-5155
> URL: https://issues.apache.org/jira/browse/IGNITE-5155
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Stanilovsky Evgeny
> Fix For: 2.1
>
>
> Currently, on large topologies info dumped on "Failed to wait for partition 
> map exchange" 
> (org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java:1713)
>  floods the log and we need to reduce information dumped.
> 1. Reduce output for exchange futures that are already done. Keep event, 
> topology version, servers count, clients count (more?)
> 2. Do not dump the whole communication stats, but send message to exchange 
> coordinator, ask for its status and for number of messages received and for 
> acked messages from local node.
> 3. we can think of sending new message from cache node to coordinator that 
> may be a sign of a problem on that node (e.g. unreleased tx locks or still 
> renting partitions) and coordinator may include this info to a status thus 
> every Ignite node may point to a problem node in the logs.



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

[jira] [Assigned] (IGNITE-4947) Create AI 2.0 TC suites

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reassigned IGNITE-4947:
--

Assignee: Dmitriy Pavlov  (was: Alexander Paschenko)

> Create AI 2.0 TC suites
> ---
>
> Key: IGNITE-4947
> URL: https://issues.apache.org/jira/browse/IGNITE-4947
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.0
>Reporter: Alexander Paschenko
>Assignee: Dmitriy Pavlov
> Fix For: 2.1
>
>
> Due to OptimizedMarshaller removal from public API per IGNITE-4938, we need 
> all-new post-OptimizedMarshaller set of TC suites that will be used by 
> default after 2.0 is released.
> What has to be done:
> - Remove all OptimizedMarshaller specific suites
> - Make all 'binary' suites 'standard'



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

[jira] [Assigned] (IGNITE-5225) TcpCommunicationSpi.createTcpClient can cause OOME.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov reassigned IGNITE-5225:


Assignee: Andrew Mashenkov

> TcpCommunicationSpi.createTcpClient can cause OOME.
> ---
>
> Key: IGNITE-5225
> URL: https://issues.apache.org/jira/browse/IGNITE-5225
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.1
>
>
> TcpCommunicationSpi.filterReachable method doesn't shutdown executor 
> correctly that causes OOME.
> Possible reason is that user uses host name that can't be resolved somewhere 
> in configuration.
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
> message to remote node: TcpDiscoveryNode 
> [id=edcb71b0-bd61-455a-8742-ade1653b0701, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.162.115.12, 127.0.
> 0.1], sockAddrs=[0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, 
> ny4gets6p.jc.jefco.com/10.162.115.12:0], discPort=0, order=25, intOrder=25, 
> lastExchangeTime=1494183620982, loc=false, ver=1.8.5#20170331-sha1:2d3377c0,
>  isClient=true]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2368)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2304)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1283)
> ... 34 more
> Caused by: class org.apache.ignite.IgniteCheckedException: 
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7228)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2515)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2340)
> ... 36 more
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at 
> org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1884)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2775)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2587)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2479)
> ... 37 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.reachable(IgniteUtils.java:2091)
> at 
> org.apache.ignite.internal.util.IgniteUtils$18.run(IgniteUtils.java:1873)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)



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

[jira] [Created] (IGNITE-5226) Annotated fields compression

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-5226:
--

 Summary: Annotated fields compression
 Key: IGNITE-5226
 URL: https://issues.apache.org/jira/browse/IGNITE-5226
 Project: Ignite
  Issue Type: New Feature
  Components: binary, cache
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
 Fix For: 2.1


Develop solution for compression of annotated fields of an object.

For example:
{code}
class Foo {
@BinaryCompession
String data;
}
{code}

It must be compatible with querying and indexing.



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

[jira] [Resolved] (IGNITE-4420) .NET: Improve documentation for query configuration combined with reflective serialization

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4420.

Resolution: Fixed

> .NET: Improve documentation for query configuration combined with reflective 
> serialization
> --
>
> Key: IGNITE-4420
> URL: https://issues.apache.org/jira/browse/IGNITE-4420
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> With automatic properties the situation is straightforward: mark property 
> with [QuerySqlField].
> With manual backing fields there may be some confusion, because reflective 
> serializer operates on fields, and field names start with "_" in default 
> naming convention. 
> Make sure all situations are documented properly.



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

[jira] [Commented] (IGNITE-4420) .NET: Improve documentation for query configuration combined with reflective serialization

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4420:


Docs updated with {{Field Names and Serialization}} section: 
https://dash.readme.io/project/apacheignite-net/v2.0/docs/sql-queries

> .NET: Improve documentation for query configuration combined with reflective 
> serialization
> --
>
> Key: IGNITE-4420
> URL: https://issues.apache.org/jira/browse/IGNITE-4420
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> With automatic properties the situation is straightforward: mark property 
> with [QuerySqlField].
> With manual backing fields there may be some confusion, because reflective 
> serializer operates on fields, and field names start with "_" in default 
> naming convention. 
> Make sure all situations are documented properly.



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

[jira] [Created] (IGNITE-5225) TcpCommunicationSpi.createTcpClient can cause OOME.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-5225:


 Summary: TcpCommunicationSpi.createTcpClient can cause OOME.
 Key: IGNITE-5225
 URL: https://issues.apache.org/jira/browse/IGNITE-5225
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.0
Reporter: Andrew Mashenkov
 Fix For: 2.1


TcpCommunicationSpi.filterReachable method doesn't shutdown executor correctly 
that causes OOME.
Possible reason is that user uses host name that can't be resolved somewhere in 
configuration.

Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
message to remote node: TcpDiscoveryNode 
[id=edcb71b0-bd61-455a-8742-ade1653b0701, addrs=[0:0:0:0:0:0:0:1%lo, 
10.162.115.12, 127.0.
0.1], sockAddrs=[0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, 
ny4gets6p.jc.jefco.com/10.162.115.12:0], discPort=0, order=25, intOrder=25, 
lastExchangeTime=1494183620982, loc=false, ver=1.8.5#20170331-sha1:2d3377c0,
 isClient=true]
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2368)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2304)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1283)
... 34 more
Caused by: class org.apache.ignite.IgniteCheckedException: 
java.lang.NullPointerException
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7228)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2515)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2340)
... 36 more
Caused by: java.util.concurrent.ExecutionException: 
java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1884)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2775)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2587)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2479)
... 37 more
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.util.IgniteUtils.reachable(IgniteUtils.java:2091)
at 
org.apache.ignite.internal.util.IgniteUtils$18.run(IgniteUtils.java:1873)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)




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

[jira] [Resolved] (IGNITE-4360) .NET: LINQ documentation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4360.

Resolution: Fixed

> .NET: LINQ documentation
> 
>
> Key: IGNITE-4360
> URL: https://issues.apache.org/jira/browse/IGNITE-4360
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> Document thoroughly what is supported in LINQ, especially all the methods 
> from MethodVisitor, since this can be non obvious (like 
> DateTime.ToString("y")).



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

[jira] [Commented] (IGNITE-4360) .NET: LINQ documentation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4360:


{{Supported SQL Functions}} added to LINQ page: 
https://apacheignite-net.readme.io/docs/linq#section-supported-sql-functions

> .NET: LINQ documentation
> 
>
> Key: IGNITE-4360
> URL: https://issues.apache.org/jira/browse/IGNITE-4360
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> Document thoroughly what is supported in LINQ, especially all the methods 
> from MethodVisitor, since this can be non obvious (like 
> DateTime.ToString("y")).



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

[jira] [Updated] (IGNITE-4360) .NET: LINQ documentation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4360:
---
Labels: .NET LINQ  (was: )

> .NET: LINQ documentation
> 
>
> Key: IGNITE-4360
> URL: https://issues.apache.org/jira/browse/IGNITE-4360
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> Document thoroughly what is supported in LINQ, especially all the methods 
> from MethodVisitor, since this can be non obvious (like 
> DateTime.ToString("y")).



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

[jira] [Updated] (IGNITE-5224) .NET: PadLeft and PadRight support in LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5224:
---
Description: Add {{String.PadLeft}} and {{String.PadRight}} functions to 
LINQ, map them to SQL {{LPAD}} and {{RPAD}}. See {{MethodVisitor.cs}}.  (was: 
Add {{String.PadLeft}} and {{String.PadRight}} functions to LINQ, map them to 
SQL {{LPAD}} and {{RPAD}}.)

> .NET: PadLeft and PadRight support in LINQ
> --
>
> Key: IGNITE-5224
> URL: https://issues.apache.org/jira/browse/IGNITE-5224
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET, LINQ
> Fix For: 2.1
>
>
> Add {{String.PadLeft}} and {{String.PadRight}} functions to LINQ, map them to 
> SQL {{LPAD}} and {{RPAD}}. See {{MethodVisitor.cs}}.



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

[jira] [Updated] (IGNITE-5222) .NET: LINQ does not support IndexOf with char overloads

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5222:
---
Description: 
This works:
{{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf("a")).Dump();}}

This does not:
{{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf('a')).Dump();}}

See {{MethodVisitor.cs}}.

  was:
This works:
{{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf("a")).Dump();}}

This does not:
{{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf('a')).Dump();}}


> .NET: LINQ does not support IndexOf with char overloads
> ---
>
> Key: IGNITE-5222
> URL: https://issues.apache.org/jira/browse/IGNITE-5222
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET, LINQ
> Fix For: 2.1
>
>
> This works:
> {{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf("a")).Dump();}}
> This does not:
> {{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf('a')).Dump();}}
> See {{MethodVisitor.cs}}.



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

[jira] [Created] (IGNITE-5223) Allow use local binary metadata cache if it's possible

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-5223:
---

 Summary: Allow use local binary metadata cache if it's possible
 Key: IGNITE-5223
 URL: https://issues.apache.org/jira/browse/IGNITE-5223
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.9
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev
 Fix For: 1.9


Add system property that will use local binary metadata cache instead of 
distributed one, when all classes available on all nodes and don't change.



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

[jira] [Assigned] (IGNITE-5215) Allow user to configure memory policy with maxSize lesser than default initialSize

[Ivan Rakov (JIRA)]

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

Ivan Rakov reassigned IGNITE-5215:
--

Assignee: Alexey Goncharuk  (was: Ivan Rakov)

> Allow user to configure memory policy with maxSize lesser than default 
> initialSize
> --
>
> Key: IGNITE-5215
> URL: https://issues.apache.org/jira/browse/IGNITE-5215
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.0
>Reporter: Ivan Rakov
>Assignee: Alexey Goncharuk
>
> Attempt to create memory policy with small maxSize ends with error:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: MemoryPolicy 
> maxSize must not be smaller than initialSize [name=dfltMemPlc, initSize=268,4 
> MB, maxSize=209,7 MB]
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.checkPolicySize(IgniteCacheDatabaseSharedManager.java:419)
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.validateConfiguration(IgniteCacheDatabaseSharedManager.java:337)
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.init(IgniteCacheDatabaseSharedManager.java:112)
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:99)
>   at 
> org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.initDataBase(GridCacheDatabaseSharedManager.java:493)
>   at 
> org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:436)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:53)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:644)
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1763)
>   ... 29 more
> {noformat}
> This can be easily fixed by setting initialSize. Though, it would be better 
> to don't oblige user to spend time on fixing it.



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

[jira] [Commented] (IGNITE-5215) Allow user to configure memory policy with maxSize lesser than default initialSize

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5215:


GitHub user glukos opened a pull request:

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

IGNITE-5215: Allow user to configure memory policy with maxSize lesse…



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

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

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

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


commit 6319266003704b4bc478de9ba0af6b4c5f84af9a
Author: Ivan Rakov 
Date:   2017-05-15T12:27:00Z

IGNITE-5215: Allow user to configure memory policy with maxSize lesser than 
default initialSize




> Allow user to configure memory policy with maxSize lesser than default 
> initialSize
> --
>
> Key: IGNITE-5215
> URL: https://issues.apache.org/jira/browse/IGNITE-5215
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.0
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>
> Attempt to create memory policy with small maxSize ends with error:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: MemoryPolicy 
> maxSize must not be smaller than initialSize [name=dfltMemPlc, initSize=268,4 
> MB, maxSize=209,7 MB]
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.checkPolicySize(IgniteCacheDatabaseSharedManager.java:419)
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.validateConfiguration(IgniteCacheDatabaseSharedManager.java:337)
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.init(IgniteCacheDatabaseSharedManager.java:112)
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:99)
>   at 
> org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.initDataBase(GridCacheDatabaseSharedManager.java:493)
>   at 
> org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:436)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:53)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:644)
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1763)
>   ... 29 more
> {noformat}
> This can be easily fixed by setting initialSize. Though, it would be better 
> to don't oblige user to spend time on fixing it.



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

[jira] [Created] (IGNITE-5222) .NET: LINQ does not support IndexOf with char overloads

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5222:
--

 Summary: .NET: LINQ does not support IndexOf with char overloads
 Key: IGNITE-5222
 URL: https://issues.apache.org/jira/browse/IGNITE-5222
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.1


This works:
{{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf("a")).Dump();}}

This does not:
{{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf('a')).Dump();}}



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

[jira] [Resolved] (IGNITE-5029) Ignite ML next steps

[Yury Babak (JIRA)]

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

Yury Babak resolved IGNITE-5029.

   Resolution: Done
Fix Version/s: 2.1

The separate tickets was created for all planned features/fixes.

> Ignite ML next steps
> 
>
> Key: IGNITE-5029
> URL: https://issues.apache.org/jira/browse/IGNITE-5029
> Project: Ignite
>  Issue Type: Task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.1
>
>
> We want to find out what should be done next 3 months.
> Currently we thinking about the following areas:
> 1) [~oignatenko] - Regression and clustering algorithms. 
> 2) [~amalykh] - Deep Learning/Neural Networks stuff.
> 3) [~chief] - DSL/scripting support.



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

[jira] [Created] (IGNITE-5221) Investigate possibility of integrating with dl4j

[Artem Malykh (JIRA)]

Artem Malykh created IGNITE-5221:


 Summary: Investigate possibility of integrating with dl4j
 Key: IGNITE-5221
 URL: https://issues.apache.org/jira/browse/IGNITE-5221
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.1
Reporter: Artem Malykh
 Fix For: 2.1


Investigate if there is an easy possibility for integration of apache ignite 
with dl4j.



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

[jira] [Created] (IGNITE-5220) Partial derivatives calculation.

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5220:
--

 Summary: Partial derivatives calculation.
 Key: IGNITE-5220
 URL: https://issues.apache.org/jira/browse/IGNITE-5220
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Yury Babak


We need mechanism of computation of partial derivatives which we need for 
gradient descent.



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

[jira] [Created] (IGNITE-5219) Generalization of cost function for Linear Regression.

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5219:
--

 Summary: Generalization of cost function for Linear Regression.
 Key: IGNITE-5219
 URL: https://issues.apache.org/jira/browse/IGNITE-5219
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Yury Babak


We want to add support of custom cost functions for Linear Regression.



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

[jira] [Updated] (IGNITE-5114) Parallalel plus/multiply matrix algorithms.

[Yury Babak (JIRA)]

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

Yury Babak updated IGNITE-5114:
---
Component/s: ml

> Parallalel plus/multiply matrix algorithms.
> ---
>
> Key: IGNITE-5114
> URL: https://issues.apache.org/jira/browse/IGNITE-5114
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>
> We need design and implement parallel(distributed?) versions of matrix 
> plus/multiply algorithms because current implementation is implemented by 
> definition. Those implementations is really slow.



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

[jira] [Updated] (IGNITE-5217) Gradient descent

[Yury Babak (JIRA)]

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

Yury Babak updated IGNITE-5217:
---
Issue Type: New Feature  (was: Task)

> Gradient descent
> 
>
> Key: IGNITE-5217
> URL: https://issues.apache.org/jira/browse/IGNITE-5217
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>
> We should implement Gradient Descent for Ignite ML. Current we have only 
> normal equation for linear regression.



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

[jira] [Updated] (IGNITE-5218) Decision trees

[Yury Babak (JIRA)]

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

Yury Babak updated IGNITE-5218:
---
Issue Type: New Feature  (was: Task)

> Decision trees
> --
>
> Key: IGNITE-5218
> URL: https://issues.apache.org/jira/browse/IGNITE-5218
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>
> We want to implement Decision trees for Ignite ML because it's really common 
> one for ML.



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

[jira] [Updated] (IGNITE-5216) Add Stream API support to Ignite ML matrices.

[Yury Babak (JIRA)]

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

Yury Babak updated IGNITE-5216:
---
Issue Type: New Feature  (was: Task)

> Add Stream API support to Ignite ML matrices.
> -
>
> Key: IGNITE-5216
> URL: https://issues.apache.org/jira/browse/IGNITE-5216
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>
> We want to add Stream API support to Ignite matrices and possibly to vectors. 
> We already have implementation of Spliterator for AbstractVector and 
> AbstractMatrix so it's looks like next step.



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

[jira] [Created] (IGNITE-5218) Decision trees

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5218:
--

 Summary: Decision trees
 Key: IGNITE-5218
 URL: https://issues.apache.org/jira/browse/IGNITE-5218
 Project: Ignite
  Issue Type: Task
  Components: ml
Reporter: Yury Babak


We want to implement Decision trees for Ignite ML because it's really common 
one for ML.



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

[jira] [Created] (IGNITE-5217) Gradient descent

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5217:
--

 Summary: Gradient descent
 Key: IGNITE-5217
 URL: https://issues.apache.org/jira/browse/IGNITE-5217
 Project: Ignite
  Issue Type: Task
  Components: ml
Reporter: Yury Babak


We should implement Gradient Descent for Ignite ML. Current we have only normal 
equation for linear regression.



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

[jira] [Created] (IGNITE-5216) Add Stream API support to Ignite ML matrices.

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5216:
--

 Summary: Add Stream API support to Ignite ML matrices.
 Key: IGNITE-5216
 URL: https://issues.apache.org/jira/browse/IGNITE-5216
 Project: Ignite
  Issue Type: Task
  Components: ml
Reporter: Yury Babak


We want to add Stream API support to Ignite matrices and possibly to vectors. 
We already have implementation of Spliterator for AbstractVector and 
AbstractMatrix so it's looks like next step.



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

[jira] [Updated] (IGNITE-5215) Allow user to configure memory policy with maxSize lesser than default initialSize

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5215:
---
Description: 
Attempt to create memory policy with small maxSize ends with error:
{noformat}
Caused by: class org.apache.ignite.IgniteCheckedException: MemoryPolicy maxSize 
must not be smaller than initialSize [name=dfltMemPlc, initSize=268,4 MB, 
maxSize=209,7 MB]
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.checkPolicySize(IgniteCacheDatabaseSharedManager.java:419)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.validateConfiguration(IgniteCacheDatabaseSharedManager.java:337)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.init(IgniteCacheDatabaseSharedManager.java:112)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:99)
at 
org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.initDataBase(GridCacheDatabaseSharedManager.java:493)
at 
org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:436)
at 
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:53)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:644)
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1763)
... 29 more
{noformat}
This can be easily fixed by setting initialSize. Though, it would be better to 
don't oblige user to spend time on fixing it.

  was:
Attempt to create memory policy with small maxSize ends with error:
{noformat}
Caused by: class org.apache.ignite.IgniteCheckedException: MemoryPolicy maxSize 
must not be smaller than initialSize [name=dfltMemPlc, initSize=268,4 MB, 
maxSize=209,7 MB]
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.checkPolicySize(IgniteCacheDatabaseSharedManager.java:419)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.validateConfiguration(IgniteCacheDatabaseSharedManager.java:337)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.init(IgniteCacheDatabaseSharedManager.java:112)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:99)
at 
org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.initDataBase(GridCacheDatabaseSharedManager.java:493)
at 
org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:436)
at 
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:53)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:644)
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1763)
... 29 more
{noformat}
This can be easily fixed by setting initialSize. Though, it would be better to 
don't oblige user spending time on fixing it.


> Allow user to configure memory policy with maxSize lesser than default 
> initialSize
> --
>
> Key: IGNITE-5215
> URL: https://issues.apache.org/jira/browse/IGNITE-5215
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.0
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>
> Attempt to create memory policy with small maxSize ends with error:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: MemoryPolicy 
> maxSize must not be smaller than initialSize [name=dfltMemPlc, initSize=268,4 
> MB, maxSize=209,7 MB]
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.checkPolicySize(IgniteCacheDatabaseSharedManager.java:419)
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.validateConfiguration(IgniteCacheDatabaseSharedManager.java:337)
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.init(IgniteCacheDatabaseSharedManager.java:112)
>   at 
> org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:99)
>   at 
> 

[jira] [Created] (IGNITE-5215) Allow user to configure memory policy with maxSize lesser than default initialSize

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-5215:
--

 Summary: Allow user to configure memory policy with maxSize lesser 
than default initialSize
 Key: IGNITE-5215
 URL: https://issues.apache.org/jira/browse/IGNITE-5215
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.0
Reporter: Ivan Rakov
Assignee: Ivan Rakov


Attempt to create memory policy with small maxSize ends with error:
{noformat}
Caused by: class org.apache.ignite.IgniteCheckedException: MemoryPolicy maxSize 
must not be smaller than initialSize [name=dfltMemPlc, initSize=268,4 MB, 
maxSize=209,7 MB]
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.checkPolicySize(IgniteCacheDatabaseSharedManager.java:419)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.validateConfiguration(IgniteCacheDatabaseSharedManager.java:337)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.init(IgniteCacheDatabaseSharedManager.java:112)
at 
org.apache.ignite.internal.processors.cache.database.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:99)
at 
org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.initDataBase(GridCacheDatabaseSharedManager.java:493)
at 
org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:436)
at 
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:53)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:644)
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1763)
... 29 more
{noformat}
This can be easily fixed by setting initialSize. Though, it would be better to 
don't oblige user spending time on fixing it.



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

[jira] [Commented] (IGNITE-2492) .NET: Peer assembly loading

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2492:


[~vozerov] peer deployment implemented and enabled for Compute API. Please 
review.
Other APIs can be enabled later easily.

> .NET: Peer assembly loading
> ---
>
> Key: IGNITE-2492
> URL: https://issues.apache.org/jira/browse/IGNITE-2492
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.1
>
>
> Similar to peer class loading in Java, we can provide a possibility to load 
> assemblies on already started nodes, so that a node can execute jobs that are 
> not present on other nodes.
> Considerations:
> * Can we unload assemblies after use to free memory? This requires a separate 
> AppDomain, can we work with that?



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

[jira] [Commented] (IGNITE-2492) .NET: Peer assembly loading

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2492:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-2492 .NET: Peer assembly loading



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

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

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

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


commit 44f3d90e4e162460754ba4e7d2158ca25d0dbec1
Author: Pavel Tupitsyn 
Date:   2017-01-11T14:12:50Z

Adding tests

commit 60772b69cc059326b873aee8866dbf74aedeb1b1
Author: Pavel Tupitsyn 
Date:   2017-01-11T15:42:12Z

wip tests

commit f099a22bd2632cf3da2fb537fdffc533e46c25de
Author: Pavel Tupitsyn 
Date:   2017-01-11T16:18:21Z

wip tests

commit f4e036c9211c99c98a51ccafa6ff86eaec9391b4
Author: Pavel Tupitsyn 
Date:   2017-01-11T16:18:44Z

wip

commit 5ac39038ec816f81cdd960745d39fdc6d08c8efc
Author: Pavel Tupitsyn 
Date:   2017-01-11T16:29:52Z

wip tests

commit 3fdd04c0adfc13d3be1ab1066bf5f85efde5769d
Author: Pavel Tupitsyn 
Date:   2017-01-11T16:30:05Z

wip

commit 4792aa1bbb1b2440f340748f2a56f3954d34eb8b
Author: Pavel Tupitsyn 
Date:   2017-01-11T16:38:14Z

wip

commit fe20574763b494c82bd6672ac7538de4083b6d8d
Author: Pavel Tupitsyn 
Date:   2017-01-12T12:08:30Z

wip tests

commit 58a8ff78e8b8eb1d22c19cc5d6d6e8f55a07d325
Author: Pavel Tupitsyn 
Date:   2017-01-12T12:12:21Z

Test done

commit 0e371fbc9787625376d41921fb07e9d7aa2ddc74
Author: Pavel Tupitsyn 
Date:   2017-01-12T12:28:44Z

Remove current assembly resolver

commit 726ed99a4e00d6e5494e2f8abacf810483be2a94
Author: Pavel Tupitsyn 
Date:   2017-01-12T12:50:06Z

wip

commit 224f6465a6b1bb8c272fda56ecf1265ecd379388
Author: Pavel Tupitsyn 
Date:   2017-01-12T13:16:01Z

Refactor LoadedAssembliesResolver usage to SerializableObjectHolder

commit 884246e39b798e9137a1d5d6cf166babe9395fa9
Author: Pavel Tupitsyn 
Date:   2017-01-12T13:39:11Z

IsPeerAssemblyLoadingEnabled

commit cda5f9e01430f49e5961515e8fb0e6db51de0a92
Author: Pavel Tupitsyn 
Date:   2017-01-12T13:47:30Z

PeerAssemblyResolver added

commit 4ff92856a859ae8b32583a5861a46fdf02801991
Author: Pavel Tupitsyn 
Date:   2017-01-12T13:54:42Z

GetAssemblyFunc

commit f52526cc7daf6cb28e598c6e17facf18c611873f
Author: Pavel Tupitsyn 
Date:   2017-01-12T14:01:37Z

wip AssemblyLoader

commit a113edc6bd082b7bf2530b3e599244fb199b3b22
Author: Pavel Tupitsyn 
Date:   2017-01-12T14:08:44Z

wip

commit 65f5aedb212282d39355192d2d96829a9edee2cf
Author: Pavel Tupitsyn 
Date:   2017-01-12T15:19:14Z

wip

commit 068e64b84e1c2d39987ab4fdd1592db4cd55f58f
Author: Pavel Tupitsyn 
Date:   2017-01-12T15:24:10Z

wip

commit ffd896b19c8b3cca23b17944c3483b292bb73ce3
Author: Pavel Tupitsyn 
Date:   2017-01-12T15:43:00Z

wip tests

commit 75cbc6e12365c852e42652ec05a26b8b55a4fc50
Author: Pavel Tupitsyn 
Date:   2017-01-12T15:46:04Z

fix cluster

commit 1a004add3531f202fc5a82980dfbeaa879fbbf70
Author: Pavel Tupitsyn 
Date:   2017-01-12T16:02:14Z

Fix lazy instance

commit c66463a94f51df588addbc13069cd3f6f8473e6d
Author: Pavel Tupitsyn 
Date:   2017-01-12T16:18:33Z

Register system func

commit d103f134d9eee29a33fb23683b193ef48a775c29
Author: Pavel Tupitsyn 
Date:   2017-01-12T16:30:32Z

GetAssemblyByNameFunc

commit ea76139afe15543c07b2e1d24f41b00e72f74df9
Author: Pavel Tupitsyn 
Date:   2017-01-12T16:34:20Z

Test works for Serializable!

commit f75b2879919382d7316aa97113f7d48535b248b9
Author: Pavel Tupitsyn 
Date:   2017-01-12T16:41:17Z

binarizable test

commit 8f11f440dfa02bd3bb1dbee2892f3c79a7074216
Author: Pavel Tupitsyn 
Date:   2017-01-12T16:53:07Z

Fix binarizable test

commit fab4dca2715c2ba8d257e3729f08045dfe661f98
Author: Pavel Tupitsyn 
Date:   2017-01-13T07:48:05Z

Update config schema

commit 733aa0f5e96745286abac34305562000c73d90e2
Author: Pavel Tupitsyn 
Date:   2017-01-13T07:50:34Z

[jira] [Updated] (IGNITE-4052) Add ability to set up users for MESOS

[Vadim Opolski (JIRA)]

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

Vadim Opolski updated IGNITE-4052:
--

Hello Prachi!

I reassigned issue https://issues.apache.org/jira/browse/IGNITE-4052 to you
to approve changes of page -
https://apacheignite.readme.io/docs/mesos-deployment#section-ignite-mesos-framework

Vadim




> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Prachi Garg
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



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

[jira] [Assigned] (IGNITE-5100) Exchange queue is not used properly

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny reassigned IGNITE-5100:
--

Assignee: Stanilovsky Evgeny

> Exchange queue is not used properly
> ---
>
> Key: IGNITE-5100
> URL: https://issues.apache.org/jira/browse/IGNITE-5100
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Fix For: 2.1
>
>
> Currently exchange futures share same queue for pending(incomplete) and 
> completed exchanges.
> The queue has fixed hardcoded size of 1000.
> This leads to a problem when > 1000 nodes try to enter grid.
> In such case oldest exchanges will be removed by ExchangeFutureSet size 
> limit, leading to whole exchange hanging.
> Solution: 
> 1. Use separate queues for pending and completed exchanges.
> 2. Pending exchange queue must be unbounded.
> 3. Add system property to control exchange history.



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

[jira] [Assigned] (IGNITE-5212) Allow custom affinity for system caches

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov reassigned IGNITE-5212:
-

Assignee: Vladislav Pyatkov

> Allow custom affinity for system caches
> ---
>
> Key: IGNITE-5212
> URL: https://issues.apache.org/jira/browse/IGNITE-5212
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Vladislav Pyatkov
>  Labels: newbie
>
> Currently there is no option to specify affinity function atomics system 
> cache, which may be not appropriate in custom data placement scenarios.
> Suggestion: allow setting custom affinity for AtomicConfiguration



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

[jira] [Resolved] (IGNITE-5213) .NET: Reflective serializer fails on custom dictionaries

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-5213.

Resolution: Fixed

> .NET: Reflective serializer fails on custom dictionaries 
> -
>
> Key: IGNITE-5213
> URL: https://issues.apache.org/jira/browse/IGNITE-5213
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> See {{BinaryReflectiveActions:489}}. All types that implement {{IDictionary}} 
> and are not generic are written as {{Hashtable}}, which is not correct, since 
> type information is lost. Deserialization fails with {{InvalidCastException}}.



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

[jira] [Commented] (IGNITE-5213) .NET: Reflective serializer fails on custom dictionaries

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5213:


Fixed in master: only {{ICollection}}, {{ArrayList}}, {{IDictionary}}, 
{{Hashtable}} fields are now written in Java format, all other fields are 
written as objects.

> .NET: Reflective serializer fails on custom dictionaries 
> -
>
> Key: IGNITE-5213
> URL: https://issues.apache.org/jira/browse/IGNITE-5213
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> See {{BinaryReflectiveActions:489}}. All types that implement {{IDictionary}} 
> and are not generic are written as {{Hashtable}}, which is not correct, since 
> type information is lost. Deserialization fails with {{InvalidCastException}}.



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

[jira] [Assigned] (IGNITE-4052) Add ability to set up users for MESOS

[Vadim Opolski (JIRA)]

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

Vadim Opolski reassigned IGNITE-4052:
-

Assignee: Prachi Garg  (was: Vadim Opolski)

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Prachi Garg
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



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

[jira] [Updated] (IGNITE-5214) ConcurrentModificationException with enable DEBUG log level

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-5214:
-
Attachment: IGNITE_5214.patch

> ConcurrentModificationException with enable DEBUG log level
> ---
>
> Key: IGNITE-5214
> URL: https://issues.apache.org/jira/browse/IGNITE-5214
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
>Assignee: Nikolay Tikhonov
> Attachments: IGNITE_5214.patch
>
>
> ConcurrentModificationException with 
> org.apache.ignite.continuous.query=DEBUG
> {noformat}
> Unexpected exception during cache update 
> java.util.ConcurrentModificationException: null
>   at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
>   at java.util.TreeMap$EntryIterator.next(TreeMap.java:1247)
>   at java.util.TreeMap$EntryIterator.next(TreeMap.java:1242)
>   at java.util.AbstractMap.toString(AbstractMap.java:554)
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$PartitionRecovery.collectEntries(CacheContinuousQueryHandler.java:1132)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:739)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:792)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$800(CacheContinuousQueryHandler.java:91)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:419)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:347)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2669)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2390)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1792)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1632)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:263)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:208)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1152)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1150)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:847)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAsync0(GridDhtAtomicCache.java:1150)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:619)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2574)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsentAsync(GridDhtAtomicCache.java:664)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsent(GridDhtAtomicCache.java:657)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putIfAbsent(IgniteCacheProxy.java:1451)
>   at 
> com.workday.fabric.ignite.management.IgniteManagementService.doExecute(IgniteManagementService.java:174)
>   at 
> com.workday.fabric.ignite.service.AbstractIgniteService.execute(AbstractIgniteService.java:94)
>   at 
> 

[jira] [Commented] (IGNITE-2492) .NET: Peer assembly loading

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2492:


Transient dependency loading fixed by wrapping all objects in graph and 
subscribing to {{AssemblyResolve}} while performing assembly loading and object 
deserialization.

Uncovered IGNITE-5213 during testing, will fix before continuing with this one.

> .NET: Peer assembly loading
> ---
>
> Key: IGNITE-2492
> URL: https://issues.apache.org/jira/browse/IGNITE-2492
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.1
>
>
> Similar to peer class loading in Java, we can provide a possibility to load 
> assemblies on already started nodes, so that a node can execute jobs that are 
> not present on other nodes.
> Considerations:
> * Can we unload assemblies after use to free memory? This requires a separate 
> AppDomain, can we work with that?



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

[jira] [Updated] (IGNITE-5214) ConcurrentModificationException with enable DEBUG log level

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-5214:
-
Description: 
ConcurrentModificationException with 
org.apache.ignite.continuous.query=DEBUG
{noformat}
Unexpected exception during cache update 
java.util.ConcurrentModificationException: null
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
at java.util.TreeMap$EntryIterator.next(TreeMap.java:1247)
at java.util.TreeMap$EntryIterator.next(TreeMap.java:1242)
at java.util.AbstractMap.toString(AbstractMap.java:554)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$PartitionRecovery.collectEntries(CacheContinuousQueryHandler.java:1132)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:739)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:792)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$800(CacheContinuousQueryHandler.java:91)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:419)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:347)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2669)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2390)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1792)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1632)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:263)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:208)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1152)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1150)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:847)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAsync0(GridDhtAtomicCache.java:1150)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:619)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2574)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsentAsync(GridDhtAtomicCache.java:664)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsent(GridDhtAtomicCache.java:657)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putIfAbsent(IgniteCacheProxy.java:1451)
at 
com.workday.fabric.ignite.management.IgniteManagementService.doExecute(IgniteManagementService.java:174)
at 
com.workday.fabric.ignite.service.AbstractIgniteService.execute(AbstractIgniteService.java:94)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$3.run(GridServiceProcessor.java:1157)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}

  was:
ConcurrentModificationException with 
org.apache.ignite.continuous.query=DEBUG
{{noformat}}
Unexpected 

[jira] [Created] (IGNITE-5213) .NET: Reflective serializer fails on custom dictionaries

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5213:
--

 Summary: .NET: Reflective serializer fails on custom dictionaries 
 Key: IGNITE-5213
 URL: https://issues.apache.org/jira/browse/IGNITE-5213
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.1


See {{BinaryReflectiveActions:489}}. All types that implement {{IDictionary}} 
and are not generic are written as {{Hashtable}}, which is not correct, since 
type information is lost. Deserialization fails with {{InvalidCastException}}.



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

[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-1094:
--

[~DmitriyGovorukhin] 
done.http://reviews.ignite.apache.org/ignite/review/IGNT-CR-181

> Ignite.createCache(CacheConfiguration) hangs if some exception occurs during 
> cache initialization
> -
>
> Key: IGNITE-1094
> URL: https://issues.apache.org/jira/browse/IGNITE-1094
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Sergey Evdokimov
>Assignee: Alexey Kuznetsov
>  Labels: Muted_test
> Fix For: 2.1
>
>
> User can pass broken configuration, for example, store factory that throws 
> exception from create() method. I created test to demonstrate the problem. 
> See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' 
> branch 



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

[jira] [Updated] (IGNITE-5086) Web Console: Redesign of Modal Windows

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-5086:
---
Fix Version/s: 2.1

> Web Console: Redesign of Modal Windows
> --
>
> Key: IGNITE-5086
> URL: https://issues.apache.org/jira/browse/IGNITE-5086
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Affects Versions: 2.1
>Reporter: Vica Abramova
>Assignee: Andrey Novikov
> Fix For: 2.1
>
>




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

[jira] [Assigned] (IGNITE-4447) Remove "Ignite 150 Clients" suite.

[Vadim Opolski (JIRA)]

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

Vadim Opolski reassigned IGNITE-4447:
-

Assignee: Vadim Opolski

> Remove "Ignite 150 Clients" suite.
> --
>
> Key: IGNITE-4447
> URL: https://issues.apache.org/jira/browse/IGNITE-4447
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vadim Opolski
>Priority: Minor
> Fix For: 2.1
>
>
> It has only 1 tests. It runs for ~1m, but takes ~6m including build phase. 
> Let's just embed it into one of cache suites.



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

[jira] [Commented] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5207:


[~vozerov] no changes to the protocol.
* Enums can be {{byte}}, {{sbyte}}, {{short}}, {{ushort}}, {{int}}, {{uint}}, 
{{long}}, {{ulong}}.
* In 2.0 there is an exception for any non-Int32 enum.
* After this fix all enums that fit into 4 bytes are written in Ignite format. 
{{long}} and {{ulong}} enums are written as regular objects with a single field 
(via reflective serializer).


> .NET: Non-Int32 enums can't be serialized
> -
>
> Key: IGNITE-5207
> URL: https://issues.apache.org/jira/browse/IGNITE-5207
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> There is no way to serialize non-Int32 enums. 
> Enums in .NET can be {{byte}}, {{sbyte}}, {{short}}, {{ushort}}, {{int}}, 
> {{uint}}, {{long}}, {{ulong}} (see 
> https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/enum).
> We should write all of these except {{long}} and {{ulong}} properly 
> (converting them to int and back).
> {{long}} and {{ulong}} enums should be written as object.



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

[jira] [Closed] (IGNITE-5165) Web Console: Buttons redesign

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-5165.
--
Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Web Console:  Buttons redesign 
> ---
>
> Key: IGNITE-5165
> URL: https://issues.apache.org/jira/browse/IGNITE-5165
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
> Attachments: 5165 debug page.diff
>
>
> Create common style to all buttons in project.
> Refactoring current style for buttons in 
> web-console/frontend/public/stylesheets/style.scss
> 1) Button with icon and text
> 2) Button with only icon
> 3) Button with only text
> 4) Button group
> 5) fill and stroke buttons for color Red, Blue, White
> Implement class modificator .btn-ignite to apply this features



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

[jira] [Updated] (IGNITE-5165) Web Console: Buttons redesign

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-5165:
---
Fix Version/s: 2.1

> Web Console:  Buttons redesign 
> ---
>
> Key: IGNITE-5165
> URL: https://issues.apache.org/jira/browse/IGNITE-5165
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
> Attachments: 5165 debug page.diff
>
>
> Create common style to all buttons in project.
> Refactoring current style for buttons in 
> web-console/frontend/public/stylesheets/style.scss
> 1) Button with icon and text
> 2) Button with only icon
> 3) Button with only text
> 4) Button group
> 5) fill and stroke buttons for color Red, Blue, White
> Implement class modificator .btn-ignite to apply this features



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

[jira] [Commented] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5207:
-

[~ptupitsyn], could you please clarify how this was fixed? Did it require any 
changes to the protocol?

> .NET: Non-Int32 enums can't be serialized
> -
>
> Key: IGNITE-5207
> URL: https://issues.apache.org/jira/browse/IGNITE-5207
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> There is no way to serialize non-Int32 enums. 
> Enums in .NET can be {{byte}}, {{sbyte}}, {{short}}, {{ushort}}, {{int}}, 
> {{uint}}, {{long}}, {{ulong}} (see 
> https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/enum).
> We should write all of these except {{long}} and {{ulong}} properly 
> (converting them to int and back).
> {{long}} and {{ulong}} enums should be written as object.



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