[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)
9 years, 10 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)
9 years, 10 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)
9 years, 10 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)
9 years, 10 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)
9 years, 10 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)
9 years, 10 months
[JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugi... ]
Petr Široký commented on DROOLS-1048:
-------------------------------------
One additional possibility could be to directly rename the org.unit. Github seems to support that: https://help.github.com/articles/renaming-an-organization/. The advantage would be that the old URLs should still work.
> Change github url from github.com/droolsjbpm/ to github.com/kiegroup/
> ---------------------------------------------------------------------
>
> Key: DROOLS-1048
> URL: https://issues.jboss.org/browse/DROOLS-1048
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Critical
>
> [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care.
> Preparation:
> 1) Get some experience
> - Make a dummy repository in droolsjbpm, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times:
> -- Once from droolsjbpm
> -- Once from your user account with droolsjbpm addes as upstream ("git remote add upstream ...github.com/droolsjbpm/...")
> - Add some local changes on both dirs.
> - On GitHub, go into the repository settings, in the danger zone and move it from droolsjbpm to kiegroup.
> - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use.
> -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later.
> -- Once it's fixed, see if you can do git operations without having to specify origin for the direct droolsjbpm clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step.
> -- What happened to the open PR?
> 2) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving.
> 3) Set up roles and users of github.com/kiegroup.
> 4) Reach out
> - Talk to each type of person involved:
> -- R&D developer
> -- QA
> -- Productization
> -- Product docs
> -- Community
> - Make an inventory of references to "github.com/droolsjbpm"
> -- Do a find in path on all our files for "github.com/droolsjbpm")
> -- Which webapps reference it?
> --- jenkins
> --- jira
> --- www.openhub.net
> --- gitter
> --- stackoverflow
> --- google forums / mailing lists
> --- ...
> - Set a date when you'll be moving the first repository.
> -- Clearly communicate on all channels to let everyone know. This includes:
> --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ...
> --- Internal mailing lists: sme-brms, pm lists, bsig, etc
> --- IRC channel topics
> --- Social media (Twitter accounts etc)
> --- ...
> - Clearly communicate:
> -- What you'll do
> -- When you'll do it
> -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good!
> -- A recipe: What they need to do - step by step for dummies - after the merge is done.
> -- Get someone to review this mail before it goes out.
> - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work.
> 5) Do it:
> - You can do one repository at a time, or do multiple at the same time.
> -- I'd recommend to start with just 1 to get a feel for it.
> - Do them in reverse order of the repository-list.txt!
> - DELETE THE OLD REPOSITORY. DO NOT COPY IT, BUT MOVE IT.
> -- After the move, we want anyone that's trying to pull from droolsjbpm to clearly *fail* pulling, but without losing local changes.
> -- Some people will not have read your mail, they need to fail when pulling, otherwise they'll find themselves asking in 5 months why we haven't done any changes in 5 months.
> - In droolsjbpm, create a repository called all_repositories_have_moved_to_github_com_kiegroup and make sure it's on the top of the list of the droolsjbpm repositories. Add a link in it's readme.adoc. This is for people who follow dead links from stackoverflow etc.
> - Migrations like this should really happen during the weekend to reduce the impact on the rest of the team, ask your manager to swap a weekday for a weekend day.
> 6) Clean up the fallout
> - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not).
> Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 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*
* Removed {{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*
> * Removed {{UnicastRequest.num_received}} ?
> * Investigate whether more fields can be removed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 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}}
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).
> 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}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months