[JBoss JIRA] (JGRP-2476) MethodCall: reduce the serialized size
by Bela Ban (Jira)
Bela Ban created JGRP-2476:
------------------------------
Summary: MethodCall: reduce the serialized size
Key: JGRP-2476
URL: https://issues.redhat.com/browse/JGRP-2476
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.0.0.Beta2
MethodCallTest.testSize() shows:
{noformat}
size (TYPES): 86
size (METHOD): 186
{noformat}
This shows that the call with {{MethoCall}} has *100 bytes more* that the simple one!
Goal: reduce the size
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2475) RpcDispatcher: use ObjectMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2475?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2475.
----------------------------
Resolution: Done
> RpcDispatcher: use ObjectMessage
> --------------------------------
>
> Key: JGRP-2475
> URL: https://issues.redhat.com/browse/JGRP-2475
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Beta2
>
>
> When invoking RPCs, {{RpcDispatcher}} converts the {{MethodCall}} used into a byte array and passes that to a {{BytesMessage}} that's then sent down to the transport.
> This is inefficient, as an unneeded byte array allocation is done, both when an RPC request is sent and when the response is sent.
> Instead of doing eager marshalling of {{MethodCall}} into a byte array, pass the {{MethodCall}} to an {{ObjectMessage}}, which marshalls the latter directly to the output stream of the transport at send time.
> This eliminates 2 memory allocations per RPC round-trip (on a sync RPC).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2475) RpcDispatcher: use ObjectMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2475?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2475 at 5/14/20 8:18 AM:
---------------------------------------------------------
Actually, even better: when we *receive* a message, in the 4.x code, we'd parse the {{Message}} from the network buffer (including the byte array), and later the application would extract an object from the message's byte array.
In 5.0, if we use {{ObjectMessage}}, we construct the object _directly from the network buffer_ at receive time. This eliminates an additional memory allocation.
The lazy serialization and eager deserialization in 5.0 *saves 4 memory allocations on a sync RPC* (round trip) when using {{ObjectMessage}}!
was (Author: belaban):
Actually, even better: when we receive a message, in the 4.x code, we'd parse the {{Message}} from the network buffer (including the byte array), and later the application would extract an object from the message's byte array.
In 5.0, if we use {{ObjectMessage}}, we construct the object _directly from the network buffer_ at receive time. This eliminates an additional memory allocation. So we're *saving 4 memory allocations on a sync RPC* (round trip) when using {{ObjectMessage}}!
> RpcDispatcher: use ObjectMessage
> --------------------------------
>
> Key: JGRP-2475
> URL: https://issues.redhat.com/browse/JGRP-2475
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Beta2
>
>
> When invoking RPCs, {{RpcDispatcher}} converts the {{MethodCall}} used into a byte array and passes that to a {{BytesMessage}} that's then sent down to the transport.
> This is inefficient, as an unneeded byte array allocation is done, both when an RPC request is sent and when the response is sent.
> Instead of doing eager marshalling of {{MethodCall}} into a byte array, pass the {{MethodCall}} to an {{ObjectMessage}}, which marshalls the latter directly to the output stream of the transport at send time.
> This eliminates 2 memory allocations per RPC round-trip (on a sync RPC).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2475) RpcDispatcher: use ObjectMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2475?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2475 at 5/14/20 8:16 AM:
---------------------------------------------------------
Actually, even better: when we receive a message, in the 4.x code, we'd parse the {{Message}} from the network buffer (including the byte array), and later the application would extract an object from the message's byte array.
In 5.0, if we use {{ObjectMessage}}, we construct the object _directly from the network buffer_ at receive time. This eliminates an additional memory allocation. So we're *saving 4 memory allocations on a sync RPC* (round trip) when using {{ObjectMessage}}!
was (Author: belaban):
Actually, even better: when we receive a message, in the 4.x code, we'd parse the {{Message}} from the network buffer (including the byte array), and later the application would extract an object from the message's byte array.
In 5.0, if we use {{ObjectMessage}}, we construct the object _directly from the network buffer_ at receive time. This eliminates an additional memory allocation. So we're *saving 4 memory allocations on a sync RPC *(round trip) when using {{ObjectMessage}}!
> RpcDispatcher: use ObjectMessage
> --------------------------------
>
> Key: JGRP-2475
> URL: https://issues.redhat.com/browse/JGRP-2475
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Beta2
>
>
> When invoking RPCs, {{RpcDispatcher}} converts the {{MethodCall}} used into a byte array and passes that to a {{BytesMessage}} that's then sent down to the transport.
> This is inefficient, as an unneeded byte array allocation is done, both when an RPC request is sent and when the response is sent.
> Instead of doing eager marshalling of {{MethodCall}} into a byte array, pass the {{MethodCall}} to an {{ObjectMessage}}, which marshalls the latter directly to the output stream of the transport at send time.
> This eliminates 2 memory allocations per RPC round-trip (on a sync RPC).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2475) RpcDispatcher: use ObjectMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2475?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2475:
--------------------------------
Actually, even better: when we receive a message, in the 4.x code, we'd parse the {{Message}} from the network buffer (including the byte array), and later the application would extract an object from the message's byte array.
In 5.0, if we use {{ObjectMessage}}, we construct the object _directly from the network buffer_ at receive time. This eliminates an additional memory allocation. So we're *saving 4 memory allocations on a sync RPC *(round trip) when using {{ObjectMessage}}!
> RpcDispatcher: use ObjectMessage
> --------------------------------
>
> Key: JGRP-2475
> URL: https://issues.redhat.com/browse/JGRP-2475
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Beta2
>
>
> When invoking RPCs, {{RpcDispatcher}} converts the {{MethodCall}} used into a byte array and passes that to a {{BytesMessage}} that's then sent down to the transport.
> This is inefficient, as an unneeded byte array allocation is done, both when an RPC request is sent and when the response is sent.
> Instead of doing eager marshalling of {{MethodCall}} into a byte array, pass the {{MethodCall}} to an {{ObjectMessage}}, which marshalls the latter directly to the output stream of the transport at send time.
> This eliminates 2 memory allocations per RPC round-trip (on a sync RPC).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5331) Support for Enums in Rule Test Scenario
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5331?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5331:
-------------------------------
Summary: Support for Enums in Rule Test Scenario (was: Support for Enums in Test Scenario)
> Support for Enums in Rule Test Scenario
> ---------------------------------------
>
> Key: DROOLS-5331
> URL: https://issues.redhat.com/browse/DROOLS-5331
> Project: Drools
> Issue Type: Feature Request
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
>
> Currently, Test Scenario doesn't support an attribute of Enumeration type.
> In case of RULE Scenario:
> Loading a Data Object with such attribute, will result in Complex Type properties with a nested simple property "declaringClass" of "java.lang.Class" type.
> The expected result should be a Simple property of Enum type (in this case: category [java.lang.Enum] )
> In case of DMN Scenario:
> Currently no impacts
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5331) Support for Enums in Test Scenario
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5331?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5331:
-------------------------------
Description:
Currently, Test Scenario doesn't support an attribute of Enumeration type.
In case of RULE Scenario:
Loading a Data Object with such attribute, will result in Complex Type properties with a nested simple property "declaringClass" of "java.lang.Class" type.
The expected result should be a Simple property of Enum type (in this case: category [java.lang.Enum] )
In case of DMN Scenario:
Currently no impacts
> Support for Enums in Test Scenario
> ----------------------------------
>
> Key: DROOLS-5331
> URL: https://issues.redhat.com/browse/DROOLS-5331
> Project: Drools
> Issue Type: Feature Request
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
>
> Currently, Test Scenario doesn't support an attribute of Enumeration type.
> In case of RULE Scenario:
> Loading a Data Object with such attribute, will result in Complex Type properties with a nested simple property "declaringClass" of "java.lang.Class" type.
> The expected result should be a Simple property of Enum type (in this case: category [java.lang.Enum] )
> In case of DMN Scenario:
> Currently no impacts
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months