[GLASSFISH-20648] EJB client frozen when ORBTCPConnectTimeouts is specified Created: 20/Jun/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.1.1

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

Windows 7


TCP timeout value can be specified by the property ORBTCPConnectTimeouts.
The format of this property is com.sun.corba.ee.transport.ORBTCPConnectTimeouts=initial:max:backoff:maxsingle.
For example, this can be specified by -D option of java command or VMARGS for appclient command.
When the same value is specified for the "initial" and "max", the client program is frozen.

To reproduce the problem,
1. Create a Hello World EJB sample program.
2. When running the EJB client program, specify the ORBTCPConnectTimeouts option and invalid server name where EJB is not running.
C:\>set VMARGS=-Dcom.sun.corba.ee.transport.ORBTCPConnectTimeouts=100:100:100:1000
C:\>appclient -Dcom.sun.appserv.iiop.endpoints=invalidhost:3700 ejb30.SlessJavaClient

3. EJB client does not timeout.(It stalls and no response.)

I have created a sample program to reproduce the issue.
To use the program,
1. Edit the build.xml. Change the glassfish installation path in Line7.
2. Execute "ant build" to compile. Then, "ant deploy" to deploy
3. Execute "ant appclient". The program tries to connect to an invalid server and show exception. Then, exits and back to prompt. (This is expected. Not bug.)
4. Execute "ant appclient_bug" -Dcom.sun.corba.ee.transport.ORBTCPConnectTimeouts=100:100:100:1000 is specified in this case. The program does not timeout and stalls.

(For step 3 and 4, you can alternatively use "ant javaclient" and "ant javaclient_bug" to reproduce the bug.)

This is from the Glassfish source code.
It seems this part is causing the problem.

TcpTimeoutsImpl.java original
public boolean isExpired() {
	return total_time > max_time_to_wait ;

Changing >= in isExpried() solves the problem. See below for the suggestion.

TcpTimeoutsImpl.java suggested
public boolean isExpired() {
	return total_time >= max_time_to_wait ;

Comment by tak09 [ 20/Jun/13 ]

I have uploaded the sample program.

Please download OTBTCPConnectTimeouts.zip

Comment by Harshad Vilekar [ 21/Jun/13 ]

This will be fixed in the next GF release. ORB 4.0 workspace revision #930.

Generated at Fri Oct 21 13:07:53 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.