[jira] [Updated] (IGNITE-6190) SQL query fails silently if Set is passed as a parameter

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6190:

Attachment: TestIgniteQuery.zip

> SQL query fails silently if Set is passed as a parameter
> 
>
> Key: IGNITE-6190
> URL: https://issues.apache.org/jira/browse/IGNITE-6190
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
> Attachments: TestIgniteQuery.zip
>
>
> Seems like the SqlQuery API does not like {{Set}} as the input parameter. 
> While this query doesn't work (the Set is used as an input):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join 
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId);
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e -> 
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> This one works well (the Set is converted to Array explicitly):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join 
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId.toArray());
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e -> 
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> The fact that it fails silently is an issue. IMHO there should be some 
> validation to alert the calling code that the type specified is not valid or 
> the set has to be transformed to the array on the fly.



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

[jira] [Created] (IGNITE-6190) SQL query fails silently if Set is passed as a parameter

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6190:
---

 Summary: SQL query fails silently if Set is passed as a parameter
 Key: IGNITE-6190
 URL: https://issues.apache.org/jira/browse/IGNITE-6190
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda


Seems like the SqlQuery API does not like {{Set}} as the input parameter. 
While this query doesn't work (the Set is used as an input):

{code}
public Map getAccountsForLe(Set leId) {
SqlQuery query =
new SqlQuery(Account.class, "from Account join 
table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
.setArgs(leId);

Map results = new HashMap<>();
_cache.query(query).getAll().stream().forEach(e -> results.put(e.getKey(), 
e.getValue()));
return results;
}
{code}

This one works well (the Set is converted to Array explicitly):

{code}
public Map getAccountsForLe(Set leId) {
SqlQuery query =
new SqlQuery(Account.class, "from Account join 
table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
.setArgs(leId.toArray());

Map results = new HashMap<>();
_cache.query(query).getAll().stream().forEach(e -> results.put(e.getKey(), 
e.getValue()));
return results;
}
{code}

The fact that it fails silently is an issue. IMHO there should be some 
validation to alert the calling code that the type specified is not valid or 
the set has to be transformed to the array on the fly.



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

[jira] [Comment Edited] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov edited comment on IGNITE-6181 at 8/25/17 6:54 PM:


"By design pessimistic transaction can detect timeout if some transaction 
related process is in progress (lock acquiring or prepare phase)"

This is exactly the thing needed to be somehow fixed.

If a transaction is started and abandoned for some case(e.g exception in the 
middle and not wrapping a transaction with try-with-resources block), it will 
lock all subsequent transactions(without timeouts) which are trying to acquire 
locks held by first transaction and will block exchange process.

I suggest to associate a TimeoutObject with a transaction having non-zero 
timeout.

Reopening the issue.


was (Author: ascherbakov):
"By design pessimistic transaction can detect timeout if some transaction 
related process is in progress (lock acquiring or prepare phase)"

This is exactly the thing needed to be somehow fixed.

If a transaction is started and abandoned for some case(e.g exception in the 
middle and not wrapping a transaction with try-with-resources block), it will 
lock all subsequent transactions(without timeouts) which are trying to acquire 
locks held by hanging thread and will block exchange process.

I suggest to associate a TimeoutObject with a transaction having non-zero 
timeout.

Reopening the issue.

> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
> 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.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> 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.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests ability to rollback not properly closed transaction.
>  */
> public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
> /** */
> private static final long TX_TIMEOUT = 3_000L;
> /** */
> private static final String CACHE_NAME = "test";
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
> TcpDiscoveryVmIpFinder(true);
> /** */
> private final CountDownLatch l = new CountDownLatch(1);
> /** */
> private final Object mux = new Object();
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(IP_FINDER));
> TransactionConfiguration txCfg = new TransactionConfiguration();
> txCfg.setDefaultTxTimeout(TX_TIMEOUT);
> cfg.setTransactionConfiguration(txCfg);
> CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);
> ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }

[jira] [Comment Edited] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov edited comment on IGNITE-6181 at 8/25/17 6:52 PM:


"By design pessimistic transaction can detect timeout if some transaction 
related process is in progress (lock acquiring or prepare phase)"

This is exactly the thing needed to be somehow fixed.

If a transaction is started and abandoned for some case(e.g exception in the 
middle and not wrapping a transaction with try-with-resources block), it will 
lock all other transactions(without timeouts) which are trying to acquire locks 
held by hanging thread and will block exchange process.

I suggest to associate a TimeoutObject with a transaction having non-zero 
timeout.

Reopening the issue.


was (Author: ascherbakov):
"By design pessimistic transaction can detect timeout if some transaction 
related process is in progress (lock acquiring or prepare phase)"

This is exactly the thing needed to be somehow fixed.

If a transaction is started and abandoned for some case(e.g exception in the 
middle and not wrapping a transaction with try-with-resources block) without 
proper closing, it will lock all other transactions(without timeouts) which are 
trying to acquire locks held by hanging thread and will block exchange process.

I suggest to associate a TimeoutObject with a transaction having non-zero 
timeout.

Reopening the issue.

> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
> 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.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> 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.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests ability to rollback not properly closed transaction.
>  */
> public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
> /** */
> private static final long TX_TIMEOUT = 3_000L;
> /** */
> private static final String CACHE_NAME = "test";
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
> TcpDiscoveryVmIpFinder(true);
> /** */
> private final CountDownLatch l = new CountDownLatch(1);
> /** */
> private final Object mux = new Object();
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(IP_FINDER));
> TransactionConfiguration txCfg = new TransactionConfiguration();
> txCfg.setDefaultTxTimeout(TX_TIMEOUT);
> cfg.setTransactionConfiguration(txCfg);
> CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);
> ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cfg.setCacheConfiguration(ccfg);
> return 

[jira] [Comment Edited] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov edited comment on IGNITE-6181 at 8/25/17 6:51 PM:


"By design pessimistic transaction can detect timeout if some transaction 
related process is in progress (lock acquiring or prepare phase)"

This is exactly the thing needed to be somehow fixed.

If a transaction is started and abandoned for some case(e.g exception in the 
middle and not wrapping a transaction with try-with-resources block) without 
proper closing, it will lock all other transactions(without timeouts) which are 
trying to acquire locks held by hanging thread and will block exchange process.

I suggest to associate a TimeoutObject with a transaction having non-zero 
timeout.

Reopening the issue.


was (Author: ascherbakov):
"By design pessimistic transaction can detect timeout if some transaction 
related process is in progress (lock acquiring or prepare phase)"

This is exactly the thing needed to be somehow fixed.

If a transaction is started and abandoned for some case(e.g exception in the 
middle) without proper closing, it will lock all other transactions(without 
timeouts) which are trying to acquire locks held by hanging thread and will 
block exchange process.

I suggest to associate a TimeoutObject with a transaction having non-zero 
timeout.

Reopening the issue.

> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
> 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.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> 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.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests ability to rollback not properly closed transaction.
>  */
> public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
> /** */
> private static final long TX_TIMEOUT = 3_000L;
> /** */
> private static final String CACHE_NAME = "test";
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
> TcpDiscoveryVmIpFinder(true);
> /** */
> private final CountDownLatch l = new CountDownLatch(1);
> /** */
> private final Object mux = new Object();
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(IP_FINDER));
> TransactionConfiguration txCfg = new TransactionConfiguration();
> txCfg.setDefaultTxTimeout(TX_TIMEOUT);
> cfg.setTransactionConfiguration(txCfg);
> CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);
> ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> /** */
> public 

[jira] [Updated] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov updated IGNITE-6181:
--
Description: 
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.cache;

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteException;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.configuration.TransactionConfiguration;
import org.apache.ignite.internal.IgniteInternalFuture;
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.vm.TcpDiscoveryVmIpFinder;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
import org.apache.ignite.transactions.Transaction;
import org.apache.ignite.transactions.TransactionConcurrency;
import org.apache.ignite.transactions.TransactionIsolation;

/**
 * Tests ability to rollback not properly closed transaction.
 */
public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
/** */
private static final long TX_TIMEOUT = 3_000L;

/** */
private static final String CACHE_NAME = "test";

/** IP finder. */
private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
TcpDiscoveryVmIpFinder(true);

/** */
private final CountDownLatch l = new CountDownLatch(1);

/** */
private final Object mux = new Object();

/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String 
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);

cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(IP_FINDER));

TransactionConfiguration txCfg = new TransactionConfiguration();
txCfg.setDefaultTxTimeout(TX_TIMEOUT);

cfg.setTransactionConfiguration(txCfg);

CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);
ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);

cfg.setCacheConfiguration(ccfg);

return cfg;
}

/** */
public void testTxTimeoutHandling() throws Exception {
try {
final Ignite ignite = startGrid(0);

final AtomicBoolean released = new AtomicBoolean();

multithreadedAsync(new Runnable() {
@Override public void run() {
// Start tx with default settings.
try (Transaction tx = ignite.transactions().txStart()) {
ignite.cache(CACHE_NAME).put(1, 1);

l.countDown();

// Wait longer than default timeout.
synchronized (mux) {
while (!released.get()) {
try {
mux.wait();
}
catch (InterruptedException e) {
throw new IgniteException(e);
}
}
}

try {
tx.commit();

fail();
}
catch (IgniteException e) {
// Expect exception - tx is rolled back.
}
}
}
}, 1, "Locker");

IgniteInternalFuture fut2 = multithreadedAsync(new Runnable() {
@Override public void run() {
U.awaitQuiet(l);

// Try to acquire lock.
// Acquisition will be successul then first transaction 
will be rolled back after timeout.
try (Transaction tx = 
ignite.transactions().txStart(TransactionConcurrency.PESSIMISTIC,

[jira] [Reopened] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov reopened IGNITE-6181:
---

> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
> 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.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> 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.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests ability to rollback not properly closed transaction.
>  */
> public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
> /** */
> private static final long TX_TIMEOUT = 3_000L;
> /** */
> private static final String CACHE_NAME = "test";
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
> TcpDiscoveryVmIpFinder(true);
> /** */
> private final CountDownLatch l = new CountDownLatch(1);
> /** */
> private final Object mux = new Object();
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(IP_FINDER));
> TransactionConfiguration txCfg = new TransactionConfiguration();
> txCfg.setDefaultTxTimeout(TX_TIMEOUT);
> cfg.setTransactionConfiguration(txCfg);
> CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);
> ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> /** */
> public void testTxTimeoutHandling() throws Exception {
> try {
> final Ignite ignite = startGrid();
> final AtomicBoolean released = new AtomicBoolean();
> multithreadedAsync(new Runnable() {
> @Override public void run() {
> // Start tx with default settings.
> try (Transaction tx = ignite.transactions().txStart()) {
> ignite.cache(CACHE_NAME).put(1, 1);
> l.countDown();
> // Wait longer than default timeout.
> synchronized (mux) {
> while (!released.get()) {
> try {
> mux.wait();
> }
> catch (InterruptedException e) {
> throw new IgniteException(e);
> }
> }
> }
> try {
> tx.commit();
> fail();
> }
> catch (IgniteException e) {
> // Expect exception - tx is rolled 

[jira] [Commented] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-6181:
---

"By design pessimistic transaction can detect timeout if some transaction 
related process is in progress (lock acquiring or prepare phase)"

This is exactly the thing needed to be somehow fixed.

If a transaction is started and abandoned for some case(e.g exception in the 
middle) without proper closing, it will lock all other transactions(without 
timeouts) which are trying to acquire locks held by hanging thread and will 
block exchange process.

I suggest to associate a TimeoutObject with a transaction having non-zero 
timeout.

Reopening the issue.

> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
> 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.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> 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.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests ability to rollback not properly closed transaction.
>  */
> public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
> /** */
> private static final long TX_TIMEOUT = 3_000L;
> /** */
> private static final String CACHE_NAME = "test";
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
> TcpDiscoveryVmIpFinder(true);
> /** */
> private final CountDownLatch l = new CountDownLatch(1);
> /** */
> private final Object mux = new Object();
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(IP_FINDER));
> TransactionConfiguration txCfg = new TransactionConfiguration();
> txCfg.setDefaultTxTimeout(TX_TIMEOUT);
> cfg.setTransactionConfiguration(txCfg);
> CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);
> ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> /** */
> public void testTxTimeoutHandling() throws Exception {
> try {
> final Ignite ignite = startGrid();
> final AtomicBoolean released = new AtomicBoolean();
> multithreadedAsync(new Runnable() {
> @Override public void run() {
> // Start tx with default settings.
> try (Transaction tx = ignite.transactions().txStart()) {
> ignite.cache(CACHE_NAME).put(1, 1);
> l.countDown();
> // Wait longer than default timeout.
> synchronized (mux) {
> while (!released.get()) {
>   

[jira] [Commented] (IGNITE-6183) Make "Node crashed in the middle of checkpoint" message softer and more informative

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6183:
-

LGTM! Merged to master.

> Make "Node crashed in the middle of checkpoint" message softer and more 
> informative
> ---
>
> Key: IGNITE-6183
> URL: https://issues.apache.org/jira/browse/IGNITE-6183
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Andrey Gura
> Fix For: 2.2
>
>
> If Ignite node with persistence was stopped during checkpoint, user will see 
> message:
> {noformat}
> Ignite node crashed in the middle of checkpoint. Will restore memory state 
> and enforce checkpoint on node start.
> {noformat}
> Actually, nothing bad happened: node just need to replay WAL delta records to 
> complete the checkpoint. It's ordinary case for checkpointing algorithm. 
> Though, such word as "crashed" may alarm and confuse user.



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

[jira] [Assigned] (IGNITE-6183) Make "Node crashed in the middle of checkpoint" message softer and more informative

[Ivan Rakov (JIRA)]

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

Ivan Rakov reassigned IGNITE-6183:
--

Assignee: Andrey Gura  (was: Sergey Chugunov)

> Make "Node crashed in the middle of checkpoint" message softer and more 
> informative
> ---
>
> Key: IGNITE-6183
> URL: https://issues.apache.org/jira/browse/IGNITE-6183
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Andrey Gura
> Fix For: 2.2
>
>
> If Ignite node with persistence was stopped during checkpoint, user will see 
> message:
> {noformat}
> Ignite node crashed in the middle of checkpoint. Will restore memory state 
> and enforce checkpoint on node start.
> {noformat}
> Actually, nothing bad happened: node just need to replay WAL delta records to 
> complete the checkpoint. It's ordinary case for checkpointing algorithm. 
> Though, such word as "crashed" may alarm and confuse user.



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

[jira] [Assigned] (IGNITE-6183) Make "Node crashed in the middle of checkpoint" message softer and more informative

[Ivan Rakov (JIRA)]

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

Ivan Rakov reassigned IGNITE-6183:
--

Assignee: Sergey Chugunov  (was: Ivan Rakov)

Please, take a look.

> Make "Node crashed in the middle of checkpoint" message softer and more 
> informative
> ---
>
> Key: IGNITE-6183
> URL: https://issues.apache.org/jira/browse/IGNITE-6183
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Sergey Chugunov
> Fix For: 2.2
>
>
> If Ignite node with persistence was stopped during checkpoint, user will see 
> message:
> {noformat}
> Ignite node crashed in the middle of checkpoint. Will restore memory state 
> and enforce checkpoint on node start.
> {noformat}
> Actually, nothing bad happened: node just need to replay WAL delta records to 
> complete the checkpoint. It's ordinary case for checkpointing algorithm. 
> Though, such word as "crashed" may alarm and confuse user.



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

[jira] [Commented] (IGNITE-6183) Make "Node crashed in the middle of checkpoint" message softer and more informative

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6183:


GitHub user glukos opened a pull request:

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

IGNITE-6183 Make "Node crashed in the middle of checkpoint" message s…



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

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

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

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


commit d272bbfbd53cb180ae898e94e986180734c10b94
Author: Ivan Rakov 
Date:   2017-08-25T16:24:14Z

IGNITE-6183 Make "Node crashed in the middle of checkpoint" message softer 
and more informative




> Make "Node crashed in the middle of checkpoint" message softer and more 
> informative
> ---
>
> Key: IGNITE-6183
> URL: https://issues.apache.org/jira/browse/IGNITE-6183
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.2
>
>
> If Ignite node with persistence was stopped during checkpoint, user will see 
> message:
> {noformat}
> Ignite node crashed in the middle of checkpoint. Will restore memory state 
> and enforce checkpoint on node start.
> {noformat}
> Actually, nothing bad happened: node just need to replay WAL delta records to 
> complete the checkpoint. It's ordinary case for checkpointing algorithm. 
> Though, such word as "crashed" may alarm and confuse user.



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

[jira] [Updated] (IGNITE-6112) Review and update C++ documentation according to new features.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6112:

Description: 
It is needed to spend some time walking through the doc and updating it 
considering the latest features and changes 
https://apacheignite.readme.io/docs/quering-data 

For instance:

1. The configuration section can be switched to the usage of DDL statements for 
tables creation and indexes definition.

2. Information about "_key" and "_value" should be wiped out because presently 
there is a way to set unique names for the whole key and value.

  was:
It is needed to spend some time walking through the doc and updating it 
considering the latest features and changes 
https://apacheignite.readme.io/docs/quering-data 

For instance:

1. The configuration section [1] can be switched to the usage of DDL statements 
for tables creation and indexes definition.

2. Information about "_key" and "_value" should be wiped out because presently 
there is a way to set unique names for the whole key and value.


> Review and update C++ documentation according to new features.
> --
>
> Key: IGNITE-6112
> URL: https://issues.apache.org/jira/browse/IGNITE-6112
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>
> It is needed to spend some time walking through the doc and updating it 
> considering the latest features and changes 
> https://apacheignite.readme.io/docs/quering-data 
> For instance:
> 1. The configuration section can be switched to the usage of DDL statements 
> for tables creation and indexes definition.
> 2. Information about "_key" and "_value" should be wiped out because 
> presently there is a way to set unique names for the whole key and value.



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

[jira] [Updated] (IGNITE-6040) Update Distributed SQL Database page on the website

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-6040:

Description: 
# change DDL examples to pure SQL (without Java)
# change DML examples to pure SQL (without Java)
# change Query examples to pure SQL (without Java)
# add Java API section and show 1 Query, 1 DDL, 1 DML example from Java
# add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C#
# add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, 
PHP, etc.

  was:
# change DDL examples to pure SQL (without Java)
# change DML examples to pure SQL (without Java)
# change Query examples to pure SQL (without Java)
# add Java API section and show 1 Query, 1 DDL, 1 DML example from Java
# add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C#
# add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, 
PHP, etc.



> Update Distributed SQL Database page on the website
> ---
>
> Key: IGNITE-6040
> URL: https://issues.apache.org/jira/browse/IGNITE-6040
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Igor Sapego
>  Labels: site
>
> # change DDL examples to pure SQL (without Java)
> # change DML examples to pure SQL (without Java)
> # change Query examples to pure SQL (without Java)
> # add Java API section and show 1 Query, 1 DDL, 1 DML example from Java
> # add .NET / C# API section and show 1 Query, 1 DDL, 1 DML example from C#
> # add Other API section and show 1 Query, 1 DDL, 1 DML example from Python, 
> PHP, etc.



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

[jira] [Comment Edited] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-6181 at 8/25/17 3:00 PM:
--

[~ascherbakov] Test is incorrect in a manner. By design pessimistic transaction 
can detect timeout if some transaction related process is in progress (lock 
acquiring or prepare phase). In your test transaction does nothing because it 
has locked entry already but can't reach {{tx.commit()}} statement, so there is 
no any entity that can decide that time out happened. 

It means that if user's thread executes some long running job in the same 
thread in which transaction was initialized that timeout will not detected 
until any other transactional operation will be invoked (cache write or 
commit). 

The simplest test for pessimistic transaction timeout is the following:

{code:java}
public void testTxTimeout() throws Exception {
final Ignite ignite = startGrid();

try (Transaction tx = ignite.transactions().txStart()) {
ignite.cache(CACHE_NAME).put(1, 1);

U.sleep(TX_TIMEOUT + 1000L);

tx.commit();

fail();
}
catch (IgniteException e) {
// Expect exception - tx is rolled back.
}
}
{code}


was (Author: agura):
[~ascherbakov] Test is incorrect in some in a manner. By design pessimistic 
transaction can detect timeout if some transaction related process is in 
progress (lock acquiring or prepare phase). In your test transaction does 
nothing because it has locked entry already but can't reach {{tx.commit()}} 
statement, so there is no any entity that can decide that time out happened. 

It means that if user's thread executes some long running job in the same 
thread in which transaction was initialized that timeout will not detected 
until any other transactional operation will be invoked (cache write or 
commit). 

The simplest test for pessimistic transaction timeout is the following:

{code:java}
public void testTxTimeout() throws Exception {
final Ignite ignite = startGrid();

try (Transaction tx = ignite.transactions().txStart()) {
ignite.cache(CACHE_NAME).put(1, 1);

U.sleep(TX_TIMEOUT + 1000L);

tx.commit();

fail();
}
catch (IgniteException e) {
// Expect exception - tx is rolled back.
}
}
{code}

> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
> 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.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> 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.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests ability to rollback not properly closed transaction.
>  */
> public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
> /** */
> private static final long TX_TIMEOUT = 3_000L;
> 

[jira] [Resolved] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Andrey Gura (JIRA)]

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

Andrey Gura resolved IGNITE-6181.
-
Resolution: Won't Fix

> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
> 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.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> 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.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests ability to rollback not properly closed transaction.
>  */
> public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
> /** */
> private static final long TX_TIMEOUT = 3_000L;
> /** */
> private static final String CACHE_NAME = "test";
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
> TcpDiscoveryVmIpFinder(true);
> /** */
> private final CountDownLatch l = new CountDownLatch(1);
> /** */
> private final Object mux = new Object();
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(IP_FINDER));
> TransactionConfiguration txCfg = new TransactionConfiguration();
> txCfg.setDefaultTxTimeout(TX_TIMEOUT);
> cfg.setTransactionConfiguration(txCfg);
> CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);
> ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> /** */
> public void testTxTimeoutHandling() throws Exception {
> try {
> final Ignite ignite = startGrid();
> final AtomicBoolean released = new AtomicBoolean();
> multithreadedAsync(new Runnable() {
> @Override public void run() {
> // Start tx with default settings.
> try (Transaction tx = ignite.transactions().txStart()) {
> ignite.cache(CACHE_NAME).put(1, 1);
> l.countDown();
> // Wait longer than default timeout.
> synchronized (mux) {
> while (!released.get()) {
> try {
> mux.wait();
> }
> catch (InterruptedException e) {
> throw new IgniteException(e);
> }
> }
> }
> try {
> tx.commit();
> fail();
> }
> catch (IgniteException e) {
> // Expect exception - 

[jira] [Commented] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6181:
-

[~ascherbakov] Test is incorrect in some in a manner. By design pessimistic 
transaction can detect timeout if some transaction related process is in 
progress (lock acquiring or prepare phase). In your test transaction does 
nothing because it has locked entry already but can't reach {{tx.commit()}} 
statement, so there is no any entity that can decide that time out happened. 

It means that if user's thread executes some long running job in the same 
thread in which transaction was initialized that timeout will not detected 
until any other transactional operation will be invoked (cache write or 
commit). 

The simplest test for pessimistic transaction timeout is the following:

{code:java}
public void testTxTimeout() throws Exception {
final Ignite ignite = startGrid();

try (Transaction tx = ignite.transactions().txStart()) {
ignite.cache(CACHE_NAME).put(1, 1);

U.sleep(TX_TIMEOUT + 1000L);

tx.commit();

fail();
}
catch (IgniteException e) {
// Expect exception - tx is rolled back.
}
}
{code}

> Tx is not rolled back on timeout leading to potential whole grid hang
> -
>
> Key: IGNITE-6181
> URL: https://issues.apache.org/jira/browse/IGNITE-6181
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
> 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.cache;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> 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.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests ability to rollback not properly closed transaction.
>  */
> public class IgniteTxTimeoutTest extends GridCommonAbstractTest {
> /** */
> private static final long TX_TIMEOUT = 3_000L;
> /** */
> private static final String CACHE_NAME = "test";
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
> TcpDiscoveryVmIpFinder(true);
> /** */
> private final CountDownLatch l = new CountDownLatch(1);
> /** */
> private final Object mux = new Object();
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(IP_FINDER));
> TransactionConfiguration txCfg = new TransactionConfiguration();
> txCfg.setDefaultTxTimeout(TX_TIMEOUT);
> cfg.setTransactionConfiguration(txCfg);
> CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);
> ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> /** */
> public void testTxTimeoutHandling() throws Exception {
> try {
> final Ignite ignite = startGrid();
> final AtomicBoolean 

[jira] [Commented] (IGNITE-2779) BinaryMarshaller caches must be cleaned during client reconnect.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2779:


GitHub user NSAmelchev opened a pull request:

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

IGNITE-2779 BinaryMarshaller caches must be cleaned during client reconnect.



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

$ git pull https://github.com/NSAmelchev/ignite IGNITE-2779

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

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


commit 9170321182797ebb2acada407efea15421875911
Author: NSAmelchev 
Date:   2017-08-25T14:50:10Z

add test and fix




> BinaryMarshaller caches must be cleaned during client reconnect.
> 
>
> Key: IGNITE-2779
> URL: https://issues.apache.org/jira/browse/IGNITE-2779
> Project: Ignite
>  Issue Type: Task
>  Components: cache, general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Amelchev Nikita
>  Labels: community
> Fix For: 2.2
>
> Attachments: IgniteProblemTest.java
>
>
> The problem is originally reported by Vinay Sharma here: 
> http://apache-ignite-users.70518.x6.nabble.com/changed-cache-configuration-and-restarted-server-nodes-Getting-exception-td3064.html#none
> *Root cause*:
> When client is reconnected to topology after full topology restart (i.e. all 
> server nodes were down), it doesn't re-send binary metadata to topology. As a 
> result, {{BinaryMarshaller}} exception occurs.
> *Steps to reproduce*
> Run attached code.
> *Proposed solution*
> Clean cached binary metadata during re-connect.



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

[jira] [Updated] (IGNITE-6189) Benchmarks for check LFS used disk space

[Aleksey Chetaev (JIRA)]

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

Aleksey Chetaev updated IGNITE-6189:

Description: 
Need to create new benchmarks for test how many space we use for store n keys 
in LFS.
Benchmark should content arguments:
1. Range of entries which will be put.
2. Step: how often we show store size.

Case for e.x. params (range 1_000_000, step 100_000):
1. Put 100_000 entries, save time for put
2. Wait for checkpoint finished on all nodes.
3. Calc db size on each server.
4. Write size and time to benchmarks results.
...
6. Repeat first 4 steps while entries count in cache less that 1_000_000.


  was:
Need to create new benchmarks for test how many space we use for store n keys 
in LFS.
Benchmark should content arguments:
1. Range of entries which will be put.
2. Step: how often we show store size.

Case for e.x. params (range 1_000_000, step 100_000):
1. Put 100_000 entries, save time for put
2. Wait for checkpoint finished on all nodes.
3. Calc db size on each server.
4. Write size and time to benchmarks results.
...
6. Repeat first 4 steps while entries count in cache less that 1_000_000.


> Benchmarks for check LFS used disk space
> 
>
> Key: IGNITE-6189
> URL: https://issues.apache.org/jira/browse/IGNITE-6189
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksey Chetaev
>Assignee: Oleg Ostanin
>
> Need to create new benchmarks for test how many space we use for store n keys 
> in LFS.
> Benchmark should content arguments:
> 1. Range of entries which will be put.
> 2. Step: how often we show store size.
> Case for e.x. params (range 1_000_000, step 100_000):
> 1. Put 100_000 entries, save time for put
> 2. Wait for checkpoint finished on all nodes.
> 3. Calc db size on each server.
> 4. Write size and time to benchmarks results.
> ...
> 6. Repeat first 4 steps while entries count in cache less that 1_000_000.



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

[jira] [Commented] (IGNITE-5456) JDBC thin driver: the statement produces multiple result sets must be handled correct

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5456:


Github user tledkov-gridgain closed the pull request at:

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


> JDBC thin driver: the statement produces multiple result sets must be handled 
> correct
> -
>
> Key: IGNITE-5456
> URL: https://issues.apache.org/jira/browse/IGNITE-5456
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> Now the SQL query statement that produces is failed with:
> {code}
> [18:53:56,231][ERROR][sql-connector-#81%thin.JdbcThinStatementFullApiSelfTest0%][SqlListenerProcessor]
>  Runtime error caught during grid runnable execution: GridWorker 
> [name=message-received-notify, 
> igniteInstanceName=thin.JdbcThinStatementFullApiSelfTest0, finished=false, 
> hashCode=841829578, interrupted=false, 
> runner=sql-connector-#81%thin.JdbcThinStatementFullApiSelfTest0%]
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.prepared(GridSqlQueryParser.java:435)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1298)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1834)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1830)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2271)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1838)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:188)
>   at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:122)
>   at 
> org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:152)
>   at 
> org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:44)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
>   at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
>   at 
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> This case must be handled and appropriate exception will be thrown.



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

[jira] [Assigned] (IGNITE-6189) Benchmarks for check LFS used disk space

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin reassigned IGNITE-6189:


Assignee: Oleg Ostanin

> Benchmarks for check LFS used disk space
> 
>
> Key: IGNITE-6189
> URL: https://issues.apache.org/jira/browse/IGNITE-6189
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksey Chetaev
>Assignee: Oleg Ostanin
>
> Need to create new benchmarks for test how many space we use for store n keys 
> in LFS.
> Benchmark should content arguments:
> 1. Range of entries which will be put.
> 2. Step: how often we show store size.
> Case for e.x. params (range 1_000_000, step 100_000):
> 1. Put 100_000 entries, save time for put
> 2. Wait for checkpoint finished on all nodes.
> 3. Calc db size on each server.
> 4. Write size and time to benchmarks results.
> ...
> 6. Repeat first 4 steps while entries count in cache less that 1_000_000.



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

[jira] [Updated] (IGNITE-6189) Benchmarks for check LFS used disk space

[Aleksey Chetaev (JIRA)]

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

Aleksey Chetaev updated IGNITE-6189:

Description: 
Need to create new benchmarks for test how many space we use for store n keys 
in LFS.
Benchmark should content arguments:
1. Range of entries which will be put.
2. Step: how often we show store size.

Case for e.x. params (range 1_000_000, step 100_000):
1. Put 100_000 entries, save time for put
2. Wait for checkpoint finished on all nodes.
3. Calc db size on each server.
4. Write size and time to benchmarks results.
...
6. Repeat first 4 steps while entries count in cache less that 1_000_000.

  was:
Need to create new benchmarks for test how many space we use for store n keys 
in LFS.
Benchmark should content arguments:
1. Range of entries which will be put.
2. How often we show store size.

Case for e.x. params (range 1_000_000, step 100_000):
1. Put 100_000 entries, save time for put
2. Wait for checkpoint finished on all nodes.
3. Calc db size on each server.
4. Write size and time to benchmarks results.
...
6. Repeat first 4 steps while entries count in cache less that 1_000_000.


> Benchmarks for check LFS used disk space
> 
>
> Key: IGNITE-6189
> URL: https://issues.apache.org/jira/browse/IGNITE-6189
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksey Chetaev
>
> Need to create new benchmarks for test how many space we use for store n keys 
> in LFS.
> Benchmark should content arguments:
> 1. Range of entries which will be put.
> 2. Step: how often we show store size.
> Case for e.x. params (range 1_000_000, step 100_000):
> 1. Put 100_000 entries, save time for put
> 2. Wait for checkpoint finished on all nodes.
> 3. Calc db size on each server.
> 4. Write size and time to benchmarks results.
> ...
> 6. Repeat first 4 steps while entries count in cache less that 1_000_000.



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

[jira] [Created] (IGNITE-6189) Benchmarks for check LFS used disk space

[Aleksey Chetaev (JIRA)]

Aleksey Chetaev created IGNITE-6189:
---

 Summary: Benchmarks for check LFS used disk space
 Key: IGNITE-6189
 URL: https://issues.apache.org/jira/browse/IGNITE-6189
 Project: Ignite
  Issue Type: Improvement
Reporter: Aleksey Chetaev


Need to create new benchmarks for test how many space we use for store n keys 
in LFS.
Benchmark should content arguments:
1. Range of entries which will be put.
2. How often we show store size.

Case for e.x. params (range 1_000_000, step 100_000):
1. Put 100_000 entries, save time for put
2. Wait for checkpoint finished on all nodes.
3. Calc db size on each server.
4. Write size and time to benchmarks results.
...
6. Repeat first 4 steps while entries count in cache less that 1_000_000.



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

[jira] [Created] (IGNITE-6188) ODBC: SQLSQLFreeStmt failing if called before all the rows from the result set were fetched.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-6188:
---

 Summary: ODBC: SQLSQLFreeStmt failing if called before all the 
rows from the result set were fetched.
 Key: IGNITE-6188
 URL: https://issues.apache.org/jira/browse/IGNITE-6188
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.1
Reporter: Igor Sapego


Steps to reproduce: 
1. Execute select query with more then 1 row in result set.
2. Fetch results and close the cursor before detecting end of result set.
3. Check for statement error.

Error message:
{noformat}
HY000: Failed to find query with ID: 10
{noformat}



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

[jira] [Commented] (IGNITE-6180) Marshaller mappings are not restored from disk on node start

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6180:
-

LGTM! Thanks for contribution! Merged to master branch.

> Marshaller mappings are not restored from disk on node start
> 
>
> Key: IGNITE-6180
> URL: https://issues.apache.org/jira/browse/IGNITE-6180
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
> Fix For: 2.2
>
> Attachments: BinaryOnJoinedNodeTest.java
>
>
> h2. Steps to reproduce
> # Start node1 with persistence enabled.
> # Put instance of custom class to cache so marshaller mapping for the class 
> is created.
> # Restart node1.
> # Start node2 and ensure it joins the cluster with node1.
> # Get instance from cache on node2 added on step #2.
> h2. Expected behavior
> Instance is retrieved and deserialized successfully.
> h2. Actual behavior
> Exception is thrown, no instance is retrieved from cache.
> {noformat}
> Caused by: java.lang.ClassNotFoundException: Unknown pair [platformId=0, 
> typeId=-347776464]
>   at 
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(MarshallerContextImpl.java:392)
>   at 
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:342)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:686)
>   ... 15 more
> {noformat}
> JUnit test is attached to the ticket.



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

[jira] [Comment Edited] (IGNITE-6125) Improve robustness for JDBC driver metadata queries

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6125 at 8/25/17 12:55 PM:


The patch is OK with me.

We have to review {{jdbc2.JdbcDatabaseMetadata}} and implement some methods 
correctly.
- getTypeInfo() now returns empty results set.
- pay attention to the all methods that return empty result set. Now the 
result's metadata isn't available.

Please file separate tickets for these tasks.


was (Author: tledkov-gridgain):
The patch is OK with me.

We have to review {{jdbc2.JdbcDatabaseMetadata}} and implement some methods 
correctly.
- getTypeInfo() now returns empty results set.
- pay attention to the all methods that return empty result set. Now the 
result's metadata isn't available.


> Improve robustness for JDBC driver metadata queries
> ---
>
> Key: IGNITE-6125
> URL: https://issues.apache.org/jira/browse/IGNITE-6125
> Project: Ignite
>  Issue Type: Task
>  Components: clients, jdbc
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata is in worrysome state:
> - Makes frivolous use of toUpperCase() to address former.
> - getPrimaryKeys() never returns anything because of defective use of 
> toUpperCase().
> - No tests on indexes, primary keys, schemas or parameters metadata retrieval.
> - Ignores "catalog" parameter instead of checking if it matches empty catalog.
> - See also IGNITE-6138, IGNITE-6139
> That should be fixes without compromising backwards compatibility too much. 
> Tests may be borrowed from thin client implementation.



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

[jira] [Commented] (IGNITE-6125) Improve robustness for JDBC driver metadata queries

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6125:
--

The patch is OK with me.

We have to review {{jdbc2.JdbcDatabaseMetadata}} and implement some methods 
correctly.
- getTypeInfo() now returns empty results set.
- pay attention to the all methods that return empty result set. Now the 
result's metadata isn't available.


> Improve robustness for JDBC driver metadata queries
> ---
>
> Key: IGNITE-6125
> URL: https://issues.apache.org/jira/browse/IGNITE-6125
> Project: Ignite
>  Issue Type: Task
>  Components: clients, jdbc
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
>
> org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata is in worrysome state:
> - Makes frivolous use of toUpperCase() to address former.
> - getPrimaryKeys() never returns anything because of defective use of 
> toUpperCase().
> - No tests on indexes, primary keys, schemas or parameters metadata retrieval.
> - Ignores "catalog" parameter instead of checking if it matches empty catalog.
> - See also IGNITE-6138, IGNITE-6139
> That should be fixes without compromising backwards compatibility too much. 
> Tests may be borrowed from thin client implementation.



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

[jira] [Commented] (IGNITE-6168) Ability to use TLS client authentication in the TcpDiscoverySpi

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6168:


Github user asfgit closed the pull request at:

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


> Ability to use TLS client authentication in the TcpDiscoverySpi
> ---
>
> Key: IGNITE-6168
> URL: https://issues.apache.org/jira/browse/IGNITE-6168
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Ilya Kasnacheev
>
> I'm working on an application where we use mutual TLS to protect the 
> communication (of different kinds) between the components. It seems like 
> Ignite uses mutual TLS for the TcpCommunicationSpi but not for the 
> TcpDiscoverySpi. Would it be possible to add this ability (one way could 
> perhaps be by implementing IGNITE-6167 so that it can be done through a 
> custom socket factory)?
> I'm aware that there are other client authentication options for the 
> discovery SPI but it would be nice to be able to use the same mechanism 
> everywhere.



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

[jira] [Created] (IGNITE-6187) Cache JdbcDatabaseMetadata in JdbcConnection

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-6187:
---

 Summary: Cache JdbcDatabaseMetadata in JdbcConnection
 Key: IGNITE-6187
 URL: https://issues.apache.org/jira/browse/IGNITE-6187
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc
Affects Versions: 2.1
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


To avoid re-creating it every time



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

[jira] [Commented] (IGNITE-5855) SQL: BigInteger support broken in SQL queries.

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-5855:
-

Unfortunately I'm retracting that patch, it doesn't work as expected.

> SQL: BigInteger support broken in SQL queries.
> --
>
> Key: IGNITE-5855
> URL: https://issues.apache.org/jira/browse/IGNITE-5855
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0, 2.1
>Reporter: Andrew Mashenkov
>Assignee: Ilya Kasnacheev
> Fix For: 2.2
>
> Attachments: BigIntegerKeySqlTest.java
>
>
> Looks like BigInteger support in SQL was broken.
> It works fine on ignite-1.9
> PFA reproducer.



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

[jira] [Issue Comment Deleted] (IGNITE-4662) Server stores cache data on-heap if client has near cache

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4662:
-
Comment: was deleted

(was: what is the relation between near cache on local node and near cache 
nodes?)

> Server stores cache data on-heap if client has near cache
> -
>
> Key: IGNITE-4662
> URL: https://issues.apache.org/jira/browse/IGNITE-4662
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
> Fix For: 2.2
>
>
> Currenlty if client has near cache then server does not move data from onheap 
> to offheap (this is needed since information about near cache nodes - 
> 'readers' - is stored only in on-heap entry).



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

[jira] [Issue Comment Deleted] (IGNITE-4662) Server stores cache data on-heap if client has near cache

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-4662:
---
Comment: was deleted

(was: [~sboikov], is the issue still relevant after AI 2.0 release?)

> Server stores cache data on-heap if client has near cache
> -
>
> Key: IGNITE-4662
> URL: https://issues.apache.org/jira/browse/IGNITE-4662
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Currenlty if client has near cache then server does not move data from onheap 
> to offheap (this is needed since information about near cache nodes - 
> 'readers' - is stored only in on-heap entry).



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

[jira] [Assigned] (IGNITE-4662) Server stores cache data on-heap if client has near cache

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur reassigned IGNITE-4662:
--

Assignee: (was: Vyacheslav Daradur)

> Server stores cache data on-heap if client has near cache
> -
>
> Key: IGNITE-4662
> URL: https://issues.apache.org/jira/browse/IGNITE-4662
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
> Fix For: 2.2
>
>
> Currenlty if client has near cache then server does not move data from onheap 
> to offheap (this is needed since information about near cache nodes - 
> 'readers' - is stored only in on-heap entry).



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

[jira] [Commented] (IGNITE-6168) Ability to use TLS client authentication in the TcpDiscoverySpi

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6168:
--

[~ilyak]
Thank you for your contribution! Looks good for me. I've merged to master.

> Ability to use TLS client authentication in the TcpDiscoverySpi
> ---
>
> Key: IGNITE-6168
> URL: https://issues.apache.org/jira/browse/IGNITE-6168
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Ilya Kasnacheev
>
> I'm working on an application where we use mutual TLS to protect the 
> communication (of different kinds) between the components. It seems like 
> Ignite uses mutual TLS for the TcpCommunicationSpi but not for the 
> TcpDiscoverySpi. Would it be possible to add this ability (one way could 
> perhaps be by implementing IGNITE-6167 so that it can be done through a 
> custom socket factory)?
> I'm aware that there are other client authentication options for the 
> discovery SPI but it would be nice to be able to use the same mechanism 
> everywhere.



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

[jira] [Commented] (IGNITE-6185) Missed toString method in IPFinders

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6185:


GitHub user vsisko opened a pull request:

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

IGNITE-6185 Missed toString IPFinder information.

Missed toString IPFinder information.

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

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

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

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


commit 39c9bd75f6febb5eb036439732a48111670a0f9a
Author: vsisko 
Date:   2017-08-25T10:59:09Z

IGNITE-6185 Missed toString IPFinder information.




> Missed toString method in IPFinders
> ---
>
> Key: IGNITE-6185
> URL: https://issues.apache.org/jira/browse/IGNITE-6185
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 2.2
>
>
> TcpDiscoveryKubernetesIpFinder
> TcpDiscoveryZookeeperIpFinder



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

[jira] [Commented] (IGNITE-6178) Make CheckpointWriteOrder.SEQUENTIAL and checkpointingThreads=4 default in persistent store confguration

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6178:
-

Megred to master branch.

> Make CheckpointWriteOrder.SEQUENTIAL and checkpointingThreads=4 default in 
> persistent store confguration
> 
>
> Key: IGNITE-6178
> URL: https://issues.apache.org/jira/browse/IGNITE-6178
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Andrey Gura
> Fix For: 2.2
>
>
> Multithreaded and ordered checkpoints show better performance on most 
> enviroments.



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

[jira] [Commented] (IGNITE-6041) Update Gettting Started documentation page

[Akmal Chaudhri (JIRA)]

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

Akmal Chaudhri commented on IGNITE-6041:


Denis,

There is a GH repo:

https://github.com/VeryFatBoy/Ignite-Getting-Started

I have invited you to be collaborator. I will upload some code later today,
but not sure if you wanted sub-directories. Either way, I can add some
files quite quickly.

Thank you.

akmal






> Update Gettting Started documentation page
> --
>
> Key: IGNITE-6041
> URL: https://issues.apache.org/jira/browse/IGNITE-6041
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Dmitriy Setrakyan
>Assignee: Denis Magda
>  Labels: docs
>
> Update Getting Started guide in the documentation [1]:
> # show enable/disable persistence flag
> # add SQL connectivity example (create, insert, select)
> # put data grid example right after SQL
> # add collocated computation example to the data grid example
> # add service grid example
> [1] https://apacheignite.readme.io/docs/getting-started



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

[jira] [Updated] (IGNITE-4642) JDBC2: Support enforceJoinOrder flag for JDBC2 driver

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-4642:
-
Summary: JDBC2: Support enforceJoinOrder flag for JDBC2 driver  (was: 
Support enforceJoinOrder flag for JDBC2 driver)

> JDBC2: Support enforceJoinOrder flag for JDBC2 driver
> -
>
> Key: IGNITE-4642
> URL: https://issues.apache.org/jira/browse/IGNITE-4642
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> There is a useful {{enforceJoinOrder}} flag on {{SqlFieldsQuery}}, but it's 
> not exposed on JDBC driver.



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

[jira] [Commented] (IGNITE-6002) Make log message more pretty when instance name is null

[Kousuke Saruta (JIRA)]

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

Kousuke Saruta commented on IGNITE-6002:


[~yzhdanov] If you have time, please review this? Thanks!

> Make log message more pretty when instance name is null
> ---
>
> Key: IGNITE-6002
> URL: https://issues.apache.org/jira/browse/IGNITE-6002
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Kousuke Saruta
>Priority: Minor
>
> When instance name is null, log message containing "null" is shown like as 
> follows.
> {code}
> [09-08-2017 14:49:38][INFO ][grid-timeout-worker-#15%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=de0743ec, name=null, uptime=00:01:00:007]
> {code}



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

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

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-6186:


 Summary: 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
Priority: Minor
 Fix For: 2.2


The method is not thread-safe unless actual parameter is currentThread.



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

[jira] [Comment Edited] (IGNITE-6130) JDBC Thin: JdbcThinResultSet must support types conversions

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6130 at 8/25/17 10:03 AM:


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



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

> JDBC Thin: JdbcThinResultSet must support types conversions 
> 
>
> Key: IGNITE-6130
> URL: https://issues.apache.org/jira/browse/IGNITE-6130
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>
> Now JdbcThinResultSet  doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value:
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal, 
> getBoolean, getString, getNString}}
> See the table *B-6* at the JDBC spec (see also [8.9.5 and 
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).



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

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

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-6184:
---

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


Check if anything else is off, too.



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

[jira] [Assigned] (IGNITE-5794) BinaryMetadata is lost if all server nodes have been restarted

[Amelchev Nikita (JIRA)]

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

Amelchev Nikita reassigned IGNITE-5794:
---

Assignee: Amelchev Nikita

> BinaryMetadata is lost if all server nodes have been restarted
> --
>
> Key: IGNITE-5794
> URL: https://issues.apache.org/jira/browse/IGNITE-5794
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, general
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Amelchev Nikita
>
> Steps to reproduce are described here: 
> http://apache-ignite-users.70518.x6.nabble.com/Problem-with-Messages-after-client-reconnect-td15127.html#none
> This problem occurs because client has metadata in it's local metadata cache 
> and decides that server node should have it too. But server lost it after 
> restart.
> Possible fixes:
> - Make client nodes re-send all contents of local metadata cache after 
> reconnect.
> - If node doesn't have metadata to process incoming message, it should 
> request it from sender node.



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

[jira] [Resolved] (IGNITE-4756) Print info about partition distribution to log

[Vadim Opolski (JIRA)]

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

Vadim Opolski resolved IGNITE-4756.
---
Resolution: Fixed

> Print info about partition distribution to log 
> ---
>
> Key: IGNITE-4756
> URL: https://issues.apache.org/jira/browse/IGNITE-4756
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Vadim Opolski
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> Summarize discussions:
> Add log message in case partitions distribution is not close to even 
> distribution:
> # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default 
> value 0.1 to print warn message only when nodes count differs more then 
> threshold;
> # The statistic is calculated and printed only for the local node;
> # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and 
> calculated for new {{idealAssignment}}.
> # Message format is
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=, 
> expectedPrimary=, 
> exectedBackups=, 
> primary=, backups=].
> {noformat}
> e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes:
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=test, 
> expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), 
> backups=3(75%)].
> {noformat}



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

[jira] [Reopened] (IGNITE-4756) Print info about partition distribution to log

[Vadim Opolski (JIRA)]

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

Vadim Opolski reopened IGNITE-4756:
---

> Print info about partition distribution to log 
> ---
>
> Key: IGNITE-4756
> URL: https://issues.apache.org/jira/browse/IGNITE-4756
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Vadim Opolski
>Priority: Minor
>  Labels: newbie
> Fix For: 2.2
>
>
> Summarize discussions:
> Add log message in case partitions distribution is not close to even 
> distribution:
> # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default 
> value 0.1 to print warn message only when nodes count differs more then 
> threshold;
> # The statistic is calculated and printed only for the local node;
> # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and 
> calculated for new {{idealAssignment}}.
> # Message format is
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=, 
> expectedPrimary=, 
> exectedBackups=, 
> primary=, backups=].
> {noformat}
> e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes:
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=test, 
> expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), 
> backups=3(75%)].
> {noformat}



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

[jira] [Closed] (IGNITE-5586) Visor CMD: Add possibility to activate/deactivate grid

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-5586.
--

> Visor CMD: Add possibility to activate/deactivate grid
> --
>
> Key: IGNITE-5586
> URL: https://issues.apache.org/jira/browse/IGNITE-5586
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.2
>
>
> Extend top command to activate/deactivate grid. Wait fix IGNITE-5584.



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

[jira] [Commented] (IGNITE-5586) Visor CMD: Add possibility to activate/deactivate grid

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5586:


successfully tested

> Visor CMD: Add possibility to activate/deactivate grid
> --
>
> Key: IGNITE-5586
> URL: https://issues.apache.org/jira/browse/IGNITE-5586
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.2
>
>
> Extend top command to activate/deactivate grid. Wait fix IGNITE-5584.



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

[jira] [Commented] (IGNITE-6170) JDBC: consistent product name across all drivers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6170:


GitHub user shroman opened a pull request:

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

IGNITE-6170: JDBC: make consistent product name across all drivers



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

$ git pull https://github.com/shroman/ignite IGNITE-6170

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

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


commit 3dddb61aaaf99d0721e6451c469aeef5b07598b9
Author: shroman 
Date:   2017-08-25T07:34:23Z

IGNITE-6170: JDBC: consistent product name across all drivers




> JDBC: consistent product name across all drivers
> 
>
> Key: IGNITE-6170
> URL: https://issues.apache.org/jira/browse/IGNITE-6170
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Roman Shtykh
> Fix For: 2.2
>
>
> We have 3 JDBC drivers. Some of them report 
> {{DatabaseMetaData#getDatabaseProductName}} as *Ignite*, others as *Ignite 
> Cache*. Neither are correct. 
> It should be *Apache Ignite*.



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

[jira] [Assigned] (IGNITE-6170) JDBC: consistent product name across all drivers

[Roman Shtykh (JIRA)]

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

Roman Shtykh reassigned IGNITE-6170:


Assignee: Roman Shtykh

> JDBC: consistent product name across all drivers
> 
>
> Key: IGNITE-6170
> URL: https://issues.apache.org/jira/browse/IGNITE-6170
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Roman Shtykh
> Fix For: 2.2
>
>
> We have 3 JDBC drivers. Some of them report 
> {{DatabaseMetaData#getDatabaseProductName}} as *Ignite*, others as *Ignite 
> Cache*. Neither are correct. 
> It should be *Apache Ignite*.



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

[jira] [Updated] (IGNITE-6183) Make "Node crashed in the middle of checkpoint" message softer and more informative

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-6183:
---
Description: 
If Ignite node with persistence was stopped during checkpoint, user will see 
message:
{noformat}
Ignite node crashed in the middle of checkpoint. Will restore memory state and 
enforce checkpoint on node start.
{noformat}
Actually, nothing bad happened: node just need to replay WAL delta records to 
complete the checkpoint. It's ordinary case for checkpointing algorithm. 
Though, such word as "crashed" may alarm and confuse user.

  was:
If Ignite node with persistence was stopped during checkpoint, user will see 
message:
{noformat}
Ignite node crashed in the middle of checkpoint. Will restore memory state and 
enforce checkpoint on node start.
{noformat}
Actually, nothing bad happened: node just need to replay WAL to complete the 
checkpoint. It's ordinary case for checkpointing algorithm. Though, such word 
as "crashed" may alarm and confuse user.


> Make "Node crashed in the middle of checkpoint" message softer and more 
> informative
> ---
>
> Key: IGNITE-6183
> URL: https://issues.apache.org/jira/browse/IGNITE-6183
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.2
>
>
> If Ignite node with persistence was stopped during checkpoint, user will see 
> message:
> {noformat}
> Ignite node crashed in the middle of checkpoint. Will restore memory state 
> and enforce checkpoint on node start.
> {noformat}
> Actually, nothing bad happened: node just need to replay WAL delta records to 
> complete the checkpoint. It's ordinary case for checkpointing algorithm. 
> Though, such word as "crashed" may alarm and confuse user.



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

[jira] [Updated] (IGNITE-6183) Make "Node crashed in the middle of checkpoint" message softer and more informative

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-6183:
---
Issue Type: Task  (was: Bug)

> Make "Node crashed in the middle of checkpoint" message softer and more 
> informative
> ---
>
> Key: IGNITE-6183
> URL: https://issues.apache.org/jira/browse/IGNITE-6183
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.2
>
>
> If Ignite node with persistence was stopped during checkpoint, user will see 
> message:
> {noformat}
> Ignite node crashed in the middle of checkpoint. Will restore memory state 
> and enforce checkpoint on node start.
> {noformat}
> Actually, nothing bad happened: node just need to replay WAL to complete the 
> checkpoint. It's ordinary case for checkpointing algorithm. Though, such word 
> as "crashed" may alarm and confuse user.



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

[jira] [Commented] (IGNITE-6183) Make "Node crashed in the middle of checkpoint" message softer and more informative

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-6183:


Devlist discussion: 
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-close-G-stop-name-true-Change-flag-cancel-to-false-td20473.html

> Make "Node crashed in the middle of checkpoint" message softer and more 
> informative
> ---
>
> Key: IGNITE-6183
> URL: https://issues.apache.org/jira/browse/IGNITE-6183
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
> Fix For: 2.2
>
>
> If Ignite node with persistence was stopped during checkpoint, user will see 
> message:
> {noformat}
> Ignite node crashed in the middle of checkpoint. Will restore memory state 
> and enforce checkpoint on node start.
> {noformat}
> Actually, nothing bad happened: node just need to replay WAL to complete the 
> checkpoint. It's ordinary case for checkpointing algorithm. Though, such word 
> as "crashed" may alarm and confuse user.



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

[jira] [Created] (IGNITE-6183) Make "Node crashed in the middle of checkpoint" message softer and more informative

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-6183:
--

 Summary: Make "Node crashed in the middle of checkpoint" message 
softer and more informative
 Key: IGNITE-6183
 URL: https://issues.apache.org/jira/browse/IGNITE-6183
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.2


If Ignite node with persistence was stopped during checkpoint, user will see 
message:
{noformat}
Ignite node crashed in the middle of checkpoint. Will restore memory state and 
enforce checkpoint on node start.
{noformat}
Actually, nothing bad happened: node just need to replay WAL to complete the 
checkpoint. It's ordinary case for checkpointing algorithm. Though, such word 
as "crashed" may alarm and confuse user.



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

[jira] [Assigned] (IGNITE-6178) Make CheckpointWriteOrder.SEQUENTIAL and checkpointingThreads=4 default in persistent store confguration

[Ivan Rakov (JIRA)]

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

Ivan Rakov reassigned IGNITE-6178:
--

Assignee: Andrey Gura  (was: Ivan Rakov)

> Make CheckpointWriteOrder.SEQUENTIAL and checkpointingThreads=4 default in 
> persistent store confguration
> 
>
> Key: IGNITE-6178
> URL: https://issues.apache.org/jira/browse/IGNITE-6178
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Andrey Gura
> Fix For: 2.2
>
>
> Multithreaded and ordered checkpoints show better performance on most 
> enviroments.



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