[jira] [Updated] (IGNITE-6500) While using ignite-cassandra-store, POJO field having wrapper type, mapped to Cassandra table are getting initialized to respective default value of primitive type inste

[Yashasvi Kotamraju (JIRA)]

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

Yashasvi Kotamraju updated IGNITE-6500:
---
Affects Version/s: 2.1
Fix Version/s: 2.3

> While using ignite-cassandra-store, POJO field having wrapper type, mapped to 
> Cassandra table are getting initialized to respective default value of 
> primitive type instead of null if column value is null. 
> -
>
> Key: IGNITE-6500
> URL: https://issues.apache.org/jira/browse/IGNITE-6500
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.1
>Reporter: Yashasvi Kotamraju
>Assignee: Yashasvi Kotamraju
>Priority: Minor
> Fix For: 2.3
>
>
> While using  ignite-cassandra-store, if a POJO field is of wrapper class 
> type, and the column value mapped in cassandra persistent store is null then 
> the POJO field is getting set to default primitive type instead of null.



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

[jira] [Assigned] (IGNITE-6500) While using ignite-cassandra-store, POJO field having wrapper type, mapped to Cassandra table are getting initialized to respective default value of primitive type inst

[Yashasvi Kotamraju (JIRA)]

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

Yashasvi Kotamraju reassigned IGNITE-6500:
--

Assignee: Yashasvi Kotamraju

> While using ignite-cassandra-store, POJO field having wrapper type, mapped to 
> Cassandra table are getting initialized to respective default value of 
> primitive type instead of null if column value is null. 
> -
>
> Key: IGNITE-6500
> URL: https://issues.apache.org/jira/browse/IGNITE-6500
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Reporter: Yashasvi Kotamraju
>Assignee: Yashasvi Kotamraju
>Priority: Minor
>
> While using  ignite-cassandra-store, if a POJO field is of wrapper class 
> type, and the column value mapped in cassandra persistent store is null then 
> the POJO field is getting set to default primitive type instead of null.



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

[jira] [Updated] (IGNITE-4615) Ignite should be compilable under JDK 9

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4615:

Fix Version/s: 2.4

> Ignite should be compilable under JDK 9
> ---
>
> Key: IGNITE-4615
> URL: https://issues.apache.org/jira/browse/IGNITE-4615
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
> Fix For: 2.4
>
> Attachments: ignite.jar.dot
>
>
> The original discussion on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Should-we-take-care-of-Java-9-in-Ignite-2-0-scope-td14018.html



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

[jira] [Commented] (IGNITE-4615) Ignite should be compilable under JDK 9

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4615:
-

JDK 9 is production ready. Targeting the task for 2.4 release.

> Ignite should be compilable under JDK 9
> ---
>
> Key: IGNITE-4615
> URL: https://issues.apache.org/jira/browse/IGNITE-4615
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
> Fix For: 2.4
>
> Attachments: ignite.jar.dot
>
>
> The original discussion on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Should-we-take-care-of-Java-9-in-Ignite-2-0-scope-td14018.html



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

[jira] [Commented] (IGNITE-6506) Cluster activation hangs if a node was stopped during persistent storage checkpoint

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6506:
-

[~agoncharuk], is this a known issue that was fixed in the upcoming 2.3 release?

> 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
>
> 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 
> 

[jira] [Created] (IGNITE-6507) Commit can be lost in network split scenario

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-6507:
-

 Summary: 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
 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.name());
spi0.blockMessages(GridDhtTxFinishRequest.class, grid2.name());

IgniteInternalFuture fut = multithreadedAsync(new Runnable() {
@Override public void run() {
try {
spi0.waitForBlocked();

} catch (InterruptedException e) {
fail();
}

stopGrid(1);

[jira] [Commented] (IGNITE-6440) Flaky failures in DynamicColumnsAbstractConcurrentSelfTest

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6440:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-6440 Test fx



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

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

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

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


commit e56d099d4cd13bdf800f10bbe50f0d1e3c53b891
Author: Alexander Paschenko 
Date:   2017-09-26T19:27:09Z

IGNITE-6440 Test fx




> Flaky failures in DynamicColumnsAbstractConcurrentSelfTest
> --
>
> Key: IGNITE-6440
> URL: https://issues.apache.org/jira/browse/IGNITE-6440
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Multiple failures are observed in concrete implementations of 
> {{DynamicColumnsAbstractConcurrentSelfTest}}. Specifically:
> {code}
> testQueryConsistencyMultithreaded
> testClientReconnect
> testConcurrentRebalance   
> testCoordinatorChange
> testConcurrentPutRemove
> {code}
> Apparently there are some bugs in the test itself, as the following root 
> causes could be observed in logs:
> {code}
> junit.framework.AssertionFailedError: Found nodes from different clusters, 
> probable some test does not stop nodes 
> [allNodes=[index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest3, 
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest2, 
> index.DynamicColumnsConcurrentTransactionalReplicatedSelfTest1]]
> {code}
> {code}
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:565)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest$3.call(DynamicColumnsAbstractConcurrentSelfTest.java:560)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> Please see TeamCity, history of "Queries 2" suite in master branch.



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

[jira] [Commented] (IGNITE-6346) Distributed set does not work in REPLICATED mode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6346:


GitHub user vk23 opened a pull request:

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

IGNITE-6346 Fix: distributed set does not work in REPLICATED mode

Changes:
1. Fixed bug
2. Added tests

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

$ git pull https://github.com/vk23/ignite ignite-6346

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

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


commit 56d173378de373fe65a26193c5b150b73f0ffeae
Author: vk 
Date:   2017-09-26T19:15:04Z

IGNITE-6346 Fix: distributed set does not work in REPLICATED mode

Changes:
1. Fixed bug
2. Added tests




> Distributed set does not work in REPLICATED mode
> 
>
> Key: IGNITE-6346
> URL: https://issues.apache.org/jira/browse/IGNITE-6346
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: vk
>
> When {{IgniteSet}} is created with {{REPLICATED}} cache mode, any attempt to 
> read it fails with exception:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Cluster 
> group is empty.
>   at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:48)
>   at ReplicatedSet.main(ReplicatedSet.java:36)
>   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:498)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class 
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster 
> group is empty.
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute0(GridCacheQueryAdapter.java:481)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute(GridCacheQueryAdapter.java:442)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator0(GridCacheSetImpl.java:420)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator(GridCacheSetImpl.java:375)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSetProxy.iterator(GridCacheSetProxy.java:342)
>   ... 6 more
> {noformat}
> To reproduce run the following code:
> {code}
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-1"));
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-2"));
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> IgniteSet set = ignite.set("my-set", new 
> CollectionConfiguration().setCacheMode(CacheMode.REPLICATED));
> for (String s : set) {
> System.out.println(s);
> }
> {code}



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

[jira] [Commented] (IGNITE-6286) org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-6286:
-

[~schernolyas]
Thanks for fixing p.1.

However, I don't see any changes regarding pts. 2-4.

Pt. 2 - most members of *test* class you added don't have javadocs.
Pt. 3 - this test doesn't have anything to do with Hibernate, JPA, etc. Please 
use convenient public Ignite API, this will make test better readable and 
understandable, and it's important as we have lot of people working on the 
project.
Pt. 4 - I don't see any code deduplication you've made. Please look at your 
methods {{testStringSupport}}, {{testIntegerSupport}}, etc - they all are 
almost identical, copy-pasted. It would be much simpler if you just made one 
test method that would check all fields inside of it.

Also, please don't create any more PRs, Ignite policy is one PR per issue. Just 
push your commits with fixes to the same branch.

Thanks!

> org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>  Labels: usability
> Fix For: 2.3
>
>
> Binding values  of some types to parameterized queries leads to the exception 
>  (see fill stacktrace in comments).
> Also, the exception *blocks* using parameterized queries for Hibernate OGM.
> I proceed the exception for String type. For control it, I developed test ( 
> see 
> org.apache.ignite.internal.processors.query.IgniteSqlParameterizedQueryTest)  
> .  
> The exception reproduced for BigDecimal type in 2.3-snapshot.



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

[jira] [Comment Edited] (IGNITE-6497) Broken tests in ignite-2.1.5

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko edited comment on IGNITE-6497 at 9/26/17 6:12 PM:
-

Fix for failing tests is available in master. Merging the fixed code from 
master into the old branch 2.1.5 would mean adding a lot of code and would be 
very risky.

Because of this it makes better sense to either change tests to ignore failing 
cases (by renaming these since [affected tests use Junit 
3|https://stackoverflow.com/a/3061686/839601]) or by ignoring these TC failures.

Provided pull request and TC run results (linked to ticket) for the case if 
test changes are needed to be merged. [~dethmix], [~DmitriyGovorukhin] - please 
take a look.


was (Author: oignatenko):
Fix for failing tests is available in master. Merging the fixed code from 
master into the old branch 2.1.5 would mean adding a lot of code and would be 
very risky. Because of this it makes better sense to either change tests to 
ignore failing cases (by renaming these since [affected tests use Junit 
3|https://stackoverflow.com/a/3061686/839601]) or by ignoring these TC failures.

> Broken tests in ignite-2.1.5
> 
>
> Key: IGNITE-6497
> URL: https://issues.apache.org/jira/browse/IGNITE-6497
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Affects Versions: 2.1, 2.2
>Reporter: Yury Babak
>Assignee: Oleg Ignatenko
>
> https://ci.ignite.apache.org/viewLog.html?buildId=852249=buildResultsDiv=Ignite20Tests_IgniteMl



--
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

[Joel Lang (JIRA)]

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

Joel Lang updated IGNITE-6506:
--
Description: 
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 [nodeId=62cf0ccb-e376-4b80-8d2d-98115c3a2990, client=false, 
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1]]
java.lang.ArrayIndexOutOfBoundsException: -1
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:82)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:92)
at 
org.apache.ignite.internal.pagemem.wal.record.delta.DataPageInsertRecord.applyDelta(DataPageInsertRecord.java:57)
at 

[jira] [Updated] (IGNITE-6506) Cluster activation hangs if a node was stopped during persistent storage checkpoint

[Joel Lang (JIRA)]

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

Joel Lang updated IGNITE-6506:
--
Summary: Cluster activation hangs if a node was stopped during persistent 
storage checkpoint  (was: Unable to activate cluster node if it was stopped 
during persistent storage checkpoint)

> 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
>
> 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 

[jira] [Created] (IGNITE-6506) Unable to activate cluster node if it was stopped during persistent storage checkpoint

[Joel Lang (JIRA)]

Joel Lang created IGNITE-6506:
-

 Summary: Unable to activate cluster node if it 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


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 [nodeId=62cf0ccb-e376-4b80-8d2d-98115c3a2990, client=false, 
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1]]
java.lang.ArrayIndexOutOfBoundsException: -1
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:82)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:92)
at 

[jira] [Commented] (IGNITE-6497) Broken tests in ignite-2.1.5

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-6497:


Fix for failing tests is available in master. Merging the fixed code from 
master into the old branch 2.1.5 would mean adding a lot of code and would be 
very risky. Because of this it makes better sense to either change tests to 
ignore failing cases (by renaming these since [affected tests use Junit 
3|https://stackoverflow.com/a/3061686/839601]) or by ignoring these TC failures.

> Broken tests in ignite-2.1.5
> 
>
> Key: IGNITE-6497
> URL: https://issues.apache.org/jira/browse/IGNITE-6497
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Affects Versions: 2.1, 2.2
>Reporter: Yury Babak
>Assignee: Oleg Ignatenko
>
> https://ci.ignite.apache.org/viewLog.html?buildId=852249=buildResultsDiv=Ignite20Tests_IgniteMl



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

[jira] [Updated] (IGNITE-6216) .NET: Add CheckpointWriteOrder enum in persistent store configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6216:
---
Description: 
Since 2.2 we have {{CheckpointWriteOrder}} property in 
{{PersistentStoreConfiguration}}. It should be possible to set through .NET 
configuration classes.
Default value should be {{CheckpointWriteOrder#SEQUENTIAL}}.

  was:
Since 2.2 we have CheckpointWriteOrder property in 
PersistentStoreConfiguration. It should be possible to set through .NET 
configuration classes.
Default value should be CheckpointWriteOrder#SEQUENTIAL.


> .NET: Add CheckpointWriteOrder enum in persistent store configuration
> -
>
> Key: IGNITE-6216
> URL: https://issues.apache.org/jira/browse/IGNITE-6216
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Pavel Tupitsyn
>  Labels: .NET, usability
> Fix For: 2.3
>
>
> Since 2.2 we have {{CheckpointWriteOrder}} property in 
> {{PersistentStoreConfiguration}}. It should be possible to set through .NET 
> configuration classes.
> Default value should be {{CheckpointWriteOrder#SEQUENTIAL}}.



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

[jira] [Updated] (IGNITE-6216) .NET: Add CheckpointWriteOrder enum in persistent store configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6216:
---
Labels: .NET usability  (was: .NET MakeTeamcityGreenAgain usability)

> .NET: Add CheckpointWriteOrder enum in persistent store configuration
> -
>
> Key: IGNITE-6216
> URL: https://issues.apache.org/jira/browse/IGNITE-6216
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Pavel Tupitsyn
>  Labels: .NET, usability
> Fix For: 2.3
>
>
> Since 2.2 we have {{CheckpointWriteOrder}} property in 
> {{PersistentStoreConfiguration}}. It should be possible to set through .NET 
> configuration classes.
> Default value should be {{CheckpointWriteOrder#SEQUENTIAL}}.



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

[jira] [Updated] (IGNITE-6503) Need to test Ignite in IPv6 environment

[Vladimir Ozerov (JIRA)]

 [ 
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: 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
> Fix For: 2.3
>
>
> 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-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6502:

Fix Version/s: 2.3

> 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
>  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] [Resolved] (IGNITE-5606) .NET: Enums do not work as a messaging topic or message

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-5606.

Resolution: Fixed

> .NET: Enums do not work as a messaging topic or message
> ---
>
> Key: IGNITE-5606
> URL: https://issues.apache.org/jira/browse/IGNITE-5606
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Trying to use .NET enum in {{IMessaging}} causes "unknown pair" exception in 
> Java. May be we are missing binary mode somewhere.



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

[jira] [Comment Edited] (IGNITE-5606) .NET: Enums do not work as a messaging topic or message

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-5606 at 9/26/17 5:01 PM:
-

Does not reproduce on current master.
Tests for various data types (including enums) as message and topic added.

Merged to master: {{641dd6707f1a20601ac9c00d824bfff2aa54b994}}.


was (Author: ptupitsyn):
Does not reproduce on current master.
Tests for various data types (including enums) as message and topic added: 
{{641dd6707f1a20601ac9c00d824bfff2aa54b994}}.

> .NET: Enums do not work as a messaging topic or message
> ---
>
> Key: IGNITE-5606
> URL: https://issues.apache.org/jira/browse/IGNITE-5606
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Trying to use .NET enum in {{IMessaging}} causes "unknown pair" exception in 
> Java. May be we are missing binary mode somewhere.



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

[jira] [Commented] (IGNITE-5606) .NET: Enums do not work as a messaging topic or message

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5606:


Does not reproduce on current master.
Tests for various data types (including enums) as message and topic added: 
{{641dd6707f1a20601ac9c00d824bfff2aa54b994}}.

> .NET: Enums do not work as a messaging topic or message
> ---
>
> Key: IGNITE-5606
> URL: https://issues.apache.org/jira/browse/IGNITE-5606
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Trying to use .NET enum in {{IMessaging}} causes "unknown pair" exception in 
> Java. May be we are missing binary mode somewhere.



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

[jira] [Commented] (IGNITE-6286) org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters

[Sergey Chernolyas (JIRA)]

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

Sergey Chernolyas commented on IGNITE-6286:
---

Hi [~dmagda] !
It is same exception. I can test example from your issue.

> org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>  Labels: usability
> Fix For: 2.3
>
>
> Binding values  of some types to parameterized queries leads to the exception 
>  (see fill stacktrace in comments).
> Also, the exception *blocks* using parameterized queries for Hibernate OGM.
> I proceed the exception for String type. For control it, I developed test ( 
> see 
> org.apache.ignite.internal.processors.query.IgniteSqlParameterizedQueryTest)  
> .  
> The exception reproduced for BigDecimal type in 2.3-snapshot.



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

[jira] [Assigned] (IGNITE-5606) .NET: Enums do not work as a messaging topic or message

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-5606:
--

Assignee: Pavel Tupitsyn

> .NET: Enums do not work as a messaging topic or message
> ---
>
> Key: IGNITE-5606
> URL: https://issues.apache.org/jira/browse/IGNITE-5606
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Trying to use .NET enum in {{IMessaging}} causes "unknown pair" exception in 
> Java. May be we are missing binary mode somewhere.



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

[jira] [Updated] (IGNITE-5606) .NET: Enums do not work as a messaging topic or message

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5606:
---
Fix Version/s: 2.3

> .NET: Enums do not work as a messaging topic or message
> ---
>
> Key: IGNITE-5606
> URL: https://issues.apache.org/jira/browse/IGNITE-5606
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Trying to use .NET enum in {{IMessaging}} causes "unknown pair" exception in 
> Java. May be we are missing binary mode somewhere.



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

[jira] [Updated] (IGNITE-4809) Cache.getAll can return partially commited results.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4809:
-
Description: 
1. Create tansactional cache with Long values and fill it with zeroes.
2. Start thread that would increment all values in single transaction.
3. Start thread that would check all values are same in single transaction.

Second thread will see partial commits, but shouldn't.


Seems, it is related to OPTIMISTIC concurrency level only.

  was:
1. Create tansactional cache with Long values and fill it with zeroes.
2. Start thread that would increment all values in single transaction.
3. Start thread that would check all values are same in single transaction.

Second thread will see partial commits, but shouldn't.



> Cache.getAll can return partially commited results.
> ---
>
> Key: IGNITE-4809
> URL: https://issues.apache.org/jira/browse/IGNITE-4809
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
> Fix For: 2.4
>
> Attachments: DirtyReads2.java
>
>
> 1. Create tansactional cache with Long values and fill it with zeroes.
> 2. Start thread that would increment all values in single transaction.
> 3. Start thread that would check all values are same in single transaction.
> Second thread will see partial commits, but shouldn't.
> Seems, it is related to OPTIMISTIC concurrency level only.



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

[jira] [Commented] (IGNITE-6295) SQL: Get rid of "replicatedOnly" flag

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6295:
-

Update the doc at the end: 
https://apacheignite-sql.readme.io/docs/configuration-parameters

> SQL: Get rid of "replicatedOnly" flag
> -
>
> Key: IGNITE-6295
> URL: https://issues.apache.org/jira/browse/IGNITE-6295
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>  Labels: usability
>
> This flag acts as a hint that all tables are reside in {{REPLICATED}} cache. 
> However, we already have this information in runtime! No need to ask users to 
> think about it.
> Let's deprecate that flag.



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

[jira] [Commented] (IGNITE-6296) SQL: Get rid of "collocated" flag

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6296:
-

Update the doc at the end: 
https://apacheignite-sql.readme.io/docs/configuration-parameters

> SQL: Get rid of "collocated" flag
> -
>
> Key: IGNITE-6296
> URL: https://issues.apache.org/jira/browse/IGNITE-6296
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: usability
>
> This flag forces our execution engine to perform aggregations on mapper nodes 
> rather than on reducer. 
> First, we already have enough information in runtime to decide whether we can 
> optimize or not. Second, if query is complex enough, users would have hard 
> time trying to figure whether query would return correct result or not. We 
> should never ever return invalid results.
> Let's make our engine smarter, so that it is able to determine whether such 
> grouping is safe or not and then deprecate that flag.



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

[jira] [Updated] (IGNITE-6285) Enhance persistent store paths logging on start

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6285:

Labels: documentation usability  (was: 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, 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] [Resolved] (IGNITE-5898) .NET: Datagrid.QueryDmlExample: Incorrect result if run example with standalone Apache Ignite.NET node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-5898.

Resolution: Fixed

> .NET: Datagrid.QueryDmlExample: Incorrect result if run example  with 
> standalone Apache Ignite.NET node
> ---
>
> Key: IGNITE-5898
> URL: https://issues.apache.org/jira/browse/IGNITE-5898
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.9, 2.1
>Reporter: Irina Zaporozhtseva
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.3
>
>
> {{Datagrid.QueryDmlExample}}: Incorrect result if run example with standalone 
> Apache Ignite.NET node
> without standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 2: Jane Roe, ASF, 5000
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> {code}
> with standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 3: Mary Major, Eclipse, 2000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 3: Mary Major, Eclipse, 2000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> {code}



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

[jira] [Commented] (IGNITE-5898) .NET: Datagrid.QueryDmlExample: Incorrect result if run example with standalone Apache Ignite.NET node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5898:


Fixed in master: {{b4b3fea0de3c8280dece2e59bb1a8c30832c31dd}}.

> .NET: Datagrid.QueryDmlExample: Incorrect result if run example  with 
> standalone Apache Ignite.NET node
> ---
>
> Key: IGNITE-5898
> URL: https://issues.apache.org/jira/browse/IGNITE-5898
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.9, 2.1
>Reporter: Irina Zaporozhtseva
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.3
>
>
> {{Datagrid.QueryDmlExample}}: Incorrect result if run example with standalone 
> Apache Ignite.NET node
> without standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 2: Jane Roe, ASF, 5000
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> {code}
> with standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 3: Mary Major, Eclipse, 2000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 3: Mary Major, Eclipse, 2000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> {code}



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

[jira] [Commented] (IGNITE-6286) org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6286:
-

[~schernolyas], [~al.psc], please look at the ticket below too. Both tickets 
seem related:
https://issues.apache.org/jira/browse/IGNITE-5250

> org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>  Labels: usability
> Fix For: 2.3
>
>
> Binding values  of some types to parameterized queries leads to the exception 
>  (see fill stacktrace in comments).
> Also, the exception *blocks* using parameterized queries for Hibernate OGM.
> I proceed the exception for String type. For control it, I developed test ( 
> see 
> org.apache.ignite.internal.processors.query.IgniteSqlParameterizedQueryTest)  
> .  
> The exception reproduced for BigDecimal type in 2.3-snapshot.



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

[jira] [Updated] (IGNITE-6070) Infinite redirects at Spring Security Web Session Clustering with Tomcat

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-6070:

Fix Version/s: (was: 2.3)

> Infinite redirects at Spring Security Web Session Clustering with Tomcat
> 
>
> Key: IGNITE-6070
> URL: https://issues.apache.org/jira/browse/IGNITE-6070
> Project: Ignite
>  Issue Type: Bug
>  Components: websession
>Affects Versions: 2.1
> Environment: Spring Security, Apache Tomcat
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: easyfix, newbie
> Attachments: IGNITE-6070.patch, webtest.zip
>
>
> See 
> https://stackoverflow.com/questions/45648884/apache-ignite-spring-secutiry-error
>  description.
> When Session comes from Ignite but its Authentication is anonymous, Spring 
> Security does the following check:
> {code}
> } else if (request.getRequestedSessionId() != null && 
> !request.isRequestedSessionIdValid()) {
> this.logger.debug("Requested session ID " + 
> request.getRequestedSessionId() + " is invalid.");
> 
> this.invalidSessionStrategy.onInvalidSessionDetected(request, response);
> }
> {code}
> The problem is, in Ignite we never override isRequestedSessionIdValid() in 
> our request wrappers, so it falls back to Tomcat's own (session) Manager, 
> which will then find that it has never seen this Session and it is therefore 
> invalid. Thus failover is triggered, and if there's "invalid-session-url" 
> clause in Spring Security config, redirect will be issued, possibly circular.
> I've attaching a sample Maven WAR project. It should be deployed to two 
> different Tomcat instances operating on two different ports of same machine, 
> e.g. 8080 and 8180, and then 
> http://localhost:PORT/webtest-1.0-SNAPSHOT/index.jsp should be opened in the 
> same Web Browser one after another for two ports. The second one should cause 
> infinite 302 Redirect to same URL.
> There's also a minor bug in the same code: see session.jsp in the example. It 
> will needlessly throw NPE in WebSessionFilter:1001 and confuse web server. 
> Should output "OK" when fixed.
> Discussion:
> By the way, letting the web server to get hold on Sessions that it creates 
> for us causes additional problems: it's going to store these sessions in 
> parallel with Ignite, consuming memory in the process that first saw a given 
> session. We should probably have (possibly a third party) an Ignite-using 
> Manager implementation for Tomcat specifically. It will be much simpler than 
> filter-based approach while performing better.
> Or maybe we should create our own Sessions that we never allow the web server 
> to see.



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

[jira] [Updated] (IGNITE-5730) .NET: Failed to load ignite.jni.dll when starting up multiple nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5730:
---
Fix Version/s: 2.3

> .NET: Failed to load ignite.jni.dll when starting up multiple nodes
> ---
>
> Key: IGNITE-5730
> URL: https://issues.apache.org/jira/browse/IGNITE-5730
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> When starting multiple nodes at once (with a script of some kind), failure to 
> load unmanaged dll can occur:
> {code}
> set IGNITE_NATIVE_TEST_CLASSPATH=true
> FOR /L %%A IN (1,1,20) DO (
>   start Apache.Ignite.exe
> )
> {code}
> Exception:
> {code}
> ERROR: System.TypeInitializationException: The type initializer for 
> 'Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils' threw an exception. ---> 
> Apache.Ignite.Core.Common.IgniteException: Failed to load ignite.jni.dll: 126
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils..cctor()
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.Initialize()
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.IgniteRunner.Main(String[] args)
> {code}
> Error codes may be 5 (ERROR_ACCESS_DENIED) or 126 (ERROR_MOD_NOT_FOUND).



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

[jira] [Updated] (IGNITE-5898) .NET: Datagrid.QueryDmlExample: Incorrect result if run example with standalone Apache Ignite.NET node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5898:
---
Fix Version/s: 2.3

> .NET: Datagrid.QueryDmlExample: Incorrect result if run example  with 
> standalone Apache Ignite.NET node
> ---
>
> Key: IGNITE-5898
> URL: https://issues.apache.org/jira/browse/IGNITE-5898
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.9, 2.1
>Reporter: Irina Zaporozhtseva
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.3
>
>
> {{Datagrid.QueryDmlExample}}: Incorrect result if run example with standalone 
> Apache Ignite.NET node
> without standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 2: Jane Roe, ASF, 5000
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> {code}
> with standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 3: Mary Major, Eclipse, 2000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 3: Mary Major, Eclipse, 2000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> {code}



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

[jira] [Assigned] (IGNITE-5898) .NET: Datagrid.QueryDmlExample: Incorrect result if run example with standalone Apache Ignite.NET node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-5898:
--

Assignee: Pavel Tupitsyn

> .NET: Datagrid.QueryDmlExample: Incorrect result if run example  with 
> standalone Apache Ignite.NET node
> ---
>
> Key: IGNITE-5898
> URL: https://issues.apache.org/jira/browse/IGNITE-5898
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.9, 2.1
>Reporter: Irina Zaporozhtseva
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.3
>
>
> {{Datagrid.QueryDmlExample}}: Incorrect result if run example with standalone 
> Apache Ignite.NET node
> without standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 2: Jane Roe, ASF, 5000
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> {code}
> with standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 3: Mary Major, Eclipse, 2000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 3: Mary Major, Eclipse, 2000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> {code}



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

[jira] [Updated] (IGNITE-6485) Binary marshaller fails on deserialization of object with writeReplace()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6485:

Fix Version/s: 2.3

> Binary marshaller fails on deserialization of object with writeReplace()
> 
>
> Key: IGNITE-6485
> URL: https://issues.apache.org/jira/browse/IGNITE-6485
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Andrey Gura
>Priority: Critical
> Fix For: 2.3
>
>
> The problem found during testing vertx-ignite project with new version of 
> Vert.x framework.
> Binary marshaller fails on deserialization of object with writeReplace() 
> because deserialized object can't be assigned to field due to a type 
> incompatibility. 
> During setting field value the following checking will be failed in 
> {{UnsafeObjectFieldAccessorImpl.set(Object var1, Object var2)}} method (see 
> comment):
> {code:java}
> public void set(Object var1, Object var2) throws 
> IllegalArgumentException, IllegalAccessException {
> this.ensureObj(var1);
> if (this.isFinal) {
> this.throwFinalFieldIllegalAccessException(var2);
> }
> // HERE: Field type isn't assignable from object type.
> if (var2 != null && 
> !this.field.getType().isAssignableFrom(var2.getClass())) {
> this.throwSetIllegalArgumentException(var2);
> }
> unsafe.putObject(var1, this.fieldOffset, var2);
> }
> {code}
> The following error will be logged:
> {noformat}
> class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize 
> object 
> [typeName=org.apache.ignite.internal.binary.BinaryMarshallerReplaceObjectTest$TestObject]
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:797)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserialize(BinaryObjectImpl.java:639)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshallerReplaceObjectTest.testUnmarshal(BinaryMarshallerReplaceObjectTest.java:35)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to 
> read field [name=val]
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:168)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843)
>   ... 14 more
> Caused by: java.lang.IllegalArgumentException: Can not set 
> org.apache.ignite.internal.binary.BinaryMarshallerReplaceObjectTest$Intf 
> field 
> org.apache.ignite.internal.binary.BinaryMarshallerReplaceObjectTest$TestObject.val
>  to org.apache.ignite.internal.binary.BinaryMarshallerReplaceObjectTest$Cls
>   at 
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
>   at 
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
>   at 
> sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
>   at java.lang.reflect.Field.set(Field.java:741)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:683)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164)
>   ... 15 more
> {noformat}
> Minimal reproducer:
> {code:java}
> package org.apache.ignite.internal.binary;
> import java.io.Serializable;
> import java.util.Arrays;
> import java.util.Collection;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.binary.BinaryIdMapper;
> import org.apache.ignite.binary.BinaryNameMapper;
> 

[jira] [Created] (IGNITE-6505) .NET: Verify output in ExamplesTest

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6505:
--

 Summary: .NET: Verify output in ExamplesTest
 Key: IGNITE-6505
 URL: https://issues.apache.org/jira/browse/IGNITE-6505
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Priority: Minor


{{ExamplesTest}} currently verifies that examples run without exceptions.

Add console output verification to make sure that results are adequate.



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

[jira] [Updated] (IGNITE-6504) Very quick checkpoint can cause AssertionError on next start from LFS

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-6504:
---
Labels: newbie  (was: )

> Very quick checkpoint can cause AssertionError on next start from LFS
> -
>
> Key: IGNITE-6504
> URL: https://issues.apache.org/jira/browse/IGNITE-6504
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>  Labels: newbie
> Fix For: 2.4
>
>
> Checkpoint markers are compared using their timestamps. If checkpoint took 
> less than 1 millisecond, two subsequent markers will have same timestamp, 
> which will lead to error:
> {noformat}
> java.lang.AssertionError: 
> o1=/data/teamcity/tmpfs/work/db/127_0_0_1_47503/cp/1506338145591-c4f23411-e1b1-4468-856a-4419003bba93-END.bin,
>  
> o2=/data/teamcity/tmpfs/work/db/127_0_0_1_47503/cp/1506338145591-f76c023b-9982-40d7-a1eb-855a33b710f2-END.bin
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$4.compare(GridCacheDatabaseSharedManager.java:216)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$4.compare(GridCacheDatabaseSharedManager.java:195)
> at java.util.TimSort.binarySort(TimSort.java:265)
> at java.util.TimSort.sort(TimSort.java:208)
> at java.util.TimSort.sort(TimSort.java:173)
> at java.util.Arrays.sort(Arrays.java:659)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$CheckpointHistory.loadHistory(GridCacheDatabaseSharedManager.java:2704)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$CheckpointHistory.access$2600(GridCacheDatabaseSharedManager.java:2685)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1468)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:562)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:722)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:613)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2289)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Created] (IGNITE-6504) Very quick checkpoint can cause AssertionError on next start from LFS

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-6504:
--

 Summary: Very quick checkpoint can cause AssertionError on next 
start from LFS
 Key: IGNITE-6504
 URL: https://issues.apache.org/jira/browse/IGNITE-6504
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.1
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.4


Checkpoint markers are compared using their timestamps. If checkpoint took less 
than 1 millisecond, two subsequent markers will have same timestamp, which will 
lead to error:
{noformat}
java.lang.AssertionError: 
o1=/data/teamcity/tmpfs/work/db/127_0_0_1_47503/cp/1506338145591-c4f23411-e1b1-4468-856a-4419003bba93-END.bin,
 
o2=/data/teamcity/tmpfs/work/db/127_0_0_1_47503/cp/1506338145591-f76c023b-9982-40d7-a1eb-855a33b710f2-END.bin
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$4.compare(GridCacheDatabaseSharedManager.java:216)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$4.compare(GridCacheDatabaseSharedManager.java:195)
at java.util.TimSort.binarySort(TimSort.java:265)
at java.util.TimSort.sort(TimSort.java:208)
at java.util.TimSort.sort(TimSort.java:173)
at java.util.Arrays.sort(Arrays.java:659)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$CheckpointHistory.loadHistory(GridCacheDatabaseSharedManager.java:2704)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$CheckpointHistory.access$2600(GridCacheDatabaseSharedManager.java:2685)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1468)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:562)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:722)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:613)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2289)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{noformat}



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

[jira] [Commented] (IGNITE-5730) .NET: Failed to load ignite.jni.dll when starting up multiple nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5730:


Done, waiting for TeamCity.

> .NET: Failed to load ignite.jni.dll when starting up multiple nodes
> ---
>
> Key: IGNITE-5730
> URL: https://issues.apache.org/jira/browse/IGNITE-5730
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> When starting multiple nodes at once (with a script of some kind), failure to 
> load unmanaged dll can occur:
> {code}
> set IGNITE_NATIVE_TEST_CLASSPATH=true
> FOR /L %%A IN (1,1,20) DO (
>   start Apache.Ignite.exe
> )
> {code}
> Exception:
> {code}
> ERROR: System.TypeInitializationException: The type initializer for 
> 'Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils' threw an exception. ---> 
> Apache.Ignite.Core.Common.IgniteException: Failed to load ignite.jni.dll: 126
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils..cctor()
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.Initialize()
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.IgniteRunner.Main(String[] args)
> {code}
> Error codes may be 5 (ERROR_ACCESS_DENIED) or 126 (ERROR_MOD_NOT_FOUND).



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

[jira] [Comment Edited] (IGNITE-5439) JDBC thin: support query cancel

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-5439 at 9/26/17 3:12 PM:
---

[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2436%2Fhead]
 are OK with me.
[~vozerov], [~skalashnikov], please review the patch.


was (Author: tledkov-gridgain):
[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2436%2Fhead]
 are OK with me.
[~vozerov], please review the patch.

> 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] [Updated] (IGNITE-5730) .NET: Failed to load ignite.jni.dll when starting up multiple nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5730:
---
Description: 
When starting multiple nodes at once (with a script of some kind), failure to 
load unmanaged dll can occur:

{code}
set IGNITE_NATIVE_TEST_CLASSPATH=true

FOR /L %%A IN (1,1,20) DO (
  start Apache.Ignite.exe
)
{code}

Exception:
{code}
ERROR: System.TypeInitializationException: The type initializer for 
'Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils' threw an exception. ---> 
Apache.Ignite.Core.Common.IgniteException: Failed to load ignite.jni.dll: 126
   at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils..cctor()
   --- End of inner exception stack trace ---
   at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.Initialize()
   at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
ILogger log)
   at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
   at Apache.Ignite.IgniteRunner.Main(String[] args)
{code}

Error codes may be 5 (ERROR_ACCESS_DENIED) or 126 (ERROR_MOD_NOT_FOUND).

  was:
When starting multiple nodes at once (with a script of some kind), failure to 
load unmanaged dll can occur:

{code}
for (int i = 0; i < 30; i++)
{
Process.Start(@"cmd.exe", @"/k Apache.Ignite.exe");
}
{code}

Exception:
{code}
ERROR: System.TypeInitializationException: The type initializer for 
'Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils' threw an exception. ---> 
Apache.Ignite.Core.Common.IgniteException: Failed to load ignite.jni.dll: 126
   at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils..cctor()
   --- End of inner exception stack trace ---
   at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.Initialize()
   at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
ILogger log)
   at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
   at Apache.Ignite.IgniteRunner.Main(String[] args)
{code}

Error codes may be 5 (ERROR_ACCESS_DENIED) or 126 (ERROR_MOD_NOT_FOUND).


> .NET: Failed to load ignite.jni.dll when starting up multiple nodes
> ---
>
> Key: IGNITE-5730
> URL: https://issues.apache.org/jira/browse/IGNITE-5730
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> When starting multiple nodes at once (with a script of some kind), failure to 
> load unmanaged dll can occur:
> {code}
> set IGNITE_NATIVE_TEST_CLASSPATH=true
> FOR /L %%A IN (1,1,20) DO (
>   start Apache.Ignite.exe
> )
> {code}
> Exception:
> {code}
> ERROR: System.TypeInitializationException: The type initializer for 
> 'Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils' threw an exception. ---> 
> Apache.Ignite.Core.Common.IgniteException: Failed to load ignite.jni.dll: 126
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils..cctor()
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.Initialize()
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.IgniteRunner.Main(String[] args)
> {code}
> Error codes may be 5 (ERROR_ACCESS_DENIED) or 126 (ERROR_MOD_NOT_FOUND).



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

[jira] [Comment Edited] (IGNITE-5439) JDBC thin: support query cancel

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-5439 at 9/26/17 3:12 PM:
---

[Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2436%2Fhead]
 are OK with me.
[~vozerov], please review the patch.


was (Author: tledkov-gridgain):
Waits for [Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2436%2Fhead].

> 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-5730) .NET: Failed to load ignite.jni.dll when starting up multiple nodes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5730:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-5730 .NET: Fix ignite.jni.dll temp dir race



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

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

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

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


commit f184776f8ee89fa365db08569714eb2e5b04ec63
Author: Pavel Tupitsyn 
Date:   2017-09-26T14:49:19Z

IGNITE-5730 .NET: Fix ignite.jni.dll temp dir race




> .NET: Failed to load ignite.jni.dll when starting up multiple nodes
> ---
>
> Key: IGNITE-5730
> URL: https://issues.apache.org/jira/browse/IGNITE-5730
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> When starting multiple nodes at once (with a script of some kind), failure to 
> load unmanaged dll can occur:
> {code}
> for (int i = 0; i < 30; i++)
> {
>   Process.Start(@"cmd.exe", @"/k Apache.Ignite.exe");
> }
> {code}
> Exception:
> {code}
> ERROR: System.TypeInitializationException: The type initializer for 
> 'Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils' threw an exception. ---> 
> Apache.Ignite.Core.Common.IgniteException: Failed to load ignite.jni.dll: 126
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils..cctor()
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.Initialize()
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.IgniteRunner.Main(String[] args)
> {code}
> Error codes may be 5 (ERROR_ACCESS_DENIED) or 126 (ERROR_MOD_NOT_FOUND).



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

[jira] [Updated] (IGNITE-6477) Add cache index metric to represent index size

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6477:

Fix Version/s: (was: 2.2)
   2.3

> Add cache index metric to represent index size
> --
>
> Key: IGNITE-6477
> URL: https://issues.apache.org/jira/browse/IGNITE-6477
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8, 1.9, 2.0, 2.1
>Reporter: Alexander Belyak
>Priority: Minor
>
> Now we can't estimate space used by particular cache index. Let's add it!



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

[jira] [Updated] (IGNITE-6477) Add cache index metric to represent index size

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6477:

Fix Version/s: (was: 2.3)

> Add cache index metric to represent index size
> --
>
> Key: IGNITE-6477
> URL: https://issues.apache.org/jira/browse/IGNITE-6477
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8, 1.9, 2.0, 2.1
>Reporter: Alexander Belyak
>Priority: Minor
>
> Now we can't estimate space used by particular cache index. Let's add it!



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

[jira] [Updated] (IGNITE-6226) Review docs for integration with Apache Zeppelin

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6226:

Fix Version/s: (was: 2.2)
   2.3

> Review docs for integration with Apache Zeppelin
> 
>
> Key: IGNITE-6226
> URL: https://issues.apache.org/jira/browse/IGNITE-6226
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Ilya Suntsov
>Assignee: Ilya Suntsov
> Fix For: 2.3
>
>
> Now we have non actual documentation for Apache Zeppelin integration: 
> https://apacheignite.readme.io/v1.1/docs/data-analysis-with-apache-zeppelin?edits=true



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

[jira] [Updated] (IGNITE-4591) File interop_target.h is missing from source-release

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4591:

Fix Version/s: (was: 2.2)
   2.3

> File interop_target.h is missing from source-release
> 
>
> Key: IGNITE-4591
> URL: https://issues.apache.org/jira/browse/IGNITE-4591
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Ilya Suntsov
>  Labels: cpp
> Fix For: 2.3
>
>
> File 
> {{modules\platforms\cpp\core\include\ignite\impl\interop\interop_target.h}} 
> missing from source releases of versions 1.7.0 and 1.8.0. It is present, 
> however, in repository and binary releases.



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

[jira] [Updated] (IGNITE-5817) Change checksum calculation methods

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5817:

Fix Version/s: 2.2

> 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
> 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-6360) NPE occurs if object with null indexed field is added

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov updated IGNITE-6360:
--
Component/s: sql

> NPE occurs if object with null indexed field is added
> -
>
> Key: IGNITE-6360
> URL: https://issues.apache.org/jira/browse/IGNITE-6360
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
> Environment: NPE occurs if object with null indexed field is added
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
> Fix For: 2.3
>
>




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

[jira] [Updated] (IGNITE-6238) Fix GridClosureProcessorRemoteTest, add it to suite

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6238:

Fix Version/s: 2.3

> Fix GridClosureProcessorRemoteTest, add it to suite
> ---
>
> Key: IGNITE-6238
> URL: https://issues.apache.org/jira/browse/IGNITE-6238
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Trivial
> Fix For: 2.3
>
>
> It seems that it got lost and suffered from bit rot.



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

[jira] [Assigned] (IGNITE-5730) .NET: Failed to load ignite.jni.dll when starting up multiple nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-5730:
--

Assignee: Pavel Tupitsyn

> .NET: Failed to load ignite.jni.dll when starting up multiple nodes
> ---
>
> Key: IGNITE-5730
> URL: https://issues.apache.org/jira/browse/IGNITE-5730
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> When starting multiple nodes at once (with a script of some kind), failure to 
> load unmanaged dll can occur:
> {code}
> for (int i = 0; i < 30; i++)
> {
>   Process.Start(@"cmd.exe", @"/k Apache.Ignite.exe");
> }
> {code}
> Exception:
> {code}
> ERROR: System.TypeInitializationException: The type initializer for 
> 'Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils' threw an exception. ---> 
> Apache.Ignite.Core.Common.IgniteException: Failed to load ignite.jni.dll: 126
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils..cctor()
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.Initialize()
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.IgniteRunner.Main(String[] args)
> {code}
> Error codes may be 5 (ERROR_ACCESS_DENIED) or 126 (ERROR_MOD_NOT_FOUND).



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

[jira] [Commented] (IGNITE-5615) .NET: IgniteConfiguration.LocalEventListeners

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5615:


Done, including unsubscription. [~vozerov] please have a look.

> .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-5439) JDBC thin: support query cancel

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-5439:
--

Waits for [Tests 
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2436%2Fhead].

> 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-5615) .NET: IgniteConfiguration.LocalEventListeners

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5615:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-5615 .NET: IgniteConfiguration.LocalEventListeners



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

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

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

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


commit 30232dbdb8317122cf46a3ef7560564085efd04a
Author: Pavel Tupitsyn 
Date:   2017-09-26T14:26:01Z

IGNITE-5615 .NET: IgniteConfiguration.LocalEventListeners




> .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-6030) Allow enabling persistence per-cache

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6030:


Replied to dev-list 
http://apache-ignite-developers.2346864.n4.nabble.com/Persistence-per-memory-policy-configuration-td22018.html

> 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
> 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] [Commented] (IGNITE-5730) .NET: Failed to load ignite.jni.dll when starting up multiple nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5730:


Simple solution is to check directory creation time and do not remove recently 
created ones.

> .NET: Failed to load ignite.jni.dll when starting up multiple nodes
> ---
>
> Key: IGNITE-5730
> URL: https://issues.apache.org/jira/browse/IGNITE-5730
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>  Labels: .NET
>
> When starting multiple nodes at once (with a script of some kind), failure to 
> load unmanaged dll can occur:
> {code}
> for (int i = 0; i < 30; i++)
> {
>   Process.Start(@"cmd.exe", @"/k Apache.Ignite.exe");
> }
> {code}
> Exception:
> {code}
> ERROR: System.TypeInitializationException: The type initializer for 
> 'Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils' threw an exception. ---> 
> Apache.Ignite.Core.Common.IgniteException: Failed to load ignite.jni.dll: 126
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils..cctor()
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.Initialize()
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.IgniteRunner.Main(String[] args)
> {code}
> Error codes may be 5 (ERROR_ACCESS_DENIED) or 126 (ERROR_MOD_NOT_FOUND).



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

[jira] [Resolved] (IGNITE-6491) Race in TopologyValidator.validate() and EVT_NODE_LEFT listener calls (split-brain activator)

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov resolved IGNITE-6491.
---
   Resolution: Fixed
Fix Version/s: (was: 2.2)
   2.3

> Race in TopologyValidator.validate() and EVT_NODE_LEFT listener calls 
> (split-brain activator)
> -
>
> Key: IGNITE-6491
> URL: https://issues.apache.org/jira/browse/IGNITE-6491
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 2.1
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
> Fix For: 2.3
>
>
> The following wrong cache {{validate}}/{{put}} sequence may occur
> On node left {{GridDhtPartitionsExchangeFuture}} will be generated by the 
> {{disco-event-worker}} thread.
> Then the {{exchange-worker}} thread does
> {noformat}
> Split-brain detected [cacheName=test40, activatorTopVer=0, cacheTopVer=14]
>   at 
> org.apache.ignite.internal.util.IgniteUtils.dumpStack(IgniteUtils.java:1141)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest$SplitAwareTopologyValidator.validate(IgniteTopologyValidatorGridSplitCacheTest.java:307)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCacheGroup(GridDhtTopologyFutureAdapter.java:64)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1456)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:115)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:668)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2278)
> {noformat}
> The result of validation is stored in {{grpValidRes}} with value of {{false}}.
> After some delay the {{disco-event-worker}} thread will do
> {noformat}
> java.lang.Exception: Node is segment activator [cacheName=test40, 
> activatorTopVer=14]
>   at 
> org.apache.ignite.internal.util.IgniteUtils.dumpStack(IgniteUtils.java:1141)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest$SplitAwareTopologyValidator$2.apply(IgniteTopologyValidatorGridSplitCacheTest.java:360)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest$SplitAwareTopologyValidator$2.apply(IgniteTopologyValidatorGridSplitCacheTest.java:349)
>   at 
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$UserListenerWrapper.onEvent(GridEventStorageManager.java:1463)
>   at 
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:859)
>   at 
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:844)
>   at 
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:341)
>   at 
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:307)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:2478)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:2684)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:2507)
> {noformat}
> After this invocation the result of {{SplitAwareTopologyValidator.validate}} 
> should be changed to {{true}}, but it was already invoked and the result has 
> been cached in {{grpValidRes}} with the value of {{false}}.
> So any successive calls to {{cache.put}} causes to fail
> {noformat}
> Test failed.
> java.lang.RuntimeException: tryPut() failed 
> [gridName=cache.IgniteTopologyValidatorGridSplitCacheTest0]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:262)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidator(IgniteTopologyValidatorGridSplitCacheTest.java:182)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 

[jira] [Assigned] (IGNITE-6043) Fix GridCacheSemaphoreImpl methods semantics

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6043:


Assignee: Andrey Kuznetsov

> Fix GridCacheSemaphoreImpl methods semantics
> 
>
> Key: IGNITE-6043
> URL: https://issues.apache.org/jira/browse/IGNITE-6043
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Critical
>
> Current semaphore implementation, {{GridCacheSemaphoreImpl}}, has inverted 
> method semantics: {{acquire()}} releases the permit and {{release()}} 
> acquires it. Also, debug-level method {{availablePermits()}} returns permits 
> acquired so far. This confusing behaviour should be fixed.
> Also, it's worth noting in IgniteSemaphore's javadoc its unbounded nature, as 
> opposed to {{java.util.concurrent.Semaphore}}.



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

[jira] [Updated] (IGNITE-6343) Index is not used properly if changing sort order.

[Vladimir Ozerov (JIRA)]

 [ 
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: 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
> Fix For: 2.3
>
>
> 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);
> 

[jira] [Updated] (IGNITE-6070) Infinite redirects at Spring Security Web Session Clustering with Tomcat

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6070:

Fix Version/s: 2.3

> Infinite redirects at Spring Security Web Session Clustering with Tomcat
> 
>
> Key: IGNITE-6070
> URL: https://issues.apache.org/jira/browse/IGNITE-6070
> Project: Ignite
>  Issue Type: Bug
>  Components: websession
>Affects Versions: 2.1
> Environment: Spring Security, Apache Tomcat
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: easyfix, newbie
> Fix For: 2.3
>
> Attachments: IGNITE-6070.patch, webtest.zip
>
>
> See 
> https://stackoverflow.com/questions/45648884/apache-ignite-spring-secutiry-error
>  description.
> When Session comes from Ignite but its Authentication is anonymous, Spring 
> Security does the following check:
> {code}
> } else if (request.getRequestedSessionId() != null && 
> !request.isRequestedSessionIdValid()) {
> this.logger.debug("Requested session ID " + 
> request.getRequestedSessionId() + " is invalid.");
> 
> this.invalidSessionStrategy.onInvalidSessionDetected(request, response);
> }
> {code}
> The problem is, in Ignite we never override isRequestedSessionIdValid() in 
> our request wrappers, so it falls back to Tomcat's own (session) Manager, 
> which will then find that it has never seen this Session and it is therefore 
> invalid. Thus failover is triggered, and if there's "invalid-session-url" 
> clause in Spring Security config, redirect will be issued, possibly circular.
> I've attaching a sample Maven WAR project. It should be deployed to two 
> different Tomcat instances operating on two different ports of same machine, 
> e.g. 8080 and 8180, and then 
> http://localhost:PORT/webtest-1.0-SNAPSHOT/index.jsp should be opened in the 
> same Web Browser one after another for two ports. The second one should cause 
> infinite 302 Redirect to same URL.
> There's also a minor bug in the same code: see session.jsp in the example. It 
> will needlessly throw NPE in WebSessionFilter:1001 and confuse web server. 
> Should output "OK" when fixed.
> Discussion:
> By the way, letting the web server to get hold on Sessions that it creates 
> for us causes additional problems: it's going to store these sessions in 
> parallel with Ignite, consuming memory in the process that first saw a given 
> session. We should probably have (possibly a third party) an Ignite-using 
> Manager implementation for Tomcat specifically. It will be much simpler than 
> filter-based approach while performing better.
> Or maybe we should create our own Sessions that we never allow the web server 
> to see.



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

[jira] [Updated] (IGNITE-6184) No checkClusterState() in IgniteKernal.getOrCreateCaches()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6184:

Fix Version/s: 2.3

> No checkClusterState() in IgniteKernal.getOrCreateCaches()
> --
>
> Key: IGNITE-6184
> URL: https://issues.apache.org/jira/browse/IGNITE-6184
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
> Fix For: 2.3
>
>
> Check if anything else is off, too.



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

[jira] [Commented] (IGNITE-6285) Enhance persistent store paths logging on start

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6285:


GitHub user dspavlov opened a pull request:

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

IGNITE-6285: Enhance persistent store paths logging on start

Experimental commits to run TC tests, do not merge

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

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

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

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


commit b150519f05c99e71be83af9d5107ae599c90f05f
Author: dpavlov 
Date:   2017-09-26T13:31:54Z

IGNITE-6285: Enhance persistent store paths logging on start




> 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: 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] [Updated] (IGNITE-3306) Extend IgniteCluster interface with the methods to send and receive custom discovery events

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3306:

Fix Version/s: (was: 2.3)

> Extend IgniteCluster interface with the methods to send and receive custom 
> discovery events
> ---
>
> Key: IGNITE-3306
> URL: https://issues.apache.org/jira/browse/IGNITE-3306
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Andrey Kornev
>Assignee: Yakov Zhdanov
>
> {{GridDiscoveryManager}} already provides the methods for sending/receiving 
> custom discovery messages: {{GridDiscoveryManager.sendCustomEvent(...)}} and 
> {{GridDiscoveryManager.setCustomEventListener(...)}} methods correspondingly. 
> This API is very powerful as it provides reliable delivery guarantees that 
> are totally ordered with respect to the rest of discovery events. It's 
> essential for implementing so-called view-synchronous group communication 
> primitives.
> Unfortunately, {{GridDiscoveryManager}} is not part of the public API. 
> This ticket proposes to extend {{IgniteCluster}} interface to expose those 
> methods. {{DiscoveryCustomMessage}} class should also be moved out of the 
> {{internal}} package to a public package.



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

[jira] [Updated] (IGNITE-4152) Make ignite-shmem lib optional

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4152:

Fix Version/s: (was: 2.3)

> Make ignite-shmem lib optional
> --
>
> Key: IGNITE-4152
> URL: https://issues.apache.org/jira/browse/IGNITE-4152
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Denis Magda
>Assignee: Denis Magda
>
> Presently, if someone starts up a cluster and has at least two nodes running 
> on a single Unix machine then those nodes will be communicating over the 
> shared memory (shmem) by default.
> This approach sounds absolutely reasonable but the shmem library is not ideal 
> at the moment. There are many situations when a cluster may hang in the 
> production or during long running tests due to some unclear issues in shmem 
> internals. Even from Ignite community side we have the following shmem 
> related issues 
> https://issues.apache.org/jira/browse/IGNITE-1578
> https://issues.apache.org/jira/browse/IGNITE-1294
> Let's make the shmem lib optional by putting it into 
> "{{ignite-release/libs/optional}}" folder and removing any explicit reference 
> we may have in a pom.xml file.
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Making-Ignite-shmem-library-optional-td11874.html



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

[jira] [Updated] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2422:

Fix Version/s: (was: 2.3)

> Unable to deserialize BinaryObjectBuilder
> -
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead 
> to the errors at deserialization stage.
> After a brief investigation I see that this happens because neither 
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}} 
> presents in {{META-INF/classnames.properties}} file.
> If you try to update 
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by 
> building the project from scratch and copying-pasting generated content from 
> built {{classnames.properties}}, then you will still see that there are still 
> no entries for  {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes 
> by some reason.



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

[jira] [Updated] (IGNITE-5704) Do not allow cluster to be deactivated if the joining node does not complete start all components

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5704:

Fix Version/s: (was: 2.3)

> Do not allow cluster to be deactivated if the joining node does not complete 
> start all components
> -
>
> Key: IGNITE-5704
> URL: https://issues.apache.org/jira/browse/IGNITE-5704
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>
> Potential problem, if we deactivate cluster during node join, we can get 
> various  exception because all component is not finished initialization.



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

[jira] [Updated] (IGNITE-6439) IgnitePersistentStoreSchemaLoadTest is broken

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6439:

Fix Version/s: (was: 2.3)

> IgnitePersistentStoreSchemaLoadTest is broken
> -
>
> Key: IGNITE-6439
> URL: https://issues.apache.org/jira/browse/IGNITE-6439
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>  Labels: MakeTeamcityGreenAgain
>
> After start nodes, cluster must be activated explicit.



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

[jira] [Updated] (IGNITE-5759) IgniteCache5 suite timed out by GridCachePartitionEvictionDuringReadThroughSelfTest.testPartitionRent

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5759:

Fix Version/s: (was: 2.3)

> IgniteCache5 suite timed out by 
> GridCachePartitionEvictionDuringReadThroughSelfTest.testPartitionRent
> -
>
> Key: IGNITE-5759
> URL: https://issues.apache.org/jira/browse/IGNITE-5759
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, test-fail
> Attachments: threadDumpFromLogs.log
>
>
> http://ci.ignite.apache.org/viewLog.html?buildId=727951=Ignite20Tests_IgniteCache5
> There is no 'Test has been timed out' message in logs.
> Last 'Starting test:' message was 
> GridCachePartitionEvictionDuringReadThroughSelfTest#testPartitionRent
> Latest exception from working test was as follows;
> {noformat}
> [23:19:11]W:   [org.apache.ignite:ignite-core] [2017-07-14 
> 20:19:11,392][ERROR][tcp-comm-worker-#8980%distributed.GridCachePartitionEvictionDuringReadThroughSelfTest4%][TcpCommunicationSpi]
>  TcpCommunicationSpi failed to establish connection to node, node will be 
> dropped from cluster [rmtNode=TcpDiscoveryNode 
> [id=a93fce57-6b2d-4947-8c23-8a677b93, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1500063443391, loc=false, ver=2.1.0#19700101-sha1:, 
> isClient=false]]
> [23:19:11]W:   [org.apache.ignite:ignite-core] class 
> org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node 
> still alive?). Make sure that each ComputeTask and cache Transaction has a 
> timeout set in order to prevent parties from waiting forever in case of 
> network issues [nodeId=a93fce57-6b2d-4947-8c23-8a677b93, 
> addrs=[/127.0.0.1:45273]]
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3173)
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2757)
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2649)
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5900(TcpCommunicationSpi.java:245)
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:4065)
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3891)
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [23:19:11]W:   [org.apache.ignite:ignite-core]Suppressed: 
> class org.apache.ignite.IgniteCheckedException: Failed to connect to address 
> [addr=/127.0.0.1:45273, err=Connection refused]
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3178)
> [23:19:11]W:   [org.apache.ignite:ignite-core]... 6 
> more
> [23:19:11]W:   [org.apache.ignite:ignite-core]Caused by: 
> java.net.ConnectException: Connection refused
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:117)
> [23:19:11]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3024)
> [23:19:11]W:   [org.apache.ignite:ignite-core]... 6 
> more
> {noformat}
> and then
> {noformat}
> [23:19:11]W:   [org.apache.ignite:ignite-core] [2017-07-14 
> 20:19:11,895][WARN ][main][root] Interrupting threads started so far: 5
> [23:19:11] :   [Step 4/5] [2017-07-14 20:19:11,895][INFO ][main][root] >>> 
> Stopping test class: GridCachePartitionEvictionDuringReadThroughSelfTest <<<
> [23:19:11]W:   

[jira] [Updated] (IGNITE-4930) Try to move free lists into a tread-local structure to avoid contention

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4930:

Fix Version/s: (was: 2.3)

> Try to move free lists into a tread-local structure to avoid contention
> ---
>
> Key: IGNITE-4930
> URL: https://issues.apache.org/jira/browse/IGNITE-4930
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>




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

[jira] [Updated] (IGNITE-2176) Not valid exceptions in case when example can't works with remote node started with server classpath (Java 8)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2176:

Fix Version/s: (was: 2.3)

> Not valid exceptions in case when example can't works with remote node 
> started with server classpath (Java 8)
> -
>
> Key: IGNITE-2176
> URL: https://issues.apache.org/jira/browse/IGNITE-2176
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
> Environment: jdk 1.7
> OS X 10.10.2
>Reporter: Ilya Suntsov
>Assignee: Yakov Zhdanov
>Priority: Critical
>
> Steps for reproduce:
> 1. Start one node from IDEA and one more from terminal
> 2. Run StreamVisitorExample (Java 8):
> Exception:
> {noformat}
> Exception in thread "pub-#2%null%" class 
> org.apache.ignite.binary.BinaryInvalidTypeException: 
> org.apache.ignite.examples.java8.streaming.StreamVisitorExample
>   at 
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:467)
>   at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1330)
>   at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1284)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readClass(BinaryReaderExImpl.java:339)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:835)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:645)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:696)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1646)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:645)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:696)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:267)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal(BinaryMarshaller.java:112)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:271)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:49)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:76)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:819)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:782)
>   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: java.lang.ClassNotFoundException: 
> org.apache.ignite.examples.java8.streaming.StreamVisitorExample
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:348)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8172)
>   at 
> org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:185)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:458)
>   ... 22 more
> {noformat}
> 3. Run StreamTransformerExample (Java 8)
> Exception:
> {noformat}
> Exception in thread "pub-#2%null%" class 
> org.apache.ignite.binary.BinaryInvalidTypeException: 
> org.apache.ignite.examples.java8.streaming.StreamTransformerExample
>   at 
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:467)
>   at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1330)
>   at 
> 

[jira] [Updated] (IGNITE-6097) GridCacheDatabaseSharedManager.restorePartitionState(...) should not access PageMemory directly

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6097:

Fix Version/s: (was: 2.3)

> GridCacheDatabaseSharedManager.restorePartitionState(...) should not access 
> PageMemory directly
> ---
>
> Key: IGNITE-6097
> URL: https://issues.apache.org/jira/browse/IGNITE-6097
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>
> It breaks encapsulation and leads to subtle non-trivial problems (like 
> deadlock in IGNITE-6096). We should update state by calling methods of 
> GridDhtLocalPartition instead.



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

[jira] [Updated] (IGNITE-6422) In visorcmd "cache on nodes" statistics mixes together primary and backup entries

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6422:

Fix Version/s: (was: 2.3)

> 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: Vasiliy Sisko
>
> 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   |
> ++
> {code}
> NB: It might be feasible to keep 

[jira] [Updated] (IGNITE-6452) Invocation of getAll() through cache proxy during cache restart can throw unexpected CacheException

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6452:

Fix Version/s: (was: 2.3)

> Invocation of getAll() through cache proxy during cache restart can throw 
> unexpected CacheException
> ---
>
> Key: IGNITE-6452
> URL: https://issues.apache.org/jira/browse/IGNITE-6452
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>  Labels: MakeTeamcityGreenAgain
>
> Instead of expected IgniteCacheRestartingException, load test shows the 
> following exception sometimes:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
> Failed to find message handler for message: GridNearGetRequest 
> [futId=6fc73459e51-84b93e3c-47e1-433c-8a91-0700f131c617, 
> miniId=27d73459e51-84b93e3c-47e1-433c-8a91-0700f131c617, ver=null, 
> keyMap=null, flags=1, topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=32], subjId=080177d4-b78e-4f6f-a386-77be8830, taskNameHash=0, 
> createTtl=-1, accessTtl=-1]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1285)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1648)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAll(IgniteCacheProxyImpl.java:873)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAll(GatewayProtectedCacheProxy.java:718)
>   at 
> org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest$15.apply(IgniteDbSnapshotSelfTest.java:1911)
>   at 
> org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest$15.apply(IgniteDbSnapshotSelfTest.java:1904)
>   at 
> org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotSelfTest.testReuseCacheProxyAfterRestore(IgniteDbSnapshotSelfTest.java:1796)
>   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 junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Assigned] (IGNITE-6216) .NET: Add CheckpointWriteOrder enum in persistent store configuration

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6216:
---

Assignee: Pavel Tupitsyn

> .NET: Add CheckpointWriteOrder enum in persistent store configuration
> -
>
> Key: IGNITE-6216
> URL: https://issues.apache.org/jira/browse/IGNITE-6216
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Pavel Tupitsyn
>  Labels: .NET, MakeTeamcityGreenAgain, usability
> Fix For: 2.3
>
>
> Since 2.2 we have CheckpointWriteOrder property in 
> PersistentStoreConfiguration. It should be possible to set through .NET 
> configuration classes.
> Default value should be CheckpointWriteOrder#SEQUENTIAL.



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

[jira] [Updated] (IGNITE-5644) Metrics collection must be removed from discovery thread.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5644:

Fix Version/s: (was: 2.3)

> Metrics collection must be removed from discovery thread.
> -
>
> Key: IGNITE-5644
> URL: https://issues.apache.org/jira/browse/IGNITE-5644
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
>
> Cache metrics are copied in discovery worker threads. This looks a bit risky 
> because in case of metrics collection may stall the whole cluster. We need to 
> make sure that when the heartbeat message is processed, we already have a 
> metrics snapshot enabled



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

[jira] [Updated] (IGNITE-5594) Ignite test framework intervenes into configuration of Ignite node internal components

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5594:

Fix Version/s: (was: 2.3)

> Ignite test framework intervenes into configuration of Ignite node internal 
> components
> --
>
> Key: IGNITE-5594
> URL: https://issues.apache.org/jira/browse/IGNITE-5594
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>
> h2. Notes
> Class *IgniteTestResources* participates in configuring ignite nodes managed 
> by test framework and makes some configurations which may mask real issues 
> with configuring nodes IRL.
> E.g. jUnit test supposed to reproduce some issue passes but the real problem 
> isn't fixed.
> h2. Acceptance Criteria
> # Malicious configuration actions are cleaned up from *IgniteTestResources*.
> # No new test failures are introduced by this change.



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

[jira] [Updated] (IGNITE-5265) Eviction Rate memory metric to be implemented

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5265:

Fix Version/s: (was: 2.3)

> Eviction Rate memory metric to be implemented
> -
>
> Key: IGNITE-5265
> URL: https://issues.apache.org/jira/browse/IGNITE-5265
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Sergey Chugunov
>Assignee: Ivan Rakov
>
> Eviction rate metric is declared on *MemoryMetrics* interface but isn't 
> implemented in *MemoryMetricsImpl* (current implementation returns 0 right 
> away).
> This metric must be implemented identically to *allocationRate* metric from 
> the same interface (algorithm for *allocationRate* can be reused with minor 
> refactoring).



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

[jira] [Updated] (IGNITE-2693) withKeepBinary and non-binary marshallers

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2693:

Fix Version/s: (was: 2.3)

> withKeepBinary and non-binary marshallers
> -
>
> Key: IGNITE-2693
> URL: https://issues.apache.org/jira/browse/IGNITE-2693
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Sergey Kozlov
>Assignee: Oddo
>  Labels: newbie
>
> Currently the user is able to set {{.withKeepBinary()}} for any used 
> marshaller. But it obviously causes ClassCastException for non-binary 
> marshallers and should be available only for binary marshaller.



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

[jira] [Updated] (IGNITE-5910) Method stopGrid(name) doesn't work in multiJvm mode

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5910:

Fix Version/s: (was: 2.3)

> Method stopGrid(name) doesn't work in multiJvm mode
> ---
>
> Key: IGNITE-5910
> URL: https://issues.apache.org/jira/browse/IGNITE-5910
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>
> {code:title=Exception at call}
> java.lang.ClassCastException: 
> org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy cannot be 
> cast to org.apache.ignite.internal.IgniteKernal
> {code}
> {code:title=Reproducer snippet}
> /** {@inheritDoc} */
> @Override protected boolean isMultiJvm() {
> return true;
> }
> /**
>  * @throws Exception If failed.
>  */
> public void testGrid() throws Exception {
> try {
> startGrid(0);
> startGrid(1);
> }
> finally {
> stopGrid(1);
> stopGrid(0);
> }
> }
> {code}



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

[jira] [Commented] (IGNITE-6286) org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters

[Sergey Chernolyas (JIRA)]

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

Sergey Chernolyas commented on IGNITE-6286:
---

Hi [~al.psc]

I recreated my PR. Please see https://github.com/apache/ignite/pull/2750 .
I fixed your comments N 1, 2 and 4 (If I understood you correctly).

About comment N3.
The test do same that do Hibernate OGM for Ignite. I mean that JPA Entity not 
uses annotation '@QuerySqlField' . Can I remain as is?



> org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>  Labels: usability
> Fix For: 2.3
>
>
> Binding values  of some types to parameterized queries leads to the exception 
>  (see fill stacktrace in comments).
> Also, the exception *blocks* using parameterized queries for Hibernate OGM.
> I proceed the exception for String type. For control it, I developed test ( 
> see 
> org.apache.ignite.internal.processors.query.IgniteSqlParameterizedQueryTest)  
> .  
> The exception reproduced for BigDecimal type in 2.3-snapshot.



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

[jira] [Updated] (IGNITE-4683) Need to avoid extra-copy to byte array when marshalling to cache object (e.g. return ByteBuffer)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4683:

Fix Version/s: (was: 2.3)

> Need to avoid extra-copy to byte array when marshalling to cache object (e.g. 
> return ByteBuffer)
> 
>
> Key: IGNITE-4683
> URL: https://issues.apache.org/jira/browse/IGNITE-4683
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
>
> Now, when Ignite marshals to cache object it marshals to byte array and then 
> strips the byte array to return array of exact size. In most cases marshalled 
> objects are sent via network or copied to offheap, so last step with copying 
> data to a new array is not needed.
> # We can add overload for marshalling methods to return ByteBuffer. 
> # Probably, we will need some new CacheObject implementations to wrap 
> ByteBuffer.
> # We will need to add support for ByteBuffers to direct marshaller



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

[jira] [Updated] (IGNITE-5059) Implement logistic regression

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5059:

Fix Version/s: (was: 2.3)

> Implement logistic regression 
> --
>
> Key: IGNITE-5059
> URL: https://issues.apache.org/jira/browse/IGNITE-5059
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Vladisav Jelisavcic
>Assignee: Vladisav Jelisavcic
>  Labels: important
>
> Implement logistic regression using ignite ml.math. Model should be able to 
> incorporate L1 and L2 regularization. 
> Model should also work with stochastic gradient descent (SGD) as well as 
> batch and mini-batch gradient descent optimization algorithms.  



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

[jira] [Updated] (IGNITE-6425) Races during transaction finalization

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6425:

Fix Version/s: (was: 2.3)

> Races during transaction finalization
> -
>
> Key: IGNITE-6425
> URL: https://issues.apache.org/jira/browse/IGNITE-6425
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Critical
>
> I have found during stress-test (start-stop nodes during transactions 
> running):
> {code}
> [2017-09-20 12:37:04,224][ERROR][updater-1][GridDhtColocatedCache]  
> Failed to rollback transaction (cache may contain stale locks): 
> GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl [mapping=null], 
> nearLocallyMapped=false, colocatedLocallyMapped=false, needCheckBackup=null, 
> hasRemoteLocks=false, thread=updater-1, mappings=IgniteTxMappingsSingleImpl 
> [mapping=null], super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, 
> nearNodes=[], dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter 
> [completedBase=null, sndTransformedVals=false, depEnabled=false, 
> txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false], 
> super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=117380231, 
> order=1505900296519, nodeOrder=1], writeVer=null, implicit=true, loc=true, 
> threadId=15914, startTime=1505900224068, 
> nodeId=2699eb85-b97a-431f-a038-a6970ee0, startVer=GridCacheVersion 
> [topVer=117380231, order=1505900296519, nodeOrder=1], endVer=null, 
> isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0, 
> sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion 
> [topVer=117380231, order=1505900296519, nodeOrder=1], finalizing=NONE, 
> invalidParts=null, state=ROLLED_BACK, timedOut=false, 
> topVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], duration=153ms, 
> onePhaseCommit=false], size=1]]]
> class org.apache.ignite.IgniteCheckedException: Failed to commit transaction: 
> GridNearTxLocal[id=749f6ae9e51--06ff-1487--0001, 
> concurrency=OPTIMISTIC, isolation=READ_COMMITTED, state=ROLLED_BACK, 
> invalidate=false, rollbackOnly=true, 
> nodeId=2699eb85-b97a-431f-a038-a6970ee0, duration=153]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:423)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3310)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2411)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$10.applyx(GridNearTxLocal.java:2393)
>   at 
> org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
>   at 
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheCompoundIdentityFuture.onDone(GridCacheCompoundIdentityFuture.java:56)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:340)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onDone(GridNearTxFinishFuture.java:69)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
>   at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
>  

[jira] [Updated] (IGNITE-4515) Throw exception when key and value fields mapped to the same DB columns

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4515:

Fix Version/s: (was: 2.3)

> Throw exception when key and value fields mapped to the same DB columns
> ---
>
> Key: IGNITE-4515
> URL: https://issues.apache.org/jira/browse/IGNITE-4515
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>
> In case of using JDBC store and following config (pseudocode):
> KeyClass { field1; field2; field3 }, ValClass { field1; field2; field3 }
> Fields mapped to the same DB table TABLE_NAME and columns: field1 -> col1, 
> field2 -> col2, field3 -> col3.
> On node startup throw an exception with message that restricts such case. 
> Field mappings should not intersect.



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

[jira] [Updated] (IGNITE-3117) Weblogic manual tests for HttpSession caching.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3117:

Fix Version/s: (was: 2.3)

> Weblogic manual tests for HttpSession caching.
> --
>
> Key: IGNITE-3117
> URL: https://issues.apache.org/jira/browse/IGNITE-3117
> Project: Ignite
>  Issue Type: Test
>  Components: websession
>Affects Versions: 1.6
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Minor
>  Labels: patch, test
> Attachments: IGNITE_3117_servlet_tests.patch
>
>
> Simple tests that allow deploy and check that HttpSession is cached properly 
> in grid.



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

[jira] [Updated] (IGNITE-4682) Need to finish transition to thread-per-partition model

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4682:

Fix Version/s: (was: 2.3)

> Need to finish transition to thread-per-partition model
> ---
>
> Key: IGNITE-4682
> URL: https://issues.apache.org/jira/browse/IGNITE-4682
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Yakov Zhdanov
>
> Need to create sub-tasks with proper description
> -atomic cache is almost done
> -tx cache - need to start working
> -rebalancing seems to be pretty easy to move to this approach
> -then we can remove deleted entries buffer



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

[jira] [Updated] (IGNITE-5056) Implement communication backpressure control

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5056:

Fix Version/s: (was: 2.3)

> Implement communication backpressure control
> 
>
> Key: IGNITE-5056
> URL: https://issues.apache.org/jira/browse/IGNITE-5056
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Yakov Zhdanov
>Priority: Critical
>
> Problem
> Currently backpressure control relies on semaphore on sending side that 
> ensures that sending queue cannot be  overflown and a special counter on 
> receiving side that stops reading from the socket when unprocessed message 
> count outgrows limit config parameter.
> In some scenarios it may lead to a distributed deadlock. E.g. we send many 
> async jobs to remote nodes which in turn do sync cache operations. If task 
> master node is a backup or primary for some cache updates and has already 
> scheduled too many job requests for send it will not be able to respond to 
> cache requests thus remote jobs would never complete.
> Solution
> Reading from socket should never stop
> Design notes
> * add IgniteConfiguration.maxAsyncRequests and propagate it via node 
> attributes to all nodes of the cluster. All nodes may have different value 
> (however this is unlikely).
> * add a flag to GridIoMessage.async. If flag is false then sender node 
> assumed to synchronously wait for response and does not wait otherwise.
> * all sent async messages should be tracked on sender node on per-receiver 
> basis.
> * all received async messages should be tracked on receiver nodes
> * nodes should add flag to communication acks on whether they can more async 
> messages or not 
> * sender should never exceed IgniteConfiguration.maxAsyncRequests async 
> requests per node
> * if IgniteConfiguration.maxAsyncRequests is exceeded or node sets flag in 
> communication ack then all async messages become sync
> * above means:
> ** next compute job from the task is sent to the node only after response for 
> some previous comes
> ** next dht update request (for primary sync or full async) is sent, but node 
> doesn't send response to near node unless it has not received response for 
> former operation from remote backup or for this operation
> ** next cache operation becomes sync - we force user code to wait on 
> operation future.  



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

[jira] [Updated] (IGNITE-4900) org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4 periodically fails in master

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4900:

Fix Version/s: (was: 2.3)

> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4 
> periodically fails in master
> --
>
> Key: IGNITE-4900
> URL: https://issues.apache.org/jira/browse/IGNITE-4900
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Ivan Rakov
> Attachments: log.txt
>
>
> See attached log



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

[jira] [Updated] (IGNITE-2107) Splitting TX example and adding new

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2107:

Fix Version/s: (was: 2.3)

> Splitting TX example and adding new
> ---
>
> Key: IGNITE-2107
> URL: https://issues.apache.org/jira/browse/IGNITE-2107
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4, 1.5.0.final
>Reporter: Yakov Zhdanov
>Assignee: Yakov Zhdanov
>
> We need to introduce {{tx}} package and add examples demonstrating different 
> types of txs:
> # pessimistic repeatable read
> # optimistic repeatable read
> # optimistic serializable - we need to accent that this is deadlock free mode.



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

[jira] [Updated] (IGNITE-4646) Try to unmarshall direct messages in striped pool

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4646:

Fix Version/s: (was: 2.3)

> Try to unmarshall direct messages in striped pool
> -
>
> Key: IGNITE-4646
> URL: https://issues.apache.org/jira/browse/IGNITE-4646
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
>
> During marshalling in NIO thread the following should be added to the write 
> buffer and sent to peer:
> 1. chunk size - 16 bits (this probably puts limitation on max write buffer 
> size of 64k or will require some changes to direct writer)
> 2. last  chunk - 1 bit
> 3. pool policy - 8 bits
> Here is the scheme to explain how this should work.
> {noformat}
> [chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more 
> space in write buffer
> [next chunk size] [last flag] [chunk data] <<-- we write next chunk once some 
> space is available in write buffer, but we skip partition and policy flags 
> and maybe others that should be sent only once.
> ...
> ...
> [next chunk size] [last flag] [chunk data] <<-- last flag is true here
> {noformat}
> Examples
> Write buffer - 64k
> Message - 84k
> # sender reserves space for chunk size
> # reserves space for policy and last chunk flag
> # marshalls message to buffer while it has free space (64k - SPACE will be 
> written to buffer)
> # puts size and flags to reserved space in the beginning
> # sends buffer or part of it which makes some space available to further 
> writes
> # reserves space for next chunk size and flags
> # marshalls message to buffer while it has free space (lets assume the rest 
> of message fits)
> # puts size and last=true to the reserved space and sends
> Receiver:
> # reads chunk size, stores the target pool and partition
> # allocates heap buffer and copies chunk data to it from read buffer
> # once all message chunks are fully read message should be submitted to a 
> pool where it will be unmarshalled and processed



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

[jira] [Updated] (IGNITE-961) Provide Basic NodeJS Integration

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-961:
---
Fix Version/s: (was: 2.3)

> Provide Basic NodeJS Integration
> 
>
> Key: IGNITE-961
> URL: https://issues.apache.org/jira/browse/IGNITE-961
> Project: Ignite
>  Issue Type: New Feature
>  Components: clients
>Reporter: Yakov Zhdanov
>Assignee: Andrey Gura
>




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

[jira] [Commented] (IGNITE-6286) org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6286:


GitHub user schernolyas opened a pull request:

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

IGNITE-6286: fix org.h2.jdbc.JdbcSQLException

changes:

1. develop test for check all supported types for parameterized queries
2. add support BigDecimal type as type of paraameter's value
3. refactoring (remove unused 'log.info')

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

$ git pull https://github.com/schernolyas/ignite IGNITE-6286-DEV2

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

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


commit 10938b6ec77bd00037d96881c42174525fe0aa58
Author: Sergey Chernolyas 
Date:   2017-09-26T12:56:44Z

IGNITE-6286: fix org.h2.jdbc.JdbcSQLException

changes:

1. develop test for check all supported types for parameterized queries
2. add support BigDecimal type as type of paraameter's value
3. refactoring (remove unused 'log.info')




> org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-6286
> URL: https://issues.apache.org/jira/browse/IGNITE-6286
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>  Labels: usability
> Fix For: 2.3
>
>
> Binding values  of some types to parameterized queries leads to the exception 
>  (see fill stacktrace in comments).
> Also, the exception *blocks* using parameterized queries for Hibernate OGM.
> I proceed the exception for String type. For control it, I developed test ( 
> see 
> org.apache.ignite.internal.processors.query.IgniteSqlParameterizedQueryTest)  
> .  
> The exception reproduced for BigDecimal type in 2.3-snapshot.



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

[jira] [Commented] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6186:
--

[~sboikov], please review my changes.

> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> ---
>
> Key: IGNITE-6186
> URL: https://issues.apache.org/jira/browse/IGNITE-6186
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
>
> The method is not thread-safe unless actual parameter is currentThread.



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

[jira] [Commented] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6186:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-6186: Removed redundant parameter.



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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-6186

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

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


commit 9646f442bb6327bb08c984c5e0caf0a9f7438640
Author: Andrey Kuznetsov 
Date:   2017-09-26T12:55:13Z

IGNITE-6186: Removed redundant parameter.




> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> ---
>
> Key: IGNITE-6186
> URL: https://issues.apache.org/jira/browse/IGNITE-6186
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
>
> The method is not thread-safe unless actual parameter is currentThread.



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

[jira] [Updated] (IGNITE-6426) Add support for variable length numbers in raw readers/writers.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6426:

Labels: iep-2  (was: )

> Add support for variable length numbers in raw readers/writers.
> ---
>
> Key: IGNITE-6426
> URL: https://issues.apache.org/jira/browse/IGNITE-6426
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>  Labels: iep-2
> Fix For: 2.3
>
>
> This is useful for implementing custom efficient compression.



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

[jira] [Updated] (IGNITE-962) node.js: provide json cache object implementation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-962:
---
Fix Version/s: (was: 2.3)

> node.js: provide json cache object implementation
> -
>
> Key: IGNITE-962
> URL: https://issues.apache.org/jira/browse/IGNITE-962
> Project: Ignite
>  Issue Type: Sub-task
>  Components: clients
>Reporter: Yakov Zhdanov
>Assignee: Andrey Gura
>
> * check if  we can optimize strings store with storing byte arrays
> * implement SQL indexing support for new object



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

[jira] [Updated] (IGNITE-966) node.js: documentation on readme.io

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-966:
---
Fix Version/s: (was: 2.3)

> node.js: documentation on readme.io
> ---
>
> Key: IGNITE-966
> URL: https://issues.apache.org/jira/browse/IGNITE-966
> Project: Ignite
>  Issue Type: Sub-task
>  Components: clients
>Reporter: Yakov Zhdanov
>Assignee: Andrey Gura
>
> http://apacheignite.readme.io/v1.2/docs



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

[jira] [Updated] (IGNITE-965) node.js: provide npm package

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-965:
---
Fix Version/s: (was: 2.3)

> node.js: provide npm package
> 
>
> Key: IGNITE-965
> URL: https://issues.apache.org/jira/browse/IGNITE-965
> Project: Ignite
>  Issue Type: Sub-task
>  Components: clients
>Reporter: Yakov Zhdanov
>Assignee: Andrey Gura
>
> Need to investigate how packages are built and shared.
> The result should be a script or automated procedure that build and share the 
> package



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

[jira] [Updated] (IGNITE-6221) ContinuousQuery. Local listener notified if filter throws exception

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6221:

Fix Version/s: (was: 2.3)

> ContinuousQuery. Local listener notified if filter throws exception
> ---
>
> Key: IGNITE-6221
> URL: https://issues.apache.org/jira/browse/IGNITE-6221
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Nikolay Izhikov
>Priority: Minor
>
> Local listener of continuous query receives event if filter throw exception 
> from `evaluate`.
> Steps to reproduce the bug:
> 1. Run continuous query with remote filter.
> 2. Throw exception from filter.
> Current behavior:
> 3. Local listener notified.
> Expected behavior:
> 3. Local listener doesn't notify.
> [Mail-list 
> discussion|http://apache-ignite-developers.2346864.n4.nabble.com/ContinuousQueryWithTransformer-implementation-questions-2-td21418.html]
> Filter description from [jcache 
> Javadoc|https://static.javadoc.io/javax.cache/cache-api/1.0.0/javax/cache/event/CacheEntryEventFilter.html#evaluate(javax.cache.event.CacheEntryEvent)]:
> {noformat}
> Returns:
>true if the evaluation passes, otherwise false.
>The effect of returning true is that listener will be invoked
> {noformat}
> Test to reproduce error: 
> {code:java}
> package org.apache.ignite.internal.processors.cache.query.continuous;
> import java.io.Serializable;
> import javax.cache.Cache;
> import javax.cache.event.CacheEntryEvent;
> import javax.cache.event.CacheEntryUpdatedListener;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheEntryEventSerializableFilter;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.query.ContinuousQuery;
> import org.apache.ignite.cache.query.QueryCursor;
> public class GridCacheContinuousQueryFilterExceptionTest extends 
> GridCacheContinuousQueryAbstractSelfTest implements Serializable {
> /**
>  * @throws Exception If failed.
>  */
> public void testListenerAfterFilterException() throws Exception {
> IgniteCache cache = 
> grid(0).cache(DEFAULT_CACHE_NAME);
> ContinuousQuery qry = new ContinuousQuery<>();
> qry.setLocalListener(new CacheEntryUpdatedListener Integer>() {
> @Override public void onUpdated(Iterable> evts) {
> fail("Listener shouldn't be called");
> }
> });
> qry.setRemoteFilter(new CacheEntryEventSerializableFilter Integer>() {
> @Override public boolean evaluate(CacheEntryEvent Integer, ? extends Integer> evt) {
> throw new RuntimeException("Test error.");
> }
> });
> try (QueryCursor> ignored = 
> cache.query(qry)) {
> for (int i = 0; i < 100; i++)
> cache.put(i, i);
> }
> }
> @Override protected CacheMode cacheMode() {
> return CacheMode.REPLICATED;
> }
> @Override protected int gridCount() {
> return 1;
> }
> }
> {code}



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