Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33254 > unrolled thread

multithread client socket

Back to article view | Back to comp.lang.java.programmer

Contents

  multithread client socket Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2015-12-01 09:36 -0800
    Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-01 11:58 -0800
      Re: multithread client socket Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2015-12-01 23:02 -0800
        Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-02 06:39 -0800
    Re: multithread client socket Jan Burse <janburse@fastmail.fm> - 2015-12-01 22:01 +0100
      Re: multithread client socket Jan Burse <janburse@fastmail.fm> - 2015-12-01 22:06 +0100
        Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-01 13:55 -0800
      Re: multithread client socket Martin Gregorie <martin@address-in-sig.invalid> - 2015-12-01 22:04 +0000
        Re: multithread client socket Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2015-12-01 23:04 -0800
          Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-02 05:52 -0800
          Re: multithread client socket Martin Gregorie <martin@address-in-sig.invalid> - 2015-12-02 14:38 +0000
    Re: multithread client socket Arne Vajhøj <arne@vajhoej.dk> - 2015-12-05 20:00 -0500

#33254 — multithread client socket

Hello,

I'm using a cached thread pool which gets a lot of callable objects. Each callable create with "new Socket" a client socket to a server, sends data to the server, receive the response and returns the response with a future object. The server closes the socket after the response is send.

On large datasets the runtime cannot create new socket objects (socket already in use message). The Java client runs explicit socket.close without any error. My idea is, that each thread of the thread-pool holds a member with the socket, but I need must reconnect the client socket on each task, because the server closes the socket.

My question is, how can I use a lot of client sockets which can be closed by the server, but without re instantiation on Java side. On a socket.connect I get "socket is closed" after the server has closed it.

Thanks

Phil

[toc] | [next] | [standalone]

#33258

On Tuesday, December 1, 2015 at 12:37:00 PM UTC-5, Philipp Kraus wrote:
> Hello,
> 
> I'm using a cached thread pool which gets a lot of callable objects. Each callable create with "new Socket" a client socket to a server, sends data to the server, receive the response and returns the response with a future object. The server closes the socket after the response is send.
> 
> On large datasets the runtime cannot create new socket objects (socket already in use message). The Java client runs explicit socket.close without any error. My idea is, that each thread of the thread-pool holds a member with the socket, but I need must reconnect the client socket on each task, because the server closes the socket.
> 
> My question is, how can I use a lot of client sockets which can be closed by the server, but without re instantiation on Java side. On a socket.connect I get "socket is closed" after the server has closed it.
> 
> Thanks
> 
> Phil

Do you have some sample code?

How are you getting to the socket in use error?

I wrote a socket server class which connects to any number of clients.  In my testing the clients got 3 types of errors on creating the Socket object: ConnectException if the server was not running, UnknownHostException if they pass an invalid host name, or IOException for a general connection issue.

For each client-server session my client creates a new Socket instance and my server starts a new Socket (passed to it from ServerSocket.accept()) on a new Thread.  My server sits on an endless loop of starting new Threads every time it gets a value from that accept() method.  Whenever the client or server closes the socket, the other receives an IOException if it attempts to access the socket again which tells it to also close the socket.  When my server closes the socket it ends the thread, so if that client reconnects it gets a new socket with a new thread.  I haven't had to worry about limits to number of open sockets or active threads, so if you find a limit let us know, and you'll have to set up a queue as Martin mentioned.

[toc] | [prev] | [next] | [standalone]

#33264

Am Dienstag, 1. Dezember 2015 20:59:07 UTC+1 schrieb Eric Douglas:
> Do you have some sample code?

Yes sure:

The task building process for my thread-pool: 
https://github.com/JIM-DB/Java-Client/blob/master/src/main/java/jimdb/Connection.java#L120

The connection call (ITask implements Callable):
https://github.com/JIM-DB/Java-Client/blob/master/src/main/java/jimdb/CInsertTask.java#L53

and the socket-opening
https://github.com/JIM-DB/Java-Client/blob/master/src/main/java/jimdb/CLink.java#L64

> How are you getting to the socket in use error?

The structure works at the moment, but if I have got a lot of tasks I reach a limit to create new sockets

> I haven't had to worry about limits to number of open sockets or active threads, so if you find a limit let us know, and you'll have to set up a queue as Martin mentioned.

I use a queue but the queue can store some 100k items, so I seems to be, that I reach the limit.

[toc] | [prev] | [next] | [standalone]

#33268

On Wednesday, December 2, 2015 at 2:02:48 AM UTC-5, Philipp Kraus wrote:
> The structure works at the moment, but if I have got a lot of tasks I reach a limit to create new sockets
> 
> > I haven't had to worry about limits to number of open sockets or active threads, so if you find a limit let us know, and you'll have to set up a queue as Martin mentioned.
> 
> I use a queue but the queue can store some 100k items, so I seems to be, that I reach the limit.

I don't know that there is a limit to number of sockets, but the number of concurrent sockets would at least be limited by your hardware.  I just ran a test running a local socket server connecting infinite socket clients.  It stopped around 9,897 clients and my CPU was maxed, so check your allocated resources and make sure your concurrent processes are set to a reasonable limit.

[toc] | [prev] | [next] | [standalone]

#33259

Philipp Kraus schrieb:
> On large datasets the runtime cannot create new
 > socket objects (socket already in use message).
 > The Java client runs explicit socket.close
 > without any error. My idea is, that each thread
 > of the thread-pool holds a member with the socket,
 > but I need must reconnect the client socket on
 > each task, because the server closes the socket.

Its not necessarely the server that closes the socket.
Check your exception handling and socket parameters,
such as time out settings. See also:
http://docs.oracle.com/javase/7/docs/api/java/net/SocketTimeoutException.html

[toc] | [prev] | [next] | [standalone]

#33260

Jan Burse schrieb:
> Philipp Kraus schrieb:
>> On large datasets the runtime cannot create new
>  > socket objects (socket already in use message).
>  > The Java client runs explicit socket.close
>  > without any error. My idea is, that each thread
>  > of the thread-pool holds a member with the socket,
>  > but I need must reconnect the client socket on
>  > each task, because the server closes the socket.
>
> Its not necessarely the server that closes the socket.
> Check your exception handling and socket parameters,
> such as time out settings. See also:
> http://docs.oracle.com/javase/7/docs/api/java/net/SocketTimeoutException.html

Also check your network infrastructure, I am
hearing a lot of stories from collegues where
firewalls etc.. impose additional constraints
and kick out connections.

Maybe switch to out of the box solutions, such
as Http connection, which might have additional
features which are not so easy to implement from
scratch.

Also out of the box solutions might have a
different idea on how conversations between
client and server function.

For example in a Http connection the session
cookie is responsible for tying together multiple
requests and responses and not the socket version.

Bye

[toc] | [prev] | [next] | [standalone]

#33261

On Tuesday, December 1, 2015 at 4:06:22 PM UTC-5, Jan Burse wrote:
> For example in a Http connection the session
> cookie is responsible for tying together multiple
> requests and responses and not the socket version.
> 
> Bye

Java has a server class and a client class for an easy socket connection.  There's a client class for Http connection, is there an easy server setup or do you have to run a separate web service?

[toc] | [prev] | [next] | [standalone]

#33262

On Tue, 01 Dec 2015 22:01:39 +0100, Jan Burse wrote:

> Philipp Kraus schrieb:
>> On large datasets the runtime cannot create new
>  > socket objects (socket already in use message). The Java client runs
>  > explicit socket.close without any error. My idea is, that each thread
>  > of the thread-pool holds a member with the socket,
>  > but I need must reconnect the client socket on each task, because the
>  > server closes the socket.
> 
> Its not necessarely the server that closes the socket.
>
Maybe so, but as Eric describes, given the way that POSIX socket handling 
works, the obvious way to write a server is to use this logic:

   Open a ServerSocket and listen for connections
   while (stillRunning)
   {
      Socket skt = ServerSocket.accept();
      while(stillConnected)
      {
         if (sktIsClosedByClient)
         {
            stillConnected = false;
            skt.close();
         }
         else
         { 
            read request from skt
            process the request
            write response to skt
         }
      }
   }

and it doesn't much matter whether the server is single or multi-threaded 
Java. Same goes for a server written in C, using poll() or select() and 
asynchronous i/o.
 
The only oddity I see is that Philip's server, which he seems to be 
saying already exists and is working so its behavior is a given, should 
close the socket after sending a response. 

The convention, in all the cases I've seen, is that the client is 
responsible for opening a session with the server and for closing it when 
the interaction is complete. This is good practise because it makes 
exception reporting easier (if the server closes the session it has a 
problem) and if a client can issue several requests its much more 
efficient to leave the session open until they've all been dealt with 
rather than starting a new session for each request.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33265

I don't use a server socket, it is only a client socket

Phil

Am Dienstag, 1. Dezember 2015 23:06:51 UTC+1 schrieb Martin Gregorie:
> On Tue, 01 Dec 2015 22:01:39 +0100, Jan Burse wrote:
> 
> > Philipp Kraus schrieb:
> >> On large datasets the runtime cannot create new
> >  > socket objects (socket already in use message). The Java client runs
> >  > explicit socket.close without any error. My idea is, that each thread
> >  > of the thread-pool holds a member with the socket,
> >  > but I need must reconnect the client socket on each task, because the
> >  > server closes the socket.
> > 
> > Its not necessarely the server that closes the socket.
> >
> Maybe so, but as Eric describes, given the way that POSIX socket handling 
> works, the obvious way to write a server is to use this logic:
> 
>    Open a ServerSocket and listen for connections
>    while (stillRunning)
>    {
>       Socket skt = ServerSocket.accept();
>       while(stillConnected)
>       {
>          if (sktIsClosedByClient)
>          {
>             stillConnected = false;
>             skt.close();
>          }
>          else
>          { 
>             read request from skt
>             process the request
>             write response to skt
>          }
>       }
>    }
> 
> and it doesn't much matter whether the server is single or multi-threaded 
> Java. Same goes for a server written in C, using poll() or select() and 
> asynchronous i/o.
>  
> The only oddity I see is that Philip's server, which he seems to be 
> saying already exists and is working so its behavior is a given, should 
> close the socket after sending a response. 
> 
> The convention, in all the cases I've seen, is that the client is 
> responsible for opening a session with the server and for closing it when 
> the interaction is complete. This is good practise because it makes 
> exception reporting easier (if the server closes the session it has a 
> problem) and if a client can issue several requests its much more 
> efficient to leave the session open until they've all been dealt with 
> rather than starting a new session for each request.
>  
> 
> -- 
> martin@   | Martin Gregorie
> gregorie. | Essex, UK
> org       |

[toc] | [prev] | [next] | [standalone]

#33267

On Wednesday, December 2, 2015 at 2:04:24 AM UTC-5, Philipp Kraus wrote:
> I don't use a server socket, it is only a client socket

Of course there is a server socket process though I don't see one in that github folder.  If you're not writing your own server process you're connecting to one someone else wrote.  Your new Socket() call will throw a ConnectException if you don't have a socket listener running on the specified host/port.  Of course it's unrelated to the error but client sockets cannot exist without server sockets.

[toc] | [prev] | [next] | [standalone]

#33269

On Tue, 01 Dec 2015 23:04:11 -0800, Philipp Kraus wrote:

> I don't use a server socket, it is only a client socket
>
I should hope not! 

Server sockets are server's tool for being notified about incoming 
connections. Used by me as an illustration of how typical server logic 
works and why its a bad idea for a server to close connections opened by 
the client.

When you open a Socket you pass it the address and port number of the 
server's ServerSocket. This accepts the connection and immediately spawns 
a Socket instance which gets passed to the server code that reads and 
responds to the client's request(s). Meanwhile the ServerSocket goes on 
listening for more incoming requests.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33311

On 12/1/2015 12:36 PM, Philipp Kraus wrote:
> I'm using a cached thread pool which gets a lot of callable objects.
> Each callable create with "new Socket" a client socket to a server,
> sends data to the server, receive the response and returns the
> response with a future object. The server closes the socket after the
> response is send.
>
> On large datasets the runtime cannot create new socket objects
> (socket already in use message). The Java client runs explicit
> socket.close without any error. My idea is, that each thread of the
> thread-pool holds a member with the socket, but I need must reconnect
> the client socket on each task, because the server closes the
> socket.
>
> My question is, how can I use a lot of client sockets which can be
> closed by the server, but without re instantiation on Java side. On a
> socket.connect I get "socket is closed" after the server has closed
> it.

Are you by any chance running your Java application on Windows?

I have had lots of problem with opening and closing a large number
of sockets on Windows.

It seems like:
* Windows keep the outbound port open for a short time after
   application close
* Windows has a rather strict limit on the number of outbound
   ports

The best approach would be avoid opening and closing
sockets all the time time and keep the sockets open
permanently and just put them in a pool for reuse.

That may not be possible due to the way the servers
works, but it should be considered.

The more hackish workaround is to bump MaxUserPort.

https://msdn.microsoft.com/en-us/library/aa560610%28v=bts.20%29.aspx

http://smallvoid.com/article/winnt-tcpip-max-limit.html

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web