[jira] [Commented] (IGNITE-15349) Fix feedback #4
[ https://issues.apache.org/jira/browse/IGNITE-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402414#comment-17402414 ] Denis A. Magda commented on IGNITE-15349: - [~igusev] - done! > Fix feedback #4 > --- > > Key: IGNITE-15349 > URL: https://issues.apache.org/jira/browse/IGNITE-15349 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > We need to update text on > [https://ignite.apache.org/docs/latest/sql-reference/transactions#] to > include ROLLBACK command -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15355) Test method corruptDataEntry works incorrecly for in-memory and persistence caches
Maxim Muzafarov created IGNITE-15355:
Summary: Test method corruptDataEntry works incorrecly for
in-memory and persistence caches
Key: IGNITE-15355
URL: https://issues.apache.org/jira/browse/IGNITE-15355
Project: Ignite
Issue Type: Test
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
Fix For: 2.12
There are several issues with the {{corruptDataEntry}} method wich are need to
be fixed:
- public package for org.apache.ignite.TestStorageUtils#corruptDataEntry needs
to change to internal
- duplicated code org.apache.ignite.TestStorageUtils#corruptDataEntry and
org.apache.ignite.util.GridCommandHandlerClusterByClassTest#corruptDataEntry
- corruptDataEntry can't be uses 'as is' for in-memory and persistence caches
since it has dependency at the {{applyUpdate}} which has meaning only for
persistence.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15355) Test method corruptDataEntry works incorrecly for in-memory and persistence caches
[
https://issues.apache.org/jira/browse/IGNITE-15355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-15355:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Test method corruptDataEntry works incorrecly for in-memory and persistence
> caches
> --
>
> Key: IGNITE-15355
> URL: https://issues.apache.org/jira/browse/IGNITE-15355
> Project: Ignite
> Issue Type: Test
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.12
>
>
> There are several issues with the {{corruptDataEntry}} method wich are need
> to be fixed:
> - public package for org.apache.ignite.TestStorageUtils#corruptDataEntry
> needs to change to internal
> - duplicated code org.apache.ignite.TestStorageUtils#corruptDataEntry and
> org.apache.ignite.util.GridCommandHandlerClusterByClassTest#corruptDataEntry
> - corruptDataEntry can't be uses 'as is' for in-memory and persistence caches
> since it has dependency at the {{applyUpdate}} which has meaning only for
> persistence.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15354) Investigate Maven Shade plugin capabilities for Guava
[ https://issues.apache.org/jira/browse/IGNITE-15354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-15354: - Description: Since we want to somehow shade the Guava library into the Ignite 3 project, we need to understand if it is possible to do using the Shade plugin ([https://maven.apache.org/plugins/maven-shade-plugin/)] . In particular, the following should be investigated: # How to re-write the Guava package names in transitive dependencies (e.g. Calcite). # How to minimize the shaded JAR (remove unneeded classes to reduce the JAR size). was: Since we want to somehow shade the Guava library into the Ignite 3 project, we need to investigate if it is possible to do using the Shade plugin ([https://maven.apache.org/plugins/maven-shade-plugin/)] . In particular, the following should be investigated: # How to re-write the Guava package names in transitive dependencies (e.g. Calcite). # How to minimize the shaded JAR (remove unneeded classes to reduce the JAR size). > Investigate Maven Shade plugin capabilities for Guava > - > > Key: IGNITE-15354 > URL: https://issues.apache.org/jira/browse/IGNITE-15354 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 3.0.0-alpha3 > > > Since we want to somehow shade the Guava library into the Ignite 3 project, > we need to understand if it is possible to do using the Shade plugin > ([https://maven.apache.org/plugins/maven-shade-plugin/)] . In particular, the > following should be investigated: > # How to re-write the Guava package names in transitive dependencies (e.g. > Calcite). > # How to minimize the shaded JAR (remove unneeded classes to reduce the JAR > size). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15354) Investigate Maven Shade plugin capabilities for Guava
[ https://issues.apache.org/jira/browse/IGNITE-15354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-15354: - Summary: Investigate Maven Shade plugin capabilities for Guava (was: Ivestigate Maven Shade plugin capabilities for Guava) > Investigate Maven Shade plugin capabilities for Guava > - > > Key: IGNITE-15354 > URL: https://issues.apache.org/jira/browse/IGNITE-15354 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 3.0.0-alpha3 > > > Since we want to somehow shade the Guava library into the Ignite 3 project, > we need to investigate if it is possible to do using the Shade plugin > ([https://maven.apache.org/plugins/maven-shade-plugin/)] . In particular, the > following should be investigated: > # How to re-write the Guava package names in transitive dependencies (e.g. > Calcite). > # How to minimize the shaded JAR (remove unneeded classes to reduce the JAR > size). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15354) Ivestigate Maven Shade plugin capabilities for Guava
[ https://issues.apache.org/jira/browse/IGNITE-15354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-15354: - Description: Since we want to somehow shade the Guava library into the Ignite 3 project, we need to investigate if it is possible to do using the Shade plugin ([https://maven.apache.org/plugins/maven-shade-plugin/)] . In particular, the following should be investigated: # How to re-write the Guava package names in transitive dependencies (e.g. Calcite). # How to minimize the shaded JAR (remove unneeded classes to reduce the JAR size). > Ivestigate Maven Shade plugin capabilities for Guava > > > Key: IGNITE-15354 > URL: https://issues.apache.org/jira/browse/IGNITE-15354 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 3.0.0-alpha3 > > > Since we want to somehow shade the Guava library into the Ignite 3 project, > we need to investigate if it is possible to do using the Shade plugin > ([https://maven.apache.org/plugins/maven-shade-plugin/)] . In particular, the > following should be investigated: > # How to re-write the Guava package names in transitive dependencies (e.g. > Calcite). > # How to minimize the shaded JAR (remove unneeded classes to reduce the JAR > size). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15354) Ivestigate Maven Shade plugin capabilities for Guava
Aleksandr Polovtcev created IGNITE-15354: Summary: Ivestigate Maven Shade plugin capabilities for Guava Key: IGNITE-15354 URL: https://issues.apache.org/jira/browse/IGNITE-15354 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev Fix For: 3.0.0-alpha3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15353) CPP: Ignored loading openssl libraries from OPENSSL_HOME on Windows
[
https://issues.apache.org/jira/browse/IGNITE-15353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15353:
-
Description:
Currently, logic looks like this
{code}
libssl = LoadSslLibrary("libssl");
if (!libssl.IsLoaded())
{
libcrypto = LoadSslLibrary("libcrypto-1_1-x64");
libssl = LoadSslLibrary("libssl-1_1-x64");
}
if (!libssl.IsLoaded())
{
libeay32 = LoadSslLibrary("libeay32");
ssleay32 = LoadSslLibrary("ssleay32");
}
{code}
1. First line is for linux, it is ok.
2. Second line has a few problem.
* On 64 bit -- If OPENSSL_HOME contains 1.0.x version of openssl, it is ignored
and another version is loaded.
* On 32 bit -- naming is different, libcrypto-1_1 and libssl-1_1, so loading
will fail
was:
Currently, logic looks like this
{{code}}
libssl = LoadSslLibrary("libssl");
if (!libssl.IsLoaded())
{
libcrypto = LoadSslLibrary("libcrypto-1_1-x64");
libssl = LoadSslLibrary("libssl-1_1-x64");
}
if (!libssl.IsLoaded())
{
libeay32 = LoadSslLibrary("libeay32");
ssleay32 = LoadSslLibrary("ssleay32");
}
{{code}}
1. First line is for linux, it is ok.
2. Second line has a few problem.
* On 64 bit -- If OPENSSL_HOME contains 1.0.x version of openssl, it is ignored
and another version is loaded.
* On 32 bit -- naming is different, libcrypto-1_1 and libssl-1_1, so loading
will fail
> CPP: Ignored loading openssl libraries from OPENSSL_HOME on Windows
> ---
>
> Key: IGNITE-15353
> URL: https://issues.apache.org/jira/browse/IGNITE-15353
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Daschinsky
>Assignee: Igor Sapego
>Priority: Major
> Labels: platform
>
> Currently, logic looks like this
> {code}
> libssl = LoadSslLibrary("libssl");
> if (!libssl.IsLoaded())
> {
> libcrypto = LoadSslLibrary("libcrypto-1_1-x64");
> libssl = LoadSslLibrary("libssl-1_1-x64");
> }
> if (!libssl.IsLoaded())
> {
> libeay32 = LoadSslLibrary("libeay32");
> ssleay32 = LoadSslLibrary("ssleay32");
> }
> {code}
> 1. First line is for linux, it is ok.
> 2. Second line has a few problem.
> * On 64 bit -- If OPENSSL_HOME contains 1.0.x version of openssl, it is
> ignored and another version is loaded.
> * On 32 bit -- naming is different, libcrypto-1_1 and libssl-1_1, so loading
> will fail
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15353) CPP: Ignored loading openssl libraries from OPENSSL_HOME on Windows
[
https://issues.apache.org/jira/browse/IGNITE-15353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15353:
-
Labels: platform (was: )
> CPP: Ignored loading openssl libraries from OPENSSL_HOME on Windows
> ---
>
> Key: IGNITE-15353
> URL: https://issues.apache.org/jira/browse/IGNITE-15353
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Daschinsky
>Assignee: Igor Sapego
>Priority: Major
> Labels: platform
>
> Currently, logic looks like this
> {{code}}
> libssl = LoadSslLibrary("libssl");
> if (!libssl.IsLoaded())
> {
> libcrypto = LoadSslLibrary("libcrypto-1_1-x64");
> libssl = LoadSslLibrary("libssl-1_1-x64");
> }
> if (!libssl.IsLoaded())
> {
> libeay32 = LoadSslLibrary("libeay32");
> ssleay32 = LoadSslLibrary("ssleay32");
> }
> {{code}}
> 1. First line is for linux, it is ok.
> 2. Second line has a few problem.
> * On 64 bit -- If OPENSSL_HOME contains 1.0.x version of openssl, it is
> ignored and another version is loaded.
> * On 32 bit -- naming is different, libcrypto-1_1 and libssl-1_1, so loading
> will fail
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15353) CPP: Ignored loading openssl libraries from OPENSSL_HOME on Windows
Ivan Daschinsky created IGNITE-15353:
Summary: CPP: Ignored loading openssl libraries from OPENSSL_HOME
on Windows
Key: IGNITE-15353
URL: https://issues.apache.org/jira/browse/IGNITE-15353
Project: Ignite
Issue Type: Bug
Reporter: Ivan Daschinsky
Assignee: Igor Sapego
Currently, logic looks like this
{{code}}
libssl = LoadSslLibrary("libssl");
if (!libssl.IsLoaded())
{
libcrypto = LoadSslLibrary("libcrypto-1_1-x64");
libssl = LoadSslLibrary("libssl-1_1-x64");
}
if (!libssl.IsLoaded())
{
libeay32 = LoadSslLibrary("libeay32");
ssleay32 = LoadSslLibrary("ssleay32");
}
{{code}}
1. First line is for linux, it is ok.
2. Second line has a few problem.
* On 64 bit -- If OPENSSL_HOME contains 1.0.x version of openssl, it is ignored
and another version is loaded.
* On 32 bit -- naming is different, libcrypto-1_1 and libssl-1_1, so loading
will fail
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14943) testInstallLargeSnapshotWithThrottle is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402269#comment-17402269
]
Alexey Scherbakov commented on IGNITE-14943:
[~maliev]
LGTM
Merged to master #0983c2a98f510ebbb71d2e4b9f010f64b6174dab
> testInstallLargeSnapshotWithThrottle is flaky
> --
>
> Key: IGNITE-14943
> URL: https://issues.apache.org/jira/browse/IGNITE-14943
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Node has failed to caugh up due to timeout by unclear reason.
> https://ci.ignite.apache.org/viewLog.html?buildId=6052568=ignite3_Test_IntegrationTests_IntegrationTests
> UPD: The root cause of the test's flakiness is possible race in
> {{ThreadId.setError}} method. More details and investigation see in JRaft
> original repo https://github.com/sofastack/sofa-jraft/issues/664
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15283) Remove duplicated managing of CacheDataStore in offheap manager
[
https://issues.apache.org/jira/browse/IGNITE-15283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402254#comment-17402254
]
Aleksey Plekhanov commented on IGNITE-15283:
[~mmuzaf], LGTM.
> Remove duplicated managing of CacheDataStore in offheap manager
> ---
>
> Key: IGNITE-15283
> URL: https://issues.apache.org/jira/browse/IGNITE-15283
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The cache group patition topology provides the same view on created cache
> data stores. , so managing of data stores in the offeap manager can be
> omitted.
> {code}
> protected final ConcurrentMap partDataStores =
> new ConcurrentHashMap<>();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11949) Yardstick benchmarks for WAL page snapshot compression
[ https://issues.apache.org/jira/browse/IGNITE-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402247#comment-17402247 ] Maxim Muzafarov commented on IGNITE-11949: -- [~alex_pl] Do we need anything else to proceed? > Yardstick benchmarks for WAL page snapshot compression > -- > > Key: IGNITE-11949 > URL: https://issues.apache.org/jira/browse/IGNITE-11949 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-20, yardstick > Time Spent: 10m > Remaining Estimate: 0h > > WAL page snapshots compression (implemented by IGNITE-11336) can be enabled > by modifying config.xml file. It will be better to configure benchmarks by > command line options. > Also, some new probes (WAL size for example) can be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11949) Yardstick benchmarks for WAL page snapshot compression
[ https://issues.apache.org/jira/browse/IGNITE-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11949: - Fix Version/s: 2.12 > Yardstick benchmarks for WAL page snapshot compression > -- > > Key: IGNITE-11949 > URL: https://issues.apache.org/jira/browse/IGNITE-11949 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-20, yardstick > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > WAL page snapshots compression (implemented by IGNITE-11336) can be enabled > by modifying config.xml file. It will be better to configure benchmarks by > command line options. > Also, some new probes (WAL size for example) can be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12349) File transmission can cause the cluster to freeze.
[
https://issues.apache.org/jira/browse/IGNITE-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin resolved IGNITE-12349.
---
Resolution: Cannot Reproduce
I think this has been fixed in IGNITE-13098.
> File transmission can cause the cluster to freeze.
> --
>
> Key: IGNITE-12349
> URL: https://issues.apache.org/jira/browse/IGNITE-12349
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Pavel Pereslegin
>Assignee: Maxim Muzafarov
>Priority: Critical
>
> When we initiating file transmission - a timeout object with mutable endTime
> is added to the timeout processor "queue" (see
> TcpCommunicationSpi#openChannel).
> Since endTime is mutable, a timeout for this object will never occur,
> moreover, at some point, this object will be the first in the "queue" and
> TimeoutProcessor will stop working at all.
> Reproducer
> {code:java}
> public class FileTransmissionTimeoutProcessorTest extends
> GridCommonAbstractTest {
> @After
> public void after() throws Exception {
> cleanPersistenceDir();
> stopAllGrids();
> }
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration()
> .setPersistenceEnabled(true)
> .setMaxSize(500L * 1024 * 1024)))
> .setCacheConfiguration(new CacheConfiguration Integer>(DEFAULT_CACHE_NAME));
> }
> @Test
> public void testChannelTimeoutObject() throws Exception {
> IgniteEx snd = startGrid(0);
> IgniteEx rcv = startGrid(1);
> // Do some transfer between nodes.
> initiateFileTransfer(snd, rcv);
> GridFutureAdapter fut = new GridFutureAdapter<>();
> // Add new timeout object after file transmission timeout object.
> snd.context().timeout().addTimeoutObject(new
> GridTimeoutObjectAdapter(DFLT_CONN_TIMEOUT + 1_000) {
> @Override public void onTimeout() {
> fut.onDone(true);
> }
> });
> // The timeout processor will hang on the file transfer timeout
> object and will never complete the remaining tasks.
> boolean success = fut.get(DFLT_CONN_TIMEOUT + 30_000);
> assertTrue(success);
> }
> /** */
> private void initiateFileTransfer(IgniteEx snd, IgniteEx rcv) throws
> IOException, IgniteCheckedException, InterruptedException {
> snd.cluster().active(true);
> awaitPartitionMapExchange();
> try (IgniteDataStreamer dataStreamer =
> snd.dataStreamer(DEFAULT_CACHE_NAME)) {
> dataStreamer.allowOverwrite(true);
> for (int i = 0; i < 10_000; i++)
> dataStreamer.addData(i, i + DEFAULT_CACHE_NAME.hashCode());
> }
> Map fileSizes = new HashMap<>();
> Map fileCrcs = new HashMap<>();
> Map fileParams = new HashMap<>();
>
> assertTrue(snd.context().io().fileTransmissionSupported(rcv.localNode()));
> File tempStore = U.resolveWorkDirectory(U.defaultWorkDirectory(),
> "ctmp", true);
>
> rcv.context().io().addTransmissionHandler(GridTopic.TOPIC_CACHE.topic("test",
> 0), new TransmissionHandler() {
> @Override public void onException(UUID nodeId, Throwable err) {
> // No-op.
> }
> @Override public String filePath(UUID nodeId, TransmissionMeta
> fileMeta) {
> return new File(tempStore, fileMeta.name()).getAbsolutePath();
> }
> @Override public Consumer chunkHandler(UUID nodeId,
> TransmissionMeta initMeta) {
> return null;
> }
> @Override public Consumer fileHandler(UUID nodeId,
> TransmissionMeta initMeta) {
> return new Consumer() {
> @Override public void accept(File file) {
> assertTrue(fileSizes.containsKey(file.getName()));
> // Save all params.
> fileParams.putAll(initMeta.params());
> }
> };
> }
> });
> IgniteInternalCache defCache =
> snd.cachex(DEFAULT_CACHE_NAME);
> File cacheDirIg0 = ((FilePageStoreManager)(defCache).context()
> .shared()
> .pageStore()).cacheWorkDir(defCache.configuration());
> File[] cacheParts = cacheDirIg0.listFiles(new FilenameFilter() {
> @Override public boolean accept(File dir, String name) {
> return
[jira] [Resolved] (IGNITE-14137) Detect and fix failures reasons (nightly runs fails)
[ https://issues.apache.org/jira/browse/IGNITE-14137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-14137. --- Resolution: Fixed > Detect and fix failures reasons (nightly runs fails) > > > Key: IGNITE-14137 > URL: https://issues.apache.org/jira/browse/IGNITE-14137 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Blocker > > Jenkins runs fails, 1-4 ... 60 tests affected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14278) Design public Index API
[ https://issues.apache.org/jira/browse/IGNITE-14278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402224#comment-17402224 ] Maksim Timonin commented on IGNITE-14278: - result is IEP-71 https://cwiki.apache.org/confluence/display/IGNITE/IEP-71%3A+Public+API+for+secondary+index+search > Design public Index API > --- > > Key: IGNITE-14278 > URL: https://issues.apache.org/jira/browse/IGNITE-14278 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > > There is a feature request - provide opportunity to index non-key fields for > non-SQL caches. > Need to check opportunity to implement it and design API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14278) Design public Index API
[ https://issues.apache.org/jira/browse/IGNITE-14278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin resolved IGNITE-14278. - Resolution: Resolved > Design public Index API > --- > > Key: IGNITE-14278 > URL: https://issues.apache.org/jira/browse/IGNITE-14278 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > > There is a feature request - provide opportunity to index non-key fields for > non-SQL caches. > Need to check opportunity to implement it and design API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14954) Calcite engine. MONTHNAME, DAYNAME functions fail due to null locale
[
https://issues.apache.org/jira/browse/IGNITE-14954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14954:
---
Labels: calcite3-required (was: )
> Calcite engine. MONTHNAME, DAYNAME functions fail due to null locale
>
>
> Key: IGNITE-14954
> URL: https://issues.apache.org/jira/browse/IGNITE-14954
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query
> {{SELECT MONTHNAME(CAST('1992-05-31' AS DATE));}}
> fails with exception
> {code}
> class org.apache.ignite.IgniteException: Unexpected exception
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:244)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.NullPointerException: locale
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at
> java.base/java.time.format.DateTimeFormatter.(DateTimeFormatter.java:1421)
> at
> java.base/java.time.format.DateTimeFormatter.withLocale(DateTimeFormatter.java:1463)
> at
> org.apache.calcite.runtime.SqlFunctions.monthNameWithDate(SqlFunctions.java:2391)
> at SC.execute(Unknown Source)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl$ProjectImpl.apply(ExpressionFactoryImpl.java:387)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ProjectNode.push(ProjectNode.java:63)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:239)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14597) Calcite engine. Exception when using FIRST
[
https://issues.apache.org/jira/browse/IGNITE-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402218#comment-17402218
]
Aleksey Plekhanov commented on IGNITE-14597:
[~tledkov-gridgain], thanks for the review! Merged to sql-calcite branch.
> Calcite engine. Exception when using FIRST
> --
>
> Key: IGNITE-14597
> URL: https://issues.apache.org/jira/browse/IGNITE-14597
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Exception is thrown when running a query {{SELECT FIRST(NULL::DECIMAL)}}
> {code:java}
> class org.apache.ignite.IgniteException: Error at:
> decimal_aggregates.test:10. sql: SELECT FIRST(NULL::DECIMAL)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:518)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:93)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> plan query.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:541)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:398)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:246)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:513)
> ... 3 more
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 8 to line 1, column 27: Function 'FIRST(NULL :: DECIMAL, 0)' can only
> be used in MATCH_RECOGNIZE
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:467)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:883)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:868)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5043)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5574)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateCall(IgniteSqlValidator.java:230)
> at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
> at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:273)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4259)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4234)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3474)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:176)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1067)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateNamespace(IgniteSqlValidator.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1041)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:232)
> at
>
[jira] [Updated] (IGNITE-14597) Calcite engine. Exception when using FIRST
[
https://issues.apache.org/jira/browse/IGNITE-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14597:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite engine. Exception when using FIRST
> --
>
> Key: IGNITE-14597
> URL: https://issues.apache.org/jira/browse/IGNITE-14597
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite3-required
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Exception is thrown when running a query {{SELECT FIRST(NULL::DECIMAL)}}
> {code:java}
> class org.apache.ignite.IgniteException: Error at:
> decimal_aggregates.test:10. sql: SELECT FIRST(NULL::DECIMAL)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:518)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:93)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> plan query.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:541)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:398)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:246)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:513)
> ... 3 more
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 8 to line 1, column 27: Function 'FIRST(NULL :: DECIMAL, 0)' can only
> be used in MATCH_RECOGNIZE
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:467)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:883)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:868)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5043)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5574)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateCall(IgniteSqlValidator.java:230)
> at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
> at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:273)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4259)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4234)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3474)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:176)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1067)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateNamespace(IgniteSqlValidator.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1041)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:232)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1016)
> at
>
[jira] [Updated] (IGNITE-15352) Thin 3.0 Perf: Compact scale for decimals.
[ https://issues.apache.org/jira/browse/IGNITE-15352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15352: -- Fix Version/s: 3.0 > Thin 3.0 Perf: Compact scale for decimals. > -- > > Key: IGNITE-15352 > URL: https://issues.apache.org/jira/browse/IGNITE-15352 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-alpha3 >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-76, ignite-3 > Fix For: 3.0 > > > We have to write `scale` within the Decimal value. > Let's write `scale` in VarInt format, as in most cases 1-byte will be > sufficient for this. > https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15352) Thin 3.0 Perf: Compact scale for decimals.
[ https://issues.apache.org/jira/browse/IGNITE-15352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15352: -- Priority: Minor (was: Major) > Thin 3.0 Perf: Compact scale for decimals. > -- > > Key: IGNITE-15352 > URL: https://issues.apache.org/jira/browse/IGNITE-15352 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-alpha3 >Reporter: Andrey Mashenkov >Priority: Minor > Labels: iep-76, ignite-3 > Fix For: 3.0 > > > We have to write `scale` within the Decimal value. > Let's write `scale` in VarInt format, as in most cases 1-byte will be > sufficient for this. > https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15352) Thin 3.0 Perf: Compact scale for decimals.
[ https://issues.apache.org/jira/browse/IGNITE-15352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15352: -- Description: We have to write `scale` within the Decimal value. Let's write `scale` in VarInt format, as in most cases 1-byte will be sufficient for this. https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0 was: Add support for custom data types like BitSet, Decimal, Temporal to the Ignite 3.0 thin client. https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0 > Thin 3.0 Perf: Compact scale for decimals. > -- > > Key: IGNITE-15352 > URL: https://issues.apache.org/jira/browse/IGNITE-15352 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-alpha3 >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-76, ignite-3 > Fix For: 3.0.0-alpha3 > > > We have to write `scale` within the Decimal value. > Let's write `scale` in VarInt format, as in most cases 1-byte will be > sufficient for this. > https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15352) Thin 3.0 Perf: Compact scale for decimals.
[ https://issues.apache.org/jira/browse/IGNITE-15352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15352: -- Fix Version/s: (was: 3.0.0-alpha3) > Thin 3.0 Perf: Compact scale for decimals. > -- > > Key: IGNITE-15352 > URL: https://issues.apache.org/jira/browse/IGNITE-15352 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-alpha3 >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-76, ignite-3 > > We have to write `scale` within the Decimal value. > Let's write `scale` in VarInt format, as in most cases 1-byte will be > sufficient for this. > https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15352) Thin 3.0 Perf: Compact scale for decimals.
Andrey Mashenkov created IGNITE-15352: - Summary: Thin 3.0 Perf: Compact scale for decimals. Key: IGNITE-15352 URL: https://issues.apache.org/jira/browse/IGNITE-15352 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 3.0.0-alpha3 Reporter: Andrey Mashenkov Assignee: Andrey Mashenkov Fix For: 3.0.0-alpha3 Add support for custom data types like BitSet, Decimal, Temporal to the Ignite 3.0 thin client. https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15352) Thin 3.0 Perf: Compact scale for decimals.
[ https://issues.apache.org/jira/browse/IGNITE-15352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-15352: - Assignee: (was: Andrey Mashenkov) > Thin 3.0 Perf: Compact scale for decimals. > -- > > Key: IGNITE-15352 > URL: https://issues.apache.org/jira/browse/IGNITE-15352 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-alpha3 >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-76, ignite-3 > Fix For: 3.0.0-alpha3 > > > Add support for custom data types like BitSet, Decimal, Temporal to the > Ignite 3.0 thin client. > https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15163) Thin 3.0: Add custom data types support
[ https://issues.apache.org/jira/browse/IGNITE-15163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-15163: - Assignee: Andrey Mashenkov (was: Pavel Tupitsyn) > Thin 3.0: Add custom data types support > --- > > Key: IGNITE-15163 > URL: https://issues.apache.org/jira/browse/IGNITE-15163 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-alpha3 >Reporter: Pavel Tupitsyn >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-76, ignite-3 > Fix For: 3.0.0-alpha3 > > > Add support for custom data types like BitSet, Decimal, Temporal to the > Ignite 3.0 thin client. > https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15351) Research possibility of having caching layer on top of RocksDB partitions
[ https://issues.apache.org/jira/browse/IGNITE-15351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15351: --- Description: In Ignite 2.x there's a concept of "Data Regions", which is basically a set of fixed-sized in-memory caches that store data for a number of cache groups (let's ignore system region and similar stuff for now). It is very convenient and represents a core design feature in Apache Ignite - In-Memory Database. Currently, Page Memory subsystem is not yet ported to Ignite 3.x codebase. Instead, there's an implementation based on RocksDB database to store data persistently. But, this implementation is very simple and naive. There's no notion of in-memory cache across multiple tables, meaning that it can't be called an In-Memory Database. We should investigate ways to add this concept back on top of RocksDB implementation. There are several things to investigate here: * how do you set up rocksdb properly and control its memory consumption - we should allow some configuration and a meaningful set of defaults; * how do you put a cache on top of several rocksdb instances. This is actually pretty easy, just use "org.rocksdb.Options#setRowCache(org.rocksdb.Cache)", it has LRU and Clock implementations. A way to configure it is still required; * how do we introduce data regions into our system? I see something like this: ** list of regions is either a node or cluster configuration; ** name of the region is a property of every individual table or table group (or whatever else we'll be having). Last proposition is a bit tricky, cause it won't look like "create table with rocks engine with Clock cache...", it would look like "create table in region Foo". We have to conceptualize all these things and come up with proper naming at least. was: In Ignite 2.x there's a concept of "Data Regions", which is basically a set of fixed-sized in-memory caches that store data for a number of cache groups (let's ignore system region and similar stuff for now). It is very convenient and represents a core design feature in Apache Ignite - In-Memory Database. Currently, Page Memory subsystem is not yet ported to Ignite 3.x codebase. Instead, there's an implementation based on RocksDB database to store data persistently. But, this implementation is very simple and naive. There's no notion of in-memory cache across multiple tables, meaning that it can't be called an In-Memory Database. We should investigate ways to add this concept back on top of RocksDB implementation. There are several things to investigate here: * how do you set up rocksdb properly and control its memory consumption - we should allow some configuration and a meaningful set of defaults; * how do you put a cache on top of several rocksdb instances. This is actually pretty easy, just use "org.rocksdb.Options#setRowCache(org.rocksdb.Cache)", but a way to configure it is still required; * how do we introduce data regions into our system? I see something like this: ** list of regions is either a node or cluster configuration; ** name of the region is a property of every individual table or table group (or whatever else we'll be having). Last proposition is a bit tricky, cause it won't look like "create table with rocks engine with Clock cache...", it would look like "create table in region Foo". We have to conceptualize all this things and come up with proper naming at least. > Research possibility of having caching layer on top of RocksDB partitions > - > > Key: IGNITE-15351 > URL: https://issues.apache.org/jira/browse/IGNITE-15351 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > In Ignite 2.x there's a concept of "Data Regions", which is basically a set > of fixed-sized in-memory caches that store data for a number of cache groups > (let's ignore system region and similar stuff for now). It is very convenient > and represents a core design feature in Apache Ignite - In-Memory Database. > Currently, Page Memory subsystem is not yet ported to Ignite 3.x codebase. > Instead, there's an implementation based on RocksDB database to store data > persistently. > But, this implementation is very simple and naive. There's no notion of > in-memory cache across multiple tables, meaning that it can't be called an > In-Memory Database. We should investigate ways to add this concept back on > top of RocksDB implementation. > There are several things to investigate here: > * how do you set up rocksdb properly and control its memory consumption - we > should allow some configuration and a meaningful set of defaults; > * how do you put a cache on top of several rocksdb instances. This is > actually
[jira] [Created] (IGNITE-15351) Research possibility of having caching layer on top of RocksDB partitions
Ivan Bessonov created IGNITE-15351: -- Summary: Research possibility of having caching layer on top of RocksDB partitions Key: IGNITE-15351 URL: https://issues.apache.org/jira/browse/IGNITE-15351 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov In Ignite 2.x there's a concept of "Data Regions", which is basically a set of fixed-sized in-memory caches that store data for a number of cache groups (let's ignore system region and similar stuff for now). It is very convenient and represents a core design feature in Apache Ignite - In-Memory Database. Currently, Page Memory subsystem is not yet ported to Ignite 3.x codebase. Instead, there's an implementation based on RocksDB database to store data persistently. But, this implementation is very simple and naive. There's no notion of in-memory cache across multiple tables, meaning that it can't be called an In-Memory Database. We should investigate ways to add this concept back on top of RocksDB implementation. There are several things to investigate here: * how do you set up rocksdb properly and control its memory consumption - we should allow some configuration and a meaningful set of defaults; * how do you put a cache on top of several rocksdb instances. This is actually pretty easy, just use "org.rocksdb.Options#setRowCache(org.rocksdb.Cache)", but a way to configure it is still required; * how do we introduce data regions into our system? I see something like this: ** list of regions is either a node or cluster configuration; ** name of the region is a property of every individual table or table group (or whatever else we'll be having). Last proposition is a bit tricky, cause it won't look like "create table with rocks engine with Clock cache...", it would look like "create table in region Foo". We have to conceptualize all this things and come up with proper naming at least. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15350) Refactor EncryptedFileIO
[
https://issues.apache.org/jira/browse/IGNITE-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-15350:
--
Description:
Current EncryptedFileIO has wierd implementations of several methods. Like
{code:java}
@Override public int write(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
@Override public int read(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
{code}
Why not supported?
Or:
{code:java}
@Override public int read(ByteBuffer destBuf) throws IOException {
assert position() == 0;
return plainFileIO.read(destBuf);
}
{code}
Why encrypted reading is not supported beyond the header? Why `assert
position() == 0`
The class contains several writes and reading implemented differently. Some of
them are not supported.
*Suggestion:* Make one write(...) and one read(...) implementation and call
them passing correct arguments. Read/write the header without encryption.
Read/write everything beyond the header with encryption.
was:
Current EncryptedFileIO has wierd implementations of several methods. Like
{code:java}
@Override public int write(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
{code}
@Override public int read(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
Why not supported?
Or:
{code:java}
@Override public int read(ByteBuffer destBuf) throws IOException {
assert position() == 0;
return plainFileIO.read(destBuf);
}
{code}
Why encrypted reading is not supported beyond the header? Why `assert
position() == 0`
The class contains several writes and reading implemented differently. Some of
them are not supported.
*Suggestion:* Make one write(...) and one read(...) implementation and call
them passing correct arguments. Read/write the header without encryption.
Read/write everything beyond the header with encryption.
> Refactor EncryptedFileIO
>
>
> Key: IGNITE-15350
> URL: https://issues.apache.org/jira/browse/IGNITE-15350
> Project: Ignite
> Issue Type: Task
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: newbee
>
> Current EncryptedFileIO has wierd implementations of several methods. Like
> {code:java}
> @Override public int write(byte[] buf, int off, int len) throws IOException {
> throw new UnsupportedOperationException("Encrypted File doesn't
> support this operation");
> }
> @Override public int read(byte[] buf, int off, int len) throws
> IOException {
> throw new UnsupportedOperationException("Encrypted File doesn't
> support this operation");
> }
> {code}
> Why not supported?
> Or:
> {code:java}
> @Override public int read(ByteBuffer destBuf) throws IOException {
> assert position() == 0;
> return plainFileIO.read(destBuf);
> }
> {code}
> Why encrypted reading is not supported beyond the header? Why `assert
> position() == 0`
> The class contains several writes and reading implemented differently. Some
> of them are not supported.
> *Suggestion:* Make one write(...) and one read(...) implementation and call
> them passing correct arguments. Read/write the header without encryption.
> Read/write everything beyond the header with encryption.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14954) Calcite engine. MONTHNAME, DAYNAME functions fail due to null locale
[
https://issues.apache.org/jira/browse/IGNITE-14954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402175#comment-17402175
]
Ivan Daschinsky commented on IGNITE-14954:
--
[~alex_pl] Looks good to me.
> Calcite engine. MONTHNAME, DAYNAME functions fail due to null locale
>
>
> Key: IGNITE-14954
> URL: https://issues.apache.org/jira/browse/IGNITE-14954
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The query
> {{SELECT MONTHNAME(CAST('1992-05-31' AS DATE));}}
> fails with exception
> {code}
> class org.apache.ignite.IgniteException: Unexpected exception
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:244)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.NullPointerException: locale
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at
> java.base/java.time.format.DateTimeFormatter.(DateTimeFormatter.java:1421)
> at
> java.base/java.time.format.DateTimeFormatter.withLocale(DateTimeFormatter.java:1463)
> at
> org.apache.calcite.runtime.SqlFunctions.monthNameWithDate(SqlFunctions.java:2391)
> at SC.execute(Unknown Source)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl$ProjectImpl.apply(ExpressionFactoryImpl.java:387)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ProjectNode.push(ProjectNode.java:63)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:239)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15350) Refactor EncryptedFileIO
[
https://issues.apache.org/jira/browse/IGNITE-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-15350:
--
Description:
Current EncryptedFileIO has wierd implementations of several methods. Like
{code:java}
@Override public int write(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
{code}
@Override public int read(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
Why not supported?
Or:
{code:java}
@Override public int read(ByteBuffer destBuf) throws IOException {
assert position() == 0;
return plainFileIO.read(destBuf);
}
{code}
Why encrypted reading is not supported beyond the header? Why `assert
position() == 0`
The class contains several writes and reading implemented differently. Some of
them are not supported.
*Suggestion:* Make one write(...) and one read(...) implementation and call
them passing correct arguments. Read/write the header without encryption.
Read/write everything beyond the header with encryption.
was:
Current EncryptedFileIO has wierd implementations of several methods. Like
{code:java}
@Override public int write(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
{code}
@Override public int read(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
Why not supported?
Or:
{code:java}
@Override public int read(ByteBuffer destBuf) throws IOException {
assert position() == 0;
return plainFileIO.read(destBuf);
}
{code}
Why encrypted reading is not supported beyond the header? Why `assert
position() == 0`
The class contains several writes and reading implemented differently. Some of
them are not supported.
Suggestion: Make one write(...) and one read(...) implementation and call them
passing correct arguments. Read/write the header without encryption. Read/write
everything beyond the header with encryption.
> Refactor EncryptedFileIO
>
>
> Key: IGNITE-15350
> URL: https://issues.apache.org/jira/browse/IGNITE-15350
> Project: Ignite
> Issue Type: Task
>Reporter: Vladimir Steshin
>Priority: Minor
>
> Current EncryptedFileIO has wierd implementations of several methods. Like
> {code:java}
> @Override public int write(byte[] buf, int off, int len) throws IOException {
> throw new UnsupportedOperationException("Encrypted File doesn't
> support this operation");
> }
> {code}
> @Override public int read(byte[] buf, int off, int len) throws
> IOException {
> throw new UnsupportedOperationException("Encrypted File doesn't
> support this operation");
> }
> Why not supported?
> Or:
> {code:java}
> @Override public int read(ByteBuffer destBuf) throws IOException {
> assert position() == 0;
> return plainFileIO.read(destBuf);
> }
> {code}
> Why encrypted reading is not supported beyond the header? Why `assert
> position() == 0`
> The class contains several writes and reading implemented differently. Some
> of them are not supported.
> *Suggestion:* Make one write(...) and one read(...) implementation and call
> them passing correct arguments. Read/write the header without encryption.
> Read/write everything beyond the header with encryption.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15350) Refactor EncryptedFileIO
[
https://issues.apache.org/jira/browse/IGNITE-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-15350:
--
Labels: newbee (was: )
> Refactor EncryptedFileIO
>
>
> Key: IGNITE-15350
> URL: https://issues.apache.org/jira/browse/IGNITE-15350
> Project: Ignite
> Issue Type: Task
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: newbee
>
> Current EncryptedFileIO has wierd implementations of several methods. Like
> {code:java}
> @Override public int write(byte[] buf, int off, int len) throws IOException {
> throw new UnsupportedOperationException("Encrypted File doesn't
> support this operation");
> }
> {code}
> @Override public int read(byte[] buf, int off, int len) throws
> IOException {
> throw new UnsupportedOperationException("Encrypted File doesn't
> support this operation");
> }
> Why not supported?
> Or:
> {code:java}
> @Override public int read(ByteBuffer destBuf) throws IOException {
> assert position() == 0;
> return plainFileIO.read(destBuf);
> }
> {code}
> Why encrypted reading is not supported beyond the header? Why `assert
> position() == 0`
> The class contains several writes and reading implemented differently. Some
> of them are not supported.
> *Suggestion:* Make one write(...) and one read(...) implementation and call
> them passing correct arguments. Read/write the header without encryption.
> Read/write everything beyond the header with encryption.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15350) Refactor EncryptedFileIO
Vladimir Steshin created IGNITE-15350:
-
Summary: Refactor EncryptedFileIO
Key: IGNITE-15350
URL: https://issues.apache.org/jira/browse/IGNITE-15350
Project: Ignite
Issue Type: Task
Reporter: Vladimir Steshin
Current EncryptedFileIO has wierd implementations of several methods. Like
{code:java}
@Override public int write(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
{code}
@Override public int read(byte[] buf, int off, int len) throws IOException {
throw new UnsupportedOperationException("Encrypted File doesn't support
this operation");
}
Why not supported?
Or:
{code:java}
@Override public int read(ByteBuffer destBuf) throws IOException {
assert position() == 0;
return plainFileIO.read(destBuf);
}
{code}
Why encrypted reading is not supported beyond the header? Why `assert
position() == 0`
The class contains several writes and reading implemented differently. Some of
them are not supported.
Suggestion: Make one write(...) and one read(...) implementation and call them
passing correct arguments. Read/write the header without encryption. Read/write
everything beyond the header with encryption.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13558) GridCacheProcessor should implement better parallelization when restoring partition states on startup
[ https://issues.apache.org/jira/browse/IGNITE-13558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402133#comment-17402133 ] Denis Chudov edited comment on IGNITE-13558 at 8/20/21, 11:11 AM: -- I added RestorePartitionStateBenchmark into ignite-benchmarks module. It shows significant difference on a node with non-uniform distribution of partitions count in different cache groups between current version and this optimization (both approaches). In the same time, none of approaches has an advantage, as I expected. PR with my implementation: [https://github.com/apache/ignite/pull/9243] PR with alternative approach, task per partition: [https://github.com/apache/ignite/pull/9327] PR for tests of current version: [https://github.com/apache/ignite/pull/9334] Partition restore times on teamcity: ||PR||Run 1||Run 2||Run 3|| |9243|_795ms_|_804ms_|_935ms_| |9327|_941ms_|_750ms_|_769ms_| |9334|_1s515ms_|_1s590ms_|_1s471ms_| was (Author: denis chudov): I added RestorePartitionStateBenchmark into ignite-benchmarks module. It shows significant difference on a node with non-uniform distribution of cache group sizes between current version and this optimization (both approaches). In the same time, none of approaches has an advantage, as I expected. PR with my implementation: [https://github.com/apache/ignite/pull/9243] PR with alternative approach, task per partition: [https://github.com/apache/ignite/pull/9327] PR for tests of current version: [https://github.com/apache/ignite/pull/9334] Partition restore times on teamcity: ||PR||Run 1||Run 2||Run 3|| |9243|_795ms_|_804ms_|_935ms_| |9327|_941ms_|_750ms_|_769ms_| |9334|_1s515ms_|_1s590ms_|_1s471ms_| > GridCacheProcessor should implement better parallelization when restoring > partition states on startup > - > > Key: IGNITE-13558 > URL: https://issues.apache.org/jira/browse/IGNITE-13558 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Denis Chudov >Priority: Major > Time Spent: 3h > Remaining Estimate: 0h > > GridCacheProcessor#restorePartitionStates method tries to employ striped pool > to restore partition states in parallel but level of parallelization is down > only to cache group per thread. > It is not enough and not utilizes resources effectively in case of one cache > group much bigger than the others. > We need to parallel restore process down to individual partitions to get the > most from the available resources and speed up node startup. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13558) GridCacheProcessor should implement better parallelization when restoring partition states on startup
[ https://issues.apache.org/jira/browse/IGNITE-13558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402159#comment-17402159 ] Denis Chudov commented on IGNITE-13558: --- [~ktkale...@gridgain.com] could you continue the review? > GridCacheProcessor should implement better parallelization when restoring > partition states on startup > - > > Key: IGNITE-13558 > URL: https://issues.apache.org/jira/browse/IGNITE-13558 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Denis Chudov >Priority: Major > Time Spent: 3h > Remaining Estimate: 0h > > GridCacheProcessor#restorePartitionStates method tries to employ striped pool > to restore partition states in parallel but level of parallelization is down > only to cache group per thread. > It is not enough and not utilizes resources effectively in case of one cache > group much bigger than the others. > We need to parallel restore process down to individual partitions to get the > most from the available resources and speed up node startup. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14963) Calcite engine. Date interval arythmetic returns invalid results
[
https://issues.apache.org/jira/browse/IGNITE-14963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402153#comment-17402153
]
Ivan Daschinsky commented on IGNITE-14963:
--
[~alex_pl] Looks goot, please proceed with merge
> Calcite engine. Date interval arythmetic returns invalid results
>
>
> Key: IGNITE-14963
> URL: https://issues.apache.org/jira/browse/IGNITE-14963
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{select date '1992-01-01' + interval (17) days}} - returns {{1992-01-18}} -
> valid
> {{select date '1992-01-01' + interval (18) days}} - returns {{1992-01-18}} -
> invalid
> Tests:
> {{function/date/test_extract_month.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11298) TcpCommunicationSpi does not support TLSv1.3
[
https://issues.apache.org/jira/browse/IGNITE-11298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402152#comment-17402152
]
Ilya Kasnacheev commented on IGNITE-11298:
--
But it's not my comment :) I've just posted it.
мопед не мой
> TcpCommunicationSpi does not support TLSv1.3
>
>
> Key: IGNITE-11298
> URL: https://issues.apache.org/jira/browse/IGNITE-11298
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: Java11
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When started on Java 11 we cannot form a secure cluster - Discovery will
> happily use the default TLSv1.3 but Communication will fail with its custom
> SSLEngine-using code.
> Need to fix that.
> Until that, nodes may be salvaged by setProtocol("TLSv1.2") on
> SslContextFactory, or by system property -Djdk.tls.client.protocols="TLSv1.2"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13558) GridCacheProcessor should implement better parallelization when restoring partition states on startup
[ https://issues.apache.org/jira/browse/IGNITE-13558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402133#comment-17402133 ] Denis Chudov commented on IGNITE-13558: --- I added RestorePartitionStateBenchmark into ignite-benchmarks module. It shows significant difference on a node with non-uniform distribution of cache group sizes between current version and this optimization (both approaches). In the same time, none of approaches has an advantage, as I expected. PR with my implementation: [https://github.com/apache/ignite/pull/9243] PR with alternative approach, task per partition: [https://github.com/apache/ignite/pull/9327] PR for tests of current version: [https://github.com/apache/ignite/pull/9334] Partition restore times on teamcity: ||PR||Run 1||Run 2||Run 3|| |9243|_795ms_|_804ms_|_935ms_| |9327|_941ms_|_750ms_|_769ms_| |9334|_1s515ms_|_1s590ms_|_1s471ms_| > GridCacheProcessor should implement better parallelization when restoring > partition states on startup > - > > Key: IGNITE-13558 > URL: https://issues.apache.org/jira/browse/IGNITE-13558 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Denis Chudov >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > GridCacheProcessor#restorePartitionStates method tries to employ striped pool > to restore partition states in parallel but level of parallelization is down > only to cache group per thread. > It is not enough and not utilizes resources effectively in case of one cache > group much bigger than the others. > We need to parallel restore process down to individual partitions to get the > most from the available resources and speed up node startup. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15349) Fix feedback #4
[ https://issues.apache.org/jira/browse/IGNITE-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402115#comment-17402115 ] Igor Gusev commented on IGNITE-15349: - [~dma...@apache.org] Can you merge the PR? It fixes the feedback issue in doc. > Fix feedback #4 > --- > > Key: IGNITE-15349 > URL: https://issues.apache.org/jira/browse/IGNITE-15349 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We need to update text on > [https://ignite.apache.org/docs/latest/sql-reference/transactions#] to > include ROLLBACK command -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15349) Fix feedback #4
Igor Gusev created IGNITE-15349: --- Summary: Fix feedback #4 Key: IGNITE-15349 URL: https://issues.apache.org/jira/browse/IGNITE-15349 Project: Ignite Issue Type: Improvement Reporter: Igor Gusev We need to update text on [https://ignite.apache.org/docs/latest/sql-reference/transactions#] to include ROLLBACK command -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15349) Fix feedback #4
[ https://issues.apache.org/jira/browse/IGNITE-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-15349: --- Assignee: Igor Gusev > Fix feedback #4 > --- > > Key: IGNITE-15349 > URL: https://issues.apache.org/jira/browse/IGNITE-15349 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > > We need to update text on > [https://ignite.apache.org/docs/latest/sql-reference/transactions#] to > include ROLLBACK command -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15348) Checkstyle should check whitespace after cast token.
[ https://issues.apache.org/jira/browse/IGNITE-15348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-15348: Ignite Flags: (was: Docs Required,Release Notes Required) > Checkstyle should check whitespace after cast token. > - > > Key: IGNITE-15348 > URL: https://issues.apache.org/jira/browse/IGNITE-15348 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Priority: Major > Labels: newbie > > According to Ignite code style [1] there shouldn't a whitespace after the > ")" token. Let's add check for that. > > Solution is add the TYPECAST token to the NoWhitespaceAfter module > > > > > Also it is required to fix all issues within repo. > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15348) Checkstyle should check whitespace after cast token.
[ https://issues.apache.org/jira/browse/IGNITE-15348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-15348: Labels: newbie (was: ) > Checkstyle should check whitespace after cast token. > - > > Key: IGNITE-15348 > URL: https://issues.apache.org/jira/browse/IGNITE-15348 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Priority: Major > Labels: newbie > > According to Ignite code style [1] there shouldn't a whitespace after the > ")" token. Let's add check for that. > > Solution is add the TYPECAST token to the NoWhitespaceAfter module > > > > > Also it is required to fix all issues within repo. > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15109) Calcite engine. TIMESTAMPDIFF for MICROSECOND unit doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-15109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-15109:
--
Assignee: Aleksey Plekhanov
> Calcite engine. TIMESTAMPDIFF for MICROSECOND unit doesn't work
> ---
>
> Key: IGNITE-15109
> URL: https://issues.apache.org/jira/browse/IGNITE-15109
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> The function TIMESTAMPDIFF for MICROSECOND unit return incorrect results for
> many cases. As the example below returns 0.
> {code:sql}
> SELECT TIMESTAMPDIFF(MICROSECOND, TIMESTAMP '2022-02-01 10:30:28.000',
> TIMESTAMP '2022-02-01 10:30:28.128'){code}
> see src/test/sql/function/timestamp/test_timestampdiff.test_ignore
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15348) Checkstyle should check whitespace after cast token.
Maksim Timonin created IGNITE-15348: --- Summary: Checkstyle should check whitespace after cast token. Key: IGNITE-15348 URL: https://issues.apache.org/jira/browse/IGNITE-15348 Project: Ignite Issue Type: New Feature Reporter: Maksim Timonin According to Ignite code style [1] there shouldn't a whitespace after the ")" token. Let's add check for that. Solution is add the TYPECAST token to the NoWhitespaceAfter module Also it is required to fix all issues within repo. [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15278) Node start/stop refactoring
[ https://issues.apache.org/jira/browse/IGNITE-15278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-15278: - Description: [~ibessonov] suggested simplifying the node start logic by: * Transferring the startup components management logic from IgnititionImpl to IgniteImpl. * Separating the logic of constructing and starting components even more: it is suggested to instantiate all the components first, and then start all of them. During implementation it occurred that the ClusterService constructor assumes that nodeConfiguarion is already started. In order to satisfy the need of full-construct-then-start-logic org.apache.ignite.network.ClusterServiceFactory#createClusterService was updated: # Instead of port parameter within CluserLocalConfiguration ClusterServiceFactory#createClusterService accepts nodeConfiguration. # Instead of NodeFinder that also depends on nodeConfiguration ClusterServiceFactory#createClusterService accepts node finder supplier. was: [~ibessonov] suggested simplifying the node start logic by: * Transferring the startup components management logic from IgnititionImpl to IgniteImpl. * Separating the logic of constructing and starting components even more. It is suggested to instantiate all the components first, and then start all of them. During implementation it occurred that the ClusterService constructor assumes that nodeConfiguarion is already started. In order to satisfy the need of full-construct-then-start-logic org.apache.ignite.network.ClusterServiceFactory#createClusterService was updated: # Instead of port parameter within CluserLocalConfiguration ClusterServiceFactory#createClusterService accepts nodeConfiguration. # Instead of NodeFinder that also depends on nodeConfiguration ClusterServiceFactory#createClusterService accepts node finder supplier. > Node start/stop refactoring > --- > > Key: IGNITE-15278 > URL: https://issues.apache.org/jira/browse/IGNITE-15278 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > [~ibessonov] suggested simplifying the node start logic by: > * Transferring the startup components management logic from IgnititionImpl > to IgniteImpl. > * Separating the logic of constructing and starting components even more: it > is suggested to instantiate all the components first, and then start all of > them. > During implementation it occurred that the ClusterService constructor assumes > that nodeConfiguarion is already started. In order to satisfy the need of > full-construct-then-start-logic > org.apache.ignite.network.ClusterServiceFactory#createClusterService was > updated: > # Instead of port parameter within CluserLocalConfiguration > ClusterServiceFactory#createClusterService accepts nodeConfiguration. > # Instead of NodeFinder that also depends on nodeConfiguration > ClusterServiceFactory#createClusterService accepts node finder supplier. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15278) Node start/stop refactoring
[ https://issues.apache.org/jira/browse/IGNITE-15278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-15278: - Description: [~ibessonov] suggested simplifying the node start logic by: * Transferring the startup components management logic from IgnititionImpl to IgniteImpl. * Separating the logic of constructing and starting components even more: it is suggested to instantiate all the components first, and then start all of them. During the implementation it occurred that the ClusterService constructor assumes that nodeConfiguarion is already started. In order to satisfy the need of full-construct-then-start-logic org.apache.ignite.network.ClusterServiceFactory#createClusterService was updated: # Instead of port parameter within CluserLocalConfiguration ClusterServiceFactory#createClusterService accepts nodeConfiguration. # Instead of NodeFinder that also depends on nodeConfiguration ClusterServiceFactory#createClusterService accepts node finder supplier. was: [~ibessonov] suggested simplifying the node start logic by: * Transferring the startup components management logic from IgnititionImpl to IgniteImpl. * Separating the logic of constructing and starting components even more: it is suggested to instantiate all the components first, and then start all of them. During implementation it occurred that the ClusterService constructor assumes that nodeConfiguarion is already started. In order to satisfy the need of full-construct-then-start-logic org.apache.ignite.network.ClusterServiceFactory#createClusterService was updated: # Instead of port parameter within CluserLocalConfiguration ClusterServiceFactory#createClusterService accepts nodeConfiguration. # Instead of NodeFinder that also depends on nodeConfiguration ClusterServiceFactory#createClusterService accepts node finder supplier. > Node start/stop refactoring > --- > > Key: IGNITE-15278 > URL: https://issues.apache.org/jira/browse/IGNITE-15278 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > [~ibessonov] suggested simplifying the node start logic by: > * Transferring the startup components management logic from IgnititionImpl > to IgniteImpl. > * Separating the logic of constructing and starting components even more: it > is suggested to instantiate all the components first, and then start all of > them. > During the implementation it occurred that the ClusterService constructor > assumes that nodeConfiguarion is already started. In order to satisfy the > need of full-construct-then-start-logic > org.apache.ignite.network.ClusterServiceFactory#createClusterService was > updated: > # Instead of port parameter within CluserLocalConfiguration > ClusterServiceFactory#createClusterService accepts nodeConfiguration. > # Instead of NodeFinder that also depends on nodeConfiguration > ClusterServiceFactory#createClusterService accepts node finder supplier. -- This message was sent by Atlassian Jira (v8.3.4#803005)
