[jira] [Commented] (IGNITE-5733) Activate/deactivate cluster through http-rest api
[ https://issues.apache.org/jira/browse/IGNITE-5733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169625#comment-16169625 ] Alexander Belyak commented on IGNITE-5733: -- [~agoncharuk] test added, can U take a look again? > Activate/deactivate cluster through http-rest api > - > > Key: IGNITE-5733 > URL: https://issues.apache.org/jira/browse/IGNITE-5733 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Minor > Fix For: 2.3 > > > Need to add command to get/set cluster active flag into http rest api. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5136) GridLogThrottle memory leak
[ https://issues.apache.org/jira/browse/IGNITE-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169413#comment-16169413 ] Vadim Opolski commented on IGNITE-5136: --- [~zstan] [~avinogradov] In my opinion tests look good. [TC Overview | https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_RunAll_Ignite20Tests=pull%2F2674%2Fmerge=buildTypeStatusDiv] > GridLogThrottle memory leak > --- > > Key: IGNITE-5136 > URL: https://issues.apache.org/jira/browse/IGNITE-5136 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Stanilovsky Evgeny >Assignee: Vadim Opolski > > class GridLogThrottle stores throttle info into map and noone clears it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang
[
https://issues.apache.org/jira/browse/IGNITE-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-6181:
--
Description:
Incorrectly handled transactions (not calling commit, rollback or close) are
staying in grid forever, potentially holding locks and preventing exchange
start.
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
[jira] [Commented] (IGNITE-6181) Tx is not rolled back on timeout leading to potential whole grid hang
[
https://issues.apache.org/jira/browse/IGNITE-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169254#comment-16169254
]
Alexei Scherbakov commented on IGNITE-6181:
---
Fixed some issues with concurrent deadlock detection. If tx is rolled back due
to reaching timeout because of deadlock, it might not be reported correctly.
Looks like test [1] is not working correctly on low timeout values <= 100 ms
Larger timeouts work fine. Investigation is needed
TC result: https://ci.ignite.apache.org/viewLog.html?buildId=833829
[1] TxRollbackOnTimeoutTest#testDeadlockUnblockedOnTimeout3
> 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: Improvement
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
>Assignee: 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(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();
>
[jira] [Commented] (IGNITE-6403) IgniteSqlNotNullConstraintTest.testTransactionalAddColumnNotNullCheckDmlInsertValues fails periodically
[
https://issues.apache.org/jira/browse/IGNITE-6403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169227#comment-16169227
]
Vladimir Ozerov commented on IGNITE-6403:
-
May be we can just wait for local client futures. Need to investigate this
further.
> IgniteSqlNotNullConstraintTest.testTransactionalAddColumnNotNullCheckDmlInsertValues
> fails periodically
> ---
>
> Key: IGNITE-6403
> URL: https://issues.apache.org/jira/browse/IGNITE-6403
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> Looks like we have a bug in {{ALTER TABLE}} - column is not visible after
> command is completed:
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: Column "NAME" not found; SQL
> statement:
> INSERT INTO test(id, name, age) VALUES (1, 'ok', 1), (2, NULLIF('a', 'a'),
> 2), (3, 'ok', 3) [42122-195]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6416) SQL: DDL tests should not check internal structures, but rather rely on expected public behavior
Vladimir Ozerov created IGNITE-6416: --- Summary: SQL: DDL tests should not check internal structures, but rather rely on expected public behavior Key: IGNITE-6416 URL: https://issues.apache.org/jira/browse/IGNITE-6416 Project: Ignite Issue Type: Task Components: sql Affects Versions: 2.3 Reporter: Vladimir Ozerov Assignee: Alexander Paschenko Fix For: 2.3 We need to review our DDL tests. Looks like there are a lot waits in the tests which mask concurrency bugs (e.g. see IGNITE-6403). Instead, we should do the following: 1) If we want to tests asynchronous propagation of changes to clients, separate test should be created for this 2) For all other cases we should not use private API at all, and do not perform any waits. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6415) ALTER TABLE: investigate why descriptor is not updated from GridQueryProcessor#onLocalOperationFinished
Vladimir Ozerov created IGNITE-6415:
---
Summary: ALTER TABLE: investigate why descriptor is not updated
from GridQueryProcessor#onLocalOperationFinished
Key: IGNITE-6415
URL: https://issues.apache.org/jira/browse/IGNITE-6415
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.3
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
Fix For: 2.3
For {{CREATE INDEX}} and {{DROP INDEX}} our DDL engine works as follows:
1) Update H2 structures from DDL worker thread
2) Then update type descriptor from
{{GridQueryProcessor#onLocalOperationFinished}}
For some reason {{ALTER TABLE}} handled differently, and we first update
descriptor, then update H2. See
{{GridQueryProcessor#processSchemaOperationLocal}}.
Two questions:
1) Why descriptor is updated before H2? In this case we may endup in
inconsistent state if H2 failed for some reason
2) Why we decided not to follow {{CREATE/DROP INDEX}} approach?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6403) IgniteSqlNotNullConstraintTest.testTransactionalAddColumnNotNullCheckDmlInsertValues fails periodically
[
https://issues.apache.org/jira/browse/IGNITE-6403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169224#comment-16169224
]
Vladimir Ozerov commented on IGNITE-6403:
-
[~al.psc], [~skalashnikov], I debugged the problem.
{{IgniteSqlNotNullConstraintTest}} performs all SQL operations against client
node. And our DDL engine doesn't wait for clients to respond before completing
client future. For this reason, by the time client is notified about
successfull completion, it might not have applied changes yet. {{CREATE TABLE}}
is not affected by this problem because we have special re-try logic for this.
But {{ALTER TABLE}} is affected. I think {{CREATE INDEX}} is also broken.
When I changed the test so that SQL is executed on server nodes, everything
works fine.
> IgniteSqlNotNullConstraintTest.testTransactionalAddColumnNotNullCheckDmlInsertValues
> fails periodically
> ---
>
> Key: IGNITE-6403
> URL: https://issues.apache.org/jira/browse/IGNITE-6403
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.3
>
>
> Looks like we have a bug in {{ALTER TABLE}} - column is not visible after
> command is completed:
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: Column "NAME" not found; SQL
> statement:
> INSERT INTO test(id, name, age) VALUES (1, 'ok', 1), (2, NULLIF('a', 'a'),
> 2), (3, 'ok', 3) [42122-195]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
