October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-772) HA-JNDI multicast reply not reaching client

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-772?page=all ] Brian Stansberry updated JBAS-772: ---------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta) > HA-JNDI multicast reply not reaching client > ------------------------------------------- > > Key: JBAS-772 > URL: http://jira.jboss.com/jira/browse/JBAS-772 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > Assigned To: Jerry Gauthier > Fix For: JBossAS-5.0.0.CR1 > > Attachments: DeviceManager.jsp, DeviceModule.java, TelematicsJNDI.java > > > SourceForge Submitter: rmontag . > I just made some expiriences with the HA-JNDI multicast > and running multiple instances on a single machine. I > encountered some problems... > My setup: > - JBoss 3.2.2 > - JDK 1.4.2 > - Two instances running on a single W2K-PC, > alternatively I 'm using two instances running on a > single SUN solaris. instance 1 using 1200 as HA-JNDI > port, instance 2 using 1300. > - "JBoss Clustering" documentation, 4. edition > - Standalone testclient (JUnit) on PC or SUN, > configured for Multicast (url-property not set) > The problem: > Case A: Testclient and server instances on PC > Case B: Testclient on PC, server instances on SUN > When starting my testclient and making a lookup via > multicast, both instances receive the GET_ADDRESS > datagram. Then each server send a datagram packet back > NOT using a multcast. Since the testclient opens a > MulticastSocket on the Multigroup port 1102, each > server sends a response datagramm back to <client-ip>:1102. > I encountered two problems with this approach: > 1) If client and server are one the same instance like > in case A, they have the same ip-address. In my > environment one server instance always "catches" all > the answers, so the client timed-out with no answers > (Note: On W2K, I set "loopback" to true, on SUN to > false as described in the cluster document). > 2) Same problem if two clients on one instance make a > concurrent multicast call (servers on other machine): > Both waiting for responses, only one client catches all > the responses. The second client ever lose. > Two possible solutions come to my mind: > 1) Currently the NamingContext opens a MulticastSocket > on the multicast group port. If the client would use a > different dedicated port, he can send his call with the > multicast group address and the server could reply to > <client-ip>:<dedicated client-port> with his answer. No > one else (another client or server) would "catch" the > server response if using different port numbers > (Disadvantage: One additional HA-JNDI JNP property like > "jnp.multicastPort"). > 2) HANamingService currently sends a response datagram > back to a dedicated IP:port address (Unicast). Why > doesn't the server also sends a multicast call using > the well-known multicast group address to propagate his > answer ? A multicast answer seems to be a clean > solution because: a) All clients waiting for an answer > will receive them and b) other server(s) receiving the > answer will ignore them as they already do now. > Solution 2 simply means exchanging one line in > HANamingService.java: > Instead of > DatagramPacket p = new DatagramPacket (ipAddress, > ipAddress.length, packet.getAddress(), packet.getPort()); > do this one: > DatagramPacket p = new DatagramPacket(ipAddress, > ipAddress.length, group, adGroupPort); > Solution 1, as stated above would need one additinal > config property for the client port. -- 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

19 years, 3 months

1
0
0 / 0

[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

19 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

19 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

19 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

19 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

19 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

19 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

19 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

19 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

19 years, 3 months

1
1
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 October 2006