[jira] [Commented] (IGNITE-7752) Update Ignite KafkaStreamer to use new KafkaConsmer configuration.
[ https://issues.apache.org/jira/browse/IGNITE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544066#comment-16544066 ] ASF GitHub Bot commented on IGNITE-7752: GitHub user shroman opened a pull request: https://github.com/apache/ignite/pull/4363 IGNITE-7752: Update Ignite KafkaStreamer to use new consumer. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shroman/ignite IGNITE-7752 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4363.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4363 commit b099602287ac1282b3b3fcb094e601c1f9e33e52 Author: shroman Date: 2018-07-14T05:56:00Z IGNITE-7752: Update Ignite KafkaStreamer to use new consumer. commit 8eafc4c305b6c069b7b63b7d4d567a7160b17043 Author: shroman Date: 2018-07-14T05:56:33Z IGNITE-7752: Update Ignite KafkaStreamer to use new consumer. > Update Ignite KafkaStreamer to use new KafkaConsmer configuration. > -- > > Key: IGNITE-7752 > URL: https://issues.apache.org/jira/browse/IGNITE-7752 > Project: Ignite > Issue Type: Task > Components: streaming >Reporter: Andrew Mashenkov >Assignee: Roman Shtykh >Priority: Major > Labels: newbie > Fix For: 2.7 > > > Seems, for now it is impossible to use new style KafkaConsumer configuration > in KafkaStreamer. > The issue here is Ignite use > kafka.consumer.Consumer.createJavaConsumerConnector() method which creates > old consumer (ZookeeperConsumerConnector). > We should create a new KafkaConsumer instead which looks like support both, > old and new style configs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7752) Update Ignite KafkaStreamer to use new KafkaConsmer configuration.
[ https://issues.apache.org/jira/browse/IGNITE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543998#comment-16543998 ] Roman Shtykh commented on IGNITE-7752: -- Need this feature now, reassigned to myself. > Update Ignite KafkaStreamer to use new KafkaConsmer configuration. > -- > > Key: IGNITE-7752 > URL: https://issues.apache.org/jira/browse/IGNITE-7752 > Project: Ignite > Issue Type: Task > Components: streaming >Reporter: Andrew Mashenkov >Assignee: Roman Shtykh >Priority: Major > Labels: newbie > Fix For: 2.7 > > > Seems, for now it is impossible to use new style KafkaConsumer configuration > in KafkaStreamer. > The issue here is Ignite use > kafka.consumer.Consumer.createJavaConsumerConnector() method which creates > old consumer (ZookeeperConsumerConnector). > We should create a new KafkaConsumer instead which looks like support both, > old and new style configs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7752) Update Ignite KafkaStreamer to use new KafkaConsmer configuration.
[ https://issues.apache.org/jira/browse/IGNITE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh reassigned IGNITE-7752: Assignee: Roman Shtykh (was: Chandresh Pancholi) > Update Ignite KafkaStreamer to use new KafkaConsmer configuration. > -- > > Key: IGNITE-7752 > URL: https://issues.apache.org/jira/browse/IGNITE-7752 > Project: Ignite > Issue Type: Task > Components: streaming >Reporter: Andrew Mashenkov >Assignee: Roman Shtykh >Priority: Major > Labels: newbie > Fix For: 2.7 > > > Seems, for now it is impossible to use new style KafkaConsumer configuration > in KafkaStreamer. > The issue here is Ignite use > kafka.consumer.Consumer.createJavaConsumerConnector() method which creates > old consumer (ZookeeperConsumerConnector). > We should create a new KafkaConsumer instead which looks like support both, > old and new style configs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-8411. - Resolution: Fixed > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8411. --- > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543693#comment-16543693 ] Denis Magda commented on IGNITE-8411: - [~isapego] hope your beliefs are true :) Closing the ticket. > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[ https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543637#comment-16543637 ] Ryabov Dmitrii commented on IGNITE-602: --- [~agoncharuk], I think combining them to another tuple will not make our code cleaner. > [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by > infinite recursion > > > Key: IGNITE-602 > URL: https://issues.apache.org/jira/browse/IGNITE-602 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Artem Shutak >Assignee: Ryabov Dmitrii >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.7 > > > See test > org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention > and related TODO in same source file. > Also take a look at > http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring > Test should be unmuted on TC after fix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9000) [Test Failed] IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9000:
-
Labels: MakeTeamcityGreenAgain (was: )
> [Test Failed] IgniteServiceReassignmentTest.testZombieAssignmentsCleanup
> fails sometimes.
> -
>
> Key: IGNITE-9000
> URL: https://issues.apache.org/jira/browse/IGNITE-9000
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteServiceReassignmentTest.testZombieAssignmentsCleanup has flaky failures
> on TC:
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-4702193284623513465&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=__all_branches__&itemsCount=50
> Typical output:
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> {noformat}
> Exception that triggers an assertion error:
> {noformat}
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=dc037d7a-2882-478c-a944-56c66131, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
> lastExchangeTime=1531485137994, loc=true, ver=2.7.0#19700101-sha1:,
> isClient=false], grp=ignite-sys-cache, topVer=AffinityTopologyVersion
> [topVer=3, minorTopVer=0], head=AffinityTopologyVersion [topVer=4,
> minorTopVer=0], history=[AffinityTopologyVersion [topVer=2, minorTopVer=0],
> AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion
> [topVer=4, minorTopVer=0]]]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:694)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:594)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:225)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:261)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:252)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:276)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1879)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2066)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[
https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543561#comment-16543561
]
Alexey Goncharuk commented on IGNITE-602:
-
[~SomeFire], [~alex_pl] changes look good to me.
Do you think it makes sense to move both {{SBLimitedLength}} and
{{IdentityHashMap}} into a single thread-local to make the code a bit cleaner?
> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by
> infinite recursion
>
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.7
>
>
> See test
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
> and related TODO in same source file.
> Also take a look at
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8564) DataStreamer fails if client reconnected to the cluster and allowOverride = true
[ https://issues.apache.org/jira/browse/IGNITE-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543536#comment-16543536 ] ASF GitHub Bot commented on IGNITE-8564: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4296 > DataStreamer fails if client reconnected to the cluster and allowOverride = > true > > > Key: IGNITE-8564 > URL: https://issues.apache.org/jira/browse/IGNITE-8564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: test > Fix For: 2.7 > > Attachments: DataStreamerClientReconnectAfterClusterRestartTest.java > > > But wait, there's more. > This only happens when client has reconnected to a new cluster and topology > version after that is exactly the same like when it left. > Please see the attached test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8900) SqlFieldsQuery provides incorrect result when item size exceeds page size
[ https://issues.apache.org/jira/browse/IGNITE-8900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543488#comment-16543488 ] Alexey Goncharuk commented on IGNITE-8900: -- [~ilantukh] the changes look good, please convert the provided reproducer into a unit-test. > SqlFieldsQuery provides incorrect result when item size exceeds page size > - > > Key: IGNITE-8900 > URL: https://issues.apache.org/jira/browse/IGNITE-8900 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Anton Kurbanov >Assignee: Ilya Lantukh >Priority: Blocker > Attachments: Main.java, Node.java > > > Start several server nodes, then start client, execute queries with value > range in where clause. Duplicate entries may be found, some entries may be > missing. > Results as an example: > expected 5 results but got back 3 results (query range 61002664327616 to > 610026643276160004), cache.getAll returned 5 entries. > expected 8 results but got back 7 results (query range 61002664327616 to > 610026643276160007), cache.getAll returned 8 entries. > Query results: [61002664327616, 610026643276160003, 610026643276160004, > 610026643276160005, 610026643276160005, 610026643276160006, > 610026643276160007] > Please find reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8774) Daemon moves cluster to compatibility mode when joins
[
https://issues.apache.org/jira/browse/IGNITE-8774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543455#comment-16543455
]
Dmitriy Pavlov commented on IGNITE-8774:
I've retriggered a number of suspicious tests.
> Daemon moves cluster to compatibility mode when joins
> -
>
> Key: IGNITE-8774
> URL: https://issues.apache.org/jira/browse/IGNITE-8774
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.7
>
>
> When a daemon node joins the cluster seems to switch to compatibility mode
> (allowing nodes without baseline support). It prevents baseline nodes from
> being restarted.
> Example:
> {code}
> Ignite ignite1 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv1");
> Ignite ignite2 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> ignite2.cluster().active(true);
> IgnitionEx.setClientMode(true);
> IgnitionEx.setDaemon(true);
> Ignite daemon =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "daemon");
> IgnitionEx.setClientMode(false);
> IgnitionEx.setDaemon(false);
> ignite2.close();
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> {code}
> The attempt to restart ignite2 throws an exception:
> {code}
> [2018-06-11 18:45:25,766][ERROR][tcp-disco-msg-worker-#39%srv2%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler,
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, 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:714)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:883)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1939)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4354)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2744)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8912) PartitionLossPolicy.READ_ONLY_SAFE does not detect partition loss
[ https://issues.apache.org/jira/browse/IGNITE-8912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543446#comment-16543446 ] ASF GitHub Bot commented on IGNITE-8912: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4331 > PartitionLossPolicy.READ_ONLY_SAFE does not detect partition loss > -- > > Key: IGNITE-8912 > URL: https://issues.apache.org/jira/browse/IGNITE-8912 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.7 > > Attachments: MissedPartitionLostReproducer.java > > > Cluster of 4 for a cache with 1 backup and READ_ONLY_SAFE . > After forcefully killed two nodes, a partition lost without including in > partitionsLost collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin
Dmitriy Pavlov created IGNITE-9005:
--
Summary: Eviction policy MBeans change failed LifecycleAwareTest
on cache name injectoin
Key: IGNITE-9005
URL: https://issues.apache.org/jira/browse/IGNITE-9005
Project: Ignite
Issue Type: Test
Reporter: Dmitriy Pavlov
Assignee: Stanislav Lukyanov
Fix For: 2.7
http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
New test failure detected
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7246907407546697403&branch=%3Cdefault%3E&tab=testDetails
after merging
IGNITE-8776 Eviction policy MBeans are never registered if
evictionPolicyFactory is used
Revert of commit makes test passing.
Locally test also failed. Failed with message
{noformat}
Unexpected cache name for
org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
expected: but was:
{noformat}
Message of failure seems to be related to TestEvictionPolicy instance from test
class.
Seems that returing call to cctx.kernalContext (). resource (). injectCacheName
(rsrc, cfg.getName ()); should fix issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8995) FailureHandler executed on error in ScanQuery's IgniteBiPredicate
[
https://issues.apache.org/jira/browse/IGNITE-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543405#comment-16543405
]
Dmitriy Gladkikh commented on IGNITE-8995:
--
Please approve the PR from [~ivandasch].
> FailureHandler executed on error in ScanQuery's IgniteBiPredicate
> -
>
> Key: IGNITE-8995
> URL: https://issues.apache.org/jira/browse/IGNITE-8995
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitriy Gladkikh
>Assignee: Ivan Daschinskiy
>Priority: Critical
> Fix For: 2.7
>
>
> This code demonstrates this behavior:
> {code:java}
> import java.util.Collections;
> import javax.cache.Cache;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObject;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.query.QueryCursor;
> import org.apache.ignite.cache.query.ScanQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> /**
> * -ea -DIGNITE_QUIET=false
> */
> public class ScanQueryIgniteBiPredicateWithError {
> private static final String CACHE_NAME = "test_cache_name";
> public static void main(String[] args) {
> try (Ignite igniteServer = Ignition.start(getCfg("node_server",
> false));
> Ignite igniteClient = Ignition.start(getCfg("node_client",
> true)))
> {
> IgniteCache cache =
> igniteClient.cache(CACHE_NAME);
> cache.put(1,
> igniteClient.binary().builder("test_type").setField("field_0",
> "field_0_val").build());
> try (QueryCursor> cursor =
> cache.withKeepBinary().query(new ScanQuery<>(
> new IgniteBiPredicate() {
> @Override public boolean apply(Integer key, BinaryObject
> value) {
> throw new AssertionError(); // Error.
> //return value.field(null) != null; // Error.
> //return true; // Ok.
> }
> })))
> {
> for (Cache.Entry entry : cursor)
> // Without error in IgniteBiPredicate:
> // Key = 1, Val = test_type [idHash=2024711353,
> hash=394028655, field_0=val_0]
> System.out.printf("Key = %s, Val = %s%n", entry.getKey(),
> entry.getValue());
> }
> }
> }
> /**
> * @param instanceName Ignite instance name.
> * @param clientMode Client mode.
> * @return Ignite configuration.
> */
> private static IgniteConfiguration getCfg(String instanceName, boolean
> clientMode) {
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();
> tcpDiscoverySpi.setIpFinder(ipFinder);
> DataRegionConfiguration dataRegionCfg = new DataRegionConfiguration();
> dataRegionCfg.setPersistenceEnabled(true);
> DataStorageConfiguration dataStorageCfg = new
> DataStorageConfiguration();
> dataStorageCfg.setDefaultDataRegionConfiguration(dataRegionCfg);
> CacheConfiguration ccfg = new
> CacheConfiguration(CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setCacheMode(CacheMode.PARTITIONED);
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setIgniteInstanceName(instanceName);
> cfg.setDiscoverySpi(tcpDiscoverySpi);
> cfg.setDataStorageConfiguration(dataStorageCfg);
> cfg.setCacheConfiguration(ccfg);
> if (!clientMode)
> cfg.setAutoActivationEnabled(true);
> else
> cfg.setClientMode(true);
> return cfg;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8995) FailureHandler executed on error in ScanQuery's IgniteBiPredicate
[
https://issues.apache.org/jira/browse/IGNITE-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Gladkikh reassigned IGNITE-8995:
Assignee: Ivan Daschinskiy (was: Dmitriy Gladkikh)
> FailureHandler executed on error in ScanQuery's IgniteBiPredicate
> -
>
> Key: IGNITE-8995
> URL: https://issues.apache.org/jira/browse/IGNITE-8995
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitriy Gladkikh
>Assignee: Ivan Daschinskiy
>Priority: Critical
> Fix For: 2.7
>
>
> This code demonstrates this behavior:
> {code:java}
> import java.util.Collections;
> import javax.cache.Cache;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObject;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.query.QueryCursor;
> import org.apache.ignite.cache.query.ScanQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> /**
> * -ea -DIGNITE_QUIET=false
> */
> public class ScanQueryIgniteBiPredicateWithError {
> private static final String CACHE_NAME = "test_cache_name";
> public static void main(String[] args) {
> try (Ignite igniteServer = Ignition.start(getCfg("node_server",
> false));
> Ignite igniteClient = Ignition.start(getCfg("node_client",
> true)))
> {
> IgniteCache cache =
> igniteClient.cache(CACHE_NAME);
> cache.put(1,
> igniteClient.binary().builder("test_type").setField("field_0",
> "field_0_val").build());
> try (QueryCursor> cursor =
> cache.withKeepBinary().query(new ScanQuery<>(
> new IgniteBiPredicate() {
> @Override public boolean apply(Integer key, BinaryObject
> value) {
> throw new AssertionError(); // Error.
> //return value.field(null) != null; // Error.
> //return true; // Ok.
> }
> })))
> {
> for (Cache.Entry entry : cursor)
> // Without error in IgniteBiPredicate:
> // Key = 1, Val = test_type [idHash=2024711353,
> hash=394028655, field_0=val_0]
> System.out.printf("Key = %s, Val = %s%n", entry.getKey(),
> entry.getValue());
> }
> }
> }
> /**
> * @param instanceName Ignite instance name.
> * @param clientMode Client mode.
> * @return Ignite configuration.
> */
> private static IgniteConfiguration getCfg(String instanceName, boolean
> clientMode) {
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();
> tcpDiscoverySpi.setIpFinder(ipFinder);
> DataRegionConfiguration dataRegionCfg = new DataRegionConfiguration();
> dataRegionCfg.setPersistenceEnabled(true);
> DataStorageConfiguration dataStorageCfg = new
> DataStorageConfiguration();
> dataStorageCfg.setDefaultDataRegionConfiguration(dataRegionCfg);
> CacheConfiguration ccfg = new
> CacheConfiguration(CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setCacheMode(CacheMode.PARTITIONED);
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setIgniteInstanceName(instanceName);
> cfg.setDiscoverySpi(tcpDiscoverySpi);
> cfg.setDataStorageConfiguration(dataStorageCfg);
> cfg.setCacheConfiguration(ccfg);
> if (!clientMode)
> cfg.setAutoActivationEnabled(true);
> else
> cfg.setClientMode(true);
> return cfg;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8938) file-decompressor thread termination should be handled with Failure handler
[
https://issues.apache.org/jira/browse/IGNITE-8938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543377#comment-16543377
]
Ivan Rakov commented on IGNITE-8938:
Code changes and TC state looks good to me. Please proceed with merge.
> file-decompressor thread termination should be handled with Failure handler
> ---
>
> Key: IGNITE-8938
> URL: https://issues.apache.org/jira/browse/IGNITE-8938
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.7
>
>
> file-decompressor thread termination should be handled with Failure Handler
> (IEP-14).
> It doesn't work right now. Also exception handling in {{body()}} method
> should be revised.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9004) Failed to move temp file during segment creation
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543370#comment-16543370
]
ASF GitHub Bot commented on IGNITE-9004:
GitHub user akalash opened a pull request:
https://github.com/apache/ignite/pull/4362
IGNITE-9004 rollback formatFile changes
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9004
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4362.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4362
commit e431f2311fc756b0945ac20ee24b1a768a4d8c62
Author: Anton Kalashnikov
Date: 2018-07-13T15:53:30Z
IGNITE-9004 rollback formatFile changes
> Failed to move temp file during segment creation
>
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>
> Reproduced by Activate/Deactivate suit, for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> class org.apache.ignite.internal.pagemem.wal.StorageException: Failed to move
> temp file to a regular WAL segment file: /data/teamcity/work/c182b70f2dfa650
> 7/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1446)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:2269)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$4500(FileWriteAheadLogManager.java:143)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.allocateRemainingFiles(FileWriteAheadLogManage
> r.java:1862)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.body(FileWriteAheadLogManager.java:1606)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [13:56:05]W: [org.apache.ignite:ignite-core] Caused by:
> java.nio.file.NoSuchFileException:
> /data/teamcity/work/c182b70f2dfa6507/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal.tmp
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:409)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.nio.file.Files.move(Files.java:1395)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1442)
> [13:56:05]W: [org.apache.ignite:ignite-core] ... 6 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8971) GridRestProcessor should propagate error message
[ https://issues.apache.org/jira/browse/IGNITE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543369#comment-16543369 ] Andrew Medvedev commented on IGNITE-8971: - Also fixed tests TC https://ci.ignite.apache.org/viewQueued.html?itemId=1489736 > GridRestProcessor should propagate error message > > > Key: IGNITE-8971 > URL: https://issues.apache.org/jira/browse/IGNITE-8971 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Assignee: Andrew Medvedev >Priority: Major > > GridRestProcessor should propagate error message (stack trace) for handling > disk full error messages -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8995) FailureHandler executed on error in ScanQuery's IgniteBiPredicate
[
https://issues.apache.org/jira/browse/IGNITE-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-8995:
-
Priority: Critical (was: Major)
> FailureHandler executed on error in ScanQuery's IgniteBiPredicate
> -
>
> Key: IGNITE-8995
> URL: https://issues.apache.org/jira/browse/IGNITE-8995
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitriy Gladkikh
>Assignee: Dmitriy Gladkikh
>Priority: Critical
> Fix For: 2.7
>
>
> This code demonstrates this behavior:
> {code:java}
> import java.util.Collections;
> import javax.cache.Cache;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObject;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.query.QueryCursor;
> import org.apache.ignite.cache.query.ScanQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> /**
> * -ea -DIGNITE_QUIET=false
> */
> public class ScanQueryIgniteBiPredicateWithError {
> private static final String CACHE_NAME = "test_cache_name";
> public static void main(String[] args) {
> try (Ignite igniteServer = Ignition.start(getCfg("node_server",
> false));
> Ignite igniteClient = Ignition.start(getCfg("node_client",
> true)))
> {
> IgniteCache cache =
> igniteClient.cache(CACHE_NAME);
> cache.put(1,
> igniteClient.binary().builder("test_type").setField("field_0",
> "field_0_val").build());
> try (QueryCursor> cursor =
> cache.withKeepBinary().query(new ScanQuery<>(
> new IgniteBiPredicate() {
> @Override public boolean apply(Integer key, BinaryObject
> value) {
> throw new AssertionError(); // Error.
> //return value.field(null) != null; // Error.
> //return true; // Ok.
> }
> })))
> {
> for (Cache.Entry entry : cursor)
> // Without error in IgniteBiPredicate:
> // Key = 1, Val = test_type [idHash=2024711353,
> hash=394028655, field_0=val_0]
> System.out.printf("Key = %s, Val = %s%n", entry.getKey(),
> entry.getValue());
> }
> }
> }
> /**
> * @param instanceName Ignite instance name.
> * @param clientMode Client mode.
> * @return Ignite configuration.
> */
> private static IgniteConfiguration getCfg(String instanceName, boolean
> clientMode) {
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();
> tcpDiscoverySpi.setIpFinder(ipFinder);
> DataRegionConfiguration dataRegionCfg = new DataRegionConfiguration();
> dataRegionCfg.setPersistenceEnabled(true);
> DataStorageConfiguration dataStorageCfg = new
> DataStorageConfiguration();
> dataStorageCfg.setDefaultDataRegionConfiguration(dataRegionCfg);
> CacheConfiguration ccfg = new
> CacheConfiguration(CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setCacheMode(CacheMode.PARTITIONED);
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setIgniteInstanceName(instanceName);
> cfg.setDiscoverySpi(tcpDiscoverySpi);
> cfg.setDataStorageConfiguration(dataStorageCfg);
> cfg.setCacheConfiguration(ccfg);
> if (!clientMode)
> cfg.setAutoActivationEnabled(true);
> else
> cfg.setClientMode(true);
> return cfg;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9004) Failed to move temp file during segment creation
Anton Kalashnikov created IGNITE-9004:
-
Summary: Failed to move temp file during segment creation
Key: IGNITE-9004
URL: https://issues.apache.org/jira/browse/IGNITE-9004
Project: Ignite
Issue Type: Test
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov
Reproduced by Activate/Deactivate suit, for example
IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
{noformat}
class org.apache.ignite.internal.pagemem.wal.StorageException: Failed to move
temp file to a regular WAL segment file: /data/teamcity/work/c182b70f2dfa650
7/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal
[13:56:05]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1446)
[13:56:05]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:2269)
[13:56:05]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$4500(FileWriteAheadLogManager.java:143)
[13:56:05]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.allocateRemainingFiles(FileWriteAheadLogManage
r.java:1862)
[13:56:05]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.body(FileWriteAheadLogManager.java:1606)
[13:56:05]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[13:56:05]W: [org.apache.ignite:ignite-core] at
java.lang.Thread.run(Thread.java:748)
[13:56:05]W: [org.apache.ignite:ignite-core] Caused by:
java.nio.file.NoSuchFileException:
/data/teamcity/work/c182b70f2dfa6507/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal.tmp
[13:56:05]W: [org.apache.ignite:ignite-core] at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
[13:56:05]W: [org.apache.ignite:ignite-core] at
sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
[13:56:05]W: [org.apache.ignite:ignite-core] at
sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
[13:56:05]W: [org.apache.ignite:ignite-core] at
sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:409)
[13:56:05]W: [org.apache.ignite:ignite-core] at
sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
[13:56:05]W: [org.apache.ignite:ignite-core] at
java.nio.file.Files.move(Files.java:1395)
[13:56:05]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1442)
[13:56:05]W: [org.apache.ignite:ignite-core] ... 6 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8995) FailureHandler executed on error in ScanQuery's IgniteBiPredicate
[
https://issues.apache.org/jira/browse/IGNITE-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-8995:
-
Fix Version/s: 2.7
> FailureHandler executed on error in ScanQuery's IgniteBiPredicate
> -
>
> Key: IGNITE-8995
> URL: https://issues.apache.org/jira/browse/IGNITE-8995
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitriy Gladkikh
>Assignee: Dmitriy Gladkikh
>Priority: Major
> Fix For: 2.7
>
>
> This code demonstrates this behavior:
> {code:java}
> import java.util.Collections;
> import javax.cache.Cache;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObject;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.query.QueryCursor;
> import org.apache.ignite.cache.query.ScanQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> /**
> * -ea -DIGNITE_QUIET=false
> */
> public class ScanQueryIgniteBiPredicateWithError {
> private static final String CACHE_NAME = "test_cache_name";
> public static void main(String[] args) {
> try (Ignite igniteServer = Ignition.start(getCfg("node_server",
> false));
> Ignite igniteClient = Ignition.start(getCfg("node_client",
> true)))
> {
> IgniteCache cache =
> igniteClient.cache(CACHE_NAME);
> cache.put(1,
> igniteClient.binary().builder("test_type").setField("field_0",
> "field_0_val").build());
> try (QueryCursor> cursor =
> cache.withKeepBinary().query(new ScanQuery<>(
> new IgniteBiPredicate() {
> @Override public boolean apply(Integer key, BinaryObject
> value) {
> throw new AssertionError(); // Error.
> //return value.field(null) != null; // Error.
> //return true; // Ok.
> }
> })))
> {
> for (Cache.Entry entry : cursor)
> // Without error in IgniteBiPredicate:
> // Key = 1, Val = test_type [idHash=2024711353,
> hash=394028655, field_0=val_0]
> System.out.printf("Key = %s, Val = %s%n", entry.getKey(),
> entry.getValue());
> }
> }
> }
> /**
> * @param instanceName Ignite instance name.
> * @param clientMode Client mode.
> * @return Ignite configuration.
> */
> private static IgniteConfiguration getCfg(String instanceName, boolean
> clientMode) {
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();
> tcpDiscoverySpi.setIpFinder(ipFinder);
> DataRegionConfiguration dataRegionCfg = new DataRegionConfiguration();
> dataRegionCfg.setPersistenceEnabled(true);
> DataStorageConfiguration dataStorageCfg = new
> DataStorageConfiguration();
> dataStorageCfg.setDefaultDataRegionConfiguration(dataRegionCfg);
> CacheConfiguration ccfg = new
> CacheConfiguration(CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setCacheMode(CacheMode.PARTITIONED);
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setIgniteInstanceName(instanceName);
> cfg.setDiscoverySpi(tcpDiscoverySpi);
> cfg.setDataStorageConfiguration(dataStorageCfg);
> cfg.setCacheConfiguration(ccfg);
> if (!clientMode)
> cfg.setAutoActivationEnabled(true);
> else
> cfg.setClientMode(true);
> return cfg;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8991) Failed server node if predicate in scan query throw AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-8991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy resolved IGNITE-8991.
--
Resolution: Duplicate
> Failed server node if predicate in scan query throw AssertionError
> --
>
> Key: IGNITE-8991
> URL: https://issues.apache.org/jira/browse/IGNITE-8991
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: RunFD7747.java
>
>
> Reproducer [attach|^RunFD7747.java] ,
> server nodes react by stopping at Error when scan query
> {code}
> org/apache/ignite/internal/processors/cache/query/GridCacheQueryManager.java:1335
> if (e instanceof Error)
> throw (Error)e;
> {code}
>
> execute query, kill server node
> {code}
> cache.query(new ScanQuery<>(new IgniteBiPredicate() {
> @Override public boolean apply(Object key, Object value) {
> throw new AssertionError("It's not Exception, it's worse.");
> }
> }));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9002) CPP Thin: Crash when used with dynamic cache without configuration
[ https://issues.apache.org/jira/browse/IGNITE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543339#comment-16543339 ] ASF GitHub Bot commented on IGNITE-9002: GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/4361 IGNITE-9002: Fixed C++ thin client crash when used with dynamic cache without config You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9002 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4361.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4361 commit 88bdec61ba3a4855de354744b9f4d9a4e8dd9045 Author: Igor Sapego Date: 2018-07-13T15:19:55Z IGNITE-9002: Added test. commit 8d4acbdf230af01d082a6101f54002844c90dedf Author: Igor Sapego Date: 2018-07-13T15:21:00Z IGNITE-9002: Fixed issue commit d86ab299341fec69a4892820d34b8d6b83ecc59e Author: Igor Sapego Date: 2018-07-13T15:22:00Z IGNITE-9002: Bumped protocol version commit 39bebb18e6b828d3760fcf67cd7b6a6f4a4dde57 Author: Igor Sapego Date: 2018-07-13T15:22:37Z IGNITE-9002: Added default constructors for CacheClient and IgniteClient > CPP Thin: Crash when used with dynamic cache without configuration > -- > > Key: IGNITE-9002 > URL: https://issues.apache.org/jira/browse/IGNITE-9002 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Crash happens because of the unhandled case when cache has zero partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543325#comment-16543325
]
Sergey Chugunov commented on IGNITE-8957:
-
[~Mmuzaf],
I replied to your comments in Pull Request, most of them were fixed.
To the question about *walSegmentsCleared* improvement I think it is not
rational to include it to the current ticket which is about fixing test failure
so I created another one: IGNITE-9003.
Feel free to pick it up and improve other things that were not covered in this
ticket.
Thank you for your efforts!
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9003) walSegmentsCleared piece of checkpoint logging improvement
[ https://issues.apache.org/jira/browse/IGNITE-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-9003: Priority: Minor (was: Major) > walSegmentsCleared piece of checkpoint logging improvement > -- > > Key: IGNITE-9003 > URL: https://issues.apache.org/jira/browse/IGNITE-9003 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Priority: Minor > Fix For: 2.7 > > Original Estimate: 48h > Remaining Estimate: 48h > > In the IGNITE-8737 ticket *walSegmentsCovered* piece was added: now on > checkpoint finish absolute indexes of all wal segments that are not needed > anymore for restoring from this checkpoint are logged at info level. > The same thing should be done for *walSegmentsCleared* piece: instead of > number of cleared segments index range should be printed out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9003) walSegmentsCleared piece of checkpoint logging improvement
Sergey Chugunov created IGNITE-9003: --- Summary: walSegmentsCleared piece of checkpoint logging improvement Key: IGNITE-9003 URL: https://issues.apache.org/jira/browse/IGNITE-9003 Project: Ignite Issue Type: Improvement Components: persistence Reporter: Sergey Chugunov Fix For: 2.7 In the IGNITE-8737 ticket *walSegmentsCovered* piece was added: now on checkpoint finish absolute indexes of all wal segments that are not needed anymore for restoring from this checkpoint are logged at info level. The same thing should be done for *walSegmentsCleared* piece: instead of number of cleared segments index range should be printed out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9002) CPP Thin: Crash when used with dynamic cache without configuration
[ https://issues.apache.org/jira/browse/IGNITE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-9002: Summary: CPP Thin: Crash when used with dynamic cache without configuration (was: CPP Thin: Crash when used with not partitioned cache) > CPP Thin: Crash when used with dynamic cache without configuration > -- > > Key: IGNITE-9002 > URL: https://issues.apache.org/jira/browse/IGNITE-9002 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Crash happens because of the unhandled case when cache has zero partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9002) CPP Thin: Crash when used with not partitioed cache
[ https://issues.apache.org/jira/browse/IGNITE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-9002: Summary: CPP Thin: Crash when used with not partitioed cache (was: CPP Thin: Crash when used with not replicated cache) > CPP Thin: Crash when used with not partitioed cache > --- > > Key: IGNITE-9002 > URL: https://issues.apache.org/jira/browse/IGNITE-9002 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Crash happens because of the unhandled case when cache has zero partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9002) CPP Thin: Crash when used with not partitioned cache
[ https://issues.apache.org/jira/browse/IGNITE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-9002: Summary: CPP Thin: Crash when used with not partitioned cache (was: CPP Thin: Crash when used with not partitioed cache) > CPP Thin: Crash when used with not partitioned cache > > > Key: IGNITE-9002 > URL: https://issues.apache.org/jira/browse/IGNITE-9002 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Crash happens because of the unhandled case when cache has zero partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8995) FailureHandler executed on error in ScanQuery's IgniteBiPredicate
[
https://issues.apache.org/jira/browse/IGNITE-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543210#comment-16543210
]
ASF GitHub Bot commented on IGNITE-8995:
GitHub user ivandasch opened a pull request:
https://github.com/apache/ignite/pull/4360
IGNITE-8995: Catch and proper propagate uncatched exceptions from filter
and transformer to client.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ivandasch/ignite ignite-8995
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4360.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4360
commit a4ad28a4ee05c490ff468eaa33b687ad5446e405
Author: Ivan Daschinskiy
Date: 2018-07-13T13:47:12Z
IGNITE-8995: Catch and proper propagate uncatched exceptions from filter
and transformer to client.
> FailureHandler executed on error in ScanQuery's IgniteBiPredicate
> -
>
> Key: IGNITE-8995
> URL: https://issues.apache.org/jira/browse/IGNITE-8995
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitriy Gladkikh
>Assignee: Dmitriy Gladkikh
>Priority: Major
>
> This code demonstrates this behavior:
> {code:java}
> import java.util.Collections;
> import javax.cache.Cache;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObject;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.query.QueryCursor;
> import org.apache.ignite.cache.query.ScanQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> /**
> * -ea -DIGNITE_QUIET=false
> */
> public class ScanQueryIgniteBiPredicateWithError {
> private static final String CACHE_NAME = "test_cache_name";
> public static void main(String[] args) {
> try (Ignite igniteServer = Ignition.start(getCfg("node_server",
> false));
> Ignite igniteClient = Ignition.start(getCfg("node_client",
> true)))
> {
> IgniteCache cache =
> igniteClient.cache(CACHE_NAME);
> cache.put(1,
> igniteClient.binary().builder("test_type").setField("field_0",
> "field_0_val").build());
> try (QueryCursor> cursor =
> cache.withKeepBinary().query(new ScanQuery<>(
> new IgniteBiPredicate() {
> @Override public boolean apply(Integer key, BinaryObject
> value) {
> throw new AssertionError(); // Error.
> //return value.field(null) != null; // Error.
> //return true; // Ok.
> }
> })))
> {
> for (Cache.Entry entry : cursor)
> // Without error in IgniteBiPredicate:
> // Key = 1, Val = test_type [idHash=2024711353,
> hash=394028655, field_0=val_0]
> System.out.printf("Key = %s, Val = %s%n", entry.getKey(),
> entry.getValue());
> }
> }
> }
> /**
> * @param instanceName Ignite instance name.
> * @param clientMode Client mode.
> * @return Ignite configuration.
> */
> private static IgniteConfiguration getCfg(String instanceName, boolean
> clientMode) {
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();
> tcpDiscoverySpi.setIpFinder(ipFinder);
> DataRegionConfiguration dataRegionCfg = new DataRegionConfiguration();
> dataRegionCfg.setPersistenceEnabled(true);
> DataStorageConfiguration dataStorageCfg = new
> DataStorageConfiguration();
> dataStorageCfg.setDefaultDataRegionConfiguration(dataRegionCfg);
> CacheConfiguration ccfg = new
> CacheConfiguration(CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setCacheMode(CacheMode.PARTITIONED);
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setIgniteInstanceName(instanceName);
>
[jira] [Created] (IGNITE-9002) CPP Thin: Crash when used with not replicated cache
Igor Sapego created IGNITE-9002: --- Summary: CPP Thin: Crash when used with not replicated cache Key: IGNITE-9002 URL: https://issues.apache.org/jira/browse/IGNITE-9002 Project: Ignite Issue Type: Bug Components: platforms, thin client Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.7 Crash happens because of the unhandled case when cache has zero partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8055) Sqline command !tables works incorrect for client node
[ https://issues.apache.org/jira/browse/IGNITE-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543203#comment-16543203 ] Ilya Kasnacheev commented on IGNITE-8055: - https://github.com/apache/ignite/pull/4359 > Sqline command !tables works incorrect for client node > -- > > Key: IGNITE-8055 > URL: https://issues.apache.org/jira/browse/IGNITE-8055 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Ilya Kasnacheev >Priority: Minor > Fix For: 2.7 > > > For reproducing: > You should start one local server and one local client nodes and follow the > instructions: > 1)Connect to server node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10800 > 2)Create new table on server node: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > 3)Check that table exists from server node: > !tables > On this step table should be shown in the response. > 4)Connect to client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 5)Check that table exists from server node: > !tables > *On this step there is no "city" table in the list.* > Next commands work from client node as well: > SELECT * FROM City > DROP TABLE City > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-8995) FailureHandler executed on error in ScanQuery's IgniteBiPredicate
[
https://issues.apache.org/jira/browse/IGNITE-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny updated IGNITE-8995:
---
Comment: was deleted
(was: one comment from me (take a look into github), all other lgfm, thanks !)
> FailureHandler executed on error in ScanQuery's IgniteBiPredicate
> -
>
> Key: IGNITE-8995
> URL: https://issues.apache.org/jira/browse/IGNITE-8995
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitriy Gladkikh
>Assignee: Dmitriy Gladkikh
>Priority: Major
>
> This code demonstrates this behavior:
> {code:java}
> import java.util.Collections;
> import javax.cache.Cache;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObject;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.query.QueryCursor;
> import org.apache.ignite.cache.query.ScanQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> /**
> * -ea -DIGNITE_QUIET=false
> */
> public class ScanQueryIgniteBiPredicateWithError {
> private static final String CACHE_NAME = "test_cache_name";
> public static void main(String[] args) {
> try (Ignite igniteServer = Ignition.start(getCfg("node_server",
> false));
> Ignite igniteClient = Ignition.start(getCfg("node_client",
> true)))
> {
> IgniteCache cache =
> igniteClient.cache(CACHE_NAME);
> cache.put(1,
> igniteClient.binary().builder("test_type").setField("field_0",
> "field_0_val").build());
> try (QueryCursor> cursor =
> cache.withKeepBinary().query(new ScanQuery<>(
> new IgniteBiPredicate() {
> @Override public boolean apply(Integer key, BinaryObject
> value) {
> throw new AssertionError(); // Error.
> //return value.field(null) != null; // Error.
> //return true; // Ok.
> }
> })))
> {
> for (Cache.Entry entry : cursor)
> // Without error in IgniteBiPredicate:
> // Key = 1, Val = test_type [idHash=2024711353,
> hash=394028655, field_0=val_0]
> System.out.printf("Key = %s, Val = %s%n", entry.getKey(),
> entry.getValue());
> }
> }
> }
> /**
> * @param instanceName Ignite instance name.
> * @param clientMode Client mode.
> * @return Ignite configuration.
> */
> private static IgniteConfiguration getCfg(String instanceName, boolean
> clientMode) {
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();
> tcpDiscoverySpi.setIpFinder(ipFinder);
> DataRegionConfiguration dataRegionCfg = new DataRegionConfiguration();
> dataRegionCfg.setPersistenceEnabled(true);
> DataStorageConfiguration dataStorageCfg = new
> DataStorageConfiguration();
> dataStorageCfg.setDefaultDataRegionConfiguration(dataRegionCfg);
> CacheConfiguration ccfg = new
> CacheConfiguration(CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setCacheMode(CacheMode.PARTITIONED);
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setIgniteInstanceName(instanceName);
> cfg.setDiscoverySpi(tcpDiscoverySpi);
> cfg.setDataStorageConfiguration(dataStorageCfg);
> cfg.setCacheConfiguration(ccfg);
> if (!clientMode)
> cfg.setAutoActivationEnabled(true);
> else
> cfg.setClientMode(true);
> return cfg;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8100) jdbc getSchemas method could miss schemas for not started remote caches
[
https://issues.apache.org/jira/browse/IGNITE-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543202#comment-16543202
]
Ilya Kasnacheev commented on IGNITE-8100:
-
https://github.com/apache/ignite/pull/4359
> jdbc getSchemas method could miss schemas for not started remote caches
> ---
>
> Key: IGNITE-8100
> URL: https://issues.apache.org/jira/browse/IGNITE-8100
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Kuznetsov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> On jdbc side we have
> org.apache.ignite.internal.jdbc.thin.JdbcThinDatabaseMetadata#getSchemas(java.lang.String,
> java.lang.String)
> on the server side result is constructed by this:
> {noformat}
> for (String cacheName : ctx.cache().publicCacheNames()) {
> for (GridQueryTypeDescriptor table : ctx.query().types(cacheName)) {
> if (matches(table.schemaName(), schemaPtrn))
>schemas.add(table.schemaName());
> }
> }
> {noformat}
> see
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler#getSchemas
> If we havn't started cache(with a table) on some remote node, we will miss
> that scheme.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543198#comment-16543198 ] Igor Sapego commented on IGNITE-8411: - [~dmagda], I believe so > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown
[ https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543192#comment-16543192 ] ASF GitHub Bot commented on IGNITE-8060: GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/4359 IGNITE-8060 IGNITE-8055 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8060 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4359.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4359 commit 2b9a0f46b7ca37cfd00cac6eb5e0ecda74884ca0 Author: Ilya Kasnacheev Date: 2018-07-13T11:41:39Z IGNITE-8060 Start missing caches before executing operations on all caches. commit e732561681cd6e62978b07f7ab4116797ecda2a3 Author: Ilya Kasnacheev Date: 2018-07-13T11:42:55Z IGNITE-8055 Start missing caches even if "IF EXISTS" not in query. > Sqline creating tables on client nodes works incorrect in case of node's > shutdown > - > > Key: IGNITE-8060 > URL: https://issues.apache.org/jira/browse/IGNITE-8060 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.7 > > Attachments: ignite-76cc6387.log, ignite-a1c90af9.log > > > For reproducing (master branch) > You should start one local server and one local client nodes and follow the > instructions: > 1)Connect to client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 2)Create new table on client node: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > 3)Check that table exists from server node: > !tables > On this step table should be shown in the response. > 4)Drop the client node > 5)Create new client node > 6)Connect to new client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 7)Check that table exists from server node: > !tables > *On this step there is no "city" table in the list.* > 8)Try to drop the table: > DROP TABLE City; > java.sql.SQLException: Table doesn't exist: CITY > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) > at sqlline.Commands.execute(Commands.java:823) > at sqlline.Commands.sql(Commands.java:733) > at sqlline.SqlLine.dispatch(SqlLine.java:795) > at sqlline.SqlLine.begin(SqlLine.java:668) > at sqlline.SqlLine.start(SqlLine.java:373) > at sqlline.SqlLine.main(SqlLine.java:265) > 9)Try to create new table: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > java.sql.SQLException: Table already exists: CITY > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) > at sqlline.Commands.execute(Commands.java:823) > at sqlline.Commands.sql(Commands.java:733) > at sqlline.SqlLine.dispatch(SqlLine.java:795) > at sqlline.SqlLine.begin(SqlLine.java:668) > at sqlline.SqlLine.start(SqlLine.java:373) > at sqlline.SqlLine.main(SqlLine.java:265) > Update: > Exceptions on CREATE/REMOVE are thrown only until first SELECT isn't done. > !tables doen\t work even after SELECT > SELECT works OK. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543191#comment-16543191
]
Andrew Medvedev commented on IGNITE-8957:
-
[~Mmuzaf] AFAIK we fixed the main issue - AssertionError
formatting can bep erfected at any time
Thanks [~ivan.glukos]!
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown
[ https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-8060: --- Assignee: Ilya Kasnacheev > Sqline creating tables on client nodes works incorrect in case of node's > shutdown > - > > Key: IGNITE-8060 > URL: https://issues.apache.org/jira/browse/IGNITE-8060 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.7 > > Attachments: ignite-76cc6387.log, ignite-a1c90af9.log > > > For reproducing (master branch) > You should start one local server and one local client nodes and follow the > instructions: > 1)Connect to client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 2)Create new table on client node: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > 3)Check that table exists from server node: > !tables > On this step table should be shown in the response. > 4)Drop the client node > 5)Create new client node > 6)Connect to new client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 7)Check that table exists from server node: > !tables > *On this step there is no "city" table in the list.* > 8)Try to drop the table: > DROP TABLE City; > java.sql.SQLException: Table doesn't exist: CITY > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) > at sqlline.Commands.execute(Commands.java:823) > at sqlline.Commands.sql(Commands.java:733) > at sqlline.SqlLine.dispatch(SqlLine.java:795) > at sqlline.SqlLine.begin(SqlLine.java:668) > at sqlline.SqlLine.start(SqlLine.java:373) > at sqlline.SqlLine.main(SqlLine.java:265) > 9)Try to create new table: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > java.sql.SQLException: Table already exists: CITY > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) > at sqlline.Commands.execute(Commands.java:823) > at sqlline.Commands.sql(Commands.java:733) > at sqlline.SqlLine.dispatch(SqlLine.java:795) > at sqlline.SqlLine.begin(SqlLine.java:668) > at sqlline.SqlLine.start(SqlLine.java:373) > at sqlline.SqlLine.main(SqlLine.java:265) > Update: > Exceptions on CREATE/REMOVE are thrown only until first SELECT isn't done. > !tables doen\t work even after SELECT > SELECT works OK. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8055) Sqline command !tables works incorrect for client node
[ https://issues.apache.org/jira/browse/IGNITE-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-8055: --- Assignee: Ilya Kasnacheev > Sqline command !tables works incorrect for client node > -- > > Key: IGNITE-8055 > URL: https://issues.apache.org/jira/browse/IGNITE-8055 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Ilya Kasnacheev >Priority: Minor > Fix For: 2.7 > > > For reproducing: > You should start one local server and one local client nodes and follow the > instructions: > 1)Connect to server node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10800 > 2)Create new table on server node: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > 3)Check that table exists from server node: > !tables > On this step table should be shown in the response. > 4)Connect to client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 5)Check that table exists from server node: > !tables > *On this step there is no "city" table in the list.* > Next commands work from client node as well: > SELECT * FROM City > DROP TABLE City > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8100) jdbc getSchemas method could miss schemas for not started remote caches
[
https://issues.apache.org/jira/browse/IGNITE-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-8100:
---
Assignee: Ilya Kasnacheev (was: Pavel Kuznetsov)
> jdbc getSchemas method could miss schemas for not started remote caches
> ---
>
> Key: IGNITE-8100
> URL: https://issues.apache.org/jira/browse/IGNITE-8100
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Kuznetsov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> On jdbc side we have
> org.apache.ignite.internal.jdbc.thin.JdbcThinDatabaseMetadata#getSchemas(java.lang.String,
> java.lang.String)
> on the server side result is constructed by this:
> {noformat}
> for (String cacheName : ctx.cache().publicCacheNames()) {
> for (GridQueryTypeDescriptor table : ctx.query().types(cacheName)) {
> if (matches(table.schemaName(), schemaPtrn))
>schemas.add(table.schemaName());
> }
> }
> {noformat}
> see
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler#getSchemas
> If we havn't started cache(with a table) on some remote node, we will miss
> that scheme.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8738) Improve coordinator change information
[
https://issues.apache.org/jira/browse/IGNITE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543037#comment-16543037
]
ASF GitHub Bot commented on IGNITE-8738:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4198
> Improve coordinator change information
> --
>
> Key: IGNITE-8738
> URL: https://issues.apache.org/jira/browse/IGNITE-8738
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Evgenii Zagumennov
>Priority: Major
> Time Spent: 16h
> Remaining Estimate: 0h
>
> When topology changes and coordinator is also changed, we need to print out
> this alongside with topology information.
> An example of such message:
> {{Coordinator changed [prev=node.tostring(), cur=node.tostr()]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9001) Crush when using SSL on Ignite.NET 2.5.0
[ https://issues.apache.org/jira/browse/IGNITE-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Poltoratskiy updated IGNITE-9001: --- Description: I updated from Ignite.NET 2.4.0 to 2.5.0 and found this bug. Here you can download minimal project that reproduces the bug: [https://yadi.sk/d/j0GqBfDN3Z8xNX] When executing the last line "var ignite = Ignition.Start(igniteConfig)", this exception occurs: [16:06:36,744][SEVERE][main][IgniteKernal] Exception during start processors, node will be stopped and close connections class org.apache.ignite.IgniteException: Java exception occurred [class=java.lang.NullPointerException, message=] at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongLongLongObjectOutLong(Native Method) at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.onStart(PlatformCallbackGateway.java:805) at org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.start(PlatformProcessorImpl.java:249) at org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1738) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:999) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723) at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649) at org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43) at org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:75) [16:06:36,747][SEVERE][main][IgniteKernal] Got exception while starting (will rollback startup routine). class org.apache.ignite.IgniteException: Java exception occurred [class=java.lang.NullPointerException, message=] at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongLongLongObjectOutLong(Native Method) at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.onStart(PlatformCallbackGateway.java:805) at org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.start(PlatformProcessorImpl.java:249) at org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1738) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:999) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723) at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649) at org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43) at org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:75) [16:06:36] Ignite node stopped OK [uptime=00:00:10.602] was: I update form 2.4.0 to 2.5.0 and found this bug. Here you can download minimal project that reproduces the bug: [https://yadi.sk/d/j0GqBfDN3Z8xNX] When executing the last line "var ignite = Ignition.Start(igniteConfig)", this exception occurs: [16:06:36,744][SEVERE][main][IgniteKernal] Exception during start processors, node will be stopped and close connections class org.apache.ignite.IgniteException: Java exception occurred [class=java.lang.NullPointerException, message=] at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongLongLongObjectOutLong(Native Method) at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.onStart(PlatformCallbackGateway.java:805) at org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.start(PlatformProcessorImpl.java:249) at org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1738) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:999) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723) at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649) at org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43) at org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:75) [16:06:36,747][SEVERE][main][IgniteKernal] Got
[jira] [Created] (IGNITE-9001) Crush when using SSL on Ignite.NET 2.5.0
Pavel Poltoratskiy created IGNITE-9001: -- Summary: Crush when using SSL on Ignite.NET 2.5.0 Key: IGNITE-9001 URL: https://issues.apache.org/jira/browse/IGNITE-9001 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Pavel Poltoratskiy I update form 2.4.0 to 2.5.0 and found this bug. Here you can download minimal project that reproduces the bug: [https://yadi.sk/d/j0GqBfDN3Z8xNX] When executing the last line "var ignite = Ignition.Start(igniteConfig)", this exception occurs: [16:06:36,744][SEVERE][main][IgniteKernal] Exception during start processors, node will be stopped and close connections class org.apache.ignite.IgniteException: Java exception occurred [class=java.lang.NullPointerException, message=] at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongLongLongObjectOutLong(Native Method) at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.onStart(PlatformCallbackGateway.java:805) at org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.start(PlatformProcessorImpl.java:249) at org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1738) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:999) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723) at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649) at org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43) at org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:75) [16:06:36,747][SEVERE][main][IgniteKernal] Got exception while starting (will rollback startup routine). class org.apache.ignite.IgniteException: Java exception occurred [class=java.lang.NullPointerException, message=] at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongLongLongObjectOutLong(Native Method) at org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.onStart(PlatformCallbackGateway.java:805) at org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.start(PlatformProcessorImpl.java:249) at org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1738) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:999) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723) at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151) at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649) at org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43) at org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:75) [16:06:36] Ignite node stopped OK [uptime=00:00:10.602] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9000) [Test Failed] IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9000:
-
Description:
IgniteServiceReassignmentTest.testZombieAssignmentsCleanup has flaky failures
on TC:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-4702193284623513465&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=__all_branches__&itemsCount=50
Typical output:
{noformat}
junit.framework.AssertionFailedError
at
org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
{noformat}
Exception that triggers an assertion error:
{noformat}
java.lang.IllegalStateException: Getting affinity for topology version earlier
than affinity is calculated [locNode=TcpDiscoveryNode
[id=dc037d7a-2882-478c-a944-56c66131, addrs=[127.0.0.1],
sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1531485137994, loc=true, ver=2.7.0#19700101-sha1:,
isClient=false], grp=ignite-sys-cache, topVer=AffinityTopologyVersion
[topVer=3, minorTopVer=0], head=AffinityTopologyVersion [topVer=4,
minorTopVer=0], history=[AffinityTopologyVersion [topVer=2, minorTopVer=0],
AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion
[topVer=4, minorTopVer=0]]]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:694)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:594)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:225)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:261)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:252)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:276)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1879)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2066)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
IgniteServiceReassignmentTest.testZombieAssignmentsCleanup has flaky failures.
Typical output:
{noformat}
junit.framework.AssertionFailedError
at
org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
{noformat}
Exception that triggers an assertion error:
{noformat}
java.lang.IllegalStateException: Getting affinity for topology version earlier
than affinity is calculated [locNode=TcpDiscoveryNode
[id=dc037d7a-2882-478c-a944-56c66131, addrs=[127.0.0.1],
sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1531485137994, loc=true, ver=2.7.0#19700101-sha1:,
isClient=false], grp=ignite-sys-cache, topVer=AffinityTopologyVersion
[topVer=3, minorTopVer=0], head=AffinityTopologyVersion [topVer=4,
minorTopVer=0], history=[AffinityTopologyVersion [topVer=2, minorTopVer=0],
AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion
[topVer=4, minorTopVer=0]]]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:694)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:594)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:225)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:261)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:252)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:276)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1879)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2066)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoo
[jira] [Created] (IGNITE-9000) [Test Failed] IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails sometimes.
Pavel Pereslegin created IGNITE-9000:
Summary: [Test Failed]
IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails sometimes.
Key: IGNITE-9000
URL: https://issues.apache.org/jira/browse/IGNITE-9000
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Pavel Pereslegin
IgniteServiceReassignmentTest.testZombieAssignmentsCleanup has flaky failures.
Typical output:
{noformat}
junit.framework.AssertionFailedError
at
org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
{noformat}
Exception that triggers an assertion error:
{noformat}
java.lang.IllegalStateException: Getting affinity for topology version earlier
than affinity is calculated [locNode=TcpDiscoveryNode
[id=dc037d7a-2882-478c-a944-56c66131, addrs=[127.0.0.1],
sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1531485137994, loc=true, ver=2.7.0#19700101-sha1:,
isClient=false], grp=ignite-sys-cache, topVer=AffinityTopologyVersion
[topVer=3, minorTopVer=0], head=AffinityTopologyVersion [topVer=4,
minorTopVer=0], history=[AffinityTopologyVersion [topVer=2, minorTopVer=0],
AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion
[topVer=4, minorTopVer=0]]]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:694)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:594)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:225)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:261)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:252)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:276)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1879)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2066)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8923) Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
[
https://issues.apache.org/jira/browse/IGNITE-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543024#comment-16543024
]
Ilya Murchenko commented on IGNITE-8923:
Added step by step guide for Google Kubernetes Engine Deployment in Markdown
format.
Also please update
[example-kube.xml|https://raw.githubusercontent.com/apache/ignite/master/modules/kubernetes/config/example-kube.xml]
from example-kube.xml file in attachments.
> Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
>
>
> Key: IGNITE-8923
> URL: https://issues.apache.org/jira/browse/IGNITE-8923
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Roman Guseinov
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: config.zip, example-kube.xml,
> google_cloud_engine_deployment.zip, yaml.zip
>
>
> We have such documentation for Microsoft Azure
> [https://apacheignite.readme.io/docs/microsoft-azure-deployment]
> It would be great to publish the same for GCE.
> Here are steps which I used to deploy cluster (stateless, stateful) and web
> console:
> {code:java}
> ## Start Ignite Cluster
> 1. Grant cluster-admin role to current google user (to allow create roles):
> $ kubectl create clusterrolebinding myname2-cluster-admin-binding \
> --clusterrole=cluster-admin \
> --user=
> 2. Create service account and grant permissions:
> $ kubectl create -f sa.yaml
> $ kubectl create -f role.yaml
> $ kubectl create -f rolebind.yaml
> 3. Create a grid service:
> $ kubectl create -f service.yaml
> 4. Deploy Ignite Cluster:
> $ kubectl create -f grid.yaml
> ## Enable Ignite Persistence
> 5. Deploy Ignite StatefulSet with enabled Persistence (instead of step 4).
> $ kubectl create -f grid-pds.yaml
> 6. Connect to the Ignite node and activate cluster:
> $ kubectl exec -it ignite-cluster-0 -- /bin/bash
> $ cd /opt/ignite/apache-ignite-*
> $ ./bin/control.sh --activate
> ## Deploy Web Console:
> 7. Create a volume to keep web console data:
> $ kubectl create -f console-volume.yaml
> 8. Create load balancer to expose HTTP port and make web console available by
> service DNS-name (web-console.default.svc.cluster.local) inside Kuberntes
> enviroment:
> $ kubectl create -f console-service.yaml
> 9. Deploy Web Console:
> $ kubectl create -f console.yaml
> 10. Check external IP:
> $ kubectl get service web-console
> 11. Open Web Console in a web browser and Sign Up.
> 12. Move to User Profile page (Settings > Profile) and copy security token.
> 13. Insert security token into web-agent.yaml (TOKENS environment variable).
> 14. Deploy Web Agent:
> $ kubectl create -f web-agent.yaml
> {code}
> YAML and configs are attached.
> Creating a public Docker-image for Web Agent in progress:
> https://issues.apache.org/jira/browse/IGNITE-8526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8923) Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
[
https://issues.apache.org/jira/browse/IGNITE-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Murchenko updated IGNITE-8923:
---
Attachment: google_cloud_engine_deployment.zip
> Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
>
>
> Key: IGNITE-8923
> URL: https://issues.apache.org/jira/browse/IGNITE-8923
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Roman Guseinov
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: config.zip, example-kube.xml,
> google_cloud_engine_deployment.zip, yaml.zip
>
>
> We have such documentation for Microsoft Azure
> [https://apacheignite.readme.io/docs/microsoft-azure-deployment]
> It would be great to publish the same for GCE.
> Here are steps which I used to deploy cluster (stateless, stateful) and web
> console:
> {code:java}
> ## Start Ignite Cluster
> 1. Grant cluster-admin role to current google user (to allow create roles):
> $ kubectl create clusterrolebinding myname2-cluster-admin-binding \
> --clusterrole=cluster-admin \
> --user=
> 2. Create service account and grant permissions:
> $ kubectl create -f sa.yaml
> $ kubectl create -f role.yaml
> $ kubectl create -f rolebind.yaml
> 3. Create a grid service:
> $ kubectl create -f service.yaml
> 4. Deploy Ignite Cluster:
> $ kubectl create -f grid.yaml
> ## Enable Ignite Persistence
> 5. Deploy Ignite StatefulSet with enabled Persistence (instead of step 4).
> $ kubectl create -f grid-pds.yaml
> 6. Connect to the Ignite node and activate cluster:
> $ kubectl exec -it ignite-cluster-0 -- /bin/bash
> $ cd /opt/ignite/apache-ignite-*
> $ ./bin/control.sh --activate
> ## Deploy Web Console:
> 7. Create a volume to keep web console data:
> $ kubectl create -f console-volume.yaml
> 8. Create load balancer to expose HTTP port and make web console available by
> service DNS-name (web-console.default.svc.cluster.local) inside Kuberntes
> enviroment:
> $ kubectl create -f console-service.yaml
> 9. Deploy Web Console:
> $ kubectl create -f console.yaml
> 10. Check external IP:
> $ kubectl get service web-console
> 11. Open Web Console in a web browser and Sign Up.
> 12. Move to User Profile page (Settings > Profile) and copy security token.
> 13. Insert security token into web-agent.yaml (TOKENS environment variable).
> 14. Deploy Web Agent:
> $ kubectl create -f web-agent.yaml
> {code}
> YAML and configs are attached.
> Creating a public Docker-image for Web Agent in progress:
> https://issues.apache.org/jira/browse/IGNITE-8526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8923) Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
[
https://issues.apache.org/jira/browse/IGNITE-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Murchenko updated IGNITE-8923:
---
Attachment: example-kube.xml
> Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
>
>
> Key: IGNITE-8923
> URL: https://issues.apache.org/jira/browse/IGNITE-8923
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Roman Guseinov
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: config.zip, example-kube.xml,
> google_cloud_engine_deployment.zip, yaml.zip
>
>
> We have such documentation for Microsoft Azure
> [https://apacheignite.readme.io/docs/microsoft-azure-deployment]
> It would be great to publish the same for GCE.
> Here are steps which I used to deploy cluster (stateless, stateful) and web
> console:
> {code:java}
> ## Start Ignite Cluster
> 1. Grant cluster-admin role to current google user (to allow create roles):
> $ kubectl create clusterrolebinding myname2-cluster-admin-binding \
> --clusterrole=cluster-admin \
> --user=
> 2. Create service account and grant permissions:
> $ kubectl create -f sa.yaml
> $ kubectl create -f role.yaml
> $ kubectl create -f rolebind.yaml
> 3. Create a grid service:
> $ kubectl create -f service.yaml
> 4. Deploy Ignite Cluster:
> $ kubectl create -f grid.yaml
> ## Enable Ignite Persistence
> 5. Deploy Ignite StatefulSet with enabled Persistence (instead of step 4).
> $ kubectl create -f grid-pds.yaml
> 6. Connect to the Ignite node and activate cluster:
> $ kubectl exec -it ignite-cluster-0 -- /bin/bash
> $ cd /opt/ignite/apache-ignite-*
> $ ./bin/control.sh --activate
> ## Deploy Web Console:
> 7. Create a volume to keep web console data:
> $ kubectl create -f console-volume.yaml
> 8. Create load balancer to expose HTTP port and make web console available by
> service DNS-name (web-console.default.svc.cluster.local) inside Kuberntes
> enviroment:
> $ kubectl create -f console-service.yaml
> 9. Deploy Web Console:
> $ kubectl create -f console.yaml
> 10. Check external IP:
> $ kubectl get service web-console
> 11. Open Web Console in a web browser and Sign Up.
> 12. Move to User Profile page (Settings > Profile) and copy security token.
> 13. Insert security token into web-agent.yaml (TOKENS environment variable).
> 14. Deploy Web Agent:
> $ kubectl create -f web-agent.yaml
> {code}
> YAML and configs are attached.
> Creating a public Docker-image for Web Agent in progress:
> https://issues.apache.org/jira/browse/IGNITE-8526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8859) Open upper Java verison bounds
[ https://issues.apache.org/jira/browse/IGNITE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543012#comment-16543012 ] Peter Ivanov commented on IGNITE-8859: -- Everything looks perfect! > Open upper Java verison bounds > -- > > Key: IGNITE-8859 > URL: https://issues.apache.org/jira/browse/IGNITE-8859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > JDK is going to be release twice a year and it will be always an issue for > users to start Ignite on newer Java version as we have explicit bounds. > Ignite should not disallow starting in latest JDK, but show warning that it > wasn't tested against running version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8998) Client hangs after merge exchange
[ https://issues.apache.org/jira/browse/IGNITE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542994#comment-16542994 ] ASF GitHub Bot commented on IGNITE-8998: GitHub user akalash opened a pull request: https://github.com/apache/ignite/pull/4358 IGNITE-8998 Send reconnect exception without partitions You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8998 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4358.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4358 commit 147e8c52e1aab3e54b14c9dbd168d228a1282fb8 Author: Anton Kalashnikov Date: 2018-07-13T12:36:14Z IGNITE-8998 Send reconnect exception without partitions > Client hangs after merge exchange > - > > Key: IGNITE-8998 > URL: https://issues.apache.org/jira/browse/IGNITE-8998 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > > Reproduce by CacheExchangeMergeTest#testConcurrentStartServersAndClients -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8957:
---
Fix Version/s: 2.7
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542975#comment-16542975
]
Maxim Muzafarov commented on IGNITE-8957:
-
[~ivan.glukos], [~sergey-chugunov], [~agoncharuk]
Folks, can you clarify why we've merged this PR? What was the point?
A lot of questions still exists for this issue.
They haven't been answered or investigated.
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8490) Web Console: Update to AngularJS 1.7.x
[ https://issues.apache.org/jira/browse/IGNITE-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8490: Assignee: Alexey Kuznetsov (was: Ilya Borisov) > Web Console: Update to AngularJS 1.7.x > -- > > Key: IGNITE-8490 > URL: https://issues.apache.org/jira/browse/IGNITE-8490 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > AngularJS 1.7.0 was released. > We can try to upgrade. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8490) Web Console: Update to AngularJS 1.7.x
[ https://issues.apache.org/jira/browse/IGNITE-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov resolved IGNITE-8490. -- Resolution: Duplicate > Web Console: Update to AngularJS 1.7.x > -- > > Key: IGNITE-8490 > URL: https://issues.apache.org/jira/browse/IGNITE-8490 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Kuznetsov >Assignee: Ilya Borisov >Priority: Major > > AngularJS 1.7.0 was released. > We can try to upgrade. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8990) Web console: unexpected 'Unsaved changes' warning
[ https://issues.apache.org/jira/browse/IGNITE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8990: Assignee: Vasiliy Sisko (was: Ilya Borisov) > Web console: unexpected 'Unsaved changes' warning > - > > Key: IGNITE-8990 > URL: https://issues.apache.org/jira/browse/IGNITE-8990 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Major > Attachments: screenshot-1.png > > > My steps were: > # Create a new cluster configuration > # Change Client connector configuration > # Save & Download > # Change the cluster name > # Save & Download > # Go to the Monitoring > I getting the warning about unsaved changes > !screenshot-1.png! > The same issue if I select just Save w\o download. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8990) Web console: unexpected 'Unsaved changes' warning
[ https://issues.apache.org/jira/browse/IGNITE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542952#comment-16542952 ] Ilya Borisov commented on IGNITE-8990: -- The issue was caused by improper listener lifecycle in fakeUiCanExit directive. I've fixed it and covered with both E2E and unit tests. [~vsisko] please test. > Web console: unexpected 'Unsaved changes' warning > - > > Key: IGNITE-8990 > URL: https://issues.apache.org/jira/browse/IGNITE-8990 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Ilya Borisov >Priority: Major > Attachments: screenshot-1.png > > > My steps were: > # Create a new cluster configuration > # Change Client connector configuration > # Save & Download > # Change the cluster name > # Save & Download > # Go to the Monitoring > I getting the warning about unsaved changes > !screenshot-1.png! > The same issue if I select just Save w\o download. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542879#comment-16542879
]
Ivan Rakov commented on IGNITE-8957:
Merged to master.
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542878#comment-16542878
]
ASF GitHub Bot commented on IGNITE-8957:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4334
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8999) WebConsole should correct parsing trace error messages introduced by #8971
[ https://issues.apache.org/jira/browse/IGNITE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-8999: - Assignee: Vasiliy Sisko > WebConsole should correct parsing trace error messages introduced by #8971 > -- > > Key: IGNITE-8999 > URL: https://issues.apache.org/jira/browse/IGNITE-8999 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Assignee: Vasiliy Sisko >Priority: Major > > https://issues.apache.org/jira/browse/IGNITE-8971 added trace to error > messages, change to WC parsing is needed, see comments there -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8971) GridRestProcessor should propagate error message
[ https://issues.apache.org/jira/browse/IGNITE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542837#comment-16542837 ] Andrew Medvedev commented on IGNITE-8971: - [~kuaw26] I created https://issues.apache.org/jira/browse/IGNITE-8999 for WC and set this for "patch available" > GridRestProcessor should propagate error message > > > Key: IGNITE-8971 > URL: https://issues.apache.org/jira/browse/IGNITE-8971 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Assignee: Andrew Medvedev >Priority: Major > > GridRestProcessor should propagate error message (stack trace) for handling > disk full error messages -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8999) WebConsole should correct parsing trace error messages introduced by #8971
[ https://issues.apache.org/jira/browse/IGNITE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Medvedev updated IGNITE-8999: Affects Version/s: 2.5 Description: https://issues.apache.org/jira/browse/IGNITE-8971 added trace to error messages, change to WC parsing is needed, see comments there > WebConsole should correct parsing trace error messages introduced by #8971 > -- > > Key: IGNITE-8999 > URL: https://issues.apache.org/jira/browse/IGNITE-8999 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Priority: Major > > https://issues.apache.org/jira/browse/IGNITE-8971 added trace to error > messages, change to WC parsing is needed, see comments there -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8999) WebConsole should correct parsing trace error messages introduced by #8971
Andrew Medvedev created IGNITE-8999: --- Summary: WebConsole should correct parsing trace error messages introduced by #8971 Key: IGNITE-8999 URL: https://issues.apache.org/jira/browse/IGNITE-8999 Project: Ignite Issue Type: Bug Reporter: Andrew Medvedev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8859) Open upper Java verison bounds
[ https://issues.apache.org/jira/browse/IGNITE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542768#comment-16542768 ] Dmitry Karachentsev commented on IGNITE-8859: - [~vveider] Thanks for review! I've fixed one note and answered on second one, please check. > Open upper Java verison bounds > -- > > Key: IGNITE-8859 > URL: https://issues.apache.org/jira/browse/IGNITE-8859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > JDK is going to be release twice a year and it will be always an issue for > users to start Ignite on newer Java version as we have explicit bounds. > Ignite should not disallow starting in latest JDK, but show warning that it > wasn't tested against running version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1393) [Test] AssertionError when stop node executing transaction - GridCacheStopSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542757#comment-16542757
]
ASF GitHub Bot commented on IGNITE-1393:
Github user SomeFire closed the pull request at:
https://github.com/apache/ignite/pull/1596
> [Test] AssertionError when stop node executing transaction -
> GridCacheStopSelfTest
> ---
>
> Key: IGNITE-1393
> URL: https://issues.apache.org/jira/browse/IGNITE-1393
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Semen Boikov
>Assignee: Ryabov Dmitrii
>Priority: Major
> Labels: Muted_test
> Fix For: 2.1
>
>
> I fixed GridCacheStopSelfTest which was disabled for long time, now it fails
> because of asserts:
> {noformat}
> [10:53:02,362][ERROR][async-runner-1][GridNearTxLocal] Heuristic transaction
> failure.
> class
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
> Failed to locally write to cache (all transaction entries will be
> invalidated, however there was a window when entries for this transaction
> were visible to others): GridNearTxLocal [nearLocallyMapped=false,
> colocatedLocallyMapped=true, hasRemoteLocks=false,
> mappings=[009f5238-db3d-426f-b787-9a4a156e8000], super=GridDhtTxLocalAdapter
> [dhtThreadId=101, needsCompletedVers=false, nearNodes=[], dhtNodes=[],
> explicitLock=false, super=IgniteTxLocalAdapter [txMap={IgniteTxKey
> [key=KeyCacheObjectImpl [val=22, hasValBytes=true], cacheId=1]=IgniteTxEntry
> [key=KeyCacheObjectImpl [val=22, hasValBytes=true], cacheId=1,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=22, hasValBytes=true],
> cacheId=1], val=[op=CREATE, val=UserCacheObjectImpl [val=22,
> hasValBytes=true]], prevVal=[op=CREATE, val=UserCacheObjectImpl [val=22,
> hasValBytes=true]], entryProcessorsCol=null, entryProcessorCalcVal=null,
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=GridCacheVersion [topVer=53261582, nodeOrderDrId=1,
> globalTime=1441781582327, order=1441781581691], filters=[],
> filtersPassed=false, filtersSet=true, entry=GridDhtColocatedCacheEntry
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition [id=22,
> mapPubSize=1, rmvQueue=GridCircularBuffer [sizeMask=31, idxGen=0],
> state=OWNING, reservations=0, empty=false, createTime=09/09/2015 10:53:02,
> mapPubSize=1], super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [val=22, hasValBytes=true], val=CacheObjectImpl
> [val=22, hasValBytes=true], startVer=1441781581658, ver=GridCacheVersion
> [topVer=53261582, nodeOrderDrId=1, globalTime=1441781582327,
> order=1441781581691], hash=2018242870, extras=null, flags=2,
> prepared=false, locked=true, nodeId=009f5238-db3d-426f-b787-9a4a156e8000,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> xidVer=GridCacheVersion [topVer=53261582, nodeOrderDrId=1,
> globalTime=1441781582217, order=1441781581591]]}, completedBase=null,
> sndTransformedVals=false, super=IgniteTxAdapter [xidVer=GridCacheVersion
> [topVer=53261582, nodeOrderDrId=1, globalTime=1441781582217,
> order=1441781581591], writeVer=GridCacheVersion [topVer=53261582,
> nodeOrderDrId=1, globalTime=1441781582327, order=1441781581691],
> implicit=false, implicitSingle=false, loc=true, threadId=101,
> startTime=1441781582212, nodeId=009f5238-db3d-426f-b787-9a4a156e8000,
> startVer=GridCacheVersion [topVer=53261582, nodeOrderDrId=1,
> globalTime=1441781582218, order=1441781581611], endVer=GridCacheVersion
> [topVer=53261582, nodeOrderDrId=1, globalTime=1441781582336,
> order=1441781581738], isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
> timeout=0, sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion
> [topVer=53261582, nodeOrderDrId=1, globalTime=1441781582217,
> order=1441781581591], finalizing=NONE, preparing=false, state=COMMITTED,
> timedOut=false, topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0],
> duration=138ms, onePhaseCommit=true], size=1]]]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:1036)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.finish(GridNearTxLocal.java:654)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$3.apply(GridNearTxLocal.java:749)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$3.apply(GridNearTxLocal.java:741)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:262)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.liste
[jira] [Commented] (IGNITE-8985) Node segmented itself after connRecoveryTimeout
[ https://issues.apache.org/jira/browse/IGNITE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542723#comment-16542723 ] Dmitry Karachentsev commented on IGNITE-8985: - Here are few things that caused this behavior. 1. One node was killed. 2. Previous for it was unable to connect and tried to go to next of the killed. 3. As we have 60 secs of failure detection timeout, then connection check frequency will be 60 / 3 = 20 secs. So it means that previous node will be treated as failed if there was no message during 20 secs. In the other hand, recovery timeout is 10 secs. 4. Another case is that each node has two loopback addresses, when one of them 172.17.0.1:47500 is not determined as localhost and was checked. In other words node checked connection to itself. To fix it should be applied loopback check from IGNITE-8683 ticket and add IGNITE-8944 to mark node as failed faster. > Node segmented itself after connRecoveryTimeout > --- > > Key: IGNITE-8985 > URL: https://issues.apache.org/jira/browse/IGNITE-8985 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Dmitry Karachentsev >Priority: Major > Attachments: Archive.zip > > > I can see the following message in logs: > [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect > to next nodes in a ring, it seems local node is experiencing connectivity > issues. Segmenting local node to avoid case when one node fails a big part of > cluster. To disable that behavior set > TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. > [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1] > [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node > SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, > addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, > lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, > order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, > ver=2.4.7#20180710-sha1:a48ae923, isClient=false] > I have failure detection time out 60_000 and during the test I had GC > <25secs, so I don't expect that node should be segmented. > > Logs are attached. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8998) Client hangs after merge exchange
Anton Kalashnikov created IGNITE-8998: - Summary: Client hangs after merge exchange Key: IGNITE-8998 URL: https://issues.apache.org/jira/browse/IGNITE-8998 Project: Ignite Issue Type: Test Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Reproduce by CacheExchangeMergeTest#testConcurrentStartServersAndClients -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8073) Cache read metric is calculated incorrectly in atomic cache.
[ https://issues.apache.org/jira/browse/IGNITE-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16525254#comment-16525254 ] Alexey Kuznetsov edited comment on IGNITE-8073 at 7/13/18 8:11 AM: --- [~dpavlov] Hi! I think its rather important fix : cache read metric calculated incorrectly. Could you plz review! was (Author: alexey kuznetsov): [~dpavlov] Hi! I think its rather important fix : cache read metric calculated incorrectly. Could you plz review/ > Cache read metric is calculated incorrectly in atomic cache. > > > Key: IGNITE-8073 > URL: https://issues.apache.org/jira/browse/IGNITE-8073 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: GridCacheNearAtomicMetricsSelfTest.java > > > In atomic cache with near enabled we perform put and remove operations. > After it, get operation is called. > Now, cache 'read' metric is calculated incorrectly, because it takes into > account near cache entry. > Reproducer is attached. > Note that remove operation untracks 'reader' node from dht cache entry, but > near cache entry still exists. The following test checks it : > GridCacheAtomicNearCacheSelfTest#checkNearCache, see checkReaderRemove() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8997) Web Console: Need to remove all the icons from all modal windows
[ https://issues.apache.org/jira/browse/IGNITE-8997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8997: - Summary: Web Console: Need to remove all the icons from all modal windows (was: Web Console: Need to destroy all the icons from all modal windows) > Web Console: Need to remove all the icons from all modal windows > > > Key: IGNITE-8997 > URL: https://issues.apache.org/jira/browse/IGNITE-8997 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: icon.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8997) Web Console: Need to remove all the icons from all modal windows
[ https://issues.apache.org/jira/browse/IGNITE-8997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8997: Assignee: Alexander Kalinin (was: Alexey Kuznetsov) > Web Console: Need to remove all the icons from all modal windows > > > Key: IGNITE-8997 > URL: https://issues.apache.org/jira/browse/IGNITE-8997 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexander Kalinin >Priority: Major > Attachments: icon.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8997) Web Console: Need to destroy all the icons from all modal windows
Vica Abramova created IGNITE-8997: - Summary: Web Console: Need to destroy all the icons from all modal windows Key: IGNITE-8997 URL: https://issues.apache.org/jira/browse/IGNITE-8997 Project: Ignite Issue Type: Improvement Components: UI, wizards Reporter: Vica Abramova Assignee: Alexey Kuznetsov Attachments: icon.png -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8994) Configuring dedicated volumes for WAL and data with Kuberenetes
[ https://issues.apache.org/jira/browse/IGNITE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Murchenko reassigned IGNITE-8994: -- Assignee: Ilya Murchenko > Configuring dedicated volumes for WAL and data with Kuberenetes > --- > > Key: IGNITE-8994 > URL: https://issues.apache.org/jira/browse/IGNITE-8994 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.7 > > > The current StatefulSet documentation request only one persistent volume for > both WAL and data/index files: > https://apacheignite.readme.io/docs/stateful-deployment#section-statefulset-deployment > However, according to Ignite performance guide the WAL has to be located on a > dedicated volume: > https://apacheignite.readme.io/docs/durable-memory-tuning#section-separate-disk-device-for-wal > Provide StatefulSet configuration that shows how to request separate volumes > for the WAL and data/index files. If needed, provide YAML configs for > StorageClass and volume claims. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8993) Configuring sticky LoadBalancer for Ignite Service with Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Murchenko reassigned IGNITE-8993: -- Assignee: Ilya Murchenko > Configuring sticky LoadBalancer for Ignite Service with Kubernetes > -- > > Key: IGNITE-8993 > URL: https://issues.apache.org/jira/browse/IGNITE-8993 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.7 > > > Ignite service used for Ignite pods auto-discovery and access to the cluster > from remote applications is deployed as LoadBalancer: > https://apacheignite.readme.io/docs/ignite-service > This might lead to problems when a stateful session is needed between an app > and the cluster. For instance, Ignite JDBC driver preserves the state of an > opened connection meaning that once LoadBalancer connects the driver to an > Ignite pod, all the queries have to be redirected to that Ignite pod only > (unless the pod is down). > We need to show how to configure a sticky LoadBalancer that will assign a > client connection to a specific pod and won't change it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8923) Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
[
https://issues.apache.org/jira/browse/IGNITE-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Murchenko reassigned IGNITE-8923:
--
Assignee: Ilya Murchenko
> Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
>
>
> Key: IGNITE-8923
> URL: https://issues.apache.org/jira/browse/IGNITE-8923
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Roman Guseinov
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: config.zip, yaml.zip
>
>
> We have such documentation for Microsoft Azure
> [https://apacheignite.readme.io/docs/microsoft-azure-deployment]
> It would be great to publish the same for GCE.
> Here are steps which I used to deploy cluster (stateless, stateful) and web
> console:
> {code:java}
> ## Start Ignite Cluster
> 1. Grant cluster-admin role to current google user (to allow create roles):
> $ kubectl create clusterrolebinding myname2-cluster-admin-binding \
> --clusterrole=cluster-admin \
> --user=
> 2. Create service account and grant permissions:
> $ kubectl create -f sa.yaml
> $ kubectl create -f role.yaml
> $ kubectl create -f rolebind.yaml
> 3. Create a grid service:
> $ kubectl create -f service.yaml
> 4. Deploy Ignite Cluster:
> $ kubectl create -f grid.yaml
> ## Enable Ignite Persistence
> 5. Deploy Ignite StatefulSet with enabled Persistence (instead of step 4).
> $ kubectl create -f grid-pds.yaml
> 6. Connect to the Ignite node and activate cluster:
> $ kubectl exec -it ignite-cluster-0 -- /bin/bash
> $ cd /opt/ignite/apache-ignite-*
> $ ./bin/control.sh --activate
> ## Deploy Web Console:
> 7. Create a volume to keep web console data:
> $ kubectl create -f console-volume.yaml
> 8. Create load balancer to expose HTTP port and make web console available by
> service DNS-name (web-console.default.svc.cluster.local) inside Kuberntes
> enviroment:
> $ kubectl create -f console-service.yaml
> 9. Deploy Web Console:
> $ kubectl create -f console.yaml
> 10. Check external IP:
> $ kubectl get service web-console
> 11. Open Web Console in a web browser and Sign Up.
> 12. Move to User Profile page (Settings > Profile) and copy security token.
> 13. Insert security token into web-agent.yaml (TOKENS environment variable).
> 14. Deploy Web Agent:
> $ kubectl create -f web-agent.yaml
> {code}
> YAML and configs are attached.
> Creating a public Docker-image for Web Agent in progress:
> https://issues.apache.org/jira/browse/IGNITE-8526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8761) WAL fsync at rollover should be asynchronous in LOG_ONLY and BACKGROUND modes
[
https://issues.apache.org/jira/browse/IGNITE-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542647#comment-16542647
]
ASF GitHub Bot commented on IGNITE-8761:
GitHub user vldpyatkov opened a pull request:
https://github.com/apache/ignite/pull/4356
IGNITE-8761 WAL fsync at rollover should be asynchronous in LOG_ONLY …
…and BACKGROUND modes
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8761-2
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4356.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4356
commit 2cd5d6c91a008291731a6210f4f4afa9813e943e
Author: vd-pyatkov
Date: 2018-07-10T14:54:30Z
IGNITE-8761 WAL fsync at rollover should be asynchronous in LOG_ONLY and
BACKGROUND modes
> WAL fsync at rollover should be asynchronous in LOG_ONLY and BACKGROUND modes
> -
>
> Key: IGNITE-8761
> URL: https://issues.apache.org/jira/browse/IGNITE-8761
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Ivan Rakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.7
>
>
> Transactions may periodically hang for a few seconds in LOG_ONLY or
> BACKGROUND persistent modes. Thread dumps show that threads are hanging on
> syncing previous WAL segment during rollover:
> {noformat}
> java.lang.Thread.State: RUNNABLE
>at java.nio.MappedByteBuffer.force0(MappedByteBuffer.java:-1)
>at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:203)
>at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.close(FileWriteAheadLogManager.java:2843)
>at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$600(FileWriteAheadLogManager.java:2483)
>at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.rollOver(FileWriteAheadLogManager.java:1094)
> {noformat}
> Waiting for this fsync is not necessary action to ensure crash recovery
> guarantees. Instead of this, we should just perform fsyncs asychronously and
> ensure that they are completed prior to next checkpoint start.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8995) FailureHandler executed on error in ScanQuery's IgniteBiPredicate
[
https://issues.apache.org/jira/browse/IGNITE-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542629#comment-16542629
]
Stanilovsky Evgeny commented on IGNITE-8995:
one comment from me (take a look into github), all other lgfm, thanks !
> FailureHandler executed on error in ScanQuery's IgniteBiPredicate
> -
>
> Key: IGNITE-8995
> URL: https://issues.apache.org/jira/browse/IGNITE-8995
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitriy Gladkikh
>Assignee: Dmitriy Gladkikh
>Priority: Major
>
> This code demonstrates this behavior:
> {code:java}
> import java.util.Collections;
> import javax.cache.Cache;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObject;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.query.QueryCursor;
> import org.apache.ignite.cache.query.ScanQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.lang.IgniteBiPredicate;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> /**
> * -ea -DIGNITE_QUIET=false
> */
> public class ScanQueryIgniteBiPredicateWithError {
> private static final String CACHE_NAME = "test_cache_name";
> public static void main(String[] args) {
> try (Ignite igniteServer = Ignition.start(getCfg("node_server",
> false));
> Ignite igniteClient = Ignition.start(getCfg("node_client",
> true)))
> {
> IgniteCache cache =
> igniteClient.cache(CACHE_NAME);
> cache.put(1,
> igniteClient.binary().builder("test_type").setField("field_0",
> "field_0_val").build());
> try (QueryCursor> cursor =
> cache.withKeepBinary().query(new ScanQuery<>(
> new IgniteBiPredicate() {
> @Override public boolean apply(Integer key, BinaryObject
> value) {
> throw new AssertionError(); // Error.
> //return value.field(null) != null; // Error.
> //return true; // Ok.
> }
> })))
> {
> for (Cache.Entry entry : cursor)
> // Without error in IgniteBiPredicate:
> // Key = 1, Val = test_type [idHash=2024711353,
> hash=394028655, field_0=val_0]
> System.out.printf("Key = %s, Val = %s%n", entry.getKey(),
> entry.getValue());
> }
> }
> }
> /**
> * @param instanceName Ignite instance name.
> * @param clientMode Client mode.
> * @return Ignite configuration.
> */
> private static IgniteConfiguration getCfg(String instanceName, boolean
> clientMode) {
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();
> tcpDiscoverySpi.setIpFinder(ipFinder);
> DataRegionConfiguration dataRegionCfg = new DataRegionConfiguration();
> dataRegionCfg.setPersistenceEnabled(true);
> DataStorageConfiguration dataStorageCfg = new
> DataStorageConfiguration();
> dataStorageCfg.setDefaultDataRegionConfiguration(dataRegionCfg);
> CacheConfiguration ccfg = new
> CacheConfiguration(CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setCacheMode(CacheMode.PARTITIONED);
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setIgniteInstanceName(instanceName);
> cfg.setDiscoverySpi(tcpDiscoverySpi);
> cfg.setDataStorageConfiguration(dataStorageCfg);
> cfg.setCacheConfiguration(ccfg);
> if (!clientMode)
> cfg.setAutoActivationEnabled(true);
> else
> cfg.setClientMode(true);
> return cfg;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
