[JBoss JIRA] Updated: (JBAS-2957) Replace HA-JNDI AutoDiscovery with JGroups based implementation
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2957?page=all ]
Brian Stansberry updated JBAS-2957:
-----------------------------------
Fix Version/s: JBossAS-5.0.0.CR1
(was: JBossAS-5.0.0.Beta)
I'm changing this to 5.0.0.CR1 on the slight chance a good way to do this comes out of Remoting work. But it's on the knife edge of being 'No Release' (i.e. someday....) or 'Won't Fix'.
> Replace HA-JNDI AutoDiscovery with JGroups based implementation
> ---------------------------------------------------------------
>
> Key: JBAS-2957
> URL: http://jira.jboss.com/jira/browse/JBAS-2957
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Jerry Gauthier
> Assigned To: Jerry Gauthier
> Priority: Minor
> Fix For: JBossAS-5.0.0.CR1
>
>
> HA-JNDI AutoDiscovery uses its own IP multicasting-based discovery mechanism. This is error-prone code and should be replaced with the well-tested JGroups framework.
> See JIRA issue JBCLUSTER-43 for further details.
--
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
[JBoss JIRA] Updated: (JBAS-1483) Black box testing for http session (with and without replication)
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1483?page=all ]
Brian Stansberry updated JBAS-1483:
-----------------------------------
Fix Version/s: JBossAS-5.0.1.CR1
(was: JBossAS-5.0.0.Beta)
Since this issue was created, a large number of unit tests of failover session behavior in have been added. These include, perhaps accidentally, quite a bit of simple testing of non-failover behavior. We need to beef up the testing of the non-failover behavior. Good news is much of this behavior is inherited from the Tomcat code.
> Black box testing for http session (with and without replication)
> -----------------------------------------------------------------
>
> Key: JBAS-1483
> URL: http://jira.jboss.com/jira/browse/JBAS-1483
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Ben Wang
> Fix For: JBossAS-5.0.1.CR1
>
> Original Estimate: 4 weeks
> Remaining Estimate: 4 weeks
>
> While talking with Ivelin, I think we need to have more black box testing for http requests with and without replication. Every feature in single node should also be supported bu clustering, plus some additional use caes for clustering failover. But currently, I only have limited unit test case for clustering in term of failing over.
> So here is two main steps:
> 1. Create an automated black box testing suite for http session request in a single node. We can use some tool to do this. Question is we need to define the tests.
> 2. Currently, Tomcat has a whole suite of unit testing on http session. We should look into that to see if we can re-use some of it in our own Tomcat module.
> 3. Create test cases for fail-over. I can help to define the set here.
--
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
[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
18 years, 3 months