[jira] [Assigned] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li reassigned IGNITE-12852: - Assignee: Anton Kurbanov (was: YuJue Li) > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: Anton Kurbanov >Priority: Critical > Fix For: 2.8.1 > > Time Spent: 10m > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12880) IllegalArgumentException on activation of LogExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080993#comment-17080993
]
Denis A. Magda commented on IGNITE-12880:
-
Nikolay, thanks for looking into that.
Setting {code:java} setPeriod(EXPORT_TIMEOUT){code} did the trick and I could
start the node with the exporter enabled. However, I still don't see any logs
printed even after setting {code:java}cfg.setMetricsLogFrequency(5000){code}.
Here is a simple code sample I'm playing with (please see ServerNodeStartup
file):
https://github.com/gridgain/demos/tree/master/ignite-metrics-demo
What should I expect to see and do we really need two parameters (setPeriod and
setMetricsLogFrequence) to control the behavior? Also, I would advise us to
set a default value of setPeriod to non-zero (like 1 minute) so that the
feature works once an instance of LogExporter is passed into the
IgniteConfiguration.
> IllegalArgumentException on activation of LogExporterSpi
>
>
> Key: IGNITE-12880
> URL: https://issues.apache.org/jira/browse/IGNITE-12880
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Nikolay Izhikov
>Priority: Major
>
> I tried to enable `LogExporterSpi` and getting an error below. Running on
> jdk1.8.0_77.jdk and macOS Catalina. See a source file attached.
> {noformat}
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Got exception while starting (will rollback startup routine).
> java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:589)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStart(PushMetricsExporterAdapter.java:56)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.start(GridMetricManager.java:277)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1960)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1171)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to stop component (ignoring): GridManagerAdapter
> [enabled=true, name=o.a.i.i.processors.metric.GridMetricManager]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStop(PushMetricsExporterAdapter.java:71)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.stop(GridMetricManager.java:314)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2627)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2499)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1395)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> [13:07:00] Ignite node stopped wih ERRORS [uptime=00:00:01.303]
> Exception in thread "main" class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1067)
> at org.apache.ignite.Ignition.start(Ignition.java:324)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1402)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
>
[jira] [Commented] (IGNITE-12883) .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental
[
https://issues.apache.org/jira/browse/IGNITE-12883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080985#comment-17080985
]
Ignite TC Bot commented on IGNITE-12883:
{panel:title=Branch: [pull/7656/head] Base: [master] : Possible Blockers
(418)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5212719]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5212729]]
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5212671]]
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testDisconnectAfterNetworkTimeout -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}JCache TCK 1.1{color} [[tests 51 Out Of Memory Error , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5212685]]
* javax.cache.configuration.ConfigurationTest.testDefaultConstructor - Test has
low fail rate in base branch 0,0% and is not flaky
* org.jsr107.tck.ReplaceTest.replace_3arg_NullValue2 - Test has low fail rate
in base branch 0,0% and is not flaky
* org.jsr107.tck.ReplaceTest.replace_2arg_NullKey - Test has low fail rate in
base branch 0,0% and is not flaky
* org.jsr107.tck.ReplaceTest.replace_3arg_NullKey - Test has low fail rate in
base branch 0,0% and is not flaky
*
javax.cache.configuration.MutableConfigurationTest.testDefaultCacheFromCacheManagerUsesCorrectDefaults
- Test has low fail rate in base branch 0,0% and is not flaky
*
javax.cache.configuration.MutableConfigurationTest.shouldNotBeTheSameButAClone
- Test has low fail rate in base branch 0,0% and is not flaky
* org.jsr107.tck.ReplaceTest.replace_3arg_Closed - Test has low fail rate in
base branch 0,0% and is not flaky
* javax.cache.configuration.MutableConfigurationTest.testCopyConstructor - Test
has low fail rate in base branch 0,0% and is not flaky
* javax.cache.configuration.MutableConfigurationTest.testEqualsHashCode - Test
has low fail rate in base branch 0,0% and is not flaky
* javax.cache.configuration.MutableConfigurationTest.shouldEqual - Test has low
fail rate in base branch 0,0% and is not flaky
*
javax.cache.configuration.MutableConfigurationTest.shouldBeEqualWhenUsingDefaults
- Test has low fail rate in base branch 0,0% and is not flaky
... and 40 tests blockers
{color:#d04437}MVCC Queries{color} [[tests 359 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5212689]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlQueriesTest.testUpdateSingleValue_ClientServer - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlQueriesTest.testUpdateSingleValue_SingleNode - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlQueriesTest.testUpdateSingleValue_LocalQuery_SingleNode -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlQueriesTest.testJoinTransactional_DistributedJoins_ClientServer2
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlQueriesTest.testMaxMinTransactional_SingleNode - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlTxQueriesWithReducerTest.testQueryReducerInsertValues -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups2_Sql
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlTxQueriesTest.testParsingErrorHasNoSideEffect - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlTxQueriesWithReducerTest.testQueryReducerInsert - Test
has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlTxQueriesTest.testParsingErrorHasNoSideEffect - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlTxQueriesWithReducerTest.testQueryReducerUpdate - Test
has low fail rate in base branch 0,0% and is not flaky
... and 348 tests blockers
{color:#d04437}MVCC PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5212751]]
* IgnitePdsMvccTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testStopCachesOnDeactivationFirstGroup
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Service Grid (legacy mode){color} [[tests 0 TIMEOUT , Out Of
Memory Error , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5212738]]
[jira] [Commented] (IGNITE-12883) .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental
[ https://issues.apache.org/jira/browse/IGNITE-12883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080918#comment-17080918 ] Igor Sapego commented on IGNITE-12883: -- [~ptupitsyn] looks good to me. > .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental > - > > Key: IGNITE-12883 > URL: https://issues.apache.org/jira/browse/IGNITE-12883 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > PlatformNearCache is not actually "Near" - it just mirrors cache entries that > are present on current node in CLR heap for faster access. Those entries can > be primary, backup, or near. > PlatformCache seems to be a better name. > Rename: > * `PlatformNearCacheConfiguration` -> `PlatformCacheConfiguration` > * `CachePeekMode.PlatformNear` -> `CachePeekMode.Platform` > * `CacheConfiguration.PlatformNearConfiguration` -> > `CacheConfiguration.PlatformCacheConfiguration` > Mark all new platform (near) cache APIs with `[IgniteExperimental]` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-10011) Pages leak suspicion in PDS
[ https://issues.apache.org/jira/browse/IGNITE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080608#comment-17080608 ] Ilya Kasnacheev edited comment on IGNITE-10011 at 4/10/20, 4:07 PM: [~agoncharuk] Should we go forward with this? LGTM, is it still actual? Is it possible to write a test? was (Author: ilyak): [~agoncharuk] Should we go forward with this? LGTM, is it still actual? > Pages leak suspicion in PDS > --- > > Key: IGNITE-10011 > URL: https://issues.apache.org/jira/browse/IGNITE-10011 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ilya Kasnacheev >Priority: Critical > Labels: performance > Fix For: 2.9, 2.8.1 > > Attachments: Main.java > > Time Spent: 10m > Remaining Estimate: 0h > > See the attached Main which adds 500k records to 3 caches, then clears them, > rinse, repeat. > When ran with default settings, totalAllocatedSize will slowly double over > the course of a few hours and then continue to grow. > When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M -> > 1800M -> etc. > See the userlist discussion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10011) Pages leak suspicion in PDS
[ https://issues.apache.org/jira/browse/IGNITE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080608#comment-17080608 ] Ilya Kasnacheev commented on IGNITE-10011: -- [~agoncharuk] Should we go forward with this? LGTM, is it still actual? > Pages leak suspicion in PDS > --- > > Key: IGNITE-10011 > URL: https://issues.apache.org/jira/browse/IGNITE-10011 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ilya Kasnacheev >Priority: Critical > Labels: performance > Fix For: 2.9, 2.8.1 > > Attachments: Main.java > > Time Spent: 10m > Remaining Estimate: 0h > > See the attached Main which adds 500k records to 3 caches, then clears them, > rinse, repeat. > When ran with default settings, totalAllocatedSize will slowly double over > the course of a few hours and then continue to grow. > When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M -> > 1800M -> etc. > See the userlist discussion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12793) Deadlock in the System Pool on Metadata processing
[
https://issues.apache.org/jira/browse/IGNITE-12793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080557#comment-17080557
]
Sergey Chugunov commented on IGNITE-12793:
--
[~macrergate],
I reproduced the issue with your test, it seems this deadlock isn't related to
any recent changes and was always around since moving binary metadata exchange
to discovery protocol.
It seems to me that the best solution here is to introduce additional
GridIoPolicy with semantics "always create separate thread for message handler
execution".
Given that exchange of MetadataRequest/Response messages shouldn't be very
intensive this solution won't create too much pressure on client side.
What do you think?
> Deadlock in the System Pool on Metadata processing
> --
>
> Key: IGNITE-12793
> URL: https://issues.apache.org/jira/browse/IGNITE-12793
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.7.6
>Reporter: Sergey Kosarev
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.9
>
> Attachments: ignite-12793-threaddump.txt
>
>
> I've recently tried to apply Ilya's idea
> (https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread
> pools and tried to set system pool to 3 in my own tests.
> It caused deadlock on a client node and I think it can happen not only on
> such small pool values.
> Details are following:
> I'm not using persistence currently (if it matters).
> On the client note I use ignite compute to call a job on every server node
> (there are 3 server nodes in the tests).
> Then I've found in logs:
> {{[10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773]
> {grid-timeout-worker-#8}
> [WARN] [o.a.i.i.IgniteKernal] - Possible thread pool starvation detected (no
> task completed in last 3ms, is system thread pool size large enough?)
> [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0, qSize=9]}}
> I see in threaddumps that all 3 system pool workers do the same - processing
> of job responses:
> {{ "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34
> waiting on condition [0x7b91d000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
>
[jira] [Assigned] (IGNITE-12793) Deadlock in the System Pool on Metadata processing
[
https://issues.apache.org/jira/browse/IGNITE-12793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov reassigned IGNITE-12793:
Assignee: Sergey Chugunov
> Deadlock in the System Pool on Metadata processing
> --
>
> Key: IGNITE-12793
> URL: https://issues.apache.org/jira/browse/IGNITE-12793
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.7.6
>Reporter: Sergey Kosarev
>Assignee: Sergey Chugunov
>Priority: Major
> Attachments: ignite-12793-threaddump.txt
>
>
> I've recently tried to apply Ilya's idea
> (https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread
> pools and tried to set system pool to 3 in my own tests.
> It caused deadlock on a client node and I think it can happen not only on
> such small pool values.
> Details are following:
> I'm not using persistence currently (if it matters).
> On the client note I use ignite compute to call a job on every server node
> (there are 3 server nodes in the tests).
> Then I've found in logs:
> {{[10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773]
> {grid-timeout-worker-#8}
> [WARN] [o.a.i.i.IgniteKernal] - Possible thread pool starvation detected (no
> task completed in last 3ms, is system thread pool size large enough?)
> [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0, qSize=9]}}
> I see in threaddumps that all 3 system pool workers do the same - processing
> of job responses:
> {{ "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34
> waiting on condition [0x7b91d000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:306)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10493)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:828)
> at
>
[jira] [Updated] (IGNITE-12793) Deadlock in the System Pool on Metadata processing
[
https://issues.apache.org/jira/browse/IGNITE-12793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-12793:
-
Fix Version/s: 2.9
> Deadlock in the System Pool on Metadata processing
> --
>
> Key: IGNITE-12793
> URL: https://issues.apache.org/jira/browse/IGNITE-12793
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.7.6
>Reporter: Sergey Kosarev
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.9
>
> Attachments: ignite-12793-threaddump.txt
>
>
> I've recently tried to apply Ilya's idea
> (https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread
> pools and tried to set system pool to 3 in my own tests.
> It caused deadlock on a client node and I think it can happen not only on
> such small pool values.
> Details are following:
> I'm not using persistence currently (if it matters).
> On the client note I use ignite compute to call a job on every server node
> (there are 3 server nodes in the tests).
> Then I've found in logs:
> {{[10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773]
> {grid-timeout-worker-#8}
> [WARN] [o.a.i.i.IgniteKernal] - Possible thread pool starvation detected (no
> task completed in last 3ms, is system thread pool size large enough?)
> [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0, qSize=9]}}
> I see in threaddumps that all 3 system pool workers do the same - processing
> of job responses:
> {{ "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34
> waiting on condition [0x7b91d000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:306)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10493)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:828)
> at
>
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080539#comment-17080539 ] Nikolay Izhikov commented on IGNITE-12764: -- LGTM > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10477) An empty cluster falls if wal segment size small
[
https://issues.apache.org/jira/browse/IGNITE-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov resolved IGNITE-10477.
-
Resolution: Cannot Reproduce
> An empty cluster falls if wal segment size small
> -
>
> Key: IGNITE-10477
> URL: https://issues.apache.org/jira/browse/IGNITE-10477
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.7
>Reporter: ARomantsov
>Assignee: Yaroslav Molochkov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> I set and try to activate
> empty cluster.
> Get cluster drop by handler and next error
> Two servers and many caches
> {code:java}
> [15:45:12,723][SEVERE][db-checkpoint-thread-#99][] Critical system error
> detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TE
> RMINATION, err=java.lang.IllegalArgumentException: Record is too long
> [capacity=100, size=1802204]]]
> java.lang.IllegalArgumentException: Record is too long [capacity=100,
> size=1802204]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBuffer.offer0(SegmentedRingByteBuffer.java:214)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBuffer.offer(SegmentedRingByteBuffer.java:193)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:2472)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1600(FileWriteAheadLogManager.java:2376)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:821)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3604)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3091)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2990)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-10477) An empty cluster falls if wal segment size small
[
https://issues.apache.org/jira/browse/IGNITE-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov reassigned IGNITE-10477:
---
Assignee: Yaroslav Molochkov
> An empty cluster falls if wal segment size small
> -
>
> Key: IGNITE-10477
> URL: https://issues.apache.org/jira/browse/IGNITE-10477
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.7
>Reporter: ARomantsov
>Assignee: Yaroslav Molochkov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> I set and try to activate
> empty cluster.
> Get cluster drop by handler and next error
> Two servers and many caches
> {code:java}
> [15:45:12,723][SEVERE][db-checkpoint-thread-#99][] Critical system error
> detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TE
> RMINATION, err=java.lang.IllegalArgumentException: Record is too long
> [capacity=100, size=1802204]]]
> java.lang.IllegalArgumentException: Record is too long [capacity=100,
> size=1802204]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBuffer.offer0(SegmentedRingByteBuffer.java:214)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBuffer.offer(SegmentedRingByteBuffer.java:193)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:2472)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1600(FileWriteAheadLogManager.java:2376)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:821)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3604)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3091)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2990)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-10477) An empty cluster falls if wal segment size small
[
https://issues.apache.org/jira/browse/IGNITE-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov reassigned IGNITE-10477:
---
Assignee: (was: Yaroslav Molochkov)
> An empty cluster falls if wal segment size small
> -
>
> Key: IGNITE-10477
> URL: https://issues.apache.org/jira/browse/IGNITE-10477
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.7
>Reporter: ARomantsov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> I set and try to activate
> empty cluster.
> Get cluster drop by handler and next error
> Two servers and many caches
> {code:java}
> [15:45:12,723][SEVERE][db-checkpoint-thread-#99][] Critical system error
> detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TE
> RMINATION, err=java.lang.IllegalArgumentException: Record is too long
> [capacity=100, size=1802204]]]
> java.lang.IllegalArgumentException: Record is too long [capacity=100,
> size=1802204]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBuffer.offer0(SegmentedRingByteBuffer.java:214)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBuffer.offer(SegmentedRingByteBuffer.java:193)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:2472)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1600(FileWriteAheadLogManager.java:2376)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:821)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3604)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3091)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2990)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10477) An empty cluster falls if wal segment size small
[
https://issues.apache.org/jira/browse/IGNITE-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080528#comment-17080528
]
Yaroslav Molochkov commented on IGNITE-10477:
-
[~ARomantsov], i can't seem to reproduce the problem neither with several nodes
running locally with binary distribution 2.8.0 and walSegmentSize property set,
nor with JUnit tests. Does the problem persist with your configuration?
> An empty cluster falls if wal segment size small
> -
>
> Key: IGNITE-10477
> URL: https://issues.apache.org/jira/browse/IGNITE-10477
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.7
>Reporter: ARomantsov
>Assignee: Yaroslav Molochkov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> I set and try to activate
> empty cluster.
> Get cluster drop by handler and next error
> Two servers and many caches
> {code:java}
> [15:45:12,723][SEVERE][db-checkpoint-thread-#99][] Critical system error
> detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TE
> RMINATION, err=java.lang.IllegalArgumentException: Record is too long
> [capacity=100, size=1802204]]]
> java.lang.IllegalArgumentException: Record is too long [capacity=100,
> size=1802204]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBuffer.offer0(SegmentedRingByteBuffer.java:214)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBuffer.offer(SegmentedRingByteBuffer.java:193)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:2472)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1600(FileWriteAheadLogManager.java:2376)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:821)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3604)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3091)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2990)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12880) IllegalArgumentException on activation of LogExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080518#comment-17080518
]
Nikolay Izhikov commented on IGNITE-12880:
--
It seems you don't setup period for a LoggerSPI.
{code:java}
LogExporterSpi logSpi = new LogExporterSpi();
logSpi.setPeriod(EXPORT_TIMEOUT);
{code}
An exception is not intuitive so we should fix the way we set up LogExporter
anyway.
> IllegalArgumentException on activation of LogExporterSpi
>
>
> Key: IGNITE-12880
> URL: https://issues.apache.org/jira/browse/IGNITE-12880
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Nikolay Izhikov
>Priority: Major
>
> I tried to enable `LogExporterSpi` and getting an error below. Running on
> jdk1.8.0_77.jdk and macOS Catalina. See a source file attached.
> {noformat}
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Got exception while starting (will rollback startup routine).
> java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:589)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStart(PushMetricsExporterAdapter.java:56)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.start(GridMetricManager.java:277)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1960)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1171)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to stop component (ignoring): GridManagerAdapter
> [enabled=true, name=o.a.i.i.processors.metric.GridMetricManager]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStop(PushMetricsExporterAdapter.java:71)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.stop(GridMetricManager.java:314)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2627)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2499)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1395)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> [13:07:00] Ignite node stopped wih ERRORS [uptime=00:00:01.303]
> Exception in thread "main" class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1067)
> at org.apache.ignite.Ignition.start(Ignition.java:324)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1402)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> ... 1 more
> Caused by: java.lang.IllegalArgumentException
> at
>
[jira] [Commented] (IGNITE-12880) IllegalArgumentException on activation of LogExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080511#comment-17080511
]
Nikolay Izhikov commented on IGNITE-12880:
--
Hello [~dmagda]. Can you provide a reproducer for your issue?
> IllegalArgumentException on activation of LogExporterSpi
>
>
> Key: IGNITE-12880
> URL: https://issues.apache.org/jira/browse/IGNITE-12880
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Nikolay Izhikov
>Priority: Major
>
> I tried to enable `LogExporterSpi` and getting an error below. Running on
> jdk1.8.0_77.jdk and macOS Catalina. See a source file attached.
> {noformat}
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Got exception while starting (will rollback startup routine).
> java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:589)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStart(PushMetricsExporterAdapter.java:56)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.start(GridMetricManager.java:277)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1960)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1171)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to stop component (ignoring): GridManagerAdapter
> [enabled=true, name=o.a.i.i.processors.metric.GridMetricManager]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStop(PushMetricsExporterAdapter.java:71)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.stop(GridMetricManager.java:314)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2627)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2499)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1395)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> [13:07:00] Ignite node stopped wih ERRORS [uptime=00:00:01.303]
> Exception in thread "main" class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1067)
> at org.apache.ignite.Ignition.start(Ignition.java:324)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1402)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> ... 1 more
> Caused by: java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:589)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStart(PushMetricsExporterAdapter.java:56)
> at
>
[jira] [Assigned] (IGNITE-12880) IllegalArgumentException on activation of LogExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-12880:
Assignee: Nikolay Izhikov
> IllegalArgumentException on activation of LogExporterSpi
>
>
> Key: IGNITE-12880
> URL: https://issues.apache.org/jira/browse/IGNITE-12880
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Nikolay Izhikov
>Priority: Major
>
> I tried to enable `LogExporterSpi` and getting an error below. Running on
> jdk1.8.0_77.jdk and macOS Catalina. See a source file attached.
> {noformat}
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Got exception while starting (will rollback startup routine).
> java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:589)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStart(PushMetricsExporterAdapter.java:56)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.start(GridMetricManager.java:277)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1960)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1171)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to stop component (ignoring): GridManagerAdapter
> [enabled=true, name=o.a.i.i.processors.metric.GridMetricManager]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStop(PushMetricsExporterAdapter.java:71)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.stop(GridMetricManager.java:314)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2627)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2499)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1395)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> [13:07:00] Ignite node stopped wih ERRORS [uptime=00:00:01.303]
> Exception in thread "main" class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1067)
> at org.apache.ignite.Ignition.start(Ignition.java:324)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1402)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> ... 1 more
> Caused by: java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:589)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStart(PushMetricsExporterAdapter.java:56)
> at
>
[jira] [Commented] (IGNITE-8343) InetSocketAddress.getAddress() returns null, should check it in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-8343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080482#comment-17080482
]
Ignite TC Bot commented on IGNITE-8343:
---
{panel:title=Branch: [pull/7485/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5206288buildTypeId=IgniteTests24Java8_RunAll]
> InetSocketAddress.getAddress() returns null, should check it in
> TcpCommunicationSpi
> ---
>
> Key: IGNITE-8343
> URL: https://issues.apache.org/jira/browse/IGNITE-8343
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ilya Kasnacheev
>Assignee: Sergey Chugunov
>Priority: Critical
> Labels: test
> Fix For: 2.9
>
> Attachments: TcpDiscoveryMultiJvmTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is especially notorious in the following scenario:
> {code}
> // -Djava.net.preferIPv4Stack=true
> System.err.println(new InetSocketAddress("0:0:0:0:0:0:0:1%lo",
> 12345).getAddress()); // null
> {code}
> Yes we already warn if different nodes have differing preferIPv4Stack, still
> this is warning not a error, and there may be other cases where getAddress()
> returns null. Should make a check.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080464#comment-17080464 ] Dmitriy Sorokin commented on IGNITE-12764: -- [~nizhikov], thank you for hinting to me about more suitable test class, please review my changes! > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11147) Re-balance cancellation occur by non-affected event
[
https://issues.apache.org/jira/browse/IGNITE-11147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080462#comment-17080462
]
Ignite TC Bot commented on IGNITE-11147:
{panel:title=Branch: [pull/7428/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5211515]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5211314buildTypeId=IgniteTests24Java8_RunAll]
> Re-balance cancellation occur by non-affected event
> ---
>
> Key: IGNITE-11147
> URL: https://issues.apache.org/jira/browse/IGNITE-11147
> Project: Ignite
> Issue Type: Test
> Components: cache
>Affects Versions: 2.7
>Reporter: Sergey Antonov
>Assignee: Vladislav Pyatkov
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Re-balance cancels by non-affected events, for examples:
> 1) joining non affinity node
> 2) stating snapshot
> 3) starting/stopping other cache
> Try to skip as more as possible events instead of cancellation.
> After solved several issues appearing during this testing, I decided to add
> specific property allowing on/off rebalance's optimization. (see
> {{IgniteSystemProperties#IGNITE_DISABLE_REBALANCING_CANCELLATION_OPTIMIZATION}}
> by default false).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-7537) SQL COPY command: implement CSV format options
[
https://issues.apache.org/jira/browse/IGNITE-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YuJue Li reassigned IGNITE-7537:
Assignee: Anton Kurbanov
> SQL COPY command: implement CSV format options
> --
>
> Key: IGNITE-7537
> URL: https://issues.apache.org/jira/browse/IGNITE-7537
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Kirill Shirokov
>Assignee: Anton Kurbanov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following options can be implemented for the CSV format:
> * Line separator pattern
> * Field separator pattern
> * Set of quote characters
> * Escape sequence start character
> * Line comment character
> Escape sequences support is important for this feature. There is a draft code
> for handling escape sequences in a branch called ignite-7372 (see IGNITE-7372
> for details).
> Syntax example:
> {noformat}
> COPY
> ...
> FORMAT CSV
> [FIELDSEP='column-separators-regexp']
> [LINESEP='row-separators-regexp']
> [QUOTE='quote-chars']
> [ESCAPE='escape-char']
> [COMMENT='line-comment-char']
> {noformat}
> We may also want:
> * Line comments handling
> * Spaces trimming
> * Empty lines skipping
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12856) Fix two corruptedIndexPartition flaky tests.
[ https://issues.apache.org/jira/browse/IGNITE-12856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080457#comment-17080457 ] Alexey Scherbakov commented on IGNITE-12856: Merged to master 88b23568c46fa704ddf08591a0d6d714b3b8dd66. Thanks for the contribution. > Fix two corruptedIndexPartition flaky tests. > > > Key: IGNITE-12856 > URL: https://issues.apache.org/jira/browse/IGNITE-12856 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.8 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > TC highlights two new flack tests: > org.apache.ignite.util.GridCommandHandlerIndexingTest#testCorruptedIndexPartitionShouldFailValidationWithCrc > > org.apache.ignite.util.GridCommandHandlerIndexingTest#testCorruptedIndexPartitionShouldFailValidationWithoutCrc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12345) Remote listener of IgniteMessaging has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12345: Assignee: Denis Garus > Remote listener of IgniteMessaging has to run inside the Ignite Sandbox. > > > Key: IGNITE-12345 > URL: https://issues.apache.org/jira/browse/IGNITE-12345 > Project: Ignite > Issue Type: Task >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Remote listener of IgniteMessaging has to run on a remote node inside the > Ignite Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12887) Node stops on type mismatch error between index type and type of value from searched row
Taras Ledkov created IGNITE-12887:
-
Summary: Node stops on type mismatch error between index type and
type of value from searched row
Key: IGNITE-12887
URL: https://issues.apache.org/jira/browse/IGNITE-12887
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.8
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.8.1
Steps to reproduce:
1. Create table with value fields types: (INT, OTHER) and create indexes for
the fields:
{code}
CREATE TABLE TEST (ID INT PRIMARY KEY, val_int INT, VAL_OBJ OTHER)
CREATE INDEX TEST_VAL_INT ON TEST(VAL_INT)
CREATE INDEX TEST_VAL_OBJ ON TEST(VAL_OBJ)
{code}
2. Add any data to the table:
{code}
INSERT INTO TEST VALUES (0, 0, ?)
{code}
3. Any of the query below crushes and node stops:
SELECT * FROM TEST WHERE VAL_OBJ < CURRENT_TIMESTAMP()
SELECT * FROM TEST WHERE VAL_INT < CURRENT_TIMESTAMP()
*Root cause*: all runtime exception inside {{Index.find}} is converted to
{{CorruptedTreeException}} and stops the node,
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12886) Introduce separate SQL configuration
Taras Ledkov created IGNITE-12886:
-
Summary: Introduce separate SQL configuration
Key: IGNITE-12886
URL: https://issues.apache.org/jira/browse/IGNITE-12886
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.9
A lot of SQL-related configuration parameter are placed at the root of the
{{IgniteConfiguration}}.
It would be better to move them to a separate configuration class, e.g.
{{SqlConfiguration}}.
Thread on [Ignite developers
list|http://apache-ignite-developers.2346864.n4.nabble.com/Introduce-separate-SQL-configuration-td46636.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12848) SQL: H2Connection leaks on INSERT
[
https://issues.apache.org/jira/browse/IGNITE-12848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080398#comment-17080398
]
Ignite TC Bot commented on IGNITE-12848:
{panel:title=Branch: [pull/7649/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5206025buildTypeId=IgniteTests24Java8_RunAll]
> SQL: H2Connection leaks on INSERT
> -
>
> Key: IGNITE-12848
> URL: https://issues.apache.org/jira/browse/IGNITE-12848
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> H2 connection leaks on INSERT query when one row is inserted and not constant
> values are used:
> e.g.:
> {{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}
> *Root cause:*
> Query cursor isn't closed at the
> {{IgniteH2Indexing#executeUpdateNonTransactional}} after
> {{DmlUtils#processSelectResult}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080392#comment-17080392
]
Nikolay Izhikov commented on IGNITE-12827:
--
[~ivandasch] You can do it. Thanks!
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12827-vs-2.8.patch
>
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-12827:
-
Assignee: Ivan Daschinskiy (was: Nikolay Izhikov)
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12827-vs-2.8.patch
>
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080388#comment-17080388
]
Ivan Daschinskiy commented on IGNITE-12827:
---
[~nizhikov] Do you mind if I assign this ticket to me?
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12827-vs-2.8.patch
>
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12885) Checkpoint thread executes partitions fsync in single thread
Ivan Bessonov created IGNITE-12885: -- Summary: Checkpoint thread executes partitions fsync in single thread Key: IGNITE-12885 URL: https://issues.apache.org/jira/browse/IGNITE-12885 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov It should use "asyncRunner" if it was configured, this will optimize checkpoint speed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12883) .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental
[
https://issues.apache.org/jira/browse/IGNITE-12883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080369#comment-17080369
]
Ignite TC Bot commented on IGNITE-12883:
{panel:title=Branch: [pull/7656/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5211007]]
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5211033]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5211017]]
{color:#d04437}Thin Client: Java{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5210950]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5211043buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental
> -
>
> Key: IGNITE-12883
> URL: https://issues.apache.org/jira/browse/IGNITE-12883
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PlatformNearCache is not actually "Near" - it just mirrors cache entries that
> are present on current node in CLR heap for faster access. Those entries can
> be primary, backup, or near.
> PlatformCache seems to be a better name.
> Rename:
> * `PlatformNearCacheConfiguration` -> `PlatformCacheConfiguration`
> * `CachePeekMode.PlatformNear` -> `CachePeekMode.Platform`
> * `CacheConfiguration.PlatformNearConfiguration` ->
> `CacheConfiguration.PlatformCacheConfiguration`
> Mark all new platform (near) cache APIs with `[IgniteExperimental]`
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12438) Extend communication protocol to establish client-server connection
[ https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12438: -- Fix Version/s: 2.9 > Extend communication protocol to establish client-server connection > --- > > Key: IGNITE-12438 > URL: https://issues.apache.org/jira/browse/IGNITE-12438 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Recently there was quite a lot of questions related to thick clients > connectivity issues when the clients are deployed in a k8s pod [1]. The > general issue here is clients reporting network address which are not > reachable from server nodes. At the same time, the clients can connect to > server nodes. > An idea of how to fix this is as follows: > * Make sure that think clients discovery SPI always maintains a connection > to a server node (this should be already implemented) > * (Optionally) detect when a client has only one-way connectivity with the > server nodes. This part should be investigated. We need this to avoid server > nodes attempt to connect to a client and send communication request to the > client node faster > * When a server attempts to establish a connection with a client, check if > client is unreachable or the previous connection attempt failed. If so, send > a discovery message to the client to force a client-server connection. In > this case, server will be able to send the original message via the newly > established connection. > [1] > https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12875) Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event
[ https://issues.apache.org/jira/browse/IGNITE-12875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080358#comment-17080358 ] Ilya Kasnacheev commented on IGNITE-12875: -- Thank you for this improvement, I have merged it to master! > Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event > -- > > Key: IGNITE-12875 > URL: https://issues.apache.org/jira/browse/IGNITE-12875 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Current "EVT_CLUSTER_STATE" event is propagated only when transition is > finished, but it's impossible to track the start of "state transition". > For example, it makes no sense to invoke "deactivate" while someone else is > invoking "read_only" state transition at the same time. > Also this events might be useful for custom tools to monitor state of the > cluster and have more information about it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12875) Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event
[ https://issues.apache.org/jira/browse/IGNITE-12875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12875: - Component/s: general > Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event > -- > > Key: IGNITE-12875 > URL: https://issues.apache.org/jira/browse/IGNITE-12875 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Current "EVT_CLUSTER_STATE" event is propagated only when transition is > finished, but it's impossible to track the start of "state transition". > For example, it makes no sense to invoke "deactivate" while someone else is > invoking "read_only" state transition at the same time. > Also this events might be useful for custom tools to monitor state of the > cluster and have more information about it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12875) Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event
[ https://issues.apache.org/jira/browse/IGNITE-12875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12875: - Release Note: Implemented EVT_CLUSTER_STATE_CHANGE_STARTED event. > Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event > -- > > Key: IGNITE-12875 > URL: https://issues.apache.org/jira/browse/IGNITE-12875 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Current "EVT_CLUSTER_STATE" event is propagated only when transition is > finished, but it's impossible to track the start of "state transition". > For example, it makes no sense to invoke "deactivate" while someone else is > invoking "read_only" state transition at the same time. > Also this events might be useful for custom tools to monitor state of the > cluster and have more information about it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12875) Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event
[ https://issues.apache.org/jira/browse/IGNITE-12875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12875: - Release Note: (was: Thank you for this improvement, I have merged it to master!) > Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event > -- > > Key: IGNITE-12875 > URL: https://issues.apache.org/jira/browse/IGNITE-12875 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Current "EVT_CLUSTER_STATE" event is propagated only when transition is > finished, but it's impossible to track the start of "state transition". > For example, it makes no sense to invoke "deactivate" while someone else is > invoking "read_only" state transition at the same time. > Also this events might be useful for custom tools to monitor state of the > cluster and have more information about it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12872) Check of correct work of explicit security permissions
[ https://issues.apache.org/jira/browse/IGNITE-12872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080333#comment-17080333 ] Nikolay Izhikov commented on IGNITE-12872: -- LGTM > Check of correct work of explicit security permissions > -- > > Key: IGNITE-12872 > URL: https://issues.apache.org/jira/browse/IGNITE-12872 > Project: Ignite > Issue Type: Test >Reporter: Nikolay Izhikov >Assignee: Denis Garus >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We need to add 3 tests that checks explicit security permission for the cache. > 1. If a user has only CACHE_READ permission for some cache. > * get(and other read operations are permitted) > * put, remove (and other write operations are prohibited). > 2. If a user has only CACHE_REMOVE permission for some cache. > * put, get(and other reads/write operations are prohibited) > * remove (and other remove operations are permitted). > 3. If a user has only CACHE_PUT permission for some cache. > * get, remove(and other reads/remove operations are prohibited) > * put (and other write operations are permitted). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080328#comment-17080328 ] Dmitriy Sorokin commented on IGNITE-12764: -- Hello, [~tledkov-gridgain]! Thanks for reviewing of my patch! I think I fixed the code style flaws that you meant, please review my changes! > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12807) Key and Value fields with same name and SQL DML
[
https://issues.apache.org/jira/browse/IGNITE-12807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-12807:
--
Description:
Key/Value API allows both the Key and Value have fields with same name. This is
a very popular arrangement since most users are ready to sacrifice extra memory
footprint for the sake of having a self-sufficient value entity.
Using SQL DML to update such an entry will update only the key field, leaving
the value field unchanged. This is a huge usability issue for the mixed K/V and
SQL API apps.
h1. Proposal
h2. Requirements
h3. Example Data Model
Consider a business domain entity *Person \{ id: int, passportNo: String, name:
String }*
Suppose an Ignite application development team decided to map the Person entity
to Ignite data model as:
* *PersonKey \{ id: int, passportNo: String }*
* *Person \{ passportNo: String, name: String }*
h3. Public API
* *Cache API*: add new method {{setKeyValueFields(keyValueFields:
Set): QueryEntity}} to class {{QueryEntity}}
** The method marks Cache API Key and Value fields that SQL API must
initialize (on INSERT/MERGE) and update (on UPDATE/MERGE) together.
** It is still possible to use Cache API to initialize the fields marked with
{{setKeyValueFields}} to different values. SQL SELECT statement returns value
of such a field from the Key entity.
** The method accepts a set of field names and returns the declaring class
instance for chaining.
** The method throws {{ArgumentException}} if the Key and Value types are
available and the field types are different within the Key and Value entities.
* *SQL API*: add {{KEY_VALUE_FIELDS}} parameter to {{CREATE TABLE}}
statement's additional parameters list.
** The parameter's value is a space-separated list of field names with the
semantics equivalent to that of the {{setKeyValueFields}} method described
above.
** The parameter can be specified only if both the {{KEY_TYPE}} and
{{VALUE_TYPE}} parameters are specified.
h3. Use Cases
h4. Inserting Into Key and Value Fields With Same Name Initializes Both Fields
in QueryEntity-Defined Cache
* GIVEN a Person cache from the example data model configured like this in
Ignite:
{code:java}
new CacheConfiguration("CACHE")
.setQueryEntities(Collections.singleton(
new QueryEntity(PersonKey.class, Person.class)
.addQueryField("id", int.class.getName(), null)
.addQueryField("passportNo", String.class.getName(), null)
.addQueryField("name", String.class.getName(), null)
.setKeyFields(Collections.singleton("id"))
.setKeyValueFields(Collections.singleton("passportNo"))
));
{code}
** AND an entry is added to the cache with this SQL statement:
{code:sql}
INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1')
{code}
* WHEN the user gets the entity using Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
Person v = cache.get(K);
{code}
* THEN the *passportNo* field is initialized to the same value within the key
and value entities:
{code:java}
assertEquals(K.passportNo, v.passportNo);
{code}
h4. Querying Key and Value Fields With Same Name and Different Values Returns
Value from the Key in QueryEntity-Defined Cache
* GIVEN a Person cache from the previous use case
** AND an entry with different passportNo is added to the cache with this
Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
final Person V = new Person("2", "Name1");
cache.put(K, V);
{code}
* WHEN the user runs this SQL to get the enty:
{code:sql}
SELECT ID, PASSPORTNO, NAME FROM CACHE.Person
{code}
* THEN the retrieved PASSPORTNO is that of the Key: "1"
h4. Inserting Into Key and Value Fields With Same Name Initializes Both Fields
in SQL-Defined Cache
* GIVEN a Person cache from the example data model configured like this in
Ignite:
{code:sql}
CREATE TABLE Person (
id int,
passportNo varchar,
name varchar,
PRIMARY KEY(id, passportNo)
) WITH "key_type=PersonKey, value_type=Person, key_value_fields=passportNo"
{code}
** AND an entry is added to the cache with this SQL statement:
{code:sql}
INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1')
{code}
* WHEN the user gets the entity using Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
Person v = cache.get(K);
{code}
* THEN the *passportNo* field is initialized to the same value within the key
and value entities:
{code:java}
assertEquals(K.passportNo, v.passportNo);
{code}
h4. Querying Key and Value Fields With Same Name and Different Values Returns
Value from the Key in SQL-Defined Cache
* GIVEN a Person cache from the previous use case
** AND an entry with different passportNo is added to the cache with this
Cache API:
{code:java}
final PersonKey K =
[jira] [Updated] (IGNITE-12807) Key and Value fields with same name and SQL DML
[
https://issues.apache.org/jira/browse/IGNITE-12807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-12807:
--
Description:
Key/Value API allows both the Key and Value have fields with same name. This is
a very popular arrangement since most users are ready to sacrifice extra memory
footprint for the sake of having a self-sufficient value entity.
Using SQL DML to update such an entry will update only the key field, leaving
the value field unchanged. This is a huge usability issue for the mixed K/V and
SQL API apps.
h1. Proposal
h2. Requirements
h3. Example Data Model
Consider a business domain entity *Person \{ id: int, passportNo: String, name:
String }*
Suppose an Ignite application development team decided to map the Person entity
to Ignite data model as:
* *PersonKey \{ id: int, passportNo: String }*
* *Person \{ passportNo: String, name: String }*
h3. Public API
* *Cache API*: add new method {{setKeyValueFields(keyValueFields:
Set): QueryEntity}} to class {{QueryEntity}}
** The method marks Cache API Key and Value fields that SQL API must
initialize (on INSERT/MERGE) and update (on UPDATE/MERGE) together.
** It is still possible to use Cache API to initialize the fields marked with
{{setKeyValueFields}} to different values. SQL SELECT statement returns value
of such a field from the Key entity.
** The method accepts a set of field names and returns the declaring class
instance for chaining.
** The method throws {{ArgumentException}} if the Key and Value types are
available and the field types are different within the Key and Value entities.
* *SQL API*: add {{KEY_VALUE_FIELDS}} parameter to {{CREATE TABLE}}
statement's additional parameters list.
** The parameter's value is a space-separated list of field names with the
semantics equivalent to that of the {{setKeyValueFields}} method described
above.
** The parameter can be specified only if both the {{KEY_TYPE}} and
{{VALUE_TYPE}} parameters are specified.
h3. Use Cases
h4. Inserting Into Key and Value Fields With Same Name Initializes Both Fields
in QueryEntity-Defined Cache
* GIVEN a Person cache from the example data model configured like this in
Ignite:
{code:java}
new CacheConfiguration("CACHE")
.setQueryEntities(Collections.singleton(
new QueryEntity(PersonKey.class, Person.class)
.addQueryField("id", int.class.getName(), null)
.addQueryField("passportNo", String.class.getName(), null)
.addQueryField("name", String.class.getName(), null)
.setKeyFields(Collections.singleton("id"))
.setKeyValueFields(Collections.singleton("passportNo"))
));
{code}
** AND an entry is added to the cache with this SQL statement:
{code:sql}
INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1')
{code}
* WHEN the user gets the entity using Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
Person v = cache.get(K);
{code}
* THEN the *passportNo* field is initialized to the same value within the key
and value entities:
{code:java}
assertEquals(K.passportNo, v.passportNo);
{code}
h4. Querying Key and Value Fields With Same Name and Different Values Returns
Value from the Key in QueryEntity-Defined Cache
* GIVEN a Person cache from the previous use case
** AND an entry with different passportNo is added to the cache with this
Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
final Person V = new Person("2", "Name1");
cache.put(K, V);
{code}
* WHEN the user runs this SQL to get the enty:
{code:sql}
SELECT ID, PASSPORTNO, NAME FROM " + CACHE.Person {code}
* THEN the retrieved PASSPORTNO is that of the Key: "1"
h4. Inserting Into Key and Value Fields With Same Name Initializes Both Fields
in SQL-Defined Cache
* GIVEN a Person cache from the example data model configured like this in
Ignite:
{code:sql}
CREATE TABLE Person (
id int,
passportNo varchar,
name varchar,
PRIMARY KEY(id, passportNo)
) WITH "key_type=PersonKey, value_type=Person, key_value_fields=passportNo"
{code}
** AND an entry is added to the cache with this SQL statement:
{code:sql}
INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1')
{code}
* WHEN the user gets the entity using Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
Person v = cache.get(K);
{code}
* THEN the *passportNo* field is initialized to the same value within the key
and value entities:
{code:java}
assertEquals(K.passportNo, v.passportNo);
{code}
h4. Querying Key and Value Fields With Same Name and Different Values Returns
Value from the Key in SQL-Defined Cache
* GIVEN a Person cache from the previous use case
** AND an entry with different passportNo is added to the cache with this
Cache API:
{code:java}
final PersonKey
[jira] [Created] (IGNITE-12884) Extend debug output for restorePartitionStates method.
Stanilovsky Evgeny created IGNITE-12884: --- Summary: Extend debug output for restorePartitionStates method. Key: IGNITE-12884 URL: https://issues.apache.org/jira/browse/IGNITE-12884 Project: Ignite Issue Type: Improvement Components: persistence Affects Versions: 2.8 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Fix For: 2.9 There is a frequently need to investigate grid initializing time. Possibility to know additionally restored partitions size would be helpful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
[ https://issues.apache.org/jira/browse/IGNITE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080286#comment-17080286 ] Nikita Alemaskin commented on IGNITE-11494: --- Hello, [~amashenkov]! Could you, please, take a look at my changes. > Change message log message in case of too small > IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter > - > > Key: IGNITE-11494 > URL: https://issues.apache.org/jira/browse/IGNITE-11494 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Evgenii Zhuravlev >Assignee: Nikita Alemaskin >Priority: Major > Labels: newbie, usability > Attachments: > master_ee07f34e52_IGNITE-11494-large_set_logging_improving.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Message "Fetched result set was too large." should be changed to some > recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
[ https://issues.apache.org/jira/browse/IGNITE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Alemaskin updated IGNITE-11494: -- Comment: was deleted (was: Hello, [~jooger]! Could you, please, take a look at my changes.) > Change message log message in case of too small > IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter > - > > Key: IGNITE-11494 > URL: https://issues.apache.org/jira/browse/IGNITE-11494 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Evgenii Zhuravlev >Assignee: Nikita Alemaskin >Priority: Major > Labels: newbie, usability > Attachments: > master_ee07f34e52_IGNITE-11494-large_set_logging_improving.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Message "Fetched result set was too large." should be changed to some > recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12872) Check of correct work of explicit security permissions
[
https://issues.apache.org/jira/browse/IGNITE-12872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080271#comment-17080271
]
Ignite TC Bot commented on IGNITE-12872:
{panel:title=Branch: [pull/7651/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5207176buildTypeId=IgniteTests24Java8_RunAll]
> Check of correct work of explicit security permissions
> --
>
> Key: IGNITE-12872
> URL: https://issues.apache.org/jira/browse/IGNITE-12872
> Project: Ignite
> Issue Type: Test
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to add 3 tests that checks explicit security permission for the cache.
> 1. If a user has only CACHE_READ permission for some cache.
> * get(and other read operations are permitted)
> * put, remove (and other write operations are prohibited).
> 2. If a user has only CACHE_REMOVE permission for some cache.
> * put, get(and other reads/write operations are prohibited)
> * remove (and other remove operations are permitted).
> 3. If a user has only CACHE_PUT permission for some cache.
> * get, remove(and other reads/remove operations are prohibited)
> * put (and other write operations are permitted).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
