[jira] [Updated] (IGNITE-6515) .NET: Enable persistence on per-cache basis
[ https://issues.apache.org/jira/browse/IGNITE-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6515: Labels: .NET important (was: .NET) > .NET: Enable persistence on per-cache basis > --- > > Key: IGNITE-6515 > URL: https://issues.apache.org/jira/browse/IGNITE-6515 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn > Labels: .NET, important > Fix For: 2.3 > > > Propagate new configuration to .NET: IGNITE-6030 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6019) SQL: client node should not hold the whole data set in-memory when possible
[
https://issues.apache.org/jira/browse/IGNITE-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6019:
Labels: important performance (was: performance)
> SQL: client node should not hold the whole data set in-memory when possible
> ---
>
> Key: IGNITE-6019
> URL: https://issues.apache.org/jira/browse/IGNITE-6019
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Critical
> Labels: important, performance
> Fix For: 2.3
>
>
> Our SQL engine requests request data from server nodes in pieces called
> "page". This allows us to control memory consumption on client side. However,
> currently our client code is designed in a way that all pages are requested
> from all servers before a single cursor row is returned to the user. It
> defeats the whole idea of "cursor" and "page", and could easily crash client
> node with OOME.
> We need to fix that and request further pages in a kind of sliding window,
> keeping no more than "N" pages in memory simultaneously. Note that sometimes
> it is not possible, e.g. in case of {{DISTINCT}} or non-collocated {{GROUP
> BY}}. In this case we would have to build the whole result set first anyway.
> So let's focus on a scenario when the whole result set is not needed.
> As currently everything is requested synchronously page-by-page, in the first
> version it would be enough to distribute synchronous page requests between
> cursor reads, without any prefetch.
> Implementation details:
> 1) Optimization should be applied only to {{skipMergeTbl=true}} cases, when
> complete result set of map queries is not needed.
> 2) Starting point is {{GridReduceQueryExecutor#query}}, see
> {{skipMergeTbl=true}} branch - this is where we get all pages eagerly.
> 3) Get no more than one page from the server at a time. We request the page,
> iterate over it, then request another page.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5572) DDL: Support ALTER TABLE ADD COLUMN
[
https://issues.apache.org/jira/browse/IGNITE-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5572:
Labels: important (was: )
> DDL: Support ALTER TABLE ADD COLUMN
> ---
>
> Key: IGNITE-5572
> URL: https://issues.apache.org/jira/browse/IGNITE-5572
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Labels: important
> Fix For: 2.3
>
>
> We should start gradual implementation of {{ALTER TABLE}} command. Let's
> start with the most simple part - {{ADD COLUMN}}. Proposed design:
> 1) Send a message over a ring, similar to how we do that for create index
> 2) On local node: update relevant QueryEntity, update data strcutrues in
> {{GridQueryProcessor}}, update {{IgniteH2Indexing}} data structures, execute
> {{ALTER TABLE}} command on H2 database (global table lock must be acquired).
> 3) Make sure that update to {{QueryEntity}} is properly saved if persistence
> is enabled.
> Feature should be covered with tests thoroughly:
> 1) Positive cases
> 2) Negative cases (no schema, no table, column already exists)
> 3) Test with concurrent SQL operations
> 4) Test with concurrent node restarts
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6305) Need to add update checker to Ignite
[ https://issues.apache.org/jira/browse/IGNITE-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6305: Labels: important (was: ) > Need to add update checker to Ignite > > > Key: IGNITE-6305 > URL: https://issues.apache.org/jira/browse/IGNITE-6305 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Dmitriy Setrakyan >Assignee: Andrey Gura >Priority: Critical > Labels: important > Fix For: 2.3 > > > # Ignite should provide an update check on node startup, which will report to > users if there is a new version available. > # We can also use the update-checker to count Ignite starts, which will allow > the community to monitor the health of the project. > The design is specified in this dev@ thread (make sure to read all the way to > the end): > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-Update-Checker-td21150.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5211) Classes based constructor for QueryEntities
[
https://issues.apache.org/jira/browse/IGNITE-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5211:
Labels: important (was: )
> Classes based constructor for QueryEntities
> ---
>
> Key: IGNITE-5211
> URL: https://issues.apache.org/jira/browse/IGNITE-5211
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Critical
> Labels: important, usability
> Fix For: 2.3
>
>
> We need to add constructor {{QueryEntity(Class keyType, Class valueType)}} to
> query entities class and deprecate {{CacheConfiguration.setIndexedTypes(…)}}
> method.
> Otherwise, there is no easy way for people who define SQL scheme with the
> annotations to do advanced settings like names of key and value objects,
> table name, etc.
> See this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/SQL-setting-key-field-name-for-types-registered-via-CacheConfiguration-setIndexedTypes-td17603.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6030) Allow enabling persistence per-cache
[
https://issues.apache.org/jira/browse/IGNITE-6030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6030:
Labels: important (was: )
> Allow enabling persistence per-cache
>
>
> Key: IGNITE-6030
> URL: https://issues.apache.org/jira/browse/IGNITE-6030
> Project: Ignite
> Issue Type: New Feature
> Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Critical
> Labels: important
> Fix For: 2.3
>
>
> Also, when cache native persistence is disabled, we need to make sure that
> different {{CacheStores}} can be configured on per-cache basis.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6242) Passing custom cache and type names to CREATE TABLE
[
https://issues.apache.org/jira/browse/IGNITE-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6242:
Labels: important usability (was: usability)
> Passing custom cache and type names to CREATE TABLE
> ---
>
> Key: IGNITE-6242
> URL: https://issues.apache.org/jira/browse/IGNITE-6242
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Labels: important, usability
> Fix For: 2.3
>
>
> Once CREATE TABLE is executed Ignite:
> * will create an IgniteCache naming it SQL_PUBLIC_\{TABLE\}. So, if a Person
> table is created you’ll have SQL_PUBLIC_PERSON cache in the cluster.
> * will use autogenerated names for the key and value types. For instance,
> this is how the type name might look like
> SQL_PUBLIC_CITY_3f4e9fbf_3464_4598_8394_1307b86dc4e7_KEY.
> The goal of the ticket is to give a way to pass a custom cache name, key's
> type name, value's type name into WITH clause.
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Key-value-access-to-caches-created-with-DDL-td21622.html
> http://apache-ignite-developers.2346864.n4.nabble.com/Override-cache-name-created-with-CREATE-TABLE-td21456.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6192) Ignite-ML does not compile
[
https://issues.apache.org/jira/browse/IGNITE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6192:
Labels: important ml (was: ml)
> Ignite-ML does not compile
> --
>
> Key: IGNITE-6192
> URL: https://issues.apache.org/jira/browse/IGNITE-6192
> Project: Ignite
> Issue Type: Bug
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>Priority: Critical
> Labels: important, ml
> Fix For: 2.3
>
>
> Ignite ML module does not compile with this error:
> [19:06:28]W: [Step 10/12] [ERROR]
> /data/teamcity/work/6256635eb5425b7f/incubator-ignite/modules/ml/src/main/java/org/apache/ignite/ml/math/Blas.java:[21,32]
> package com.github.fommil.netlib does not exist
> [19:06:28]W: [Step 10/12] [ERROR]
> /data/teamcity/work/6256635eb5425b7f/incubator-ignite/modules/ml/src/main/java/org/apache/ignite/ml/math/Blas.java:[44,30]
> cannot find symbol
> [19:06:28] : [Step 10/12] symbol: class BLAS
> I've checked modules/ml/pom.xml file and I think the reason is line:
> pom
> in this dependency:
>
> com.github.fommil.netlib
> core
> ${netlibjava.version}
> pom
>
> I've double-checked three times on two different machines, after removing the
> line module does compile.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5884) Change default pageSize of page memory to 4KB
[ https://issues.apache.org/jira/browse/IGNITE-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5884: Labels: important usability (was: usability) > Change default pageSize of page memory to 4KB > - > > Key: IGNITE-5884 > URL: https://issues.apache.org/jira/browse/IGNITE-5884 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Critical > Labels: important, usability > Fix For: 2.3 > > Attachments: CpBenchmark.java, iostat.log, ssdlab.log > > > Checkpoint write speed is suboptimal with default 2K page on most UNIX-driven > enviroments with SSD disk. There are several reasons for this: > 1) Page size of linux page cache is 4k by default on most kernels (you can > check yours by "getconf PAGE_SIZE" command). With 2k random writes > vm.dirty_ratio threshold is reached two times faster than with 4k random > writes. > 2) Most SSD manufacturers don't expose actual disk page size, but they > recommend to write at least 4k at once. Also, 4k blocks are used during > benchmarking SSD random writes. > Related question: > https://superuser.com/questions/1168014/nvme-ssd-why-is-4k-writing-faster-than-reading > Article by Emmanuel Goossaert describing why writing less than a page is > сounterproductive: > http://codecapsule.com/2014/02/12/coding-for-ssds-part-3-pages-blocks-and-the-flash-translation-layer/ > I've prepared a checkpoint emulation benchmark (code and results attached). > Run on production-level hardware (CentOS, 100 GB RAM, total LFS size is > 100GB, vm.dirty_ratio=10) showed that checkpointing with 4k pages is much > more efficient than with 2k. > *Important: backwards compatibility must be ensured with LFS files created > with old 2k default page size.* -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5211) Classes based constructor for QueryEntities
[
https://issues.apache.org/jira/browse/IGNITE-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5211:
Labels: important usability (was: important)
> Classes based constructor for QueryEntities
> ---
>
> Key: IGNITE-5211
> URL: https://issues.apache.org/jira/browse/IGNITE-5211
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Critical
> Labels: important, usability
> Fix For: 2.3
>
>
> We need to add constructor {{QueryEntity(Class keyType, Class valueType)}} to
> query entities class and deprecate {{CacheConfiguration.setIndexedTypes(…)}}
> method.
> Otherwise, there is no easy way for people who define SQL scheme with the
> annotations to do advanced settings like names of key and value objects,
> table name, etc.
> See this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/SQL-setting-key-field-name-for-types-registered-via-CacheConfiguration-setIndexedTypes-td17603.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5991) SQL: lazy ResultSet for map query
[
https://issues.apache.org/jira/browse/IGNITE-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5991:
Labels: important (was: )
> SQL: lazy ResultSet for map query
> -
>
> Key: IGNITE-5991
> URL: https://issues.apache.org/jira/browse/IGNITE-5991
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Labels: important
> Fix For: 2.3
>
>
> Currently we move the whole {{ResultSet}} to memory when executing SQL query
> on mapper. If result set is large enough, this could easily bring server down
> due to high GC pressure or even OOME.
> To avoid that we should stream H2's {{ResultSet}} to our own consumer, which
> will construct a page and send it to the client When a page is sent,
> consumer will block current thread until "next page request" is received.
> This approach has disadvantage - query thread will be blocked. However,
> implementation should be fairly easy and will allow us to avoid OOMEs on
> server. In future we will improve it to minimize blocking (or even avoid it
> completely).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6374) Web Console SQL doesn't work with 2.2.0 RC1
[
https://issues.apache.org/jira/browse/IGNITE-6374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6374:
Labels: important (was: )
> Web Console SQL doesn't work with 2.2.0 RC1
> ---
>
> Key: IGNITE-6374
> URL: https://issues.apache.org/jira/browse/IGNITE-6374
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Denis Magda
>Assignee: Alexey Kuznetsov
>Priority: Blocker
> Labels: important
> Fix For: 2.3
>
>
> Start a couple of nodes using 2.2.0-rc1 binary bundle:
> {code}
> ./ignite.sh ../examples/config/example-ignite.xml
> {code}
> Preload data using SQLLine tool and the SQL script as described here:
> https://github.com/dmagda/ignite_world_demo
> Go to Web Console SQL tab and send the simplest query possible:
> {code}
> select * from city
> {code}
> To get the exception like that:
> {code}
> [14:42:33,440][SEVERE][rest-#54%null%][GridTaskCommandHandler] Failed to
> execute task [name=o.a.i.i.v.compute.VisorGatewayTask, clientId=null]
> class org.apache.ignite.IgniteCheckedException: Failed to find constructor
> for task argument
> [taskName=org.apache.ignite.internal.visor.query.VisorQueryTask, argsCnt=8,
> args=[SQL_PUBLIC_CITY, select * from city, false, false, false, false, 100,
> false]]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7229)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:263)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:352)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:163)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:268)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:91)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:157)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 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)
> Caused by: class org.apache.ignite.IgniteException: Failed to find
> constructor for task argument
> [taskName=org.apache.ignite.internal.visor.query.VisorQueryTask, argsCnt=8,
> args=[SQL_PUBLIC_CITY, select * from city, false, false, false, false, 100,
> false]]
> at
> org.apache.ignite.internal.visor.compute.VisorGatewayTask$VisorGatewayJob.execute(VisorGatewayTask.java:400)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6608)
> 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:1115)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1385)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:640)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:532)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:749)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:505)
> at
[jira] [Updated] (IGNITE-5817) Change checksum calculation methods
[ https://issues.apache.org/jira/browse/IGNITE-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5817: Labels: important (was: ) > Change checksum calculation methods > --- > > Key: IGNITE-5817 > URL: https://issues.apache.org/jira/browse/IGNITE-5817 > Project: Ignite > Issue Type: Task >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin >Priority: Blocker > Labels: important > Fix For: 2.2, 2.3 > > > Neither sha1 nor md5 are trustful checksum calculation methods. We should be > switching to at least sha265 or higher. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6507) Commit can be lost in network split scenario
[
https://issues.apache.org/jira/browse/IGNITE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6507:
Labels: important (was: )
> Commit can be lost in network split scenario
>
>
> Key: IGNITE-6507
> URL: https://issues.apache.org/jira/browse/IGNITE-6507
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
>Priority: Critical
> Labels: important
> Fix For: 2.3
>
>
> Commit can be lost in network split scenario
> {noformat}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.ignite.internal.processors.cache.distributed.dht;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
> import org.apache.ignite.configuration.BinaryConfiguration;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.MemoryConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.IgniteInternalFuture;
> import org.apache.ignite.internal.TestRecordingCommunicationSpi;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
> /**
> * Tests commit consitency in split-brain scenario.
> */
> public class GridCacheGridSplitTxConsistencyTest extends
> GridCommonAbstractTest {
> /** */
> private static final TcpDiscoveryIpFinder IP_FINDER = new
> TcpDiscoveryVmIpFinder(true);
> /**
> * {@inheritDoc}
> */
> @Override protected void afterTest() throws Exception {
> super.afterTest();
> stopAllGrids();
> GridTestUtils.deleteDbFiles();
> }
> /**
> * {@inheritDoc}
> */
> @Override protected IgniteConfiguration getConfiguration(String gridName)
> throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(gridName);
> cfg.setCommunicationSpi(new TestRecordingCommunicationSpi());
> cfg.setConsistentId(gridName);
> MemoryConfiguration memCfg = new MemoryConfiguration();
> memCfg.setPageSize(1024);
> memCfg.setDefaultMemoryPolicySize(100 * 1024 * 1024);
> cfg.setMemoryConfiguration(memCfg);
> ((TcpDiscoverySpi) cfg.getDiscoverySpi()).setIpFinder(IP_FINDER);
> CacheConfiguration ccfg = new CacheConfiguration();
> ccfg.setName(DEFAULT_CACHE_NAME);
> ccfg.setAtomicityMode(TRANSACTIONAL);
> ccfg.setWriteSynchronizationMode(FULL_SYNC);
> ccfg.setAffinity(new RendezvousAffinityFunction(false, 3));
> ccfg.setBackups(2);
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> /**
> * Tests if commits are working as expected.
> * @throws Exception
> */
> public void testSplitTxConsistency() throws Exception {
> IgniteEx grid0 = startGrid(0);
> grid0.active(true);
> IgniteEx grid1 = startGrid(1);
> IgniteEx grid2 = startGrid(2);
> int key = 0;
> Affinity aff = grid0.affinity(DEFAULT_CACHE_NAME);
> assertTrue(aff.isPrimary(grid0.localNode(), key));
> assertTrue(aff.isBackup(grid1.localNode(), key));
> assertTrue(aff.isBackup(grid2.localNode(), key));
> final TestRecordingCommunicationSpi spi0 =
> (TestRecordingCommunicationSpi) grid0.configuration().getCommunicationSpi();
> spi0.blockMessages(GridDhtTxFinishRequest.class, grid1.nam
[jira] [Updated] (IGNITE-6193) ML profile is missing in 2.1 binary release
[ https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6193: Labels: important ml (was: ml) > ML profile is missing in 2.1 binary release > --- > > Key: IGNITE-6193 > URL: https://issues.apache.org/jira/browse/IGNITE-6193 > Project: Ignite > Issue Type: Bug > Components: examples, ml >Reporter: Denis Magda >Assignee: Oleg Ignatenko >Priority: Blocker > Labels: important, ml > Fix For: 2.3 > > > In Apache Ignite 2.0 we added the ML profile to the binary release that > allowed activating this functionality and running the examples easily. The > getting started is written based on the profile presence: > https://apacheignite.readme.io/docs/machine-learning#section-getting-started > The profile is missing for 2.1 release. To reproduce the issue just download > 2.1 binary release and follow the getting started section, you'll stumble on > step 4: > https://apacheignite.readme.io/docs/machine-learning#section-getting-started > This has to be fixed as soon as possible and the fix should be merged both in > the master and in a branch of the urgent Ignite release that is discussed > here: > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6282) C++: impossible to start node with persistent store
[
https://issues.apache.org/jira/browse/IGNITE-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6282:
Labels: C++ important (was: C++)
> C++: impossible to start node with persistent store
> ---
>
> Key: IGNITE-6282
> URL: https://issues.apache.org/jira/browse/IGNITE-6282
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.2
>Reporter: Irina Zaporozhtseva
>Assignee: Igor Sapego
>Priority: Blocker
> Labels: C++, important
> Fix For: 2.3
>
>
> C++: impossible to start node with persistent store.
> Add to config:
> {code}
>
>class="org.apache.ignite.configuration.PersistentStoreConfiguration"/>
>
> {code}
> After node started, error message appears:
> {code}
> [17:42:39] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8,
> heap=0.89GB]
> ERROR: Can not perform the operation because the cluster is inactive. Note,
> that the cluster is considered inactive by default if Ignite Persistent Store
> is used to let all the nodes join the cluster. To activate the cluster call
> Ignite.activate(true).
> {code}
> and after that node is stopped
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6285) Enhance persistent store paths logging on start
[ https://issues.apache.org/jira/browse/IGNITE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6285: Labels: documentation important usability (was: documentation usability) > Enhance persistent store paths logging on start > --- > > Key: IGNITE-6285 > URL: https://issues.apache.org/jira/browse/IGNITE-6285 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Yakov Zhdanov >Assignee: Dmitriy Pavlov >Priority: Blocker > Labels: documentation, important, usability > Fix For: 2.3 > > > As per this thread - > http://apache-ignite-users.70518.x6.nabble.com/Specifying-location-of-persistent-storage-location-td16636i20.html > Ignite may switch storage path in case of changing DHCP lease or similar > which can lead to consistent ID change. > In order to help user in spotting the issue Ignite may output the following > to the logs: > # Output the store path and tell its (1) size or state that it is empty and > (2) last data file modification date. > # Output warning if there are other non-empty storage folders under work > directory with their sizes and dates. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6375) CREATE TABLE affinityKey parameter doesn't work as expected
[
https://issues.apache.org/jira/browse/IGNITE-6375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16183751#comment-16183751
]
Vladimir Ozerov commented on IGNITE-6375:
-
New test run:
https://ci.ignite.apache.org/viewQueued.html?itemId=858531&tab=queuedBuildOverviewTab
> CREATE TABLE affinityKey parameter doesn't work as expected
> ---
>
> Key: IGNITE-6375
> URL: https://issues.apache.org/jira/browse/IGNITE-6375
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 2.3
>
>
> Start a couple of cluster nodes and preload the data using SQLLine tool and
> an SQL script as described here:
> https://github.com/dmagda/ignite_world_demo
> The SQL tables are couple by affinity principle, check the script. However,
> when I try to execute this query with a JOIN
> {code}
> SELECT country.name, city.name, MAX(city.population) as max_pop FROM country
> JOIN city ON city.countrycode = country.code
> WHERE country.code IN ('USA','RUS','CHN')
> GROUP BY country.name, city.name ORDER BY max_pop DESC LIMIT 3
> {code}
> then get a wrong result
> {noformat}
> United States New York 8008278
> United States Los Angeles 3694820
> United States Chicago 2896016
> {noformat}
> The correct result is the following:
> {noformat}
> China Shanghai 9696300
> Russian Federation Moscow 8389200
> United States New York 8008278
> {noformat}
> But you have to force {{non-collocated}} joins to get it.
> All this means that {{affinityKey}} parameter of CREATE TABLE doesn't work
> properly or there is an issue with DML.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set
[
https://issues.apache.org/jira/browse/IGNITE-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
vk reassigned IGNITE-6502:
--
Assignee: vk
> Need to output warning if -Djava.net.preferIPv4Stack=true is not set
>
>
> Key: IGNITE-6502
> URL: https://issues.apache.org/jira/browse/IGNITE-6502
> Project: Ignite
> Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: vk
> Labels: usability
> Fix For: 2.3
>
>
> Some issues were reported on dev/user list that may be caused by ipv6 usage.
> I am not sure if Ignite can properly work with ipv6 networks. This needs to
> be tested.
> For now it seems to be pretty handy just to have warning on node start:
> {{noformat}}
> Please set system property '-Djava.net.preferIPv4Stack=true' to avoid
> possible problems in mixed environments.
> {{noformat}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5813) Inconsistent cache store state when originating node fails on commit.
[ https://issues.apache.org/jira/browse/IGNITE-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5813: Fix Version/s: (was: 2.3) > Inconsistent cache store state when originating node fails on commit. > - > > Key: IGNITE-5813 > URL: https://issues.apache.org/jira/browse/IGNITE-5813 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov > Attachments: IgniteTxRecoveryAfterStoreCommitSelfTest.java > > > Same tx can be rolled back by cache and commited by CacheStore. > It is possible when originating tx node commit tx successfully, but fails to > notify other nodes. > PFA reproducer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6163) Upgrade to Spark 2.2.0
[
https://issues.apache.org/jira/browse/IGNITE-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6163:
Fix Version/s: (was: 2.3)
> Upgrade to Spark 2.2.0
> --
>
> Key: IGNITE-6163
> URL: https://issues.apache.org/jira/browse/IGNITE-6163
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Magda
>Priority: Blocker
> Labels: usability
>
> Apache Ignite's Spark integration module has to be updated to Spark 2.2.0 to
> avoid issues like this:
> https://github.com/dmagda/IgniteSparkIoT/issues/1
> In short, Spark 2.1.0 and Spark 2.2.0 modules can't be mixed together,
> otherwise, the exceptions like this will pop up:
> {code}
> Exception in thread "main" java.lang.NoSuchMethodError:
> org.apache.spark.ui.SparkUI.setStreamingJobProgressListener(Lorg/apache/spark/scheduler/SparkListener;)V
> at
> org.apache.spark.streaming.ui.StreamingTab.(StreamingTab.scala:41)
> at
> org.apache.spark.streaming.StreamingContext.(StreamingContext.scala:192)
> at
> org.apache.spark.streaming.StreamingContext.(StreamingContext.scala:85)
> at
> org.apache.spark.streaming.api.java.JavaStreamingContext.(JavaStreamingContext.scala:138)
> at
> org.apache.ignite.iot.SparkStreamerStartup.main(SparkStreamerStartup.java:71)
> 17/08/22 18:27:25 INFO SparkContext: Invoking stop() from shutdown hook
> 17/08/22 18:27:25 INFO SparkUI: Stopped Spark web UI at http://10.0.1.6:4040
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-4890) Unable to create tables automatically because 'unconfigured columnfamily' error is not handled for older Cassandra versions
[
https://issues.apache.org/jira/browse/IGNITE-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4890:
Fix Version/s: (was: 2.3)
> Unable to create tables automatically because 'unconfigured columnfamily'
> error is not handled for older Cassandra versions
> ---
>
> Key: IGNITE-4890
> URL: https://issues.apache.org/jira/browse/IGNITE-4890
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Venky Kandaswamy
> Labels: patch
>
> PROBLEM:
> When running Ignite with older Cassandra versions (i.e DSE 4.8.10, Cassandra
> 2.1.6 or older), we noticed that only the first tabel in an Ignite config is
> created and the others fail with 'unconfigured columnfamily' exception.
> SUGGESTED FIX:
> It appears that the error from Cassandra is changed in newer versions to
> 'unconfigured table ...' and this is handled. The conditions checked in
> org.apache.ignite.cache.store.cassandra.common.CassandraHelper needs to be
> modified to handle the older Cassandra errors.
> We are submitting a patch to do that.
> 13:44:28,753 ERROR com.walmartlabs.qarth.ignite.tests.utils.CacheStoreHelper
> [main] - Failed to execute Cassandra CQL statement: insert into
> "test1"."blob_test2" ("key", "value") values (?,?);
> class org.apache.ignite.IgniteException: Failed to execute Cassandra CQL
> statement: insert into "test1"."blob_test2" ("key", "value") values (?,?);
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:163)
> at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore.write(CassandraCacheStore.java:276)
> at
> com.walmartlabs.qarth.ignite.tests.cassandra.CassandraDirectPersistenceTest.blobStrategyTest(CassandraDirectPersistenceTest.java:233)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: class org.apache.ignite.IgniteException: Failed to prepare
> Cassandra CQL statement: insert into "test1"."blob_test2" ("key", "value")
> values (?,?);
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.prepareStatement(CassandraSessionImpl.java:615)
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:133)
> ... 27 more
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException:
> unconfigured columnfamily blob_test2
> at
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
> at
> com.da
[jira] [Updated] (IGNITE-2377) Docker image hangs on Mac OS
[
https://issues.apache.org/jira/browse/IGNITE-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2377:
Fix Version/s: (was: 2.3)
> Docker image hangs on Mac OS
>
>
> Key: IGNITE-2377
> URL: https://issues.apache.org/jira/browse/IGNITE-2377
> Project: Ignite
> Issue Type: Wish
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Chandresh Pancholi
> Labels: newbie
>
> Docker hangs at the point when {{CommandLineRandomNumberGenerator}} is being
> executed. The reason is that the current and previous Docker version has some
> bug that can be overcame if to put {{System.exit(0)}} at the end of
> {{main(...)}} function.
> More investigation details and steps to reproduce can be found here:
> http://stackoverflow.com/questions/34661934/ignite-running-in-docker-is-general-java-docker-issue
> It makes sense to add {{System.exit(0)}} to all our classes that are executed
> by {{ignite.bat}} or {{ignite.sh}} because it's not harmful in any case.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5496) Externalizable classes get registered twice
[ https://issues.apache.org/jira/browse/IGNITE-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5496: Fix Version/s: (was: 2.3) > Externalizable classes get registered twice > --- > > Key: IGNITE-5496 > URL: https://issues.apache.org/jira/browse/IGNITE-5496 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Amelchev Nikita > Labels: important > > I observed a strange behavior on ignite-1.7. If I have an externalizable > class inside of a serializable class and BinaryMarshaller is used, the > externalizable class gets registered twice with different typeIds. > Looks like this happens because in BinaryWriterExImpl#marshal0 we first call > ctx.descriptorForClass(cls, false) which will calculate and register type > with one typeId. Then we figure out that the class is externalizable and > switch to optimized marshaller (U.marshal(ctx.optimizedMarsh(), obj)) which > will register another type ID. > Need to check if this is still reproducible in 2.1-2.2 as it may be a > performance issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6503) Need to test Ignite in IPv6 environment
[ https://issues.apache.org/jira/browse/IGNITE-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6503: Fix Version/s: (was: 2.3) > Need to test Ignite in IPv6 environment > --- > > Key: IGNITE-6503 > URL: https://issues.apache.org/jira/browse/IGNITE-6503 > Project: Ignite > Issue Type: Improvement >Reporter: Yakov Zhdanov >Priority: Minor > Labels: usability > > It seems that Ignite may have problems with IPv6. Need to test it and fix if > necessary. > Areas to check: > # build cluster on local node with different IP finders on different OSes. > # build distributed cluster with different IP finders on different OSes. > # check communication by running some yardstick benchmark (e.g. atomic put). > 1 client vs 2-3 servers will be fine. > # kill some node while benchmark is running > # add new node while benchmark is running > http://apache-ignite-developers.2346864.n4.nabble.com/Issues-if-Djava-net-preferIPv4Stack-true-is-not-set-td22372.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-1948) ClusterTopologyCheckedException can return null for retryReadyFuture()
[
https://issues.apache.org/jira/browse/IGNITE-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-1948:
Fix Version/s: (was: 2.3)
> ClusterTopologyCheckedException can return null for retryReadyFuture()
> --
>
> Key: IGNITE-1948
> URL: https://issues.apache.org/jira/browse/IGNITE-1948
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Denis Magda
>Assignee: Alexander Menshikov
>
> It was noted that {{ClusterTopologyCheckedException}} ready future can be
> null.
> Go though all the places where this kind of exception is being initialized
> and check why the ready future is not set in some cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-4448) Implement correct affinity validation on joining topology.
[
https://issues.apache.org/jira/browse/IGNITE-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4448:
Fix Version/s: (was: 2.3)
> Implement correct affinity validation on joining topology.
> --
>
> Key: IGNITE-4448
> URL: https://issues.apache.org/jira/browse/IGNITE-4448
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>
> Currently on joining a topology only affinity class name and partition number
> are checked between configurations of local and remote nodes.
> This is not enough in case of configured backup filter and possible extension
> with primary filter and can lead to disastrous situations due to node
> misconfiguration.
> We should implement something like {{AffinityValidator}} having signature as
> follows:
> {noformat}
> boolean validate(Affinity affinity)
> {noformat}
> Maybe it'll be useful for other grid objects as well, like
> {{CacheStore}},{{NodeFilter}}, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6506) Cluster activation hangs if a node was stopped during persistent storage checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6506:
Fix Version/s: 2.3
> Cluster activation hangs if a node was stopped during persistent storage
> checkpoint
> ---
>
> Key: IGNITE-6506
> URL: https://issues.apache.org/jira/browse/IGNITE-6506
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.2
>Reporter: Joel Lang
>Priority: Critical
> Fix For: 2.3
>
>
> I have a cluster with two nodes: A and B.
> On startup, node A and B wait for each other to be connected and then node A
> will attempt to activate the cluster.
> While testing high availability we find that if a node is stopped during the
> persistent store checkpoint, we cannot activate the cluster on startup
> without deleting the persistent storage directory. Specifically in the case
> where node A is stopped during checkpointing, upon the next startup it will
> encounter several exceptions during activation and then hang without
> completing activation.
> Here is the log.
> {noformat}
> 2017-09-26 12:11:24 [tcp-disco-msg-worker-#2%mbe%] INFO
> o.a.i.i.p.c.GridClusterStateProcessor - Start state transition: true
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO
> o.a.ignite.internal.exchange.time - Started exchange init
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], crd=true, evt=18,
> node=TcpDiscoveryNode [id=62cf0ccb-e376-4b80-8d2d-98115c3a2990,
> addrs=[10.5.17.19, 127.0.0.1],
> sockAddrs=[shouvdevmbe02.petrolink.net/10.5.17.19:47510, /127.0.0.1:47510],
> discPort=47510, order=1, intOrder=1, lastExchangeTime=1506445884063,
> loc=true, ver=2.2.0#20170915-sha1:5747ce6b, isClient=false],
> evtNode=TcpDiscoveryNode [id=62cf0ccb-e376-4b80-8d2d-98115c3a2990,
> addrs=[10.5.17.19, 127.0.0.1],
> sockAddrs=[shouvdevmbe02.petrolink.net/10.5.17.19:47510, /127.0.0.1:47510],
> discPort=47510, order=1, intOrder=1, lastExchangeTime=1506445884063,
> loc=true, ver=2.2.0#20170915-sha1:5747ce6b, isClient=false],
> customEvt=ChangeGlobalStateMessage
> [id=1d0cb2fbe51-7967bd11-40aa-40fe-b0a6-c43302cd4ee7,
> reqId=f7155dea-fede-4340-b244-7a3b65f167a8,
> initiatingNodeId=62cf0ccb-e376-4b80-8d2d-98115c3a2990, activate=true]]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO
> o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture - Start activation process
> [nodeId=62cf0ccb-e376-4b80-8d2d-98115c3a2990, client=false,
> topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1]]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO
> o.a.i.i.p.c.p.f.FilePageStoreManager - Resolved page store work directory:
> /opt/mbe1/ignite/db/mbe_MBE1
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO
> o.a.i.i.p.c.p.w.FileWriteAheadLogManager - Resolved write ahead log work
> directory: /opt/mbe1/ignite/db/wal/mbe_MBE1
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO
> o.a.i.i.p.c.p.w.FileWriteAheadLogManager - Resolved write ahead log archive
> directory: /opt/mbe1/ignite/db/wal/archive/mbe_MBE1
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] WARN
> o.a.i.i.p.c.p.GridCacheDatabaseSharedManager - No user-defined default
> MemoryPolicy found; system default of 1GB size will be used.
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO
> o.a.i.i.p.c.p.pagemem.PageMemoryImpl - Started page memory
> [memoryAllocated=100.0 MiB, pages=48592, tableSize=2.9 MiB,
> checkpointBuffer=819.4 MiB]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO
> o.a.i.i.p.c.p.pagemem.PageMemoryImpl - Started page memory
> [memoryAllocated=3.1 GiB, pages=1544064, tableSize=91.0 MiB,
> checkpointBuffer=819.4 MiB]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO
> o.a.i.i.p.c.p.GridCacheDatabaseSharedManager - Read checkpoint status: start
> marker =
> /opt/mbe1/ignite/db/mbe_MBE1/cp/1506444061104-38b80aaa-8c3d-4572-a42e-5b7a3b472505-START.bin,
> end marker =
> /opt/mbe1/ignite/db/mbe_MBE1/cp/1506442980839-ff65a0dc-3d83-436a-8329-7b3a31fe5ffc-END.bin
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO
> o.a.i.i.p.c.p.GridCacheDatabaseSharedManager - Checking memory state
> [lastValidPos=FileWALPointer [idx=139, fileOffset=31406805, len=20731,
> forceFlush=false], lastMarked=FileWALPointer [idx=0, fileOffset=0, len=0,
> forceFlush=false], lastCheckpointId=38b80aaa-8c3d-4572-a42e-5b7a3b472505]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] WARN
> o.a.i.i.p.c.p.GridCacheDatabaseSharedManager - Ignite node stopped in the
> middle of checkpoint. Will restore memory state and finish checkpoint on node
> start.
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] ERROR
> o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture - Failed to activate node
> components [n
[jira] [Updated] (IGNITE-2421) EventTypes are badly documented
[
https://issues.apache.org/jira/browse/IGNITE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2421:
Fix Version/s: (was: 2.3)
> EventTypes are badly documented
> ---
>
> Key: IGNITE-2421
> URL: https://issues.apache.org/jira/browse/IGNITE-2421
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>
> We have to go through all the {{EventTypes}} and document them well:
> - in which conditions they are fired;
> - what kind of nodes (primary, backups or both) will receive and update;
> - etc.
> As an example.
> From {{EVT_CACHE_ENTRY_CREATED}} is not clear when it's fired at all. However
> it's fired when an entry is loaded from a storage, or when it's initially
> created due to a cache put.
> The same situation is around {{EVT_CACHE_OBJECT_PUT}}. There is no info
> saying that it's fired on both primary and backup nodes. That it's not fired
> due to a loading from a cache, etc.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-435) Visor should use smart format for time values
[
https://issues.apache.org/jira/browse/IGNITE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-435:
---
Fix Version/s: (was: 2.3)
> Visor should use smart format for time values
> -
>
> Key: IGNITE-435
> URL: https://issues.apache.org/jira/browse/IGNITE-435
> Project: Ignite
> Issue Type: Bug
>Affects Versions: sprint-2
>Reporter: Pavel Konstantinov
>Assignee: YoungGyu Chun
>Priority: Minor
> Labels: visor
>
> {code}
> Maximum job execute time| 60009ms - should show 1m
> Curent job execute time | 120ms
> Average job execute time| 1126.57ms - should show 1s
> Total busy time | 70769ms - should show 1m 10s
> {code}
> Also please fix the typo 'Curent' - should be 'Current'
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6518) Smarter analysis of INSERT and MERGE statements at parsing stage
[ https://issues.apache.org/jira/browse/IGNITE-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6518: Fix Version/s: (was: 2.3) > Smarter analysis of INSERT and MERGE statements at parsing stage > > > Key: IGNITE-6518 > URL: https://issues.apache.org/jira/browse/IGNITE-6518 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Paschenko > > We could analyze INSERT and MERGE statements to detect that they don't > specify data for key and/or value to notify users early that their query > can't be executed within Ignite - prior to building plans and attempting to > actually do anything. > (Note how we check that CREATE TABLE doesn't declare columns for key - logic > here would be similar.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5580) Improve node failure cause information
[ https://issues.apache.org/jira/browse/IGNITE-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5580: Fix Version/s: (was: 2.3) > Improve node failure cause information > -- > > Key: IGNITE-5580 > URL: https://issues.apache.org/jira/browse/IGNITE-5580 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Vadim Opolski > Labels: observability > > When a node fails, we do not print out any information about the root cause > of this failure. This makes it extremely hard to investigate the failure > causes - I need to find a previous node for the failed node and check the > logs on the previous node. > I suggest that we add extensive information about the reason of the node > failure and the sequence of events that led to this, e.g.: > [time] [NODE] Sending a message to next node - failed _because_ - write > timeout, read timeout, ...? > [time] [NODE] Connection check - failed - why? Connection refused, handshake > timed out, ...? > ... > [time] [NODE] Decided to drop the node because of the sequence above > Maybe we do not need to print out this information always, but we do need > this when troubleshooting logger is enabled. > Also, DiscoverySpi should collect a set of latest important events and dump > these events in case of local node segmentation. This will allow users to > match the events in the cluster and events on local node and get to the > bottom of the failure. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5561) Warn about long-running cache store operations
[ https://issues.apache.org/jira/browse/IGNITE-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5561: Fix Version/s: (was: 2.3) > Warn about long-running cache store operations > -- > > Key: IGNITE-5561 > URL: https://issues.apache.org/jira/browse/IGNITE-5561 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Vadim Opolski > Labels: observability > > When a cache store is used, it may become very confusing if a cache store > performs a very long-running operation, because in this case, Ignite would > output a warning about long-running cache operations. I think, in addition to > that, we should measure and output a warning if a specific cache store > operation took too long. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException
[ https://issues.apache.org/jira/browse/IGNITE-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5823: Fix Version/s: (was: 2.3) > Need to remove CacheAtomicUpdateTimeoutException > > > Key: IGNITE-5823 > URL: https://issues.apache.org/jira/browse/IGNITE-5823 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Sergey Dorozhkin >Priority: Minor > Labels: newbie > > And releated - CacheAtomicUpdateTimeoutCheckedException > These exceptions are not used any more and can be removed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2313:
Fix Version/s: (was: 2.3)
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6361) Add Meta descriptions on Ignite website pages
[ https://issues.apache.org/jira/browse/IGNITE-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6361: Fix Version/s: 2.3 > Add Meta descriptions on Ignite website pages > - > > Key: IGNITE-6361 > URL: https://issues.apache.org/jira/browse/IGNITE-6361 > Project: Ignite > Issue Type: Task >Reporter: Prachi Garg >Assignee: Prachi Garg > > Determine which pages need meta descriptions and create them. Meta > descriptions should be unique and created to draw users in from the SERPs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6361) Add Meta descriptions on Ignite website pages
[ https://issues.apache.org/jira/browse/IGNITE-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6361: Fix Version/s: (was: 2.3) > Add Meta descriptions on Ignite website pages > - > > Key: IGNITE-6361 > URL: https://issues.apache.org/jira/browse/IGNITE-6361 > Project: Ignite > Issue Type: Task >Reporter: Prachi Garg >Assignee: Prachi Garg > > Determine which pages need meta descriptions and create them. Meta > descriptions should be unique and created to draw users in from the SERPs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6361) Add Meta descriptions on Ignite website pages
[ https://issues.apache.org/jira/browse/IGNITE-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6361: Fix Version/s: (was: 2.3) > Add Meta descriptions on Ignite website pages > - > > Key: IGNITE-6361 > URL: https://issues.apache.org/jira/browse/IGNITE-6361 > Project: Ignite > Issue Type: Task >Reporter: Prachi Garg >Assignee: Prachi Garg > > Determine which pages need meta descriptions and create them. Meta > descriptions should be unique and created to draw users in from the SERPs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6518) Smarter analysis of INSERT and MERGE statements at parsing stage
Alexander Paschenko created IGNITE-6518: --- Summary: Smarter analysis of INSERT and MERGE statements at parsing stage Key: IGNITE-6518 URL: https://issues.apache.org/jira/browse/IGNITE-6518 Project: Ignite Issue Type: Improvement Components: sql Reporter: Alexander Paschenko Fix For: 2.3 We could analyze INSERT and MERGE statements to detect that they don't specify data for key and/or value to notify users early that their query can't be executed within Ignite - prior to building plans and attempting to actually do anything. (Note how we check that CREATE TABLE doesn't declare columns for key - logic here would be similar.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4358) Better error reporting in case of unmarshallable classes.
[ https://issues.apache.org/jira/browse/IGNITE-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4358: Fix Version/s: (was: 2.3) > Better error reporting in case of unmarshallable classes. > - > > Key: IGNITE-4358 > URL: https://issues.apache.org/jira/browse/IGNITE-4358 > Project: Ignite > Issue Type: Improvement > Components: compute, messaging >Affects Versions: 1.6 >Reporter: Alexei Scherbakov >Assignee: Rohit Mohta >Priority: Trivial > Labels: newbie > Attachments: IGNITE-4358-Exceptionlog-05Dec2016.txt, > IGNITE-4358-GridClosureProcessor-05Dec2016.patch, PureIgniteRunTest.java > > > When trying to execute Thread's derived class implementing IgniteRunnable > using compute API, it silently serializes to null because Thread > serialization is prohibited in MarshallerExclusions and throws NPE on > executing node. > We need to throw more informative exception for such case. > Reproducer in the attachment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6042) Update KafkaStreamer dependencies to Kafka 0.11.x
[ https://issues.apache.org/jira/browse/IGNITE-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6042: Fix Version/s: (was: 2.3) > Update KafkaStreamer dependencies to Kafka 0.11.x > - > > Key: IGNITE-6042 > URL: https://issues.apache.org/jira/browse/IGNITE-6042 > Project: Ignite > Issue Type: Task > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
[ https://issues.apache.org/jira/browse/IGNITE-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3878: Fix Version/s: (was: 2.3) > Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent > -- > > Key: IGNITE-3878 > URL: https://issues.apache.org/jira/browse/IGNITE-3878 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.7 >Reporter: Nikolay Tikhonov >Assignee: Maksim Kozlov >Priority: Minor > > In some cases useful know where (on primary or backup nodes) was invoked a > continuous query filter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5037) Fix broken @AffinityKeyMapped annotation for compute jobs.
[ https://issues.apache.org/jira/browse/IGNITE-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5037: Fix Version/s: (was: 2.3) > Fix broken @AffinityKeyMapped annotation for compute jobs. > -- > > Key: IGNITE-5037 > URL: https://issues.apache.org/jira/browse/IGNITE-5037 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Alexei Scherbakov >Assignee: Maksim Kozlov > Labels: newbie > > See related discussion on dev list entitled Proper collocation of > computations and data > (http://apache-ignite-developers.2346864.n4.nabble.com/Proper-collocation-of-computations-and-data-td16945.html). > We must repair data affinity routing for compute jobs. It should work same as > for affinityCall/Run with partition. > Currently, ComputeTask map method returns Map ClusterNode>, > but we have to provide some API allows to map ComputeJobs to partitions or > keys. > This can be done using AffinityKeyMapped annotation or any other way. > Since that's a publiс API any fixes should be discussed on dev list prior to > implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4910) Add copyOnRead property for near cache.
[
https://issues.apache.org/jira/browse/IGNITE-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4910:
Fix Version/s: (was: 2.3)
> Add copyOnRead property for near cache.
> ---
>
> Key: IGNITE-4910
> URL: https://issues.apache.org/jira/browse/IGNITE-4910
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.1
>Reporter: Maksim Kozlov
>Assignee: Maksim Kozlov
>
> Add {{setCopyOnRead}} to {{NearCacheConfiguration}} class.
> Continuation of the task from the ticket
> [https://issues.apache.org/jira/browse/IGNITE-2558].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5046) TcpDiscoverySpi.toString() method miss some fields.
[ https://issues.apache.org/jira/browse/IGNITE-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5046: Fix Version/s: (was: 2.3) > TcpDiscoverySpi.toString() method miss some fields. > --- > > Key: IGNITE-5046 > URL: https://issues.apache.org/jira/browse/IGNITE-5046 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.9 >Reporter: Andrew Mashenkov >Assignee: neeraj >Priority: Minor > Labels: newbie > > We have a number of protected fields that is missed by toString method. > Looks like we should annotate these fields with @GridToStringInclude. > locAddr, locPort, locPortRange, netTimeout and others. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5227) StackOverflowError in GridCacheMapEntry#checkOwnerChanged()
[
https://issues.apache.org/jira/browse/IGNITE-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5227:
Fix Version/s: (was: 2.3)
> 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: Mikhail Cherkasov
>Priority: Critical
>
> A simple test reproducing this error:
> {code}
> /**
> * @throws Exception if failed.
> */
> public void testBatchUnlock() throws Exception {
>startGrid(0);
>grid(0).createCache(new CacheConfiguration Integer>(DEFAULT_CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> 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.4.14#64029)
[jira] [Updated] (IGNITE-5947) ClassCastException when two-dimensional array is fetched from cache
[
https://issues.apache.org/jira/browse/IGNITE-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5947:
Fix Version/s: (was: 2.3)
> ClassCastException when two-dimensional array is fetched from cache
> ---
>
> Key: IGNITE-5947
> URL: https://issues.apache.org/jira/browse/IGNITE-5947
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Nikolay Tikhonov
>Priority: Critical
> Attachments: TestMain.java
>
>
> When an instance of {{Object[][]}} is put into cache, and then read from
> there, the following exception is thrown:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object;
> cannot be cast to [[Ljava.lang.Object;
> {noformat}
> Reproducer attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5833) Change maven goal from "install" to "package" for building from sour
[ https://issues.apache.org/jira/browse/IGNITE-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5833: Fix Version/s: (was: 2.3) > Change maven goal from "install" to "package" for building from sour > > > Key: IGNITE-5833 > URL: https://issues.apache.org/jira/browse/IGNITE-5833 > Project: Ignite > Issue Type: Bug >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin > > Currently we need to run 'mvn clean install' to build Apache Ignite from > sources, otherwise we can not perform javadoc generation in the next build > step in DEVNOTES.txt. We need to fix this issue before next release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5270) Cassandra store should support binary objects with POJO strategy
[ https://issues.apache.org/jira/browse/IGNITE-5270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5270: Fix Version/s: (was: 2.3) > Cassandra store should support binary objects with POJO strategy > > > Key: IGNITE-5270 > URL: https://issues.apache.org/jira/browse/IGNITE-5270 > Project: Ignite > Issue Type: Improvement > Components: cassandra >Affects Versions: 2.0 >Reporter: Valentin Kulichenko >Assignee: Igor Rudyak > > Currently Cassandra store requires to have POJO classes on server nodes when > POJO strategy is used. We should improve it and allow to support binary > objects directly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4645: Fix Version/s: (was: 2.3) > Best effort to avoid extra copying in binary marshaller > --- > > Key: IGNITE-4645 > URL: https://issues.apache.org/jira/browse/IGNITE-4645 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Yakov Zhdanov >Assignee: Igor Seliverstov > > If we marshal a class that contain only primitives then we can predict the > final byte array size and avoid copies to grow array and final trimming. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-6212) Assertion error: Invalid node2part
[ https://issues.apache.org/jira/browse/IGNITE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-6212. --- > Assertion error: Invalid node2part > -- > > Key: IGNITE-6212 > URL: https://issues.apache.org/jira/browse/IGNITE-6212 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.3 > > > Reproduced by IgniteServiceDynamicCachesSelfTest with ~10% probability. Leads > to hang-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-3610) Implements RAMP transactions on top of Cassandra
[ https://issues.apache.org/jira/browse/IGNITE-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3610: Fix Version/s: (was: 2.3) > Implements RAMP transactions on top of Cassandra > > > Key: IGNITE-3610 > URL: https://issues.apache.org/jira/browse/IGNITE-3610 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Igor Rudyak >Assignee: Igor Rudyak > > Implement RAMP transaction (http://www.bailis.org/papers/ramp-sigmod2014.pdf) > to provide atomic read isolation for cache data modified withing transaction. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-2037) Update javadocs and documentation about LOCAL cache could be created on client node
[
https://issues.apache.org/jira/browse/IGNITE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2037:
Fix Version/s: (was: 2.3)
> Update javadocs and documentation about LOCAL cache could be created on
> client node
> ---
>
> Key: IGNITE-2037
> URL: https://issues.apache.org/jira/browse/IGNITE-2037
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexey Kuznetsov
>Assignee: kcheng.mvp
>Priority: Trivial
> Labels: newbie
>
> Code that show local cache on client node:
> {code}
> public class LocalCacheOnClient {
> public static void main(String[] args) throws IgniteException {
> IgniteConfiguration cfgSrv = new IgniteConfiguration();
> cfgSrv.setGridName("srv");
> Ignite n1 = Ignition.start(cfgSrv);
> IgniteConfiguration cfgClm = new IgniteConfiguration();
> cfgClm.setGridName("cln");
> cfgClm.setClientMode(true);
> Ignite n2 = Ignition.start(cfgClm);
> CacheConfiguration ccfg = new
> CacheConfiguration<>("local");
> ccfg.setCacheMode(CacheMode.LOCAL);
> IgniteCache c = n2.getOrCreateCache(ccfg);
> c.put(1, 100);
> n1.close(); // stop server node
> c.put(2, 200); // local cache works fine.
> System.out.println(c.get(1));
> System.out.println(c.get(2));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-4626) GridDhtPartitionTopologyImpl refactoring
[ https://issues.apache.org/jira/browse/IGNITE-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4626: Fix Version/s: (was: 2.3) > GridDhtPartitionTopologyImpl refactoring > > > Key: IGNITE-4626 > URL: https://issues.apache.org/jira/browse/IGNITE-4626 > Project: Ignite > Issue Type: Task >Reporter: Konstantin Dudkov >Assignee: Konstantin Dudkov > > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#nodes(int, > org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion) > Need to refactor this method to use Object[] - partId->List -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6248) Check Java 7 builds for compatibility with Ignite and update documentation
[ https://issues.apache.org/jira/browse/IGNITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6248: Fix Version/s: (was: 2.3) > Check Java 7 builds for compatibility with Ignite and update documentation > -- > > Key: IGNITE-6248 > URL: https://issues.apache.org/jira/browse/IGNITE-6248 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Evgenii Zhuravlev >Assignee: Dmitry Karachentsev > Labels: usability > > According to these threads on SO and user list, some old Java 7 versions > doesn't compatible with Ignite since version 2.1 anymore: > http://apache-ignite-users.70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-General-error-quot-java-lang-IllegalMonitorStateException-Attt-td15684.html > https://stackoverflow.com/questions/45911616/datastreamer-does-not-work-well/45972341#45972341 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5564) Race between read-through and topology version update
[
https://issues.apache.org/jira/browse/IGNITE-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5564:
Fix Version/s: (was: 2.3)
> Race between read-through and topology version update
> -
>
> Key: IGNITE-5564
> URL: https://issues.apache.org/jira/browse/IGNITE-5564
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Dmitry Karachentsev
> Attachments: GridCachePartitionEvictionDuringReadThroughSelfTest.java
>
>
> I occasionally observe the following assertions when working with ATOMIC
> cache with cache store on changing topology:
> {code}
> java.lang.AssertionError: Invalid version for inner update [isNew=false,
> entry=GridDhtAtomicCacheEntry [super=GridDhtCacheEntry [rdrs=[],
> locPart=GridDhtLocalPartition [id=157,
> map=org.apache.ignite.internal.processors.cache.GridCacheConcurrentMapImpl@7a99d0af,
> rmvQueue=GridCircularBuffer [sizeMask=31, idxGen=0], cntr=8,
> shouldBeRenting=false, state=OWNING, reservations=0, empty=false,
> createTime=06/21/2017 09:59:03], super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=1181,
> hasValBytes=true], val=CacheObjectImpl [val=1181, hasValBytes=true],
> startVer=1498028394357, ver=GridCacheVersion [topVer=109508344,
> time=1498028344708, order=1498028394358, nodeOrder=1], hash=1181,
> extras=GridCacheTtlEntryExtras [ttl=6, expireTime=1498028404707],
> flags=0, newVer=GridCacheVersion [topVer=109508343, time=1498028344709,
> order=1498028394369, nodeOrder=1]]
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2485)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1887)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1727)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264)
> 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:209)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1242)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:675)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2294)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearAtomicCache.put(GridNearAtomicCache.java:437)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2271)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379)
> {code}
> The assertion happens because there is a race between these events:
> 1) An update is mapped on topology version N
> 2) Topology version changes and discovery updates the version to N+1, but the
> event is not yet processed by the exchange future
> 3) A read-through request comes in and performs the read. Inside
> {{versionedValue()}} call a new entry version is generated. Since the
> discovery version is already updated, the new entry version is based on
> topVer=N+1
> 4) Update request proceeds and read-locks the topology. Since the exchange
> future is not yet initialized, the request does not attempt to remap and
> proceeds with version N
> 5) The next entry version is generated using request topology version = N
> 6) Inside the entry update method, we assert that new version is greater than
> old version, but it's not the case in this scenario, and assertion fails
> Attached is a test reproducing the issue (see
> testConcurrentReadThroughUpdate())
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6447) Web console: the panel with text 'Demo mode' hides buttons on Query screen
[ https://issues.apache.org/jira/browse/IGNITE-6447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6447: Fix Version/s: (was: 2.3) > Web console: the panel with text 'Demo mode' hides buttons on Query screen > -- > > Key: IGNITE-6447 > URL: https://issues.apache.org/jira/browse/IGNITE-6447 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Dmitriy Shabalin > Attachments: screenshot-1.png > > > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5518) Rework test on join active/inactive node
[ https://issues.apache.org/jira/browse/IGNITE-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5518: Fix Version/s: (was: 2.3) > Rework test on join active/inactive node > - > > Key: IGNITE-5518 > URL: https://issues.apache.org/jira/browse/IGNITE-5518 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4159) Cloud Native Deployment of Apache Ignite using Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4159: Fix Version/s: (was: 2.3) > Cloud Native Deployment of Apache Ignite using Kubernetes > - > > Key: IGNITE-4159 > URL: https://issues.apache.org/jira/browse/IGNITE-4159 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Magda >Assignee: Denis Magda > > Kubernetes is an open-source system for automating deployment, scaling, and > management of containerized applications. > http://kubernetes.io > Apache Ignite perfectly fits the concepts implemented in Kubernetes which may > greatly simplify and automate the maintenance and scaling of Apache Ignite > clusters running under the supervision of Kubernetes. > Ignite won't be the first distributed storage that supports Kubernetes. There > are already a number of existed ones that being used: > https://github.com/kubernetes/kubernetes/tree/master/examples/storage/cassandra > https://github.com/pires/hazelcast-kubernetes > https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes > This is an umbrella ticket that incorporates all the works that have to be > done before Ignite officially claims that it can be launched under Kubernetes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6339) WAL: Avoid closed by interruption exception when user thread is interrupted
[ https://issues.apache.org/jira/browse/IGNITE-6339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6339: Fix Version/s: (was: 2.3) > WAL: Avoid closed by interruption exception when user thread is interrupted > --- > > Key: IGNITE-6339 > URL: https://issues.apache.org/jira/browse/IGNITE-6339 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Andrey Gura >Assignee: Andrey Gura > > We should have a separate writer thread for WAL that will write completed > serialized chunks of data. This will allow us avoid closed by interruption > exception when user thread is interrupted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5539) MemoryMetrics.getTotalAllocatedPages return 0 when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5539: Fix Version/s: (was: 2.3) > MemoryMetrics.getTotalAllocatedPages return 0 when persistence is enabled > - > > Key: IGNITE-5539 > URL: https://issues.apache.org/jira/browse/IGNITE-5539 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Kuznetsov >Assignee: Sergey Chugunov > > In memory only mode metrics show some not zero values. > With persistence it shows zero. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6234) [Test failure] GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode
[
https://issues.apache.org/jira/browse/IGNITE-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6234:
Fix Version/s: (was: 2.3)
> [Test failure]
> GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode
> ---
>
> Key: IGNITE-6234
> URL: https://issues.apache.org/jira/browse/IGNITE-6234
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
> Labels: MakeTeamcityGreenAgain
>
> Test reproducible locally although with a very low probability.
> I wasn't able to reproduce it starting test in isolation but managed to do it
> starting *GridCacheClientModesTcpClientDiscoveryAbstractTest* 50 times in a
> row observing from 1 to 3 failures.
> Test run with failed test is available
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=798538&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteCache].
> It seems that when client requests value of custom class from near cache it
> may see BinaryMetadata for this class with no schema.
> Test fails with the following exception:
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.binary.BinaryMetadata.hasSchema(BinaryMetadata.java:189)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:517)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:185)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1237)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:284)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:183)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:161)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:41)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1734)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1828)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.loadEntries(GridNearGetFuture.java:752)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.access$000(GridNearGetFuture.java:68)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture$MiniFuture.onResult(GridNearGetFuture.java:1012)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.onResult(GridNearGetFuture.java:215)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearCacheAdapter.processGetResponse(GridNearCacheAdapter.java:294)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:92)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:90)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeList
[jira] [Updated] (IGNITE-4378) Affinity function should support assigning partition to subset of cluster nodes
[
https://issues.apache.org/jira/browse/IGNITE-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4378:
Fix Version/s: (was: 2.3)
> Affinity function should support assigning partition to subset of cluster
> nodes
> ---
>
> Key: IGNITE-4378
> URL: https://issues.apache.org/jira/browse/IGNITE-4378
> Project: Ignite
> Issue Type: New Feature
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Alexei Scherbakov
>
> Currently both default affinity function(AF) implementations randomly choose
> primary node among all topology nodes.
> This may not be enough to handle complex data placement scenarios without
> implementing own AF.
> On example, some partitions can be assigned to more powerful hardware, or
> limited to subset of cluster nodes due to ease of management or fault
> tolerance scenarios.
> We should implement node filter, which will allow to choose subset of cluster
> nodes to place primary and backup partitions.
> With already existing ability to filter backup nodes (using
> {{AffinityBackupFilter}}) it will allow to implement different approaches to
> data placement with Ignite without resorting to custom AF.
> It's also desirable to include a practical example of both topology filters
> based on node attribute values.
> Proposed primary filter interface is below.
> {noformat}
> /**
> * Allows partition placement to subset of cluster node.
> *
> * Backup nodes also will be assigned from the subset.
> */
> public interface AffinityPrimaryFilter extends IgniteBiClosure List, List> {
> /**
> * Return nodes allowed to contain given partition.
> * @param partition Partition.
> * @param currentTopologyNodes All nodes from current topology.
> * @return Subset of nodes.
> */
> @Override public List apply(Integer partition,
> List currentTopologyNodes);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-4554) Optimize integer sets.
[ https://issues.apache.org/jira/browse/IGNITE-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4554: Fix Version/s: (was: 2.3) > Optimize integer sets. > -- > > Key: IGNITE-4554 > URL: https://issues.apache.org/jira/browse/IGNITE-4554 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.6 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov > > Ignite has many uses of data structures like Set, IntArray etc. > This is not most efficient way to represent integer sets. The best way is to > use compressed bit sets. This should save a lot of heap space. > We should optimize integer sets whenever possible. > The most obvious place to start is GridAffinityAssignment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-2656) Documentation on debugging and fixing the reasons of node disconnection from the cluster
[
https://issues.apache.org/jira/browse/IGNITE-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2656:
Labels: (was: documentation)
> Documentation on debugging and fixing the reasons of node disconnection from
> the cluster
>
>
> Key: IGNITE-2656
> URL: https://issues.apache.org/jira/browse/IGNITE-2656
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.3
>
>
> Sometimes a node can be abruptly kicked off from the cluster buy some reason.
> The documentation must contain information on how to get to the root of the
> issue by looking at logs files. Usually the node that was kicked off contains
> "Local node segmented" message and the node that failed its next neighbor
> contains a message with more details "Failed to send message to next node".
> Next the article must list possible reasons of the disconnection:
> - long GC pauses. Give recommendations on how to check;
> - high node utilization so that it responds with a delay;
> - low network configuration parameters that are not suited for an environment;
> There should be a section about
> {{IgniteConfiguration.failureDetectionTimeout}} describing its behavior and
> showing all its pros and cons.
> The article must say when it makes sense to 'disable' this timeout by
> switching to explicit configuration of TcpDiscoverySpi.socketTimeout,
> TcpDiscoverySpi.ackTimeout, TcpDiscoverySpi.maxAckTimeout,
> TcpDiscoverySpi.reconnectCount. Pros and cons of manual configuration has to
> be mentioned as well.
>
> Also I would list the usage of TcpDiscoverySpi.joinTimeout,
> TcpDiscoverySpi.networkTimeout (used on client reconnect, servers waits for
> join result, node stop, socket reader first message.) there as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-2656) Documentation on debugging and fixing the reasons of node disconnection from the cluster
[
https://issues.apache.org/jira/browse/IGNITE-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2656:
Component/s: documentation
> Documentation on debugging and fixing the reasons of node disconnection from
> the cluster
>
>
> Key: IGNITE-2656
> URL: https://issues.apache.org/jira/browse/IGNITE-2656
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.3
>
>
> Sometimes a node can be abruptly kicked off from the cluster buy some reason.
> The documentation must contain information on how to get to the root of the
> issue by looking at logs files. Usually the node that was kicked off contains
> "Local node segmented" message and the node that failed its next neighbor
> contains a message with more details "Failed to send message to next node".
> Next the article must list possible reasons of the disconnection:
> - long GC pauses. Give recommendations on how to check;
> - high node utilization so that it responds with a delay;
> - low network configuration parameters that are not suited for an environment;
> There should be a section about
> {{IgniteConfiguration.failureDetectionTimeout}} describing its behavior and
> showing all its pros and cons.
> The article must say when it makes sense to 'disable' this timeout by
> switching to explicit configuration of TcpDiscoverySpi.socketTimeout,
> TcpDiscoverySpi.ackTimeout, TcpDiscoverySpi.maxAckTimeout,
> TcpDiscoverySpi.reconnectCount. Pros and cons of manual configuration has to
> be mentioned as well.
>
> Also I would list the usage of TcpDiscoverySpi.joinTimeout,
> TcpDiscoverySpi.networkTimeout (used on client reconnect, servers waits for
> join result, node stop, socket reader first message.) there as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-2656) Documentation on debugging and fixing the reasons of node disconnection from the cluster
[
https://issues.apache.org/jira/browse/IGNITE-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2656:
Labels: documentation (was: )
> Documentation on debugging and fixing the reasons of node disconnection from
> the cluster
>
>
> Key: IGNITE-2656
> URL: https://issues.apache.org/jira/browse/IGNITE-2656
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.3
>
>
> Sometimes a node can be abruptly kicked off from the cluster buy some reason.
> The documentation must contain information on how to get to the root of the
> issue by looking at logs files. Usually the node that was kicked off contains
> "Local node segmented" message and the node that failed its next neighbor
> contains a message with more details "Failed to send message to next node".
> Next the article must list possible reasons of the disconnection:
> - long GC pauses. Give recommendations on how to check;
> - high node utilization so that it responds with a delay;
> - low network configuration parameters that are not suited for an environment;
> There should be a section about
> {{IgniteConfiguration.failureDetectionTimeout}} describing its behavior and
> showing all its pros and cons.
> The article must say when it makes sense to 'disable' this timeout by
> switching to explicit configuration of TcpDiscoverySpi.socketTimeout,
> TcpDiscoverySpi.ackTimeout, TcpDiscoverySpi.maxAckTimeout,
> TcpDiscoverySpi.reconnectCount. Pros and cons of manual configuration has to
> be mentioned as well.
>
> Also I would list the usage of TcpDiscoverySpi.joinTimeout,
> TcpDiscoverySpi.networkTimeout (used on client reconnect, servers waits for
> join result, node stop, socket reader first message.) there as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-4773) Web Console: Create New Design Concept
[ https://issues.apache.org/jira/browse/IGNITE-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4773: Fix Version/s: (was: 2.3) 2.4 > Web Console: Create New Design Concept > -- > > Key: IGNITE-4773 > URL: https://issues.apache.org/jira/browse/IGNITE-4773 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Vica Abramova > Fix For: 2.4 > > > Don't forget to support multi-clustering. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5038: Fix Version/s: (was: 2.3) > BinaryMarshaller might need to use context class loader for deserialization > --- > > Key: IGNITE-5038 > URL: https://issues.apache.org/jira/browse/IGNITE-5038 > Project: Ignite > Issue Type: Improvement > Components: binary >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Vladimir Ozerov > Labels: features > Attachments: results-compound-20170802.zip, > results-compound-20170808.zip > > > There is a special use case discussed on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224 > According to the use case, BinaryMarshaller might need to try to deserialize > an object using a context class loader if it failed to do so with a custom > classloader (`IgniteConfiguration.getClassLoader()`) or the system one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6343) Index is not used properly if changing sort order.
[
https://issues.apache.org/jira/browse/IGNITE-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6343:
Fix Version/s: (was: 2.3)
> Index is not used properly if changing sort order.
> --
>
> Key: IGNITE-6343
> URL: https://issues.apache.org/jira/browse/IGNITE-6343
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
> Labels: performance
>
> Unit test reproducer:
> {noformat}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.ignite.internal.processors.cache;
> import java.util.Calendar;
> import java.util.Collections;
> import java.util.Date;
> import java.util.LinkedHashMap;
> import java.util.List;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.QueryEntity;
> import org.apache.ignite.cache.QueryIndex;
> import org.apache.ignite.cache.QueryIndexType;
> import org.apache.ignite.cache.query.SqlFieldsQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.MemoryConfiguration;
> import org.apache.ignite.configuration.MemoryPolicyConfiguration;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
> import static java.util.Calendar.*;
> /**
> * Tests for cache query results serialization.
> */
> public class GridCacheQueryIndexUsageSelfTest extends GridCommonAbstractTest {
> /** */
> private static final int GRID_CNT = 1;
> /** */
> private static final String CACHE_NAME = "A";
> /** */
> private static final CacheMode CACHE_MODE = PARTITIONED;
> /** */
> private static TcpDiscoveryIpFinder ipFinder = new
> TcpDiscoveryVmIpFinder(true);
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> startGridsMultiThreaded(GRID_CNT);
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> }
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> MemoryPolicyConfiguration mpcfg = new MemoryPolicyConfiguration();
> //mpcfg.setMaxSize(2 * 1024 * 1024 * 1024L);
> mpcfg.setName("def");
> MemoryConfiguration mcfg = new MemoryConfiguration();
> mcfg.setDefaultMemoryPolicyName("def");
> mcfg.setMemoryPolicies(mpcfg);
> cfg.setMemoryConfiguration(mcfg);
> TcpDiscoverySpi disco = new TcpDiscoverySpi();
> disco.setIpFinder(ipFinder);
> cfg.setDiscoverySpi(disco);
> CacheConfiguration cacheCfg = defaultCacheConfiguration();
> cacheCfg.setName(CACHE_NAME);
> cacheCfg.setCacheMode(CACHE_MODE);
> cacheCfg.setWriteSynchronizationMode(FULL_SYNC);
> QueryEntity qe = new QueryEntity();
> qe.setKeyType(Long.class.getName());
> qe.setValueType(IndexedValue.class.getName());
> LinkedHashMap fields = U.newLinkedHashMap(3);
> fields.put("id", Long.class.getName());
> fields.put("startDate", Date.class.getName());
> qe.setFields(fields);
> QueryIndex idx = new QueryIndex();
> idx.setIndexType(QueryIndexType.SORTED);
> LinkedHashMap idxFields = U.newLinkedHashMap(3);
> idxFields.put("startDate", Boolean.TRUE);
> i
[jira] [Updated] (IGNITE-4490) Optimize DML for fast INSERT and MERGE
[
https://issues.apache.org/jira/browse/IGNITE-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4490:
Fix Version/s: (was: 2.3)
2.4
> Optimize DML for fast INSERT and MERGE
> --
>
> Key: IGNITE-4490
> URL: https://issues.apache.org/jira/browse/IGNITE-4490
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Labels: performance
> Fix For: 2.4
>
>
> It's possible to avoid any SQL querying and map some INSERT and MERGE
> statements to cache operations in a way similar to that of UPDATE and DELETE
> - i.e. don't make queries when there are no expressions to evaluate in the
> query and enhance update plans to perform direct cache operations when INSERT
> and MERGE affect columns {{_key}} and {{_val}} only.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-4489) Maintain correct MERGE semantic in DML
[ https://issues.apache.org/jira/browse/IGNITE-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4489: Fix Version/s: (was: 2.3) 2.4 > Maintain correct MERGE semantic in DML > -- > > Key: IGNITE-4489 > URL: https://issues.apache.org/jira/browse/IGNITE-4489 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Assignee: Alexander Paschenko > Fix For: 2.4 > > > Currently it's impossible to MERGE object in UPDATE style - i.e. when key is > present in cache, unaffected field values should be retained, and instead of > building new object we should base it on previous one for given key. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6092) Bulk Inserts are not Supported
[
https://issues.apache.org/jira/browse/IGNITE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6092:
Fix Version/s: (was: 2.3)
2.4
> Bulk Inserts are not Supported
> ---
>
> Key: IGNITE-6092
> URL: https://issues.apache.org/jira/browse/IGNITE-6092
> Project: Ignite
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 2.4
>
>
> Presently the bulk inserts like these are not supported by Ignite's SQL
> engine:
> {code}
> INSERT INTO City (id, name)
> VALUES (1, 'Forest Hill'),
>(2, "Denver"),
>(3, "St. Petersburg")
> INSERT INTO Person (id, name, city_id)
> VALUES (1, 'John Doe', 3),
>(2, "Jane Roe", 2),
>(3, "Mary Major", 1),
>(4, "Richard Miles", 2)
> {code}
> Let's plan to support them for the nearest release. I've used DBeaver tool to
> validate the statements above:
> https://apacheignite-tools.readme.io/docs/dbeaver
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6059) Use any distributed matrix in K-Means
[ https://issues.apache.org/jira/browse/IGNITE-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182992#comment-16182992 ] Mikhail Lipkovich commented on IGNITE-6059: --- Thanks both of you for your comments. I will dive into it after my vacation > Use any distributed matrix in K-Means > - > > Key: IGNITE-6059 > URL: https://issues.apache.org/jira/browse/IGNITE-6059 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak > > Currently k-means work only with row/col matrix. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5784) .NET: QueryIndex.InlineSize
[
https://issues.apache.org/jira/browse/IGNITE-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-5784:
--
Assignee: Pavel Tupitsyn
> .NET: QueryIndex.InlineSize
> ---
>
> Key: IGNITE-5784
> URL: https://issues.apache.org/jira/browse/IGNITE-5784
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> {{QueryIndex.InlineSize}} controls index payload when it is stored in Ignite
> page memory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6517) .NET: DataStreamer DefaultPerNodeBufferSize, DefaultParallelOpsMultiplier
Pavel Tupitsyn created IGNITE-6517:
--
Summary: .NET: DataStreamer DefaultPerNodeBufferSize,
DefaultParallelOpsMultiplier
Key: IGNITE-6517
URL: https://issues.apache.org/jira/browse/IGNITE-6517
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.3
Add default constants {{DefaultPerNodeBufferSize}} and
{{DefaultParallelOpsMultiplier}} somewhere (interface does not allow them).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6516) .NET: PersistentStoreConfiguration.WriteThrottlingEnabled
Pavel Tupitsyn created IGNITE-6516:
--
Summary: .NET: PersistentStoreConfiguration.WriteThrottlingEnabled
Key: IGNITE-6516
URL: https://issues.apache.org/jira/browse/IGNITE-6516
Project: Ignite
Issue Type: Improvement
Components: platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.3
Add {{PersistentStoreConfiguration.WriteThrottlingEnabled}} to .NET.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5784) .NET: QueryIndex.InlineSize
[
https://issues.apache.org/jira/browse/IGNITE-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-5784:
---
Fix Version/s: 2.3
> .NET: QueryIndex.InlineSize
> ---
>
> Key: IGNITE-5784
> URL: https://issues.apache.org/jira/browse/IGNITE-5784
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> {{QueryIndex.InlineSize}} controls index payload when it is stored in Ignite
> page memory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6515) .NET: Enable persistence on per-cache basis
Pavel Tupitsyn created IGNITE-6515: -- Summary: .NET: Enable persistence on per-cache basis Key: IGNITE-6515 URL: https://issues.apache.org/jira/browse/IGNITE-6515 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.3 Reporter: Pavel Tupitsyn Fix For: 2.3 Propagate new configuration to .NET: IGNITE-6030 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5615) .NET: IgniteConfiguration.LocalEventListeners
[
https://issues.apache.org/jira/browse/IGNITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182928#comment-16182928
]
ASF GitHub Bot commented on IGNITE-5615:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2754
> .NET: IgniteConfiguration.LocalEventListeners
> -
>
> Key: IGNITE-5615
> URL: https://issues.apache.org/jira/browse/IGNITE-5615
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> Propagate {{IgniteConfiguration.LocalEventListeners}} to .NET. This allows
> catching all events right from the node start.
> * Can we unsubscribe from these events later? Does Java support this?
> * What about GetEvents for a cluster group, how do we handle local listeners
> in this case?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5615) .NET: IgniteConfiguration.LocalEventListeners
[
https://issues.apache.org/jira/browse/IGNITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182922#comment-16182922
]
Pavel Tupitsyn commented on IGNITE-5615:
Merged to master: {{b364589dffcb57aa2297fd1f2862f16065d44701}}.
> .NET: IgniteConfiguration.LocalEventListeners
> -
>
> Key: IGNITE-5615
> URL: https://issues.apache.org/jira/browse/IGNITE-5615
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> Propagate {{IgniteConfiguration.LocalEventListeners}} to .NET. This allows
> catching all events right from the node start.
> * Can we unsubscribe from these events later? Does Java support this?
> * What about GetEvents for a cluster group, how do we handle local listeners
> in this case?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6422) In visorcmd "cache on nodes" statistics mixes together primary and backup entries
[
https://issues.apache.org/jira/browse/IGNITE-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182822#comment-16182822
]
Ilya Kasnacheev commented on IGNITE-6422:
-
Looks OK to me!
> In visorcmd "cache on nodes" statistics mixes together primary and backup
> entries
> -
>
> Key: IGNITE-6422
> URL: https://issues.apache.org/jira/browse/IGNITE-6422
> Project: Ignite
> Issue Type: Bug
> Components: visor
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Alexey Kuznetsov
>
> Suppose we have a cache, with 1000 entries, one backup and eviction after 500
> entries. Then, off-heap entries are doubled in visorcmd, while on-heap
> entries are not:
> {code}
> +-+
> | Name(@) | EmployeesCache(@c0) |
> | Nodes | 2 |
> | Total size Min/Avg/Max | 1500 / 1500.00 / 1500 |
> | Heap size Min/Avg/Max | 500 / 500.00 / 500|
> | Off-heap size Min/Avg/Max | 1000 / 1000.00 / 1000 |
> +-+
> Nodes for: EmployeesCache(@c0)
> +=+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
> Size | Hi/Mi/Rd/Wr |
> +=+
> | 37333BC6(@n0), 172.16.9.1 | 8| 4.47 %| 0.40 % | 00:00:47:154 |
> Total: 1500 | Hi: 0 |
> | | | | | |
> Heap: 500 | Mi: 0 |
> | | | | | |
> Off-Heap: 1000 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +---+--+---+--+--+--+-+
> | 26FD4343(@n1), 172.16.9.1 | 8| 3.09 %| 0.23 % | 00:00:41:602 |
> Total: 1500 | Hi: 0 |
> | | | | | |
> Heap: 500 | Mi: 0 |
> | | | | | |
> Off-Heap: 1000 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +-+
> 'Hi' - Number of cache hits.
> {code}
> By contrast, on 1.9 it looks like this:
> {code}
> Cache 'EmployeesCache(@c0)':
> +-+
> | Name(@) | EmployeesCache(@c0) |
> | Nodes | 2 |
> | Total size Min/Avg/Max | 1000 / 1000.00 / 1000 |
> | Heap size Min/Avg/Max | 500 / 500.00 / 500|
> | Off-heap size Min/Avg/Max | 500 / 500.00 / 500|
> +-+
> Nodes for: EmployeesCache(@c0)
> ++
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
> Size | Hi/Mi/Rd/Wr |
> ++
> | 3229FABE(@n0), 172.16.9.1 | 8| 1.25 %| 0.23 % | 00:00:43:111 |
> Total: 1000 | Hi: 0 |
> | | | | | |
> Heap: 500 | Mi: 0 |
> | | | | | |
> Off-Heap: 500 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 88kb | Wr: 0 |
> +---+--+---+--+--+-+-+
> | 58FA742B(@n1), 172.16.9.1 | 8| 1.15 %| 0.47 % | 00:00:38:828 |
> Total: 1000 | Hi: 0 |
> | | | | | |
> Heap: 500 | Mi: 0 |
> | | | | | |
> Off-Heap: 500 | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 88kb | Wr: 0 |
> ++
> {cod
[jira] [Resolved] (IGNITE-6514) Hide QueryEntity.notNullFields from public API
[ https://issues.apache.org/jira/browse/IGNITE-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-6514. -- Resolution: Fixed > Hide QueryEntity.notNullFields from public API > -- > > Key: IGNITE-6514 > URL: https://issues.apache.org/jira/browse/IGNITE-6514 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk > Fix For: 2.3 > > > The QueryEntity class already became too overloaded, so we need to hide this > from public API for now until a better approach is developed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6514) Hide QueryEntity.notNullFields from public API
Alexey Goncharuk created IGNITE-6514: Summary: Hide QueryEntity.notNullFields from public API Key: IGNITE-6514 URL: https://issues.apache.org/jira/browse/IGNITE-6514 Project: Ignite Issue Type: Improvement Components: cache Reporter: Alexey Goncharuk Assignee: Alexey Goncharuk Fix For: 2.3 The QueryEntity class already became too overloaded, so we need to hide this from public API for now until a better approach is developed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6513) Add ability manage version of WAL serializer via system properties
[ https://issues.apache.org/jira/browse/IGNITE-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-6513: --- Summary: Add ability manage version of WAL serializer via system properties (was: Add ability manage version for WAL serializer via system properties) > Add ability manage version of WAL serializer via system properties > -- > > Key: IGNITE-6513 > URL: https://issues.apache.org/jira/browse/IGNITE-6513 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6513) Add ability manage version for WAL serializer via system properties
Dmitriy Govorukhin created IGNITE-6513: -- Summary: Add ability manage version for WAL serializer via system properties Key: IGNITE-6513 URL: https://issues.apache.org/jira/browse/IGNITE-6513 Project: Ignite Issue Type: Improvement Affects Versions: 2.1, 2.0, 2.2, 2.3 Reporter: Dmitriy Govorukhin Assignee: Dmitriy Govorukhin Fix For: 2.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5439) JDBC thin: support query cancel
[
https://issues.apache.org/jira/browse/IGNITE-5439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182566#comment-16182566
]
Taras Ledkov edited comment on IGNITE-5439 at 9/27/17 2:46 PM:
---
[~vozerov],
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than
generic error usage. I cannot see the SQLSTATE corresponds to query
cancellation at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for
this case.
[Tests|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&tab=projectOverview&branch_Ignite20Tests=pull%2F2436%2Fhead]
are OK. Please review the changes.
was (Author: tledkov-gridgain):
[~vozerov],
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than
generic error usage. I cannot see the SQLSTATE corresponds to query
cancellation at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for
this case.
> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> The JDBC {{Statement.cancel}} method must be supported.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182665#comment-16182665 ] Michael Griggs commented on IGNITE-6069: >all service instances with the same name must have the same version I think this ticket is a good opportunity to have multiple versions of a service available in the cluster at the same time. By default requests would go to the latest version, but earlier versions could be requested by adding a parameter to the `serviceProxy()` method. The service version could be better indicated using an attribute on the service implementation, rather than using serialVersionUuid. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented, it has to be documented extensively. The > ticket must not be closed until this happens. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5439) JDBC thin: support query cancel
[
https://issues.apache.org/jira/browse/IGNITE-5439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182566#comment-16182566
]
Taras Ledkov edited comment on IGNITE-5439 at 9/27/17 1:39 PM:
---
[~vozerov],
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than
generic error usage. I cannot see the SQLSTATE corresponds to query
cancellation at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for
this case.
was (Author: tledkov-gridgain):
[~vozerov],
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than
use generic error. I cannot see the SQLSTATE corresponds to query cancellation
at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for this case.
> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> The JDBC {{Statement.cancel}} method must be supported.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5439) JDBC thin: support query cancel
[
https://issues.apache.org/jira/browse/IGNITE-5439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182566#comment-16182566
]
Taras Ledkov edited comment on IGNITE-5439 at 9/27/17 1:39 PM:
---
[~vozerov],
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than
use generic error. I cannot see the SQLSTATE corresponds to query cancellation
at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for this case.
was (Author: tledkov-gridgain):
[~vozerov],
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case better than use
generic error. I cannot see the SQLSTATE corresponds to query cancellation at
the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for this case.
> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> The JDBC {{Statement.cancel}} method must be supported.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5439) JDBC thin: support query cancel
[
https://issues.apache.org/jira/browse/IGNITE-5439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182566#comment-16182566
]
Taras Ledkov commented on IGNITE-5439:
--
[~vozerov],
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case better than use
generic error. I cannot see the SQLSTATE corresponds to query cancellation at
the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for this case.
> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> The JDBC {{Statement.cancel}} method must be supported.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6512) Need a possibility to start caches without discarding their 'restarting' state
Eduard Shangareev created IGNITE-6512: - Summary: Need a possibility to start caches without discarding their 'restarting' state Key: IGNITE-6512 URL: https://issues.apache.org/jira/browse/IGNITE-6512 Project: Ignite Issue Type: Improvement Reporter: Eduard Shangareev Now we always discard restarting state on cache while it is starting. But sometimes we need extra steps before making caches available from public API. So, I suggest adding a new method which would be called when we want to make caches available for public API clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5713) The ignite-spring module should not rely on the ignite-indexing module.
[ https://issues.apache.org/jira/browse/IGNITE-5713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182500#comment-16182500 ] ASF GitHub Bot commented on IGNITE-5713: GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/2763 IGNITE-5713 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5713 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2763.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 #2763 commit 34ec1d24d67f7429693477d96fa9293393b8ed97 Author: devozerov Date: 2017-09-27T12:41:48Z IGNITE-5713: Removed dependency in ignite-indexing. > The ignite-spring module should not rely on the ignite-indexing module. > --- > > Key: IGNITE-5713 > URL: https://issues.apache.org/jira/browse/IGNITE-5713 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.0 >Reporter: Yujue Li >Assignee: Vladimir Ozerov >Priority: Minor > Fix For: 2.3 > > > In version 2.0, the ignite-spring module has increased reliance on the > ignite-indexing module, which is not appropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5713) The ignite-spring module should not rely on the ignite-indexing module.
[ https://issues.apache.org/jira/browse/IGNITE-5713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-5713: --- Assignee: Vladimir Ozerov > The ignite-spring module should not rely on the ignite-indexing module. > --- > > Key: IGNITE-5713 > URL: https://issues.apache.org/jira/browse/IGNITE-5713 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.0 >Reporter: Yujue Li >Assignee: Vladimir Ozerov >Priority: Minor > Fix For: 2.3 > > > In version 2.0, the ignite-spring module has increased reliance on the > ignite-indexing module, which is not appropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5713) The ignite-spring module should not rely on the ignite-indexing module.
[
https://issues.apache.org/jira/browse/IGNITE-5713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182498#comment-16182498
]
Vladimir Ozerov commented on IGNITE-5713:
-
Added as a part of {{03183a9abd830d9d15a26e773a4d95b841f6d8c3}} commit. No
apparent reason for this.
> The ignite-spring module should not rely on the ignite-indexing module.
> ---
>
> Key: IGNITE-5713
> URL: https://issues.apache.org/jira/browse/IGNITE-5713
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.0
>Reporter: Yujue Li
>Priority: Minor
> Fix For: 2.3
>
>
> In version 2.0, the ignite-spring module has increased reliance on the
> ignite-indexing module, which is not appropriate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5347) Document enums usage in SQL queries
[ https://issues.apache.org/jira/browse/IGNITE-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5347: Fix Version/s: (was: 2.3) > Document enums usage in SQL queries > --- > > Key: IGNITE-5347 > URL: https://issues.apache.org/jira/browse/IGNITE-5347 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Denis Magda > > Here is a documentation to be added to this page > (https://apacheignite.readme.io/v2.0/docs/distributed-queries-21): > If a field is of a Java enum type, then you can pass the field's value as a > parameter via standard `?` keyword or use enum's literal or ordinal value > directly, as shown in the example below: > // SQL query with the field of Java enum type. > SqlFieldsQuery sql = new SqlFieldsQuery( > "SELECT name FROM Person WHERE role = 'DEVELOPER' or role = 2"); -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-3939) Compact NULL values binary representation
[ https://issues.apache.org/jira/browse/IGNITE-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3939: Fix Version/s: (was: 2.3) > Compact NULL values binary representation > - > > Key: IGNITE-3939 > URL: https://issues.apache.org/jira/browse/IGNITE-3939 > Project: Ignite > Issue Type: Improvement > Components: binary >Affects Versions: 1.7 >Reporter: Andrew Mashenkov >Assignee: Taras Ledkov > Labels: iep-2, performance > > We can use separate type for Long zero values and exclude 8-byte value from > binary representation. This will reduce memory footprint and network load. > Compatibility with previous versions MUST be preserved. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
[
https://issues.apache.org/jira/browse/IGNITE-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182469#comment-16182469
]
Sergey Kalashnikov commented on IGNITE-6511:
Workaround: check resulting error message length (reallen > 0) before
manipulation with the error message pointer.
Reproducer:
{quote}
BOOST_AUTO_TEST_CASE(TestLongErrorMessage)
{
StartAdditionalNode("Node1");
Connect("DRIVER={Apache Ignite};ADDRESS=127.0.0.1:0;SCHEMA=PUBLIC");
SQLCHAR req[] = "DROP INDEX Nonexisting";
SQLRETURN ret;
ret = SQLExecDirect(stmt, req, SQL_NTS);
BOOST_REQUIRE_EQUAL(ret, SQL_ERROR);
SQLCHAR sqlstate[7] = {};
SQLINTEGER nativeCode;
SQLCHAR message[10];
SQLSMALLINT reallen = 0;
SQLGetDiagRec(SQL_HANDLE_STMT, stmt, 1, sqlstate, &nativeCode, message,
sizeof(message), &reallen);
BOOST_CHECK_EQUAL(reallen, sizeof(message));
}
{quote}
> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Reporter: Sergey Kalashnikov
> Labels: usability
>
> When buffer size provided for error message is not big enough to hold the
> entire error message, the function {{SqlGetDiagRec()}} returns wrong
> resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} instead
> of {{SQL_SUCCESS_WITH_INFO}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
[
https://issues.apache.org/jira/browse/IGNITE-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6511:
Fix Version/s: (was: 2.3)
> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Reporter: Sergey Kalashnikov
> Labels: usability
>
> When buffer size provided for error message is not big enough to hold the
> entire error message, the function {{SqlGetDiagRec()}} returns wrong
> resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} instead
> of {{SQL_SUCCESS_WITH_INFO}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
[
https://issues.apache.org/jira/browse/IGNITE-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6511:
Fix Version/s: 2.3
> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Reporter: Sergey Kalashnikov
> Labels: usability
> Fix For: 2.3
>
>
> When buffer size provided for error message is not big enough to hold the
> entire error message, the function {{SqlGetDiagRec()}} returns wrong
> resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} instead
> of {{SQL_SUCCESS_WITH_INFO}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
