views:

280

answers:

6

Hi; We have an application which creates many sockets which belongs to its thread, By design if this application somehow fails, all threads stop which is not wanted. So to overcome this issue, each thread must be separated from the main application, if one of the threads fails, the other ones should be running. One thing in our mind is to pass created socket to another java process, so what is the correct way?

An other approach also is welcome?

Waiting for your suggestions...

+2  A: 

It isn't. (Sockets can't be serialized.)

When one thread fails, its exception should be caught, logged, and this should not interfere with other threads. So either design it to stop completely, or design it to not stop completely.

Or pass all the information about the socket (address/port) to another application, which itself could open a similar socket.

Bozho
@Bozho - So you mean that sockets are locked to its process, there is no such thing in the world?
whoi
+2  A: 

see this similar question socket passing between processes.
Unfortunately the barrier of the address space can not be exceeded.

lsalamon
+3  A: 

Forking:

You can't pass a socket handle between Java processes using the normal API as far as I can tell. However, it does seem to be possible on windows using the Winsock 2 API. On Posix you should be able to fork a child process with access to the parent socket, since forked processes inherit the parent's sockets.

You could, I think, implement a new SocketImpl class which supports moving a socket handle to another process, but you'd need to write some JNI code to do it.

Sounds pretty hairy to me, I doubt forking a new process from within Java is a good idea!

Listeners:

Another approach might be to spawn a new 'listener' process which is essentially a new pre-forked worker. Each worker could then take turns to listen to the socket for connections. The workers would then need to coordinate with a control process which manages spawning new processes as needed.

I agree with @Bozho, if an error in one thread can take them all down (I guess it would have to be a JVM exception killing the whole app) you have a bigger problem. You should look at isolating the threads if possible.

Mike Houston
+1  A: 

I rather agree with Bozho you need to redesign your applications / critic threads so that an Exception or an Error does kill your whole VM.

To help you with that I suggest you to have a look to :

  • Thread.set**Default**UncaughtExceptionHandler(...) and Thread.setUncaughtExceptionHandler(...) (see hyperlink below) which helps to fetch unforseen problems (such as runtimes)
  • Runtime.addShutdownHook(...) (see hyperlink below) which helps closing things nicely (for example when an OutOfMemoryError occurs)

Regards

Cerber

http: //java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler) http: //java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)

Cerber
A: 

Use a class that is shared between threads to hold sockets. You can use a HashMap to label each socket so other threads can reference the one it needs.

javydreamercsw
Usually I use a Class that implements the singleton patter to do this kind of things.
javydreamercsw
I meant pattern^
javydreamercsw
A: 

If u make a socket as static then u can pass that object to any process

Deepak
May I know the reason of negative rating
Deepak