Tuesday Nov 06, 2007

The GlassFish-CORBA project has been re-created

I have just finished having the GlassFish-CORBA project destroyed and re-created using subversion for source code management. I did this to facilitate automatic synchronization between the svn content at glassfish-corba and the actual source code, which is stored in mercurial at a different server. Please note that the svn contents includes only the docs, which are in the www directory in the mercurial repository. The svn contents also includes the ORB SPI javadocs, which are generated in the mercurial repository.

This change has unfortunately meant that ALL email subscriptions, project memberships, and issues were lost. Most of the glassfish-corba issues are at in the glassfish issues, so we only lost 2 issues (both fixed: see the new orb_notes document for a better writeup of the current state of the project).

If you are interested in CORBA in GlassFish, please add yourself to the appropriate email lists in the glassfish-corba project.  I have added all of the previous project members back into the project, but I cannot add people into email lists.
 

Tuesday Oct 23, 2007

More on TCP Timeouts in CORBA

I previously blogged here about how we configure TCP timeouts in the GlassFish ORB.  Scott Oaks recently discovered some cases where the default configuration needs to be changed. He also pointed out that the blog entry was missing some details about exactly HOW to set the appropriate TCP timeouts.

My previous blog entry referred to several properties that are defined in the class com.sun.corba.ee.impl.orbutil.ORBConstants.  In particular:

  • TRANSPORT_TCP_TIMEOUTS_PROPERTY is com.sun.corba.ee.transport.ORBTCPTimeouts
  • TRANSPORT_TCP_CONNECT_TIMEOUTS_PROPERTY is com.sun.corba.ee.transport.ORBTCPConnectTimeouts
  • WAIT_FOR_RESPONSE_TIMEOUT is com.sun.corba.ee.transport.ORBWaitForResponseTimeout

Any of these can be set by the appropriate -D command: e.g. -Dcom.sun.corba.ee.transport.ORBTCPTimeouts=500:30000:20.

 This is particularly important when running with a very busy app server on a large machine (like a T2000). It may happen that the default 6 second timeout is exceeded while waiting for more data to be read on a large request.  In this case, you may see errors logged like:

 

java.rmi.MarshalException: CORBA >COMM_FAILURE 1398079696 Maybe; nested
exception is: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe

 or

java.rmi.MarshalException: CORBA MARSHAL 1398079699 >Maybe; nested exception is
org.omg.CORBA.MARSHAL: vmcid: SUN minor code: 211 completed: Maybe

Errors that have completion status maybe cannot be retried, because the client ORB cannot assume they have not already executed on the server side. 

In this case, the ORBTCPTimeouts needs to be increased, say to something like 500:30000:20. This means:

  • The first timeout is .5 seconds
  • Each subsequent retry increases the timeout by 20%
  • The maximum time we will wait is 30 seconds (actually, due to some implementation details, the maximum is closer to double the configured value, or 60 seconds in this case).
We will probably increase the default in a future release, or possibly make it adapt to the observed load.


About

kcavanaugh

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today