[jira] [Resolved] (IGNITE-14696) [Ignite Website] Update for events schedule and more
[ https://issues.apache.org/jira/browse/IGNITE-14696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauricio Stekl resolved IGNITE-14696. - Resolution: Fixed > [Ignite Website] Update for events schedule and more > > > Key: IGNITE-14696 > URL: https://issues.apache.org/jira/browse/IGNITE-14696 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Mauricio Stekl >Priority: Major > > [~mstekl], please update the site: > > 1)new even for [https://ignite.apache.org/events.html] > Apache Ignite on Kubernetes > Webinar, Colin Capriati > Running Apache Ignite on Kubernetes can help Ignite developers streamline > deployment and management of applications in cloud environments, both private > and public. Apache Ignite is Kubernetes-friendly with features that simplify > cluster provisioning and minimize the operational and management burden. > Learn more: > [https://www.gridgain.com/resources/webinars/apache-ignite-kubernetes] > > 2)Please update top line on the main page: > May 25, 2021: Don't forget to join first Ignite Summit for developers > [https://ignite-summit.org/] > > 3)Please exclude Vrbo from the logos block. > 4)Please update the Ignite Summit banner for the new one > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14696) [Ignite Website] Update for events schedule and more
[ https://issues.apache.org/jira/browse/IGNITE-14696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344190#comment-17344190 ] Mauricio Stekl commented on IGNITE-14696: - [~romanova.ks.spb], I updated the events and the Vrbo logo. About the Ignite promos, I updated the top bar, and the side bar on the docs. When I receive the image for the main section on the homepage I'll update it and let you know. > [Ignite Website] Update for events schedule and more > > > Key: IGNITE-14696 > URL: https://issues.apache.org/jira/browse/IGNITE-14696 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Mauricio Stekl >Priority: Major > > [~mstekl], please update the site: > > 1)new even for [https://ignite.apache.org/events.html] > Apache Ignite on Kubernetes > Webinar, Colin Capriati > Running Apache Ignite on Kubernetes can help Ignite developers streamline > deployment and management of applications in cloud environments, both private > and public. Apache Ignite is Kubernetes-friendly with features that simplify > cluster provisioning and minimize the operational and management burden. > Learn more: > [https://www.gridgain.com/resources/webinars/apache-ignite-kubernetes] > > 2)Please update top line on the main page: > May 25, 2021: Don't forget to join first Ignite Summit for developers > [https://ignite-summit.org/] > > 3)Please exclude Vrbo from the logos block. > 4)Please update the Ignite Summit banner for the new one > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14696) [Ignite Website] Update for events schedule and more
[ https://issues.apache.org/jira/browse/IGNITE-14696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauricio Stekl reassigned IGNITE-14696: --- Assignee: Mauricio Stekl > [Ignite Website] Update for events schedule and more > > > Key: IGNITE-14696 > URL: https://issues.apache.org/jira/browse/IGNITE-14696 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Mauricio Stekl >Priority: Major > > [~mstekl], please update the site: > > 1)new even for [https://ignite.apache.org/events.html] > Apache Ignite on Kubernetes > Webinar, Colin Capriati > Running Apache Ignite on Kubernetes can help Ignite developers streamline > deployment and management of applications in cloud environments, both private > and public. Apache Ignite is Kubernetes-friendly with features that simplify > cluster provisioning and minimize the operational and management burden. > Learn more: > [https://www.gridgain.com/resources/webinars/apache-ignite-kubernetes] > > 2)Please update top line on the main page: > May 25, 2021: Don't forget to join first Ignite Summit for developers > [https://ignite-summit.org/] > > 3)Please exclude Vrbo from the logos block. > 4)Please update the Ignite Summit banner for the new one > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14544) Calcite engine. Support DISTINCT aggregates
[
https://issues.apache.org/jira/browse/IGNITE-14544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344005#comment-17344005
]
Alexey Goncharuk commented on IGNITE-14544:
---
[~tledkov-gridgain] do we have the {{AggregateExpandDistinctAggregatesRule}}
enabled? Looks like it can reduce the distinct aggregates to {{GROUP BY}} /
{{JOIN}} operators, which will simplify the implementation, this may be an
alternative approach.
> Calcite engine. Support DISTINCT aggregates
> ---
>
> Key: IGNITE-14544
> URL: https://issues.apache.org/jira/browse/IGNITE-14544
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Now, DISTINCT aggregates not implemented.
> (e.g. {{SELECT COUNT (DISTINCT lastName) FROM person}})
> Tests:
> {{aggregate/aggregates/test_count.test}}
> {{aggregate/aggregates/test_avg.test}}
> {{aggregate/aggregates/test_distinct_aggr.test}}
> {{aggregate/aggregates/test_distinct_string_agg.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14583) Server node fails on remote filter deployment after client reconnect with new node id
[
https://issues.apache.org/jira/browse/IGNITE-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343948#comment-17343948
]
Igor Belyakov commented on IGNITE-14583:
[~ascherbakov], I've fixed the tests, can you please take a look?
> Server node fails on remote filter deployment after client reconnect with new
> node id
> -
>
> Key: IGNITE-14583
> URL: https://issues.apache.org/jira/browse/IGNITE-14583
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Igor Belyakov
>Assignee: Igor Belyakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Cluster contains 1 server and 1 client node. PeerClassLoading turned on.
> *1.* Client node deploys CQ with remote filter, server node doesn't have
> classes required for remote filter in classpath.
> *2.* Remote filter successfully deployed to server node.
> *3.* Client node disconnects and reconnects by using new node id:
> [15:44:43] Client node was reconnected after it was already considered failed
> by the server topology (this could happen after all servers restarted or due
> to a long network outage between the client and servers). All continuous
> queries and remote event listeners created by this client will be
> unsubscribed, consider listening to EVT_CLIENT_NODE_RECONNECTED event to
> restore them.
> *4.* On connect, client node tries to deploy remote filter to server node,
> but server node fails due to wrong ClassLoaderId, which is sent in
> GridDeploymentInfo (used ClassLoaderId for old client node):
> {code:java}
> [15:44:42] (err) Failed to notify listener:
> o.a.i.i.util.future.GridFutureChainListener@778d0fc6class
> org.apache.ignite.IgniteException: Failed to initialize a remote filter.
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.lambda$register$2bf956f5$1(CacheContinuousQueryHandler.java:353)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:77)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:69)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:29)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:477)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1311)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.run(GridContinuousProcessor.java:693)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7162)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class
> org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to obtain
> deployment for class: Client1$$Lambda$513/0x0008003b8840
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308)
> ... 8 more
> авг. 07, 2020 3:44:42 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to unmarshal continuous routine handler
> [routineId=8f0137dc-cb32-40ff-83f4-867f272d338e,
> srcNodeId=ebcf4d5b-a476-43d5-b057-00b5694104e6]
> class org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to
> obtain deployment for class: Client1$$Lambda$513/0x0008003b8840
> at
>
[jira] [Commented] (IGNITE-14583) Server node fails on remote filter deployment after client reconnect with new node id
[
https://issues.apache.org/jira/browse/IGNITE-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343946#comment-17343946
]
Ignite TC Bot commented on IGNITE-14583:
{panel:title=Branch: [pull/9016/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9016/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Kubernetes{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6005477]]
* {color:#013220}IgniteKubernetesTestSuite:
TestClusterClientConnection.testClientConnectsToCluster - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6005561buildTypeId=IgniteTests24Java8_RunAll]
> Server node fails on remote filter deployment after client reconnect with new
> node id
> -
>
> Key: IGNITE-14583
> URL: https://issues.apache.org/jira/browse/IGNITE-14583
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Igor Belyakov
>Assignee: Igor Belyakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Cluster contains 1 server and 1 client node. PeerClassLoading turned on.
> *1.* Client node deploys CQ with remote filter, server node doesn't have
> classes required for remote filter in classpath.
> *2.* Remote filter successfully deployed to server node.
> *3.* Client node disconnects and reconnects by using new node id:
> [15:44:43] Client node was reconnected after it was already considered failed
> by the server topology (this could happen after all servers restarted or due
> to a long network outage between the client and servers). All continuous
> queries and remote event listeners created by this client will be
> unsubscribed, consider listening to EVT_CLIENT_NODE_RECONNECTED event to
> restore them.
> *4.* On connect, client node tries to deploy remote filter to server node,
> but server node fails due to wrong ClassLoaderId, which is sent in
> GridDeploymentInfo (used ClassLoaderId for old client node):
> {code:java}
> [15:44:42] (err) Failed to notify listener:
> o.a.i.i.util.future.GridFutureChainListener@778d0fc6class
> org.apache.ignite.IgniteException: Failed to initialize a remote filter.
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.lambda$register$2bf956f5$1(CacheContinuousQueryHandler.java:353)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:77)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:69)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:29)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:477)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1311)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.run(GridContinuousProcessor.java:693)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7162)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class
> org.apache.ignite.internal.IgniteDeploymentCheckedException: Failed to obtain
> deployment for class: Client1$$Lambda$513/0x0008003b8840
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:94)
> at
>
[jira] [Commented] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343923#comment-17343923 ] Igor Belyakov commented on IGNITE-11970: [~mmuzaf], I've made changes in the code according to your suggestions and added comments in the PR, can you please take a look? Failed tests are not related to the changes. > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Critical > Time Spent: 2h > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14696) [Ignite Website] Update for events schedule and more
[ https://issues.apache.org/jira/browse/IGNITE-14696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kseniya Romanova updated IGNITE-14696: -- Description: [~mstekl], please update the site: 1)new even for [https://ignite.apache.org/events.html] Apache Ignite on Kubernetes Webinar, Colin Capriati Running Apache Ignite on Kubernetes can help Ignite developers streamline deployment and management of applications in cloud environments, both private and public. Apache Ignite is Kubernetes-friendly with features that simplify cluster provisioning and minimize the operational and management burden. Learn more: [https://www.gridgain.com/resources/webinars/apache-ignite-kubernetes] 2)Please update top line on the main page: May 25, 2021: Don't forget to join first Ignite Summit for developers [https://ignite-summit.org/] 3)Please exclude Vrbo from the logos block. 4)Please update the Ignite Summit banner for the new one was: [~mstekl], please update the site: 1)new even for [https://ignite.apache.org/events.html] Apache Ignite on Kubernetes Webinar, Colin Capriati Running Apache Ignite on Kubernetes can help Ignite developers streamline deployment and management of applications in cloud environments, both private and public. Apache Ignite is Kubernetes-friendly with features that simplify cluster provisioning and minimize the operational and management burden. Learn more: [https://www.gridgain.com/resources/webinars/apache-ignite-kubernetes] 2)Please update top line on the main page: May 25, 2021: Don't forget to join first Ignite Summit for developers [https://ignite-summit.org/] 3)Please exclude Vrbo from the logos block. > [Ignite Website] Update for events schedule and more > > > Key: IGNITE-14696 > URL: https://issues.apache.org/jira/browse/IGNITE-14696 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Priority: Major > > [~mstekl], please update the site: > > 1)new even for [https://ignite.apache.org/events.html] > Apache Ignite on Kubernetes > Webinar, Colin Capriati > Running Apache Ignite on Kubernetes can help Ignite developers streamline > deployment and management of applications in cloud environments, both private > and public. Apache Ignite is Kubernetes-friendly with features that simplify > cluster provisioning and minimize the operational and management burden. > Learn more: > [https://www.gridgain.com/resources/webinars/apache-ignite-kubernetes] > > 2)Please update top line on the main page: > May 25, 2021: Don't forget to join first Ignite Summit for developers > [https://ignite-summit.org/] > > 3)Please exclude Vrbo from the logos block. > 4)Please update the Ignite Summit banner for the new one > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14595) ExpiryPolicy support to python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-14595: - Release Note: Added ExpiryPolicy suport > ExpiryPolicy support to python thin client > -- > > Key: IGNITE-14595 > URL: https://issues.apache.org/jira/browse/IGNITE-14595 > Project: Ignite > Issue Type: New Feature > Components: python, thin client >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: python, thin > Fix For: python-0.5.0 > > Time Spent: 50m > Remaining Estimate: 0h > > It's of a crucial importance to add support for expiration policy in python > client. > This is on of the most used feature of any cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14705) Invalid handling of binary object collections
[ https://issues.apache.org/jira/browse/IGNITE-14705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-14705: - Release Note: Fixed handling collections with binary objects (was: Fix handling collections with binary objects) > Invalid handling of binary object collections > - > > Key: IGNITE-14705 > URL: https://issues.apache.org/jira/browse/IGNITE-14705 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.3.4, python-0.4.0 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: python > Fix For: python-0.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > There are a few issues regarding collections exists. > 1. Binary objects in collections are not unwrapped during deserialization. > 2. Collections of binary objects inside BinaryObject doesn't deserialize > properly due to broken AnyDataObject.to_python -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14715) Create an annotation processor for generating network message implementations
[
https://issues.apache.org/jira/browse/IGNITE-14715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14715:
-
Description:
Currently all {{NetworkMessage}} implementations are created by hand which is
inconvenient (e.g. one needs to declare constructors and getters). It is
proposed to automatically generate these implementations using an annotation
processor.
h3. Implementation details
* Custom messages should be declared as interfaces extending
{{NetworkMessage}}. Methods in these interfaces should correspond to the
message fields, for example:
{code:java}
@Message(type = ACTION_REQUEST)
public interface ActionRequest extends NetworkMessage {
String groupId();
Command command();
}
{code}
* Every message interface should be annotated with the {{@Message}} interface,
with a *message type* parameter of type {{short}}, unique across a *module*.
All message types should be manually listed in an interface marked with the
{{@MessageTypes}} annotation with a *module identifier*. For example:
{code:java}
@MessageTypes(moduleType = 10)
class RaftMessageTypes {
public final short ACTION_REQUEST = 1;
}
{code}
* Message implementations should have a generated {{Builder}} interface for
creating new messages:
{code:java}
public interface Builder {
Builder command(Command cmd);
Builder groupId(String groupId);
ActionRequest build();
}
{code}
* {{Builder}} instances should be obtained using a generated factory, based on
the current module type:
{code:java}
public interface RaftClientMessageFactory {
ActionRequestBuilder actionRequest();
ActionResponseBuilder actionResponse();
// ...
}
{code}
> Create an annotation processor for generating network message implementations
> -
>
> Key: IGNITE-14715
> URL: https://issues.apache.org/jira/browse/IGNITE-14715
> Project: Ignite
> Issue Type: Sub-task
> Components: networking
>Reporter: Aleksandr Polovtcev
>Priority: Minor
>
> Currently all {{NetworkMessage}} implementations are created by hand which is
> inconvenient (e.g. one needs to declare constructors and getters). It is
> proposed to automatically generate these implementations using an annotation
> processor.
> h3. Implementation details
> * Custom messages should be declared as interfaces extending
> {{NetworkMessage}}. Methods in these interfaces should correspond to the
> message fields, for example:
> {code:java}
> @Message(type = ACTION_REQUEST)
> public interface ActionRequest extends NetworkMessage {
> String groupId();
> Command command();
> }
> {code}
> * Every message interface should be annotated with the {{@Message}}
> interface, with a *message type* parameter of type {{short}}, unique across a
> *module*. All message types should be manually listed in an interface marked
> with the {{@MessageTypes}} annotation with a *module identifier*. For example:
> {code:java}
> @MessageTypes(moduleType = 10)
> class RaftMessageTypes {
> public final short ACTION_REQUEST = 1;
> }
> {code}
> * Message implementations should have a generated {{Builder}} interface for
> creating new messages:
> {code:java}
> public interface Builder {
> Builder command(Command cmd);
> Builder groupId(String groupId);
> ActionRequest build();
> }
> {code}
> * {{Builder}} instances should be obtained using a generated factory, based
> on the current module type:
> {code:java}
> public interface RaftClientMessageFactory {
> ActionRequestBuilder actionRequest();
> ActionResponseBuilder actionResponse();
> // ...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14701) Simple PDS upgrade test
[ https://issues.apache.org/jira/browse/IGNITE-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343892#comment-17343892 ] Anton Vinogradov commented on IGNITE-14701: --- Merged into ignite-ducktape. [~nizhikov], thanks for the review. > Simple PDS upgrade test > --- > > Key: IGNITE-14701 > URL: https://issues.apache.org/jira/browse/IGNITE-14701 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Simple ducktests test checks migration to newer version from existing PDS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14705) Invalid handling of binary object collections
[ https://issues.apache.org/jira/browse/IGNITE-14705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343890#comment-17343890 ] Igor Sapego commented on IGNITE-14705: -- [~ivandasch] looks good to me. > Invalid handling of binary object collections > - > > Key: IGNITE-14705 > URL: https://issues.apache.org/jira/browse/IGNITE-14705 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.3.4, python-0.4.0 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: python > Time Spent: 10m > Remaining Estimate: 0h > > There are a few issues regarding collections exists. > 1. Binary objects in collections are not unwrapped during deserialization. > 2. Collections of binary objects inside BinaryObject doesn't deserialize > properly due to broken AnyDataObject.to_python -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14237) Affinity function
[ https://issues.apache.org/jira/browse/IGNITE-14237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-14237: - Reviewer: Alexander Lapin > Affinity function > - > > Key: IGNITE-14237 > URL: https://issues.apache.org/jira/browse/IGNITE-14237 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: iep-72, ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > It seems that we need to adopt a well-known rendezvous affinity function to > AI-3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14707) The topology is not always valid after node restart depending on cluster timeout settings
[ https://issues.apache.org/jira/browse/IGNITE-14707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343889#comment-17343889 ] Alexey Scherbakov commented on IGNITE-14707: Merged to master #21ebca1d0273caf70e675a8e21f18247fcd707a6 > The topology is not always valid after node restart depending on cluster > timeout settings > - > > Key: IGNITE-14707 > URL: https://issues.apache.org/jira/browse/IGNITE-14707 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The reporoducer is in the first branch commit > ITNodeRestartsTest > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14237) Affinity function
[ https://issues.apache.org/jira/browse/IGNITE-14237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343888#comment-17343888 ] Alexander Lapin commented on IGNITE-14237: -- [~v.pyatkov] [~slava.koptilin] LGTM from my side. > Affinity function > - > > Key: IGNITE-14237 > URL: https://issues.apache.org/jira/browse/IGNITE-14237 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: iep-72, ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > It seems that we need to adopt a well-known rendezvous affinity function to > AI-3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14388) Add affinity columns support.
[ https://issues.apache.org/jira/browse/IGNITE-14388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14388: -- Summary: Add affinity columns support. (was: Add affinity key support.) > Add affinity columns support. > - > > Key: IGNITE-14388 > URL: https://issues.apache.org/jira/browse/IGNITE-14388 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > For now, we do not calculate Row hash at all, it is always equals zero. > Let's calculate Row hash for affinity columns only while assembling the row > in RowAssembler. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14707) The topology is not always valid after node restart depending on cluster timeout settings
[ https://issues.apache.org/jira/browse/IGNITE-14707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343873#comment-17343873 ] Semyon Danilov commented on IGNITE-14707: - Looks good to me! > The topology is not always valid after node restart depending on cluster > timeout settings > - > > Key: IGNITE-14707 > URL: https://issues.apache.org/jira/browse/IGNITE-14707 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The reporoducer is in the first branch commit > ITNodeRestartsTest > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11970) Excessive use of memory in continuous queries
[
https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343872#comment-17343872
]
Ignite TC Bot commented on IGNITE-11970:
{panel:title=Branch: [pull/7934/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}JDBC Driver{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6005563]]
{color:#d04437}RDD{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6005565]]
{panel}
{panel:title=Branch: [pull/7934/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Continuous Query 4{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6005210]]
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
ContinuousQueryBufferCleanupTest.testBufferCleanup[2 1 false Query [pageSize=1,
loc=false]] - PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
ContinuousQueryBufferCleanupTest.testBufferCleanup[2 0 true Query [pageSize=1,
loc=false]] - PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
ContinuousQueryBufferCleanupTest.testBufferCleanup[2 1 true Query [pageSize=1,
loc=false]] - PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
ContinuousQueryBufferCleanupTest.testBufferCleanup[1 0 true Query [pageSize=1,
loc=false]] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6005246buildTypeId=IgniteTests24Java8_RunAll]
> Excessive use of memory in continuous queries
> -
>
> Key: IGNITE-11970
> URL: https://issues.apache.org/jira/browse/IGNITE-11970
> Project: Ignite
> Issue Type: Bug
>Reporter: Igor Belyakov
>Assignee: Igor Belyakov
>Priority: Critical
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When we prepare to send an entry into the continuous query's filter and
> listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch.
> The batch is an array of entries of size
> IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the
> currently received entries (we need it for the case of concurrent updates to
> make sure that we preserve the order of update counters).
> The issue is that when we process a part of the array we keep the links to
> the processed entries until we exhaust the array (after when we finally clear
> it). Because of that we may store up to 999 garbage objects which can be a
> lot if the entries are big.
> Need to clear the entries right after we've processed them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14716) Introduce and adapt baseline topology concept into AI3.0
Vyacheslav Koptilin created IGNITE-14716: Summary: Introduce and adapt baseline topology concept into AI3.0 Key: IGNITE-14716 URL: https://issues.apache.org/jira/browse/IGNITE-14716 Project: Ignite Issue Type: Improvement Reporter: Vyacheslav Koptilin Need to adapt the concept of baseline topology (introduced by [IEP-4|https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches]) to Ignite 3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14715) Create an annotation processor for generating network message implementations
Aleksandr Polovtcev created IGNITE-14715: Summary: Create an annotation processor for generating network message implementations Key: IGNITE-14715 URL: https://issues.apache.org/jira/browse/IGNITE-14715 Project: Ignite Issue Type: Sub-task Components: networking Reporter: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14649) Create an annotation processor for generating message serializers and de-serializers
[
https://issues.apache.org/jira/browse/IGNITE-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14649:
-
Component/s: networking
> Create an annotation processor for generating message serializers and
> de-serializers
>
>
> Key: IGNITE-14649
> URL: https://issues.apache.org/jira/browse/IGNITE-14649
> Project: Ignite
> Issue Type: Sub-task
> Components: networking
>Reporter: Semyon Danilov
>Assignee: Aleksandr Polovtcev
>Priority: Major
>
> {{NetworkMessage}} instances can be (de-)serialized using instances of
> {{MessageSerializer}} and {{MessageDeserializer}} interfaces. These
> interfaces have to be implemented for every message type which is very
> tedious and can be automated. It is proposed to use annotation processing to
> generate the corresponding implementations for every network message.
> Current serialization procedure looks like the following:
> # Message header is written.
> # Message fields are sorted alphanumerically. This is done for historical
> reasons and not needed at the moment, but it was decided to keep this logic.
> # Message fields are dumped into the provided stateful {{MessageWriter}}.
> De-serialization procedure performs the same actions in reverse order.
> h3. Requirements
> # Create an annotation processor for generating instances of the following
> interfaces:
> ## {{MessageDeserializer}}
> ## {{MessageSerializer}}
> ## {{MessageSerializationFactory}}
> # Introduce the {{@AutoSerializable}} annotation that will be used to mark
> {{NetworkMessage}} implementations which will be considered as candidates for
> code generation by the annotation processor.
> # It should be possible to implement custom (de-)serializers for some
> messages. In this case it is proposed to simply omit the
> {{@AutoSerializable}} annotation on such messages.
> # Auto-generated {{MessageSerializationFactory}} instances should be
> automatically registered in a {{MessageSerializationRegistry}}. It is
> proposed to create a helper class that will add the generated factories to
> the provided registry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14714) MaxLineLength checkstyle rule
[ https://issues.apache.org/jira/browse/IGNITE-14714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-14714: Assignee: Nikolay Izhikov > MaxLineLength checkstyle rule > - > > Key: IGNITE-14714 > URL: https://issues.apache.org/jira/browse/IGNITE-14714 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > > To improve static code checks we need to add MaxLineLength checkstyle rule. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14714) MaxLineLength checkstyle rule
Nikolay Izhikov created IGNITE-14714: Summary: MaxLineLength checkstyle rule Key: IGNITE-14714 URL: https://issues.apache.org/jira/browse/IGNITE-14714 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov To improve static code checks we need to add MaxLineLength checkstyle rule. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14649) Create an annotation processor for generating message serializers and de-serializers
[
https://issues.apache.org/jira/browse/IGNITE-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14649:
-
Description:
{{NetworkMessage}} instances can be (de-)serialized using instances of
{{MessageSerializer}} and {{MessageDeserializer}} interfaces. These interfaces
have to be implemented for every message type which is very tedious and can be
automated. It is proposed to use annotation processing to generate the
corresponding implementations for every network message.
Current serialization procedure looks like the following:
# Message header is written.
# Message fields are sorted alphanumerically. This is done for historical
reasons and not needed at the moment, but it was decided to keep this logic.
# Message fields are dumped into the provided stateful {{MessageWriter}}.
De-serialization procedure performs the same actions in reverse order.
h3. Requirements
# Create an annotation processor for generating instances of the following
interfaces:
## {{MessageDeserializer}}
## {{MessageSerializer}}
## {{MessageSerializationFactory}}
# Introduce the {{@AutoSerializable}} annotation that will be used to mark
{{NetworkMessage}} implementations which will be considered as candidates for
code generation by the annotation processor.
# It should be possible to implement custom (de-)serializers for some
messages. In this case it is proposed to simply omit the {{@AutoSerializable}}
annotation on such messages.
# Auto-generated {{MessageSerializationFactory}} instances should be
automatically registered in a {{MessageSerializationRegistry}}. It is proposed
to create a helper class that will add the generated factories to the provided
registry.
was:
`NetworkMessage` instances can be (de-)serialized using instances of
`MessageSerializer` and `MessageDeserializer` interfaces. These interfaces have
to be implemented for every message type which is very tedious and can be
automated. It is proposed to use annotation processing to generate the
corresponding implementations for every network message.{color:#00}
{color}
Current serialize
> Create an annotation processor for generating message serializers and
> de-serializers
>
>
> Key: IGNITE-14649
> URL: https://issues.apache.org/jira/browse/IGNITE-14649
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Semyon Danilov
>Assignee: Aleksandr Polovtcev
>Priority: Major
>
> {{NetworkMessage}} instances can be (de-)serialized using instances of
> {{MessageSerializer}} and {{MessageDeserializer}} interfaces. These
> interfaces have to be implemented for every message type which is very
> tedious and can be automated. It is proposed to use annotation processing to
> generate the corresponding implementations for every network message.
> Current serialization procedure looks like the following:
> # Message header is written.
> # Message fields are sorted alphanumerically. This is done for historical
> reasons and not needed at the moment, but it was decided to keep this logic.
> # Message fields are dumped into the provided stateful {{MessageWriter}}.
> De-serialization procedure performs the same actions in reverse order.
> h3. Requirements
> # Create an annotation processor for generating instances of the following
> interfaces:
> ## {{MessageDeserializer}}
> ## {{MessageSerializer}}
> ## {{MessageSerializationFactory}}
> # Introduce the {{@AutoSerializable}} annotation that will be used to mark
> {{NetworkMessage}} implementations which will be considered as candidates for
> code generation by the annotation processor.
> # It should be possible to implement custom (de-)serializers for some
> messages. In this case it is proposed to simply omit the
> {{@AutoSerializable}} annotation on such messages.
> # Auto-generated {{MessageSerializationFactory}} instances should be
> automatically registered in a {{MessageSerializationRegistry}}. It is
> proposed to create a helper class that will add the generated factories to
> the provided registry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14649) Create an annotation processor for generating message serializers and deserializers
[
https://issues.apache.org/jira/browse/IGNITE-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14649:
-
Description:
`NetworkMessage` instances can be (de-)serialized using instances of
`MessageSerializer` and `MessageDeserializer` interfaces. These interfaces have
to be implemented for every message type which is very tedious and can be
automated. It is proposed to use annotation processing to generate the
corresponding implementations for every network message.{color:#00}
{color}
Current serialize
> Create an annotation processor for generating message serializers and
> deserializers
> ---
>
> Key: IGNITE-14649
> URL: https://issues.apache.org/jira/browse/IGNITE-14649
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Semyon Danilov
>Assignee: Aleksandr Polovtcev
>Priority: Major
>
> `NetworkMessage` instances can be (de-)serialized using instances of
> `MessageSerializer` and `MessageDeserializer` interfaces. These interfaces
> have to be implemented for every message type which is very tedious and can
> be automated. It is proposed to use annotation processing to generate the
> corresponding implementations for every network message.{color:#00}
> {color}
> Current serialize
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14649) Create an annotation processor for generating message serializers and de-serializers
[
https://issues.apache.org/jira/browse/IGNITE-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14649:
-
Summary: Create an annotation processor for generating message serializers
and de-serializers (was: Create an annotation processor for generating message
serializers and deserializers)
> Create an annotation processor for generating message serializers and
> de-serializers
>
>
> Key: IGNITE-14649
> URL: https://issues.apache.org/jira/browse/IGNITE-14649
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Semyon Danilov
>Assignee: Aleksandr Polovtcev
>Priority: Major
>
> `NetworkMessage` instances can be (de-)serialized using instances of
> `MessageSerializer` and `MessageDeserializer` interfaces. These interfaces
> have to be implemented for every message type which is very tedious and can
> be automated. It is proposed to use annotation processing to generate the
> corresponding implementations for every network message.{color:#00}
> {color}
> Current serialize
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14707) The topology is not always valid after node restart depending on cluster timeout settings
[ https://issues.apache.org/jira/browse/IGNITE-14707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343809#comment-17343809 ] Alexey Scherbakov edited comment on IGNITE-14707 at 5/13/21, 11:50 AM: --- The list of changes: # Implemented correct topology event handling in case nodes are restarted in quick succession. # Tuned SWIM protocol parameters to make topology events detection and propagation even more fast and stable. # Each ClusterNode now has new id field which is a temporary id changing on each restart. The topology events are bound to node id. # Added test logging to networking using slf4j simple bridge. was (Author: ascherbakov): The list of changes: # Implemented correct topology event handling in case nodes are restarted in quick succession. # Tuned SWIM protocol parameters to make topology events detection and propagation even more fast and stable. # Each ClusterNode now has new id field which is a temporary id changing on each restart. The topology events are bound to node id. # Added logging to networking using slf4j simple bridge. > The topology is not always valid after node restart depending on cluster > timeout settings > - > > Key: IGNITE-14707 > URL: https://issues.apache.org/jira/browse/IGNITE-14707 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > The reporoducer is in the first branch commit > ITNodeRestartsTest > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14707) The topology is not always valid after node restart depending on cluster timeout settings
[ https://issues.apache.org/jira/browse/IGNITE-14707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343809#comment-17343809 ] Alexey Scherbakov commented on IGNITE-14707: The list of changes: # Implemented correct topology event handling in case nodes are restarted in quick succession. # Tuned SWIM protocol parameters to make topology events detection and propagation even more fast and stable. # Each ClusterNode now has new id field which is a temporary id changing on each restart. The topology events are bound to node id. # Added logging to networking using slf4j simple bridge. > The topology is not always valid after node restart depending on cluster > timeout settings > - > > Key: IGNITE-14707 > URL: https://issues.apache.org/jira/browse/IGNITE-14707 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > > The reporoducer is in the first branch commit > ITNodeRestartsTest > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14705) Invalid handling of binary object collections
[ https://issues.apache.org/jira/browse/IGNITE-14705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-14705: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Invalid handling of binary object collections > - > > Key: IGNITE-14705 > URL: https://issues.apache.org/jira/browse/IGNITE-14705 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.3.4, python-0.4.0 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: python > Time Spent: 10m > Remaining Estimate: 0h > > There are a few issues regarding collections exists. > 1. Binary objects in collections are not unwrapped during deserialization. > 2. Collections of binary objects inside BinaryObject doesn't deserialize > properly due to broken AnyDataObject.to_python -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14705) Invalid handling of binary object collections
[ https://issues.apache.org/jira/browse/IGNITE-14705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343800#comment-17343800 ] Ivan Daschinsky commented on IGNITE-14705: -- [~isapego] Hi, could you please take a look? > Invalid handling of binary object collections > - > > Key: IGNITE-14705 > URL: https://issues.apache.org/jira/browse/IGNITE-14705 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.3.4, python-0.4.0 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: python > Time Spent: 10m > Remaining Estimate: 0h > > There are a few issues regarding collections exists. > 1. Binary objects in collections are not unwrapped during deserialization. > 2. Collections of binary objects inside BinaryObject doesn't deserialize > properly due to broken AnyDataObject.to_python -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14490) cache.invoke() triggers failure handler and freezes if entry processor is not urideployed
[ https://issues.apache.org/jira/browse/IGNITE-14490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-14490: - Fix Version/s: 2.11 > cache.invoke() triggers failure handler and freezes if entry processor is not > urideployed > - > > Key: IGNITE-14490 > URL: https://issues.apache.org/jira/browse/IGNITE-14490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.11 > > Attachments: LoclerMain.java > > Time Spent: 10m > Remaining Estimate: 0h > > If URI deployment is specified > Caused by: java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14649) Create an annotation processor for generating message serializers and deserializers
[ https://issues.apache.org/jira/browse/IGNITE-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14649: - Summary: Create an annotation processor for generating message serializers and deserializers (was: Introduce annotation processor for message serializers/deserializers) > Create an annotation processor for generating message serializers and > deserializers > --- > > Key: IGNITE-14649 > URL: https://issues.apache.org/jira/browse/IGNITE-14649 > Project: Ignite > Issue Type: Sub-task >Reporter: Semyon Danilov >Assignee: Aleksandr Polovtcev >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
