[jira] [Resolved] (IGNITE-13116) CPP: Can not compile using msvc 14.1
[ https://issues.apache.org/jira/browse/IGNITE-13116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego resolved IGNITE-13116. -- Resolution: Duplicate Resolved by IGNITE-13174 > CPP: Can not compile using msvc 14.1 > > > Key: IGNITE-13116 > URL: https://issues.apache.org/jira/browse/IGNITE-13116 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > There are linking errors when trying to build Ignite C++ with msvc 15. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13441) Cache (Restarts) 1 failed with Execution timeout
[ https://issues.apache.org/jira/browse/IGNITE-13441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov reassigned IGNITE-13441: -- Assignee: Alexey Scherbakov > Cache (Restarts) 1 failed with Execution timeout > > > Key: IGNITE-13441 > URL: https://issues.apache.org/jira/browse/IGNITE-13441 > Project: Ignite > Issue Type: Task >Reporter: Nikita Tolstunov >Assignee: Alexey Scherbakov >Priority: Major > > Suite [Cache(Restarts) > 1|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CacheRestarts1?branch=%3Cdefault%3E=builds] > regularly fails with execution timeout. > I found that in some cases > IgniteCacheNearRestartRollbackSelfTest#testRestarts caused it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache's operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Summary: Cache's operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ. (was: Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.) > Cache's operation getAndXXX doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > - > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndXXX_ operation is executed. > A transaction cache works fine. > _getAndXXX_ contains: > * _getAndPut_ > * _getAndPutAsync_ > * _getAndPutIfAbsent_ > * _getAndPutIfAbsentAsync_ > * _getAndRemove_ > * _getAndRemoveAsync_ > * _getAndReplace_ > * _getAndReplaceAsync_ > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12968) Create cluster snapshot documentation pages
[ https://issues.apache.org/jira/browse/IGNITE-12968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204034#comment-17204034 ] Denis A. Magda commented on IGNITE-12968: - [~mmuzaf], sure, feel free to close it. > Create cluster snapshot documentation pages > --- > > Key: IGNITE-12968 > URL: https://issues.apache.org/jira/browse/IGNITE-12968 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Blocker > Labels: iep-43, important > Fix For: 2.9 > > Time Spent: 8h > Remaining Estimate: 0h > > Add the following to the Apache Ignite documentation: > 1. How to create a cluster snapshot (describe API, limitations) > 2. How to configure a destination directory > 3. Manual steps for a snapshot restore > 4. Examples -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
[
https://issues.apache.org/jira/browse/IGNITE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204028#comment-17204028
]
Ivan Daschinskiy commented on IGNITE-13491:
---
[~surkov] Looks good to me, lets obtain the bot's visa.
> Fix incorrect topology snapshot logger output about coordinator change.
> ---
>
> Key: IGNITE-13491
> URL: https://issues.apache.org/jira/browse/IGNITE-13491
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Surkov Aleksandr
>Priority: Minor
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, logic in
> {{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
> has major drawback, in condition we don't check that failed node with order
> less than oldest server node, is actually server node. So we can see invalid
> message about coordinator change, even though previous node was a client.
> Reproducer:
> 1. Start server #1
> 2. Start client
> 3. Start server #2
> 4. Stop server #2 and client
> We will see in logs of server #2 something like this:
> {{[2020-09-29 10:41:25,909][INFO
> ][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%|#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
> Coordinator changed [prev=TcpDiscoveryNode
> [id=371896fb-f612-4640-bfcd-cef6d281,
> consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2,
> intOrder=2, lastExchangeTime=1601365285287, loc=false,
> ver=2.10.0#20200929-sha1:, *isClient=true*], cur=TcpDiscoveryNode
> [id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900,
> loc=true, ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13499) Reconnected node sends old id as security subject id
[ https://issues.apache.org/jira/browse/IGNITE-13499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17203941#comment-17203941 ] Stepachev Maksim commented on IGNITE-13499: --- [https://github.com/apache/ignite/pull/8290] > Reconnected node sends old id as security subject id > > > Key: IGNITE-13499 > URL: https://issues.apache.org/jira/browse/IGNITE-13499 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.8.1 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.9 > > > After reconnection a client node send old security subject id. We must > invalidate inner structures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13499) Reconnected node sends old id as security subject id
Stepachev Maksim created IGNITE-13499: - Summary: Reconnected node sends old id as security subject id Key: IGNITE-13499 URL: https://issues.apache.org/jira/browse/IGNITE-13499 Project: Ignite Issue Type: Bug Components: security Affects Versions: 2.8.1 Reporter: Stepachev Maksim Assignee: Stepachev Maksim Fix For: 2.9 After reconnection a client node send old security subject id. We must invalidate inner structures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13488) Add command to control.(sh|bin) to get an arbitrary Metric
[
https://issues.apache.org/jira/browse/IGNITE-13488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-13488:
Description:
It's needed to add the ability to get an arbitrary Metric via control.(sh|bin)
script.
If name of the metric registry is passed, value of all its metrics should be
printed.
Proposed command structure:
{code:java}
control.(sh|bat) --metric [--node-id node_id] name
Parameters:
name - Name of the metric which value should be printed. If name of
the metric registry is specified, value of all its metrics will be printed.
node_id - ID of the node to get the metric value from. If not set,
random node will be chosen.
{code}
was:
It's needed to add the ability to get an arbitrary Metric via control.(sh|bin)
script.
If name of the metric registry is specified, value of all its metrics should be
printed.
Proposed command structure:
{code:java}
control.(sh|bat) --metric [--node-id node_id] name
Parameters:
name - Name of the metric which value should be printed. If name of
the metric registry is specified, value of all its metrics will be printed.
node_id - ID of the node to get the metric value from. If not set,
random node will be chosen.
{code}
> Add command to control.(sh|bin) to get an arbitrary Metric
> --
>
> Key: IGNITE-13488
> URL: https://issues.apache.org/jira/browse/IGNITE-13488
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's needed to add the ability to get an arbitrary Metric via
> control.(sh|bin) script.
> If name of the metric registry is passed, value of all its metrics should be
> printed.
> Proposed command structure:
> {code:java}
> control.(sh|bat) --metric [--node-id node_id] name
> Parameters:
> name - Name of the metric which value should be printed. If name of
> the metric registry is specified, value of all its metrics will be printed.
> node_id - ID of the node to get the metric value from. If not set,
> random node will be chosen.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13488) Add command to control.(sh|bin) to get an arbitrary Metric
[
https://issues.apache.org/jira/browse/IGNITE-13488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-13488:
Description:
It's needed to add the ability to get an arbitrary Metric via control.(sh|bin)
script.
If name of the metric registry is specified, value of all its metrics should be
printed.
Proposed command structure:
{code:java}
control.(sh|bat) --metric [--node-id node_id] name
Parameters:
name - Name of the metric which value should be printed. If name of
the metric registry is specified, value of all its metrics will be printed.
node_id - ID of the node to get the metric value from. If not set,
random node will be chosen.
{code}
was:
It's needed to add the ability to get an arbitrary Metric via control.(sh|bin)
script.
Proposed command structure:
{code:java}
control.(sh|bin) --metric [–node-id node_id] metric_name
Parameters:
metric_name - Name of the metric which value is requested.
node_id- ID of the node to get the metric value
from.
If not set, random node will be chosen.
{code}
> Add command to control.(sh|bin) to get an arbitrary Metric
> --
>
> Key: IGNITE-13488
> URL: https://issues.apache.org/jira/browse/IGNITE-13488
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's needed to add the ability to get an arbitrary Metric via
> control.(sh|bin) script.
> If name of the metric registry is specified, value of all its metrics should
> be printed.
> Proposed command structure:
> {code:java}
> control.(sh|bat) --metric [--node-id node_id] name
> Parameters:
> name - Name of the metric which value should be printed. If name of
> the metric registry is specified, value of all its metrics will be printed.
> node_id - ID of the node to get the metric value from. If not set,
> random node will be chosen.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13498) Thin client throws "unexpected response id" when timeout is too small
Ilya Kasnacheev created IGNITE-13498:
Summary: Thin client throws "unexpected response id" when timeout
is too small
Key: IGNITE-13498
URL: https://issues.apache.org/jira/browse/IGNITE-13498
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.8.1
Reporter: Ilya Kasnacheev
Reportedly, if you set Java thin client timeout to 50 (ms), it will start
throwing the following exceptions:
{code}
Exception: Unexpected response ID [3630521808404506928], [5259] was expected
at
org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:160)
at
org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:126)
at
org.apache.ignite.internal.client.thin.TcpClientCache.getAll(TcpClientCache.java:165)
{code}
It is expected that it will throw timeout exceptions instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12968) Create cluster snapshot documentation pages
[ https://issues.apache.org/jira/browse/IGNITE-12968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17203902#comment-17203902 ] Maxim Muzafarov commented on IGNITE-12968: -- [~dmagda] Can I resolve the issue? > Create cluster snapshot documentation pages > --- > > Key: IGNITE-12968 > URL: https://issues.apache.org/jira/browse/IGNITE-12968 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Blocker > Labels: iep-43, important > Fix For: 2.9 > > Time Spent: 8h > Remaining Estimate: 0h > > Add the following to the Apache Ignite documentation: > 1. How to create a cluster snapshot (describe API, limitations) > 2. How to configure a destination directory > 3. Manual steps for a snapshot restore > 4. Examples -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
[
https://issues.apache.org/jira/browse/IGNITE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-13491:
--
Description:
Currently, logic in
{{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
has major drawback, in condition we don't check that failed node with order
less than oldest server node, is actually server node. So we can see invalid
message about coordinator change, even though previous node was a client.
Reproducer:
1. Start server #1
2. Start client
3. Start server #1
4. Stop server #2 and client
We will see in logs of server #2 something like this:
{{[2020-09-29 10:41:25,909][INFO
][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%|#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
Coordinator changed [prev=TcpDiscoveryNode
[id=371896fb-f612-4640-bfcd-cef6d281,
consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2, intOrder=2,
lastExchangeTime=1601365285287, loc=false, ver=2.10.0#20200929-sha1:,
*isClient=true*], cur=TcpDiscoveryNode
[id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900, loc=true,
ver=2.10.0#20200929-sha1:, isClient=false]]}}
was:
Currently, logic in
{{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
has major drawback, in condition we don't check that failed node with order
less than oldest server node, is actually server node. So we can see invalid
message about coordinator change, even though previous node was a client.
Reproducer:
1. Start server #1
2. Start client
3. Start server #1
4. Stop server #1 and client
We will see in logs of server #2 something like this:
{{[2020-09-29 10:41:25,909][INFO
][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
Coordinator changed [prev=TcpDiscoveryNode
[id=371896fb-f612-4640-bfcd-cef6d281,
consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2, intOrder=2,
lastExchangeTime=1601365285287, loc=false, ver=2.10.0#20200929-sha1:,
*isClient=true*], cur=TcpDiscoveryNode
[id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900, loc=true,
ver=2.10.0#20200929-sha1:, isClient=false]]}}
> Fix incorrect topology snapshot logger output about coordinator change.
> ---
>
> Key: IGNITE-13491
> URL: https://issues.apache.org/jira/browse/IGNITE-13491
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Surkov Aleksandr
>Priority: Minor
> Labels: newbie
> Fix For: 2.10
>
>
> Currently, logic in
> {{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
> has major drawback, in condition we don't check that failed node with order
> less than oldest server node, is actually server node. So we can see invalid
> message about coordinator change, even though previous node was a client.
> Reproducer:
> 1. Start server #1
> 2. Start client
> 3. Start server #1
> 4. Stop server #2 and client
> We will see in logs of server #2 something like this:
> {{[2020-09-29 10:41:25,909][INFO
> ][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%|#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
> Coordinator changed [prev=TcpDiscoveryNode
> [id=371896fb-f612-4640-bfcd-cef6d281,
> consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2,
> intOrder=2, lastExchangeTime=1601365285287, loc=false,
> ver=2.10.0#20200929-sha1:, *isClient=true*], cur=TcpDiscoveryNode
> [id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900,
> loc=true, ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
[
https://issues.apache.org/jira/browse/IGNITE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-13491:
--
Description:
Currently, logic in
{{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
has major drawback, in condition we don't check that failed node with order
less than oldest server node, is actually server node. So we can see invalid
message about coordinator change, even though previous node was a client.
Reproducer:
1. Start server #1
2. Start client
3. Start server #2
4. Stop server #2 and client
We will see in logs of server #2 something like this:
{{[2020-09-29 10:41:25,909][INFO
][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%|#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
Coordinator changed [prev=TcpDiscoveryNode
[id=371896fb-f612-4640-bfcd-cef6d281,
consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2, intOrder=2,
lastExchangeTime=1601365285287, loc=false, ver=2.10.0#20200929-sha1:,
*isClient=true*], cur=TcpDiscoveryNode
[id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900, loc=true,
ver=2.10.0#20200929-sha1:, isClient=false]]}}
was:
Currently, logic in
{{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
has major drawback, in condition we don't check that failed node with order
less than oldest server node, is actually server node. So we can see invalid
message about coordinator change, even though previous node was a client.
Reproducer:
1. Start server #1
2. Start client
3. Start server #1
4. Stop server #2 and client
We will see in logs of server #2 something like this:
{{[2020-09-29 10:41:25,909][INFO
][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%|#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
Coordinator changed [prev=TcpDiscoveryNode
[id=371896fb-f612-4640-bfcd-cef6d281,
consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2, intOrder=2,
lastExchangeTime=1601365285287, loc=false, ver=2.10.0#20200929-sha1:,
*isClient=true*], cur=TcpDiscoveryNode
[id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900, loc=true,
ver=2.10.0#20200929-sha1:, isClient=false]]}}
> Fix incorrect topology snapshot logger output about coordinator change.
> ---
>
> Key: IGNITE-13491
> URL: https://issues.apache.org/jira/browse/IGNITE-13491
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Surkov Aleksandr
>Priority: Minor
> Labels: newbie
> Fix For: 2.10
>
>
> Currently, logic in
> {{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
> has major drawback, in condition we don't check that failed node with order
> less than oldest server node, is actually server node. So we can see invalid
> message about coordinator change, even though previous node was a client.
> Reproducer:
> 1. Start server #1
> 2. Start client
> 3. Start server #2
> 4. Stop server #2 and client
> We will see in logs of server #2 something like this:
> {{[2020-09-29 10:41:25,909][INFO
> ][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%|#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
> Coordinator changed [prev=TcpDiscoveryNode
> [id=371896fb-f612-4640-bfcd-cef6d281,
> consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2,
> intOrder=2, lastExchangeTime=1601365285287, loc=false,
> ver=2.10.0#20200929-sha1:, *isClient=true*], cur=TcpDiscoveryNode
> [id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900,
> loc=true, ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13489) Client nodes start-stop ducktape tests
[ https://issues.apache.org/jira/browse/IGNITE-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Sviridov reassigned IGNITE-13489: - Assignee: Mikhail Sviridov > Client nodes start-stop ducktape tests > -- > > Key: IGNITE-13489 > URL: https://issues.apache.org/jira/browse/IGNITE-13489 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Mikhail Sviridov >Priority: Major > Labels: IEP-56, ducktape > > Connection of the client node to the cluster trigger PME. > So it's not free for the whole cluster. > We should check the correctness and impact of the start-stop client node > events to the cluster and it's stability: > The test scenario can be the following: > # Start cluster of X server nodes. > # Start Y client nodes that stable and perform some operation with the data. > # N time from M nodes start client node, do some operation, and stops it > after K seconds. >We should be able to switch [kill, stop gracefully] with some test > parameter. > Should check that all client nodes connect to the cluster successfully. > Should measure operation latency and throughput for stable client nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
[
https://issues.apache.org/jira/browse/IGNITE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr reassigned IGNITE-13491:
-
Assignee: Surkov Aleksandr
> Fix incorrect topology snapshot logger output about coordinator change.
> ---
>
> Key: IGNITE-13491
> URL: https://issues.apache.org/jira/browse/IGNITE-13491
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Surkov Aleksandr
>Priority: Minor
> Labels: newbie
> Fix For: 2.10
>
>
> Currently, logic in
> {{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
> has major drawback, in condition we don't check that failed node with order
> less than oldest server node, is actually server node. So we can see invalid
> message about coordinator change, even though previous node was a client.
> Reproducer:
> 1. Start server #1
> 2. Start client
> 3. Start server #1
> 4. Stop server #1 and client
> We will see in logs of server #2 something like this:
> {{[2020-09-29 10:41:25,909][INFO
> ][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
> Coordinator changed [prev=TcpDiscoveryNode
> [id=371896fb-f612-4640-bfcd-cef6d281,
> consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2,
> intOrder=2, lastExchangeTime=1601365285287, loc=false,
> ver=2.10.0#20200929-sha1:, *isClient=true*], cur=TcpDiscoveryNode
> [id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900,
> loc=true, ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-12633) Calcite integration. Query cancel purpose.
[ https://issues.apache.org/jira/browse/IGNITE-12633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-12633. --- Resolution: Implemented Done in scope of IGNITE-13198 > Calcite integration. Query cancel purpose. > -- > > Key: IGNITE-12633 > URL: https://issues.apache.org/jira/browse/IGNITE-12633 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Igor Seliverstov >Assignee: Ravil Galeyev >Priority: Minor > > Currently on a query participant node left whole query is cancelled, but the > end user doesn't know the purpose. We should pass causing cancel exception to > end user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndXXX_ operation is executed. A transaction cache works fine. _getAndXXX_ contains: * _getAndPut_ * _getAndPutAsync_ * _getAndPutIfAbsent_ * _getAndPutIfAbsentAsync_ * _getAndRemove_ * _getAndRemoveAsync_ * _getAndReplace_ * _getAndReplaceAsync_ The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndXXX_ operation is executed. A transaction cache works fine. _getAndXXX_ contains_:_ * _getAndPut_ * _getAndPutAsync_ * _getAndPutIfAbsent_ * _getAndPutIfAbsentAsync_ * _getAndRemove_ * _getAndRemoveAsync_ * _getAndReplace_ * _getAndReplaceAsync_ The reproducer is in the attachment. > Cache operation getAndXXX doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndXXX_ operation is executed. > A transaction cache works fine. > _getAndXXX_ contains: > * _getAndPut_ > * _getAndPutAsync_ > * _getAndPutIfAbsent_ > * _getAndPutIfAbsentAsync_ > * _getAndRemove_ > * _getAndRemoveAsync_ > * _getAndReplace_ > * _getAndReplaceAsync_ > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndXXX_ operation is executed. A transaction cache works fine. _getAndXXX_ contains_:_ * _getAndPut_ * _getAndPutAsync_ * _getAndPutIfAbsent_ * _getAndPutIfAbsentAsync_ * _getAndRemove_ * _getAndRemoveAsync_ * _getAndReplace_ * _getAndReplaceAsync_ The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, getAndPutIfAbsentAsync_ operations are executed. A transaction cache works fine. The reproducer is in the attachment. > Cache operation getAndXXX doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndXXX_ operation is executed. > A transaction cache works fine. > _getAndXXX_ contains_:_ > * _getAndPut_ > * _getAndPutAsync_ > * _getAndPutIfAbsent_ > * _getAndPutIfAbsentAsync_ > * _getAndRemove_ > * _getAndRemoveAsync_ > * _getAndReplace_ > * _getAndReplaceAsync_ > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Summary: Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ. (was: Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.) > Cache operation getAndXXX doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, > getAndPutIfAbsentAsync_ operations are executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11312) JDBC: Thin driver reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11312: - Ignite Flags: (was: Docs Required) > JDBC: Thin driver reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Lev Agafonov >Priority: Major > Labels: newbie > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-11312) JDBC: Thin driver reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev resolved IGNITE-11312. -- Fix Version/s: 2.10 Release Note: Report correct thin JDBC property names to external tools Resolution: Fixed Thank you for this fix [~levagafonov], I have merged it to master. > JDBC: Thin driver reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Lev Agafonov >Priority: Major > Labels: newbie > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13386) [ML] Add more distances between two Vectors (Part 2)
[ https://issues.apache.org/jira/browse/IGNITE-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-13386: - Ignite Flags: Docs Required,Release Notes Required (was: Release Notes Required) > [ML] Add more distances between two Vectors (Part 2) > > > Key: IGNITE-13386 > URL: https://issues.apache.org/jira/browse/IGNITE-13386 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Alexey Zinoviev >Assignee: Mark Andreev >Priority: Minor > Fix For: 2.10 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Mark suggested to add more distances, below his letter about topic > [http://apache-ignite-developers.2346864.n4.nabble.com/First-contribute-to-Ignite-ML-td48950.html] > "Currently, Ignite supports only these distances > (org.apache.ignite.ml.math.distances) : > - ChebyshevDistance > - CosineSimilarity > - EuclideanDistance > - HammingDistance > - JaccardIndex > - ManhattanDistance > - MinkowskiDistance > But in scipy ( > [https://docs.scipy.org/doc/scipy/reference/spatial.distance.html]) we can > find at least: > - BrayCurtis > - Canberra > - Jensen-Shannon > - Seuclidean > - Weighted Minkowski > I can implement those and coverage with unit tests." -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13386) [ML] Add more distances between two Vectors (Part 2)
[ https://issues.apache.org/jira/browse/IGNITE-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-13386: - Fix Version/s: 2.10 > [ML] Add more distances between two Vectors (Part 2) > > > Key: IGNITE-13386 > URL: https://issues.apache.org/jira/browse/IGNITE-13386 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Alexey Zinoviev >Assignee: Mark Andreev >Priority: Minor > Fix For: 2.10 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Mark suggested to add more distances, below his letter about topic > [http://apache-ignite-developers.2346864.n4.nabble.com/First-contribute-to-Ignite-ML-td48950.html] > "Currently, Ignite supports only these distances > (org.apache.ignite.ml.math.distances) : > - ChebyshevDistance > - CosineSimilarity > - EuclideanDistance > - HammingDistance > - JaccardIndex > - ManhattanDistance > - MinkowskiDistance > But in scipy ( > [https://docs.scipy.org/doc/scipy/reference/spatial.distance.html]) we can > find at least: > - BrayCurtis > - Canberra > - Jensen-Shannon > - Seuclidean > - Weighted Minkowski > I can implement those and coverage with unit tests." -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13344) [ML] DummyVectorizer fails to extract label for coordinate with value "0.0" when backed by sparse vector
[
https://issues.apache.org/jira/browse/IGNITE-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-13344:
-
Fix Version/s: 2.10
> [ML] DummyVectorizer fails to extract label for coordinate with value "0.0"
> when backed by sparse vector
>
>
> Key: IGNITE-13344
> URL: https://issues.apache.org/jira/browse/IGNITE-13344
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.8.1
>Reporter: Thilo-Alexander Ginkel
>Assignee: Alexey Zinoviev
>Priority: Minor
> Fix For: 2.10
>
>
> Given: A labeled DummyVectorizer:
>
> {code:java}
> new DummyVectorizer()
> .exclude(excludeCoordinates.stream().map(coord -> vectorLength +
> coord).toArray(Integer[]::new))
> .labeled(labelCoord);
> {code}
> {{When extracting the label, the call hierarchy eventually ends up at
> org.apache.ignite.ml.dataset.feature.extractor.impl.DummyVectorizer#feature,
> which returns null for val.getRaw when val is a sparse vector with the
> element at the requested label coordinate being 0.0. This causes the training
> job to fail (which expects a non-null label):}}
> {code:java}
> org.apache.ignite.IgniteException: Remote job threw user exception (override
> or implement ComputeTask.result(..) method if you would like to have
> automatic failover for this exception):
> nullorg.apache.ignite.IgniteException: Remote job threw user exception
> (override or implement ComputeTask.result(..) method if you would like to
> have automatic failover for this exception): null at
> org.apache.ignite.compute.ComputeTaskAdapter.result(ComputeTaskAdapter.java:102)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1062)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1055)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7037)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:1055)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:862)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1146)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.job.GridJobWorker.finishJob(GridJobWorker.java:961)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.job.GridJobWorker.finishJob(GridJobWorker.java:809)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:659)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:519)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> ~[na:na] at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> ~[na:na] at java.base/java.lang.Thread.run(Thread.java:832) ~[na:na]Caused
> by: org.apache.ignite.IgniteException: null at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1858)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:596)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7005)
> ~[ignite-core-2.8.1.jar:2.8.1] at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:590)
> ~[ignite-core-2.8.1.jar:2.8.1] ... 5 common frames omittedCaused by:
> java.lang.NullPointerException: null at
> org.apache.ignite.ml.dataset.impl.bootstrapping.BootstrappedDatasetBuilder.build(BootstrappedDatasetBuilder.java:91)
> ~[ignite-ml-2.8.1.jar:2.8.1] at
> org.apache.ignite.ml.dataset.impl.bootstrapping.BootstrappedDatasetBuilder.build(BootstrappedDatasetBuilder.java:41)
> ~[ignite-ml-2.8.1.jar:2.8.1] at
> org.apache.ignite.ml.dataset.impl.cache.util.ComputeUtils.lambda$getData$4(ComputeUtils.java:239)
> ~[ignite-ml-2.8.1.jar:2.8.1] at
> org.apache.ignite.ml.dataset.impl.cache.util.PartitionDataStorage.lambda$computeDataIfAbsent$1(PartitionDataStorage.java:56)
> ~[ignite-ml-2.8.1.jar:2.8.1] at
>
[jira] [Updated] (IGNITE-10870) [ML] Add an example for KNN/LogReg and multi-class task full Iris dataset
[ https://issues.apache.org/jira/browse/IGNITE-10870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10870: - Fix Version/s: (was: 3.0) 2.10 > [ML] Add an example for KNN/LogReg and multi-class task full Iris dataset > - > > Key: IGNITE-10870 > URL: https://issues.apache.org/jira/browse/IGNITE-10870 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 3.0 >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Minor > Fix For: 2.10 > > > Add a one or two examples for KNN/LogReg and Iris dataset with 3 classes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10539) [ML] Make 'with' methods consistent
[ https://issues.apache.org/jira/browse/IGNITE-10539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10539: - Reporter: Alexey Zinoviev (was: Artem Malykh) > [ML] Make 'with' methods consistent > --- > > Key: IGNITE-10539 > URL: https://issues.apache.org/jira/browse/IGNITE-10539 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > Fix For: 2.10 > > > In some places we have 'with*' methods making inplace changes and returning > object itself (for example MLPTrainer::withLoss) while in other places we > have them creating new instances with corresponding parameter changed (for > example DatasetBuilder::withFilter, > DatasetBuilder::withUpstreamTrainsformer). This inconsistency makes user look > into javadoc each time and worsens overall API consistensy level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10539) [ML] Make 'with' methods consistent
[ https://issues.apache.org/jira/browse/IGNITE-10539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10539: - Fix Version/s: (was: 2.10) > [ML] Make 'with' methods consistent > --- > > Key: IGNITE-10539 > URL: https://issues.apache.org/jira/browse/IGNITE-10539 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > > In some places we have 'with*' methods making inplace changes and returning > object itself (for example MLPTrainer::withLoss) while in other places we > have them creating new instances with corresponding parameter changed (for > example DatasetBuilder::withFilter, > DatasetBuilder::withUpstreamTrainsformer). This inconsistency makes user look > into javadoc each time and worsens overall API consistensy level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10869) [ML] Add MultiClass classification metrics
[ https://issues.apache.org/jira/browse/IGNITE-10869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10869: - Affects Version/s: (was: 2.9) > [ML] Add MultiClass classification metrics > -- > > Key: IGNITE-10869 > URL: https://issues.apache.org/jira/browse/IGNITE-10869 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Minor > > Add ability to calculate multiple metrics (as binary metrics) for multiclass > classification > It can be merged with OneVsRest approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10870) [ML] Add an example for KNN/LogReg and multi-class task full Iris dataset
[ https://issues.apache.org/jira/browse/IGNITE-10870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10870: - Affects Version/s: (was: 3.0) > [ML] Add an example for KNN/LogReg and multi-class task full Iris dataset > - > > Key: IGNITE-10870 > URL: https://issues.apache.org/jira/browse/IGNITE-10870 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Minor > Fix For: 2.10 > > > Add a one or two examples for KNN/LogReg and Iris dataset with 3 classes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10869) [ML] Add MultiClass classification metrics
[ https://issues.apache.org/jira/browse/IGNITE-10869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10869: - Fix Version/s: (was: 3.0) > [ML] Add MultiClass classification metrics > -- > > Key: IGNITE-10869 > URL: https://issues.apache.org/jira/browse/IGNITE-10869 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.9 >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Minor > > Add ability to calculate multiple metrics (as binary metrics) for multiclass > classification > It can be merged with OneVsRest approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10870) [ML] Add an example for KNN/LogReg and multi-class task full Iris dataset
[ https://issues.apache.org/jira/browse/IGNITE-10870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10870: - Labels: newbie (was: ) > [ML] Add an example for KNN/LogReg and multi-class task full Iris dataset > - > > Key: IGNITE-10870 > URL: https://issues.apache.org/jira/browse/IGNITE-10870 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Minor > Labels: newbie > Fix For: 2.10 > > > Add a one or two examples for KNN/LogReg and Iris dataset with 3 classes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10503) [ML] Meta information for vectors
[ https://issues.apache.org/jira/browse/IGNITE-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10503: - Reporter: Alexey Zinoviev (was: Alexey Platonov) > [ML] Meta information for vectors > - > > Key: IGNITE-10503 > URL: https://issues.apache.org/jira/browse/IGNITE-10503 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > > We need to design and implement vector meta-information like feature names, > bagging information, etc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9415) [ML] Using sparce vectors in LSQR and MLP
[ https://issues.apache.org/jira/browse/IGNITE-9415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-9415: Fix Version/s: (was: 2.10) > [ML] Using sparce vectors in LSQR and MLP > - > > Key: IGNITE-9415 > URL: https://issues.apache.org/jira/browse/IGNITE-9415 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > > We need to investigate and apply sparce vectors support in BLAS for LSQR and > MLP (or implement own version) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9414) [ML] Using sparce vectors in Tree-based algorithms.
[ https://issues.apache.org/jira/browse/IGNITE-9414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-9414: Fix Version/s: (was: 2.10) > [ML] Using sparce vectors in Tree-based algorithms. > --- > > Key: IGNITE-9414 > URL: https://issues.apache.org/jira/browse/IGNITE-9414 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > > We need to support sparce vectors in DecisionTrees, RF, GDB -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10503) [ML] Meta information for vectors
[ https://issues.apache.org/jira/browse/IGNITE-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10503: - Fix Version/s: (was: 2.10) > [ML] Meta information for vectors > - > > Key: IGNITE-10503 > URL: https://issues.apache.org/jira/browse/IGNITE-10503 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Alexey Zinoviev >Priority: Major > > We need to design and implement vector meta-information like feature names, > bagging information, etc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12396) [ML] Random Forest generates NaN for a part of models on small datasets
[
https://issues.apache.org/jira/browse/IGNITE-12396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-12396:
-
Affects Version/s: (was: 2.8)
> [ML] Random Forest generates NaN for a part of models on small datasets
> ---
>
> Key: IGNITE-12396
> URL: https://issues.apache.org/jira/browse/IGNITE-12396
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Alexey Zinoviev
>Assignee: Alexey Zinoviev
>Priority: Major
> Fix For: 2.10
>
>
> @Override public Double predict(Vector features) {
> double[] predictions = new double[models.size()];
> for (int i = 0; i < models.size(); i++)
> predictions[i] = models.get(i).predict(features);
> return predictionsAggregator.apply(predictions);
> }
>
> predictionAggreagtor gets a lot of models and part of them returns null and
> it could be aggregated, first of all handle this in Aggregator (using
> threshold for amount of broken models before aggregation) also RandomForest
> trees should return Double.NaN - it should fail or throw message after the
> training
>
> I've tested with 100 or 1000 rows and it fails and doesn't fail on 10 000 rows
>
> RF generates a few models with one LEAF node with empty val (Double.NaN by
> default)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12396) [ML] Random Forest generates NaN for a part of models on small datasets
[
https://issues.apache.org/jira/browse/IGNITE-12396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-12396:
-
Fix Version/s: (was: 3.0)
2.10
> [ML] Random Forest generates NaN for a part of models on small datasets
> ---
>
> Key: IGNITE-12396
> URL: https://issues.apache.org/jira/browse/IGNITE-12396
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.8
>Reporter: Alexey Zinoviev
>Assignee: Alexey Zinoviev
>Priority: Major
> Fix For: 2.10
>
>
> @Override public Double predict(Vector features) {
> double[] predictions = new double[models.size()];
> for (int i = 0; i < models.size(); i++)
> predictions[i] = models.get(i).predict(features);
> return predictionsAggregator.apply(predictions);
> }
>
> predictionAggreagtor gets a lot of models and part of them returns null and
> it could be aggregated, first of all handle this in Aggregator (using
> threshold for amount of broken models before aggregation) also RandomForest
> trees should return Double.NaN - it should fail or throw message after the
> training
>
> I've tested with 100 or 1000 rows and it fails and doesn't fail on 10 000 rows
>
> RF generates a few models with one LEAF node with empty val (Double.NaN by
> default)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13497) [ML] Tutorial examples fails with serialization error
Alexey Zinoviev created IGNITE-13497: Summary: [ML] Tutorial examples fails with serialization error Key: IGNITE-13497 URL: https://issues.apache.org/jira/browse/IGNITE-13497 Project: Ignite Issue Type: Bug Components: ml Reporter: Alexey Zinoviev Assignee: Alexey Zinoviev Fix For: 2.10 Cross-Validation uses in interfaces unserializable functions (DoubleConsumers and etc.) Adds custom serializable functions and double check-up all public interfaces to find similar problems -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, getAndPutIfAbsentAsync_ operations are executed. A transaction cache works fine. The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, getAndPutIfAbsentAsync_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. > Cache operation getAndPut doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, > getAndPutIfAbsentAsync_ operations are executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, getAndPutIfAbsentAsync_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut (getAndPutAsync)_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. > Cache operation getAndPut doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, > getAndPutIfAbsentAsync_ operation is executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut (getAndPutAsync)_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. > Cache operation getAndPut doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut (getAndPutAsync)_ operation is executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13496) Java thin: Use non-blocking socket IO
[ https://issues.apache.org/jira/browse/IGNITE-13496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-13496: Description: IGNITE-7623 introduces async APIs to the Java thin client. However, socket writes still cause user thread blocking and thus reduce scalability. Investigate and prepare an IEP to use non-blocking IO. This ticket does not affect user-facing APIs, only changes the way we do IO internally. was: IGNITE-7623 introduces async APIs to the Java thin client. However, socket writes still cause user thread blocking and thus reduce scalability. Investigate and prepare an IEP to use non-blocking IO. > Java thin: Use non-blocking socket IO > -- > > Key: IGNITE-13496 > URL: https://issues.apache.org/jira/browse/IGNITE-13496 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.10 > > > IGNITE-7623 introduces async APIs to the Java thin client. However, socket > writes still cause user thread blocking and thus reduce scalability. > Investigate and prepare an IEP to use non-blocking IO. > This ticket does not affect user-facing APIs, only changes the way we do IO > internally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13496) Java thin: Use non-blocking socket IO
Pavel Tupitsyn created IGNITE-13496: --- Summary: Java thin: Use non-blocking socket IO Key: IGNITE-13496 URL: https://issues.apache.org/jira/browse/IGNITE-13496 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 2.9 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.10 IGNITE-7623 introduces async APIs to the Java thin client. However, socket writes still cause user thread blocking and thus reduce scalability. Investigate and prepare an IEP to use non-blocking IO. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13378) .NET: Thin Client: Use non-blocking socket IO
[ https://issues.apache.org/jira/browse/IGNITE-13378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-13378: Issue Type: Improvement (was: Bug) > .NET: Thin Client: Use non-blocking socket IO > - > > Key: IGNITE-13378 > URL: https://issues.apache.org/jira/browse/IGNITE-13378 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > > .NET Thin Client was initially developed for Windows and .NET Framework. > Benchmarks at that time proved that blocking socket IO was faster for > single-threaded workload, and we developed a solution with a dedicated thread > for response handling, and async APIs use blocking writes. > We may want to reconsider this design: > * Scalability is often more important than single-threaded performance > * .NET Core has many perf improvements over .NET Framework > Investigate async socket IO performance on .NET Core 3.x/5.x compared to the > current approach on Windows and Linux and refactor ClientSocket accordingly > to avoid any blocking and a dedicated thread usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13495) ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as coordinator
[
https://issues.apache.org/jira/browse/IGNITE-13495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13495:
--
Description:
Due to invalid algorithm in
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
sometimes invalid coordinator could be returned
Consider scenarion:
1. Start server #1
2. Start client
3. Start server #2
4. Stop server #1
After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
coordinator a client, because it is the oldest node in topology.
We should fix
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
to return *oldest server*, not any node.
was:
Due to invalid algorithm in
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
sometimes invalid coordinator could be return
Consider scenarion:
1. Start server #1
2. Start client
3. Start server #2
4. Stop server #1
After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
coordinator a client, because it is the oldest node in topology.
We should fix
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
to return *oldest server*, not any node.
> ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as
> coordinator
>
>
> Key: IGNITE-13495
> URL: https://issues.apache.org/jira/browse/IGNITE-13495
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Sergei Ryzhov
>Priority: Major
> Labels: newbie, zookeeper
> Fix For: 2.10
>
>
> Due to invalid algorithm in
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> sometimes invalid coordinator could be returned
> Consider scenarion:
> 1. Start server #1
> 2. Start client
> 3. Start server #2
> 4. Stop server #1
> After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
> coordinator a client, because it is the oldest node in topology.
> We should fix
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> to return *oldest server*, not any node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13495) ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as coordinator
[
https://issues.apache.org/jira/browse/IGNITE-13495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergei Ryzhov reassigned IGNITE-13495:
--
Assignee: Sergei Ryzhov
> ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as
> coordinator
>
>
> Key: IGNITE-13495
> URL: https://issues.apache.org/jira/browse/IGNITE-13495
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Sergei Ryzhov
>Priority: Major
> Labels: newbie, zookeeper
> Fix For: 2.10
>
>
> Due to invalid algorithm in
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> sometimes invalid coordinator could be return
> Consider scenarion:
> 1. Start server #1
> 2. Start client
> 3. Start server #2
> 4. Stop server #1
> After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
> coordinator a client, because it is the oldest node in topology.
> We should fix
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> to return *oldest server*, not any node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13495) ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as coordinator
[
https://issues.apache.org/jira/browse/IGNITE-13495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13495:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as
> coordinator
>
>
> Key: IGNITE-13495
> URL: https://issues.apache.org/jira/browse/IGNITE-13495
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Priority: Major
> Labels: newbie, zookeeper
> Fix For: 2.10
>
>
> Due to invalid algorithm in
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> sometimes invalid coordinator could be return
> Consider scenarion:
> 1. Start server #1
> 2. Start client
> 3. Start server #2
> 4. Stop server #1
> After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
> coordinator a client, because it is the oldest node in topology.
> We should fix
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> to return *oldest server*, not any node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
[
https://issues.apache.org/jira/browse/IGNITE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13491:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix incorrect topology snapshot logger output about coordinator change.
> ---
>
> Key: IGNITE-13491
> URL: https://issues.apache.org/jira/browse/IGNITE-13491
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Priority: Minor
> Labels: newbie
> Fix For: 2.10
>
>
> Currently, logic in
> {{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
> has major drawback, in condition we don't check that failed node with order
> less than oldest server node, is actually server node. So we can see invalid
> message about coordinator change, even though previous node was a client.
> Reproducer:
> 1. Start server #1
> 2. Start client
> 3. Start server #1
> 4. Stop server #1 and client
> We will see in logs of server #2 something like this:
> {{[2020-09-29 10:41:25,909][INFO
> ][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
> Coordinator changed [prev=TcpDiscoveryNode
> [id=371896fb-f612-4640-bfcd-cef6d281,
> consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2,
> intOrder=2, lastExchangeTime=1601365285287, loc=false,
> ver=2.10.0#20200929-sha1:, *isClient=true*], cur=TcpDiscoveryNode
> [id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900,
> loc=true, ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13495) ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as coordinator
Ivan Daschinskiy created IGNITE-13495:
-
Summary: ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return
invalid node as coordinator
Key: IGNITE-13495
URL: https://issues.apache.org/jira/browse/IGNITE-13495
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Ivan Daschinskiy
Fix For: 2.10
Due to invalid algorithm in
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
sometimes invalid coordinator could be return
Consider scenarion:
1. Start server #1
2. Start client
3. Start server #2
4. Stop server #1
After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
coordinator a client, because it is the oldest node in topology.
We should rewrite
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
to return *oldest server*, not any node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13495) ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as coordinator
[
https://issues.apache.org/jira/browse/IGNITE-13495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13495:
--
Description:
Due to invalid algorithm in
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
sometimes invalid coordinator could be return
Consider scenarion:
1. Start server #1
2. Start client
3. Start server #2
4. Stop server #1
After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
coordinator a client, because it is the oldest node in topology.
We should fix
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
to return *oldest server*, not any node.
was:
Due to invalid algorithm in
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
sometimes invalid coordinator could be return
Consider scenarion:
1. Start server #1
2. Start client
3. Start server #2
4. Stop server #1
After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
coordinator a client, because it is the oldest node in topology.
We should rewrite
{{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
to return *oldest server*, not any node.
> ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as
> coordinator
>
>
> Key: IGNITE-13495
> URL: https://issues.apache.org/jira/browse/IGNITE-13495
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Priority: Major
> Labels: newbie, zookeeper
> Fix For: 2.10
>
>
> Due to invalid algorithm in
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> sometimes invalid coordinator could be return
> Consider scenarion:
> 1. Start server #1
> 2. Start client
> 3. Start server #2
> 4. Stop server #1
> After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
> coordinator a client, because it is the oldest node in topology.
> We should fix
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> to return *oldest server*, not any node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13494) Snapshot and start-stop clients test for ducktape
Sergei Ryzhov created IGNITE-13494: -- Summary: Snapshot and start-stop clients test for ducktape Key: IGNITE-13494 URL: https://issues.apache.org/jira/browse/IGNITE-13494 Project: Ignite Issue Type: Task Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov Starting and stopping clients during snapshot creation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13493) Snapshot and node failures (unstable topology) test for ducktape
Sergei Ryzhov created IGNITE-13493: -- Summary: Snapshot and node failures (unstable topology) test for ducktape Key: IGNITE-13493 URL: https://issues.apache.org/jira/browse/IGNITE-13493 Project: Ignite Issue Type: Task Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov Falling server node during snapshot creation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13492) Basic snapshot test for ducktape
Sergei Ryzhov created IGNITE-13492: -- Summary: Basic snapshot test for ducktape Key: IGNITE-13492 URL: https://issues.apache.org/jira/browse/IGNITE-13492 Project: Ignite Issue Type: Task Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov Basic snapshot test for ducktape -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10837) control.sh --baseline should output node IP addresses
[ https://issues.apache.org/jira/browse/IGNITE-10837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov reassigned IGNITE-10837: --- Assignee: Kirill Gusakov > control.sh --baseline should output node IP addresses > - > > Key: IGNITE-10837 > URL: https://issues.apache.org/jira/browse/IGNITE-10837 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.5, 2.8 >Reporter: Max Shonichev >Assignee: Kirill Gusakov >Priority: Major > > control.sh --baseline outputs node's consistent IDs > it would be very useful, if it also output node's IP addresses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
[
https://issues.apache.org/jira/browse/IGNITE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13491:
--
Description:
Currently, logic in
{{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
has major drawback, in condition we don't check that failed node with order
less than oldest server node, is actually server node. So we can see invalid
message about coordinator change, even though previous node was a client.
Reproducer:
1. Start server #1
2. Start client
3. Start server #1
4. Stop server #1 and client
We will see in logs of server #2 something like this:
{{[2020-09-29 10:41:25,909][INFO
][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
Coordinator changed [prev=TcpDiscoveryNode
[id=371896fb-f612-4640-bfcd-cef6d281,
consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2, intOrder=2,
lastExchangeTime=1601365285287, loc=false, ver=2.10.0#20200929-sha1:,
*isClient=true*], cur=TcpDiscoveryNode
[id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900, loc=true,
ver=2.10.0#20200929-sha1:, isClient=false]]}}
was:
Currently, logic in
{{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
has major drawback, in condition we don't check that failed node with order
less than oldest server node, is actually server node. So we can see invalid
message about coordinator change, event though previous node was a client.
Reproducer:
1. Start server #1
2. Start client
3. Start server #1
4. Stop server #1 and client
We will see in logs of server #2 something like this:
{{[2020-09-29 10:41:25,909][INFO
][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
Coordinator changed [prev=TcpDiscoveryNode
[id=371896fb-f612-4640-bfcd-cef6d281,
consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2, intOrder=2,
lastExchangeTime=1601365285287, loc=false, ver=2.10.0#20200929-sha1:,
*isClient=true*], cur=TcpDiscoveryNode
[id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900, loc=true,
ver=2.10.0#20200929-sha1:, isClient=false]]}}
> Fix incorrect topology snapshot logger output about coordinator change.
> ---
>
> Key: IGNITE-13491
> URL: https://issues.apache.org/jira/browse/IGNITE-13491
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Daschinskiy
>Priority: Minor
> Labels: newbie
>
> Currently, logic in
> {{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
> has major drawback, in condition we don't check that failed node with order
> less than oldest server node, is actually server node. So we can see invalid
> message about coordinator change, even though previous node was a client.
> Reproducer:
> 1. Start server #1
> 2. Start client
> 3. Start server #1
> 4. Stop server #1 and client
> We will see in logs of server #2 something like this:
> {{[2020-09-29 10:41:25,909][INFO
> ][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
> Coordinator changed [prev=TcpDiscoveryNode
> [id=371896fb-f612-4640-bfcd-cef6d281,
> consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2,
> intOrder=2, lastExchangeTime=1601365285287, loc=false,
> ver=2.10.0#20200929-sha1:, *isClient=true*], cur=TcpDiscoveryNode
> [id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900,
> loc=true, ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
[
https://issues.apache.org/jira/browse/IGNITE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13491:
--
Fix Version/s: 2.10
> Fix incorrect topology snapshot logger output about coordinator change.
> ---
>
> Key: IGNITE-13491
> URL: https://issues.apache.org/jira/browse/IGNITE-13491
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Priority: Minor
> Labels: newbie
> Fix For: 2.10
>
>
> Currently, logic in
> {{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
> has major drawback, in condition we don't check that failed node with order
> less than oldest server node, is actually server node. So we can see invalid
> message about coordinator change, even though previous node was a client.
> Reproducer:
> 1. Start server #1
> 2. Start client
> 3. Start server #1
> 4. Stop server #1 and client
> We will see in logs of server #2 something like this:
> {{[2020-09-29 10:41:25,909][INFO
> ][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
> Coordinator changed [prev=TcpDiscoveryNode
> [id=371896fb-f612-4640-bfcd-cef6d281,
> consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2,
> intOrder=2, lastExchangeTime=1601365285287, loc=false,
> ver=2.10.0#20200929-sha1:, *isClient=true*], cur=TcpDiscoveryNode
> [id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900,
> loc=true, ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
[
https://issues.apache.org/jira/browse/IGNITE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13491:
--
Affects Version/s: 2.9
> Fix incorrect topology snapshot logger output about coordinator change.
> ---
>
> Key: IGNITE-13491
> URL: https://issues.apache.org/jira/browse/IGNITE-13491
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Priority: Minor
> Labels: newbie
>
> Currently, logic in
> {{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
> has major drawback, in condition we don't check that failed node with order
> less than oldest server node, is actually server node. So we can see invalid
> message about coordinator change, even though previous node was a client.
> Reproducer:
> 1. Start server #1
> 2. Start client
> 3. Start server #1
> 4. Stop server #1 and client
> We will see in logs of server #2 something like this:
> {{[2020-09-29 10:41:25,909][INFO
> ][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
> Coordinator changed [prev=TcpDiscoveryNode
> [id=371896fb-f612-4640-bfcd-cef6d281,
> consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2,
> intOrder=2, lastExchangeTime=1601365285287, loc=false,
> ver=2.10.0#20200929-sha1:, *isClient=true*], cur=TcpDiscoveryNode
> [id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900,
> loc=true, ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
Ivan Daschinskiy created IGNITE-13491:
-
Summary: Fix incorrect topology snapshot logger output about
coordinator change.
Key: IGNITE-13491
URL: https://issues.apache.org/jira/browse/IGNITE-13491
Project: Ignite
Issue Type: Bug
Reporter: Ivan Daschinskiy
Currently, logic in
{{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
has major drawback, in condition we don't check that failed node with order
less than oldest server node, is actually server node. So we can see invalid
message about coordinator change, event though previous node was a client.
Reproducer:
1. Start server #1
2. Start client
3. Start server #1
4. Stop server #1 and client
We will see in logs of server #2 something like this:
{{[2020-09-29 10:41:25,909][INFO
][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
Coordinator changed [prev=TcpDiscoveryNode
[id=371896fb-f612-4640-bfcd-cef6d281,
consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2, intOrder=2,
lastExchangeTime=1601365285287, loc=false, ver=2.10.0#20200929-sha1:,
*isClient=true*], cur=TcpDiscoveryNode
[id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900, loc=true,
ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut_ operation is executed. A transaction cache works fine. The reproducer in the attachment. > Cache operation getAndPut doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut_ operation is executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
Denis Garus created IGNITE-13490: Summary: Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ. Key: IGNITE-13490 URL: https://issues.apache.org/jira/browse/IGNITE-13490 Project: Ignite Issue Type: Bug Components: cache Reporter: Denis Garus Attachments: GetAndPutCacheEventsTest.java An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut_ operation is executed. A transaction cache works fine. The reproducer in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
