[jira] [Commented] (IGNITE-2190) ScanQuery without a filter triggers object's deserialization on the server side
[ https://issues.apache.org/jira/browse/IGNITE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.ignite.internal.processors.cache.GridCach
[jira] [Updated] (IGNITE-5229) Specify caches when using Redis protocol
[ 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 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 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.
[ 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()
[ https://issues.apache.org/jira/browse/IGNITE-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ 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
[ 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-5163) JDBC Driver: implement handshake for thin jdbc driver based on common odbc/jdbc protocol
[ https://issues.apache.org/jira/browse/IGNITE-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011256#comment-16011256 ] Taras Ledkov commented on IGNITE-5163: -- [~vozerov], please review the changes at the ODBC/JDBC protocol encoding and JDBC handshake implementation. > JDBC Driver: implement handshake for thin jdbc driver based on common > odbc/jdbc protocol > > > Key: IGNITE-5163 > URL: https://issues.apache.org/jira/browse/IGNITE-5163 > Project: Ignite > Issue Type: Task > Components: odbc, sql >Affects Versions: 1.9 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.1 > > > The GridClient must be removed from thin jdbc driver. > It is the first step to unify JDBC & ODBC protocols. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS
[ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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] [Resolved] (IGNITE-5178) Simplify ML Grid build and release process
[ https://issues.apache.org/jira/browse/IGNITE-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-5178. - Resolution: Won't Fix It was decided to use current build and release procedure. The procedure will be simplified once Apache Ignite drops Java 7 support. > 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
[ https://issues.apache.org/jira/browse/IGNITE-5131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-5225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer > > >*, std::_Rb_tree_node_base*, int const&)+0x41 > C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::find(int const&)+0x45 > C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer, > std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::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
[ https://issues.apache.org/jira/browse/IGNITE-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer > > >*, std::_Rb_tree_node_base*, int const&)+0x41 > C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::find(int const&)+0x45 > C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer, > std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::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
[ https://issues.apache.org/jira/browse/IGNITE-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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 org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioCli
[jira] [Commented] (IGNITE-5208) C++ Segfault on Put
[ https://issues.apache.org/jira/browse/IGNITE-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer > > >*, std::_Rb_tree_node_base*, int const&)+0x41 > C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::find(int const&)+0x45 > C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer, > std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::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.
[ 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 org.apache.ignite.spi.communicatio
[jira] [Comment Edited] (IGNITE-5208) C++ Segfault on Put
[ https://issues.apache.org/jira/browse/IGNITE-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 type of object but not the same objects, > - doing multithreaded `::Put` operation, only one put is done on each cache
[jira] [Commented] (IGNITE-5208) C++ Segfault on Put
[ https://issues.apache.org/jira/browse/IGNITE-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer > > >*, std::_Rb_tree_node_base*, int const&)+0x41 > C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::find(int const&)+0x45 > C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer, > std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::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:n
[jira] [Comment Edited] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16010700#comment-16010700 ] Pavel Tupitsyn commented on IGNITE-5097: [~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
[ https://issues.apache.org/jira/browse/IGNITE-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::_M_lower_bound(std::_Rb_tree_node ignite::common::concurrent::SharedPointer > > >*, std::_Rb_tree_node_base*, int const&)+0x41 > C [test+0x1105a9d] std::_Rb_tree ignite::common::concurrent::SharedPointer > >, std::_Select1st ignite::common::concurrent::SharedPointer > > >, std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::find(int const&)+0x45 > C [test+0x1104e7f] std::map ignite::common::concurrent::SharedPointer, > std::less, std::allocator ignite::common::concurrent::SharedPointer > > > >::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-5153) CPP: BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16010641#comment-16010641 ] Igor Sapego commented on IGNITE-5153: - On hold until issue above is resolved. > 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] [Commented] (IGNITE-5225) TcpCommunicationSpi.createTcpClient can cause OOME.
[ https://issues.apache.org/jira/browse/IGNITE-5225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ 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 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
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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.
[ 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 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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 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] [Created] (IGNITE-5224) .NET: PadLeft and PadRight support in LINQ
Pavel Tupitsyn created IGNITE-5224: -- Summary: .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 Fix For: 2.1 Add {{String.PadLeft}} and {{String.PadRight}} functions to LINQ, map them to SQL {{LPAD}} and {{RPAD}}. -- 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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 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 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 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.
[ 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
[ 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
[ 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.
[ 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 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 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 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
[ 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 > org.gridgain.grid.internal.processors.cache.database.GridCacheDatabaseSharedManager.initDataBase(GridCacheDa
[jira] [Created] (IGNITE-5215) Allow user to configure memory policy with maxSize lesser than default initialSize
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
[ https://issues.apache.org/jira/browse/IGNITE-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 Update configuration tests commit 6f3abd8271d15a86abcea871464f3fcaf4d1899a Author: Pavel Tupitsyn Date: 2017-01-13T08:14:41Z Cache assembly bytes in AssemblyLoader > .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 p
[jira] [Updated] (IGNITE-4052) Add ability to set up users for MESOS
[ 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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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 > org.apache.ignite.internal.processors.service.GridServiceProcessor$3.run(GridServiceProcessor
[jira] [Commented] (IGNITE-2492) .NET: Peer assembly loading
[ https://issues.apache.org/jira/browse/IGNITE-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 exc
[jira] [Created] (IGNITE-5213) .NET: Reflective serializer fails on custom dictionaries
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] [Created] (IGNITE-5214) ConcurrentModificationException with enable DEBUG log level
Nikolay Tikhonov created IGNITE-5214: Summary: 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 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$Worke
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Closed] (IGNITE-5086) Web Console: Redesign of Modal Windows
[ https://issues.apache.org/jira/browse/IGNITE-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-5086. -- Assignee: Alexey Kuznetsov (was: Andrey Novikov) > 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: Alexey Kuznetsov > Fix For: 2.1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5086) Web Console: Redesign of Modal Windows
[ 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.
[ 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] [Comment Edited] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized
[ https://issues.apache.org/jira/browse/IGNITE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16010107#comment-16010107 ] Pavel Tupitsyn edited comment on IGNITE-5207 at 5/15/17 7:42 AM: - [~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-{{int}} 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). was (Author: ptupitsyn): [~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] [Commented] (IGNITE-5207) .NET: Non-Int32 enums can't be serialized
[ https://issues.apache.org/jira/browse/IGNITE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)