Skip to main content

Getting OBJ_NOT_EXIST when doing NamingContextHelper.narrow() to Name Service if java.net.connectiontimeout is set?

  • February 16, 2013
  • 0 replies
  • 0 views

Problem

  • Product Name: Visibroker Java
  • Product Version: 4.5.1
  • Product Component: Naming Service
  • Platform/OS Version: All
  • JDK/Compiler Version: JDK 1.3.1

The NamingContextHelper.narrow() failed with OBJ_NOT_EXIST when the java.net.connectiontimeout system property is set in the java runtime environment.

Resolution

A detailed examination of the system calls and JVM source code (for JDK 1.3.1) shows that there is a Sun bug in the JVM logic.

The JVM logic has it:
- if the java.net.connectiontimeout setting is set, it becomes the preferredTimeout.
- the preferredTimeout is passed to the native call PlainSocketImpl.c"s connect() call.
- the connect() call check that if this condition is met:

if (preferredTimeout > 0 and the errorno != InProgress),
then close the socket and return

Sun Bug Id: 4514190 ConnectionException is thrown even when connection is successful
This was reported against JDK 1.2.2 and 1.3.x. Unfortunately, Sun did not release any patch, and there is no work-around. This problem, however, is solved in JDK 1.4.x.

The problem is found when testing on both a local instance of name service vs. a remote instance of name service is that:

- for the local instance of Visibroker Name Service, creating a socket returns successfully with a value of 0, no errorno of "InProgrress" is detected. So if the Visibroker Name Service runs on a local machine as the client, the client failed to establish the socket to the Name Service (to be exact, it did establish a socket successfully, but because of the hole in the JVM logic, that socket got closed immediately.)


- for the remote instance of Visibroker Name Service, creating the socket causes an errorno of "InProgress", and thus the client was able to successfully communicate with the Name Service. This can potentially be a work-around. However, why exactly the errorno is returned when talking to a remote name service is not for certain, and there is no guarantee that on a different system the errorno will still be returned.

Since the exact detailed difference between a local vs. a remote Name Service is not known, one can not ascertain that using a remote Name Service will always be a valid work-around.

To demonstrate that this is a JVM bug, one can use a simple Java client and server that creates tcp sockets to talk to each other. There is no Visibroker components involved. And one can see that as soon as the client uses the java.net.connectiontimeout= setting, the client fails to connect to the server. The sample code is posted at the end of this article.

A similar reporting on the Java Bug Database has also been found:

So it seems that the only via option to resolve this issue is to try one or both of the follows:
- follow Sun"s advice, quoted from the Bug Database
"It"s important to note that java.net.connecttimeout is an undocumented property for 1.2.2/1.3.x only and was created only for customers escalating the issue. The right solution is to programmatically specifies the timeout with the new API support in merlin."


- run a remote instance of the Name Service

- run the Name Service in JDK 1.4.x. However, please remember that VBJ 4.5.1 is not supported on JDK 1.4.x.

Old KB# 26418


#Security
#VisiBroker
#ConnectionException
#4514190
#NameService