[JBoss JIRA] (JGRP-2012) Request: optimize in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2012?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2012 at 2/2/16 8:28 AM:
--------------------------------------------------------
* Removed {{Request.request_msg}}, passed via {{execute()}}
* Removed {{UnicastRequest.num_received}}
** Not done on 3.6.8, as MuxRpcDispatcher requires this field
* Removed {{Request.block_for_results}}
was (Author: belaban):
* Removed {{Request.request_msg}}, passed via {{execute()}}
* Removed {{UnicastRequest.num_received}}
* Removed {{Request.block_for_results}}
> Request: optimize in-memory size
> --------------------------------
>
> Key: JGRP-2012
> URL: https://issues.jboss.org/browse/JGRP-2012
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> {{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
> * {{request_msg}} can be removed and instead passed as arg to {{execute()}}
> * Remove {{UnicastRequest.num_received}} ?
> * Investigate whether more fields can be removed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2012) Request: optimize in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2012?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2012 at 2/2/16 8:01 AM:
--------------------------------------------------------
* Removed {{Request.request_msg}}, passed via {{execute()}}
* Removed {{UnicastRequest.num_received}}
* Removed {{Request.block_for_results}}
was (Author: belaban):
* Removed {{UnicastRequest.num_received}}
* Removed {{Request.block_for_results}}
> Request: optimize in-memory size
> --------------------------------
>
> Key: JGRP-2012
> URL: https://issues.jboss.org/browse/JGRP-2012
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> {{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
> * {{request_msg}} can be removed and instead passed as arg to {{execute()}}
> * Remove {{UnicastRequest.num_received}} ?
> * Investigate whether more fields can be removed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2011) Rsp: optimize in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2011?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2011.
----------------------------
Resolution: Done
> Rsp: optimize in-memory size
> ----------------------------
>
> Key: JGRP-2011
> URL: https://issues.jboss.org/browse/JGRP-2011
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> The in-memory size of {{Rsp}} can be made smaller. Currently, it looks like this:
> {noformat}
> public class Rsp {
> protected boolean received;
> protected boolean suspected;
> protected boolean unreachable;
> protected final Address sender;
> protected T retval;
> protected Throwable exception;
> }
> {noformat}
> Optimizations:
> # received, suspected and unreachable can be compacted into a byte field (flags)
> # retval and exception can be merged into {{Object value}}
> # sender can be removed: {{RspList}} already has the sender
> New format:
> {noformat}
> public class Rsp {
> protected byte flags;
> protected Object value;
> }
> {noformat}
> Size of {{Rsp}} is 32 bytes (used JOL to measure) before, and 24 bytes after the changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5989) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5989?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-5989:
-------------------------------
Description:
# Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
{noformat}
./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
{noformat}
results in exception:
{noformat}
java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
{noformat}
To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
{noformat}
new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
new RemotingPermission("createEndpoint"),
new RuntimePermission("createXnioWorker"),
new RemotingPermission("addConnectionProvider"),
new RuntimePermission("modifyThread"),
new RuntimePermission("accessDeclaredMembers"),
new ReflectPermission("suppressAccessChecks")
{noformat}
which is very confusing.
Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
was:
Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
{noformat}
./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
{noformat}
results in exception:
{noformat}
java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
{noformat}
To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
{noformat}
new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
new RemotingPermission("createEndpoint"),
new RuntimePermission("createXnioWorker"),
new RemotingPermission("addConnectionProvider"),
new RuntimePermission("modifyThread"),
new RuntimePermission("accessDeclaredMembers"),
new ReflectPermission("suppressAccessChecks")
{noformat}
which is very confusing.
Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5989
> URL: https://issues.jboss.org/browse/WFLY-5989
> Project: WildFly
> Issue Type: Bug
> Components: Remoting, Security Manager
> Affects Versions: 10.0.0.CR5
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-1620) MessageDispatcher changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1620?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1620:
---------------------------
Description:
* In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
* Return null from castMessage() if the call is async, instead of a null {{RspList}}
* Investigate whether non-blocking RPCs need to create Request instances at all
was:
* In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
* Return null from castMessage() if the call is async, instead of a null {{RspList}}
> MessageDispatcher changes
> -------------------------
>
> Key: JGRP-1620
> URL: https://issues.jboss.org/browse/JGRP-1620
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> * In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
> ** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
> * Return null from castMessage() if the call is async, instead of a null {{RspList}}
> * Investigate whether non-blocking RPCs need to create Request instances at all
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2012) Request: optimize in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2012?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2012:
---------------------------
Description:
{{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
* {{request_msg}} can be removed and instead passed as arg to {{execute()}}
* Remove {{UnicastRequest.num_received}} ?
* Investigate whether more fields can be removed
was:
{{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
* {{request_msg}} can be removed and instead passed as arg to {{execute()}}
* *Investigate whether non-blocking RPCs need to create Request instances at all*
* Remove {{UnicastRequest.num_received}} ?
* Investigate whether more fields can be removed
> Request: optimize in-memory size
> --------------------------------
>
> Key: JGRP-2012
> URL: https://issues.jboss.org/browse/JGRP-2012
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> {{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
> * {{request_msg}} can be removed and instead passed as arg to {{execute()}}
> * Remove {{UnicastRequest.num_received}} ?
> * Investigate whether more fields can be removed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2012) Request: optimize in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2012?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2012:
---------------------------
Description:
{{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
* {{request_msg}} can be removed and instead passed as arg to {{execute()}}
* *Investigate whether non-blocking RPCs need to create Request instances at all*
* Remove {{UnicastRequest.num_received}} ?
* Investigate whether more fields can be removed
was:
{{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
* {{request_msg}} can be removed and instead passed as arg to {{execute()}}
* *Investigate whether non-blocking RPCs need to create Request instances at all*
* Removed {{UnicastRequest.num_received}} ?
* Investigate whether more fields can be removed
> Request: optimize in-memory size
> --------------------------------
>
> Key: JGRP-2012
> URL: https://issues.jboss.org/browse/JGRP-2012
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> {{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
> * {{request_msg}} can be removed and instead passed as arg to {{execute()}}
> * *Investigate whether non-blocking RPCs need to create Request instances at all*
> * Remove {{UnicastRequest.num_received}} ?
> * Investigate whether more fields can be removed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2012) Request: optimize in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2012?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2012:
--------------------------------
* Removed {{UnicastRequest.num_received}}
* Removed {{Request.block_for_results}}
> Request: optimize in-memory size
> --------------------------------
>
> Key: JGRP-2012
> URL: https://issues.jboss.org/browse/JGRP-2012
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> {{Request}}, {{UnicastRequest}} and {{GroupRequest}} can be optimized:
> * {{request_msg}} can be removed and instead passed as arg to {{execute()}}
> * *Investigate whether non-blocking RPCs need to create Request instances at all*
> * Remove {{UnicastRequest.num_received}} ?
> * Investigate whether more fields can be removed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months