• Post Reply Bookmark Topic Watch Topic
  • New Topic

multiple sockets connection. One jammed affects all

 
Harris Tanu
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've written client/server communication code using socket.
multiple clients can connect to a server where the clients are receiving incoming stream published by the server.

This problem only happens when the server is deployed on solaris OS (not in winXP). A client can run in any OS.
-When 2 clients are connected to server (running in solaris)
-one client is freezed (in WinXP, you can mark the dos window running the client).
-after awhile the 2nd client does not receive any incoming stream.

As both client run using different socket why communication with one client affect another client in Solaris OS?

any idea?

tx
 
Joe Ess
Bartender
Posts: 9361
11
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Off the top of my head, I'd say that you are using the same thread to service all the socket connections so when one socket blocks, times out or throws an exception it affects all the connections. As for why it behaves differently on different OS's, that is strange, but there are going to be implementation and configuration differences which may account for it. Can you post a small sample of code that exhibits this behavior?
 
Harris Tanu
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm using different socket and different thread. Each client is served by a single thread(StreamingThread). But of course the call to the thread is from the mainthread.
the sThread.send() could potentially block when the client doesn't consume the stream.




StreamingThread.send(String) method consist of:


[ May 10, 2006: Message edited by: Harris Tanu ]
 
Joe Ess
Bartender
Posts: 9361
11
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's some curious code. Why synchronize on ctItr? Do you have multiple threads in that class (mainthread I presume)? Also, StreamingThread does not appear to be executing its own thread. send() is invoked directly from mainthread, so it would execute in the same thread.
Have a look at the Java Tutorial chapter on threads and see if that clears up how to use multiple threads.
 
Harris Tanu
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



yes, the send() is invoked directly from mainthread (mainthread loops through multiple StreamThread instances to send out the 'stringbuffer').

I guess, during sending part, one of the cThread.send() was blocking and the mainthread could not continue sending to other clients.

The interesting part was: Why it doesn't block on winXP?
I still try to figure out.
[ May 10, 2006: Message edited by: Harris Tanu ]
 
Tal Nathan Tal Nathan
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not related to your code but more related to why it happens in solaris and not winxp.

The one thing I can think of is how the operating systems map kernel threads to system threads.

Win XP uses the M:M model so that many threads are serviced by many kernel threads and solaris possibly uses a M:1 or a 1:1 so if you thread blocks the kernel thread then all other threads will be blocked.

I could be talking rubbish, my CS course on thread synch's was a long time ago.
 
Tal Nathan Tal Nathan
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Then again the JVM handles the threads so I prob am wrong.
 
Harris Tanu
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks for all the tips.

But I have a new idea to avoid the blocking:

When I call send,the code will not call outputstream immediately. But it will wake up another thread running inside the STreamingThread to invoke outputstream. In this case the blocking will be internal to the StreamingThread.

 
Joe Ess
Bartender
Posts: 9361
11
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's the standard way to write a server which handles more than one client. The Java Tutorial has an example in the Networking thread if you are interested in seeing another implementation.
 
Harris Tanu
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks everybody.

the problem has been solved now.
 
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
well as you have not posted the code this would be difficult to see what exactly are you doing..well I faced a similar problem while making a server in my final year at the university.The best pattern to make servers , which you expect to handle multiple clients is multithreaded approach..as soon as the client request is accepted by the server , it should swamp a independent thread to handle the request and the server's main thread should again get back to listening mode..

Thanks

Rahul B
SCJP 1.4
 
Harris Tanu
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


In the previous code, the StreamingThread.send() will immediately call outputstream. Instead of calling outuputstream directly, I move the messages into a vector to be send out by separate thread running inside the StreamingThread:





 
Harris Tanu
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
the code still requires refactoring. the send() which always returns true, doesn't make sense but it was required as part of refactoring of older code.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!