[jira] [Commented] (IGNITE-13123) Move control.sh to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-13123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148323#comment-17148323 ] Kirill Tkalenko commented on IGNITE-13123: -- [~agoncharuk] Please make review. > Move control.sh to a separate module > > > Key: IGNITE-13123 > URL: https://issues.apache.org/jira/browse/IGNITE-13123 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Move [1] and its associated classes to a separate "ignite-control-utility" > module. > [1] - org.apache.ignite.internal.commandline.CommandHandler -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13123) Move control.sh to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-13123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148318#comment-17148318 ] Kirill Tkalenko edited comment on IGNITE-13123 at 6/30/20, 5:31 AM: https://ci.ignite.apache.org/viewLog.html?buildId=5426362; https://ci.ignite.apache.org/viewLog.html?buildId=5427990; was (Author: ktkale...@gridgain.com): [https://ci.ignite.apache.org/viewLog.html?buildId=5426362; ] [https://ci.ignite.apache.org/viewLog.html?buildId=5427990;] [|https://ci.ignite.apache.org/viewLog.html?buildId=5426362;] > Move control.sh to a separate module > > > Key: IGNITE-13123 > URL: https://issues.apache.org/jira/browse/IGNITE-13123 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Move [1] and its associated classes to a separate "ignite-control-utility" > module. > [1] - org.apache.ignite.internal.commandline.CommandHandler -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13123) Move control.sh to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-13123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148318#comment-17148318 ] Kirill Tkalenko edited comment on IGNITE-13123 at 6/30/20, 5:31 AM: [https://ci.ignite.apache.org/viewLog.html?buildId=5426362; ] [https://ci.ignite.apache.org/viewLog.html?buildId=5427990;] [|https://ci.ignite.apache.org/viewLog.html?buildId=5426362;] was (Author: ktkale...@gridgain.com): [https://ci.ignite.apache.org/viewLog.html?buildId=5426362;] > Move control.sh to a separate module > > > Key: IGNITE-13123 > URL: https://issues.apache.org/jira/browse/IGNITE-13123 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Move [1] and its associated classes to a separate "ignite-control-utility" > module. > [1] - org.apache.ignite.internal.commandline.CommandHandler -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13123) Move control.sh to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-13123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148318#comment-17148318 ] Kirill Tkalenko commented on IGNITE-13123: -- [https://ci.ignite.apache.org/viewLog.html?buildId=5426362;] > Move control.sh to a separate module > > > Key: IGNITE-13123 > URL: https://issues.apache.org/jira/browse/IGNITE-13123 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Move [1] and its associated classes to a separate "ignite-control-utility" > module. > [1] - org.apache.ignite.internal.commandline.CommandHandler -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13196) Greater than Where condition on secondary column in Primary key does not work when also filtering on primary column in primary key
Andrew created IGNITE-13196:
---
Summary: Greater than Where condition on secondary column in
Primary key does not work when also filtering on primary column in primary key
Key: IGNITE-13196
URL: https://issues.apache.org/jira/browse/IGNITE-13196
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.8.1
Environment: Windows 10
Reporter: Andrew
Using the Java Thin Client when I try to use the SQL API, I have an issue where
I am unable to query by both columns in a composite primary key when one of
those conditions is a greater than condition.
For example if I create a table: "Create Table If Not Exists test (foo varchar,
bar int, biz int, PRIMARY KEY( foo, bar))
And then insert the following data: INSERT INTO test VALUES ('key1', 1, 2),
('key2', 2, 3 )
The following queries return the same result (('key2', 2, 3)):
"Select * from test where foo = 'key2'"
"Select * from test where bar > 1"
However the following query returns no data:
"Select * from test where foo = 'key2' and bar > 1"
For reference each query is executed using: igniteClient.query( new
SqlFieldsQuery( Query) ).getAll()
Could you help explain why this is happening and if there are any workarounds?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148083#comment-17148083
]
Aleksey Kurinov commented on IGNITE-13040:
--
[~agoncharuk] , pull request is https://github.com/apache/ignite/pull/7977
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Improvement
> Environment:
>Reporter: Vladimir Steshin
>Assignee: Aleksey Kurinov
>Priority: Trivial
> Labels: newbie
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscoverySpi.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
[
https://issues.apache.org/jira/browse/IGNITE-13194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148078#comment-17148078
]
Ignite TC Bot commented on IGNITE-13194:
{panel:title=Branch: [pull/7969/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7969/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=e7534fff271-3894fd1b-8172-41e9-9fe8-844c72777061, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=12f72d17-04b6-4281-8877-718db9b63902, topVer=0, nodeId8=12f72d17,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593432094074]],
val2=AffinityTopologyVersion [topVer=-6239499851066511036, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=737f25d8-4a41-4b37-81a0-8639cb9d504c, topVer=0,
nodeId8=d0f36d0d, msg=, type=NODE_JOINED, tstamp=1593432094074],
val2=AffinityTopologyVersion [topVer=8837420793991566154, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=737f25d8-4a41-4b37-81a0-8639cb9d504c, topVer=0,
nodeId8=d0f36d0d, msg=, type=NODE_JOINED, tstamp=1593432094074],
val2=AffinityTopologyVersion [topVer=8837420793991566154, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=e7534fff271-3894fd1b-8172-41e9-9fe8-844c72777061, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=12f72d17-04b6-4281-8877-718db9b63902, topVer=0, nodeId8=12f72d17,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593432094074]],
val2=AffinityTopologyVersion [topVer=-6239499851066511036, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=383873aa-7f2e-4f87-9241-2114b1ce4c42, topVer=0,
nodeId8=d12741d9, msg=, type=NODE_JOINED, tstamp=1593431836269],
val2=AffinityTopologyVersion [topVer=7262422483954622305, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=383873aa-7f2e-4f87-9241-2114b1ce4c42, topVer=0,
nodeId8=d12741d9, msg=, type=NODE_JOINED, tstamp=1593431836269],
val2=AffinityTopologyVersion [topVer=7262422483954622305, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=542c9fff271-bf04e62e-f2ad-45f3-a8ae-7e0c64f04a7f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=88961155-e1f0-478e-bf47-c5d11e4e2c85, topVer=0, nodeId8=88961155,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593431836269]],
val2=AffinityTopologyVersion [topVer=-4510207700847366825, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=542c9fff271-bf04e62e-f2ad-45f3-a8ae-7e0c64f04a7f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=88961155-e1f0-478e-bf47-c5d11e4e2c85, topVer=0, nodeId8=88961155,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593431836269]],
val2=AffinityTopologyVersion [topVer=-4510207700847366825, minorTopVer=0]]] -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5425238buildTypeId=IgniteTests24Java8_RunAll]
> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Test
> {code:java}
>
[jira] [Commented] (IGNITE-13123) Move control.sh to a separate module
[
https://issues.apache.org/jira/browse/IGNITE-13123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148056#comment-17148056
]
Ignite TC Bot commented on IGNITE-13123:
{panel:title=Branch: [pull/7910/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5425567]]
{panel}
{panel:title=Branch: [pull/7910/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b10db200-4ede-4f6b-939b-a83d7d80cc0f, topVer=0,
nodeId8=f37905ac, msg=, type=NODE_JOINED, tstamp=1593448667445],
val2=AffinityTopologyVersion [topVer=7178104327855210152, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b10db200-4ede-4f6b-939b-a83d7d80cc0f, topVer=0,
nodeId8=f37905ac, msg=, type=NODE_JOINED, tstamp=1593448667445],
val2=AffinityTopologyVersion [topVer=7178104327855210152, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=93911f00371-09e1520e-eca4-4c8e-9348-84601dcda8f0, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=c2b9e92a-a55d-40d9-9d4b-b6d86116cecd, topVer=0, nodeId8=c2b9e92a,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593448667445]],
val2=AffinityTopologyVersion [topVer=-2879718019931616062, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=93911f00371-09e1520e-eca4-4c8e-9348-84601dcda8f0, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=c2b9e92a-a55d-40d9-9d4b-b6d86116cecd, topVer=0, nodeId8=c2b9e92a,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593448667445]],
val2=AffinityTopologyVersion [topVer=-2879718019931616062, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=a0568f19-5103-43ea-b62e-9330d8fb7569, topVer=0,
nodeId8=93285897, msg=, type=NODE_JOINED, tstamp=1593448782668],
val2=AffinityTopologyVersion [topVer=-5399858290264171078, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=a0568f19-5103-43ea-b62e-9330d8fb7569, topVer=0,
nodeId8=93285897, msg=, type=NODE_JOINED, tstamp=1593448782668],
val2=AffinityTopologyVersion [topVer=-5399858290264171078, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=7526df00371-6617c238-2c96-49b0-b191-3e19cb724728, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=db1df3d9-ac87-415c-a716-85a286d9f9e6, topVer=0, nodeId8=db1df3d9,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593448782668]],
val2=AffinityTopologyVersion [topVer=3758675786951635777, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=7526df00371-6617c238-2c96-49b0-b191-3e19cb724728, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=db1df3d9-ac87-415c-a716-85a286d9f9e6, topVer=0, nodeId8=db1df3d9,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1593448782668]],
val2=AffinityTopologyVersion [topVer=3758675786951635777, minorTopVer=0]]] -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5425606buildTypeId=IgniteTests24Java8_RunAll]
> Move control.sh to a separate module
>
>
> Key: IGNITE-13123
> URL: https://issues.apache.org/jira/browse/IGNITE-13123
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Move [1] and its
[jira] [Commented] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM
[
https://issues.apache.org/jira/browse/IGNITE-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148053#comment-17148053
]
Manuel Núñez commented on IGNITE-13005:
---
[~ilyak] and sorry for the delay ... too many things on the tray
> Spring Data 2 - "JPA style" and working with multiple Ignite instances on
> same JVM
> --
>
> Key: IGNITE-13005
> URL: https://issues.apache.org/jira/browse/IGNITE-13005
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.7.6, 2.8.1
>Reporter: Manuel Núñez
>Assignee: Manuel Núñez
>Priority: Major
> Labels: spring-data
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some
> interesting improvements.
> Code is 100% compatible with previous versions.
> [https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
> * Supports multiple ignite instances on same JVM (@RepositoryConfig).
> * Supports query tuning parameters in {{@Query}} annotation
> * Supports projections
> * Supports {{Page}} and {{Stream}} responses
> * Supports Sql Fields Query resultset transformation into the domain entity
> * Supports named parameters ({{:myParam}}) into SQL queries, declared using
> {{@Param("myParam")}}
> * Supports advanced parameter binding and SpEL expressions into SQL queries:
> ** *Template variables*:
> *** {{#entityName}} - the simple class name of the domain entity
> ** *Method parameter expressions*: Parameters are exposed for indexed access
> ({{[0]}} is the first query method's param) or via the name declared using
> {{@Param}}. The actual SpEL expression binding is triggered by {{?#}}.
> Example: {{?#\{[0]\}} or {{?#\{#myParamName\}}}
> ** *Advanced SpEL expressions*: While advanced parameter binding is a very
> useful feature, the real power of SpEL stems from the fact, that the
> expressions can refer to framework abstractions or other application
> components through SpEL EvaluationContext extension model.
> * Supports SpEL expressions into Text queries ({{TextQuery}}).
> Some examples:
> {code:java}
> // Spring Data Repositories using different ignite instances on same JVM
> @RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
> public interface FlightRouteRepository extends IgniteRepository String> {
> ...
> }
> @RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
> public interface PoiRepository extends IgniteRepository {
> ...
> }
> {code}
> {code:java}
> // named parameter
> @Query(value = "SELECT * from #{#entityName} where email = :email")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // indexed parameters
> @Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city
> = ?#{[1]}")
> List searchUsersByCity(@Param("country") String country, @Param("city")
> String city, Pageable pageable);
> {code}
> {code:java}
> // ordered method parameters
> @Query(value = "SELECT * from #{#entityName} where email = ?")
> User searchUserByEmail(String email);
> {code}
> {code:java}
> // Advanced SpEL expressions
> @Query(value = "SELECT * from #{#entityName} where uuidCity =
> ?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
> List searchUsersByCity(@Param("city") String city, Pageable pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "email: #{#email}")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "#{#textToSearch}")
> List searchUsersByText(@Param("textToSearch") String text, Pageable
> pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL indexed parameter
> @Query(textQuery = true, value = "#{[0]}")
> List searchUsersByText(String textToSearch, Pageable pageable);
> {code}
> {code:java}
> // Static Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
> List searchMerchantsByOrigin(@Param("origin") String origin,
> @Param("disabled") boolean disabled);
> {code}
> {code:java}
> // Dynamic Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.id,
[jira] [Commented] (IGNITE-13176) C++: Remove autotools build after merging CMake
[
https://issues.apache.org/jira/browse/IGNITE-13176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147996#comment-17147996
]
Ivan Daschinskiy commented on IGNITE-13176:
---
[~ilyak] There are no new tests. This is strange new feature of mtcga. Memory
leak report on x64 Debug is common thing, you can easily find this by observing
history. Actually, this build is excluded from RunAll.
> C++: Remove autotools build after merging CMake
> ---
>
> Key: IGNITE-13176
> URL: https://issues.apache.org/jira/browse/IGNITE-13176
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Trivial
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Old autotools build scripts and release steps in {{pom.xml}} should be
> removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13176) C++: Remove autotools build after merging CMake
[
https://issues.apache.org/jira/browse/IGNITE-13176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147994#comment-17147994
]
Ilya Kasnacheev commented on IGNITE-13176:
--
Why new tests at winx64?
> C++: Remove autotools build after merging CMake
> ---
>
> Key: IGNITE-13176
> URL: https://issues.apache.org/jira/browse/IGNITE-13176
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Trivial
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Old autotools build scripts and release steps in {{pom.xml}} should be
> removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12934) Change test start|stop log format for correct TC and build.log visibility.
[ https://issues.apache.org/jira/browse/IGNITE-12934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12934: - Reviewer: Maxim Muzafarov > Change test start|stop log format for correct TC and build.log visibility. > -- > > Key: IGNITE-12934 > URL: https://issues.apache.org/jira/browse/IGNITE-12934 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > For correct TC and builds log visibility need to repeat log format, from : > ">>> Stopping test: " > as > "##teamcity[testFinished name='" > additional info: > https://www.jetbrains.com/help/teamcity/build-script-interaction-with-teamcity.html#BuildScriptInteractionwithTeamCity-ReportingTests > Also, make “Starting test”, “Stopping test” messages visible in Quiet mode! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM
[
https://issues.apache.org/jira/browse/IGNITE-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147887#comment-17147887
]
Manuel Núñez commented on IGNITE-13005:
---
[~ilyak] done.
> Spring Data 2 - "JPA style" and working with multiple Ignite instances on
> same JVM
> --
>
> Key: IGNITE-13005
> URL: https://issues.apache.org/jira/browse/IGNITE-13005
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.7.6, 2.8.1
>Reporter: Manuel Núñez
>Assignee: Manuel Núñez
>Priority: Major
> Labels: spring-data
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some
> interesting improvements.
> Code is 100% compatible with previous versions.
> [https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
> * Supports multiple ignite instances on same JVM (@RepositoryConfig).
> * Supports query tuning parameters in {{@Query}} annotation
> * Supports projections
> * Supports {{Page}} and {{Stream}} responses
> * Supports Sql Fields Query resultset transformation into the domain entity
> * Supports named parameters ({{:myParam}}) into SQL queries, declared using
> {{@Param("myParam")}}
> * Supports advanced parameter binding and SpEL expressions into SQL queries:
> ** *Template variables*:
> *** {{#entityName}} - the simple class name of the domain entity
> ** *Method parameter expressions*: Parameters are exposed for indexed access
> ({{[0]}} is the first query method's param) or via the name declared using
> {{@Param}}. The actual SpEL expression binding is triggered by {{?#}}.
> Example: {{?#\{[0]\}} or {{?#\{#myParamName\}}}
> ** *Advanced SpEL expressions*: While advanced parameter binding is a very
> useful feature, the real power of SpEL stems from the fact, that the
> expressions can refer to framework abstractions or other application
> components through SpEL EvaluationContext extension model.
> * Supports SpEL expressions into Text queries ({{TextQuery}}).
> Some examples:
> {code:java}
> // Spring Data Repositories using different ignite instances on same JVM
> @RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
> public interface FlightRouteRepository extends IgniteRepository String> {
> ...
> }
> @RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
> public interface PoiRepository extends IgniteRepository {
> ...
> }
> {code}
> {code:java}
> // named parameter
> @Query(value = "SELECT * from #{#entityName} where email = :email")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // indexed parameters
> @Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city
> = ?#{[1]}")
> List searchUsersByCity(@Param("country") String country, @Param("city")
> String city, Pageable pageable);
> {code}
> {code:java}
> // ordered method parameters
> @Query(value = "SELECT * from #{#entityName} where email = ?")
> User searchUserByEmail(String email);
> {code}
> {code:java}
> // Advanced SpEL expressions
> @Query(value = "SELECT * from #{#entityName} where uuidCity =
> ?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
> List searchUsersByCity(@Param("city") String city, Pageable pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "email: #{#email}")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "#{#textToSearch}")
> List searchUsersByText(@Param("textToSearch") String text, Pageable
> pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL indexed parameter
> @Query(textQuery = true, value = "#{[0]}")
> List searchUsersByText(String textToSearch, Pageable pageable);
> {code}
> {code:java}
> // Static Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
> List searchMerchantsByOrigin(@Param("origin") String origin,
> @Param("disabled") boolean disabled);
> {code}
> {code:java}
> // Dynamic Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
> List
[jira] [Commented] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147822#comment-17147822
]
Alexey Scherbakov commented on IGNITE-12935:
[~v.pyatkov]
I've left several minor comments.
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> {noformat}
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but minimum present counter is less than maximum
> reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
> maxReservedNodeId=ID], ...]{noformat}
> ## We can also aggregate previous message by (minNodeId) to easily find the
> exact node (or nodes) which were the reason of full rebalance.
> # Log results of {{reserveHistoryForExchange()}}. They can be compactly
> represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
> group, also log message about why the previous checkpoint wasn't successfully
> reserved.
> There can be three reasons:
> ## Previous checkpoint simply isn't present in the history (the oldest is
> reserved)
> ## WAL reservation failure (call below returned false)
> {code:java}
> chpEntry = entry(cpTs);
> boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
> checkpoint WAL history can't be reserved, stop searching.
> if (!reserved)
> break;{code}
> ## Checkpoint was marked as inapplicable for historical rebalancing
> {code:java}
> for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
> if (!isCheckpointApplicableForGroup(grpId, chpEntry))
> groupsAndPartitions.remove(grpId);{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-10782) javadoc description for ml.math.exceptions.preprocessing and ml.selection.scoring.evaluator
[ https://issues.apache.org/jira/browse/IGNITE-10782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev resolved IGNITE-10782. -- Resolution: Fixed > javadoc description for ml.math.exceptions.preprocessing and > ml.selection.scoring.evaluator > --- > > Key: IGNITE-10782 > URL: https://issues.apache.org/jira/browse/IGNITE-10782 > Project: Ignite > Issue Type: Bug > Components: documentation, ml >Reporter: Stepan Pilschikov >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.9 > > > Need to add modules description for > - org.apache.ignite.ml.math.exceptions.preprocessing > - org.apache.ignite.ml.selection.scoring.evaluator > Located in ignite/docs/overview-summary.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10782) javadoc description for ml.math.exceptions.preprocessing and ml.selection.scoring.evaluator
[ https://issues.apache.org/jira/browse/IGNITE-10782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147792#comment-17147792 ] Stepan Pilschikov commented on IGNITE-10782: [~zaleslaw] now all looks good. Issue can be closed, i think > javadoc description for ml.math.exceptions.preprocessing and > ml.selection.scoring.evaluator > --- > > Key: IGNITE-10782 > URL: https://issues.apache.org/jira/browse/IGNITE-10782 > Project: Ignite > Issue Type: Bug > Components: documentation, ml >Reporter: Stepan Pilschikov >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.9 > > > Need to add modules description for > - org.apache.ignite.ml.math.exceptions.preprocessing > - org.apache.ignite.ml.selection.scoring.evaluator > Located in ignite/docs/overview-summary.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10015) Sporadic JVM crash due to restart nodes
[
https://issues.apache.org/jira/browse/IGNITE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10015:
---
Fix Version/s: (was: 2.9)
2.10
> Sporadic JVM crash due to restart nodes
>
>
> Key: IGNITE-10015
> URL: https://issues.apache.org/jira/browse/IGNITE-10015
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
> Fix For: 3.0, 2.10
>
> Attachments: hs_err_pid9126.log
>
>
> 1. Start 4 node cluster with pre-configured TTL caches.
> 2. Some 4 node may crash:
> {noformat}
> [22:43:01,485][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_002,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_013,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_001,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_012,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_004,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_015,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_003,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,006][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_014,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=ignite-sys-cache,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_011,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_010,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_009,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_006,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_005,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_016,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_008,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_007,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,012][INFO][db-checkpoint-thread-#68][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=214d43f2-6096-4b42-ab0f-52b7f98078f4,
> startPtr=FileWALPointer [idx=0, fileOff=513096, len=16483],
> checkpointLockWait=0ms, checkpointLockHoldTime=23ms,
> walCpRecordFsyncDuration=880ms, pages=238, reason='timeout']
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0x7) at pc=0x7f0aa29d8522, pid=12344, tid=0x7f08b15f5700
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build
> 1.8.0_161-b12)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # C [libzip.so+0x12522] newEntry+0x62
> #
> # Core dump written. Default location:
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/core or core.12344
> #
> # An error report file with more information is saved as:
> #
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/hs_err_pid12344.log
> Compiled method (nm)7845 558 n 0
> java.util.zip.ZipFile::getEntry (native)
> total in heap [0x7f0a8d3d1850,0x7f0a8d3d1bc0] = 880
> relocation [0x7f0a8d3d1978,0x7f0a8d3d19c0] = 72
> main code [0x7f0a8d3d19c0,0x7f0a8d3d1bc0] = 512
> [thread 139675315439360 also had an error]
> #
> # If you would like to submit a bug report, please visit:
> #
[jira] [Updated] (IGNITE-10112) Prioritize processing of tx finish=false message due to timeout
[ https://issues.apache.org/jira/browse/IGNITE-10112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10112: --- Fix Version/s: (was: 2.9) > Prioritize processing of tx finish=false message due to timeout > --- > > Key: IGNITE-10112 > URL: https://issues.apache.org/jira/browse/IGNITE-10112 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Priority: Major > > Currently tx rollback messages are processed in the same way as others. > For forced rollback on example triggered by tx timeouts on PME (see > org.apache.ignite.configuration.TransactionConfiguration#getTxTimeoutOnPartitionMapExchange) > they should be prioritized to avoid timeout violation under load. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10082) MVCC TX: Partition sizes become inconsistent after rebalance.
[ https://issues.apache.org/jira/browse/IGNITE-10082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10082: --- Fix Version/s: (was: 2.9) > MVCC TX: Partition sizes become inconsistent after rebalance. > - > > Key: IGNITE-10082 > URL: https://issues.apache.org/jira/browse/IGNITE-10082 > Project: Ignite > Issue Type: Bug > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Major > Labels: mvcc_stability, rebalance > > While rebalance partition size increments on each put operation; since > several versions of one key may be rebalanced, partition sizes become > inconsistent after rebalance finished. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10066) MVCC: Missing key and value constraint validation for MVCC tables
[
https://issues.apache.org/jira/browse/IGNITE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10066:
---
Fix Version/s: (was: 2.9)
> MVCC: Missing key and value constraint validation for MVCC tables
> -
>
> Key: IGNITE-10066
> URL: https://issues.apache.org/jira/browse/IGNITE-10066
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Mikhail Petrov
>Priority: Major
>
> It seems that key and value constraints for MVCC tables are ignoring now when
> code approach is using to operate with table. The same SQL requests work fine.
> It seems that QueryTypeDescriptorImpl.validateKeyAndValue method call which
> provides corresponding constraints is missed now.
>
> Reproducer for not null constraint:
> {code:java}
> public class IgniteCacheTransactionalSnapshotNullConstraintTest extends
> GridCommonAbstractTest {
> private static final String REPLICATED_CACHE_NAME = "replicatedCacheName";
> private static final String PARTITIONED_CACHE_NAME =
> "partitionedCacheName";
> @Override protected void beforeTestsStarted() throws Exception {
> startGrid(0);
> execSQL("CREATE TABLE table(id INT PRIMARY KEY, str VARCHAR NOT NULL)
> WITH \"atomicity=transactional_snapshot\"");
> jcache(grid(0), cacheConfiguration(REPLICATED,
> TRANSACTIONAL_SNAPSHOT), REPLICATED_CACHE_NAME);
> jcache(grid(0), cacheConfiguration(PARTITIONED,
> TRANSACTIONAL_SNAPSHOT), PARTITIONED_CACHE_NAME);
> }
> protected CacheConfiguration cacheConfiguration(CacheMode cacheMode,
> CacheAtomicityMode atomicityMode) {
> CacheConfiguration cfg = new CacheConfiguration();
> cfg.setCacheMode(cacheMode);
> cfg.setAtomicityMode(atomicityMode);
> cfg.setWriteSynchronizationMode(FULL_SYNC);
> cfg.setQueryEntities(Collections.singletonList(new
> QueryEntity(Integer.class, Person.class)));
> return cfg;
> }
> public void testPutNullValueReplicatedModeFail() throws Exception {
> IgniteCache cache = jcache(0, REPLICATED_CACHE_NAME);
> assertThrowsWithCause(() -> {
> cache.put(0, new Person(null, 25));
> }, IgniteException.class);
> }
> public void testPutNullValuePartitionedModeFail() throws Exception {
> IgniteCache cache = jcache(0,
> PARTITIONED_CACHE_NAME);
> assertThrowsWithCause(() -> {
> cache.put(1, new Person(null, 18));
> }, IgniteException.class);
> }
> public void testPutNullValueSQLFail() throws Exception {
> checkSQLThrows("INSERT INTO table VALUES(?, ?)", NULL_VALUE, 0, null);
> }
> public static class Person implements Serializable {
> @QuerySqlField(notNull = true)
> private String name;
> @QuerySqlField
> private int age;
> public Person(String name, int age) {
> this.name = name;
> this.age = age;
> }
> }
> private void checkSQLThrows(String sql, String sqlStateCode, Object...
> args) {
> IgniteSQLException err =
> (IgniteSQLException)GridTestUtils.assertThrowsWithCause(() -> {
> execSQL(sql, args);
> return 0;
> }, IgniteSQLException.class);
> assertEquals((err).sqlState(), sqlStateCode);
> }
> private List execSQL(String sql, Object... args) {
> SqlFieldsQuery qry = new SqlFieldsQuery(sql)
> .setArgs(args);
> return grid(0).context().query().querySqlFields(qry, true).getAll();
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10065) possibility to get EVT_CACHE_STARTED before cache proxy initialization
[ https://issues.apache.org/jira/browse/IGNITE-10065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10065: --- Fix Version/s: (was: 2.9) > possibility to get EVT_CACHE_STARTED before cache proxy initialization > -- > > Key: IGNITE-10065 > URL: https://issues.apache.org/jira/browse/IGNITE-10065 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: ARomantsov >Priority: Critical > > It looks , I can take EVT_CACHE_STARTED before take message - Finish proxy > initialization, cacheName=cache -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10061) Improvement: warning or debug message is required in case if some data in SQL join requests isn't collocated.
[ https://issues.apache.org/jira/browse/IGNITE-10061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10061: --- Fix Version/s: (was: 2.9) > Improvement: warning or debug message is required in case if some data in SQL > join requests isn't collocated. > - > > Key: IGNITE-10061 > URL: https://issues.apache.org/jira/browse/IGNITE-10061 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.6 >Reporter: Andrey Aleksandrov >Priority: Major > > When data isn't collocated then during executing of the join request will be > great to get for some warning like "your data isn't collocated" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10035) Fix tests IgniteWalFormatFileFailoverTest
[ https://issues.apache.org/jira/browse/IGNITE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10035: --- Fix Version/s: (was: 2.9) > Fix tests IgniteWalFormatFileFailoverTest > - > > Key: IGNITE-10035 > URL: https://issues.apache.org/jira/browse/IGNITE-10035 > Project: Ignite > Issue Type: Test > Components: cache >Affects Versions: 2.8 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Minor > > After IGNITE-9420 introduce, WAL Archiver component is started together with > WAL manager. Tests suppose that WAL Archiver will be started after first > activation, and proper file io factory will be injected to it. Need to find > out how to inject file io factory before file archiver is started. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10039) Small data region may lead IgniteOOM
[
https://issues.apache.org/jira/browse/IGNITE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10039:
---
Fix Version/s: (was: 2.9)
> Small data region may lead IgniteOOM
>
>
> Key: IGNITE-10039
> URL: https://issues.apache.org/jira/browse/IGNITE-10039
> Project: Ignite
> Issue Type: Bug
> Components: cache, persistence
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Major
>
> For small data region(s) the node restart may lead IgniteOOM. We should
> calculate the minimal required size and show a warning message on node output.
> {noformat}
> [21:36:06,648][SEVERE][exchange-worker-#63][] Critical system error detected.
> Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=class o.a.i.i.mem.IgniteOutOfMemoryException: Failed to find a page for
> eviction [segmentCapacity=3952, loaded=1549, maxDirtyPages=1162,
> dirtyPages=1549, cpPages=0, pinnedInSegment=0, failedToPrepare=1549]
> Out of memory in data region [name=default, initSize=50.0 MiB, maxSize=100.0
> MiB, persistenceEnabled=true] Try the following:
> ^-- Increase maximum off-heap memory size (DataRegionConfiguration.maxSize)
> ^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
> ^-- Enable eviction or expiration policies]]
> class org.apache.ignite.internal.mem.IgniteOutOfMemoryException: Failed to
> find a page for eviction [segmentCapacity=3952, loaded=1549,
> maxDirtyPages=1162, dirtyPages=1549, cpPages=0, pinnedInSegment=0,
> failedToPrepare=1549]
> Out of memory in data region [name=default, initSize=50.0 MiB, maxSize=100.0
> MiB, persistenceEnabled=true] Try the following:
> ^-- Increase maximum off-heap memory size (DataRegionConfiguration.maxSize)
> ^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
> ^-- Enable eviction or expiration policies
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.tryToFindSequentially(PageMemoryImpl.java:2361)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.removePageForReplacement(PageMemoryImpl.java:2255)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.access$900(PageMemoryImpl.java:1864)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:696)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:637)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.(CacheFreeListImpl.java:49)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore$1.(GridCacheOffheapManager.java:1339)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1339)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:1631)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:991)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.(GridDhtLocalPartition.java:224)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.forceCreatePartition(GridDhtPartitionTopologyImpl.java:884)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2444)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2382)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1624)
> at
>
[jira] [Updated] (IGNITE-10048) Bounded iteration in standalone WAL iterator with compaction enabled may skip records
[
https://issues.apache.org/jira/browse/IGNITE-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10048:
---
Fix Version/s: (was: 2.9)
> Bounded iteration in standalone WAL iterator with compaction enabled may skip
> records
> -
>
> Key: IGNITE-10048
> URL: https://issues.apache.org/jira/browse/IGNITE-10048
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Bounded iteration with non-zero start/end offsets may skip some records in
> intermediate segments. Reproducer (wal compaction should be enabled):
> {noformat}
> /**
> *
> */
> public void testBoundedIterationOverSeveralSegments() throws Exception {
> walCompactionEnabled = true;
> IgniteEx ig = (IgniteEx)startGrid();
> String archiveWalDir = getArchiveWalDirPath(ig);
> ig.cluster().active(true);
> IgniteCache cache = ig.getOrCreateCache(
> new CacheConfiguration<>().setName("c-n").setAffinity(new
> RendezvousAffinityFunction(false, 32)));
> IgniteCacheDatabaseSharedManager sharedMgr =
> ig.context().cache().context().database();
> IgniteWriteAheadLogManager walMgr =
> ig.context().cache().context().wal();
> WALPointer fromPtr = null;
> int recordsCnt = WAL_SEGMENT_SIZE / 8 /* record size */ * 5;
> for (int i = 0; i < recordsCnt; i++) {
> WALPointer ptr = walMgr.log(new PartitionDestroyRecord(i, i));
> if (i == 100)
> fromPtr = ptr;
> }
> assertNotNull(fromPtr);
> cache.put(1, 1);
> forceCheckpoint();
> // Generate WAL segments for filling WAL archive folder.
> for (int i = 0; i < 2 *
> ig.configuration().getDataStorageConfiguration().getWalSegments(); i++) {
> sharedMgr.checkpointReadLock();
> try {
> walMgr.log(new SnapshotRecord(i, false),
> RolloverType.NEXT_SEGMENT);
> }
> finally {
> sharedMgr.checkpointReadUnlock();
> }
> }
> cache.put(2, 2);
> forceCheckpoint();
> U.sleep(5000);
> stopGrid();
> WALIterator it = new IgniteWalIteratorFactory(log)
> .iterator(new
> IteratorParametersBuilder().from((FileWALPointer)fromPtr).filesOrDirs(archiveWalDir));
> TreeSet foundCounters = new TreeSet<>();
> it.forEach(x -> {
> WALRecord rec = x.get2();
> if (rec instanceof PartitionDestroyRecord)
> foundCounters.add(((WalRecordCacheGroupAware)rec).groupId());
> });
> assertEquals(new Integer(100), foundCounters.first());
> assertEquals(new Integer(recordsCnt - 1), foundCounters.last());
> assertEquals(recordsCnt - 100, foundCounters.size());
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
[
https://issues.apache.org/jira/browse/IGNITE-13194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13194:
--
Description:
Test
{code:java}
IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
{code}
fails in master. Changed error message is incorrectly checked in the test.
> Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> --
>
> Key: IGNITE-13194
> URL: https://issues.apache.org/jira/browse/IGNITE-13194
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test
> {code:java}
> IgnitePdsBinaryMetadataOnClusterRestartTest.testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
> {code}
> fails in master. Changed error message is incorrectly checked in the test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13195) Allow skipping autotools invocation when building Ignite release
[
https://issues.apache.org/jira/browse/IGNITE-13195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-13195:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Allow skipping autotools invocation when building Ignite release
>
>
> Key: IGNITE-13195
> URL: https://issues.apache.org/jira/browse/IGNITE-13195
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>
> I do not have an up-to-date set of autotools installed on local machine, and
> Apache Ignite release build fails locally with the following error:
> {code}
> main::scan_file() called too early to check prototype at
> /usr/local/bin/aclocal line 617.
> configure.ac:36: warning: macro `AM_PROG_AR' not found in library
> configure.ac:21: error: Autoconf version 2.69 or higher is required
> configure.ac:21: the top level
> autom4te: /usr/bin/m4 failed with exit status: 63
> aclocal: autom4te failed with exit status: 63
> {code}
> I do not need to run these commands locally because I only need a quick
> assembly (java only, even no javadocs) to verify the release structure and
> command-line utilities integrity.
> It would be great to move these commands to a separate profile (enabled by
> default) so users can skip them when building the release package, something
> like {{mvn initialize -Prelease -P!autotools}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13195) Allow skipping autotools invocation when building Ignite release
[
https://issues.apache.org/jira/browse/IGNITE-13195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-13195:
-
Ignite Flags: (was: Release Notes Required)
> Allow skipping autotools invocation when building Ignite release
>
>
> Key: IGNITE-13195
> URL: https://issues.apache.org/jira/browse/IGNITE-13195
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>
> I do not have an up-to-date set of autotools installed on local machine, and
> Apache Ignite release build fails locally with the following error:
> {code}
> main::scan_file() called too early to check prototype at
> /usr/local/bin/aclocal line 617.
> configure.ac:36: warning: macro `AM_PROG_AR' not found in library
> configure.ac:21: error: Autoconf version 2.69 or higher is required
> configure.ac:21: the top level
> autom4te: /usr/bin/m4 failed with exit status: 63
> aclocal: autom4te failed with exit status: 63
> {code}
> I do not need to run these commands locally because I only need a quick
> assembly (java only, even no javadocs) to verify the release structure and
> command-line utilities integrity.
> It would be great to move these commands to a separate profile (enabled by
> default) so users can skip them when building the release package, something
> like {{mvn initialize -Prelease -P!autotools}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13195) Allow skipping autotools invocation when building Ignite release
[
https://issues.apache.org/jira/browse/IGNITE-13195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev resolved IGNITE-13195.
--
Resolution: Duplicate
> Allow skipping autotools invocation when building Ignite release
>
>
> Key: IGNITE-13195
> URL: https://issues.apache.org/jira/browse/IGNITE-13195
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>
> I do not have an up-to-date set of autotools installed on local machine, and
> Apache Ignite release build fails locally with the following error:
> {code}
> main::scan_file() called too early to check prototype at
> /usr/local/bin/aclocal line 617.
> configure.ac:36: warning: macro `AM_PROG_AR' not found in library
> configure.ac:21: error: Autoconf version 2.69 or higher is required
> configure.ac:21: the top level
> autom4te: /usr/bin/m4 failed with exit status: 63
> aclocal: autom4te failed with exit status: 63
> {code}
> I do not need to run these commands locally because I only need a quick
> assembly (java only, even no javadocs) to verify the release structure and
> command-line utilities integrity.
> It would be great to move these commands to a separate profile (enabled by
> default) so users can skip them when building the release package, something
> like {{mvn initialize -Prelease -P!autotools}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10029) Node attributes are not restored from metastore after node restart.
[ https://issues.apache.org/jira/browse/IGNITE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10029: --- Fix Version/s: (was: 2.9) > Node attributes are not restored from metastore after node restart. > --- > > Key: IGNITE-10029 > URL: https://issues.apache.org/jira/browse/IGNITE-10029 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Priority: Major > > Scenario: > 1. Start node with enabled persistence, configure some user attributes. > 2. Restart node without directly setting node attributes again. > 3. Read any user attribute and observe NULL value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10001) MVCC: Make existed tests run in MVCC mode as well.
[ https://issues.apache.org/jira/browse/IGNITE-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10001: --- Fix Version/s: (was: 2.9) > MVCC: Make existed tests run in MVCC mode as well. > -- > > Key: IGNITE-10001 > URL: https://issues.apache.org/jira/browse/IGNITE-10001 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Andrey Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > > This is umbrella ticket. > We should add MVCC mode to all relevant existed tests, as MVCC is a new > feature and integrations with other features haven't tested yet. > Let's add separate suite with mvcc mode for each existed one at first and > mute non-relevant and failed tests. > (This way will not affects current tests TC statistics and will not broke > current TC runs) > Then we will be able to rearrange and\or refactor existed tests to add MVCC > mode to tests properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9966) Dump configuration to distinct file and all dynamic changes to the cluster
[ https://issues.apache.org/jira/browse/IGNITE-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9966: -- Fix Version/s: (was: 2.9) > Dump configuration to distinct file and all dynamic changes to the cluster > -- > > Key: IGNITE-9966 > URL: https://issues.apache.org/jira/browse/IGNITE-9966 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > > Sometimes it's difficult to analyze issues, very often we can't restore > nodes/caches configurations due to log rotation, I think we can dump > configurations on start in work dir. > Also, it will be convenient to dump configurations of all dynamically created > caches to the file too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9965) Ignite.sh must enable GC logs by default
[ https://issues.apache.org/jira/browse/IGNITE-9965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9965: -- Fix Version/s: (was: 2.9) > Ignite.sh must enable GC logs by default > > > Key: IGNITE-9965 > URL: https://issues.apache.org/jira/browse/IGNITE-9965 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > > Almost always you need to monitor GC and almost always people foget to enable > GC logs, so why not to enable GC logs by default? > Let's check if it's oracle/openjdk and no GC logs config is specified then > collect GC logs, also we may add a script variable to specify a path for logs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9949) MVCC TX: Scan query can return wrong result on unstable topology
[
https://issues.apache.org/jira/browse/IGNITE-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9949:
--
Fix Version/s: (was: 2.9)
> MVCC TX: Scan query can return wrong result on unstable topology
>
>
> Key: IGNITE-9949
> URL: https://issues.apache.org/jira/browse/IGNITE-9949
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: mvcc_stability, transactions
>
> Scan query map nodes do not take into account topology version when filtering
> primary partitions. See method {{GridCacheQueryManager#scanIterator}} - each
> node takes it's current topology version. This causes wrong partition
> filtering results.
> To fix this problem the single topology version should be taken on reduce
> node propagated to map nodes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9958) Optimize execution time of CacheContinuousQueryVariationsTest
[ https://issues.apache.org/jira/browse/IGNITE-9958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9958: -- Fix Version/s: (was: 2.9) > Optimize execution time of CacheContinuousQueryVariationsTest > - > > Key: IGNITE-9958 > URL: https://issues.apache.org/jira/browse/IGNITE-9958 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Tests from CacheContinuousQueryVariationsTest require a lot of time ([sample > run|https://ci.ignite.apache.org/viewLog.html?buildId=2136245=IgniteTests24Java8_RunAll=testsInfo]) > and thus slow down build on TeamCity significantly. > They need to be investigated and optimized if possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9921) Local Node Job Metrics are not displayed
[ https://issues.apache.org/jira/browse/IGNITE-9921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9921: -- Fix Version/s: (was: 2.9) > Local Node Job Metrics are not displayed > > > Key: IGNITE-9921 > URL: https://issues.apache.org/jira/browse/IGNITE-9921 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5, 2.6 >Reporter: Ivan Kapralov >Priority: Major > Labels: 2.5.1-next > > Metrics CurrentActiveJobs, CurrentCancelledJobs, CurrentJobExecuteTime, > CurrentJobWaitTime, CurrentWaitingJobs in bean ClusterLocalNodeMXBeanImpl are > not calculated properly in the following scenario: > - start a server node; > - start a client node that will perform some compute/SQL/put-get tasks; > - CurrentActiveJobs, CurrentCancelledJobs, CurrentJobExecuteTime, > CurrentJobWaitTime, CurrentWaitingJobs will always be 0 on both server and > client nodes. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9925) Validate QueryEntites on cache creation
[ https://issues.apache.org/jira/browse/IGNITE-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9925: -- Fix Version/s: (was: 2.9) > Validate QueryEntites on cache creation > --- > > Key: IGNITE-9925 > URL: https://issues.apache.org/jira/browse/IGNITE-9925 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Priority: Major > > it's possible to create a cache with the index for non-existing field and > kill the whole cluster, I think this should be prevented by configuration > validation, see reproducer in > https://issues.apache.org/jira/browse/IGNITE-9907 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9915) Do not block get/getAll during baseline node stopping.
[ https://issues.apache.org/jira/browse/IGNITE-9915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9915: -- Fix Version/s: (was: 2.9) > Do not block get/getAll during baseline node stopping. > -- > > Key: IGNITE-9915 > URL: https://issues.apache.org/jira/browse/IGNITE-9915 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > > Do not block get/getAll during baseline node stopping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9912) Improve Javadoc suite
[
https://issues.apache.org/jira/browse/IGNITE-9912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9912:
--
Fix Version/s: (was: 2.9)
> Improve Javadoc suite
> -
>
> Key: IGNITE-9912
> URL: https://issues.apache.org/jira/browse/IGNITE-9912
> Project: Ignite
> Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
>
> # Add {{javadoc}} profile to maven execution
> # Devise a solution to workaround warning about Hibernate duplicate
> package-info (due to Hibernate 4 and 5 modules together in single reactor)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9883) Do not block get/getAll during start/stop operations on other cache.
[ https://issues.apache.org/jira/browse/IGNITE-9883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9883: -- Fix Version/s: (was: 2.9) > Do not block get/getAll during start/stop operations on other cache. > > > Key: IGNITE-9883 > URL: https://issues.apache.org/jira/browse/IGNITE-9883 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > > Do not block get/getAll during start/stop operations on other cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9896) TxRollbackOnTimeoutNoDeadlockDetectionTest fails in master for many tests
[ https://issues.apache.org/jira/browse/IGNITE-9896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9896: -- Fix Version/s: (was: 2.9) > TxRollbackOnTimeoutNoDeadlockDetectionTest fails in master for many tests > - > > Key: IGNITE-9896 > URL: https://issues.apache.org/jira/browse/IGNITE-9896 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Priority: Major > > Example of 100% failing test: > org.apache.ignite.internal.processors.cache.transactions.TxRollbackOnTimeoutNoDeadlockDetectionTest#testRollbackOnTimeoutTxServerRemapPessimisticReadCommitted > This have not been noticed earlier because > org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager#DEADLOCK_MAX_ITERS > is static and propery is not correctly applied if test is executed from > suite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9867) Add ability to block out of range IP on discovery request
[
https://issues.apache.org/jira/browse/IGNITE-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9867:
--
Fix Version/s: (was: 2.9)
> Add ability to block out of range IP on discovery request
> -
>
> Key: IGNITE-9867
> URL: https://issues.apache.org/jira/browse/IGNITE-9867
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.7
>Reporter: ARomantsov
>Priority: Critical
>
> Now we can set list of cluster collector node, but cannot deny another ips to
> connect to our cluster
> {code:java}
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9871) IgniteOOM on client is not clear
[ https://issues.apache.org/jira/browse/IGNITE-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9871: -- Fix Version/s: (was: 2.9) > IgniteOOM on client is not clear > > > Key: IGNITE-9871 > URL: https://issues.apache.org/jira/browse/IGNITE-9871 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Sergey Kozlov >Priority: Major > > 1. Start grid with small data region w/o PDS > 2. Start client used streamer and load data exceeding the data region. > 3. The client throws IgniteOOM but it's not clear which node caused the > issue. Also the client may not expect such exception like this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9866) Unify and optimise *.sh and *.bat code base
[ https://issues.apache.org/jira/browse/IGNITE-9866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9866: -- Fix Version/s: (was: 2.9) > Unify and optimise *.sh and *.bat code base > --- > > Key: IGNITE-9866 > URL: https://issues.apache.org/jira/browse/IGNITE-9866 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Peter Ivanov >Assignee: Ilya Murchenko >Priority: Major > > There are lots of duplicated code at /bin/*.[sh|bat] scripts (especially -- > Java run string construction). It is required to move duplicated code to > common function script. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9827) Assertion error due historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-9827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9827:
--
Fix Version/s: (was: 2.9)
> Assertion error due historical rebalance
>
>
> Key: IGNITE-9827
> URL: https://issues.apache.org/jira/browse/IGNITE-9827
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: ARomantsov
>Priority: Major
>
> I work with next situation
> 1) Start two nodes with '-DIGNITE_PDS_WAL_REBALANCE_THRESHOLD=0',
> 2) Preload
> 3) Stop node 2
> 4) Load
> 5) Corrupt all wal archive file in node 1
> 5) Start node 2
> And found assertion in log coordinator - is it ok?
> Coordinator
> {code:java}
> [16:25:19,715][INFO][exchange-worker-#63][GridCachePartitionExchangeManager]
> Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
> [topVer=16, minorTopVer=0], evt=NODE_JOINED,
> node=d2beced9-b630-465e-85aa-733aeff15245]
> [16:25:19,829][INFO][utility-#144][GridDhtPartitionSupplier] Finished
> supplying rebalancing [grp=ignite-sys-cache,
> demander=d2beced9-b630-465e-85aa-733aeff15245, topVer=AffinityTopologyVersion
> [topVer=16, minorTopVer=0], topic=0]
> [16:25:19,844][SEVERE][sys-#65][GridDhtPartitionSupplier] Failed to continue
> supplying [grp=cache_group_2_031,
> demander=d2beced9-b630-465e-85aa-733aeff15245, topVer=AffinityTopologyVersion
> [topVer=16, minorTopVer=0], topic=0]
> java.lang.AssertionError: Partitions after rebalance should be either done or
> missing: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
> 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
> 38, 39
> , 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58,
> 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77,
> 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96,
> 97, 98
> , 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113,
> 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128,
> 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143,
> 144, 145,
> 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160,
> 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175,
> 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190,
> 191, 192, 1
> 93, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207,
> 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222,
> 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237,
> 238, 239, 24
> 0, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255,
> 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270,
> 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285,
> 286, 287
> , 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302,
> 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317,
> 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332,
> 333, 334,
> 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349,
> 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364,
> 365, 366, 367, 368, 369, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379,
> 380, 381,
> 382, 383, 384, 385, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 396,
> 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411,
> 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426,
> 427, 428, 4
> 29, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443,
> 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458,
> 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473,
> 474, 475, 47
> 6, 477, 478, 479, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 490, 491,
> 492, 493, 494, 495, 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506,
> 507, 508, 509, 510, 511]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:394)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:348)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:415)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:400)
> at
>
[jira] [Updated] (IGNITE-9781) JDK11: SSL handshake is failed
[
https://issues.apache.org/jira/browse/IGNITE-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9781:
--
Fix Version/s: (was: 2.9)
> JDK11: SSL handshake is failed
> --
>
> Key: IGNITE-9781
> URL: https://issues.apache.org/jira/browse/IGNITE-9781
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
> Environment: JDK11
>Reporter: Taras Ledkov
>Priority: Major
> Labels: jdk11
>
> The problem is reproduced on JDK11 by the test
> {{GridNioSslSelfTest.testSimpleMessages}}
> Error on the Ignite node
> {code}
> [2018-10-03 14:35:08,033][ERROR][grid-nio-worker-0-#42%nio-test-grid%][root]
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: No value present
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2412)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2153)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.NoSuchElementException: No value present
> at java.base/java.util.Optional.get(Optional.java:148)
> at
> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:551)
> at
> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1189)
> at
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1125)
> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:831)
> at
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:792)
> at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
> at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1065)
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1052)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:999)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.runTasks(GridNioSslHandler.java:624)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.handshake(GridNioSslHandler.java:243)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.messageReceived(GridNioSslHandler.java:321)
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onMessageReceived(GridNioSslFilter.java:330)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3547)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1132)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2386)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9806) Legacy tx invalidation code breaks data consistency between owners.
[
https://issues.apache.org/jira/browse/IGNITE-9806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9806:
--
Fix Version/s: (was: 2.9)
> Legacy tx invalidation code breaks data consistency between owners.
> ---
>
> Key: IGNITE-9806
> URL: https://issues.apache.org/jira/browse/IGNITE-9806
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Scherbakov
>Priority: Major
>
> Reproducer:
> {noformat}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.ignite.internal.processors.cache.transactions;
> import java.util.UUID;
> import java.util.function.Supplier;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.IgniteTransactions;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.CacheWriteSynchronizationMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.managers.communication.GridIoPolicy;
> import org.apache.ignite.internal.processors.cache.GridCacheSharedContext;
> import
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal;
> import org.apache.ignite.internal.util.typedef.G;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.testsuites.IgniteIgnore;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> import org.jetbrains.annotations.Nullable;
> import org.mockito.Mockito;
> import org.mockito.invocation.InvocationOnMock;
> import org.mockito.stubbing.Answer;
> /**
> * Tests data consistency if transaction is failed due to heuristic exception
> on originating node.
> */
> public class TxDataConsistencyOnCommitFailureTest extends
> GridCommonAbstractTest {
> /** */
> public static final int KEY = 0;
> /** */
> public static final String CLIENT = "client";
> /** */
> private int nodesCnt;
> /** */
> private int backups;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setClientMode(igniteInstanceName.startsWith(CLIENT));
> cfg.setCacheConfiguration(new CacheConfiguration(DEFAULT_CACHE_NAME).
> setCacheMode(CacheMode.PARTITIONED).
> setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL).
> setBackups(backups).
>
> setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC));
> return cfg;
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> super.afterTest();
> stopAllGrids();
> }
> /** */
> @IgniteIgnore(value = "https://issues.apache.org/jira/browse/IGNITE-590;,
> forceFailure = false)
> public void testCommitErrorOnColocatedNode2PC() throws Exception {
> nodesCnt = 3;
> backups = 2;
> doTestCommitError(() -> primaryNode(KEY, DEFAULT_CACHE_NAME));
> }
> /**
> * @param factory Factory.
> */
> private void doTestCommitError(Supplier factory) throws Exception
> {
> Ignite crd = startGridsMultiThreaded(nodesCnt);
> crd.cache(DEFAULT_CACHE_NAME).put(KEY, KEY);
> Ignite ignite = factory.get();
> if (ignite == null)
> ignite = startGrid("client");
> assertNotNull(ignite.cache(DEFAULT_CACHE_NAME));
> injectMockedTxManager(ignite);
> checkKey();
> IgniteTransactions transactions = ignite.transactions();
> try(Transaction tx =
> transactions.txStart(TransactionConcurrency.PESSIMISTIC,
[jira] [Updated] (IGNITE-9778) Gathering local node statistics on query level
[ https://issues.apache.org/jira/browse/IGNITE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9778: -- Fix Version/s: (was: 2.9) > Gathering local node statistics on query level > -- > > Key: IGNITE-9778 > URL: https://issues.apache.org/jira/browse/IGNITE-9778 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > > Should be gathered and exposed IO statistics on SQL query level. It should > contains number of logical and physical read operations. In case query is > distributed then local gathered statistics should contains aggregated stats > from all required node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9725) Introduce affinity distribution prototype for similar cache group configurations
[ https://issues.apache.org/jira/browse/IGNITE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9725: -- Fix Version/s: (was: 2.9) > Introduce affinity distribution prototype for similar cache group > configurations > > > Key: IGNITE-9725 > URL: https://issues.apache.org/jira/browse/IGNITE-9725 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.0 >Reporter: Pavel Kovalenko >Priority: Major > Labels: cache, performance > > Currently, we perform affinity re-calculation for each of cache groups, even > if configurations (CacheMode, number of backups, affinity function) are equal. > > If two cache groups have similar affinity function and number of backups we > can calculate affinity prototype for such groups once and re-use in every > cache group. > This change will save time on affinity re-calculation if a cluster has a lot > of cache groups with similar affinity function. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9676) Ignite as storage in Spring Session
[ https://issues.apache.org/jira/browse/IGNITE-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9676: -- Fix Version/s: (was: 2.9) > Ignite as storage in Spring Session > --- > > Key: IGNITE-9676 > URL: https://issues.apache.org/jira/browse/IGNITE-9676 > Project: Ignite > Issue Type: New Feature > Components: spring >Reporter: Anton Kurbanov >Assignee: Anton Kurbanov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Implement repository backed with Ignite for sessions clustering with Spring > Session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9689) MVCC: Optimize filter usage in MvccUpdateDataRow.
[ https://issues.apache.org/jira/browse/IGNITE-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9689: -- Fix Version/s: (was: 2.9) > MVCC: Optimize filter usage in MvccUpdateDataRow. > - > > Key: IGNITE-9689 > URL: https://issues.apache.org/jira/browse/IGNITE-9689 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Andrey Mashenkov >Priority: Major > Labels: mvcc_performance > > PutIfAbsent and all Replace operation uses filter for previous values checks. > When filter has provided then we have to retrieve full row (instead of > header) just to apply the filter. > However, in most of cases filter doesn't need a value itself, but just a fact > if previous value exists. > There is unused class > org.apache.ignite.internal.processors.cache.CacheOperationFilter enum that > can be used for optimization. We can just compare filter type and visitor > resultType to make a decision in CacheDataStore.mvccUpdate\mvccRemove methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9688) MVCC: Implement out-of-order enlist optimization for bulk cache operations.
[ https://issues.apache.org/jira/browse/IGNITE-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9688: -- Fix Version/s: (was: 2.9) > MVCC: Implement out-of-order enlist optimization for bulk cache operations. > --- > > Key: IGNITE-9688 > URL: https://issues.apache.org/jira/browse/IGNITE-9688 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Andrey Mashenkov >Priority: Major > Labels: mvcc_performance, performance > > For now, we always enlist updates in given order via setting > "GridNearTxEnlistFuture.sequential" flag to true. > This flag is always true for query updates as we do not know full data set at > a time future has been created. > For putAll (and other batch operations) full update map is known and we can > make per-node batches full filled before send. > E.g. we can send batches to nodes one by one regarding primary node order. > This optimization has to be disscussed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9690) MVCC: Check mvcc operations behavior with LOST partitions.
[ https://issues.apache.org/jira/browse/IGNITE-9690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9690: -- Fix Version/s: (was: 2.9) > MVCC: Check mvcc operations behavior with LOST partitions. > -- > > Key: IGNITE-9690 > URL: https://issues.apache.org/jira/browse/IGNITE-9690 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Andrey Mashenkov >Priority: Major > > We have to analyze mvcc behaviour in case of lost partition for different > lost policies for both cases SQL and KV API. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9660) Switch default test FailureHandler to StopNodeFailureHandler
[
https://issues.apache.org/jira/browse/IGNITE-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9660:
--
Fix Version/s: (was: 2.9)
> Switch default test FailureHandler to StopNodeFailureHandler
>
>
> Key: IGNITE-9660
> URL: https://issues.apache.org/jira/browse/IGNITE-9660
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Andrey Kuznetsov
>Priority: Major
>
> {{GridAbstractTest.getFailureHandler()}} returns {{NoOpFailureHandler}}
> instance. This often leads to hiding bugs occurring in tests.
> {{getFailureFailureHandler()}} should return {{StopNodeFailureHandler}}
> instead.
> The change assumes re-checking failed tests and set handler to
> {{NoOpFailureHandler}} in subclasses where it's really a must.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9664) Found unexpected checkpoint marker after node deactivation.
[ https://issues.apache.org/jira/browse/IGNITE-9664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9664: -- Fix Version/s: (was: 2.9) > Found unexpected checkpoint marker after node deactivation. > --- > > Key: IGNITE-9664 > URL: https://issues.apache.org/jira/browse/IGNITE-9664 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Stanilovsky Evgeny >Assignee: Pavel Kovalenko >Priority: Major > Attachments: err.log > > > Found numerous messages : _Found unexpected checkpoint marker_ in ignite.log > (partially attached) , this errors appeared after node segmentation (i`m > using zookeeperDiscoverySpi), next node activation lead to %subj% error > message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9666) TxPessimisticDeadlockDetectionCrossCacheTest.testDeadlockAnotherNear is flaky on master
[
https://issues.apache.org/jira/browse/IGNITE-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9666:
--
Fix Version/s: (was: 2.9)
> TxPessimisticDeadlockDetectionCrossCacheTest.testDeadlockAnotherNear is flaky
> on master
> ---
>
> Key: IGNITE-9666
> URL: https://issues.apache.org/jira/browse/IGNITE-9666
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Kuznetsov
>Priority: Major
>
> Sometimes the test cannot pass {{assertTrue(deadlock.get())}}.
> Presumably, it's due to ignoring possible long JVM pauses. For example, one
> can see near the first 'put' pair (note timestamps) :
> {noformat}
> [2018-09-23 11:16:55,975][INFO ][tx-thread-1][root] >>> Performs put
> [node=TcpDiscoveryNode [id=dd46ab0e-ed28-4c67-b3c4-98900bb0,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500],
> discPort=47500, order=1, intOrder=1, lastExchangeTime=1537690615852,
> loc=true, ver=2.7.0#19700101-sha1:, isClient=false],
> tx=TransactionProxyImpl [tx=IgniteTxAdapter [xidVer=GridCacheVersion
> [topVer=149170604, order=1537690611182, nodeOrder=1], writeVer=null,
> implicit=false, loc=true, threadId=129, startTime=1537690615791,
> nodeId=dd46ab0e-ed28-4c67-b3c4-98900bb0, startVer=GridCacheVersion
> [topVer=149170604, order=1537690611182, nodeOrder=1], endVer=null,
> isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=500,
> sysInvalidate=false, sys=false, plc=2, commitVer=null, finalizing=NONE,
> invalidParts=null, state=ACTIVE, timedOut=false,
> topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
> txCounters=org.apache.ignite.internal.processors.cache.transactions.TxCounters@31c7393f,
> duration=155ms, onePhaseCommit=false]IgniteTxLocalAdapter
> [completedBase=null, sndTransformedVals=false, depEnabled=false,
> txState=IgniteTxStateImpl [activeCacheIds=[], recovery=null,
> mvccEnabled=null, txMap=EmptySet []], mvccWaitTxs=null, qryEnlisted=false,
> super=, size=0]GridDhtTxLocalAdapter [nearOnOriginatingNode=false,
> nearNodes=KeySetView [], dhtNodes=KeySetView [], explicitLock=false,
> super=]GridNearTxLocal [mappings=IgniteTxMappingsImpl [],
> nearLocallyMapped=false, colocatedLocallyMapped=false, needCheckBackup=null,
> hasRemoteLocks=false, trackTimeout=true, lb=null, mvccTracker=null, sql=null,
> thread=tx-thread-1, mappings=IgniteTxMappingsImpl [], super=], async=false,
> asyncRes=null], key=2, cache=cache0]
> [2018-09-23 11:16:55,975][INFO ][tx-thread-2][root] >>> Performs put
> [node=TcpDiscoveryNode [id=dd46ab0e-ed28-4c67-b3c4-98900bb0,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500],
> discPort=47500, order=1, intOrder=1, lastExchangeTime=1537690615852,
> loc=true, ver=2.7.0#19700101-sha1:, isClient=false],
> tx=TransactionProxyImpl [tx=IgniteTxAdapter [xidVer=GridCacheVersion
> [topVer=149170604, order=1537690611181, nodeOrder=1], writeVer=null,
> implicit=false, loc=true, threadId=130, startTime=1537690615791,
> nodeId=dd46ab0e-ed28-4c67-b3c4-98900bb0, startVer=GridCacheVersion
> [topVer=149170604, order=1537690611182, nodeOrder=1], endVer=null,
> isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=500,
> sysInvalidate=false, sys=false, plc=2, commitVer=null, finalizing=NONE,
> invalidParts=null, state=ACTIVE, timedOut=false,
> topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
> txCounters=org.apache.ignite.internal.processors.cache.transactions.TxCounters@14d54c9c,
> duration=155ms, onePhaseCommit=false]IgniteTxLocalAdapter
> [completedBase=null, sndTransformedVals=false, depEnabled=false,
> txState=IgniteTxStateImpl [activeCacheIds=[], recovery=null,
> mvccEnabled=null, txMap=EmptySet []], mvccWaitTxs=null, qryEnlisted=false,
> super=, size=0]GridDhtTxLocalAdapter [nearOnOriginatingNode=false,
> nearNodes=KeySetView [], dhtNodes=KeySetView [], explicitLock=false,
> super=]GridNearTxLocal [mappings=IgniteTxMappingsImpl [],
> nearLocallyMapped=false, colocatedLocallyMapped=false, needCheckBackup=null,
> hasRemoteLocks=false, trackTimeout=true, lb=null, mvccTracker=null, sql=null,
> thread=tx-thread-2, mappings=IgniteTxMappingsImpl [], super=], async=false,
> asyncRes=null], key=2, cache=cache1]
> [2018-09-23 11:16:56,378][INFO
> ][exchange-worker-#38%transactions.TxPessimisticDeadlockDetectionCrossCacheTest0%][time]
> Started exchange init [topVer=AffinityTopologyVersion [topVer=2,
> minorTopVer=3], mvccCrd=MvccCoordinator
> [nodeId=dd46ab0e-ed28-4c67-b3c4-98900bb0, crdVer=1537690602134,
> topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0]],
> mvccCrdChange=false, crd=true, evt=DISCOVERY_CUSTOM_EVT,
> evtNode=dd46ab0e-ed28-4c67-b3c4-98900bb0,
>
[jira] [Updated] (IGNITE-9653) StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master branch
[
https://issues.apache.org/jira/browse/IGNITE-9653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9653:
--
Fix Version/s: (was: 2.9)
> StopNodeOrHaltFailureHandlerTest.testJvmHalted has flaky failures on master
> branch
> --
>
> Key: IGNITE-9653
> URL: https://issues.apache.org/jira/browse/IGNITE-9653
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Kuznetsov
>Priority: Major
>
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.failure.StopNodeOrHaltFailureHandlerTest.testJvmHalted(StopNodeOrHaltFailureHandlerTest.java:93)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9564) Ignite K8 service and sticky session with AWS K8 deployments
[ https://issues.apache.org/jira/browse/IGNITE-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9564: -- Fix Version/s: (was: 2.9) > Ignite K8 service and sticky session with AWS K8 deployments > > > Key: IGNITE-9564 > URL: https://issues.apache.org/jira/browse/IGNITE-9564 > Project: Ignite > Issue Type: Task >Reporter: Denis A. Magda >Assignee: Ilya Murchenko >Priority: Major > > _sessionAffinity_ parameter is not supported by AWS Kubernetes which causes > the failure of the standard Ignite service deployment: > http://apache-ignite-users.70518.x6.nabble.com/Error-installing-Ignite-on-K8s-td23999.html > See how Ignite service configuration have to be updated considering sticky > session capabilities of AWS: > https://aws.amazon.com/elasticloadbalancing/details/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9496) Add listenAsync method to GridFutureAdapter
[ https://issues.apache.org/jira/browse/IGNITE-9496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9496: -- Fix Version/s: (was: 2.9) > Add listenAsync method to GridFutureAdapter > --- > > Key: IGNITE-9496 > URL: https://issues.apache.org/jira/browse/IGNITE-9496 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Priority: Major > > Currently, there is no possibility to add an async listener to an internal > future with the possibility to choose an appropriate executor for such > listener. > This would be useful to change thread that will execute a future listener. > We should add listenAsync method to GridFutureAdapter and add the possibility > to set arbitrary submitter/executor for such listeners. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9494) Communication error resolver may be invoked when topology is under construction
[ https://issues.apache.org/jira/browse/IGNITE-9494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9494: -- Fix Version/s: (was: 2.9) > Communication error resolver may be invoked when topology is under > construction > --- > > Key: IGNITE-9494 > URL: https://issues.apache.org/jira/browse/IGNITE-9494 > Project: Ignite > Issue Type: Bug > Components: cache, zookeeper >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Priority: Major > > Zookeeper Discovery. > During massive node start and join to topology there can happen communication > error problems which can lead to invoking communication error resolver. > Communication error resolver initiates a peer-to-peer ping process on all > alive nodes. Youngest nodes in a cluster may have the not complete picture > about alive nodes in a cluster. This can lead to a situation, that youngest > node will not ping all available nodes, and the coordinator may decide that > those nodes have an unstable network and unexpectedly kill them. > We should throttle communication error resolver in case of massive node join > and give them a time to get the complete picture about topology. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9491) Exchange latch coordinator shouldn't be oldest node in a cluster
[ https://issues.apache.org/jira/browse/IGNITE-9491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9491: -- Fix Version/s: (was: 2.9) > Exchange latch coordinator shouldn't be oldest node in a cluster > > > Key: IGNITE-9491 > URL: https://issues.apache.org/jira/browse/IGNITE-9491 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > > Currently, we have a lot of components having coordinator election ability. > Each of these components is electing the oldest node as coordinator. It leads > to overloading the oldest node and may be a cause of delaying of some > processes. > The oldest node can have large inbound/outbound messages queue in large > topologies which leads to delaying of processing Exchange Latch Ack messages. > We should choose secondary oldest node as coordinator to unload the oldest > coordinator. This change will significantly accelerate exchange latch waiting > process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9444) TcpDiscoveryCloudIpFinderSelfTest.testRackspace fails in master
[
https://issues.apache.org/jira/browse/IGNITE-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9444:
--
Fix Version/s: (was: 2.9)
> TcpDiscoveryCloudIpFinderSelfTest.testRackspace fails in master
> ---
>
> Key: IGNITE-9444
> URL: https://issues.apache.org/jira/browse/IGNITE-9444
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Priority: Major
>
> Looks like something changed in the rackspace infrastructure, the test
> started to fail with {{java.util.NoSuchElementException: apiType compute not
> found in catalog []}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9449) Lazy unmarshalling of discovery events in TcpDiscovery
[ https://issues.apache.org/jira/browse/IGNITE-9449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9449: -- Fix Version/s: (was: 2.9) > Lazy unmarshalling of discovery events in TcpDiscovery > -- > > Key: IGNITE-9449 > URL: https://issues.apache.org/jira/browse/IGNITE-9449 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Kovalenko >Priority: Major > > Currently disco-msg-worker thread spend major part of time on disocvery > message unmarshalling before send it to the next node. In most cases this is > unnecessary and message can be send immediately after receiving and notyfing > discovery-event-worker. > Responsibility of unmarshalling should moved to discovery-event-worker thread > and this improvement will significantly reduce latency of sending custom > messages across ring. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9432) Investigate ability to make ScanQuery faster
[ https://issues.apache.org/jira/browse/IGNITE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9432: -- Fix Version/s: (was: 2.9) > Investigate ability to make ScanQuery faster > > > Key: IGNITE-9432 > URL: https://issues.apache.org/jira/browse/IGNITE-9432 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.7 >Reporter: Anton Dmitriev >Priority: Major > Labels: newbie, newbie++ > > When we make ScanQuery via Binary Client Protocol it works very slowly in > case we need to retrieve a big amount of objects (all objects in our case). > The most slower part is a waiting for response from Apache Ignite. This also > mentioned on devlist > [http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html]. > To reproduce the problem we've prepared a small example: > [slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer]. > In this example we creates a cache with 500 objects 1Mb each (on localhost), > we make ScanQuery with different page sizes and calculate time between the > moment when the request has been sent and the moment when the response is > ready to be receive. The measurements are here: > Page size 5 Mb, waiting time 119.85 ± 6.72 ms > Page size 10 Mb, waiting time 157.70 ± 15.35 ms > Page size 20 Mb, waiting time 204.50 ± 19.18 ms > Page size 50 Mb, waiting time 264.70 ± 22.30 ms > Page size 100 Mb, waiting time 463.35 ± 17.12 ms > Page size 150 Mb, waiting time 672.50 ± 21.98 ms > As result we spend ~4ms per every megabyte on _something_. It means that we > will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't > it? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13195) Allow skipping autotools invocation when building Ignite release
Alexey Goncharuk created IGNITE-13195:
-
Summary: Allow skipping autotools invocation when building Ignite
release
Key: IGNITE-13195
URL: https://issues.apache.org/jira/browse/IGNITE-13195
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
I do not have an up-to-date set of autotools installed on local machine, and
Apache Ignite release build fails locally with the following error:
{code}
main::scan_file() called too early to check prototype at /usr/local/bin/aclocal
line 617.
configure.ac:36: warning: macro `AM_PROG_AR' not found in library
configure.ac:21: error: Autoconf version 2.69 or higher is required
configure.ac:21: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal: autom4te failed with exit status: 63
{code}
I do not need to run these commands locally because I only need a quick
assembly (java only, even no javadocs) to verify the release structure and
command-line utilities integrity.
It would be great to move these commands to a separate profile (enabled by
default) so users can skip them when building the release package, something
like {{mvn initialize -Prelease -P!autotools}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13123) Move control.sh to a separate module
[
https://issues.apache.org/jira/browse/IGNITE-13123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147654#comment-17147654
]
Alexey Goncharuk commented on IGNITE-13123:
---
[~ktkale...@gridgain.com] the new module is not present in the binary release
which causes the {{control.sh}} to fail with
{code}
apache-ignite-2.9.0-SNAPSHOT-bin $ ./bin/control.sh --baseline
Error: Could not find or load main class
org.apache.ignite.internal.commandline.CommandHandler
Caused by: java.lang.ClassNotFoundException:
org.apache.ignite.internal.commandline.CommandHandler
{code}
Also, you need to pull the latest master (a new metadata command was added
there, this is a minor conflict).
Otherwise looks good, please fix the release assembly and I will merge this
change.
> Move control.sh to a separate module
>
>
> Key: IGNITE-13123
> URL: https://issues.apache.org/jira/browse/IGNITE-13123
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Move [1] and its associated classes to a separate "ignite-control-utility"
> module.
> [1] - org.apache.ignite.internal.commandline.CommandHandler
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13194) Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster()
Vladimir Steshin created IGNITE-13194: - Summary: Fix testNodeWithIncompatibleMetadataIsProhibitedToJoinTheCluster() Key: IGNITE-13194 URL: https://issues.apache.org/jira/browse/IGNITE-13194 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin Assignee: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-13192:
--
Description:
Start use thin client with compact footer equals true(setCompactFooter(true) ).
Create table through SQL. Then execut INSERT and put() with different id/key.
And then call method get() with id from INSERT. A BinaryObjectException will
occur. It is expected the value inserted through INSERT.
Reproducer:
{code:java}
@Test
public void testSql() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
) {
// 1. Create table
client.query(
new SqlFieldsQuery(String.format(
"CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
Person.class.getName(), "PersonCache"
)).setSchema("PUBLIC")
).getAll();
int key = 1;
Person val = new Person(key, "Person " + key);
// 2. INSERT value to cache
client.query(new SqlFieldsQuery("INSERT INTO Person(id, name) VALUES(?,
?)")
.setArgs(val.getId(), val.getName())
.setSchema("PUBLIC")
)
.getAll();
// 4. Execute put(). The key must be different from what was in INSERT
// Without this line, there will be no exception
client.getOrCreateCache("PersonCache").put(2, val);
// 5. Execute get(). There will be an exception:
org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for object
with compact footer
assertNotNull(client.getOrCreateCache("PersonCache").get(1));
}
}{code}
Decision:
{code:java}
+++
modules/core/src/main/java/org/apache/ignite/internal/client/thin/TcpIgniteClient.java
(date 1593418365270)
@@ -365,6 +365,11 @@
@Override public BinaryType metadata(int typeId, int schemaId) throws
BinaryObjectException {
BinaryType meta = metadata(typeId);
+if (meta != null &&
!((BinaryTypeImpl)meta).metadata().hasSchema(schemaId)) {
+cache.metadata().removeIf(t -> t.typeId() == typeId);
+meta = metadata(typeId);
+}
+
return meta != null &&
((BinaryTypeImpl)meta).metadata().hasSchema(schemaId) ? meta : null;
}{code}
was:
If use thin client with setCompactFooter(true)
Reproducer:
{code:java}
@Test
public void testSql() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
) {
// 1. Create table
client.query(
new SqlFieldsQuery(String.format(
"CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
Person.class.getName(), "PersonCache"
)).setSchema("PUBLIC")
).getAll();
int key = 1;
Person val = new Person(key, "Person " + key);
// 2. INSERT value to cache
client.query(new SqlFieldsQuery("INSERT INTO Person(id, name) VALUES(?,
?)")
.setArgs(val.getId(), val.getName())
.setSchema("PUBLIC")
)
.getAll();
// 4. Execute put(). The key must be different from what was in INSERT
// Without this line, there will be no exception
client.getOrCreateCache("PersonCache").put(2, val);
// 5. Execute get(). There will be an exception:
org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for object
with compact footer
assertNotNull(client.getOrCreateCache("PersonCache").get(1));
}
}{code}
Decision:
{code:java}
+++
modules/core/src/main/java/org/apache/ignite/internal/client/thin/TcpIgniteClient.java
(date 1593418365270)
@@ -365,6 +365,11 @@
@Override public BinaryType metadata(int typeId, int schemaId) throws
BinaryObjectException {
BinaryType meta = metadata(typeId);
+if (meta != null &&
!((BinaryTypeImpl)meta).metadata().hasSchema(schemaId)) {
+cache.metadata().removeIf(t -> t.typeId() == typeId);
+meta = metadata(typeId);
+}
+
return meta != null &&
((BinaryTypeImpl)meta).metadata().hasSchema(schemaId) ? meta : null;
}{code}
> Thin client with compactFooter: exception on get value after INSERT and put
>
[jira] [Commented] (IGNITE-13015) Use nano time in node failure detection.
[
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147624#comment-17147624
]
Anton Vinogradov commented on IGNITE-13015:
---
Merged to master.
Thanks for your contribution.
> Use nano time in node failure detection.
>
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: iep-45
> Fix For: 2.9
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Make sure node failure detection do not use:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> We should use nano time instead. Disadventages of current impl.:
> 1)System time has no quarantine of strict forward movement. System time
> can be adjusted, synchronized by NTP as example. This can lead to incorrect
> and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms
> *To fix*:
> {code:java}ServerImpl.lastRingMsgReceivedTime{code} should be nano.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13015) Use nano time in node failure detection.
[
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-13015:
--
Fix Version/s: 2.9
> Use nano time in node failure detection.
>
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: iep-45
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Make sure node failure detection do not use:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> We should use nano time instead. Disadventages of current impl.:
> 1)System time has no quarantine of strict forward movement. System time
> can be adjusted, synchronized by NTP as example. This can lead to incorrect
> and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms
> *To fix*:
> {code:java}ServerImpl.lastRingMsgReceivedTime{code} should be nano.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-13192:
--
Description:
If use thin client with setCompactFooter(true)
Reproducer:
{code:java}
@Test
public void testSql() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
) {
// 1. Create table
client.query(
new SqlFieldsQuery(String.format(
"CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
Person.class.getName(), "PersonCache"
)).setSchema("PUBLIC")
).getAll();
int key = 1;
Person val = new Person(key, "Person " + key);
// 2. INSERT value to cache
client.query(new SqlFieldsQuery("INSERT INTO Person(id, name) VALUES(?,
?)")
.setArgs(val.getId(), val.getName())
.setSchema("PUBLIC")
)
.getAll();
// 4. Execute put(). The key must be different from what was in INSERT
// Without this line, there will be no exception
client.getOrCreateCache("PersonCache").put(2, val);
// 5. Execute get(). There will be an exception:
org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for object
with compact footer
assertNotNull(client.getOrCreateCache("PersonCache").get(1));
}
}{code}
Decision:
{code:java}
+++
modules/core/src/main/java/org/apache/ignite/internal/client/thin/TcpIgniteClient.java
(date 1593418365270)
@@ -365,6 +365,11 @@
@Override public BinaryType metadata(int typeId, int schemaId) throws
BinaryObjectException {
BinaryType meta = metadata(typeId);
+if (meta != null &&
!((BinaryTypeImpl)meta).metadata().hasSchema(schemaId)) {
+cache.metadata().removeIf(t -> t.typeId() == typeId);
+meta = metadata(typeId);
+}
+
return meta != null &&
((BinaryTypeImpl)meta).metadata().hasSchema(schemaId) ? meta : null;
}{code}
was:
Reproducer:
{code:java}
@Test
public void testSql() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
) {
// 1. Create table
client.query(
new SqlFieldsQuery(String.format(
"CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
Person.class.getName(), "PersonCache"
)).setSchema("PUBLIC")
).getAll();
int key = 1;
Person val = new Person(key, "Person " + key);
// 2. INSERT value to cache
client.query(new SqlFieldsQuery("INSERT INTO Person(id, name) VALUES(?,
?)")
.setArgs(val.getId(), val.getName())
.setSchema("PUBLIC")
)
.getAll();
// 4. Execute put(). The key must be different from what was in INSERT
// Without this line, there will be no exception
client.getOrCreateCache("PersonCache").put(2, val);
// 5. Execute get(). There will be an exception:
org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for object
with compact footer
assertNotNull(client.getOrCreateCache("PersonCache").get(1));
}
}{code}
Decision:
{code:java}
+++
modules/core/src/main/java/org/apache/ignite/internal/client/thin/TcpIgniteClient.java
(date 1593418365270)
@@ -365,6 +365,11 @@
@Override public BinaryType metadata(int typeId, int schemaId) throws
BinaryObjectException {
BinaryType meta = metadata(typeId);
+if (meta != null &&
!((BinaryTypeImpl)meta).metadata().hasSchema(schemaId)) {
+cache.metadata().removeIf(t -> t.typeId() == typeId);
+meta = metadata(typeId);
+}
+
return meta != null &&
((BinaryTypeImpl)meta).metadata().hasSchema(schemaId) ? meta : null;
}{code}
> Thin client with compactFooter: exception on get value after INSERT and put
> ---
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>
[jira] [Created] (IGNITE-13193) Implement fallback to full partition rebalancing in case historical supplier failed to read all necessary data updates from WAL
Vyacheslav Koptilin created IGNITE-13193: Summary: Implement fallback to full partition rebalancing in case historical supplier failed to read all necessary data updates from WAL Key: IGNITE-13193 URL: https://issues.apache.org/jira/browse/IGNITE-13193 Project: Ignite Issue Type: Improvement Affects Versions: 2.8.1 Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin Historical rebalance may fail for several reasons: 1) WAL on supplier node is corrupted - the supplier will trigger a failure handler in the current implementation. 2) After iteration over WAL demander node didn't receive all updates to make MOVING partition up-to-date (resulting update counter didn't converge with expected update counter of OWNING partition) - demander will silently ignore lack of updates in the current implementation. Such behavior negatively affects the stability of the cluster: an inappropriate state of historical WAL is not a reason to fail a supplier node. The more proper way to handle this scenario is: - Either try to rebalance partition historically from another supplier - Or use full partition rebalance for problem partition Once the supplier fails to provide data from part of the WAL, its corresponding sequence of checkpoints should be marked as inapplicable for historical rebalance in order to prevent further errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-13192:
--
Description:
Reproducer:
{code:java}
@Test
public void testSql() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
) {
// 1. Create table
client.query(
new SqlFieldsQuery(String.format(
"CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
Person.class.getName(), "PersonCache"
)).setSchema("PUBLIC")
).getAll();
int key = 1;
Person val = new Person(key, "Person " + key);
// 2. INSERT value to cache
client.query(new SqlFieldsQuery("INSERT INTO Person(id, name) VALUES(?,
?)")
.setArgs(val.getId(), val.getName())
.setSchema("PUBLIC")
)
.getAll();
// 4. Execute put(). The key must be different from what was in INSERT
// Without this line, there will be no exception
client.getOrCreateCache("PersonCache").put(2, val);
// 5. Execute get(). There will be an exception:
org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for object
with compact footer
assertNotNull(client.getOrCreateCache("PersonCache").get(1));
}
}{code}
Decision:
{code:java}
+++
modules/core/src/main/java/org/apache/ignite/internal/client/thin/TcpIgniteClient.java
(date 1593418365270)
@@ -365,6 +365,11 @@
@Override public BinaryType metadata(int typeId, int schemaId) throws
BinaryObjectException {
BinaryType meta = metadata(typeId);
+if (meta != null &&
!((BinaryTypeImpl)meta).metadata().hasSchema(schemaId)) {
+cache.metadata().removeIf(t -> t.typeId() == typeId);
+meta = metadata(typeId);
+}
+
return meta != null &&
((BinaryTypeImpl)meta).metadata().hasSchema(schemaId) ? meta : null;
}{code}
was:
Reproducer:
{code:java}
@Test
public void testSql() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
) {
// 1. Create table
client.query(
new SqlFieldsQuery(String.format(
"CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
Person.class.getName(), "PersonCache"
)).setSchema("PUBLIC")
).getAll();
int key = 1;
Person val = new Person(key, "Person " + key);
// 2. INSERT value to cache
client.query(new SqlFieldsQuery("INSERT INTO Person(id, name) VALUES(?,
?)")
.setArgs(val.getId(), val.getName())
.setSchema("PUBLIC")
)
.getAll();
// 4. Execute put(). The key must be different from what was in INSERT
// Without this line, there will be no exception
client.getOrCreateCache("PersonCache").put(2, val);
// 5. Execute get(). There will be an exception:
org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for object
with compact footer
assertNotNull(client.getOrCreateCache("PersonCache").get(1));
}
}{code}
> Thin client with compactFooter: exception on get value after INSERT and put
> ---
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Surkov Aleksandr
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR)
[jira] [Updated] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13192:
---
Labels: (was: Thin)
> Thin client with compactFooter: exception on get value after INSERT and put
> ---
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Surkov Aleksandr
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
> Person.class.getName(), "PersonCache"
> )).setSchema("PUBLIC")
> ).getAll();
> int key = 1;
> Person val = new Person(key, "Person " + key);
>
> // 2. INSERT value to cache
> client.query(new SqlFieldsQuery("INSERT INTO Person(id, name)
> VALUES(?, ?)")
> .setArgs(val.getId(), val.getName())
> .setSchema("PUBLIC")
> )
> .getAll();
>
> // 4. Execute put(). The key must be different from what was in INSERT
> // Without this line, there will be no exception
> client.getOrCreateCache("PersonCache").put(2, val);
> // 5. Execute get(). There will be an exception:
> org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
> object with compact footer
> assertNotNull(client.getOrCreateCache("PersonCache").get(1));
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-13192:
--
Labels: Thin (was: thin)
> Thin client with compactFooter: exception on get value after INSERT and put
> ---
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Surkov Aleksandr
>Priority: Major
> Labels: Thin
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
> Person.class.getName(), "PersonCache"
> )).setSchema("PUBLIC")
> ).getAll();
> int key = 1;
> Person val = new Person(key, "Person " + key);
>
> // 2. INSERT value to cache
> client.query(new SqlFieldsQuery("INSERT INTO Person(id, name)
> VALUES(?, ?)")
> .setArgs(val.getId(), val.getName())
> .setSchema("PUBLIC")
> )
> .getAll();
>
> // 4. Execute put(). The key must be different from what was in INSERT
> // Without this line, there will be no exception
> client.getOrCreateCache("PersonCache").put(2, val);
> // 5. Execute get(). There will be an exception:
> org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
> object with compact footer
> assertNotNull(client.getOrCreateCache("PersonCache").get(1));
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13192:
---
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Thin client with compactFooter: exception on get value after INSERT and put
> ---
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Surkov Aleksandr
>Priority: Major
> Labels: Thin
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
> Person.class.getName(), "PersonCache"
> )).setSchema("PUBLIC")
> ).getAll();
> int key = 1;
> Person val = new Person(key, "Person " + key);
>
> // 2. INSERT value to cache
> client.query(new SqlFieldsQuery("INSERT INTO Person(id, name)
> VALUES(?, ?)")
> .setArgs(val.getId(), val.getName())
> .setSchema("PUBLIC")
> )
> .getAll();
>
> // 4. Execute put(). The key must be different from what was in INSERT
> // Without this line, there will be no exception
> client.getOrCreateCache("PersonCache").put(2, val);
> // 5. Execute get(). There will be an exception:
> org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
> object with compact footer
> assertNotNull(client.getOrCreateCache("PersonCache").get(1));
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13192:
---
Labels: thin (was: )
> Thin client with compactFooter: exception on get value after INSERT and put
> ---
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
>Reporter: Surkov Aleksandr
>Priority: Major
> Labels: thin
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
> Person.class.getName(), "PersonCache"
> )).setSchema("PUBLIC")
> ).getAll();
> int key = 1;
> Person val = new Person(key, "Person " + key);
>
> // 2. INSERT value to cache
> client.query(new SqlFieldsQuery("INSERT INTO Person(id, name)
> VALUES(?, ?)")
> .setArgs(val.getId(), val.getName())
> .setSchema("PUBLIC")
> )
> .getAll();
>
> // 4. Execute put(). The key must be different from what was in INSERT
> // Without this line, there will be no exception
> client.getOrCreateCache("PersonCache").put(2, val);
> // 5. Execute get(). There will be an exception:
> org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
> object with compact footer
> assertNotNull(client.getOrCreateCache("PersonCache").get(1));
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13192:
---
Component/s: thin client
> Thin client with compactFooter: exception on get value after INSERT and put
> ---
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Surkov Aleksandr
>Priority: Major
> Labels: thin
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
> Person.class.getName(), "PersonCache"
> )).setSchema("PUBLIC")
> ).getAll();
> int key = 1;
> Person val = new Person(key, "Person " + key);
>
> // 2. INSERT value to cache
> client.query(new SqlFieldsQuery("INSERT INTO Person(id, name)
> VALUES(?, ?)")
> .setArgs(val.getId(), val.getName())
> .setSchema("PUBLIC")
> )
> .getAll();
>
> // 4. Execute put(). The key must be different from what was in INSERT
> // Without this line, there will be no exception
> client.getOrCreateCache("PersonCache").put(2, val);
> // 5. Execute get(). There will be an exception:
> org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
> object with compact footer
> assertNotNull(client.getOrCreateCache("PersonCache").get(1));
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-13192:
--
Assignee: Aleksey Plekhanov
> Thin client with compactFooter: exception on get value after INSERT and put
> ---
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Surkov Aleksandr
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: Thin
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
> Person.class.getName(), "PersonCache"
> )).setSchema("PUBLIC")
> ).getAll();
> int key = 1;
> Person val = new Person(key, "Person " + key);
>
> // 2. INSERT value to cache
> client.query(new SqlFieldsQuery("INSERT INTO Person(id, name)
> VALUES(?, ?)")
> .setArgs(val.getId(), val.getName())
> .setSchema("PUBLIC")
> )
> .getAll();
>
> // 4. Execute put(). The key must be different from what was in INSERT
> // Without this line, there will be no exception
> client.getOrCreateCache("PersonCache").put(2, val);
> // 5. Execute get(). There will be an exception:
> org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
> object with compact footer
> assertNotNull(client.getOrCreateCache("PersonCache").get(1));
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Thin client with compactFooter: exception on get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-13192:
--
Summary: Thin client with compactFooter: exception on get value after
INSERT and put (was: Get value after INSERT and put)
> Thin client with compactFooter: exception on get value after INSERT and put
> ---
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
>Reporter: Surkov Aleksandr
>Priority: Major
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
> Person.class.getName(), "PersonCache"
> )).setSchema("PUBLIC")
> ).getAll();
> int key = 1;
> Person val = new Person(key, "Person " + key);
>
> // 2. INSERT value to cache
> client.query(new SqlFieldsQuery("INSERT INTO Person(id, name)
> VALUES(?, ?)")
> .setArgs(val.getId(), val.getName())
> .setSchema("PUBLIC")
> )
> .getAll();
>
> // 4. Execute put(). The key must be different from what was in INSERT
> // Without this line, there will be no exception
> client.getOrCreateCache("PersonCache").put(2, val);
> // 5. Execute get(). There will be an exception:
> org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
> object with compact footer
> assertNotNull(client.getOrCreateCache("PersonCache").get(1));
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-13192:
--
Priority: Major (was: Critical)
> Get value after INSERT and put
> --
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
>Reporter: Surkov Aleksandr
>Priority: Major
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
> Person.class.getName(), "PersonCache"
> )).setSchema("PUBLIC")
> ).getAll();
> int key = 1;
> Person val = new Person(key, "Person " + key);
>
> // 2. INSERT value to cache
> client.query(new SqlFieldsQuery("INSERT INTO Person(id, name)
> VALUES(?, ?)")
> .setArgs(val.getId(), val.getName())
> .setSchema("PUBLIC")
> )
> .getAll();
>
> // 4. Execute put(). The key must be different from what was in INSERT
> // Without this line, there will be no exception
> client.getOrCreateCache("PersonCache").put(2, val);
> // 5. Execute get(). There will be an exception:
> org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
> object with compact footer
> assertNotNull(client.getOrCreateCache("PersonCache").get(1));
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13192) Get value after INSERT and put
[
https://issues.apache.org/jira/browse/IGNITE-13192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-13192:
--
Description:
Reproducer:
{code:java}
@Test
public void testSql() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
) {
// 1. Create table
client.query(
new SqlFieldsQuery(String.format(
"CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
Person.class.getName(), "PersonCache"
)).setSchema("PUBLIC")
).getAll();
int key = 1;
Person val = new Person(key, "Person " + key);
// 2. INSERT value to cache
client.query(new SqlFieldsQuery("INSERT INTO Person(id, name) VALUES(?,
?)")
.setArgs(val.getId(), val.getName())
.setSchema("PUBLIC")
)
.getAll();
// 4. Execute put(). The key must be different from what was in INSERT
// Without this line, there will be no exception
client.getOrCreateCache("PersonCache").put(2, val);
// 5. Execute get(). There will be an exception:
org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for object
with compact footer
assertNotNull(client.getOrCreateCache("PersonCache").get(1));
}
}{code}
was:
Reproducer:
{code:java}
@Test
public void testSql() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
) {
// 1. Create table
client.query(
new SqlFieldsQuery(String.format(
"CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
Person.class.getName(), "PersonCache"
)).setSchema("PUBLIC")
).getAll();
int key = 1;
Person val = new Person(key, "Person " + key);
// 2. INSERT value to cache
client.query(new SqlFieldsQuery("INSERT INTO Person(id, name) VALUES(?,
?)")
.setArgs(val.getId(), val.getName())
.setSchema("PUBLIC")
)
.getAll();
// 4. Execute put()
// Without this line, there will be no exception
client.getOrCreateCache("PersonCache").put(2, val);
// 5. Execute get(). There will be an exception:
org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for object
with compact footer
assertNotNull(client.getOrCreateCache("PersonCache").get(1));
}
}{code}
> Get value after INSERT and put
> --
>
> Key: IGNITE-13192
> URL: https://issues.apache.org/jira/browse/IGNITE-13192
> Project: Ignite
> Issue Type: Bug
>Reporter: Surkov Aleksandr
>Priority: Critical
>
> Reproducer:
> {code:java}
> @Test
> public void testSql() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
> ) {
> // 1. Create table
> client.query(
> new SqlFieldsQuery(String.format(
> "CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
> VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
> Person.class.getName(), "PersonCache"
> )).setSchema("PUBLIC")
> ).getAll();
> int key = 1;
> Person val = new Person(key, "Person " + key);
>
> // 2. INSERT value to cache
> client.query(new SqlFieldsQuery("INSERT INTO Person(id, name)
> VALUES(?, ?)")
> .setArgs(val.getId(), val.getName())
> .setSchema("PUBLIC")
> )
> .getAll();
>
> // 4. Execute put(). The key must be different from what was in INSERT
> // Without this line, there will be no exception
> client.getOrCreateCache("PersonCache").put(2, val);
> // 5. Execute get(). There will be an exception:
> org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
> object with compact footer
>
[jira] [Created] (IGNITE-13192) Get value after INSERT and put
Surkov Aleksandr created IGNITE-13192:
-
Summary: Get value after INSERT and put
Key: IGNITE-13192
URL: https://issues.apache.org/jira/browse/IGNITE-13192
Project: Ignite
Issue Type: Bug
Reporter: Surkov Aleksandr
Reproducer:
{code:java}
@Test
public void testSql() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
Ignite ignored2 = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)).setAddresses(Config.SERVER))
) {
// 1. Create table
client.query(
new SqlFieldsQuery(String.format(
"CREATE TABLE IF NOT EXISTS Person (id INT PRIMARY KEY, name
VARCHAR) WITH \"VALUE_TYPE=%s,CACHE_NAME=%s\"",
Person.class.getName(), "PersonCache"
)).setSchema("PUBLIC")
).getAll();
int key = 1;
Person val = new Person(key, "Person " + key);
// 2. INSERT value to cache
client.query(new SqlFieldsQuery("INSERT INTO Person(id, name) VALUES(?,
?)")
.setArgs(val.getId(), val.getName())
.setSchema("PUBLIC")
)
.getAll();
// 4. Execute put()
// Without this line, there will be no exception
client.getOrCreateCache("PersonCache").put(2, val);
// 5. Execute get(). There will be an exception:
org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for object
with compact footer
assertNotNull(client.getOrCreateCache("PersonCache").get(1));
}
}{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Reviewer: Alexey Scherbakov
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> {noformat}
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but minimum present counter is less than maximum
> reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
> maxReservedNodeId=ID], ...]{noformat}
> ## We can also aggregate previous message by (minNodeId) to easily find the
> exact node (or nodes) which were the reason of full rebalance.
> # Log results of {{reserveHistoryForExchange()}}. They can be compactly
> represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
> group, also log message about why the previous checkpoint wasn't successfully
> reserved.
> There can be three reasons:
> ## Previous checkpoint simply isn't present in the history (the oldest is
> reserved)
> ## WAL reservation failure (call below returned false)
> {code:java}
> chpEntry = entry(cpTs);
> boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
> checkpoint WAL history can't be reserved, stop searching.
> if (!reserved)
> break;{code}
> ## Checkpoint was marked as inapplicable for historical rebalancing
> {code:java}
> for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
> if (!isCheckpointApplicableForGroup(grpId, chpEntry))
> groupsAndPartitions.remove(grpId);{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13151) Checkpointer code refactoring: extracting classes from GridCacheDatabaseSharedManager
[ https://issues.apache.org/jira/browse/IGNITE-13151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147600#comment-17147600 ] Sergey Chugunov commented on IGNITE-13151: -- [~akalashnikov], As far as I understand, this patch just moves checkpointer code and related interfaces outside of GridCacheDatabaseSharedManager class, no structural refactoring was made. >From that perspective change looks good to me. How do you estimate risks of merging it to master before upcoming 2.9 release? > Checkpointer code refactoring: extracting classes from > GridCacheDatabaseSharedManager > - > > Key: IGNITE-13151 > URL: https://issues.apache.org/jira/browse/IGNITE-13151 > Project: Ignite > Issue Type: Sub-task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Anton Kalashnikov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Checkpointer is at the center of Ignite persistence subsystem and more people > from the community understand it the better means it is more stable and more > efficient. > However for now checkpointer code sits inside of > GridCacheDatabaseSharedManager class and is entangled with this higher-level > and more general component. > To take a step forward to more modular checkpointer we need to do two things: > # Move checkpointer code outside database manager to a separate class. > (That's what this ticket is about.) > # Create a well-defined API of checkpointer that will allow us to create new > implementations of checkpointer in the future. An example of this is new > checkpointer implementation needed for defragmentation feature purposes. > (Should be done in a separate ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
