[GLASSFISH-15637] IIOP Loadbalancing not happening Created: 20/Jan/11  Updated: 13/Feb/13  Due: 01/Feb/11

Status: Reopened
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1_b38
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: gopaljorapur Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File patch.tgz    
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

IIOP Loadbalancing not happening with certain apps

The Initial context is created as follows

public void createContextForACC()
{
try

{ InitialContext initial = new InitialContext(); myEnv = (InitialContext)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

All new ic creations are going to same instance



 Comments   
Comment by Ken Cavanaugh [ 21/Jan/11 ]

I don't understand what is failing here. Is this an issue about some of the failover
tests? Which ones?

Or is it an issue about how the InitialContext is created?

I also have no idea what a lookup of java:comp/env/ejb is supposed to do.
This is not part of IIOP or FOLB.

Please clarify or close this issue.

Comment by gopaljorapur [ 21/Jan/11 ]

The loadbalancing is not happening, all new ic creations happen on one random instance in the cluster

Comment by Ken Cavanaugh [ 25/Jan/11 ]

This issue does not currently correctly describe the observed problem.
I THINK (from email and conversation with Gopal) that the problem is
that loadbalancing does not happen when the endpoints property is specified
in the app client command, but DOES happen when the endpoints property
is passed to the (first) new InitialContext call.

I will investigate that question in my testing shortly.

Comment by Ken Cavanaugh [ 26/Jan/11 ]

My test (same as the 14867 existing instance case) works with -Dcom.sun.appserver.iiop.endpoints specified,
but fails with appclient -targetserver. I've sent email to Tim to see if this is a configuration error in
my code, or an error in the ACC argument parsing.

Comment by Ken Cavanaugh [ 30/Jan/11 ]

This patch contains two fixes:

1. The sticky context reference count has been fixed to avoid extra increments, which
creates a "stuck" condition in which the same SerialContext underlying the InitialContext
call is used all the time. This fix is in glassfish-naming.

2. I added code to the ORB to detect and specially label name service implementations.
The FOLB server group manager then arranges to always send a membership label
update on the reply to any name server invocation. This means that the
lookup call on the new InitialContext will get any updates to the cluster shape.
This in turn prevents the situation where the client is always obtaining up-to-date
references from naming, but the new InitialContext call is not informed of the changes
(which happens only the the ClientGroupManager receives a response contains an
updated IOR for a membership label change).

Just unpatch the patch into the modules directory as usual.

Comment by Ken Cavanaugh [ 31/Jan/11 ]

How bad is its impact? (Severity)
Regression in IIOP FOLB from GF 2.1.

How often does it happen? (Frequency)
Happens all the time in the following test scenario (which should have
been added earlier to this issue):

0. Start with com.sun.appserv.iiop.endpoints referring to two elements, the one to start in step 2
and another in the cluster.
1. Stop the cluster.
2. Start 1 instance (inst) in the cluster.
3. LB to one instance
4. Start cluster
5. Kill inst
6. LB test

This fails because LB happens to only one instance.

How much effort is required to fix it?
I have the fixes made, and the IIOP FOLB dev test passes.
Fixes are in the ORB (new support for labelling object implementations as being in a name service)
and in glassfish-naming (Fixes in how endpoint lists are merged in RoundRobinPolicy,
and fixes in sticky context reference counting in SerialContext)

What is the risk of fixing it? (Risk)
Low. We have good test coverage for all areas. The only likely impact is on IIOP FOLB.
Other functions of the ORB are unaffected by these changes.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
I don't think a reasonable workaround exists.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
N/A

How long has the bug existed in the product?
Since the beginning of GF 3.1 FOLB development (roughly 6 months)

Do regression tests exist for this issue?
Yes: IIOP FOLB dev test test15736.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The various tests that were failing that caused this issue to be filed (Gopal has the tests).

When will a tested fix be ready for integration?
Probably 1/31/11-2/1/11.

Comment by gopaljorapur [ 31/Jan/11 ]

he issue in 15637 is about IIOP Loadbalancing not happening , Scenario is as follows (I will update the issue with this scenario)

1. Start Cluster with 5 instances
2. Create 12 InitialContext in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see 12 of them in only one instance (incorrect behavior, load should be loadbalanced across cluster)

The test code is as follows

/// When we run appclient, we provide test id as RMIIIOPFOTC4, this creates 12 ic and 12 sfsb remote ref

if(testid.equals("RMIIIOPFOTC4"))
{
for(int i=0;i<12;i++)

{ client.createContextForACC(); client.createSFSBRemoteRef(); }

System.out.println("Test Passed");
}

//// Here is how ic is created

public void createContextForACC()
{
try

{ Context initial = new InitialContext(); myEnv = (Context)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

///// Here is how sfsb remote ref is
public void createSFSBRemoteRef()
{
try

{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }
catch(Exception exc)
{ exc.printStackTrace(); }
}




*******************************************************************************************************************************************************

The scenario that works:

The variation of the test, RMIIOPFOTC4A

1. Start Cluster with 5 instances
2. Create 12 InitialContext with endpoint properties in the argument in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see load distributed across all instances in the cluster (correct behavior)

Test code is as follows


/// When we run appclient, we provide test id as RMIIIOPFOTC4A, this creates 12 ic and 12 sfsb remote ref
if(testid.equals("RMIIIOPFOTC4A"))
{
for(int i=0;i<12;i++)
{ client.createContextForStandalone(); client.createSFSBRemoteRef(); }
System.out.println("Test Passed");
}

//// This is how createContextForStandalone

public void createContextForStandalone()
{
try
{ myEnv = new InitialContext(properties); }
catch(Exception exc)
{ System.err.println("Caught an unexpected exception!"); exc.printStackTrace(); }
}



///// This is how createSFSBRemoteRef is done ( its same as scenario when test fails)

public void createSFSBRemoteRef()
{
try
{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }

catch(Exception exc)

{ exc.printStackTrace(); }

}

Here is how to deploy
asadmin --user admin deploy --retrieve /export/DecCVS/agentrepo//appclient --availabilityenabled=true --target st-cluster --force=true RMIIIOPFailover.ear

appclient execution
/export/DecCVS/glassfish3/glassfish/bin/appclient -Dcom.sun.appserv.iiop.endpoints=hat2k1.us.oracle.com:23700,hat2k1.us.oracle.com:23701,hat2k2.us.oracle.com:23700,hat2k2.us.oracle.com:23701,hat2k2.us.oracle.com:23702 -client /export/DecCVS/agentrepo/appclient/RMIIIOPFailoverClient/rmi-iiop-client2Client.jar -mainclass samples.rmiiiopclient.client.ACC_Standalone_Client

Comment by Chris Kasso [ 31/Jan/11 ]

Approved for RC2.

Comment by Ken Cavanaugh [ 31/Jan/11 ]

At this point, for tracking purposes, 15637 is for the scenario I outlined above:

0. Start with com.sun.appserv.iiop.endpoints referring to two elements, the one to start in step 2
and another in the cluster.
1. Stop the cluster.
2. Start 1 instance (inst) in the cluster.
3. LB to one instance
4. Start cluster
5. Kill inst
6. LB test (which should show LB across running instances)

It's TOO LATE to change the test scenario for 15637, especially since you did not include a sufficient
description initially. I have clearly identified some defects here that need to be fixed,
so please file a NEW issue for the scenarios you have identified above. Please also indicate in any
new issues whether or not stateful vs. stateless EJBs make any difference. This does not matter
to the ORB at all, but some of your tests seem to indicate failures on the SFSB side only.
If this matters, I'll also need to add SFSB support to the dev tests.

Comment by gopaljorapur [ 31/Jan/11 ]

I have opened an issue 15768 for the Loadbalancing issue mentioned in my earlier comment

Comment by Ken Cavanaugh [ 31/Jan/11 ]

Fixed in GF rev 44807.
This includes integration of ORB version 3.1.0-b025.

Comment by gopaljorapur [ 17/Feb/11 ]

With old styled apps, this issue is not fixed

Comment by Ken Cavanaugh [ 17/Feb/11 ]

I was certain I fixed this, but I'll test it again, and target it for
3.2.





[GLASSFISH-16481] Dynamically-assigned IP addresses for cloud instances require changes to app client bootstrapping for remote RMI-IIOP access Created: 27/Apr/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb, rmi_iiop_failover, rmi_iiop_load_balancer
Affects Version/s: 4.0
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

GF 3.2 will support clouds with both statically and dynamically (DHCP) assigned IP addresses. This has
an impact on supporting app clients that access EJBs remotely and to IIOP FOLB.

First, a couple of points about the ORB:

  • The ORB normally caches and re-uses TCP/IP connections aggressively, and holds TCP connections open for a long time.
  • Stateful EJBs have their current state on a single instance, and for efficiency we normally want each request to go to the same instance.
    o When a failure occurs, IIOP failover causes all EJBs that were accessed from the failed instance to failover to the same instance ("Sticky failover").

Typically a cloud-based cluster will have a load balancer at a well-known address for handling HTTP traffic.
The instances in the cloud may or may not be accessible over the public internet (if not, the load balancer sits
in some kind of DMZ so at least an address on the LB is publicly accessible). We have the following possible scenarios:

1. Only the LB is publicly accessible.
2. LB and instances are publicly accessible, static cluster.
3. LB and instances are publicly accessible, dynamic cluster.

Case 1 is discussed in RFE 16480.

Case 2 is probably no different than supporting IIOP FOLB in GF 3.1, so it needs no further discussion.

Case 3 is interesting, because it creates a bootstrapping problem. Currently IIOP FOLB assumes that there are
at least 2 fixed addresses of instances in the cluster which can be used to bootstrap into full FOLB operation.
This is not the case for the dynamic cluster, where an app client may find that all of the instance addresses have
been re-assigned every time it attempt to contact the cluster. The only available fixed, known address in this case
is that of the load balancer (which itself may will use DNS tricks to make more than one IP address available, both
for load balancing and high availability). So IIOP FOLB must make use of the LB address in this case.

While perhaps a suitable LB might be persuaded to support some sort of request that gives the client ORB the
information that it needs, I think Tim's suggestion of a small web listener is a better idea. Here something
in each GF 3.2 instance is listing to a URL like

http(s)://host:8080/__ORBS

which would respond to a GET request with a list of instance addresses in the cluster (and perhaps other information?).
This might be formatted using JSON for convenient processing.

It's not clear whether security is required here. If it is, it would add significant complexity and require integration with
the Java SE security facilities for managing a password or certificate.

I'm not sure how best to implement this in GF; I'm sure someone familiar with the web programming side of things could
point out how to implement this rather easily.

These issues are also summarized at the Dynamic IP address concerns page.






[GLASSFISH-16480] App client using RMI-IIOP needs to work in cloud without public IP addresses Created: 27/Apr/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb, rmi_iiop_failover, rmi_iiop_load_balancer
Affects Version/s: 4.0
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

GF 3.2 will support clouds with both statically and dynamically (DHCP) assigned IP addresses. This has
an impact on supporting app clients that access EJBs remotely and to IIOP FOLB.

First, a couple of points about the ORB:

  • The ORB normally caches and re-uses TCP/IP connections aggressively, and holds TCP connections open for a long time.
  • Stateful EJBs have their current state on a single instance, and for efficiency we normally want each request to go to the same instance.
    o When a failure occurs, IIOP failover causes all EJBs that were accessed from the failed instance to failover to the same instance ("Sticky failover").

Typically a cloud-based cluster will have a load balancer at a well-known address for handling HTTP traffic.
The instances in the cloud may or may not be accessible over the public internet (if not, the load balancer sits
in some kind of DMZ so at least an address on the LB is publicly accessible). We have the following possible scenarios:

1. Only the LB is publicly accessible.
2. LB and instances are publicly accessible, static cluster.
3. LB and instances are publicly accessible, dynamic cluster.

In case 1, we have no choice but to direct IIOP traffic to the LB, assuming that the LB allows this.
If the application only uses stateless EJBs, we just run the ORB in a no-connection cache/connection per request mode
(we delivered this feature for NTT west around 5 years ago in GF 2.1.1). This allows the LB to make load balancing
decisions based on just a new TCP connection, and works reasonably well.

If the application requires stateful EJBs in case 1, we currently have no solution. I think a solution would require that the
LB somehow be aware of a sort of session affinity, where each request would be load balanced to the instance currently
containing the session for the EJB instance. A request that establishes a new session (currently that is the request
that a new InitialContext call sends) could be load balanced to any instance in the cluster. This would be very
similar to how the current IIOP LB mechanism works.

If the LB does not support IIOP, it would probably be necessary to use some sort of HTTP tunneling of IIOP requests.
This has been done many times in many products over the years (including in the circa 1995 Sun JOE ORB, probably the
first Java ORB written), but we have never supported it in the JDK/SJSAS/GF ORBs (which started in 1997). There is no
standard for tunneling IIOP over HTTP, but we could invent something proprietary to solve the problem if necessary.

Case 2 is probably no different than supporting IIOP FOLB in GF 3.1, so it needs no further discussion.

Case 3 creates a bootstrapping issue considered in another RFE.

These issues are also summarized at the Dynamic IP address concerns page.






[GLASSFISH-16323] Fix FOLB related FindBugs issues in GlassFish repository Created: 06/Apr/11  Updated: 02/Jun/11

Status: In Progress
Project: glassfish
Component/s: rmi_iiop_failover, rmi_iiop_load_balancer
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ken Cavanaugh Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There are a number of FindBugs issues in code related to IIOP FOLB that need to be fixed:

kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:490: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:273: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:253: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:421: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.RoundRobinPolicy.getAddressPortList(List) is never called
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:132: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.RoundRobinPolicy.infoLog(String, Object[]) is never called
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialContext.java:238: NP_NULL_ON_SOME_PATH: Possible null pointer dereference of ? in new com.sun.enterprise.naming.impl.SerialContext(String, Hashtable, Habitat)
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialInitContextFactory.java:292: DLS_DEAD_LOCAL_STORE: Dead store to provider in com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(Hashtable)
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialInitContextFactory.java:283: ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD: Write to static field com.sun.enterprise.naming.impl.SerialInitContextFactory.giso from instance method com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(Hashtable)
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialInitContextFactory.java:271: ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD: Write to static field com.sun.enterprise.naming.impl.SerialInitContextFactory.rrPolicy from instance method com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(Hashtable)
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/TransientContext.java:744: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.TransientContext.print(Map) is never called

kcavanaugh: ejb/ejb-container/src/main/java/com/sun/ejb/EJBUtils.java:508: DLS_DEAD_LOCAL_STORE: Dead store to generatedRemoteIntf in com.sun.ejb.EJBUtils.loadGeneratedRemoteBusinessClasses(ClassLoader, String)
kcavanaugh: ejb/ejb-container/src/main/java/com/sun/ejb/EJBUtils.java:520: DLS_DEAD_LOCAL_STORE: Dead store to generatedRemoteWrapper in com.sun.ejb.EJBUtils.loadGeneratedRemoteBusinessClasses(ClassLoader, String)

kcavanaugh: orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/PEORBConfigurator.java:153: ITA_INEFFICIENT_TO_ARRAY: Method org.glassfish.enterprise.iiop.impl.PEORBConfigurator.configure(DataCollector, ORB) uses Collection.toArray() with zero-length array argument
kcavanaugh: orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/POAProtocolMgr.java:302: BC_UNCONFIRMED_CAST: Unchecked/unconfirmed cast from java.rmi.Remote to org.omg.CORBA.Object in org.glassfish.enterprise.iiop.impl.POAProtocolMgr.isIdentical(Remote, Remote)
kcavanaugh: orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/POAProtocolMgr.java:303: BC_UNCONFIRMED_CAST: Unchecked/unconfirmed cast from java.rmi.Remote to org.omg.CORBA.Object in org.glassfish.enterprise.iiop.impl.POAProtocolMgr.isIdentical(Remote, Remote)
kcavanaugh: orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/POARemoteReferenceFactory.java:543: BC_UNCONFIRMED_CAST: Unchecked/unconfirmed cast from org.omg.PortableServer.Servant to javax.rmi.CORBA.Tie in org.glassfish.enterprise.iiop.impl.POARemoteReferenceFactory.postinvoke(byte[], POA, String, Object, Servant)

kcavanaugh: orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:79: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time
kcavanaugh: orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:123: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time
kcavanaugh: orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:134: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time
kcavanaugh: orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:142: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time

kcavanaugh: security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/IIOPSSLUtilImpl.java:157: BC_UNCONFIRMED_CAST: Unchecked/unconfirmed cast from org.omg.PortableInterceptor.IORInfo to com.sun.corba.ee.spi.legacy.interceptor.IORInfoExt in com.sun.enterprise.iiop.security.IIOPSSLUtilImpl.createSSLTaggedComponent(IORInfo, Object)



 Comments   
Comment by Harshad Vilekar [ 20/May/11 ]

Updated:
trunk/v3/orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java

Fixed following issues:
#orb-connector-1 orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:79:
IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time

#orb-connector-2 orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:123:
IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time

#orb-connector-3 orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:134:
IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time

#orb-connector-4 orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/api/GlassFishORBHelper.java:142:
IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.enterprise.iiop.api.GlassFishORBHelper.protocolManager; locked 57% of time
-----------------------

Updated trunk/v3/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/PEORBConfigurator.java
Fixed following issue:
#orb-iiop-1 orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/PEORBConfigurator.java:153:
ITA_INEFFICIENT_TO_ARRAY: Method org.glassfish.enterprise.iiop.impl.PEORBConfigurator.configure(DataCollector,
ORB) uses Collection.toArray() with zero-length array argument
-----------------------

Comment by Harshad Vilekar [ 02/Jun/11 ]

Updated:
common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java

Fixed Following Issues:

1.1 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:490: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time

1.2 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:273: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time

1.3 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:253: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of com.sun.enterprise.naming.impl.RoundRobinPolicy.resolvedEndpoints; locked 66% of time

2 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:421: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.RoundRobinPolicy.getAddressPortList(List) is never called

3 common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java:132: UPM_UNCALLED_PRIVATE_METHOD: Private method com.sun.enterprise.naming.impl.RoundRobinPolicy.infoLog(String, Object[]) is never called

Test Status:

  • Default build tests: PASS
  • web-ql, full-ql and ejb dev tests: PASS




[GLASSFISH-21333] Error when set jvm-options "-Dcom.sun.appserv.iiop.endpoints=host1:port1,host2:port2" in jvm cluster settings Created: 18/Mar/15  Updated: 18/Mar/15

Status: Open
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: malaury Assignee: russellgold
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Centos 6.5 64bits



 Description   

I have an frontend and backend application communicate whith remote EJB.
When I set jvm-options "-Dcom.sun.appserv.iiop.endpoints=host1:port1,host2:port2" in jvm frontend cluster settings and I start it I obtain this error :

java.lang.IllegalStateException: Service org.glassfish.gms.bootstrap.GMSAdapterService was started at level 1 but it has a run level of 10.

In the class : com.sun.enterprise.naming.impl.SerialInitContextFactory#getInitialContext, the boolean useLB is set to true. Then the com.sun.enterprise.naming.impl.SerialInitContextFactory#getORB method is call.
In the method org.glassfish.enterprise.iiop.impl.GlassFishORBManager#setFOLBProperties it created a new IiopFolbGmsClient( services ). In this class there is a call to gmsAdapterService = services.getService(GMSAdapterService.class);. A this line cannot create the GMSAdapterService because it start with runlevel 10.

Maybe I don't understand how to set the IIOP loadbalancing ?






[GLASSFISH-16715] per-request-loadbalancing does not seem to work anywhere Created: 24/May/11  Updated: 26/Aug/12

Status: Open
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: JFK9 Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008 SP2
Java build 1.6.0_25-b06 / 1.6.0_24 (client )
Oracle GlassFish Server 3.1 (build 43)


Attachments: XML File domain.xml     File Experiment5-DomA.ear     Java Archive File Experiment5-tests.jar     File Experiment5-WebTierEAR.ear    

 Description   

I have followed
http://download.oracle.com/docs/cd/E18930_01/html/821-2426/index.html
and
http://download.oracle.com/docs/cd/E18930_01/html/821-2418/beakv.html

I have deployed the EJBs with per-request-load-balancing set to true in the glassfish-ejb-jar.xml
The ejb-container is enabled for high-availability..
asadmin> get cluster1-config.availability-service.*
cluster1-config.availability-service.jms-availability.availability-enabled=false
cluster1-config.availability-service.jms-availability.config-store-type=masterbroker
cluster1-config.availability-service.jms-availability.message-store-type=file
cluster1-config.availability-service.ejb-container-availability.availability-enabled=true
cluster1-config.availability-service.ejb-container-availability.sfsb-ha-persistence-type=replicated
cluster1-config.availability-service.ejb-container-availability.sfsb-persistence-type=file
cluster1-config.availability-service.ejb-container-availability.sfsb-store-pool-name=jdbc/hastore
cluster1-config.availability-service.web-container-availability.availability-enabled=true
cluster1-config.availability-service.web-container-availability.persistence-frequency=web-method
cluster1-config.availability-service.web-container-availability.persistence-scope=session
cluster1-config.availability-service.web-container-availability.persistence-store-health-check-enabled=false
cluster1-config.availability-service.web-container-availability.persistence-type=replicated
cluster1-config.availability-service.web-container-availability.sso-failover-enabled=false
cluster1-config.availability-service.auto-manage-ha-store=false
cluster1-config.availability-service.availability-enabled=true
cluster1-config.availability-service.ha-store-healthcheck-enabled=false
cluster1-config.availability-service.ha-store-healthcheck-interval-in-seconds=5
Command get executed successfully.

I have deployed the EARS with availability enabled ...
deploy --availabilityenabled=true --target cluster1 C:/Users/Administrator/Desktop/Experiment5-WebTierEAR.ear

I have run the client tests in the ACC outside of any IDE.

The simple test consists in a method call to an EJB which returns information about the invocation including the instances it hit when running. The only time I see the client change server instance is when
1) I get a new InitialContext
2) I stop the instance that is being used
My cluster consists on 3 instances running on 2 nodes with a separate box for the DAS and DB.

Please find attached
1) The two EARs ( including sources ) Experiment5-WebTierEAR and Experiment5-DomA which consitute the server app ( including the ACC client app Experiment5-WebTierACC)
2) A set of stand-alone tests ( Experiment5-tests ) which I have run inside Eclipse against the cluster .. Experiment5-tests
3) the config.xml of my DAS



 Comments   
Comment by ztangm [ 26/Aug/12 ]

My feeling is also that it does not work. I would be very interested in a resolution.





Generated at Fri Dec 09 07:54:26 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.