October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-1641) Benchmarking and Load testing http session replication between different settings

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1641?page=all ] Brian Stansberry updated JBAS-1641: ----------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta) > Benchmarking and Load testing http session replication between different settings > --------------------------------------------------------------------------------- > > Key: JBAS-1641 > URL: http://jira.jboss.com/jira/browse/JBAS-1641 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: JBossAS-5.0.0.CR1 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > We will need load test http session replication using different config settings. > For example, > 1. Syncrhonous vs. asychronous cache mode > 2. Replicationg ranularity: SESSION, ATTRIBUTE, and FIELD > 3. Snapshot manager: instant and periodic -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2750) Create integration tests using JBossCache and JBoss TM

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2750?page=all ] Brian Stansberry updated JBAS-2750: ----------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta) Move to 5.0.0.CR1, not needed for beta. > Create integration tests using JBossCache and JBoss TM > ------------------------------------------------------ > > Key: JBAS-2750 > URL: http://jira.jboss.com/jira/browse/JBAS-2750 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Fix For: JBossAS-5.0.0.CR1 > > > Need to add integration tests that confirm that JBossCache works properly with JBoss TM as its transaction manager. The standalone cache unit tests use DummyTransactionManager, as use of JBoss TM requires the app server. Beginning with 4.0.4, the AS web-tier state replication tests also no longer use JBoss TM. > See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76306 for an example of the kind of thing such tests should find. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2784) ClusterPartition should close the channel rather than HAPartitionImpl

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2784?page=all ] Brian Stansberry updated JBAS-2784: ----------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta) Pushing out to 5.0.0.CR1; this is a minor thing that doesn't need to be in beta. > ClusterPartition should close the channel rather than HAPartitionImpl > --------------------------------------------------------------------- > > Key: JBAS-2784 > URL: http://jira.jboss.com/jira/browse/JBAS-2784 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Minor > Fix For: JBossAS-5.0.0.CR1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > ClusterPartition is responsible for creating the JGroups channel, but in destroyService() closing the channel is delegated to HAPartitionImpl. Should rationalize this, to help keep the roles of the different classes simpler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-3262) Analyze and adjust for impact of Multiplexer viewAccepted() semantics on services that monitor cluster topology.

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3262?page=all ] Brian Stansberry closed JBAS-3262. ---------------------------------- Fix Version/s: (was: JBossAS-5.0.0.Beta) Resolution: Out of Date > Analyze and adjust for impact of Multiplexer viewAccepted() semantics on services that monitor cluster topology. > ---------------------------------------------------------------------------------------------------------------- > > Key: JBAS-3262 > URL: http://jira.jboss.com/jira/browse/JBAS-3262 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Critical > Original Estimate: 1 week > Remaining Estimate: 1 week > > With the JGroups Mutliplexer, viewAccepted() notifications will not be sent out as services that create/destroy a MuxChannel connect and disconnect, but only when the mutliplexed JChannel connects and disconnects. JGroups MembershipListener implementations that are expecting a tighter relationship between a service lifecycle and viewAccepted() notifications may have trouble with this behavior. > HAPartition implements MembershipListener, and then passes the view info on to any implementation of HAPartition.HAMembershipListener. > Scanning in the AS codebase for implementations of that interface, I find: > 1) DRM. I have to check more carefully, but I believe DRM will handle MUX semantics just fine. A major function of DRM is to maintain a registry of what higher level services are using the channel; those higher level services tell DRM when they come and go. For DRM viewAccepted() is more of a second line of defense in case of node crashes, etc. > 2) org.jboss.aspects.versioned.DistributedSynchronizationManager. I'm not even sure exactly what this is, but it's using view changes to find and remove distributed locks held by the members no longer in the view. This could break if an app holding locks were redeployed but the channel was not. But, I think that problem exists regardless of whether MUX is involved. > 3) TopologyMonitorService. OK w/ MUX semantics if the purpose of monitoring was to see who was using the multiplexed JChannel. Not OK if the purpose was to monitor who was using the HAPartition on top of the multiplexed JChannel. This is a distinction users of the service will probably find difficult to understand. Also, may miss the initial viewAccepted() if the HAPartition is deployed separately from the JChannel. > 4) ClusterFileTransfer (part of farming). Uses viewAccepted to stop in-progress file transfers to/from dead nodes. Again, if a remote HAPartion is redeployed but the JChannel is not, this event will be missed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBAS-3262) Analyze and adjust for impact of Multiplexer viewAccepted() semantics on services that monitor cluster topology.

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3262?page=all ] Brian Stansberry reopened JBAS-3262: ------------------------------------ Reopen to get rid of Fix Version. > Analyze and adjust for impact of Multiplexer viewAccepted() semantics on services that monitor cluster topology. > ---------------------------------------------------------------------------------------------------------------- > > Key: JBAS-3262 > URL: http://jira.jboss.com/jira/browse/JBAS-3262 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Critical > Original Estimate: 1 week > Remaining Estimate: 1 week > > With the JGroups Mutliplexer, viewAccepted() notifications will not be sent out as services that create/destroy a MuxChannel connect and disconnect, but only when the mutliplexed JChannel connects and disconnects. JGroups MembershipListener implementations that are expecting a tighter relationship between a service lifecycle and viewAccepted() notifications may have trouble with this behavior. > HAPartition implements MembershipListener, and then passes the view info on to any implementation of HAPartition.HAMembershipListener. > Scanning in the AS codebase for implementations of that interface, I find: > 1) DRM. I have to check more carefully, but I believe DRM will handle MUX semantics just fine. A major function of DRM is to maintain a registry of what higher level services are using the channel; those higher level services tell DRM when they come and go. For DRM viewAccepted() is more of a second line of defense in case of node crashes, etc. > 2) org.jboss.aspects.versioned.DistributedSynchronizationManager. I'm not even sure exactly what this is, but it's using view changes to find and remove distributed locks held by the members no longer in the view. This could break if an app holding locks were redeployed but the channel was not. But, I think that problem exists regardless of whether MUX is involved. > 3) TopologyMonitorService. OK w/ MUX semantics if the purpose of monitoring was to see who was using the multiplexed JChannel. Not OK if the purpose was to monitor who was using the HAPartition on top of the multiplexed JChannel. This is a distinction users of the service will probably find difficult to understand. Also, may miss the initial viewAccepted() if the HAPartition is deployed separately from the JChannel. > 4) ClusterFileTransfer (part of farming). Uses viewAccepted to stop in-progress file transfers to/from dead nodes. Again, if a remote HAPartion is redeployed but the JChannel is not, this event will be missed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-3262) Analyze and adjust for impact of Multiplexer viewAccepted() semantics on services that monitor cluster topology.

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3262?page=all ] Brian Stansberry closed JBAS-3262. ---------------------------------- Resolution: Out of Date The Multiplexer now sends out service-specific views, so from the point of view of the service the behavior is the same as before. > Analyze and adjust for impact of Multiplexer viewAccepted() semantics on services that monitor cluster topology. > ---------------------------------------------------------------------------------------------------------------- > > Key: JBAS-3262 > URL: http://jira.jboss.com/jira/browse/JBAS-3262 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Critical > Fix For: JBossAS-5.0.0.Beta > > Original Estimate: 1 week > Remaining Estimate: 1 week > > With the JGroups Mutliplexer, viewAccepted() notifications will not be sent out as services that create/destroy a MuxChannel connect and disconnect, but only when the mutliplexed JChannel connects and disconnects. JGroups MembershipListener implementations that are expecting a tighter relationship between a service lifecycle and viewAccepted() notifications may have trouble with this behavior. > HAPartition implements MembershipListener, and then passes the view info on to any implementation of HAPartition.HAMembershipListener. > Scanning in the AS codebase for implementations of that interface, I find: > 1) DRM. I have to check more carefully, but I believe DRM will handle MUX semantics just fine. A major function of DRM is to maintain a registry of what higher level services are using the channel; those higher level services tell DRM when they come and go. For DRM viewAccepted() is more of a second line of defense in case of node crashes, etc. > 2) org.jboss.aspects.versioned.DistributedSynchronizationManager. I'm not even sure exactly what this is, but it's using view changes to find and remove distributed locks held by the members no longer in the view. This could break if an app holding locks were redeployed but the channel was not. But, I think that problem exists regardless of whether MUX is involved. > 3) TopologyMonitorService. OK w/ MUX semantics if the purpose of monitoring was to see who was using the multiplexed JChannel. Not OK if the purpose was to monitor who was using the HAPartition on top of the multiplexed JChannel. This is a distinction users of the service will probably find difficult to understand. Also, may miss the initial viewAccepted() if the HAPartition is deployed separately from the JChannel. > 4) ClusterFileTransfer (part of farming). Uses viewAccepted to stop in-progress file transfers to/from dead nodes. Again, if a remote HAPartion is redeployed but the JChannel is not, this event will be missed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-745) Create JACC Permissions when JBoss SecurityDomain annotation is missing

by Anil Saldhana (JIRA)

Create JACC Permissions when JBoss SecurityDomain annotation is missing ----------------------------------------------------------------------- Key: EJBTHREE-745 URL: http://jira.jboss.com/jira/browse/EJBTHREE-745 Project: EJB 3.0 Issue Type: Bug Components: Security Affects Versions: EJB 3.0 RC9 - FD Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: EJB 3.0 RC10 - FD -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBAS-3326) Implement JACC 1.1 Specification

by Anil Saldhana (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3326?page=all ] Anil Saldhana closed JBAS-3326. ------------------------------- Resolution: Done The permissions are all created based on the specification. I am currently validating ejb3 jacc layer in EJBTHREE-744 > Implement JACC 1.1 Specification > -------------------------------- > > Key: JBAS-3326 > URL: http://jira.jboss.com/jira/browse/JBAS-3326 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: JBossAS-5.0.0.Beta > Reporter: Anil Saldhana > Assigned To: Anil Saldhana > Fix For: JBossAS-5.0.0.Beta > > > JEE 5 mandates support for JACC 1.1 (Maintenance release for JACC 1.0 specification). > The JBoss implementation should be updated for JACC 1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-743) POJO Service Bean lacks a way to set "MBean attributes" for deployment

by Wenbo Zhu (JIRA)

POJO Service Bean lacks a way to set "MBean attributes" for deployment ---------------------------------------------------------------------- Key: EJBTHREE-743 URL: http://jira.jboss.com/jira/browse/EJBTHREE-743 Project: EJB 3.0 Issue Type: Feature Request Components: EJB3 Extensions Affects Versions: EJB 3.0 RC8 - FD Environment: JBoss AS 4.0.4 with ejb3 Reporter: Wenbo Zhu See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91030. Ideally, annotation Service should support "attribute=value", in addition to objectName and name. To align with the old service bean (sar) deployment, a "description" attribute should also be added. This will imply extending xsd for the jboss.xml too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3761) Assembly & Deployment tool

by Gilles Bardouillet (JIRA)

Assembly & Deployment tool -------------------------- Key: JBAS-3761 URL: http://jira.jboss.com/jira/browse/JBAS-3761 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Other Reporter: Gilles Bardouillet Hi, I'm looking for a graphical tool (outside the develoment scope) to edit JBoss deployment descriptors stored in EAR archive. This kind of tool exists for all others appserver (bea, ibm, sun..), but i didnt find it for jboss. It will be cool to have it for JBoss.... Regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2006