Problems with tnameserv.exe in J2SDK 1.4.2_05
Jan Persson
We recently upgraded our system from JDK 1.3.1 to 1.4.2_05 and now we are
experiencing strange problems in the CORBA layer connected to tnameserv.exe.
If I start a blank tnameserv.exe and run the following test program
(which basicly only connects to the naming service and then quits, in a loop)
it will only be able to do this 240 times. This means that our application
can only accept about 240 incoming connections before it crashes.
However, if I run the same code against a tnameserv.exe from JDK 1.3.1
it seems to be able to run forever.
Is this a known issue? Does anyone have a workaround?
Best Regards
//Jan Persson (Bitmine AB, Sweden)
---- code ahead ------------------------------------------------------------
import org.omg.CORBA.ORB;
import org.omg.CORBA.ORBPackage.InvalidName;
import org.omg.CosNaming.NamingContext;
import org.omg.CosNaming.NamingContextHelper;
public class TestNamingService
{
public static void main(String[] args)
{
int i=0;
for(;;i++)
{
connect();
System.out.println(i);
}
}
private static void connect()
{
System.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");
System.setProperty("org.omg.CORBA.ORBInitialPort", "900");
ORB orb = ORB.init(new String[] {}, null);
// get the root naming context
org.omg.CORBA.Object objRef = null;
try
{
objRef = orb.resolve_initial_references("NameService");
}
catch (InvalidName e)
{
e.printStackTrace();
}
NamingContext ncRef = NamingContextHelper.narrow(objRef);
}
}
Rob Ratcliff
client code and the server code were both using up to 250 or so threads.
Even with orbd (rather than tnamserv), your original program caused
orbd to fail sometimes with 240, 575 and 1225 calls with:
e:\sources>orbd -ORBInitialPort 900 -ORBInitialHost myhost
com.sun.corba.se.internal.iiop.IIOPConnection$DeleteConn
at
com.sun.corba.se.internal.iiop.IIOPConnection.delete(IIOPConnection.java:602)
at
com.sun.corba.se.internal.iiop.IIOPConnection.writeLock(IIOPConnection.java:576)
at
com.sun.corba.se.internal.iiop.IIOPConnection.purge_calls(IIOPConnection.java:404)
at
com.sun.corba.se.internal.iiop.ReaderThread.run(ReaderThread.java:119)
It looks like it's a thread limitation with the Java CORBA library. (It
stopped at 240 connections on Windows and Solaris so I'm thinking that
this limit must hardcoded somewhere and is not system dependent.)
Perhaps the ThreadPool has max workers set to 240?
(com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl.java is the
ThreadPool class.)
It'd be interesting to try this test case with Jacorb instead. Jacorb
is much more feature-complete and robust.
I also tried out orbd in jdk 1.5 and unfortunately got an error after
240 connections as well:
Aug 20, 2004 1:52:43 AM
com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl close
WARNING: ORBUTIL.connectionRebind
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 209 completed: No
at
com.sun.corba.se.impl.logging.ORBUtilSystemException.connectionRebind(ORBUtilSystemExcept
ion.java:1936)
at
com.sun.corba.se.impl.logging.ORBUtilSystemException.connectionRebind(ORBUtilSystemExcept
ion.java:1958)
at
com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.close(SocketOrChannelConnec
tionImpl.java:609)
at
com.sun.corba.se.impl.transport.CorbaConnectionCacheBase.reclaim(CorbaConnectionCacheBase
.java:166)
at
com.sun.corba.se.impl.transport.SocketOrChannelAcceptorImpl.accept(SocketOrChannelAccepto
rImpl.java:263)
at
com.sun.corba.se.impl.transport.SocketOrChannelAcceptorImpl.doWork(SocketOrChannelAccepto
rImpl.java:414)
at
com.sun.corba.se.impl.transport.EventHandlerBase.handleEvent(EventHandlerBase.java:99)
at
com.sun.corba.se.impl.transport.SelectorImpl.run(SelectorImpl.java:282)
Aug 20, 2004 1:52:43 AM
com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl close
or this error:
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 209 completed: No
at
com.sun.corba.se.impl.logging.ORBUtilSystemException.connectionRebind(ORBUtilSystemExcept
ion.java:1936)
at
com.sun.corba.se.impl.logging.ORBUtilSystemException.connectionRebind(ORBUtilSystemExcept
ion.java:1958)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorI
mpl.java:797)
at
com.sun.corba.se.impl.protocol.giopmsgheaders.MessageBase.callback(MessageBase.java:807)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediato
rImpl.java:665)
at
com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelCon
nectionImpl.java:375)
at
com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConne
ctionImpl.java:950)
at
com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.j
ava:394)
BTW, I modified your program to only initialize the ORB one time and it
worked as you'd expect.
import org.omg.CORBA.ORB;
import org.omg.CORBA.ORBPackage.InvalidName;
import org.omg.CosNaming.NamingContext;
import org.omg.CosNaming.NamingContextHelper;
public class TestNamingService {
public static void main(String[] args) {
System.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");
System.setProperty("org.omg.CORBA.ORBInitialPort", "900");
ORB orb = ORB.init(new String[] {}, null);
int i=0;
for(;;i++) {
connect(orb);
System.out.println(i);
}
}
private static void connect(ORB orb) {
// get the root naming context
org.omg.CORBA.Object objRef = null;
try {
objRef = orb.resolve_initial_references("NameService");
} catch (InvalidName e) {
e.printStackTrace();
}
}
Also, I believe orbd is the preferred naming service now (even though
it seems to have the same problem as tnameserv.)
(See http://java.sun.com/developer/technicalArticles/releases/corba/
http://java.sun.com/j2se/1.4.2/docs/guide/idl/orbd.html )
I'd be interested in hearing if you come up with a solution.
Rob
Jan Persson
Thanks for taking your time to help me.
Rob Ratcliff <rrr...@futuretek.com> wrote in message news:<63iVc.1793$v86...@fe2.texas.rr.com>...
> It looks like it's a thread limitation with the Java CORBA library. (It
> stopped at 240 connections on Windows and Solaris so I'm thinking that
> this limit must hardcoded somewhere and is not system dependent.)
> Perhaps the ThreadPool has max workers set to 240?
> (com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl.java is the
> ThreadPool class.)
I have reported this on SUN's bug parade, but still there is no response
from them.
>
> BTW, I modified your program to only initialize the ORB one time and it
> worked as you'd expect.
Yes, it might work, but then it would no longer resemble our
production environment where we have several hundred clients connecting
to our server at the same time.
> Also, I believe orbd is the preferred naming service now (even though
> it seems to have the same problem as tnameserv.)
> (See http://java.sun.com/developer/technicalArticles/releases/corba/
> http://java.sun.com/j2se/1.4.2/docs/guide/idl/orbd.html )
Yes orbd, does also fail and it is quite interesting to note, that
after the failure, it is not even possible to connect to it with servertool
anymore. It has crashed completly.
> I'd be interested in hearing if you come up with a solution.
Yes, I actually have a temporary solution running in production right now.
After not being able to fix this on my own (and being under great stress
from my client) I decided to look for alternatives to tnameserv. Finally
when I was just about to give up that approach, I downloaded IBM's JDK
1.4.2 for Windows and tried out their tnameserv.exe and it actually worked.
So right now our system is using SUN JDK for the middleware and IBM's
tnameserv.exe as the naming service.
I am by no means a CORBA expert (hence my questions), but as I have understood
it the CORBA implementation shipped by SUN is just a reference implementation
and not meant for production environments. Am I right? If that is the case
I might have to switch to another ORB. Maybe Jacorb would be a good choice then?
Best Regards
//Jan Persson
Rob Ratcliff
>Hi,
>
>Thanks for taking your time to help me.
>
>
Glad to help. It's interesting behavior! :- )
>>BTW, I modified your program to only initialize the ORB one time and it
>>worked as you'd expect.
>>
>>
>
>Yes, it might work, but then it would no longer resemble our
>production environment where we have several hundred clients connecting
>to our server at the same time.
>
>
I just wanted to verify that it was a multiple connection thing and not
a multiple request thing.
> Yes, I actually have a temporary solution running in production right now.
>
>After not being able to fix this on my own (and being under great stress
>from my client) I decided to look for alternatives to tnameserv. Finally
>when I was just about to give up that approach, I downloaded IBM's JDK
>1.4.2 for Windows and tried out their tnameserv.exe and it actually worked.
>
>So right now our system is using SUN JDK for the middleware and IBM's
>tnameserv.exe as the naming service.
>
>
>
How many connections did IBM's JDK support? Just for the heck of it, I
tried out Jacorb on Windows 2000. It seemed to limit the simultaneous
connections to1000. (There was a 1000 threads running in the client and
the server, 2000 total. I haven't tried it on Solaris yet.) I also tried
out Mico's nameserver (single-threaded) and it seemed to limit the
simulataneous connections to 60 for some reason.
>I am by no means a CORBA expert (hence my questions), but as I have understood
>it the CORBA implementation shipped by SUN is just a reference implementation
>and not meant for production environments. Am I right? If that is the case
>I might have to switch to another ORB. Maybe Jacorb would be a good choice then?
>
>
Jacorb is much more configurable than the JDK's ORB and also supports
other cool features such as bidirectional GIOP and security. OpenOrb
looks like another viable alternative. I've heard a lot of complaints
about the JDK's ORB.
Let us know how everything comes out.
Rob