August 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (REMJMX-61) Ensure Subject of remote user is associated with the AccessControContext handling the request.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-61?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-61: ----------------------------------- Description: WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext. As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext. No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads. This will need to apply to all versions of the protocol - this is specifically a server side change but the remote side of the connection may be using the older protocol versions. was: WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext. As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext. No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads. > Ensure Subject of remote user is associated with the AccessControContext handling the request. > ---------------------------------------------------------------------------------------------- > > Key: REMJMX-61 > URL: https://issues.jboss.org/browse/REMJMX-61 > Project: Remoting JMX > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.1.CR1, 2.0.0.Beta2 > > > WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext. > As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext. > No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads. > This will need to apply to all versions of the protocol - this is specifically a server side change but the remote side of the connection may be using the older protocol versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-61) Ensure Subject of remote user is associated with the AccessControContext handling the request.

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-61: -------------------------------------- Summary: Ensure Subject of remote user is associated with the AccessControContext handling the request. Key: REMJMX-61 URL: https://issues.jboss.org/browse/REMJMX-61 Project: Remoting JMX Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.1.CR1, 2.0.0.Beta2 WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext. As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext. No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-58) Remote JMX invocation are written out byte at a time

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-58?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved REMJMX-58. ------------------------------------ Resolution: Done > Remote JMX invocation are written out byte at a time > ---------------------------------------------------- > > Key: REMJMX-58 > URL: https://issues.jboss.org/browse/REMJMX-58 > Project: Remoting JMX > Issue Type: Bug > Components: RPC > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.0.6.CR1, 1.1.1.CR1, 2.0.0.Beta2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1436) GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1436?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1436. ---------------------------- Resolution: Won't Fix > GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE > ----------------------------------------------------------- > > Key: JGRP-1436 > URL: https://issues.jboss.org/browse/JGRP-1436 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4 > > > View bundling in GMS bundles events based on (1) whether they can be processed together and (2) whether a view bundling timeout is defined. The latter timeout is for all events, perhaps we want to define separate timeouts, e.g. the timeout for JOINs is 3000, but for LEAVE it is 500. This means that when we get multiple JOIN events, we'll wait up to 5 seconds and then process them together. When we get multiple LEAVE requests, we only wait for half a second before processing them. This causes LEAVEs to be processed almost immediately, whereas JOINs are bundled. > Also revisit the code which determines which events can be processed together. Perhaps MERGE events can be bundled, too ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1436) GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1436?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1436 at 8/1/13 6:41 AM: -------------------------------------------------------- Don't think I want to do this as it complicates the code; having separate timeouts for joins, leaves and suspects means we'd have to maintain 3 instead of 1 queue in GMS.ViewHandler. Keeping GMS.max_bundling_time sufficiently small, e.g. 50-500ms, guarantees speedy processing of those events. was (Author: belaban): Don't think I want to do this as it complicates the code; having separate timeouts for joins, leaves and suspects (?) means we'd have to maintain 3 instead of 1 queue in GMS.ViewHandler. Keeping GMS.max_bundling_time sufficiently small, e.g. 50-500ms, guarantees speedy processing of those events. > GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE > ----------------------------------------------------------- > > Key: JGRP-1436 > URL: https://issues.jboss.org/browse/JGRP-1436 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4 > > > View bundling in GMS bundles events based on (1) whether they can be processed together and (2) whether a view bundling timeout is defined. The latter timeout is for all events, perhaps we want to define separate timeouts, e.g. the timeout for JOINs is 3000, but for LEAVE it is 500. This means that when we get multiple JOIN events, we'll wait up to 5 seconds and then process them together. When we get multiple LEAVE requests, we only wait for half a second before processing them. This causes LEAVEs to be processed almost immediately, whereas JOINs are bundled. > Also revisit the code which determines which events can be processed together. Perhaps MERGE events can be bundled, too ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-58) Remote JMX invocation are written out byte at a time

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-58?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reopened REMJMX-58: ------------------------------------ > Remote JMX invocation are written out byte at a time > ---------------------------------------------------- > > Key: REMJMX-58 > URL: https://issues.jboss.org/browse/REMJMX-58 > Project: Remoting JMX > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.0.6.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-58) Remote JMX invocation are written out byte at a time

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-58?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-58: ----------------------------------- Component/s: RPC > Remote JMX invocation are written out byte at a time > ---------------------------------------------------- > > Key: REMJMX-58 > URL: https://issues.jboss.org/browse/REMJMX-58 > Project: Remoting JMX > Issue Type: Bug > Components: RPC > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.0.6.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-58) Remote JMX invocation are written out byte at a time

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-58?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-58: ----------------------------------- Fix Version/s: 1.1.1.CR1 2.0.0.Beta2 > Remote JMX invocation are written out byte at a time > ---------------------------------------------------- > > Key: REMJMX-58 > URL: https://issues.jboss.org/browse/REMJMX-58 > Project: Remoting JMX > Issue Type: Bug > Components: RPC > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.0.6.CR1, 1.1.1.CR1, 2.0.0.Beta2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-60) Add HTTP Upgrade Support

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-60: -------------------------------------- Summary: Add HTTP Upgrade Support Key: REMJMX-60 URL: https://issues.jboss.org/browse/REMJMX-60 Project: Remoting JMX Issue Type: Feature Request Components: Connection Reporter: Darran Lofthouse Assignee: Stuart Douglas Fix For: 2.0.0.Beta1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-60) Add HTTP Upgrade Support

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-60?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved REMJMX-60. ------------------------------------ Resolution: Done https://github.com/jbossas/remoting-jmx/commit/aa609dbef6fb3850e6c7026db3... > Add HTTP Upgrade Support > ------------------------ > > Key: REMJMX-60 > URL: https://issues.jboss.org/browse/REMJMX-60 > Project: Remoting JMX > Issue Type: Feature Request > Components: Connection > Reporter: Darran Lofthouse > Assignee: Stuart Douglas > Fix For: 2.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2013