[jira] [Assigned] (IGNITE-10847) Web console: failed to download the mongodb on Ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov reassigned IGNITE-10847:
---
Assignee: Vasiliy Sisko (was: Andrey Novikov)
Fixed mongo connection in test. Please restore broken tests
> Web console: failed to download the mongodb on Ubuntu 18.04
> ---
>
> Key: IGNITE-10847
> URL: https://issues.apache.org/jira/browse/IGNITE-10847
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
>
> I tried to run 'web console direct install' and faced with an error
> downloading of MongoDB due to there is no corresponding version for that OS.
> {code}
> name: 'StatusCodeError',
> statusCode: 403,
> message: '403 - " encoding=\\"UTF-8\\"?>\\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g="',
> error: ' encoding="UTF-8"?>\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g=',
> options:
>{ uri:
> 'https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-ubuntu1804-3.4.7.tgz.md5',
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap ion exchange history
[
https://issues.apache.org/jira/browse/IGNITE-11767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821418#comment-16821418
]
Ignite TC Bot commented on IGNITE-11767:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3642411]]
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3642426]]
{color:#d04437}Cache 6{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3642418]]
* IgniteCacheTestSuite6:
CacheExchangeMergeTest.testFailExchangeCoordinatorChange_NoMerge_2 - 0,0% fails
in last 135 master runs.
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3642424]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3641904buildTypeId=IgniteTests24Java8_RunAll]
> GridDhtPartitionsFullMessage retains huge maps on heap ion exchange history
> ---
>
> Key: IGNITE-11767
> URL: https://issues.apache.org/jira/browse/IGNITE-11767
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ExchangeHistory keeps a FinishState for every topology version.
> FinishState contains msg, which contains at least two huge maps:
> partCntrs2 and partsSizesBytes.
> We should probably strip msg, removing those two data structures before
> putting msg in exchFuts linked list to be stowed away.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821382#comment-16821382
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3640831]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3640853]]
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3640789]]
{color:#d04437}Platform .NET{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=3640852]]
* exe: CacheParityTest.TestCache - 0,0% fails in last 209 master runs.
{color:#d04437}Cache 5{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=3640834]]
* IgniteCacheTestSuite5:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodesWithPersistence[ATOMIC]
- 0,0% fails in last 136 master runs.
{color:#d04437}PDS 4{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=3640851]]
* IgnitePdsTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testDestroySpecificCachesInDifferentCacheGroupsFirstGroup
- 0,0% fails in last 140 master runs.
* IgnitePdsTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testDestroySpecificCacheAndCacheGroupSecondGroup
- 0,0% fails in last 140 master runs.
{color:#d04437}Activate / Deactivate Cluster{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3640771]]
* IgniteStandByClusterSuite:
IgniteClusterActivateDeactivateTest.testActivateFailover3 - 0,0% fails in last
140 master runs.
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3640817]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3640882buildTypeId=IgniteTests24Java8_RunAll]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11754) Memory leak on the GridCacheTxFinishSync#threadMap
[
https://issues.apache.org/jira/browse/IGNITE-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821371#comment-16821371
]
Alexey Goncharuk commented on IGNITE-11754:
---
Merged to master.
> Memory leak on the GridCacheTxFinishSync#threadMap
> --
>
> Key: IGNITE-11754
> URL: https://issues.apache.org/jira/browse/IGNITE-11754
> Project: Ignite
> Issue Type: Bug
> Components: general, mvcc
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{GridCacheTxFinishSync#threadMap}} is not cleared when tx thread is
> terminated.
> So, memory leak happens when transactions are executed inside new
> start/stopped threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11754) Memory leak on the GridCacheTxFinishSync#threadMap
[
https://issues.apache.org/jira/browse/IGNITE-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821369#comment-16821369
]
Alexey Goncharuk commented on IGNITE-11754:
---
Blockers exist in master as well.
> Memory leak on the GridCacheTxFinishSync#threadMap
> --
>
> Key: IGNITE-11754
> URL: https://issues.apache.org/jira/browse/IGNITE-11754
> Project: Ignite
> Issue Type: Bug
> Components: general, mvcc
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{GridCacheTxFinishSync#threadMap}} is not cleared when tx thread is
> terminated.
> So, memory leak happens when transactions are executed inside new
> start/stopped threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11754) Memory leak on the GridCacheTxFinishSync#threadMap
[
https://issues.apache.org/jira/browse/IGNITE-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821367#comment-16821367
]
Ignite TC Bot commented on IGNITE-11754:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3640922]]
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3640908]]
* JdbcThinErrorsSelfTest.testInvalidDoubleFormat (last started)
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3640936]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3641001buildTypeId=IgniteTests24Java8_RunAll]
> Memory leak on the GridCacheTxFinishSync#threadMap
> --
>
> Key: IGNITE-11754
> URL: https://issues.apache.org/jira/browse/IGNITE-11754
> Project: Ignite
> Issue Type: Bug
> Components: general, mvcc
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{GridCacheTxFinishSync#threadMap}} is not cleared when tx thread is
> terminated.
> So, memory leak happens when transactions are executed inside new
> start/stopped threads.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11489) SQL: merge IO message listener for GridTopic.TOPIC_QUERY into single listener
[ https://issues.apache.org/jira/browse/IGNITE-11489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11489: -- Summary: SQL: merge IO message listener for GridTopic.TOPIC_QUERY into single listener (was: merge IO message listener for GridTopic.TOPIC_QUERY into single listener) > SQL: merge IO message listener for GridTopic.TOPIC_QUERY into single listener > - > > Key: IGNITE-11489 > URL: https://issues.apache.org/jira/browse/IGNITE-11489 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now we have few IO listeners for GridTopic.TOPIC_QUERY. It lead to > spread of logic and we can't check that no any not expected messages received. > Need to merge it to single listeners or have different topics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11758) Python thin: a lot of documentation files without license header
[ https://issues.apache.org/jira/browse/IGNITE-11758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821328#comment-16821328 ] Denis Magda commented on IGNITE-11758: -- [~isapego], if these docs are similar to javadoc then should we care about the license? I've checked our binaries distributions and generated javadocs don't have the license header. Sorry if I'm missing anything. > Python thin: a lot of documentation files without license header > > > Key: IGNITE-11758 > URL: https://issues.apache.org/jira/browse/IGNITE-11758 > Project: Ignite > Issue Type: Bug > Components: documentation, thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Dmitry Melnichuk >Priority: Major > Fix For: 2.8 > > > There are a lot of .rst documentation files in modules/platforms/python/docs/ > that does not contain license header. We need either delete them if they are > auto generated or add headers to them if they are not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10832) [TC Bot] Auto-trigger check win agents availability before triggering a build
[ https://issues.apache.org/jira/browse/IGNITE-10832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10832. - Resolution: Won't Fix > [TC Bot] Auto-trigger check win agents availability before triggering a build > - > > Key: IGNITE-10832 > URL: https://issues.apache.org/jira/browse/IGNITE-10832 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > Currently, Win Agents may be a bottle-neck in TC throughput. > So it is reasonable to check constraint availability, but not only overall > pool of agents -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10620) [TC Bot] Implement Tracked Branches processor and IssueDetector unit tests
[ https://issues.apache.org/jira/browse/IGNITE-10620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10620. - Resolution: Incomplete > [TC Bot] Implement Tracked Branches processor and IssueDetector unit tests > -- > > Key: IGNITE-10620 > URL: https://issues.apache.org/jira/browse/IGNITE-10620 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Minor > > Implement actual tests for tracked branches processing and issue detectors. > Skeletons: > org.apache.ignite.ci.tcbot.issue.IssueDetectorTest#testDetector > org.apache.ignite.ci.tcbot.chain.TrackedBranchProcessorTest#testTrackedBranchChainsProcessor > The actual challenge is refactoring of configuration to use not singletons, > but some injected interfaces with mock-able alternatives, refactor scheduler, > and any other refactorings needed to cover issue detection by test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11751) Javadoc broken
[
https://issues.apache.org/jira/browse/IGNITE-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reassigned IGNITE-11751:
---
Assignee: Peter Ivanov
> Javadoc broken
> --
>
> Key: IGNITE-11751
> URL: https://issues.apache.org/jira/browse/IGNITE-11751
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.8
>
> Attachments: javadoc.patch
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:aggregate (core-javadoc)
> on project apache-ignite: An error has occurred in Javadoc report generation:
> [ERROR] Exit code: 1 -
> ignite/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/serializer/package-info.java:21:
> warning: a package-info.java file has already been seen for package
> org.apache.ignite.cache.store.cassandra.serializer
> [ERROR] package org.apache.ignite.cache.store.cassandra.serializer;
> [ERROR]^
> [ERROR] javadoc: warning - Multiple sources of package comments found for
> package "org.apache.ignite.cache.store.cassandra.serializer"
> [ERROR] javadoc: error - Error - Exception java.lang.ClassNotFoundException
> thrown while trying to register Taglet
> org.apache.ignite.tools.javadoc.IgniteLinkTaglet...
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java:828:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java:828:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStore.java:71:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStore.java:71:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/transactions/Transaction.java:120:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/transactions/Transaction.java:120:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/checkpoint/CheckpointSpi.java:60:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/checkpoint/CheckpointSpi.java:60:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:233:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:233:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/deployment/DeploymentSpi.java:61:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/deployment/DeploymentSpi.java:61:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToSet.java:154:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToSet.java:154:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToValue.java:152:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToValue.java:152:
>
[jira] [Updated] (IGNITE-11784) Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
[
https://issues.apache.org/jira/browse/IGNITE-11784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-11784:
Description: {{TcpDiscoveryDuplicateIdMessage}} and
{{TcpDiscoveryStatusCheckMessage}} have TcpDiscoveryNode field.
TcpDiscoveryNode could be huge object due to node attributes. We could sent
only nodeId and get TcpDiscoveryNode from DiscoCache on target node. (was:
{{TcpDiscoveryDuplicateIdMessage}} and {{TcpDiscoveryStatusCheckMessage}} have
TcpDiscoveryNode filed. TcpDiscoveryNode could be huge object due to node
attributes. We could sent only nodeId and get TcpDiscoveryNode from DiscoCache
on target node. )
> Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
> --
>
> Key: IGNITE-11784
> URL: https://issues.apache.org/jira/browse/IGNITE-11784
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> {{TcpDiscoveryDuplicateIdMessage}} and {{TcpDiscoveryStatusCheckMessage}}
> have TcpDiscoveryNode field. TcpDiscoveryNode could be huge object due to
> node attributes. We could sent only nodeId and get TcpDiscoveryNode from
> DiscoCache on target node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-11198) [TC Bot] Apache Ignite TeamCity Bot unable to issue visa for special symbol '|'
[ https://issues.apache.org/jira/browse/IGNITE-11198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-11198. - Resolution: Duplicate > [TC Bot] Apache Ignite TeamCity Bot unable to issue visa for special symbol > '|' > --- > > Key: IGNITE-11198 > URL: https://issues.apache.org/jira/browse/IGNITE-11198 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > Presence of special symbol '|' in suite name, which failure during TC run, > makes the Bot to be unable to left JIRA comment, JIRA REST failed with escape. > Replace '|' to, for example, '_' symbol in suites name for JIRA comment > generation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11784) Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
Sergey Antonov created IGNITE-11784:
---
Summary: Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
Key: IGNITE-11784
URL: https://issues.apache.org/jira/browse/IGNITE-11784
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Fix For: 2.8
{{TcpDiscoveryDuplicateIdMessage}} and {{TcpDiscoveryStatusCheckMessage}} have
TcpDiscoveryNode filed. TcpDiscoveryNode could be huge object due to node
attributes. We could sent only nodeId and get TcpDiscoveryNode from DiscoCache
on target node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11666) C++ : remove macro usages in the examples
[
https://issues.apache.org/jira/browse/IGNITE-11666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821264#comment-16821264
]
Igor Sapego commented on IGNITE-11666:
--
[~pkouznet] There is no documentation yet. Here is the ticket: IGNITE-11768
> C++ : remove macro usages in the examples
> -
>
> Key: IGNITE-11666
> URL: https://issues.apache.org/jira/browse/IGNITE-11666
> Project: Ignite
> Issue Type: Improvement
> Components: examples, platforms
>Reporter: Pavel Kuznetsov
>Assignee: Igor Sapego
>Priority: Major
> Labels: c++, examples
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently c++ examples are using internal macros. For example to specify how
> to serialize/deserialize user's c++ structs.
> {code:c++}
> IGNITE_BINARY_TYPE_START(ignite::examples::Person)
> typedef ignite::examples::Person Person;
> IGNITE_BINARY_GET_TYPE_ID_AS_HASH(Person)
> IGNITE_BINARY_GET_TYPE_NAME_AS_IS(Person)
> IGNITE_BINARY_GET_FIELD_ID_AS_HASH
> IGNITE_BINARY_IS_NULL_FALSE(Person)
> IGNITE_BINARY_GET_NULL_DEFAULT_CTOR(Person)
> //...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11783) Open file limit for deb distribution
Alexander Belyak created IGNITE-11783:
-
Summary: Open file limit for deb distribution
Key: IGNITE-11783
URL: https://issues.apache.org/jira/browse/IGNITE-11783
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.7
Environment: ubuntu-16.04
Reporter: Alexander Belyak
Step to reproduce:
1) Install ignite from deb package on ubuntu 16.04
2) Start with persistence
3) Create 5 caches (or one with 4000+ partitions)
Error text:
{noformat}
[18:29:44,369][INFO][exchange-worker-#43][GridCacheDatabaseSharedManager]
Restoring partition state for local groups [cntPartStateWal=0,
lastCheckpointId=bd24ff23-da6f-46e5-bafd-b643db3870d4]
[18:29:51,864][SEVERE][exchange-worker-#43][] Critical system error detected.
Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureH
andler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.StorageException: Failed to initialize
partition file: /usr/s
hare/apache-ignite/work/db/node00-f49af718-48da-4186-b664-62aca736bdc9/cache-SQL_PUBLIC_VERTEX_TBL/part-913.bin]]
class org.apache.ignite.internal.processors.cache.persistence.StorageException:
Failed to initialize partition file:
/usr/share/apache-ignite/work/db/node00-f49af718-48da-4186-b664-62aca736bdc9/cache-SQL_PUBLIC_
VERTEX_TBL/part-913.bin
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.init(FilePageStore.java:444)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.ensure(FilePageStore.java:650)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.ensure(FilePageStoreManager.java:712)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2472)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2419)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1628)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1302)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1453)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:806)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.nio.file.FileSystemException:
/usr/share/apache-ignite/work/db/node00-f49af718-48da-4186-b664-62aca736bdc9/cache-SQL_PUBLIC_VERTEX_TBL/part-913.bin:
Too many open files
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:91)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.newAsynchronousFileChannel(UnixFileSystemProvider.java:196)
at
java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:248)
at
java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:301)
at
org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.(AsyncFileIO.java:57)
at
org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:53)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.init(FilePageStore.java:416)
... 12 more
{noformat}
It happen because systemd service description
(/etc/systemd/system/apache-ignite@.service) didn't contain
{noformat}
LimitNOFILE=50
(possible with) LimitNPROC=50
{noformat}
see: https://fredrikaverpil.github.io/2016/04/27/systemd-and-resource-limits/
Possible, installation script should also add:
* "fs.file-max = 2097152" to "/etc/sysctl.conf"
* into /etc/security/limits.conf:
{noformat}
* hardnofile 50
* softnofile 50
root hardnofile 50
root
[jira] [Commented] (IGNITE-11678) Forbidding joining persistence node to in-memory cluster
[ https://issues.apache.org/jira/browse/IGNITE-11678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821250#comment-16821250 ] Dmitriy Govorukhin commented on IGNITE-11678: - [~akalashnikov] LGTM, thanks, merged to master. > Forbidding joining persistence node to in-memory cluster > > > Key: IGNITE-11678 > URL: https://issues.apache.org/jira/browse/IGNITE-11678 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Forbidding joining persistence node to in-memory cluster when baseline > auto-adjust enabled and timeout equal to 0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11678) Forbidding joining persistence node to in-memory cluster
[ https://issues.apache.org/jira/browse/IGNITE-11678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11678: Labels: IEP-4 Phase-2 (was: ) > Forbidding joining persistence node to in-memory cluster > > > Key: IGNITE-11678 > URL: https://issues.apache.org/jira/browse/IGNITE-11678 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Forbidding joining persistence node to in-memory cluster when baseline > auto-adjust enabled and timeout equal to 0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11666) C++ : remove macro usages in the examples
[
https://issues.apache.org/jira/browse/IGNITE-11666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821248#comment-16821248
]
Pavel Kuznetsov commented on IGNITE-11666:
--
[~isapego], In functional point, changes are ok.
Styling :
I see you removed redundant "ignite" namespace specification. Though I
personally prefer to use full namespaces (or typedefs), would you please make
other places "ignite::examples::" unified. Also
{{examples/include/ignite/examples/organization.h}} uses full namespace path as
well.
Where we can find doc, that tells us which functions we must to implement to
define binary format for the new struct?
Since it is an example I would leave comment or reference to the doc. Maybe
binary object example? Other example that explains BinaryType<> convention in
details? (Nice-to-have)
> C++ : remove macro usages in the examples
> -
>
> Key: IGNITE-11666
> URL: https://issues.apache.org/jira/browse/IGNITE-11666
> Project: Ignite
> Issue Type: Improvement
> Components: examples, platforms
>Reporter: Pavel Kuznetsov
>Assignee: Igor Sapego
>Priority: Major
> Labels: c++, examples
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently c++ examples are using internal macros. For example to specify how
> to serialize/deserialize user's c++ structs.
> {code:c++}
> IGNITE_BINARY_TYPE_START(ignite::examples::Person)
> typedef ignite::examples::Person Person;
> IGNITE_BINARY_GET_TYPE_ID_AS_HASH(Person)
> IGNITE_BINARY_GET_TYPE_NAME_AS_IS(Person)
> IGNITE_BINARY_GET_FIELD_ID_AS_HASH
> IGNITE_BINARY_IS_NULL_FALSE(Person)
> IGNITE_BINARY_GET_NULL_DEFAULT_CTOR(Person)
> //...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11678) Forbidding joining persistence node to in-memory cluster
[ https://issues.apache.org/jira/browse/IGNITE-11678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11678: Fix Version/s: 2.8 > Forbidding joining persistence node to in-memory cluster > > > Key: IGNITE-11678 > URL: https://issues.apache.org/jira/browse/IGNITE-11678 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Forbidding joining persistence node to in-memory cluster when baseline > auto-adjust enabled and timeout equal to 0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11188) Optimize baseline autoadjustment for in-memory clusters with zero timeout
[ https://issues.apache.org/jira/browse/IGNITE-11188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821244#comment-16821244 ] Dmitriy Govorukhin commented on IGNITE-11188: - [~ibessonov] Thanks for the contribution, merged to master. > Optimize baseline autoadjustment for in-memory clusters with zero timeout > - > > Key: IGNITE-11188 > URL: https://issues.apache.org/jira/browse/IGNITE-11188 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > > In current implementation (IGNITE-8571) zero-timeout case initiates two > partition map exchanges on join/leave node events. This could be improved so > that baseline is updated at the same time as join/leave event processing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11782) WAL iterator for collect per-pageId info
Anton Kalashnikov created IGNITE-11782: -- Summary: WAL iterator for collect per-pageId info Key: IGNITE-11782 URL: https://issues.apache.org/jira/browse/IGNITE-11782 Project: Ignite Issue Type: Improvement Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Implement WAL iterator for collect per-pageId info (page is root) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11736) Make the TeamCity console quiet.
[ https://issues.apache.org/jira/browse/IGNITE-11736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11736: -- Ignite Flags: (was: Docs Required) > Make the TeamCity console quiet. > > > Key: IGNITE-11736 > URL: https://issues.apache.org/jira/browse/IGNITE-11736 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > As a result of this discussion: > [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] > > # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max > size of the file isn't limited. 2. Run all will contain a parameter for > switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity > environment. > TC fixes: > Add a checkbox into the general run window. *By default* the checkbox *is > active*. If the checkbox is *active*, the TeamCity adds next params for java > run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* > otherwise *empty params*. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11736) Make the TeamCity console quiet.
[ https://issues.apache.org/jira/browse/IGNITE-11736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11736: -- Fix Version/s: 2.8 > Make the TeamCity console quiet. > > > Key: IGNITE-11736 > URL: https://issues.apache.org/jira/browse/IGNITE-11736 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > As a result of this discussion: > [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] > > # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max > size of the file isn't limited. 2. Run all will contain a parameter for > switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity > environment. > TC fixes: > Add a checkbox into the general run window. *By default* the checkbox *is > active*. If the checkbox is *active*, the TeamCity adds next params for java > run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* > otherwise *empty params*. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11736) Make the TeamCity console quiet.
[ https://issues.apache.org/jira/browse/IGNITE-11736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821243#comment-16821243 ] Alexey Goncharuk commented on IGNITE-11736: --- [~mstepachev], merged the config to master. [~vveider], can you add the described checkbox to TC? > Make the TeamCity console quiet. > > > Key: IGNITE-11736 > URL: https://issues.apache.org/jira/browse/IGNITE-11736 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > As a result of this discussion: > [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] > > # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max > size of the file isn't limited. 2. Run all will contain a parameter for > switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity > environment. > TC fixes: > Add a checkbox into the general run window. *By default* the checkbox *is > active*. If the checkbox is *active*, the TeamCity adds next params for java > run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* > otherwise *empty params*. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11743) Stopping caches concurrently with node join may lead to crash of the node
[
https://issues.apache.org/jira/browse/IGNITE-11743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821237#comment-16821237
]
Pavel Kovalenko commented on IGNITE-11743:
--
Cache2 failure is related to https://issues.apache.org/jira/browse/IGNITE-11762
JDBC Driver failure is already fixed there
https://issues.apache.org/jira/browse/IGNITE-11773
Javadocs are already broken in master.
> Stopping caches concurrently with node join may lead to crash of the node
> -
>
> Key: IGNITE-11743
> URL: https://issues.apache.org/jira/browse/IGNITE-11743
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Chugunov
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
> Attachments: IgnitePdsNodeRestartCacheCreateTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When an existing cache is stopped (e.g. via call Ignite#destroyCache(String
> name)) this action is distributed across cluster by discovery mechanism (and
> is processed from *disco-notifier-worker* thread).
> At the same time joining node prepares to start caches from *exchange-worker*
> thread.
> If a cache stop request arrives to new node right in the middle of cache
> start prepare, it may lead to exception in FilePageStoreManager like one
> below and node crash.
> Test reproducing the issue is attached.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to get page store for
> the given cache ID (cache has not been started): -1422502786
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.getStore(FilePageStoreManager.java:1132)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:482)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:469)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:854)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:681)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.getOrAllocateCacheMetas(GridCacheOffheapManager.java:869)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.initDataStructures(GridCacheOffheapManager.java:128)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.start(IgniteCacheOffheapManagerImpl.java:193)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.start(CacheGroupContext.java:1043)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:2829)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.getOrCreateCacheGroupContext(GridCacheProcessor.java:2557)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:2387)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$null$6a5b31b9$1(GridCacheProcessor.java:2209)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$5(GridCacheProcessor.java:2130)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$926b6886$1(GridCacheProcessor.java:2206)
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:10874)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11287) JDBC Thin: best effort affinity
[ https://issues.apache.org/jira/browse/IGNITE-11287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-11287: Resolution: Fixed Assignee: Alexander Lapin Merged to master. > JDBC Thin: best effort affinity > --- > > Key: IGNITE-11287 > URL: https://issues.apache.org/jira/browse/IGNITE-11287 > Project: Ignite > Issue Type: New Feature > Components: jdbc >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23, iep-24 > Fix For: 2.8 > > > It's an umbrella ticket for implementing > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > within the scope of JDBC Thin driver. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11743) Stopping caches concurrently with node join may lead to crash of the node
[
https://issues.apache.org/jira/browse/IGNITE-11743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821231#comment-16821231
]
Ignite TC Bot commented on IGNITE-11743:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3641067]]
* IgniteClientCacheStartFailoverTest.testClientStartCloseServersRestart (last
started)
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3641025]]
* JdbcThinErrorsSelfTest.testInvalidDoubleFormat (last started)
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3641053]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3641118buildTypeId=IgniteTests24Java8_RunAll]
> Stopping caches concurrently with node join may lead to crash of the node
> -
>
> Key: IGNITE-11743
> URL: https://issues.apache.org/jira/browse/IGNITE-11743
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Chugunov
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
> Attachments: IgnitePdsNodeRestartCacheCreateTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When an existing cache is stopped (e.g. via call Ignite#destroyCache(String
> name)) this action is distributed across cluster by discovery mechanism (and
> is processed from *disco-notifier-worker* thread).
> At the same time joining node prepares to start caches from *exchange-worker*
> thread.
> If a cache stop request arrives to new node right in the middle of cache
> start prepare, it may lead to exception in FilePageStoreManager like one
> below and node crash.
> Test reproducing the issue is attached.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to get page store for
> the given cache ID (cache has not been started): -1422502786
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.getStore(FilePageStoreManager.java:1132)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:482)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:469)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:854)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:681)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.getOrAllocateCacheMetas(GridCacheOffheapManager.java:869)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.initDataStructures(GridCacheOffheapManager.java:128)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.start(IgniteCacheOffheapManagerImpl.java:193)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.start(CacheGroupContext.java:1043)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:2829)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.getOrCreateCacheGroupContext(GridCacheProcessor.java:2557)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:2387)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$null$6a5b31b9$1(GridCacheProcessor.java:2209)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$5(GridCacheProcessor.java:2130)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$926b6886$1(GridCacheProcessor.java:2206)
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:10874)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11781) Invalid mode while deserializing JTS geometry objects with binary marshaller
Martin Raifer created IGNITE-11781:
--
Summary: Invalid mode while deserializing JTS geometry objects
with binary marshaller
Key: IGNITE-11781
URL: https://issues.apache.org/jira/browse/IGNITE-11781
Project: Ignite
Issue Type: Bug
Components: binary, clients, compute
Affects Versions: 2.7
Environment: Tested on a 64 bit Ubuntu 18.04, with OpenJDK 1.8.0_191,
running Ignite 2.7
Reporter: Martin Raifer
JTS Geometry objects can't be used as return types of compute jobs. Instead,
_null_ is returned. Here's a minimal example showing the bug (and one example
that shows that the bug is sometimes not triggered under slightly different
conditions):
{code:java}
// this prints "null" (wrong – the expected result would be "POINT EMPTY"):
igniteCompute.broadcast(() -> (new
GeometryFactory()).createPoint()).forEach(System.out::println);
// this prints "[POINT EMPTY]" (correct):
igniteCompute.broadcast(() -> Collections.singletonList((new
GeometryFactory()).createPoint())).forEach(System.out::println);
{code}
This is caused by an invalid _BinaryWriteMode_ of _OPTIMIZED_ in
[https://github.com/apache/ignite/blob/ignite-2.7/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryClassDescriptor.java#L852]
which then leads to a null value to be returned a few lines further down:
[https://github.com/apache/ignite/blob/ignite-2.7/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryClassDescriptor.java#L882]
>From what I can see, the _OPTIMIZED_ mode is set in
>[https://github.com/apache/ignite/blob/ignite-2.7/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryClassDescriptor.java#L161]
> where the objects are explicitly tested against the
>_org.locationtech.jts.geom.Geometry_ class. This could be a regression
>introduced in https://issues.apache.org/jira/browse/IGNITE-4259 ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11780) Command handler refactoring
[ https://issues.apache.org/jira/browse/IGNITE-11780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821221#comment-16821221 ] Sergey Antonov commented on IGNITE-11780: - [~EdShangGG] I think this ticket duplicates https://issues.apache.org/jira/browse/IGNITE-11045. > Command handler refactoring > --- > > Key: IGNITE-11780 > URL: https://issues.apache.org/jira/browse/IGNITE-11780 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Priority: Major > > Now it is just a big ball of mud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11780) Command handler refactoring
Eduard Shangareev created IGNITE-11780: -- Summary: Command handler refactoring Key: IGNITE-11780 URL: https://issues.apache.org/jira/browse/IGNITE-11780 Project: Ignite Issue Type: Improvement Reporter: Eduard Shangareev Now it is just a big ball of mud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11730) Discovery Compression check fails when nodes reconnect to cluster
[
https://issues.apache.org/jira/browse/IGNITE-11730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821213#comment-16821213
]
Alexey Goncharuk commented on IGNITE-11730:
---
[~akalashnikov] changes look good to me.
> Discovery Compression check fails when nodes reconnect to cluster
> -
>
> Key: IGNITE-11730
> URL: https://issues.apache.org/jira/browse/IGNITE-11730
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There is a check that Discovery Data Bag compression is supported by all
> nodes.
> Apparently this check does not work when nodes reconnect after server
> restart. When there is at least one client node that does not support this
> feature, clients will still send zipped data that server would not
> understand, leaving to following server error:
> {code}
> [15:46:47,101][SEVERE][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Failed to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> with given class loader: sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:161)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9922)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:290)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalJoiningNodeData(DiscoveryDataPacket.java:169)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2076)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4620)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:4307)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2962)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2729)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7496)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2833)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7427)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.EOFException
> at
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2638)
> at
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3113)
> at
> java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:853)
> at java.io.ObjectInputStream.(ObjectInputStream.java:349)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.(JdkMarshallerObjectInputStream.java:43)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:137)
> ... 16 more
> {code}
> and client nodes will fail with following error:
> {code}
> [15:46:47,175][SEVERE][tcp-client-disco-msg-worker-#4][] Critical system
> error detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.IgniteException: Node with
> BaselineTopology cannot join mixed cluster running in compatibility mode]]
> class org.apache.ignite.IgniteException: Node with BaselineTopology cannot
> join mixed cluster running in compatibility mode
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onGridDataReceived(GridClusterStateProcessor.java:727)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:899)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2083)
> at
>
[jira] [Commented] (IGNITE-11251) SQL: getMoreResults() infinitely reports about update operation on zeroCursor
[
https://issues.apache.org/jira/browse/IGNITE-11251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821212#comment-16821212
]
Alexander Lapin commented on IGNITE-11251:
--
[~rkondakov], thanks a lot, I've changed asserts with junit asserts within
touched test classes.
[~amashenkov], [~isapego] could you please merge given ticket to master?
> SQL: getMoreResults() infinitely reports about update operation on zeroCursor
> -
>
> Key: IGNITE-11251
> URL: https://issues.apache.org/jira/browse/IGNITE-11251
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: jdbc
> Fix For: 2.8
>
>
> If we got sql query that contain empty statement, jdbc thin driver will
> allways return {{true}} from {{getMoreResults}} method.
> Jdbc spec says:
> {noformat}
> oves to this Statement object's next result, returns true if it is a
> ResultSet object,
> <...>
> Returns:
> true if the next result is a ResultSet object; false if it is an update count
> or there are no more results
> {noformat}
> so test :
> {code:java}
> @Test
> public void test () throws Exception {
> try (Connection c = GridTestUtils.connect(grid(0), null)) {
> try (PreparedStatement p = c.prepareStatement(";")) {
> boolean isResultSet = p.execute();
> // Adding next line works the problem around:
> // p.getUpdateCount() == 0;
>
> boolean isResultSetReturned = p.getMoreResults();
>
>// should be false:
> assertFalse(isResultSetReturned); // == true
> }
> }
> }
> {code}
> {{getResultSet}} is {{null}} in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10124) [TC Bot] Redesign and refactor UI
[ https://issues.apache.org/jira/browse/IGNITE-10124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-10124: Ignite Flags: (was: Docs Required) > [TC Bot] Redesign and refactor UI > - > > Key: IGNITE-10124 > URL: https://issues.apache.org/jira/browse/IGNITE-10124 > Project: Ignite > Issue Type: Task >Reporter: Nikolai Kulagin >Priority: Minor > > We must make the TC bot more user-friendly, make UI more intuitive and simple -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10124) [TC Bot] Redesign and refactor UI
[ https://issues.apache.org/jira/browse/IGNITE-10124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10124. - Resolution: Fixed Assignee: Nikolai Kulagin Resolving issue as subtasks were resolved > [TC Bot] Redesign and refactor UI > - > > Key: IGNITE-10124 > URL: https://issues.apache.org/jira/browse/IGNITE-10124 > Project: Ignite > Issue Type: Task >Reporter: Nikolai Kulagin >Assignee: Nikolai Kulagin >Priority: Minor > > We must make the TC bot more user-friendly, make UI more intuitive and simple -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10326) [Tc Bot] Add trusted suites
[ https://issues.apache.org/jira/browse/IGNITE-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821198#comment-16821198 ] Dmitriy Pavlov commented on IGNITE-10326: - We'll implement it in some other way for License check specifically > [Tc Bot] Add trusted suites > --- > > Key: IGNITE-10326 > URL: https://issues.apache.org/jira/browse/IGNITE-10326 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Major > > In trusted suites every new failure will be notified as critical. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10326) [Tc Bot] Add trusted suites
[ https://issues.apache.org/jira/browse/IGNITE-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10326. - Resolution: Won't Fix > [Tc Bot] Add trusted suites > --- > > Key: IGNITE-10326 > URL: https://issues.apache.org/jira/browse/IGNITE-10326 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Major > > In trusted suites every new failure will be notified as critical. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
[
https://issues.apache.org/jira/browse/IGNITE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Suntsov closed IGNITE-9397.
> IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
> ---
>
> Key: IGNITE-9397
> URL: https://issues.apache.org/jira/browse/IGNITE-9397
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 2.6
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: r.properties
>
>
> *Setup*
> 1 server and 1 client node
> Attached the property file which has the only benchmark with the following
> parameters:
> {code}
> CONFIGS="\
> -cfg ${SCRIPT_DIR}/../config/ignite-localhost-config.xml -nn ${nodesNum} -b
> ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -r 30 -dn IgniteSqlDeleteBenchmark
> -sn IgniteNode -ds ${ver}sql-delete-${b}-backup,\
> "
> {code}
> *Steps*
> Run
> {code}
> $ bash bin/benchmark-run-all.sh config/r.properties
> {code}
> *Result*
> An exception during warm-up:
> {code}
> Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> java.util.NoSuchElementException
> at java.util.AbstractQueue.remove(AbstractQueue.java:117)
> at
> org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
> at
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
[
https://issues.apache.org/jira/browse/IGNITE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Suntsov resolved IGNITE-9397.
--
Resolution: Duplicate
> IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
> ---
>
> Key: IGNITE-9397
> URL: https://issues.apache.org/jira/browse/IGNITE-9397
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 2.6
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: r.properties
>
>
> *Setup*
> 1 server and 1 client node
> Attached the property file which has the only benchmark with the following
> parameters:
> {code}
> CONFIGS="\
> -cfg ${SCRIPT_DIR}/../config/ignite-localhost-config.xml -nn ${nodesNum} -b
> ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -r 30 -dn IgniteSqlDeleteBenchmark
> -sn IgniteNode -ds ${ver}sql-delete-${b}-backup,\
> "
> {code}
> *Steps*
> Run
> {code}
> $ bash bin/benchmark-run-all.sh config/r.properties
> {code}
> *Result*
> An exception during warm-up:
> {code}
> Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> java.util.NoSuchElementException
> at java.util.AbstractQueue.remove(AbstractQueue.java:117)
> at
> org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
> at
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11586) Update platforms/cpp/DEVNOTES.txt: OpenSSL
[
https://issues.apache.org/jira/browse/IGNITE-11586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821181#comment-16821181
]
Igor Sapego commented on IGNITE-11586:
--
[~sdarlington] thank you for the patch. Can you also add {{OPENSSL_HOME}} note
as proposed in the ticket description?
> Update platforms/cpp/DEVNOTES.txt: OpenSSL
> ---
>
> Key: IGNITE-11586
> URL: https://issues.apache.org/jira/browse/IGNITE-11586
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10 Pro, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Stephen Darlington
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ODBC compilation required OpenSSL headers and the project compilation fails
> due to unable to open {{include/openssl/ssl.h}}. I suggest to add the
> requirement to install OpenSSL and set the corresponding environment variable:
> {noformat}
> Building on Windows with Visual Studio (tm)
> --
> Common Requirements:
> ...
> * OPENSSL_HOME environment variable must be set pointing to OpenSSL
> installation directory.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap ion exchange history
[ https://issues.apache.org/jira/browse/IGNITE-11767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821177#comment-16821177 ] Pavel Kovalenko commented on IGNITE-11767: -- [~ilyak] Overall approach to solving the problem looks good. Partition sizes map in FullMessage is read only once during topology update, so it's safe to keep it in the serialized format every time. > GridDhtPartitionsFullMessage retains huge maps on heap ion exchange history > --- > > Key: IGNITE-11767 > URL: https://issues.apache.org/jira/browse/IGNITE-11767 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > ExchangeHistory keeps a FinishState for every topology version. > FinishState contains msg, which contains at least two huge maps: > partCntrs2 and partsSizesBytes. > We should probably strip msg, removing those two data structures before > putting msg in exchFuts linked list to be stowed away. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11766) cpp: JVM library not found for openjdk 11 on windows
[
https://issues.apache.org/jira/browse/IGNITE-11766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-11766:
-
Component/s: platforms
> cpp: JVM library not found for openjdk 11 on windows
>
>
> Key: IGNITE-11766
> URL: https://issues.apache.org/jira/browse/IGNITE-11766
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Igor Sapego
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Trying to run compiled ignite.exe from platforms/cpp on windows
> {code}
> An error occurred: JVM library is not found (did you set JAVA_HOME
> environment variable?)
> {code}
> Think problem that platforms\cpp\jni\os\win\src\utils -> JAVA_DDL =
> "\\jre\\bin\\server\\jvm.dll"
> searching for jre in jdk directory
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11766) cpp: JVM library not found for openjdk 11 on windows
[
https://issues.apache.org/jira/browse/IGNITE-11766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-11766:
-
Fix Version/s: 2.8
> cpp: JVM library not found for openjdk 11 on windows
>
>
> Key: IGNITE-11766
> URL: https://issues.apache.org/jira/browse/IGNITE-11766
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Trying to run compiled ignite.exe from platforms/cpp on windows
> {code}
> An error occurred: JVM library is not found (did you set JAVA_HOME
> environment variable?)
> {code}
> Think problem that platforms\cpp\jni\os\win\src\utils -> JAVA_DDL =
> "\\jre\\bin\\server\\jvm.dll"
> searching for jre in jdk directory
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11766) cpp: JVM library not found for openjdk 11 on windows
[
https://issues.apache.org/jira/browse/IGNITE-11766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-11766:
-
Ignite Flags: (was: Docs Required)
> cpp: JVM library not found for openjdk 11 on windows
>
>
> Key: IGNITE-11766
> URL: https://issues.apache.org/jira/browse/IGNITE-11766
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Igor Sapego
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Trying to run compiled ignite.exe from platforms/cpp on windows
> {code}
> An error occurred: JVM library is not found (did you set JAVA_HOME
> environment variable?)
> {code}
> Think problem that platforms\cpp\jni\os\win\src\utils -> JAVA_DDL =
> "\\jre\\bin\\server\\jvm.dll"
> searching for jre in jdk directory
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11103) "Control utility --cache idle_verify --dump --cache-filter ALL" comand result doesn't contain ignite-sys-cache group
[ https://issues.apache.org/jira/browse/IGNITE-11103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-11103: Assignee: Ilya Kasnacheev > "Control utility --cache idle_verify --dump --cache-filter ALL" comand result > doesn't contain ignite-sys-cache group > > > Key: IGNITE-11103 > URL: https://issues.apache.org/jira/browse/IGNITE-11103 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: ARomantsov >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.8 > > > Look at functional add in https://issues.apache.org/jira/browse/IGNITE-9980 > and find that issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11251) SQL: getMoreResults() infinitely reports about update operation on zeroCursor
[
https://issues.apache.org/jira/browse/IGNITE-11251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821148#comment-16821148
]
Roman Kondakov commented on IGNITE-11251:
-
[~alapin], fix looks good for me. But anyway, IMO we should avoid using java
{{assert}} keyword for checking test results in the future.
> SQL: getMoreResults() infinitely reports about update operation on zeroCursor
> -
>
> Key: IGNITE-11251
> URL: https://issues.apache.org/jira/browse/IGNITE-11251
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: jdbc
> Fix For: 2.8
>
>
> If we got sql query that contain empty statement, jdbc thin driver will
> allways return {{true}} from {{getMoreResults}} method.
> Jdbc spec says:
> {noformat}
> oves to this Statement object's next result, returns true if it is a
> ResultSet object,
> <...>
> Returns:
> true if the next result is a ResultSet object; false if it is an update count
> or there are no more results
> {noformat}
> so test :
> {code:java}
> @Test
> public void test () throws Exception {
> try (Connection c = GridTestUtils.connect(grid(0), null)) {
> try (PreparedStatement p = c.prepareStatement(";")) {
> boolean isResultSet = p.execute();
> // Adding next line works the problem around:
> // p.getUpdateCount() == 0;
>
> boolean isResultSetReturned = p.getMoreResults();
>
>// should be false:
> assertFalse(isResultSetReturned); // == true
> }
> }
> }
> {code}
> {{getResultSet}} is {{null}} in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11751) Javadoc broken
[
https://issues.apache.org/jira/browse/IGNITE-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-11751:
Attachment: javadoc.patch
> Javadoc broken
> --
>
> Key: IGNITE-11751
> URL: https://issues.apache.org/jira/browse/IGNITE-11751
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Priority: Blocker
> Fix For: 2.8
>
> Attachments: javadoc.patch
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:aggregate (core-javadoc)
> on project apache-ignite: An error has occurred in Javadoc report generation:
> [ERROR] Exit code: 1 -
> ignite/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/serializer/package-info.java:21:
> warning: a package-info.java file has already been seen for package
> org.apache.ignite.cache.store.cassandra.serializer
> [ERROR] package org.apache.ignite.cache.store.cassandra.serializer;
> [ERROR]^
> [ERROR] javadoc: warning - Multiple sources of package comments found for
> package "org.apache.ignite.cache.store.cassandra.serializer"
> [ERROR] javadoc: error - Error - Exception java.lang.ClassNotFoundException
> thrown while trying to register Taglet
> org.apache.ignite.tools.javadoc.IgniteLinkTaglet...
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR] ignite/modules/core/src/main/java/org/apache/ignite/Ignition.java:88:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java:828:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java:828:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStore.java:71:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStore.java:71:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/cache/store/CacheStoreSessionListener.java:114:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/transactions/Transaction.java:120:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/transactions/Transaction.java:120:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/checkpoint/CheckpointSpi.java:60:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/checkpoint/CheckpointSpi.java:60:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:233:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:233:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/deployment/DeploymentSpi.java:61:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/spi/deployment/DeploymentSpi.java:61:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToSet.java:154:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToSet.java:154:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToValue.java:152:
> warning - @ignitelink is an unknown tag.
> [ERROR]
> ignite/modules/core/src/main/java/org/apache/ignite/compute/gridify/GridifySetToValue.java:152:
> warning - @ignitelink is an unknown tag.
>
[jira] [Comment Edited] (IGNITE-11564) SQL: Implement KILL QUERY command
[
https://issues.apache.org/jira/browse/IGNITE-11564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821096#comment-16821096
]
Andrew Mashenkov edited comment on IGNITE-11564 at 4/18/19 1:26 PM:
All subtasks were merged to master within single commit.
was (Author: amashenkov):
Merged to master.
> SQL: Implement KILL QUERY command
> -
>
> Key: IGNITE-11564
> URL: https://issues.apache.org/jira/browse/IGNITE-11564
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
>
> This is an umbrella ticket for {{KILL QUERY}} command implementation.
> Original description could be found in IGNITE-10161.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11456) Use separate pool for KILL QUERY command
[ https://issues.apache.org/jira/browse/IGNITE-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821099#comment-16821099 ] Andrew Mashenkov commented on IGNITE-11456: --- Merged to master as a part of parent task. > Use separate pool for KILL QUERY command > > > Key: IGNITE-11456 > URL: https://issues.apache.org/jira/browse/IGNITE-11456 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > As of now we use QUERY_POOL to process cancellation requests. It can lead to > unable to cancel a queries in case the pool will be overflowed. > So, need to use separate pool or MGMT pool + non-blocking processing through > futures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11456) Use separate pool for KILL QUERY command
[ https://issues.apache.org/jira/browse/IGNITE-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11456: -- Ignite Flags: (was: Docs Required) > Use separate pool for KILL QUERY command > > > Key: IGNITE-11456 > URL: https://issues.apache.org/jira/browse/IGNITE-11456 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > As of now we use QUERY_POOL to process cancellation requests. It can lead to > unable to cancel a queries in case the pool will be overflowed. > So, need to use separate pool or MGMT pool + non-blocking processing through > futures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11564) SQL: Implement KILL QUERY command
[
https://issues.apache.org/jira/browse/IGNITE-11564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov resolved IGNITE-11564.
---
Resolution: Fixed
Merged to master.
> SQL: Implement KILL QUERY command
> -
>
> Key: IGNITE-11564
> URL: https://issues.apache.org/jira/browse/IGNITE-11564
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
>
> This is an umbrella ticket for {{KILL QUERY}} command implementation.
> Original description could be found in IGNITE-10161.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8633) Node fails to bail out of wrong BLT, instead hanging around indefinitely
[
https://issues.apache.org/jira/browse/IGNITE-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-8633:
---
Assignee: Ilya Kasnacheev (was: Sergey Chugunov)
> Node fails to bail out of wrong BLT, instead hanging around indefinitely
>
>
> Key: IGNITE-8633
> URL: https://issues.apache.org/jira/browse/IGNITE-8633
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: 8633.zip
>
>
> Follow-up on
> https://stackoverflow.com/questions/50234056/how-to-give-multiple-static-ip-in-apache-ignite-cache-configuration-xml-file/50270676?noredirect=1#comment88095814_50270676
> but not quite the same.
> I have three nodes: A, B and C.
> I've started A and C and performed activation.
> Then I stopped them both, started B and performed activation on it.
> Now I have two BlT clusters: (A, C) and (B)
> However, when I start B; and then try to launch nodes A or C I get
> inconsistent behavior:
> When I launch C, I get the error:
> {code}
> org.apache.ignite.spi.IgniteSpiException: BaselineTopology of joining node
> (8c1e210f-52bb-424f-9c7c-a2e7b1bab546 ) is not compatible with
> BaselineTopology in the cluster. Branching history of cluster BlT
> ([-1349069127]) doesn't contain branching point hash of joining node BlT
> (631694798). Consider cleaning persistent storage of the node and adding it
> to the cluster again.
> {code}
> But when I launch A, it never enters topology, but also never fails.
> Moreover, A and B will ping pong each other for eternity:
> {code}
> [20:16:38,596][WARNING][main][TcpDiscoverySpi] Node has not been connected to
> topology and will repeat join process. Check remote nodes logs for possible
> error messages. Note that large topology may require significant time to
> start. Increase 'TcpDiscoverySpi.networkTimeout' configuration property if
> getting this message on the starting nodes [networkTimeout=5000]
> [20:17:29,514][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery
> accepted incoming connection [rmtAddr=/172.25.1.36, rmtPort=49030]
> [20:17:29,522][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery
> spawning a new thread for connection [rmtAddr=/172.25.1.36, rmtPort=49030]
> [20:17:29,523][INFO][tcp-disco-sock-reader-#26][TcpDiscoverySpi] Started
> serving remote node connection [rmtAddr=/172.25.1.36:49030, rmtPort=49030]
> [20:17:29,524][INFO][tcp-disco-sock-reader-#26][TcpDiscoverySpi] Received
> ping request from the remote node
> [rmtNodeId=37104137-a21e-4b6f-a70b-09164300bbfc, rmtAddr=/172.25.1.36:49030,
> rmtPort=49030]
> [20:17:29,525][INFO][tcp-disco-sock-reader-#26][TcpDiscoverySpi] Finished
> writing ping response [rmtNodeId=37104137-a21e-4b6f-a70b-09164300bbfc,
> rmtAddr=/172.25.1.36:49030, rmtPort=49030]
> [20:17:29,526][INFO][tcp-disco-sock-reader-#26][TcpDiscoverySpi] Finished
> serving remote node connection [rmtAddr=/172.25.1.36:49030, rmtPort=49030
> [20:18:30,733][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery
> accepted incoming connection [rmtAddr=/172.25.1.36, rmtPort=50857]
> [20:18:30,733][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery
> spawning a new thread for connection [rmtAddr=/172.25.1.36, rmtPort=50857]
> [20:18:30,733][INFO][tcp-disco-sock-reader-#47][TcpDiscoverySpi] Started
> serving remote node connection [rmtAddr=/172.25.1.36:50857, rmtPort=50857]
> [20:18:30,734][INFO][tcp-disco-sock-reader-#47][TcpDiscoverySpi] Received
> ping request from the remote node
> [rmtNodeId=37104137-a21e-4b6f-a70b-09164300bbfc, rmtAddr=/172.25.1.36:50857,
> rmtPort=50857]
> [20:18:30,734][INFO][tcp-disco-sock-reader-#47][TcpDiscoverySpi] Finished
> writing ping response [rmtNodeId=37104137-a21e-4b6f-a70b-09164300bbfc,
> rmtAddr=/172.25.1.36:50857, rmtPort=50857]
> [20:18:30,734][INFO][tcp-disco-sock-reader-#47][TcpDiscoverySpi] Finished
> serving remote node connection [rmtAddr=/172.25.1.36:50857, rmtPort=50857
> {code}
> {code}
> [20:16:28,793][INFO][tcp-disco-msg-worker-#3][GridSnapshotAwareClusterStateProcessorImpl]
> Received state change finish message: true
> [20:16:28,803][INFO][exchange-worker-#62][time] Finished exchange init
> [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], crd=true]
> [20:16:28,812][INFO][exchange-worker-#62][GridCachePartitionExchangeManager]
> Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
> [topVer=1, minorTopVer=1], evt=DISCOVERY_CUSTOM_EVT,
> node=37104137-a21e-4b6f-a70b-09164300bbfc]
> [20:16:28,818][INFO][sys-#68][GridSnapshotAwareClusterStateProcessorImpl]
> Successfully performed final activation steps
> [nodeId=37104137-a21e-4b6f-a70b-09164300bbfc, client=false,
>
[jira] [Commented] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821085#comment-16821085
]
Ivan Rakov commented on IGNITE-10344:
-
[~Denis Chudov], thanks, merged to master.
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11743) Stopping caches concurrently with node join may lead to crash of the node
[
https://issues.apache.org/jira/browse/IGNITE-11743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821070#comment-16821070
]
Sergey Chugunov commented on IGNITE-11743:
--
[~Jokser],
Fix looks good to me, if it doesn't introduce any regression in tests please
merge it to master.
Thank you!
> Stopping caches concurrently with node join may lead to crash of the node
> -
>
> Key: IGNITE-11743
> URL: https://issues.apache.org/jira/browse/IGNITE-11743
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Chugunov
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
> Attachments: IgnitePdsNodeRestartCacheCreateTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When an existing cache is stopped (e.g. via call Ignite#destroyCache(String
> name)) this action is distributed across cluster by discovery mechanism (and
> is processed from *disco-notifier-worker* thread).
> At the same time joining node prepares to start caches from *exchange-worker*
> thread.
> If a cache stop request arrives to new node right in the middle of cache
> start prepare, it may lead to exception in FilePageStoreManager like one
> below and node crash.
> Test reproducing the issue is attached.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to get page store for
> the given cache ID (cache has not been started): -1422502786
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.getStore(FilePageStoreManager.java:1132)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:482)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:469)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:854)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:681)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.getOrAllocateCacheMetas(GridCacheOffheapManager.java:869)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.initDataStructures(GridCacheOffheapManager.java:128)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.start(IgniteCacheOffheapManagerImpl.java:193)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.start(CacheGroupContext.java:1043)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:2829)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.getOrCreateCacheGroupContext(GridCacheProcessor.java:2557)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:2387)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$null$6a5b31b9$1(GridCacheProcessor.java:2209)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$5(GridCacheProcessor.java:2130)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$926b6886$1(GridCacheProcessor.java:2206)
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:10874)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10700) [ML] Working with Binary Objects
[ https://issues.apache.org/jira/browse/IGNITE-10700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-10700: Fix Version/s: (was: 2.7.5) 2.8 > [ML] Working with Binary Objects > > > Key: IGNITE-10700 > URL: https://issues.apache.org/jira/browse/IGNITE-10700 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently, we do not support working with caches which contains Binary > Objects, we should add support of building datasets from those objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11142) Control.sh should print detailed information about transaction.
[
https://issues.apache.org/jira/browse/IGNITE-11142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821027#comment-16821027
]
Eduard Shangareev commented on IGNITE-11142:
Looks good.
> Control.sh should print detailed information about transaction.
> ---
>
> Key: IGNITE-11142
> URL: https://issues.apache.org/jira/browse/IGNITE-11142
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> We should be able to get detailed information about transactions. Approximate
> info per node:
> * Initiator node
> * Transaction state
> * Used caches
> * Used entry keys
> * Locked keys
>
> Possible command: {{control.sh --tx-info --ids txid1[txid2,...txidN]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11779) [TC Bot] Support configurable notifications for non-master branches
Dmitriy Pavlov created IGNITE-11779: --- Summary: [TC Bot] Support configurable notifications for non-master branches Key: IGNITE-11779 URL: https://issues.apache.org/jira/browse/IGNITE-11779 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Now dev.list notifications performed using fake common user and its settings. Need to add this rule to branches.json config and support other branches (e.g. release) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11778) [TC Bot] Implement unconditional blockers and add license check suites to blockers
Dmitriy Pavlov created IGNITE-11778: --- Summary: [TC Bot] Implement unconditional blockers and add license check suites to blockers Key: IGNITE-11778 URL: https://issues.apache.org/jira/browse/IGNITE-11778 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov License by RAT plugin validation should be also - considered as a blocker in PR validation - introduced failure should cause notification on tracked branches -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11777) [TC Bot] Send a notification in case test count in suite goes down and does not change during 4 runs in a row
Dmitriy Pavlov created IGNITE-11777: --- Summary: [TC Bot] Send a notification in case test count in suite goes down and does not change during 4 runs in a row Key: IGNITE-11777 URL: https://issues.apache.org/jira/browse/IGNITE-11777 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov In case tests stopped from being executed by a configuration error, the community can miss it because there are no notifications generated. Test count may be a floating value because of timeouts and exit codes, so we can compare only the successful run of suites. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11470) Views don't show in Dbeaver
[
https://issues.apache.org/jira/browse/IGNITE-11470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820998#comment-16820998
]
Taras Ledkov commented on IGNITE-11470:
---
[~jooger], my comments:
- please review my minor changes;
- lets refactoring code duplication at the
{{IgniteH2Indexing#tablesInformation}} and
org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewTables#getRows.
I guess only one point of gathering tables and columns Information should
exist. So the issue: IGNITE-11434 is related.
> Views don't show in Dbeaver
> ---
>
> Key: IGNITE-11470
> URL: https://issues.apache.org/jira/browse/IGNITE-11470
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At Database navigator tab we can see no a views. As of now we should see at
> least SQL system views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11499) SQL: DML should not use batches by default
[
https://issues.apache.org/jira/browse/IGNITE-11499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820996#comment-16820996
]
Yury Gerzhedovich commented on IGNITE-11499:
[~tledkov-gridgain], just one minor comment
[ConnectionPropertiesImpl.java|https://github.com/apache/ignite/pull/6381/files#diff-815dbcdf24e2a2b4fc9c2236ca20a4c9]
- need to amend javadoc for updateBatchSize field.
> SQL: DML should not use batches by default
> --
>
> Key: IGNITE-11499
> URL: https://issues.apache.org/jira/browse/IGNITE-11499
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently DML apply updates in batches equal to {{SqlFieldsQuery.pageSize}}.
> This is prone to deadlocks. Instead, we should apply updates one-by-one by
> default. Proposal:
> # Introduce {{SqlFieldsQuery.updateBatchSize}} property, set it to {{1}} by
> default
> # Print a warning about deadlock to log if it is greater than 1
> # Add it to JDBC and ODBC drivers
> # Add it to other languages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11758) Python thin: a lot of documentation files without license header
[ https://issues.apache.org/jira/browse/IGNITE-11758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820992#comment-16820992 ] Igor Sapego commented on IGNITE-11758: -- [~dmagda] in my understanding these are auto-generated docs that, kind of javadoc, so we have to store files that help us to auto-generate documentation during release. [~Melnichuk], am I right? > Python thin: a lot of documentation files without license header > > > Key: IGNITE-11758 > URL: https://issues.apache.org/jira/browse/IGNITE-11758 > Project: Ignite > Issue Type: Bug > Components: documentation, thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Dmitry Melnichuk >Priority: Major > Fix For: 2.8 > > > There are a lot of .rst documentation files in modules/platforms/python/docs/ > that does not contain license header. We need either delete them if they are > auto generated or add headers to them if they are not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11251) SQL: getMoreResults() infinitely reports about update operation on zeroCursor
[
https://issues.apache.org/jira/browse/IGNITE-11251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820991#comment-16820991
]
Alexander Lapin edited comment on IGNITE-11251 at 4/18/19 11:43 AM:
[~rkondakov], could you please take a look? Scala blocker is actually not a
blocker.
was (Author: alapin):
[~rkondakov], could you please take a look, scala blocker is actually not a
blocker.
> SQL: getMoreResults() infinitely reports about update operation on zeroCursor
> -
>
> Key: IGNITE-11251
> URL: https://issues.apache.org/jira/browse/IGNITE-11251
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: jdbc
> Fix For: 2.8
>
>
> If we got sql query that contain empty statement, jdbc thin driver will
> allways return {{true}} from {{getMoreResults}} method.
> Jdbc spec says:
> {noformat}
> oves to this Statement object's next result, returns true if it is a
> ResultSet object,
> <...>
> Returns:
> true if the next result is a ResultSet object; false if it is an update count
> or there are no more results
> {noformat}
> so test :
> {code:java}
> @Test
> public void test () throws Exception {
> try (Connection c = GridTestUtils.connect(grid(0), null)) {
> try (PreparedStatement p = c.prepareStatement(";")) {
> boolean isResultSet = p.execute();
> // Adding next line works the problem around:
> // p.getUpdateCount() == 0;
>
> boolean isResultSetReturned = p.getMoreResults();
>
>// should be false:
> assertFalse(isResultSetReturned); // == true
> }
> }
> }
> {code}
> {{getResultSet}} is {{null}} in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11251) SQL: getMoreResults() infinitely reports about update operation on zeroCursor
[
https://issues.apache.org/jira/browse/IGNITE-11251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820989#comment-16820989
]
Ignite TC Bot commented on IGNITE-11251:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3640884]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3543122buildTypeId=IgniteTests24Java8_RunAll]
> SQL: getMoreResults() infinitely reports about update operation on zeroCursor
> -
>
> Key: IGNITE-11251
> URL: https://issues.apache.org/jira/browse/IGNITE-11251
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Kuznetsov
>Assignee: Alexander Lapin
>Priority: Major
>
> If we got sql query that contain empty statement, jdbc thin driver will
> allways return {{true}} from {{getMoreResults}} method.
> Jdbc spec says:
> {noformat}
> oves to this Statement object's next result, returns true if it is a
> ResultSet object,
> <...>
> Returns:
> true if the next result is a ResultSet object; false if it is an update count
> or there are no more results
> {noformat}
> so test :
> {code:java}
> @Test
> public void test () throws Exception {
> try (Connection c = GridTestUtils.connect(grid(0), null)) {
> try (PreparedStatement p = c.prepareStatement(";")) {
> boolean isResultSet = p.execute();
> // Adding next line works the problem around:
> // p.getUpdateCount() == 0;
>
> boolean isResultSetReturned = p.getMoreResults();
>
>// should be false:
> assertFalse(isResultSetReturned); // == true
> }
> }
> }
> {code}
> {{getResultSet}} is {{null}} in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11499) SQL: DML should not use batches by default
[
https://issues.apache.org/jira/browse/IGNITE-11499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818811#comment-16818811
]
Taras Ledkov edited comment on IGNITE-11499 at 4/18/19 11:39 AM:
-
[~amashenkov], [~Pavlukhin], [~jooger] please review the patch.
was (Author: tledkov-gridgain):
[~amashenkov], [~Pavlukhin] please review the patch.
> SQL: DML should not use batches by default
> --
>
> Key: IGNITE-11499
> URL: https://issues.apache.org/jira/browse/IGNITE-11499
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently DML apply updates in batches equal to {{SqlFieldsQuery.pageSize}}.
> This is prone to deadlocks. Instead, we should apply updates one-by-one by
> default. Proposal:
> # Introduce {{SqlFieldsQuery.updateBatchSize}} property, set it to {{1}} by
> default
> # Print a warning about deadlock to log if it is greater than 1
> # Add it to JDBC and ODBC drivers
> # Add it to other languages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11188) Optimize baseline autoadjustment for in-memory clusters with zero timeout
[ https://issues.apache.org/jira/browse/IGNITE-11188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820983#comment-16820983 ] Anton Kalashnikov commented on IGNITE-11188: All of failed suites(Cache 2, JDBC Driver, Javadoc) are also failed in master. My changes are not reason of failed. > Optimize baseline autoadjustment for in-memory clusters with zero timeout > - > > Key: IGNITE-11188 > URL: https://issues.apache.org/jira/browse/IGNITE-11188 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > > In current implementation (IGNITE-8571) zero-timeout case initiates two > partition map exchanges on join/leave node events. This could be improved so > that baseline is updated at the same time as join/leave event processing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11753) control.sh improve error message in case of connection to secured cluster without credentials.
[
https://issues.apache.org/jira/browse/IGNITE-11753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820982#comment-16820982
]
Ilya Kasnacheev commented on IGNITE-11753:
--
Thank you for review, change merged.
> control.sh improve error message in case of connection to secured cluster
> without credentials.
> --
>
> Key: IGNITE-11753
> URL: https://issues.apache.org/jira/browse/IGNITE-11753
> Project: Ignite
> Issue Type: Improvement
> Components: UI
>Reporter: Sergey Antonov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If control.sh tries to connect to secured cluster without login/password now
> we got:
> {noformat}
> ./control.sh --state
> Failed to get cluster state.
> Authentication error, try connection again.
> user:
> {noformat}
> We should print info about attempt to connect to secured cluster and request
> login/password if it isn't set. I.e.
> {noformat}
> ./control.sh --state
> Failed to get cluster state.
> Cluster required authentication.
> user:
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11188) Optimize baseline autoadjustment for in-memory clusters with zero timeout
[
https://issues.apache.org/jira/browse/IGNITE-11188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820981#comment-16820981
]
Ignite TC Bot commented on IGNITE-11188:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3639487]]
* IgniteClientCacheStartFailoverTest.testClientStartCloseServersRestart (last
started)
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3639498]]
* JdbcThinErrorsSelfTest.testInvalidBigDecimalFormat (last started)
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3639496]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3633364buildTypeId=IgniteTests24Java8_RunAll]
> Optimize baseline autoadjustment for in-memory clusters with zero timeout
> -
>
> Key: IGNITE-11188
> URL: https://issues.apache.org/jira/browse/IGNITE-11188
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.8
>
>
> In current implementation (IGNITE-8571) zero-timeout case initiates two
> partition map exchanges on join/leave node events. This could be improved so
> that baseline is updated at the same time as join/leave event processing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11776) IgnitePdsStartWIthEmptyArchive is flaky
Vyacheslav Koptilin created IGNITE-11776:
Summary: IgnitePdsStartWIthEmptyArchive is flaky
Key: IGNITE-11776
URL: https://issues.apache.org/jira/browse/IGNITE-11776
Project: Ignite
Issue Type: Bug
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.8
It looks like the root cause of the issue is late registration of the listener.
It should be done statically via {{IgniteConfiguration}} I think.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11775) IgnitePdsWithTtlTest is flaky
Vyacheslav Koptilin created IGNITE-11775:
Summary: IgnitePdsWithTtlTest is flaky
Key: IGNITE-11775
URL: https://issues.apache.org/jira/browse/IGNITE-11775
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.8
It seems the reason for test failure is the fact that TTL manager cannot clean
up all entries because of TTL throttling (see {{GridCacheTtlManager#expire}}
and {{GridCacheOffheapManager.GridCacheDataStore#purgeExpired}}). It does not
seem a bug/problem, it just required to set the
{{IgniteSystemProperties.IGNITE_UNWIND_THROTTLING_TIMEOUT}} to a smaller value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11774) NPE TxDeadlockDetection in case of concurrent cache stop and tx.
Stanilovsky Evgeny created IGNITE-11774:
---
Summary: NPE TxDeadlockDetection in case of concurrent cache stop
and tx.
Key: IGNITE-11774
URL: https://issues.apache.org/jira/browse/IGNITE-11774
Project: Ignite
Issue Type: Bug
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
In process of working under :
[IGNITE-11592|https://issues.apache.org/jira/browse/IGNITE-11592] reproduced
NPE, need further research, reproducer commented in upper ticket code.
{code:java}
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.primary(TxDeadlockDetection.java:400)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.mapTxKeys(TxDeadlockDetection.java:376)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.map(TxDeadlockDetection.java:275)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.init(TxDeadlockDetection.java:267)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.access$100(TxDeadlockDetection.java:158)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection.detectDeadlock(TxDeadlockDetection.java:91)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.detectDeadlock(IgniteTxManager.java:2155)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onTimeout(GridNearOptimisticTxPrepareFuture.java:776)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11735) Safely handle new closures of IGNITE-11392 in mixed cluster environment
[ https://issues.apache.org/jira/browse/IGNITE-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820948#comment-16820948 ] Sergey Antonov commented on IGNITE-11735: - [~Denis Chudov] Changes looks good. > Safely handle new closures of IGNITE-11392 in mixed cluster environment > --- > > Key: IGNITE-11735 > URL: https://issues.apache.org/jira/browse/IGNITE-11735 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Under IGNITE-11392 we have added two new closures > (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). > In case we'll assemble mixed cluster (some nodes contain the patch, some > don't), we may bump into situation when closures are sent to node that > doesn't contain corresponding classes in classpath. Normally, closures will > be deployed to "old" node via peer-to-peer class deployment. However, p2p may > be disabled in configuration, which will cause ClassNotFoundException on > "old" node. > We should register IGNITE-11392 in IgniteFeatures (recent example: > IGNITE-11598) and filter out nodes that don't support new feature before > sending compute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11735) Safely handle new closures of IGNITE-11392 in mixed cluster environment
[ https://issues.apache.org/jira/browse/IGNITE-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820949#comment-16820949 ] Sergey Antonov commented on IGNITE-11735: - [~ivan.glukos] Please review. > Safely handle new closures of IGNITE-11392 in mixed cluster environment > --- > > Key: IGNITE-11735 > URL: https://issues.apache.org/jira/browse/IGNITE-11735 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Under IGNITE-11392 we have added two new closures > (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). > In case we'll assemble mixed cluster (some nodes contain the patch, some > don't), we may bump into situation when closures are sent to node that > doesn't contain corresponding classes in classpath. Normally, closures will > be deployed to "old" node via peer-to-peer class deployment. However, p2p may > be disabled in configuration, which will cause ClassNotFoundException on > "old" node. > We should register IGNITE-11392 in IgniteFeatures (recent example: > IGNITE-11598) and filter out nodes that don't support new feature before > sending compute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11736) Make the TeamCity console quiet.
[ https://issues.apache.org/jira/browse/IGNITE-11736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim updated IGNITE-11736: -- Description: As a result of this discussion: [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max size of the file isn't limited. 2. Run all will contain a parameter for switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity environment. TC fixes: Add a checkbox into the general run window. *By default* the checkbox *is active*. If the checkbox is *active*, the TeamCity adds next params for java run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* otherwise *empty params*. was: As a result of this discussion: [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max size of the file isn't limited. 2. Run all will contain a parameter for switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity environment. TC fixes: Add a checkbox into the general run window. *By default* the checkbox *is active*. If the checkbox is *active*, the TeamCity add next params for java run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* otherwise *empty params*. > Make the TeamCity console quiet. > > > Key: IGNITE-11736 > URL: https://issues.apache.org/jira/browse/IGNITE-11736 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > As a result of this discussion: > [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] > > # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max > size of the file isn't limited. 2. Run all will contain a parameter for > switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity > environment. > TC fixes: > Add a checkbox into the general run window. *By default* the checkbox *is > active*. If the checkbox is *active*, the TeamCity adds next params for java > run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* > otherwise *empty params*. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11736) Make the TeamCity console quiet.
[ https://issues.apache.org/jira/browse/IGNITE-11736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim updated IGNITE-11736: -- Description: As a result of this discussion: [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max size of the file isn't limited. 2. Run all will contain a parameter for switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity environment. TC fixes: Add a checkbox into the general run window. *By default* the checkbox *is active*. If the checkbox is *active*, the TeamCity add next params for java run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* otherwise *empty params*. was: As a result of this discussion: [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] 1. Rollover will be locked. Pros: Only one big file in an archive. Cons: Max size of the file isn't limited. 2. Run all will contain a parameter for switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity environment. > Make the TeamCity console quiet. > > > Key: IGNITE-11736 > URL: https://issues.apache.org/jira/browse/IGNITE-11736 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > As a result of this discussion: > [https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:Make%20the%20TeamCity%20console%20quiet.] > > # Rollover will be locked. Pros: Only one big file in an archive. Cons: Max > size of the file isn't limited. 2. Run all will contain a parameter for > switch off the quiet mode. 3. New config: log4j-tc-test.xml for TeamCity > environment. > TC fixes: > Add a checkbox into the general run window. *By default* the checkbox *is > active*. If the checkbox is *active*, the TeamCity add next params for java > run: *-DIGNITE_TEST_PROP_LOG4J_FILE=log4j-tc-test.xml -DIGNITE_QUIET=true* > otherwise *empty params*. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-10344:
Fix Version/s: 2.8
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820929#comment-16820929
]
Denis Chudov commented on IGNITE-10344:
---
Blocker is not related to the changes for this ticket.
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820928#comment-16820928
]
Ignite TC Bot commented on IGNITE-10344:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3639484]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3635167buildTypeId=IgniteTests24Java8_RunAll]
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10847) Web console: failed to download the mongodb on Ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820927#comment-16820927
]
Vasiliy Sisko commented on IGNITE-10847:
[~anovikov] Please review my changes.
> Web console: failed to download the mongodb on Ubuntu 18.04
> ---
>
> Key: IGNITE-10847
> URL: https://issues.apache.org/jira/browse/IGNITE-10847
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>Priority: Major
>
> I tried to run 'web console direct install' and faced with an error
> downloading of MongoDB due to there is no corresponding version for that OS.
> {code}
> name: 'StatusCodeError',
> statusCode: 403,
> message: '403 - " encoding=\\"UTF-8\\"?>\\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g="',
> error: ' encoding="UTF-8"?>\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g=',
> options:
>{ uri:
> 'https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-ubuntu1804-3.4.7.tgz.md5',
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11730) Discovery Compression check fails when nodes reconnect to cluster
[
https://issues.apache.org/jira/browse/IGNITE-11730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11730:
--
Fix Version/s: 2.8
> Discovery Compression check fails when nodes reconnect to cluster
> -
>
> Key: IGNITE-11730
> URL: https://issues.apache.org/jira/browse/IGNITE-11730
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There is a check that Discovery Data Bag compression is supported by all
> nodes.
> Apparently this check does not work when nodes reconnect after server
> restart. When there is at least one client node that does not support this
> feature, clients will still send zipped data that server would not
> understand, leaving to following server error:
> {code}
> [15:46:47,101][SEVERE][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Failed to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> with given class loader: sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:161)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9922)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:290)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalJoiningNodeData(DiscoveryDataPacket.java:169)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2076)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4620)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:4307)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2962)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2729)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7496)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2833)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7427)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.EOFException
> at
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2638)
> at
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3113)
> at
> java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:853)
> at java.io.ObjectInputStream.(ObjectInputStream.java:349)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.(JdkMarshallerObjectInputStream.java:43)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:137)
> ... 16 more
> {code}
> and client nodes will fail with following error:
> {code}
> [15:46:47,175][SEVERE][tcp-client-disco-msg-worker-#4][] Critical system
> error detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.IgniteException: Node with
> BaselineTopology cannot join mixed cluster running in compatibility mode]]
> class org.apache.ignite.IgniteException: Node with BaselineTopology cannot
> join mixed cluster running in compatibility mode
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onGridDataReceived(GridClusterStateProcessor.java:727)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:899)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2083)
> at
>
[jira] [Created] (IGNITE-11773) JDBC suite hangs due to cleared non-serializable proxy objects
Pavel Kovalenko created IGNITE-11773:
Summary: JDBC suite hangs due to cleared non-serializable proxy
objects
Key: IGNITE-11773
URL: https://issues.apache.org/jira/browse/IGNITE-11773
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.8
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
Fix For: 2.8
{noformat}
[01:53:02]W: [org.apache.ignite:ignite-clients]
java.lang.AssertionError
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.testframework.junits.GridAbstractTest$SerializableProxy.readResolve(GridAbstractTest.java:2419)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.lang.reflect.Method.invoke(Method.java:498)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1260)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2078)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:141)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:163)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:81)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10039)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.cache.CacheConfigurationEnricher.deserialize(CacheConfigurationEnricher.java:151)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.cache.CacheConfigurationEnricher.enrich(CacheConfigurationEnricher.java:122)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.cache.CacheConfigurationEnricher.enrichFully(CacheConfigurationEnricher.java:143)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.getConfigFromTemplate(GridCacheProcessor.java:3776)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.GridQueryProcessor.dynamicTableCreate(GridQueryProcessor.java:1549)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.h2.CommandProcessor.runCommandH2(CommandProcessor.java:437)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.h2.CommandProcessor.runCommand(CommandProcessor.java:195)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeCommand(IgniteH2Indexing.java:954)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1038)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2292)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2288)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2804)
[01:53:02]W:
[jira] [Commented] (IGNITE-11753) control.sh improve error message in case of connection to secured cluster without credentials.
[
https://issues.apache.org/jira/browse/IGNITE-11753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820910#comment-16820910
]
Sergey Antonov commented on IGNITE-11753:
-
[~ilyak] Changes looks good for me.
> control.sh improve error message in case of connection to secured cluster
> without credentials.
> --
>
> Key: IGNITE-11753
> URL: https://issues.apache.org/jira/browse/IGNITE-11753
> Project: Ignite
> Issue Type: Improvement
> Components: UI
>Reporter: Sergey Antonov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If control.sh tries to connect to secured cluster without login/password now
> we got:
> {noformat}
> ./control.sh --state
> Failed to get cluster state.
> Authentication error, try connection again.
> user:
> {noformat}
> We should print info about attempt to connect to secured cluster and request
> login/password if it isn't set. I.e.
> {noformat}
> ./control.sh --state
> Failed to get cluster state.
> Cluster required authentication.
> user:
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11142) Control.sh should print detailed information about transaction.
[
https://issues.apache.org/jira/browse/IGNITE-11142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820913#comment-16820913
]
Ignite TC Bot commented on IGNITE-11142:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3631513]]
* IgniteClientCacheStartFailoverTest.testClientStartCloseServersRestart (last
started)
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3631485]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3631564buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh should print detailed information about transaction.
> ---
>
> Key: IGNITE-11142
> URL: https://issues.apache.org/jira/browse/IGNITE-11142
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> We should be able to get detailed information about transactions. Approximate
> info per node:
> * Initiator node
> * Transaction state
> * Used caches
> * Used entry keys
> * Locked keys
>
> Possible command: {{control.sh --tx-info --ids txid1[txid2,...txidN]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8578) .NET: Add baseline auto-adjust parameters (definition, run-time change)
[ https://issues.apache.org/jira/browse/IGNITE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820907#comment-16820907 ] Alexandr Shapkin commented on IGNITE-8578: -- PR is ready, [~ptupitsyn] please review the changes. > .NET: Add baseline auto-adjust parameters (definition, run-time change) > --- > > Key: IGNITE-8578 > URL: https://issues.apache.org/jira/browse/IGNITE-8578 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Eduard Shangareev >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET, IEP-4, Phase-2 > Time Spent: 10m > Remaining Estimate: 0h > > We would introduce at IGNITE-8571 new parameters. > We need their support in .Net side. > See new methods on IgniteCluster interface IGNITE-11509 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11735) Safely handle new closures of IGNITE-11392 in mixed cluster environment
[ https://issues.apache.org/jira/browse/IGNITE-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820904#comment-16820904 ] Denis Chudov commented on IGNITE-11735: --- [~antonovsergey93] fixed > Safely handle new closures of IGNITE-11392 in mixed cluster environment > --- > > Key: IGNITE-11735 > URL: https://issues.apache.org/jira/browse/IGNITE-11735 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Under IGNITE-11392 we have added two new closures > (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). > In case we'll assemble mixed cluster (some nodes contain the patch, some > don't), we may bump into situation when closures are sent to node that > doesn't contain corresponding classes in classpath. Normally, closures will > be deployed to "old" node via peer-to-peer class deployment. However, p2p may > be disabled in configuration, which will cause ClassNotFoundException on > "old" node. > We should register IGNITE-11392 in IgniteFeatures (recent example: > IGNITE-11598) and filter out nodes that don't support new feature before > sending compute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11753) control.sh improve error message in case of connection to secured cluster without credentials.
[
https://issues.apache.org/jira/browse/IGNITE-11753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820892#comment-16820892
]
Ignite TC Bot commented on IGNITE-11753:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3638850]]
* GridCacheDhtPreloadMultiThreadedSelfTest.testConcurrentNodesStartStop (last
started)
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3638853]]
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3638859]]
* JdbcThinErrorsSelfTest.testInvalidDoubleFormat (last started)
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3638857]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3631930buildTypeId=IgniteTests24Java8_RunAll]
> control.sh improve error message in case of connection to secured cluster
> without credentials.
> --
>
> Key: IGNITE-11753
> URL: https://issues.apache.org/jira/browse/IGNITE-11753
> Project: Ignite
> Issue Type: Improvement
> Components: UI
>Reporter: Sergey Antonov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If control.sh tries to connect to secured cluster without login/password now
> we got:
> {noformat}
> ./control.sh --state
> Failed to get cluster state.
> Authentication error, try connection again.
> user:
> {noformat}
> We should print info about attempt to connect to secured cluster and request
> login/password if it isn't set. I.e.
> {noformat}
> ./control.sh --state
> Failed to get cluster state.
> Cluster required authentication.
> user:
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11735) Safely handle new closures of IGNITE-11392 in mixed cluster environment
[ https://issues.apache.org/jira/browse/IGNITE-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11735: Ignite Flags: (was: Docs Required) > Safely handle new closures of IGNITE-11392 in mixed cluster environment > --- > > Key: IGNITE-11735 > URL: https://issues.apache.org/jira/browse/IGNITE-11735 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Under IGNITE-11392 we have added two new closures > (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). > In case we'll assemble mixed cluster (some nodes contain the patch, some > don't), we may bump into situation when closures are sent to node that > doesn't contain corresponding classes in classpath. Normally, closures will > be deployed to "old" node via peer-to-peer class deployment. However, p2p may > be disabled in configuration, which will cause ClassNotFoundException on > "old" node. > We should register IGNITE-11392 in IgniteFeatures (recent example: > IGNITE-11598) and filter out nodes that don't support new feature before > sending compute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11735) Safely handle new closures of IGNITE-11392 in mixed cluster environment
[ https://issues.apache.org/jira/browse/IGNITE-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820873#comment-16820873 ] Sergey Antonov commented on IGNITE-11735: - [~Denis Chudov] I left few minor comment's in your PR. Please fix it. > Safely handle new closures of IGNITE-11392 in mixed cluster environment > --- > > Key: IGNITE-11735 > URL: https://issues.apache.org/jira/browse/IGNITE-11735 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Under IGNITE-11392 we have added two new closures > (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure). > In case we'll assemble mixed cluster (some nodes contain the patch, some > don't), we may bump into situation when closures are sent to node that > doesn't contain corresponding classes in classpath. Normally, closures will > be deployed to "old" node via peer-to-peer class deployment. However, p2p may > be disabled in configuration, which will cause ClassNotFoundException on > "old" node. > We should register IGNITE-11392 in IgniteFeatures (recent example: > IGNITE-11598) and filter out nodes that don't support new feature before > sending compute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10847) Web console: failed to download the mongodb on Ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko reassigned IGNITE-10847:
--
Assignee: Andrey Novikov (was: Vasiliy Sisko)
> Web console: failed to download the mongodb on Ubuntu 18.04
> ---
>
> Key: IGNITE-10847
> URL: https://issues.apache.org/jira/browse/IGNITE-10847
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>Priority: Major
>
> I tried to run 'web console direct install' and faced with an error
> downloading of MongoDB due to there is no corresponding version for that OS.
> {code}
> name: 'StatusCodeError',
> statusCode: 403,
> message: '403 - " encoding=\\"UTF-8\\"?>\\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g="',
> error: ' encoding="UTF-8"?>\nAccessDeniedAccess
> Denied4B7715F9CDA5127BzuhNAWP7FGOgDLjkNJ3y71iU+wxcWKR5F5kI4LoO1SqCdt+aPeLZXnJko5S0ji2zx5zkJaCZX3g=',
> options:
>{ uri:
> 'https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-ubuntu1804-3.4.7.tgz.md5',
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11676) Clean up custom event callbacks
[
https://issues.apache.org/jira/browse/IGNITE-11676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryker Zhang reassigned IGNITE-11676:
Assignee: Ryker Zhang
> Clean up custom event callbacks
> ---
>
> Key: IGNITE-11676
> URL: https://issues.apache.org/jira/browse/IGNITE-11676
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ryker Zhang
>Priority: Major
>
> Currently, {{GridDiscoveryManager}} has several ways of notifying Ignite
> components of discovery events:
> * Line 668: a set of {{instanceof}} statements to invoke specific callbacks
> for components (for example, {{ctx.state().onStateChangeMessage(...)}},
> {{ctx.cache().onCustomEvent(...)}}
> * Later, on line 715: we call a somewhat generic custom event listeners
> * Finally, on line 876, if the custom message was of a specific type, we
> fire EVT_DISCOVERY_CUSTOM_EVT
> Overall, this is a huge abstraction leak, and all non-discovery specifics
> should be eliminated from {{GridDiscoveryManager}}. I suggest the following:
> 1) Change {{CustomEventListener}} to have two methods: one of them should
> return {{true}} or {{false}} to determine whether the minor topology version
> should be incremented
> 2) Move all logic to corresponding components
> 3) Get rid of code on line 876, I see no need in this. Also, consider
> removing {{EVT_DISCOVERY_CUSTOM_EVT}}, as this is private API and should now
> be covered by the specific listener
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11735) Safely handle new closures of IGNITE-11392 in mixed cluster environment
[
https://issues.apache.org/jira/browse/IGNITE-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820861#comment-16820861
]
Ignite TC Bot commented on IGNITE-11735:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3580025]]
* IgniteClientCacheStartFailoverTest.testClientStartCloseServersRestart (last
started)
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3579997]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3580076buildTypeId=IgniteTests24Java8_RunAll]
> Safely handle new closures of IGNITE-11392 in mixed cluster environment
> ---
>
> Key: IGNITE-11735
> URL: https://issues.apache.org/jira/browse/IGNITE-11735
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Under IGNITE-11392 we have added two new closures
> (FetchActiveTxOwnerTraceClosure and TxOwnerDumpRequestAllowedSettingClosure).
> In case we'll assemble mixed cluster (some nodes contain the patch, some
> don't), we may bump into situation when closures are sent to node that
> doesn't contain corresponding classes in classpath. Normally, closures will
> be deployed to "old" node via peer-to-peer class deployment. However, p2p may
> be disabled in configuration, which will cause ClassNotFoundException on
> "old" node.
> We should register IGNITE-11392 in IgniteFeatures (recent example:
> IGNITE-11598) and filter out nodes that don't support new feature before
> sending compute.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap ion exchange history
[ https://issues.apache.org/jira/browse/IGNITE-11767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-11767: Assignee: Ilya Kasnacheev > GridDhtPartitionsFullMessage retains huge maps on heap ion exchange history > --- > > Key: IGNITE-11767 > URL: https://issues.apache.org/jira/browse/IGNITE-11767 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > ExchangeHistory keeps a FinishState for every topology version. > FinishState contains msg, which contains at least two huge maps: > partCntrs2 and partsSizesBytes. > We should probably strip msg, removing those two data structures before > putting msg in exchFuts linked list to be stowed away. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9513) [ML] Unify all preprocessors trainers' generics
[ https://issues.apache.org/jira/browse/IGNITE-9513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-9513. -- Resolution: Resolved Fix Version/s: 2.8 > [ML] Unify all preprocessors trainers' generics > --- > > Key: IGNITE-9513 > URL: https://issues.apache.org/jira/browse/IGNITE-9513 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Trivial > Fix For: 2.8 > > > Currently we have > EncoderTrainer implements PreprocessingTrainer > and > BinarizationTrainer implements PreprocessingTrainer Vector> > It will helps with raw types in OneVsRest or in Pipeline and CV processes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11642) [ML] Umbrella: API for Feature/Label extracting (part 2)
[ https://issues.apache.org/jira/browse/IGNITE-11642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-11642. --- Resolution: Resolved > [ML] Umbrella: API for Feature/Label extracting (part 2) > > > Key: IGNITE-11642 > URL: https://issues.apache.org/jira/browse/IGNITE-11642 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Critical > Labels: stability > Fix For: 2.8 > > > Replace current lambdas with fixed API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11582) [ML] Pipelines should work with Vectorizers
[ https://issues.apache.org/jira/browse/IGNITE-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-11582. --- Resolution: Fixed > [ML] Pipelines should work with Vectorizers > --- > > Key: IGNITE-11582 > URL: https://issues.apache.org/jira/browse/IGNITE-11582 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > Fix For: 2.8 > > > Currently Pipelines are implemented using feature/label extraction functions > with generic label value. We should adapt pipelines for vectorizers (maybe > after this ticket - IGNITE-11481). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11582) [ML] Pipelines should work with Vectorizers
[ https://issues.apache.org/jira/browse/IGNITE-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11582: -- Fix Version/s: 2.8 > [ML] Pipelines should work with Vectorizers > --- > > Key: IGNITE-11582 > URL: https://issues.apache.org/jira/browse/IGNITE-11582 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > Fix For: 2.8 > > > Currently Pipelines are implemented using feature/label extraction functions > with generic label value. We should adapt pipelines for vectorizers (maybe > after this ticket - IGNITE-11481). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11581) [ML] Adapt tutorial to new vectorizer API
[ https://issues.apache.org/jira/browse/IGNITE-11581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11581: -- Fix Version/s: 2.8 > [ML] Adapt tutorial to new vectorizer API > - > > Key: IGNITE-11581 > URL: https://issues.apache.org/jira/browse/IGNITE-11581 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > Fix For: 2.8 > > > Currently tutorial uses old feature-labels extraction API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11580) [ML] Evaluators should accept Vectorizers
[ https://issues.apache.org/jira/browse/IGNITE-11580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-11580. --- Resolution: Resolved > [ML] Evaluators should accept Vectorizers > - > > Key: IGNITE-11580 > URL: https://issues.apache.org/jira/browse/IGNITE-11580 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > Fix For: 2.8 > > > Currently evaluation API uses old interface with separated feature-label > extractors. In context of IGNITE-11449 we should change this API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11581) [ML] Adapt tutorial to new vectorizer API
[ https://issues.apache.org/jira/browse/IGNITE-11581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-11581. --- Resolution: Resolved > [ML] Adapt tutorial to new vectorizer API > - > > Key: IGNITE-11581 > URL: https://issues.apache.org/jira/browse/IGNITE-11581 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > Fix For: 2.8 > > > Currently tutorial uses old feature-labels extraction API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11580) [ML] Evaluators should accept Vectorizers
[ https://issues.apache.org/jira/browse/IGNITE-11580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11580: -- Fix Version/s: 2.8 > [ML] Evaluators should accept Vectorizers > - > > Key: IGNITE-11580 > URL: https://issues.apache.org/jira/browse/IGNITE-11580 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > Fix For: 2.8 > > > Currently evaluation API uses old interface with separated feature-label > extractors. In context of IGNITE-11449 we should change this API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
