[jira] [Commented] (IGNITE-11868) GridClient#data() should be deprecated/removed.
[
https://issues.apache.org/jira/browse/IGNITE-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943242#comment-16943242
]
Denis A. Magda commented on IGNITE-11868:
-
[~slava.koptilin], as long as [~ivan.glukos] is not responding we are free to
merge the changes. Could you please merge the patch?
> GridClient#data() should be deprecated/removed.
> ---
>
> Key: IGNITE-11868
> URL: https://issues.apache.org/jira/browse/IGNITE-11868
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: kcheng.mvp
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It seems that {{GridClient#data()}} does not make sense after IGNITE-3488 and
> therefore it can be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11008) JDBC Metadata: redundant spaces IS_GENERATEDCOLUMN & BUFFER_LENGTH
[ https://issues.apache.org/jira/browse/IGNITE-11008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943240#comment-16943240 ] Denis A. Magda commented on IGNITE-11008: - [~Pavlukhin], could you help with the review here? > JDBC Metadata: redundant spaces IS_GENERATEDCOLUMN & BUFFER_LENGTH > -- > > Key: IGNITE-11008 > URL: https://issues.apache.org/jira/browse/IGNITE-11008 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.7 >Reporter: Stepan Pilschikov >Assignee: kcheng.mvp >Priority: Minor > Fix For: 2.8 > > > Found redundant spaces in > org.apache.ignite.internal.jdbc.thin.JdbcThinDatabaseMetadata#getColumns > "IS_GENERATEDCOLUMN " > "BUFFER_LENGTH " -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov reassigned IGNITE-9184: - Assignee: (was: Mikhail Cherkasov) > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8802) Need to fix Ignite INFO output
[
https://issues.apache.org/jira/browse/IGNITE-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942939#comment-16942939
]
Maxim Muzafarov commented on IGNITE-8802:
-
[~agoncharuk], [~dsetrakyan]
Folks, can you evaluate does this issue a `blocker` for 2.8 release?
Can we move it to the next one?
Can we set `major` priority?
> Need to fix Ignite INFO output
> --
>
> Key: IGNITE-8802
> URL: https://issues.apache.org/jira/browse/IGNITE-8802
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Dmitriy Setrakyan
>Assignee: Alexey Goncharuk
>Priority: Blocker
> Fix For: 2.8
>
>
> I have noticed that we output a lot of garbage, almost trace level
> information into the log. Moreover, such information is logged every time a
> topology changes.
>
> Here are examples:
>
> {quote}[22:32:06,330][INFO][exchange-worker-#42][GridDhtPartitionsExchangeFuture]
> Finished waiting for partition release future
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], waitTime=0ms,
> futInfo=NA]
> [22:32:06,624][INFO][grid-nio-worker-tcp-comm-0-#25][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/127.0.0.1:48100,
> rmtAddr=/127.0.0.1:62157]
> [22:32:06,663][INFO][exchange-worker-#42][GridDhtPartitionsExchangeFuture]
> Finished waiting for partitions release latch: ServerLatch [permits=0,
> pendingAcks=[], super=CompletableLatch [id=exchange,
> topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0]]]
> [22:32:06,664][INFO][exchange-worker-#42][GridDhtPartitionsExchangeFuture]
> Finished waiting for partition release future [topVer=AffinityTopologyVersion
> [topVer=2, minorTopVer=0], waitTime=0ms, futInfo=NA]
> [22:32:06,667][INFO][exchange-worker-#42][time] Finished exchange init
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], crd=true]
> [22:32:06,676][INFO][sys-#46][GridDhtPartitionsExchangeFuture] Coordinator
> received single message [ver=AffinityTopologyVersion [topVer=2,
> minorTopVer=0], node=bf2a5abd-4a7c-4a89-b760-1b8c8021cff3, allReceived=true]
> [22:32:06,694][INFO][sys-#46][GridDhtPartitionsExchangeFuture] Coordinator
> received all messages, try merge [ver=AffinityTopologyVersion [topVer=2,
> minorTopVer=0]]
> [22:32:06,694][INFO][sys-#46][GridDhtPartitionsExchangeFuture]
> finishExchangeOnCoordinator [topVer=AffinityTopologyVersion [topVer=2,
> minorTopVer=0], resVer=AffinityTopologyVersion [topVer=2, minorTopVer=0]]
> [22:32:06,703][INFO][sys-#46][GridDhtPartitionsExchangeFuture] Finish
> exchange future [startVer=AffinityTopologyVersion [topVer=2, minorTopVer=0],
> resVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], err=null]{quote}
>
> The information above does not belong at INFO level. This is a debug level or
> trace level output. I understand that it makes it easier to solve user
> issues, but in this case we should create a separate log category and log
> this stuff into a separate file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11189) Support Java 11 for Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-11189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11189: - Ignite Flags: Docs Required,Release Notes Required (was: Docs Required) > Support Java 11 for Apache Ignite > - > > Key: IGNITE-11189 > URL: https://issues.apache.org/jira/browse/IGNITE-11189 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Priority: Major > Labels: important, jdk11 > Time Spent: 10m > Remaining Estimate: 0h > > This is an umbrella ticket to link all Java 11 related efforts in one ticket. > 'Blocked by' link type is used in case change is mandatory to be done. > Other link types, e.g. 'related to' used for nice-to-have fixes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10696) Java 9/10/11 Support [2.8]
[ https://issues.apache.org/jira/browse/IGNITE-10696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10696: - Labels: important jdk11 (was: jdk11) > Java 9/10/11 Support [2.8] > -- > > Key: IGNITE-10696 > URL: https://issues.apache.org/jira/browse/IGNITE-10696 > Project: Ignite > Issue Type: Improvement >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Critical > Labels: important, jdk11 > Fix For: 2.8 > > > Enhance Apache Ignite with ability to build, test and run under JDK 9-11. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11189) Support Java 11 for Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-11189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11189: - Labels: important jdk11 (was: jdk11) > Support Java 11 for Apache Ignite > - > > Key: IGNITE-11189 > URL: https://issues.apache.org/jira/browse/IGNITE-11189 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Priority: Major > Labels: important, jdk11 > Time Spent: 10m > Remaining Estimate: 0h > > This is an umbrella ticket to link all Java 11 related efforts in one ticket. > 'Blocked by' link type is used in case change is mandatory to be done. > Other link types, e.g. 'related to' used for nice-to-have fixes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7787) Better error reporting when issuing PDS corruptions.
[ https://issues.apache.org/jira/browse/IGNITE-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7787: Fix Version/s: (was: 2.8) > Better error reporting when issuing PDS corruptions. > > > Key: IGNITE-7787 > URL: https://issues.apache.org/jira/browse/IGNITE-7787 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Alexei Scherbakov >Priority: Trivial > > If PDS is corrupted in any way and update hits bad page shown error message > is not very helping, usually something like "Failed to get page IO instance > (page content is corrupted)" > For corruptions related to CacheDataRowStore error should contain information > about how to fix the issue: clear data for cache/group and restart node for > partition reloading. > For corruptions related to H2Tree (SQL indexes) error should contain > suggestion to remove index.bin for broken partition and restart node allowing > index to rebuild. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9838) TxStateChangeEventTest fails sometimes on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9838: Fix Version/s: (was: 2.8) > TxStateChangeEventTest fails sometimes on TeamCity > -- > > Key: IGNITE-9838 > URL: https://issues.apache.org/jira/browse/IGNITE-9838 > Project: Ignite > Issue Type: Test >Reporter: Andrey Kuznetsov >Priority: Minor > > Both test methods may fail to acquire transaction lock. Presumably, timeout > increasing can be enough to fix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6753) Allow plugable page memory for testing purpose
[ https://issues.apache.org/jira/browse/IGNITE-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6753: Fix Version/s: (was: 2.8) > Allow plugable page memory for testing purpose > -- > > Key: IGNITE-6753 > URL: https://issues.apache.org/jira/browse/IGNITE-6753 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Priority: Minor > > Allow plugable page memory for testing proposes. We need this ability to > force fast IgniteOOM in tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-4718) Add section in documentation on what actions may cause deadlock
[ https://issues.apache.org/jira/browse/IGNITE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-4718: Fix Version/s: (was: 2.8) > Add section in documentation on what actions may cause deadlock > --- > > Key: IGNITE-4718 > URL: https://issues.apache.org/jira/browse/IGNITE-4718 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 1.8 >Reporter: Dmitry Karachentsev >Priority: Minor > > Ignite has number of common cases, where wrong usage of API may lead to > deadlocks, starvations, cluster hangs, and they should be properly > documented. > For example, cache operations is not allowed in CacheEntryProcessor, > ContinuousQuery's remote filter, etc. And in some callbacks it's possible to > use cache API if they annotated with @IgniteAsyncCallback. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10504) If client have cache resource with not configurate data region it stop by handler
[
https://issues.apache.org/jira/browse/IGNITE-10504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10504:
-
Fix Version/s: (was: 2.8)
> If client have cache resource with not configurate data region it stop by
> handler
> -
>
> Key: IGNITE-10504
> URL: https://issues.apache.org/jira/browse/IGNITE-10504
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: ARomantsov
>Priority: Minor
>
> {code:java}
> [16:02:08,932][SEVERE][exchange-worker-#58][] Critical system error detected.
> Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTyp
> es=SingletonSet [SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteCheckedException:
> Requested DataRegion is not configured: region-name2]]
> class org.apache.ignite.IgniteCheckedException: Requested DataRegion is not
> configured: region-name2
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.dataRegion(IgniteCacheDatabaseSharedManager.java:729)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:2641)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$getOrCreateCacheGroupContext$8(GridCacheProcessor.java:2415)
> at
> org.apache.ignite.internal.util.InitializationProtector.protect(InitializationProtector.java:60)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.getOrCreateCacheGroupContext(GridCacheProcessor.java:2412)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:2263)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$null$fd62dedb$1(GridCacheProcessor.java:2110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$4(GridCacheProcessor.java:2033)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$937cbe24$1(GridCacheProcessor.java:2107)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10891)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:2102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:2032)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1978)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:934)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:796)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2904)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2761)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
[ https://issues.apache.org/jira/browse/IGNITE-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-3878: Fix Version/s: (was: 2.8) > Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent > -- > > Key: IGNITE-3878 > URL: https://issues.apache.org/jira/browse/IGNITE-3878 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.7 >Reporter: Nikolay Tikhonov >Priority: Minor > > In some cases useful know where (on primary or backup nodes) was invoked a > continuous query filter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10771) Print troubleshooting hint when exchange latch got stucked
[
https://issues.apache.org/jira/browse/IGNITE-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10771:
-
Fix Version/s: (was: 2.8)
> Print troubleshooting hint when exchange latch got stucked
> --
>
> Key: IGNITE-10771
> URL: https://issues.apache.org/jira/browse/IGNITE-10771
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Priority: Minor
> Labels: usability
>
> Sometimes users face with a problem when exchange latch can't be completed:
> {noformat}
> 2018-12-12 07:07:57:563 [exchange-worker-#42] WARN
> o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture:488 - Unable to await
> partitions release latch within timeout: ClientLatch
> [coordinator=ZookeeperClusterNode [id=6b9fc6e4-5b6a-4a98-be4d-6bc1aa5c014c,
> addrs=[172.17.0.1, 10.0.230.117, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3,
> loc=false, client=false], ackSent=true, super=CompletableLatch [id=exchange,
> topVer=AffinityTopologyVersion [topVer=45, minorTopVer=1]]]
> {noformat}
> It may indicate that some node in a cluster can' t finish partitions release
> (finish all ongoing operations at the previous topology version) or it can be
> silent network problem.
> We should print to log a hint how to troubleshoot it to reduce the number of
> questions about such problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-6758) Slow memory releasing while deactivation
[ https://issues.apache.org/jira/browse/IGNITE-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6758: Fix Version/s: (was: 2.8) > Slow memory releasing while deactivation > > > Key: IGNITE-6758 > URL: https://issues.apache.org/jira/browse/IGNITE-6758 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.1 >Reporter: Alexander Belyak >Priority: Minor > Attachments: js.tdump > > > It take about 1 minutes to fill each page by 0 and release it to page pool in > PageMemoryImpl.ClearSegmentRunnable() from > GridCacheDatabaseSharedManager.onCacheGroupsStopped(). When we have 100+M > pages in hundred of Gb of pageCache in take quite long to > GridUnsafe.setMemory to 0 and in logs we get lot of "Failed to wait for > partition map exchange [topVer=AffinityTopologyVersion [topVer=56, minorTop > Ver=1], node=3676f020-0bf0-4145-861e-689c96d7e853]. Dumping pending objects > that might be the cause: " without any cause and progress > indicator. So full grid reboot take longer downtime with unnecessary > warnings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11583) Seems that copypasted code from ignite.sh is irrelevant in control.sh
[
https://issues.apache.org/jira/browse/IGNITE-11583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11583:
-
Fix Version/s: (was: 2.8)
> Seems that copypasted code from ignite.sh is irrelevant in control.sh
> -
>
> Key: IGNITE-11583
> URL: https://issues.apache.org/jira/browse/IGNITE-11583
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Minor
>
> That piece of code in *control.sh* is copypasted from *ignite.sh*, however,
> as main class for control utility is *CommandHandler* instead of
> *CommandLineStartup*, the whole _loop until $RESTART_SUCCESS_FILE is created_
> logic just never works.
> {noformat}
> ERRORCODE="-1"
> while [ "${ERRORCODE}" -ne "130" ]
> do
> if [ "${INTERACTIVE:-}" == "1" ] ; then
> case $osname in
> Darwin*)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${DOCK_OPTS}"
> "${RESTART_SUCCESS_OPT}" ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}"
> \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> *)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${RESTART_SUCCESS_OPT}"
> ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}"
> \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> esac
> else
> case $osname in
> Darwin*)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${DOCK_OPTS}"
> "${RESTART_SUCCESS_OPT}" ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false
> -DIGNITE_HOME="${IGNITE_HOME}" \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> *)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${RESTART_SUCCESS_OPT}"
> ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false
> -DIGNITE_HOME="${IGNITE_HOME}" \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> esac
> fi
> ERRORCODE="$?"
> if [ ! -f "${RESTART_SUCCESS_FILE}" ] ; then
> break
> else
> rm -f "${RESTART_SUCCESS_FILE}"
> fi
> done
> if [ -f "${RESTART_SUCCESS_FILE}" ] ; then
> rm -f "${RESTART_SUCCESS_FILE}"
> fi
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10014) MVCC usability: Improve description for concurrent operation exceptions
[
https://issues.apache.org/jira/browse/IGNITE-10014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10014:
-
Fix Version/s: (was: 2.8)
> MVCC usability: Improve description for concurrent operation exceptions
> ---
>
> Key: IGNITE-10014
> URL: https://issues.apache.org/jira/browse/IGNITE-10014
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Priority: Minor
>
> autocommit=false
> {code}
> create table test(id int primary key, field_int int, field_var varchar(50))
> with "template=partitioned, ATOMICITY=TRANSACTIONAL_SNAPSHOT";
> insert into test(id, field_int, field_var) values (1, 1, 'test_1');
> first user: `select * from test`
> second user: `update test set field_var = 'updated by second user' where id
> = 1`
> second user: `commit`
> second user: `select * from test`
> first user: `update test set field_var = 'updated by first user' where id =
> 1` -> java.sql.SQLException: Cannot serialize transaction due to write
> conflict...
> first user: `select * from test` -> java.sql.SQLException: Transaction is
> already completed.
> first user: `commit` -> java.sql.SQLException: Failed to execute DDL
> statement
> first user: `select * from test`
> second user: `select * from test`
> second user: `commit`
> second user: `select * from test`
> {code}
> Now unclear to get that i should use rollback instead of commit after
> "Transaction is already completed" exception
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10948) Ignition.Stop() methods (named, all, etc.) fail to Stop cluster nodes
[
https://issues.apache.org/jira/browse/IGNITE-10948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10948:
-
Fix Version/s: (was: 2.8)
(was: 3.0)
> Ignition.Stop() methods (named, all, etc.) fail to Stop cluster nodes
> -
>
> Key: IGNITE-10948
> URL: https://issues.apache.org/jira/browse/IGNITE-10948
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
> Environment: [08:32:01] __
> [08:32:01] / _/ ___/ |/ / _/_ __/ __/
> [08:32:01] _/ // (7 7 // / / / / _/
> [08:32:01] /___/\___/_/|_/___/ /_/ /___/
> [08:32:01]
> [08:32:01] ver. 2.7.1#20181210-sha1:a39dbf0f
> [08:32:01] 2018 Copyright(C) Apache Software Foundation
> [08:32:01]
> [08:32:01] Ignite documentation: http://ignite.apache.org
> [08:32:01]
> [08:32:01] Quiet mode.
> [08:32:01] ^-- Logging to file
> 'C:\apps\gridgain-ultimate-8.7.1\work\log\ignite-55082e2d.0.log'
> [08:32:01] ^-- Logging by 'JavaLogger [quiet=true, config=null]'
> [08:32:01] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
> "-v" to ignite.\{sh|bat}
> [08:32:01]
> [08:32:01] OS: Windows 10 10.0 amd64
> [08:32:01] VM information: Java(TM) SE Runtime Environment 1.8.0_162-b12
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.162-b12
>Reporter: Glenn Wiebe
>Priority: Minor
> Labels: StopCommand
>
> The Ignition singleton stop() or stopAll() methods do not respond by stopping
> any or all of the cluster nodes.
> Unlike the ignite.cluster().stop() methods, the Ignition.stop() methods
> ignore the requested stop command, simply returning the following warning:
> "(wrn) Ignoring stopping Ignite instance that was already stopped or never
> started: MyServerName"
> This fails whether the cluster was active() = true or false.
> This fails whether the command was issued from a Server or Client node.
> Maybe this method should be deprecated, but currently documented method does
> not work.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9740) [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up to IGNITE-9711)
[
https://issues.apache.org/jira/browse/IGNITE-9740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9740:
Fix Version/s: (was: 2.8)
> [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up
> to IGNITE-9711)
> ---
>
> Key: IGNITE-9740
> URL: https://issues.apache.org/jira/browse/IGNITE-9740
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Minor
>
> [EvaluatorTest|https://github.com/apache/ignite/blob/master/modules/ml/src/test/java/org/apache/ignite/ml/selection/scoring/evaluator/EvaluatorTest.java]
> involves {{IgniteThread}} which is in fact not needed there and should be
> removed.
> {{IgniteThread}} usage is a remainder / copy-paste from older tests and
> examples that were using API requiring it. This API has been removed and
> there is no need for wrapping like that anymore. For the reference on how to
> perform suggested cleanup check changes made to ml examples per IGNITE-9711.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11174) MVCC: Remove deprecated methods form MvccFeatureChecker.
[ https://issues.apache.org/jira/browse/IGNITE-11174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11174: - Fix Version/s: (was: 2.8) > MVCC: Remove deprecated methods form MvccFeatureChecker. > > > Key: IGNITE-11174 > URL: https://issues.apache.org/jira/browse/IGNITE-11174 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Andrey Mashenkov >Priority: Minor > Labels: MakeTeamcityGreenAgain > > Let's clean-up the code and remove MvccFeatureChecker.failIfNotSupported > method after moving to JUnit 4 completely. > MvccFeatureChecker.skipIfNotSupported should be used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10088) Partition is restored in moving state instead of owning if node restarted before first checkpoint.
[
https://issues.apache.org/jira/browse/IGNITE-10088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10088:
-
Fix Version/s: (was: 2.8)
> Partition is restored in moving state instead of owning if node restarted
> before first checkpoint.
> --
>
> Key: IGNITE-10088
> URL: https://issues.apache.org/jira/browse/IGNITE-10088
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Priority: Minor
>
> This is due to
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore#exists
> returning false when called from restorePartitionStates if not enough data
> was written to store due to checkpoint.
> Reproducer:
> {noformat}
> package org.apache.ignite.internal.processors.cache.transactions;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.Map;
> import java.util.Set;
> import org.apache.ignite.IgniteDataStreamer;
> import org.apache.ignite.IgniteSystemProperties;
> import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeFailureHandler;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.IgniteInternalFuture;
> import org.apache.ignite.internal.TestRecordingCommunicationSpi;
> import org.apache.ignite.internal.managers.communication.GridIoMessage;
> import
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxFinishRequest;
> import
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRebalanceTest;
> import org.apache.ignite.internal.processors.cache.verify.IdleVerifyResultV2;
> import org.apache.ignite.internal.util.typedef.T2;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.lang.IgnitePredicate;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
> import static org.apache.ignite.configuration.WALMode.LOG_ONLY;
> import static org.apache.ignite.testframework.GridTestUtils.runAsync;
> import static
> org.apache.ignite.transactions.TransactionConcurrency.PESSIMISTIC;
> import static
> org.apache.ignite.transactions.TransactionIsolation.REPEATABLE_READ;
> /**
> * Test data loss on recovery due to missed partition counter on tx messages
> reorder.
> */
> public class MovingPartitionAfterRestartNoBLTChangeTest extends
> GridCommonAbstractTest {
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new
> TcpDiscoveryVmIpFinder(true);
> /** */
> private static final int GRID_CNT = 2;
> /** */
> private static final int MB = 1024 * 1024;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId("node" + igniteInstanceName);
> ((TcpDiscoverySpi)cfg.getDiscoverySpi()).setIpFinder(IP_FINDER);
> boolean client = igniteInstanceName.startsWith("client");
> cfg.setClientMode(client);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration().
> setWalSegmentSize(12 *
> MB).setWalMode(LOG_ONLY).setPageSize(1024).setCheckpointFrequency(100L).
> setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true).
> setInitialSize(100 * MB).setMaxSize(100 * MB)));
> if (!client) {
> CacheConfiguration ccfg = new
> CacheConfiguration(DEFAULT_CACHE_NAME);
> ccfg.setAtomicityMode(TRANSACTIONAL);
> ccfg.setBackups(2);
> ccfg.setWriteSynchronizationMode(FULL_SYNC);
> ccfg.setOnheapCacheEnabled(false);
> ccfg.setAffinity(new
[jira] [Updated] (IGNITE-11466) MVCC: Remove irrelevant tests from mvcc suites.
[ https://issues.apache.org/jira/browse/IGNITE-11466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11466: - Fix Version/s: (was: 2.8) > MVCC: Remove irrelevant tests from mvcc suites. > --- > > Key: IGNITE-11466 > URL: https://issues.apache.org/jira/browse/IGNITE-11466 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Andrey Mashenkov >Priority: Minor > > For now we have 300+ muted tests related to Mvcc support for LOCAL caches. > As IGNITE-9530 has been closed with "wont fix" we have to > # Cleanup code and remove test clones like > IgniteCacheGroupsTest.testCacheIteratorMvccTxLocal > # Add LOCAL cache test classes to ignore list in Mvcc suites. > # Other tests should be disabled in Mvcc mode with Assumption and meaningful > message. > # All these tests should be unmuted on TC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10893) ClientListenerResponse.status uses codes both from IgniteQueryErrorCode and ClientListenerResponse itself.
[ https://issues.apache.org/jira/browse/IGNITE-10893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10893: - Fix Version/s: (was: 2.8) > ClientListenerResponse.status uses codes both from IgniteQueryErrorCode and > ClientListenerResponse itself. > --- > > Key: IGNITE-10893 > URL: https://issues.apache.org/jira/browse/IGNITE-10893 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Alexander Lapin >Priority: Minor > > ClientListenerResponse.status might be set as one of IgniteQueryErrorCode > constants. Besides that, ClientListenerResponse has few codes as constants > itself. These codes may intersect, in particular, > ClientListenerResponse.STATUS_FAILED == IgniteQueryErrorCode.UNKNOWN. Seems > that it works fine at the moment, however it looks unsafe. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12191) Add support of system view and metric to Visor
[
https://issues.apache.org/jira/browse/IGNITE-12191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12191:
-
Fix Version/s: (was: 2.8)
> Add support of system view and metric to Visor
> --
>
> Key: IGNITE-12191
> URL: https://issues.apache.org/jira/browse/IGNITE-12191
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Priority: Minor
> Labels: IEP-35
>
> After Ignite obtain new {{SystemView}} and {{Metric}} API we should add
> support of it to the Visor.
> User should be able to query and view any system view content or Metric
> Registry values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9094) Request for commit check is sent to backup nodes twice on primary node left.
[
https://issues.apache.org/jira/browse/IGNITE-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9094:
Fix Version/s: (was: 2.8)
> Request for commit check is sent to backup nodes twice on primary node left.
>
>
> Key: IGNITE-9094
> URL: https://issues.apache.org/jira/browse/IGNITE-9094
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Priority: Minor
>
> This causes twice as needed messages during recovery.
> First place:
> {noformat}
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxFinishRequest.(GridDhtTxFinishRequest.java:161)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.checkCommittedRequest(GridNearTxFinishFuture.java:911)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.access$400(GridNearTxFinishFuture.java:71)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture$FinishMiniFuture.onNodeLeft(GridNearTxFinishFuture.java:1005)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:820)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:741)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:479)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3354)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.onDone(GridNearPessimisticTxPrepareFuture.java:409)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.onDone(GridNearPessimisticTxPrepareFuture.java:58)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture$MiniFuture.onError(GridNearPessimisticTxPrepareFuture.java:515)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture$MiniFuture.onNodeLeft(GridNearPessimisticTxPrepareFuture.java:496)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.onNodeLeft(GridNearPessimisticTxPrepareFuture.java:87)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$4.onEvent(GridCacheMvccManager.java:266)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1384)
> at
>
[jira] [Updated] (IGNITE-10651) GridCachePartitionExchangeManager.affinityReadyFuture() should return GridDhtTopologyFuture instead of IgniteInternalFuture
[
https://issues.apache.org/jira/browse/IGNITE-10651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10651:
-
Fix Version/s: (was: 2.8)
> GridCachePartitionExchangeManager.affinityReadyFuture() should return
> GridDhtTopologyFuture instead of IgniteInternalFuture
> ---
>
> Key: IGNITE-10651
> URL: https://issues.apache.org/jira/browse/IGNITE-10651
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Priority: Minor
>
> Under some circumstances,
> {{GridCachePartitionExchangeManager.affinityReadyFuture}} returns
> {{GridFinishedFuture}} or
> {{GridCachePartitionExchangeManager.AffinityReadyFuture}}
> Obviously, the returned future cannot be used in order to validate a cache.
> It seems that this behavior can be improved if {{affinityReadyFuture()}}
> returns an instance of {{GridDhtTopologyFuture,}} and therefore, it will
> simplify the logic related to cache validation.
> Perhaps, {{ExchangeFutureSet}} can be changed to {{ExchangeFutureMap}} that
> should contain a mapping of topology version to the corresponding
> {{GridDhtTopologyFuture}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8098) Getting affinity for topology version earlier than affinity is calculated because of data race
[
https://issues.apache.org/jira/browse/IGNITE-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-8098:
Fix Version/s: (was: 2.8)
> Getting affinity for topology version earlier than affinity is calculated
> because of data race
> --
>
> Key: IGNITE-8098
> URL: https://issues.apache.org/jira/browse/IGNITE-8098
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Andrey Aleksandrov
>Priority: Minor
>
> From time to time the Ignite cluster with services throws next exception
> during restarting of some nodes:
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=c770dbcf-2908-442d-8aa0-bf26a2aecfef, addrs=[10.44.162.169, 127.0.0.1],
> sockAddrs=[clrv041279.ic.ing.net/10.44.162.169:56500, /127.0.0.1:56500],
> discPort=56500, order=11, intOrder=8, lastExchangeTime=1520931375337,
> loc=true, ver=2.3.3#20180213-sha1:f446df34, isClient=false],
> grp=ignite-sys-cache, topVer=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], head=AffinityTopologyVersion [topVer=15, minorTopVer=0],
> history=[AffinityTopologyVersion [topVer=11, minorTopVer=0],
> AffinityTopologyVersion [topVer=11, minorTopVer=1], AffinityTopologyVersion
> [topVer=12, minorTopVer=0], AffinityTopologyVersion [topVer=15,
> minorTopVer=0]]]
> Looks like the reason of this issue is the data race in GridServiceProcessor
> class.
> How to reproduce:
> 1)To simulate data race you should update next place in source code:
> Class: GridServiceProcessor
> Method: @Override public void onEvent(final DiscoveryEvent evt, final
> DiscoCache discoCache) {
> Place:
>
> try {
> svcName.set(dep.configuration().getName());
> ctx.cache().internalCache(UTILITY_CACHE_NAME).context().affinity().
> affinityReadyFuture(topVer).get();
> //HERE (between GET and REASSIGN) you should add Thread.sleep(100) for
> example.
> //try {
> //Thread.sleep(100);
> //}
> //catch (InterruptedException e1) {
> //e1.printStackTrace();
> //}
>
> reassign(dep, topVer);
> }
> catch (IgniteCheckedException ex) {
> if (!(e instanceof ClusterTopologyCheckedException))
> LT.error(log, ex, "Failed to do service reassignment (will retry): " +
> dep.configuration().getName());
> retries.add(dep);
> }
> ...
> 2)After that you should imitate start/shutdown iterations. For reproducing I
> used GridServiceProcessorBatchDeploySelfTest (but timeout on future.get
> should be increased to avoid timeout error)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8001) Web console: show more user-friendly error instead of 'Internal error'
[ https://issues.apache.org/jira/browse/IGNITE-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-8001: Fix Version/s: (was: 2.8) > Web console: show more user-friendly error instead of 'Internal error' > -- > > Key: IGNITE-8001 > URL: https://issues.apache.org/jira/browse/IGNITE-8001 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Pavel Konstantinov >Priority: Minor > Attachments: screenshot-1.png > > > In case if the backend is down we display the 'Internal error' message. > I suggest displaying some other more user-friendly text. > !screenshot-1.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9860) Unreliable listener invocation order in GridDhtPartitionsExchangeFuture#onDone
[
https://issues.apache.org/jira/browse/IGNITE-9860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9860:
Fix Version/s: (was: 2.8)
> Unreliable listener invocation order in GridDhtPartitionsExchangeFuture#onDone
> --
>
> Key: IGNITE-9860
> URL: https://issues.apache.org/jira/browse/IGNITE-9860
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Kuznetsov
>Priority: Minor
>
> Listener being added right before {{super.onDone()}} call is intended to be
> invoked earlier than all other listeners. There is a small probability of
> breaking this guarantee: some other thread can call {{listen()}} before
> future-completing thread enters {{super.onDone()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9003) walSegmentsCleared piece of checkpoint logging improvement
[ https://issues.apache.org/jira/browse/IGNITE-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9003: Fix Version/s: (was: 2.8) > walSegmentsCleared piece of checkpoint logging improvement > -- > > Key: IGNITE-9003 > URL: https://issues.apache.org/jira/browse/IGNITE-9003 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Priority: Minor > Original Estimate: 48h > Remaining Estimate: 48h > > In the IGNITE-8737 ticket *walSegmentsCovered* piece was added: now on > checkpoint finish absolute indexes of all wal segments that are not needed > anymore for restoring from this checkpoint are logged at info level. > The same thing should be done for *walSegmentsCleared* piece: instead of > number of cleared segments index range should be printed out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10576) MVCC TX: Rework UpdateSourceIterator to mix operation types
[ https://issues.apache.org/jira/browse/IGNITE-10576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10576: - Fix Version/s: (was: 2.8) > MVCC TX: Rework UpdateSourceIterator to mix operation types > --- > > Key: IGNITE-10576 > URL: https://issues.apache.org/jira/browse/IGNITE-10576 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Priority: Minor > > The current UpdateSourceIterator implementation doesn't suit Cache API needs. > It should be able to mix operation types per key. > For example we may execute putAll operation with a half of keys are having > values and a half aren't, this way we should mix DELETE operation for > null-value keys and PUT operation for others. > Another use case is a transform operation which should turn into a number of > PUT/UPDATE/DELETE operations on a backup node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10322) MVCC TX: Clean out messages.
[ https://issues.apache.org/jira/browse/IGNITE-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10322: - Fix Version/s: (was: 2.8) > MVCC TX: Clean out messages. > > > Key: IGNITE-10322 > URL: https://issues.apache.org/jira/browse/IGNITE-10322 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Priority: Minor > > Currently MvccSnapshot is a part of many message types and some of usages > look unnecessary. Since MvccSnapshot potentially can be really long (in > bytes) we need to review and possibly optimize all places where MvccSnapshot > is a message part. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6750) Return "wrong command" error in http rest api
[
https://issues.apache.org/jira/browse/IGNITE-6750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-6750:
Fix Version/s: (was: 2.8)
> Return "wrong command" error in http rest api
> -
>
> Key: IGNITE-6750
> URL: https://issues.apache.org/jira/browse/IGNITE-6750
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9, 2.0, 2.1, 2.2
>Reporter: Alexander Belyak
>Priority: Minor
>
> If I make mistake in command name, for example
> curl "http://localhost:8080/ignite?cmd=wrongcmd;
>
> I get no error message and nothing will be logged in ignite log (even in
> IGNITE_QUIET=false mode) and only by getting response code
> curl -I "http://localhost:8080/ignite?cmd=wrongcmd;
> HTTP/1.1 400 Bad Request
> Date: Wed, 25 Oct 2017 10:03:06 GMT
> Content-Type: application/json; charset=UTF-8
> Content-Length: 0
> Server: Jetty(9.2.11.v20150529)
> I can see something, but without root cause.
> We need:
> 1) return error text
> curl "http://localhost:8080/ignite?cmd=wrongcmd;
> {"successStatus":1,"sessionToken":null,"error":"Failed to handle request:
> [req=UNKNOWN, err=Failed to find command: wrongcmd]","response":null}
> as usual:
> curl "http://localhost:8080/ignite?cmd=get;
> {"successStatus":1,"sessionToken":null,"error":"Failed to handle request:
> [req=CACHE_GET, err=Failed to find mandatory parameter in request:
> key]","response":null}
> 2) set status code in http response to 400 (
> http://www.restapitutorial.com/httpstatuscodes.html )
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-7551) .NET: AtomicConfiguration parity test
[
https://issues.apache.org/jira/browse/IGNITE-7551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7551:
Fix Version/s: (was: 2.8)
> .NET: AtomicConfiguration parity test
> -
>
> Key: IGNITE-7551
> URL: https://issues.apache.org/jira/browse/IGNITE-7551
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
>
> See {{CacheConfigurationParityTest}} as an example, add same thing for
> {{AtomicConfiguration}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10757) Refactoring: split MvccProcessor into multiple components
[ https://issues.apache.org/jira/browse/IGNITE-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10757: - Fix Version/s: (was: 2.8) > Refactoring: split MvccProcessor into multiple components > - > > Key: IGNITE-10757 > URL: https://issues.apache.org/jira/browse/IGNITE-10757 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Ivan Pavlukhin >Priority: Minor > > In current implementation MvccProcessor has multiple responsibilities which > can be extracted into separate components. Also it looks like that we do not > need an independent processor here because all logic is bound to > CacheProcessor. At least 3 components could be created: > 1. ShapshotManager responsible for granting MVCC snapshots and handling > related messages. > 2. LockManager implementing (exclusive) locking for write operations and > associated wait queues. Deadlock detection facilities could be also placed > here. > 3. VacuumManager responsible for scavenging not needed anymore row versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10090) Fix `redundant type cast` inspections over the whole project code
[
https://issues.apache.org/jira/browse/IGNITE-10090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10090:
-
Fix Version/s: (was: 2.8)
> Fix `redundant type cast` inspections over the whole project code
> -
>
> Key: IGNITE-10090
> URL: https://issues.apache.org/jira/browse/IGNITE-10090
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Minor
> Labels: inspections
>
> We need to fix `redundant type cast` over the whole Apache Ignite project
> code.
> Enable this inspection with 'ERROR' type in
> {{idea\ignite_inspections_teamcity.xml}} configuration file.
> {code}
>enabled_by_default="false" />
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10849) [ML] Prepare a benchmark to compare Ignite ML and Spark MLeap inference performance
[ https://issues.apache.org/jira/browse/IGNITE-10849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10849: - Fix Version/s: (was: 2.8) > [ML] Prepare a benchmark to compare Ignite ML and Spark MLeap inference > performance > --- > > Key: IGNITE-10849 > URL: https://issues.apache.org/jira/browse/IGNITE-10849 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Priority: Minor > Labels: await > > In IGNITE-10810 we have added functionality that allows to import Spark > models saved using MLeap. Some of these models we already have in Ignite ML. > The goal of this task is to compare inference performance of Ignite ML and > Spark MLeap models in our environment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11246) Do not use pending entries tree in MVCC execution flow
[
https://issues.apache.org/jira/browse/IGNITE-11246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11246:
-
Fix Version/s: (was: 2.8)
> Do not use pending entries tree in MVCC execution flow
> --
>
> Key: IGNITE-11246
> URL: https://issues.apache.org/jira/browse/IGNITE-11246
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Minor
>
> Currently {{IgniteCacheOffheapManagerImpl#pendingEntries}} methods are called
> during mvcc execution flow. Looks irrelevant and should be cleaned up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10842) Exception during node stopping
[
https://issues.apache.org/jira/browse/IGNITE-10842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10842:
-
Fix Version/s: (was: 2.8)
> Exception during node stopping
> --
>
> Key: IGNITE-10842
> URL: https://issues.apache.org/jira/browse/IGNITE-10842
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: branch: master
> ver. 2.8.0-SNAPSHOT#20181228-sha1:e2edf41b
>Reporter: Ilya Suntsov
>Priority: Minor
> Attachments: ticket-logs.zip
>
>
> Steps:
> # Start 3 nodes: 1 yardstick driver and 2 servers
> # Almost simultaneously start all nodes. ( kill -9 -f "Dyardstick.server"/
> "Dyardstick.driver")
> Result:
> I see the following messages in log:
> {noformat}
> 2018-12-28 12:30:06,606][ERROR][sys-stripe-8-#9][TcpCommunicationSpi] Failed
> to send message to remote node [node=TcpDiscoveryNode
> [id=8e884f80-f55d-4b32-9dcd-39e1af0ed2ef, addrs=ArrayList [1
> class org.apache.ignite.spi.IgniteSpiException: Node is stopping.
> *<-->*at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2883)
> *<-->*at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2743)
> *<-->*at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2702)
> *<-->*at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1652)
> *<-->*at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1726)
> *<-->*at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1240)
> *<-->*at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1279)
> *<-->*at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.sendDeferredUpdateResponse(GridDhtAtomicCache.java:3548)
> *<-->*at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$3300(GridDhtAtomicCache.java:139)
> *<-->*at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$DeferredUpdateTimeout.run(GridDhtAtomicCache.java:3794)
> *<-->*at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:508)
> *<-->*at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> *<-->*at java.lang.Thread.run(Thread.java:745)
> [2018-12-28 12:30:06,658][ERROR][sys-stripe-12-#13][TcpCommunicationSpi]
> Failed to send message to remote node [node=TcpDiscoveryNode
> [id=8e884f80-f55d-4b32-9dcd-39e1af0ed2ef, addrs=ArrayList
> class org.apache.ignite.spi.IgniteSpiException: Node is stopping.
> *<-->*at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2883)
> *<-->*at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2743)
> *<-->*at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2702)
> *<-->*at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1652)
> *<-->*at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1726)
> *<-->*at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1240)
> *<-->*at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1279)
> *<-->*at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.sendDeferredUpdateResponse(GridDhtAtomicCache.java:3548)
> *<-->*at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$3300(GridDhtAtomicCache.java:139)
> *<-->*at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$DeferredUpdateTimeout.run(GridDhtAtomicCache.java:3794)
> *<-->*at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:508)
> *<-->*at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> *<-->*at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I guess it is redundant information on *Node stopping* stage.
> Please take a look at logs in the attachement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10782) javadoc description for ml.math.exceptions.preprocessing and ml.selection.scoring.evaluator
[ https://issues.apache.org/jira/browse/IGNITE-10782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10782: - Fix Version/s: (was: 2.8) > javadoc description for ml.math.exceptions.preprocessing and > ml.selection.scoring.evaluator > --- > > Key: IGNITE-10782 > URL: https://issues.apache.org/jira/browse/IGNITE-10782 > Project: Ignite > Issue Type: Bug > Components: documentation, ml >Affects Versions: 2.7 >Reporter: Stepan Pilschikov >Priority: Minor > > Need to add modules description for > - org.apache.ignite.ml.math.exceptions.preprocessing > - org.apache.ignite.ml.selection.scoring.evaluator > Located in ignite/docs/overview-summary.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10276) MVCC TX: Optimize logger creations
[ https://issues.apache.org/jira/browse/IGNITE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10276: - Fix Version/s: (was: 2.8) > MVCC TX: Optimize logger creations > -- > > Key: IGNITE-10276 > URL: https://issues.apache.org/jira/browse/IGNITE-10276 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Priority: Minor > Labels: mvcc_performance > > We need to initialize loggers in all new classes like it was done in > *GridDhtAtomicAbstractUpdateFuture* for example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11156) FreeLists are overflowed with pages with almost no free space left
[
https://issues.apache.org/jira/browse/IGNITE-11156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11156:
-
Fix Version/s: (was: 2.8)
> FreeLists are overflowed with pages with almost no free space left
> --
>
> Key: IGNITE-11156
> URL: https://issues.apache.org/jira/browse/IGNITE-11156
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> /** */
> private static final int MIN_PAGE_FREE_SPACE = 8;
> {code}
> If data page has 8 unused bytes or more, it will be stored in a free list. As
> result, free lists mostly contain "free pages" that are actually useless:
> pair of (boolean, boolean) takes approximately 50 bytes. I think, we'll
> increase this constant to something like 40, memory will be used more
> efficiently and WAL usage will decrease in result.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-10690:
--
Fix Version/s: (was: 2.8)
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3782)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
>
[jira] [Updated] (IGNITE-11938) SQL: Support java.time.Instant type as native time type
[ https://issues.apache.org/jira/browse/IGNITE-11938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-11938: -- Component/s: sql > SQL: Support java.time.Instant type as native time type > --- > > Key: IGNITE-11938 > URL: https://issues.apache.org/jira/browse/IGNITE-11938 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Kuznetsov >Priority: Major > > Currently Instant type is treated by Ignite as JAVA_OBJECT sql > type(IGNITE-10690). > But it can be possibly supported as one of the internal sql types. This > probably breaks backward compatibility, since indexes should be rebuild -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov resolved IGNITE-10690.
---
Release Note:
Not a bug. Type mapping is correct.
Firstly, we should review all date\time types convertion and theirs binary
format.
Then create a proper tickets to fix.
Resolution: Won't Fix
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
>
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942847#comment-16942847
]
Andrey Mashenkov commented on IGNITE-10690:
---
Instant mapping to Timestamp_with_tz is correct. So, this can be closed.
Also we've found date\time types has incorrect mapping in Ignite in some cases.
E.g. LocalDate, LocalTime shouldn't depends on Timezone. I'l create a ticket a
bit later.
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
>
[jira] [Assigned] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-10690:
-
Assignee: (was: Pavel Kuznetsov)
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3782)
> at
>
[jira] [Commented] (IGNITE-7832) Ignite.resetLostPartitions() resets state under race.
[ https://issues.apache.org/jira/browse/IGNITE-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942838#comment-16942838 ] Andrey Mashenkov commented on IGNITE-7832: -- [~mmuzaf], fix version removed as there is no activity on this ticket. > Ignite.resetLostPartitions() resets state under race. > - > > Key: IGNITE-7832 > URL: https://issues.apache.org/jira/browse/IGNITE-7832 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Andrey Mashenkov >Assignee: Vitaliy Biryukov >Priority: Critical > > Assume, we have event listener that detects partition loss events and apply > some actions to recover lost data. > After recovery process finished an Ignite.resetLostPartitions() method should > be called to mark all lost cache partitions as healthy. > It is possible Ignite.resetLostPartitions() will be called during exchange, > but right before a new partition loss event will be fired. > E.g. exchange thread own GridDhtPartitionTopologyImpl write lock in > detectLostPartitions() method, while user thread will wait for the lock > inside Ignite.resetLostPartitions(). > So, after a new partition loss will be detected, is will be not possible to > abort user action and state of just lost partition will be reset. > For that case, we should either abort resetLostPartitions() or reset > partitions state regarding topology version provided by user some how. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7832) Ignite.resetLostPartitions() resets state under race.
[ https://issues.apache.org/jira/browse/IGNITE-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-7832: - Fix Version/s: (was: 2.8) > Ignite.resetLostPartitions() resets state under race. > - > > Key: IGNITE-7832 > URL: https://issues.apache.org/jira/browse/IGNITE-7832 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Andrey Mashenkov >Assignee: Vitaliy Biryukov >Priority: Critical > > Assume, we have event listener that detects partition loss events and apply > some actions to recover lost data. > After recovery process finished an Ignite.resetLostPartitions() method should > be called to mark all lost cache partitions as healthy. > It is possible Ignite.resetLostPartitions() will be called during exchange, > but right before a new partition loss event will be fired. > E.g. exchange thread own GridDhtPartitionTopologyImpl write lock in > detectLostPartitions() method, while user thread will wait for the lock > inside Ignite.resetLostPartitions(). > So, after a new partition loss will be detected, is will be not possible to > abort user action and state of just lost partition will be reset. > For that case, we should either abort resetLostPartitions() or reset > partitions state regarding topology version provided by user some how. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10822) AbstractFreelist init reused page in wrong way.
[
https://issues.apache.org/jira/browse/IGNITE-10822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov resolved IGNITE-10822.
---
Resolution: Cannot Reproduce
> AbstractFreelist init reused page in wrong way.
> ---
>
> Key: IGNITE-10822
> URL: https://issues.apache.org/jira/browse/IGNITE-10822
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Andrey Mashenkov
>Priority: Critical
> Fix For: 2.8
>
>
> This is similar to IGNITE-9303.
> In IGNITE-9303 we missed wrong page flag check that hides this issue.
> After fixing page flag check, one of mvcc tests fails with assertion as
> Ignite can't lock page for write due to unknown reason: smth goes wrong with
> page tag.
> ExplicitWalDeltaConsistencyTest.testNotEmptyPds() fails in mvcc mode with
> next error
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:507)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetastorageRowStore.addRow(MetastorageRowStore.java:73)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.putData(MetaStorage.java:377)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:353)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.writeBaselineTopology(GridClusterStateProcessor.java:293)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForReadWrite(GridClusterStateProcessor.java:250)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForReadWrite(GridCacheDatabaseSharedManager.java:430)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.finishRecovery(GridCacheDatabaseSharedManager.java:884){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9867) Add ability to block out of range IP on discovery request
[
https://issues.apache.org/jira/browse/IGNITE-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942834#comment-16942834
]
Maxim Muzafarov commented on IGNITE-9867:
-
[~ARomantsov]
Hello, can we move this issue to the next release?
> Add ability to block out of range IP on discovery request
> -
>
> Key: IGNITE-9867
> URL: https://issues.apache.org/jira/browse/IGNITE-9867
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.7
>Reporter: ARomantsov
>Priority: Critical
> Fix For: 2.8
>
>
> Now we can set list of cluster collector node, but cannot deny another ips to
> connect to our cluster
> {code:java}
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10136) NPE in PartitionUpdateCountersMessage
[
https://issues.apache.org/jira/browse/IGNITE-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942832#comment-16942832
]
Maxim Muzafarov commented on IGNITE-10136:
--
[~skozlov]
Does this issue is still actual?
> NPE in PartitionUpdateCountersMessage
> -
>
> Key: IGNITE-10136
> URL: https://issues.apache.org/jira/browse/IGNITE-10136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
> Fix For: 2.8
>
>
> {noformat}
> [14:00:55,950][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=9d5398bc-896a-469c-8686-38e2afd517c1,
> startPtr=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=11ms,
> walCpRecordFsyncDuration=12ms, pages=636, reason='timeout']
> [14:00:56,029][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=9d5398bc-896a-469c-8686-38e2afd517c1, pages=636,
> markPos=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=26ms,
> pagesWrite=21ms, fsync=58ms, total=105ms]
> [14:00:56,940][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=5f46c89e-ead8-4c87-adad-72a50c26bd7c,
> startPtr=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=8ms,
> walCpRecordFsyncDuration=5ms, pages=474, reason='timeout']
> [14:00:57,003][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=5f46c89e-ead8-4c87-adad-72a50c26bd7c, pages=474,
> markPos=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=15ms,
> pagesWrite=10ms, fsync=53ms, total=78ms]
> [14:00:57,065][SEVERE][grid-nio-worker-tcp-comm-2-#42][GridDirectParser]
> Failed to read message [msg=GridIoMessage [plc=0, topic=null, topicOrd=-1,
> ordered=false, timeout=0, skipOnTimeout=false, msg=null],
> buf=java.nio.DirectByteBuffer[pos=792 lim=885 cap=32768],
> reader=RollingUpgradeMessageReader [state=StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=GridCacheIdMessage [cacheId=0]GridDistributedBaseMessage
> [ver=GridCacheVersion [topVer=152301622, order=1540821647376, nodeOrder=4],
> committedVers=null, rolledbackVers=null, cnt=0,
> super=]GridDistributedTxPrepareRequest [threadId=236,
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion
> [topVer=152301622, order=1540821647377, nodeOrder=4], timeout=0, reads=null,
> writes=ArrayList [], dhtVers=null, txSize=-1, plc=2, txState=null,
> flags=last, super=]GridDhtTxPrepareRequest
> [nearNodeId=3800f476-beb1-46b0-8a39-faa51c91831d,
> futId=f794020c661-cc8749ef-caa5-4f1e-9d89-4a9beff59798, miniId=1,
> topVer=AffinityTopologyVersion [topVer=5, minorTopVer=8],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=152301622, order=1540821647374,
> nodeOrder=5], subjId=3800f476-beb1-46b0-8a39-faa51c91831d, taskNameHash=0,
> preloadKeys=null, mvccSnapshot=MvccSnapshotResponse [futId=1,
> crdVer=1540821617885, cntr=16, opCntr=1, txs=null, cleanupVer=15,
> tracking=0], skipCompletedVers=false, super=], mapIt=null, it=null,
> arrPos=-1, keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0,
> uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true],
> state=0, fieldCnt=7, readFieldCnt=0, curName=msg, typeRead=true,
> itemTypeRead=false, keyTypeRead=false, valTypeRead=false, curType=21,
> curItemType=null, curKeyType=null, curValType=null, readMsgCls=class
> o.a.i.i.managers.communication.GridIoMessage]StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=PartitionUpdateCountersMessage{cacheId=-553317389, size=0, cntrs=},
> mapIt=null, it=null, arrPos=-1, keyDone=false, readSize=1, readItems=0,
> prim=0, primShift=0, uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0,
> lastFinished=true], state=0, fieldCnt=-1, readFieldCnt=0, curName=null,
> typeRead=false, itemTypeRead=false, keyTypeRead=false, valTypeRead=false,
> curType=0, curItemType=null, curKeyType=null, curValType=null,
> readMsgCls=null]StateItem [stream=DirectByteBufferStreamImplV2
> [baseOff=140703933959040, arrOff=-1, tmpArrOff=0, valReadBytes=0,
> tmpArrBytes=0, msgTypeDone=false, msg=null, mapIt=null, it=null, arrPos=-1,
> keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0, uuidState=0,
> uuidMost=0, uuidLeast=0,
[jira] [Commented] (IGNITE-7847) Increase of total owning partition count after rebalance
[ https://issues.apache.org/jira/browse/IGNITE-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942831#comment-16942831 ] Maxim Muzafarov commented on IGNITE-7847: - [~sbberkov] I've checked you step cases locally and can't reproduce it. It seems to me that this issue is already fixed. Can I close it? > Increase of total owning partition count after rebalance > > > Key: IGNITE-7847 > URL: https://issues.apache.org/jira/browse/IGNITE-7847 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Alexander Belyak >Priority: Critical > Fix For: 2.8 > > > 1) Start 3 nodes with persistence enabled > 2) Activate grid > 3) Create cache with 1 backup and remember owning partition count on node1 > 4) Stop node2, set BLT and note that local owning partitions on node1 > increased (to total number of partitions on cache) > 5) Start node, set BLT and waitRebalance and > Expected: owning partitions count on node1 became as on step 3 > Actual: owning partitions count on node1 still equals to step 4 value -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7832) Ignite.resetLostPartitions() resets state under race.
[ https://issues.apache.org/jira/browse/IGNITE-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942829#comment-16942829 ] Maxim Muzafarov commented on IGNITE-7832: - [~amashenkov] Can we move this issue to the next release? > Ignite.resetLostPartitions() resets state under race. > - > > Key: IGNITE-7832 > URL: https://issues.apache.org/jira/browse/IGNITE-7832 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Andrey Mashenkov >Assignee: Vitaliy Biryukov >Priority: Critical > Fix For: 2.8 > > > Assume, we have event listener that detects partition loss events and apply > some actions to recover lost data. > After recovery process finished an Ignite.resetLostPartitions() method should > be called to mark all lost cache partitions as healthy. > It is possible Ignite.resetLostPartitions() will be called during exchange, > but right before a new partition loss event will be fired. > E.g. exchange thread own GridDhtPartitionTopologyImpl write lock in > detectLostPartitions() method, while user thread will wait for the lock > inside Ignite.resetLostPartitions(). > So, after a new partition loss will be detected, is will be not possible to > abort user action and state of just lost partition will be reset. > For that case, we should either abort resetLostPartitions() or reset > partitions state regarding topology version provided by user some how. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10015) Sporadic JVM crash due to restart nodes
[
https://issues.apache.org/jira/browse/IGNITE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942828#comment-16942828
]
Maxim Muzafarov commented on IGNITE-10015:
--
[~skozlov]
Hello, I've moved this issue to the next release but can we close it? Does the
issue is still actual?
> Sporadic JVM crash due to restart nodes
>
>
> Key: IGNITE-10015
> URL: https://issues.apache.org/jira/browse/IGNITE-10015
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
> Fix For: 3.0, 2.9
>
> Attachments: hs_err_pid9126.log
>
>
> 1. Start 4 node cluster with pre-configured TTL caches.
> 2. Some 4 node may crash:
> {noformat}
> [22:43:01,485][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_002,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_013,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_001,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_012,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_004,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_015,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_003,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,006][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_014,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=ignite-sys-cache,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_011,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_010,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_009,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_006,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_005,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_016,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_008,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_007,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,012][INFO][db-checkpoint-thread-#68][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=214d43f2-6096-4b42-ab0f-52b7f98078f4,
> startPtr=FileWALPointer [idx=0, fileOff=513096, len=16483],
> checkpointLockWait=0ms, checkpointLockHoldTime=23ms,
> walCpRecordFsyncDuration=880ms, pages=238, reason='timeout']
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0x7) at pc=0x7f0aa29d8522, pid=12344, tid=0x7f08b15f5700
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build
> 1.8.0_161-b12)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # C [libzip.so+0x12522] newEntry+0x62
> #
> # Core dump written. Default location:
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/core or core.12344
> #
> # An error report file with more information is saved as:
> #
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/hs_err_pid12344.log
> Compiled method (nm)7845 558 n 0
> java.util.zip.ZipFile::getEntry (native)
> total in heap [0x7f0a8d3d1850,0x7f0a8d3d1bc0] = 880
> relocation [0x7f0a8d3d1978,0x7f0a8d3d19c0] = 72
> main code [0x7f0a8d3d19c0,0x7f0a8d3d1bc0] = 512
> [thread 139675315439360 also had an error]
>
[jira] [Commented] (IGNITE-10822) AbstractFreelist init reused page in wrong way.
[
https://issues.apache.org/jira/browse/IGNITE-10822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942826#comment-16942826
]
Maxim Muzafarov commented on IGNITE-10822:
--
[~amashenkov]
Does this issue is still actual?
> AbstractFreelist init reused page in wrong way.
> ---
>
> Key: IGNITE-10822
> URL: https://issues.apache.org/jira/browse/IGNITE-10822
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Andrey Mashenkov
>Priority: Critical
> Fix For: 2.8
>
>
> This is similar to IGNITE-9303.
> In IGNITE-9303 we missed wrong page flag check that hides this issue.
> After fixing page flag check, one of mvcc tests fails with assertion as
> Ignite can't lock page for write due to unknown reason: smth goes wrong with
> page tag.
> ExplicitWalDeltaConsistencyTest.testNotEmptyPds() fails in mvcc mode with
> next error
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:507)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetastorageRowStore.addRow(MetastorageRowStore.java:73)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.putData(MetaStorage.java:377)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:353)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.writeBaselineTopology(GridClusterStateProcessor.java:293)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForReadWrite(GridClusterStateProcessor.java:250)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForReadWrite(GridCacheDatabaseSharedManager.java:430)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.finishRecovery(GridCacheDatabaseSharedManager.java:884){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10015) Sporadic JVM crash due to restart nodes
[
https://issues.apache.org/jira/browse/IGNITE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10015:
-
Fix Version/s: (was: 2.8)
2.9
3.0
> Sporadic JVM crash due to restart nodes
>
>
> Key: IGNITE-10015
> URL: https://issues.apache.org/jira/browse/IGNITE-10015
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
> Fix For: 3.0, 2.9
>
> Attachments: hs_err_pid9126.log
>
>
> 1. Start 4 node cluster with pre-configured TTL caches.
> 2. Some 4 node may crash:
> {noformat}
> [22:43:01,485][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_002,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_013,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_001,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_012,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_004,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_015,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_003,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,006][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_014,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=ignite-sys-cache,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_011,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_010,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_009,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_006,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_005,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_016,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_008,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_007,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,012][INFO][db-checkpoint-thread-#68][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=214d43f2-6096-4b42-ab0f-52b7f98078f4,
> startPtr=FileWALPointer [idx=0, fileOff=513096, len=16483],
> checkpointLockWait=0ms, checkpointLockHoldTime=23ms,
> walCpRecordFsyncDuration=880ms, pages=238, reason='timeout']
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0x7) at pc=0x7f0aa29d8522, pid=12344, tid=0x7f08b15f5700
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build
> 1.8.0_161-b12)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # C [libzip.so+0x12522] newEntry+0x62
> #
> # Core dump written. Default location:
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/core or core.12344
> #
> # An error report file with more information is saved as:
> #
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/hs_err_pid12344.log
> Compiled method (nm)7845 558 n 0
> java.util.zip.ZipFile::getEntry (native)
> total in heap [0x7f0a8d3d1850,0x7f0a8d3d1bc0] = 880
> relocation [0x7f0a8d3d1978,0x7f0a8d3d19c0] = 72
> main code [0x7f0a8d3d19c0,0x7f0a8d3d1bc0] = 512
> [thread 139675315439360 also had an error]
> #
> # If you would like to submit a bug report, please visit:
> #
[jira] [Updated] (IGNITE-7330) When client connects during cluster activation process it hangs on obtaining cache proxy
[
https://issues.apache.org/jira/browse/IGNITE-7330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7330:
Fix Version/s: (was: 2.8)
2.9
3.0
> When client connects during cluster activation process it hangs on obtaining
> cache proxy
>
>
> Key: IGNITE-7330
> URL: https://issues.apache.org/jira/browse/IGNITE-7330
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Critical
> Labels: IEP-4, Phase-2
> Fix For: 3.0, 2.9
>
>
> The test below reproduces the issue:
> {noformat}
> public void testClientJoinWhenActivationInProgress() throws Exception {
> Ignite srv = startGrids(5);
> srv.active(true);
> srv.createCaches(Arrays.asList(cacheConfigurations1()));
> Map cacheData = new LinkedHashMap<>();
> for (int i = 1; i <= 100; i++) {
> for (CacheConfiguration ccfg : cacheConfigurations1()) {
> srv.cache(ccfg.getName()).put(-i, i);
> cacheData.put(-i, i);
> }
> }
> stopAllGrids();
> srv = startGrids(5);
> final CountDownLatch clientStartLatch = new CountDownLatch(1);
> IgniteInternalFuture clStartFut = GridTestUtils.runAsync(new
> Runnable() {
> @Override public void run() {
> try {
> clientStartLatch.await();
> Thread.sleep(10);
> client = true;
> Ignite cl = startGrid("client0");
> IgniteCache atomicCache =
> cl.cache(CACHE_NAME_PREFIX + '0');
> IgniteCache txCache =
> cl.cache(CACHE_NAME_PREFIX + '1');
> assertEquals(100, atomicCache.size());
> assertEquals(100, txCache.size());
> }
> catch (Exception e) {
> log.error("Error occurred", e);
> }
> }
> }, "client-starter-thread");
> clientStartLatch.countDown();
> srv.active(true);
> clStartFut.get();
> }
> {noformat}
> Expected behavior: test finishes successfully.
> Actual behavior: test hangs on waiting for client start future to complete
> while "client-started-thread" will be hanging on obtaining a reference to the
> first cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-1535) Evicted entries still are presented
[
https://issues.apache.org/jira/browse/IGNITE-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-1535:
Fix Version/s: (was: 2.8)
> Evicted entries still are presented
>
>
> Key: IGNITE-1535
> URL: https://issues.apache.org/jira/browse/IGNITE-1535
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Sergey Kozlov
>Priority: Critical
> Attachments: CacheFifoEvictExample.java, grid_evict.xml
>
>
> Test creates 4 caches: 2 PARTITIONED for testing and 2 REPLICATED for
> comparison. Each cache has FIFO eviction policy with maxSize=750.
> Test puts 1000 entries (order: 1 ... 1000) and check that 1..250 entries are
> removed and 251..1000 presented in cache.
> 1. Copy grid_evict.xml in examples/config directory
> 2. Copy CacheFifoEvictExample in
> examples/src/main/java/org/apache/ignite/examples/datagrid
> 3. Build examples
> 4. Run 3 nodes bin/ignite.sh examples/config/grid_evict.xml
> 5. Run CacheFifoEvictExample
> Expected output:
> {noformat}
> >>>cache_1
> put keys 1..1000
> get keys 1..1000
> >>>cache_2
> put keys 1..1000
> get keys 1..1000
> {noformat}
> Bur for PARTITIONED caches I got
> {noformat}
> >>>cache_1
> put keys 1..1000
> get keys 1..1000
> >>> not null value found for 18
> >>> not null value found for 19
> >>> not null value found for 20
> >>> not null value found for 21
> >>> not null value found for 22
> >>> not null value found for 23
> >>> not null value found for 24
> >>> not null value found for 25
> >>> not null value found for 28
> ...
> >>>cache_2
> put keys 1..1000
> get keys 1..1000
> >>> not null value found for 1
> >>> not null value found for 3
> >>> not null value found for 6
> >>> not null value found for 10
> >>> not null value found for 18
> >>> not null value found for 19
> >>> not null value found for 20
> >>> not null value found for 21
> >>> not null value found for 22
> >>> not null value found for 23
> >>> not null value found for 24
> >>> not null value found for 25
> ...
> {noformat}
> Delay between puts and gets doesn't fix the issue but add null values for
> keys > 250
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-5473) Create ignite troubleshooting logger
[ https://issues.apache.org/jira/browse/IGNITE-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-5473: Fix Version/s: (was: 2.8) 2.9 3.0 > Create ignite troubleshooting logger > > > Key: IGNITE-5473 > URL: https://issues.apache.org/jira/browse/IGNITE-5473 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Priority: Critical > Labels: important, observability > Fix For: 3.0, 2.9 > > > Currently, we have two extremes of logging - either INFO wich logs almost > nothing, or DEBUG, which will pollute logs with too verbose messages. > We should create a 'troubleshooting' logger, which should be easily enabled > (via a system property, for example) and log all stability-critical node and > cluster events: > * Connection events (both communication and discovery), handshake status > * ALL ignored messages and skipped actions (even those we assume are safe to > ignore) > * Partition exchange stages and timings > * Verbose discovery state changes (this should make it easy to understand > the reason for 'Node has not been connected to the topology') > * Transaction failover stages and actions > * All unlogged exceptions > * Responses that took more than N milliseconds when in normal they should > return right away > * Long discovery SPI messages processing times > * Managed service deployment stages > * Marshaller mappings registration and notification > * Binary metadata registration and notification > * Continuous query registration / notification > (add more) > The amount of logging should be chosen accurately so that it would be safe to > enable this logger in production clusters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-5836) AffinityFunctionContext should provide consistent previous assignment
[
https://issues.apache.org/jira/browse/IGNITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-5836:
Fix Version/s: (was: 2.8)
> AffinityFunctionContext should provide consistent previous assignment
> -
>
> Key: IGNITE-5836
> URL: https://issues.apache.org/jira/browse/IGNITE-5836
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Priority: Critical
> Labels: usability
>
> Currently each cache maintains its own {{AffinityFunctionContext}}. This
> leads to the case that {{previousAssignment}} can be different for two caches
> created on different topology versions. In particular, this broke
> {{FairAffinityFunction}} which was removed because of that.
> We should do the following:
> * Make sure that {{previousAssignment}} is consistent for all caches with
> same affinity function, regardless of topology versions caches were created
> on.
> * Add mechanism to enforce equality check for affinity functions. We probably
> will need to force user to implement {{equals}} for cache node filter and
> backup filter.
> * When above is done, bring back {{FairAffinityFunction}}.
> This is also discussed on dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Resurrect-FairAffinityFunction-td19987.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10684) Memory leak in persistent IgniteSet
[
https://issues.apache.org/jira/browse/IGNITE-10684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10684:
-
Fix Version/s: (was: None)
> Memory leak in persistent IgniteSet
> ---
>
> Key: IGNITE-10684
> URL: https://issues.apache.org/jira/browse/IGNITE-10684
> Project: Ignite
> Issue Type: Bug
> Components: data structures, persistence
>Affects Versions: 2.7
>Reporter: Alexey Belov
>Priority: Critical
> Labels: Ignite, igniteset, memory-leak, persistant
> Attachments: IgniteManagerTest [4] - JProfiler 9.2.1 4.jpg,
> IgniteManagerTest.start - JProfiler 9.2.1 2.jpg, IgniteManagerTest.start -
> JProfiler 9.2.1 3.jpg, IgniteManagerTest.start - JProfiler 9.2.1.jpg
>
>
> Hello. I have found a leak in IgniteSet with using persistence. Here is my
> Unit Test:
> {code:java}
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteSet;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.*;
> import org.junit.Test;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> import java.util.UUID;
> import java.util.concurrent.LinkedBlockingQueue;
> import java.util.concurrent.ThreadPoolExecutor;
> import java.util.concurrent.TimeUnit;
> /**
> * @author Alexey Belov
> */
> public class IgniteManagerTest {
> protected final Logger log =
> LoggerFactory.getLogger(IgniteManagerTest.class);
> private ThreadPoolExecutor ex = new ThreadPoolExecutor(8, 8,
> 0L, TimeUnit.MILLISECONDS,
> new LinkedBlockingQueue());
> @Test
> public void start() throws Exception {
> final IgniteConfiguration cfg = new IgniteConfiguration();
> final DataStorageConfiguration dataStorageConfiguration = new
> DataStorageConfiguration();
> final String igniteStorageDir = "g:\\work\\garbage\\igniteTest\\" +
> UUID.randomUUID().toString();
> System.out.println(igniteStorageDir);
> dataStorageConfiguration.setStoragePath(igniteStorageDir);
> final DataRegionConfiguration defaultDataRegionConfiguration =
> dataStorageConfiguration
> .getDefaultDataRegionConfiguration();
> defaultDataRegionConfiguration.setEvictionThreshold(0.9);
> defaultDataRegionConfiguration.setMetricsEnabled(true);
> defaultDataRegionConfiguration.setPersistenceEnabled(true);
> dataStorageConfiguration.setWalMode(WALMode.NONE);
> cfg.setDataStorageConfiguration(dataStorageConfiguration);
> final Ignite ignite = Ignition.start(cfg);
> ignite.cluster().active(true);
> while (true) {
> if (ex.getQueue().size() < 8) {
> System.out.println("added task " + ex.getQueue().size() + " "
> + ex.getActiveCount());
> ex.execute(() -> runQueues(ignite));
> }
> Thread.sleep(1000);
> }
> }
> private void qu() {
> }
> private void runQueues(Ignite ignite) {
> for (int j = 0; j < 10; j++) {
> final CollectionConfiguration setConfig = new
> CollectionConfiguration();
> setConfig.setCacheMode(CacheMode.LOCAL);
> setConfig.setBackups(0);
> final String name = "set-" + j + UUID.randomUUID().toString();
> setConfig.setGroupName(name);
> final IgniteSet set = ignite
> .set(name, setConfig);
> final int i1 = 1000;
> for (int i = 0; i < i1; i++) {
> final String elem1 = UUID.randomUUID().toString();
> set.add(elem1);
> }
> log.info(j + "write");
> set.clear();
> set.close();
> ignite.destroyCache(name);
> }
> log.info("Finish!");
> }
> }
> {code}
> See the attached screenshots from JProfiler.
> I think, that it should not be like this, because i clear the set and memory
> should be freed.
> If i launch this test with queue it works fine, memory becomes free after
> some time.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10684) Memory leak in persistent IgniteSet
[
https://issues.apache.org/jira/browse/IGNITE-10684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10684:
-
Ignite Flags: (was: Docs Required)
> Memory leak in persistent IgniteSet
> ---
>
> Key: IGNITE-10684
> URL: https://issues.apache.org/jira/browse/IGNITE-10684
> Project: Ignite
> Issue Type: Bug
> Components: data structures, persistence
>Affects Versions: 2.7
>Reporter: Alexey Belov
>Priority: Critical
> Labels: Ignite, igniteset, memory-leak, persistant
> Attachments: IgniteManagerTest [4] - JProfiler 9.2.1 4.jpg,
> IgniteManagerTest.start - JProfiler 9.2.1 2.jpg, IgniteManagerTest.start -
> JProfiler 9.2.1 3.jpg, IgniteManagerTest.start - JProfiler 9.2.1.jpg
>
>
> Hello. I have found a leak in IgniteSet with using persistence. Here is my
> Unit Test:
> {code:java}
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteSet;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.*;
> import org.junit.Test;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> import java.util.UUID;
> import java.util.concurrent.LinkedBlockingQueue;
> import java.util.concurrent.ThreadPoolExecutor;
> import java.util.concurrent.TimeUnit;
> /**
> * @author Alexey Belov
> */
> public class IgniteManagerTest {
> protected final Logger log =
> LoggerFactory.getLogger(IgniteManagerTest.class);
> private ThreadPoolExecutor ex = new ThreadPoolExecutor(8, 8,
> 0L, TimeUnit.MILLISECONDS,
> new LinkedBlockingQueue());
> @Test
> public void start() throws Exception {
> final IgniteConfiguration cfg = new IgniteConfiguration();
> final DataStorageConfiguration dataStorageConfiguration = new
> DataStorageConfiguration();
> final String igniteStorageDir = "g:\\work\\garbage\\igniteTest\\" +
> UUID.randomUUID().toString();
> System.out.println(igniteStorageDir);
> dataStorageConfiguration.setStoragePath(igniteStorageDir);
> final DataRegionConfiguration defaultDataRegionConfiguration =
> dataStorageConfiguration
> .getDefaultDataRegionConfiguration();
> defaultDataRegionConfiguration.setEvictionThreshold(0.9);
> defaultDataRegionConfiguration.setMetricsEnabled(true);
> defaultDataRegionConfiguration.setPersistenceEnabled(true);
> dataStorageConfiguration.setWalMode(WALMode.NONE);
> cfg.setDataStorageConfiguration(dataStorageConfiguration);
> final Ignite ignite = Ignition.start(cfg);
> ignite.cluster().active(true);
> while (true) {
> if (ex.getQueue().size() < 8) {
> System.out.println("added task " + ex.getQueue().size() + " "
> + ex.getActiveCount());
> ex.execute(() -> runQueues(ignite));
> }
> Thread.sleep(1000);
> }
> }
> private void qu() {
> }
> private void runQueues(Ignite ignite) {
> for (int j = 0; j < 10; j++) {
> final CollectionConfiguration setConfig = new
> CollectionConfiguration();
> setConfig.setCacheMode(CacheMode.LOCAL);
> setConfig.setBackups(0);
> final String name = "set-" + j + UUID.randomUUID().toString();
> setConfig.setGroupName(name);
> final IgniteSet set = ignite
> .set(name, setConfig);
> final int i1 = 1000;
> for (int i = 0; i < i1; i++) {
> final String elem1 = UUID.randomUUID().toString();
> set.add(elem1);
> }
> log.info(j + "write");
> set.clear();
> set.close();
> ignite.destroyCache(name);
> }
> log.info("Finish!");
> }
> }
> {code}
> See the attached screenshots from JProfiler.
> I think, that it should not be like this, because i clear the set and memory
> should be freed.
> If i launch this test with queue it works fine, memory becomes free after
> some time.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942820#comment-16942820 ] Maxim Muzafarov commented on IGNITE-9184: - [~mcherkasov] Hello, any updates? > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942818#comment-16942818
]
Maxim Muzafarov commented on IGNITE-9068:
-
[~ilantukh], [~ilyak], [~agoncharuk]
Folks, any updates? Can we move it to the next release since there is no
attention to this issue for more that one year?
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Blocker
> Labels: test
> Fix For: 2.8
>
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> 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.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
> at
>
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942816#comment-16942816
]
Maxim Muzafarov commented on IGNITE-10690:
--
[~pkouznet], [~amashenkov]
Folks, any updates over this issue?
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3782)
> at
>
[jira] [Commented] (IGNITE-8552) Unable to use date as primary key
[ https://issues.apache.org/jira/browse/IGNITE-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942815#comment-16942815 ] Maxim Muzafarov commented on IGNITE-8552: - Folks, any updates? Does this issue is still actual? > Unable to use date as primary key > - > > Key: IGNITE-8552 > URL: https://issues.apache.org/jira/browse/IGNITE-8552 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Priority: Blocker > Fix For: 2.8 > > Attachments: IGNITE-8552_implemented.patch > > > It' is unable to create cache via ddl: > create table tab(id date primary key, date_field date); > Result: > ERROR CacheAffinitySharedManager - Failed to initialize cache. Will try to > rollback cache start routine. [cacheName=SQL_PUBLIC_T3] > class org.apache.ignite.IgniteCheckedException: Failed to find value class in > the node classpath (use default marshaller to enable binary objects) : > SQL_PUBLIC_T3_e90848b2_fe30_4adb_a934_6e13ca0eb409 > at > org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:426) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8771) OutOfMemory in Cache2 suite in master branch on TC
[ https://issues.apache.org/jira/browse/IGNITE-8771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942812#comment-16942812 ] Maxim Muzafarov commented on IGNITE-8771: - [~sergey-chugunov] Is this issue is still actual? Can we close it? I see no error in the master branch for this suite. https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache2=buildTypeStatusDiv_IgniteTests24Java8=%3Cdefault%3E] > OutOfMemory in Cache2 suite in master branch on TC > -- > > Key: IGNITE-8771 > URL: https://issues.apache.org/jira/browse/IGNITE-8771 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > OutOfMemory error happened in Cache2 suite for the first time in a while: > [https://ci.ignite.apache.org/viewLog.html?buildId=1372380=buildResultsDiv=IgniteTests24Java8_Cache2] > Recent history doesn't contain any OOMs or execution timeouts for this suite: > [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache2_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-3212) Servers get stuck with the warning "Failed to wait for initial partition map exchange" during falover test
[
https://issues.apache.org/jira/browse/IGNITE-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-3212:
Fix Version/s: (was: 1.9)
> Servers get stuck with the warning "Failed to wait for initial partition map
> exchange" during falover test
> --
>
> Key: IGNITE-3212
> URL: https://issues.apache.org/jira/browse/IGNITE-3212
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Priority: Critical
>
> Servers being restarted during failover test get stuck after some time with
> the warning "Failed to wait for initial partition map exchange".
> {noformat}
> [08:44:41,303][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Added new node to topology: TcpDiscoveryNode
> [id=db557f04-43b7-4e28-ae0d-d4dcf4139c89, addrs=
> [10.20.0.222, 127.0.0.1], sockAddrs=[fosters-222/10.20.0.222:47503,
> /10.20.0.222:47503, /127.0.0.1:47503], discPort=47503, order=44, intOrder=32,
> lastExchangeTime=1464
> 363880917, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:44:41,304][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Topology snapshot [ver=44, servers=19, clients=1, CPUs=64, heap=160.0GB]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Added new node to topology: TcpDiscoveryNode
> [id=6fae61a7-c1c1-40e5-8ad0-8bf5d6c86eb7, addrs=
> [10.20.0.223, 127.0.0.1], sockAddrs=[fosters-223/10.20.0.223:47503,
> /10.20.0.223:47503, /127.0.0.1:47503], discPort=47503, order=45, intOrder=33,
> lastExchangeTime=1464
> 363910999, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Topology snapshot [ver=45, servers=20, clients=1, CPUs=64, heap=170.0GB]
> [08:45:19,942][INFO ][ignite-update-notifier-timer][GridUpdateNotifier]
> Update status is not available.
> [08:46:20,370][WARN ][main][GridCachePartitionExchangeManager] Failed to wait
> for initial partition map exchange. Possible reasons are:
> ^-- Transactions in deadlock.
> ^-- Long running transactions (ignore if this is the case).
> ^-- Unreleased explicit locks.
> [08:48:30,375][WARN ][main][GridCachePartitionExchangeManager] Still waiting
> for initial partition map exchange ...
> {noformat}
> "Failed to wait for partition release future" warnings are on other nodes.
> {noformat}
> [08:09:45,822][WARN
> ][exchange-worker-#82%null%][GridDhtPartitionsExchangeFuture] Failed to wait
> for partition release future [topVer=AffinityTopologyVersion [topVer=29,
> minorTopVer=0], node=cab5d0e0-7365-4774-8f99-d9f131c5d896]. Dumping pending
> objects that might be the cause:
> [08:09:45,822][WARN
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Ready
> affinity version: AffinityTopologyVersion [topVer=28, minorTopVer=1]
> [08:09:45,826][WARN
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Last exchange
> future: GridDhtPartitionsExchangeFuture ...
> {noformat}
> Load config:
> - 1 client, 20 servers (5 servers per 1 host)
> - warmup 60
> - duration 66h
> - preload 5M
> - key range 10M
> - operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL
> PUT_IF_ABSENT REPLACE
> - backups count 3
> - 3 servers restart every 15 min with 30 sec step, pause between stop and
> start 5min
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-3212) Servers get stuck with the warning "Failed to wait for initial partition map exchange" during falover test
[
https://issues.apache.org/jira/browse/IGNITE-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-3212:
Fix Version/s: 2.9
3.0
> Servers get stuck with the warning "Failed to wait for initial partition map
> exchange" during falover test
> --
>
> Key: IGNITE-3212
> URL: https://issues.apache.org/jira/browse/IGNITE-3212
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Priority: Critical
> Fix For: 3.0, 2.9
>
>
> Servers being restarted during failover test get stuck after some time with
> the warning "Failed to wait for initial partition map exchange".
> {noformat}
> [08:44:41,303][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Added new node to topology: TcpDiscoveryNode
> [id=db557f04-43b7-4e28-ae0d-d4dcf4139c89, addrs=
> [10.20.0.222, 127.0.0.1], sockAddrs=[fosters-222/10.20.0.222:47503,
> /10.20.0.222:47503, /127.0.0.1:47503], discPort=47503, order=44, intOrder=32,
> lastExchangeTime=1464
> 363880917, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:44:41,304][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Topology snapshot [ver=44, servers=19, clients=1, CPUs=64, heap=160.0GB]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Added new node to topology: TcpDiscoveryNode
> [id=6fae61a7-c1c1-40e5-8ad0-8bf5d6c86eb7, addrs=
> [10.20.0.223, 127.0.0.1], sockAddrs=[fosters-223/10.20.0.223:47503,
> /10.20.0.223:47503, /127.0.0.1:47503], discPort=47503, order=45, intOrder=33,
> lastExchangeTime=1464
> 363910999, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Topology snapshot [ver=45, servers=20, clients=1, CPUs=64, heap=170.0GB]
> [08:45:19,942][INFO ][ignite-update-notifier-timer][GridUpdateNotifier]
> Update status is not available.
> [08:46:20,370][WARN ][main][GridCachePartitionExchangeManager] Failed to wait
> for initial partition map exchange. Possible reasons are:
> ^-- Transactions in deadlock.
> ^-- Long running transactions (ignore if this is the case).
> ^-- Unreleased explicit locks.
> [08:48:30,375][WARN ][main][GridCachePartitionExchangeManager] Still waiting
> for initial partition map exchange ...
> {noformat}
> "Failed to wait for partition release future" warnings are on other nodes.
> {noformat}
> [08:09:45,822][WARN
> ][exchange-worker-#82%null%][GridDhtPartitionsExchangeFuture] Failed to wait
> for partition release future [topVer=AffinityTopologyVersion [topVer=29,
> minorTopVer=0], node=cab5d0e0-7365-4774-8f99-d9f131c5d896]. Dumping pending
> objects that might be the cause:
> [08:09:45,822][WARN
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Ready
> affinity version: AffinityTopologyVersion [topVer=28, minorTopVer=1]
> [08:09:45,826][WARN
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Last exchange
> future: GridDhtPartitionsExchangeFuture ...
> {noformat}
> Load config:
> - 1 client, 20 servers (5 servers per 1 host)
> - warmup 60
> - duration 66h
> - preload 5M
> - key range 10M
> - operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL
> PUT_IF_ABSENT REPLACE
> - backups count 3
> - 3 servers restart every 15 min with 30 sec step, pause between stop and
> start 5min
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10698) Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
[
https://issues.apache.org/jira/browse/IGNITE-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-10698:
-
Labels: newbie usability (was: usability)
> Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
> ---
>
> Key: IGNITE-10698
> URL: https://issues.apache.org/jira/browse/IGNITE-10698
> Project: Ignite
> Issue Type: Task
>Reporter: Yakov Zhdanov
>Priority: Major
> Labels: newbie, usability
> Fix For: 3.0
>
>
> {noformat}
> @MXBeanDescription("Returns or kills transactions matching the filter
> conditions.")
> @MXBeanParametersNames(
> {
> "minDuration",
> "minSize",
> "prj",
> "consistentIds",
> "xid",
> "lbRegex",
> "limit",
> "order",
> "detailed",
> "kill"
> }
> )
> @MXBeanParametersDescriptions(
> {
> "Minimum duration (seconds).",
> "Minimum size.",
> "Projection (servers|clients).",
> "Consistent ids (separated by comma).",
> "Transaction XID.",
> "Label regexp.",
> "Limit a number of transactions collected on each node.",
> "Order by DURATION|SIZE.",
> "Show detailed description, otherwise only count.",
> "Kill matching transactions (be careful)."
> }
> )
> {noformat}
> Above looks pretty ugly and is very error prone due to messing names and
> descr order or number of strings.
> I would suggest to introduce individual parameters annotations and get them
> via mtd.getParamterAnnotations() at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11024) PME leave server node -69%
[ https://issues.apache.org/jira/browse/IGNITE-11024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942805#comment-16942805 ] Maxim Muzafarov commented on IGNITE-11024: -- [~mshonichev], Is this issue is still actual? > PME leave server node -69% > -- > > Key: IGNITE-11024 > URL: https://issues.apache.org/jira/browse/IGNITE-11024 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Critical > Fix For: 2.5 > > > PME benchmark leave server node -69% -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11451) SQL system view for IO indexes statistics
[ https://issues.apache.org/jira/browse/IGNITE-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11451: - Ignite Flags: Docs Required,Release Notes Required (was: Docs Required) > SQL system view for IO indexes statistics > - > > Key: IGNITE-11451 > URL: https://issues.apache.org/jira/browse/IGNITE-11451 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: IEP-35, iep-29 > Fix For: 3.0, 2.9 > > > Need to expose system SQL views to be able view IO statistics for SQL indexes. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11451) SQL system view for IO indexes statistics
[ https://issues.apache.org/jira/browse/IGNITE-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11451: - Fix Version/s: 2.9 3.0 > SQL system view for IO indexes statistics > - > > Key: IGNITE-11451 > URL: https://issues.apache.org/jira/browse/IGNITE-11451 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: IEP-35, iep-29 > Fix For: 3.0, 2.9 > > > Need to expose system SQL views to be able view IO statistics for SQL indexes. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11451) SQL system view for IO indexes statistics
[ https://issues.apache.org/jira/browse/IGNITE-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11451: - Fix Version/s: (was: 1.8) > SQL system view for IO indexes statistics > - > > Key: IGNITE-11451 > URL: https://issues.apache.org/jira/browse/IGNITE-11451 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: IEP-35, iep-29 > > Need to expose system SQL views to be able view IO statistics for SQL indexes. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9011) RendezvousAffinity.excludeNeighbors should be removed and be a default behavior
[ https://issues.apache.org/jira/browse/IGNITE-9011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9011: Fix Version/s: 2.9 > RendezvousAffinity.excludeNeighbors should be removed and be a default > behavior > --- > > Key: IGNITE-9011 > URL: https://issues.apache.org/jira/browse/IGNITE-9011 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.6 >Reporter: Dmitry Karachentsev >Priority: Major > Fix For: 3.0, 2.9 > > > According to this [discussion | > http://apache-ignite-developers.2346864.n4.nabble.com/Neighbors-exclusion-td32550.html], > cache backup distribution should be more straightforward. > Right now we have not obvious logic on how backups will be stored across > nodes. For example: > 1. If set nodeFilter, it will filter backup nodes and if there are not enough > nodes there will be less backups... > 2. If set property excludeNeighbors, it will ignore manually set backupFilter. > 3. By default excludeNeighbors is false. > There seems no need to keep excludeNeighbors property at all and it should be > removed. Instead, node always must do the best to distribute backups to > different machines. > If user set backupFilter, it must be used, otherwise distribute backups to > other machines if it's possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11451) SQL system view for IO indexes statistics
[ https://issues.apache.org/jira/browse/IGNITE-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11451: - Labels: IEP-35 iep-29 (was: iep-29) > SQL system view for IO indexes statistics > - > > Key: IGNITE-11451 > URL: https://issues.apache.org/jira/browse/IGNITE-11451 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: IEP-35, iep-29 > Fix For: 1.8 > > > Need to expose system SQL views to be able view IO statistics for SQL indexes. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11451) SQL system view for IO indexes statistics
[
https://issues.apache.org/jira/browse/IGNITE-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942802#comment-16942802
]
Nikolay Izhikov commented on IGNITE-11451:
--
Hello, [~jooger]
Seems, you should use {{SystemView}} API during the implementation of this
ticket.
> SQL system view for IO indexes statistics
> -
>
> Key: IGNITE-11451
> URL: https://issues.apache.org/jira/browse/IGNITE-11451
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: IEP-35, iep-29
> Fix For: 1.8
>
>
> Need to expose system SQL views to be able view IO statistics for SQL indexes.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11417) Get rid of CacheRebalanceMode#NONE
[
https://issues.apache.org/jira/browse/IGNITE-11417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11417:
-
Ignite Flags: Docs Required,Release Notes Required (was: Docs Required)
> Get rid of CacheRebalanceMode#NONE
> --
>
> Key: IGNITE-11417
> URL: https://issues.apache.org/jira/browse/IGNITE-11417
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Roman Kondakov
>Priority: Major
> Fix For: 3.0
>
>
> We should get rid of erroneous and unusable rebalance mode {{NONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11417) Get rid of CacheRebalanceMode#NONE
[
https://issues.apache.org/jira/browse/IGNITE-11417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11417:
-
Fix Version/s: 2.9
> Get rid of CacheRebalanceMode#NONE
> --
>
> Key: IGNITE-11417
> URL: https://issues.apache.org/jira/browse/IGNITE-11417
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Roman Kondakov
>Priority: Major
> Fix For: 3.0, 2.9
>
>
> We should get rid of erroneous and unusable rebalance mode {{NONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7330) When client connects during cluster activation process it hangs on obtaining cache proxy
[
https://issues.apache.org/jira/browse/IGNITE-7330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942798#comment-16942798
]
Sergey Chugunov commented on IGNITE-7330:
-
[~mmuzaf],
This issue is very old, is it still reproducible at all? If it's not all we
need to do is just to close the issue.
Anyway I've never seen about problems like this on user list so moving it to
the next release is also OK I think.
> When client connects during cluster activation process it hangs on obtaining
> cache proxy
>
>
> Key: IGNITE-7330
> URL: https://issues.apache.org/jira/browse/IGNITE-7330
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Critical
> Labels: IEP-4, Phase-2
> Fix For: 2.8
>
>
> The test below reproduces the issue:
> {noformat}
> public void testClientJoinWhenActivationInProgress() throws Exception {
> Ignite srv = startGrids(5);
> srv.active(true);
> srv.createCaches(Arrays.asList(cacheConfigurations1()));
> Map cacheData = new LinkedHashMap<>();
> for (int i = 1; i <= 100; i++) {
> for (CacheConfiguration ccfg : cacheConfigurations1()) {
> srv.cache(ccfg.getName()).put(-i, i);
> cacheData.put(-i, i);
> }
> }
> stopAllGrids();
> srv = startGrids(5);
> final CountDownLatch clientStartLatch = new CountDownLatch(1);
> IgniteInternalFuture clStartFut = GridTestUtils.runAsync(new
> Runnable() {
> @Override public void run() {
> try {
> clientStartLatch.await();
> Thread.sleep(10);
> client = true;
> Ignite cl = startGrid("client0");
> IgniteCache atomicCache =
> cl.cache(CACHE_NAME_PREFIX + '0');
> IgniteCache txCache =
> cl.cache(CACHE_NAME_PREFIX + '1');
> assertEquals(100, atomicCache.size());
> assertEquals(100, txCache.size());
> }
> catch (Exception e) {
> log.error("Error occurred", e);
> }
> }
> }, "client-starter-thread");
> clientStartLatch.countDown();
> srv.active(true);
> clStartFut.get();
> }
> {noformat}
> Expected behavior: test finishes successfully.
> Actual behavior: test hangs on waiting for client start future to complete
> while "client-started-thread" will be hanging on obtaining a reference to the
> first cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-5764) web console: delete sql command doesn't work if max pages is not equal 'unlimited'
[ https://issues.apache.org/jira/browse/IGNITE-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-5764. -- Resolution: Cannot Reproduce > web console: delete sql command doesn't work if max pages is not equal > 'unlimited' > -- > > Key: IGNITE-5764 > URL: https://issues.apache.org/jira/browse/IGNITE-5764 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: screenshot-1.png > > > Current implementation works only with 'select' command > !screenshot-1.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-5764) web console: delete sql command doesn't work if max pages is not equal 'unlimited'
[ https://issues.apache.org/jira/browse/IGNITE-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-5764. > web console: delete sql command doesn't work if max pages is not equal > 'unlimited' > -- > > Key: IGNITE-5764 > URL: https://issues.apache.org/jira/browse/IGNITE-5764 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: screenshot-1.png > > > Current implementation works only with 'select' command > !screenshot-1.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-5815) Web Console: Improve Zero Configuration Politics
[ https://issues.apache.org/jira/browse/IGNITE-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-5815. > Web Console: Improve Zero Configuration Politics > > > Key: IGNITE-5815 > URL: https://issues.apache.org/jira/browse/IGNITE-5815 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > > If the user enters a value in the field and it matches the default value, > then we generate a string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-5815) Web Console: Improve Zero Configuration Politics
[ https://issues.apache.org/jira/browse/IGNITE-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-5815. -- Resolution: Won't Fix This will not bring any significant benefits. > Web Console: Improve Zero Configuration Politics > > > Key: IGNITE-5815 > URL: https://issues.apache.org/jira/browse/IGNITE-5815 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > > If the user enters a value in the field and it matches the default value, > then we generate a string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-5914) Web console: improve importing model from DB
[ https://issues.apache.org/jira/browse/IGNITE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-5914. -- Resolution: Won't Fix Not a bug. > Web console: improve importing model from DB > > > Key: IGNITE-5914 > URL: https://issues.apache.org/jira/browse/IGNITE-5914 > Project: Ignite > Issue Type: Wish >Affects Versions: 2.1 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Minor > > I set mode = Replicated, but after import cache has Partitioned mode -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-5914) Web console: improve importing model from DB
[ https://issues.apache.org/jira/browse/IGNITE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-5914. > Web console: improve importing model from DB > > > Key: IGNITE-5914 > URL: https://issues.apache.org/jira/browse/IGNITE-5914 > Project: Ignite > Issue Type: Wish >Affects Versions: 2.1 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Minor > > I set mode = Replicated, but after import cache has Partitioned mode -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-6490) Optimize log search speed
[ https://issues.apache.org/jira/browse/IGNITE-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-6490. Turned out that current implementaion is not so easy to improve. > Optimize log search speed > - > > Key: IGNITE-6490 > URL: https://issues.apache.org/jira/browse/IGNITE-6490 > Project: Ignite > Issue Type: Improvement > Components: wizards >Affects Versions: 2.1 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > I see in VisorLogSearchJob code like this: `if > (s.toLowerCase().contains(searchStr))` and this is very non effective. This > can be reworked to `regionMatches` and this job should be profiled and may be > some other optimizations can be implemented. > See similar issue on SO: > https://codereview.stackexchange.com/questions/44021/fast-way-of-searching-for-a-string-in-a-text-file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IGNITE-6490) Optimize log search speed
[ https://issues.apache.org/jira/browse/IGNITE-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reopened IGNITE-6490: -- > Optimize log search speed > - > > Key: IGNITE-6490 > URL: https://issues.apache.org/jira/browse/IGNITE-6490 > Project: Ignite > Issue Type: Improvement > Components: wizards >Affects Versions: 2.1 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > I see in VisorLogSearchJob code like this: `if > (s.toLowerCase().contains(searchStr))` and this is very non effective. This > can be reworked to `regionMatches` and this job should be profiled and may be > some other optimizations can be implemented. > See similar issue on SO: > https://codereview.stackexchange.com/questions/44021/fast-way-of-searching-for-a-string-in-a-text-file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-6490) Optimize log search speed
[ https://issues.apache.org/jira/browse/IGNITE-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-6490. -- Resolution: Won't Fix > Optimize log search speed > - > > Key: IGNITE-6490 > URL: https://issues.apache.org/jira/browse/IGNITE-6490 > Project: Ignite > Issue Type: Improvement > Components: wizards >Affects Versions: 2.1 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > I see in VisorLogSearchJob code like this: `if > (s.toLowerCase().contains(searchStr))` and this is very non effective. This > can be reworked to `regionMatches` and this job should be profiled and may be > some other optimizations can be implemented. > See similar issue on SO: > https://codereview.stackexchange.com/questions/44021/fast-way-of-searching-for-a-string-in-a-text-file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-6543) Web agent: improve error messages in case of connection to cluster failed
[ https://issues.apache.org/jira/browse/IGNITE-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-6543. > Web agent: improve error messages in case of connection to cluster failed > - > > Key: IGNITE-6543 > URL: https://issues.apache.org/jira/browse/IGNITE-6543 > Project: Ignite > Issue Type: Improvement > Components: wizards >Affects Versions: 2.1 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > Right now it is non informative text like this: "[2017-10-02 > 17:47:40,357][WARN ][pool-1-thread-1][ClusterListener] Failed connect to > cluster." > We should print more information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8688) Pending tree is initialized outside of checkpoint lock
[
https://issues.apache.org/jira/browse/IGNITE-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942770#comment-16942770
]
Maxim Muzafarov commented on IGNITE-8688:
-
[~jokser]
Since IGNITE-8682 has been fixed, can we recheck current issue and close?
> Pending tree is initialized outside of checkpoint lock
> --
>
> Key: IGNITE-8688
> URL: https://issues.apache.org/jira/browse/IGNITE-8688
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.8
>
>
> This may lead to possible page corruption.
> {noformat}
> handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError]]
> [00:11:56]W: [org.gridgain:gridgain-compatibility]
> java.lang.AssertionError
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-6543) Web agent: improve error messages in case of connection to cluster failed
[ https://issues.apache.org/jira/browse/IGNITE-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-6543. -- Resolution: Won't Fix > Web agent: improve error messages in case of connection to cluster failed > - > > Key: IGNITE-6543 > URL: https://issues.apache.org/jira/browse/IGNITE-6543 > Project: Ignite > Issue Type: Improvement > Components: wizards >Affects Versions: 2.1 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > Right now it is non informative text like this: "[2017-10-02 > 17:47:40,357][WARN ][pool-1-thread-1][ClusterListener] Failed connect to > cluster." > We should print more information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7595) Find and switch to alternate documentation engine
[ https://issues.apache.org/jira/browse/IGNITE-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942768#comment-16942768 ] Maxim Muzafarov commented on IGNITE-7595: - [~dmagda] , Folks, can we move this issue to the next release? > Find and switch to alternate documentation engine > - > > Key: IGNITE-7595 > URL: https://issues.apache.org/jira/browse/IGNITE-7595 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Critical > Fix For: 2.8 > > Attachments: Docusaurus-GitBook comparison.docx, > readme-markdown-mapping.xlsx > > > Current readme.io documentation has many drawbacks that make the life of > Ignite technical writers hard. Some of the problems are: > * Each "version" is just a copy of the previous one. When fixing something, > you have to update > all the versions. > * No good way to review changes. > * "Propose edit" functionality is a not suitable for review. You can only > accept or reject an > edit, no way to communicate with a contributor, etc > * There is no way to prevent Google from indexing old documentation > versions. Thus, it's common to come across old doc version in a google > search. > We might consider GitHub based documentation or another approach. The > discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7595) Find and switch to alternate documentation engine
[ https://issues.apache.org/jira/browse/IGNITE-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7595: Ignite Flags: Docs Required > Find and switch to alternate documentation engine > - > > Key: IGNITE-7595 > URL: https://issues.apache.org/jira/browse/IGNITE-7595 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Critical > Fix For: 2.8 > > Attachments: Docusaurus-GitBook comparison.docx, > readme-markdown-mapping.xlsx > > > Current readme.io documentation has many drawbacks that make the life of > Ignite technical writers hard. Some of the problems are: > * Each "version" is just a copy of the previous one. When fixing something, > you have to update > all the versions. > * No good way to review changes. > * "Propose edit" functionality is a not suitable for review. You can only > accept or reject an > edit, no way to communicate with a contributor, etc > * There is no way to prevent Google from indexing old documentation > versions. Thus, it's common to come across old doc version in a google > search. > We might consider GitHub based documentation or another approach. The > discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7472) Exchange initiated by custom disco events could hang in case of coordinator leave
[
https://issues.apache.org/jira/browse/IGNITE-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7472:
Fix Version/s: (was: 2.8)
> Exchange initiated by custom disco events could hang in case of coordinator
> leave
> -
>
> Key: IGNITE-7472
> URL: https://issues.apache.org/jira/browse/IGNITE-7472
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
>
> Reproducer: {{WalModeChangeAdvancedSelfTest.testServerRestartCoordinator}}
> WAL mode change operation initiates an exchange through custom discovery
> event. The test does the following:
> 1) Initiate constant flow of such events from one node
> 2) Constantly stops current coordinator node and start another one sever node
> Debug shows the following:
> 1) Remaining client nodes is on exchange X, waiting for new coordinator to
> send affinity message
> 2) New coordinator is on exchange [X+1], waiting for client to send partition
> message
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7330) When client connects during cluster activation process it hangs on obtaining cache proxy
[
https://issues.apache.org/jira/browse/IGNITE-7330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942767#comment-16942767
]
Maxim Muzafarov commented on IGNITE-7330:
-
[~sergey-chugunov]
Hello, can we move this issue to the next release?
> When client connects during cluster activation process it hangs on obtaining
> cache proxy
>
>
> Key: IGNITE-7330
> URL: https://issues.apache.org/jira/browse/IGNITE-7330
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Critical
> Labels: IEP-4, Phase-2
> Fix For: 2.8
>
>
> The test below reproduces the issue:
> {noformat}
> public void testClientJoinWhenActivationInProgress() throws Exception {
> Ignite srv = startGrids(5);
> srv.active(true);
> srv.createCaches(Arrays.asList(cacheConfigurations1()));
> Map cacheData = new LinkedHashMap<>();
> for (int i = 1; i <= 100; i++) {
> for (CacheConfiguration ccfg : cacheConfigurations1()) {
> srv.cache(ccfg.getName()).put(-i, i);
> cacheData.put(-i, i);
> }
> }
> stopAllGrids();
> srv = startGrids(5);
> final CountDownLatch clientStartLatch = new CountDownLatch(1);
> IgniteInternalFuture clStartFut = GridTestUtils.runAsync(new
> Runnable() {
> @Override public void run() {
> try {
> clientStartLatch.await();
> Thread.sleep(10);
> client = true;
> Ignite cl = startGrid("client0");
> IgniteCache atomicCache =
> cl.cache(CACHE_NAME_PREFIX + '0');
> IgniteCache txCache =
> cl.cache(CACHE_NAME_PREFIX + '1');
> assertEquals(100, atomicCache.size());
> assertEquals(100, txCache.size());
> }
> catch (Exception e) {
> log.error("Error occurred", e);
> }
> }
> }, "client-starter-thread");
> clientStartLatch.countDown();
> srv.active(true);
> clStartFut.get();
> }
> {noformat}
> Expected behavior: test finishes successfully.
> Actual behavior: test hangs on waiting for client start future to complete
> while "client-started-thread" will be hanging on obtaining a reference to the
> first cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-7371) MVCC: Repeatable read TX should cache entries locally.
[ https://issues.apache.org/jira/browse/IGNITE-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7371: Fix Version/s: (was: 2.8) > MVCC: Repeatable read TX should cache entries locally. > -- > > Key: IGNITE-7371 > URL: https://issues.apache.org/jira/browse/IGNITE-7371 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Critical > Labels: mvcc_performance > > Repeatable read isolation implies that each GET operation whithin tx gets a > last commited version of entry *at the time the tx was started*. > A value that just has been got, should be cached locally in TX to avoid > remote call on repeatable get(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7290) Log when partition is moved to a LOST state
[ https://issues.apache.org/jira/browse/IGNITE-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942765#comment-16942765 ] Maxim Muzafarov commented on IGNITE-7290: - [~agoncharuk] I've moved the issue to the next release. Also, I've changed the priority to `minor` and mark the issue with a `newbie` label. If we expect this issue to be included in 2.8 let's do it. > Log when partition is moved to a LOST state > --- > > Key: IGNITE-7290 > URL: https://issues.apache.org/jira/browse/IGNITE-7290 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Minor > Labels: newbie > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7290) Log when partition is moved to a LOST state
[ https://issues.apache.org/jira/browse/IGNITE-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7290: Labels: newbie (was: ) > Log when partition is moved to a LOST state > --- > > Key: IGNITE-7290 > URL: https://issues.apache.org/jira/browse/IGNITE-7290 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Minor > Labels: newbie > -- This message was sent by Atlassian Jira (v8.3.4#803005)
