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

Groups > comp.lang.java.programmer > #33255 > 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 Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-12-01 10:12 -0800
    Re: multithread client socket Martin Gregorie <martin@address-in-sig.invalid> - 2015-12-01 19:38 +0000
      Re: multithread client socket Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2015-12-01 22:56 -0800
        Re: multithread client socket Martin Gregorie <martin@address-in-sig.invalid> - 2015-12-02 14:57 +0000
          Re: multithread client socket Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-02 10:54 -0500
            Re: multithread client socket Martin Gregorie <martin@address-in-sig.invalid> - 2015-12-02 19:18 +0000
            Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-02 11:47 -0800
              Re: multithread client socket Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-02 15:30 -0500
                Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-02 12:57 -0800

#33255 — 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]

#33256

On 12/1/2015 09:36, Philipp Kraus wrote:
> Hello,

> 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.

Once they are closed they can't be reopened, so either you have to make 
new ones or not close them.


-- 

Knute Johnson

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

#33257

On Tue, 01 Dec 2015 09:36:58 -0800, 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.
>
Have any server transactions finished before you get the error?

If the answer is 'No', then limit the size of the thread pool to prevent 
the error and use a Queue to store pending requests that are waiting for 
a thread to come available because this shows that requests are arriving 
faster than the server can handle them.

From what you say, it sounds as though each thread can close its socket 
once it gets the disconnection and then re-open after it gets a new 
request to process.

How many threads does the server use to handle these requests? It may be 
a bit pointless for your client to have more requests outstanding than 
the server can handle at once. Make your thread pool size configurable so 
you can tune your client for maximum speed without swamping the server 
with requests and/or impacting the performance of other parts of the 
application system.

There may be a limit on the number of sockets a Java process can have 
open: if so this will set an upper limit to the size of your thread pool. 
Is such a limit documented anywhere? Can it be changed?


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

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

#33263

Am Dienstag, 1. Dezember 2015 20:41:11 UTC+1 schrieb Martin Gregorie:

> Have any server transactions finished before you get the error?
> 
> If the answer is 'No', then limit the size of the thread pool to prevent 
> the error and use a Queue to store pending requests that are waiting for 
> a thread to come available because this shows that requests are arriving 
> faster than the server can handle them.

Yes all transaction are finished correctly. 
 
> From what you say, it sounds as though each thread can close its socket 
> once it gets the disconnection and then re-open after it gets a new 
> request to process.

I create a queue with all requested task and run invoke on the thread pool.
Each task opens the socket, sends the data, waits (socket is still open) until it gets the request result and closes the socket.


> There may be a limit on the number of sockets a Java process can have 
> open: if so this will set an upper limit to the size of your thread pool. 
> Is such a limit documented anywhere? Can it be changed?

I reach this limit at the moment, but I don't find any information to do it better / resize this limit or change my architecture

Thanks

Phil

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

#33270

On Tue, 01 Dec 2015 22:56:32 -0800, Philipp Kraus wrote:

> Am Dienstag, 1. Dezember 2015 20:41:11 UTC+1 schrieb Martin Gregorie:
> 
>> Have any server transactions finished before you get the error?
>> 
>> If the answer is 'No', then limit the size of the thread pool to
>> prevent the error and use a Queue to store pending requests that are
>> waiting for a thread to come available because this shows that requests
>> are arriving faster than the server can handle them.
> 
> Yes all transaction are finished correctly.
>
Even when you hit the limit and your client falls over?

You should able see how many Sockets are open when the client falls over 
by using a static volatile int that:

- is incremented each time a thread successfully opens a client socket

- is decremented each time a thread successfully closes a client socket

- gets its value written to stderr by the exception code triggered by 
  a client socket failing to open or close.
 
The effect on your code should be minimal since you'll already be 
catching IOExceptions thrown by Sockets.


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

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

#33272

On 12/2/2015 9:57 AM, Martin Gregorie wrote:
> [...]
> You should able see how many Sockets are open when the client falls over
> by using a static volatile int that:
>
> - is incremented each time a thread successfully opens a client socket
>
> - is decremented each time a thread successfully closes a client socket
>
> - gets its value written to stderr by the exception code triggered by
>    a client socket failing to open or close.

     Use an AtomicInteger, not a volatile int.  The latter is not
thread-safe (unless guarded by other synchronization, or unless it's
read by many threads but modified by only one).

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#33273

On Wed, 02 Dec 2015 10:54:33 -0500, Eric Sosman wrote:

> On 12/2/2015 9:57 AM, Martin Gregorie wrote:
>> [...]
>> You should able see how many Sockets are open when the client falls
>> over by using a static volatile int that:
>>
>> - is incremented each time a thread successfully opens a client socket
>>
>> - is decremented each time a thread successfully closes a client socket
>>
>> - gets its value written to stderr by the exception code triggered by
>>    a client socket failing to open or close.
> 
>      Use an AtomicInteger, not a volatile int.  The latter is not
> thread-safe (unless guarded by other synchronization, or unless it's
> read by many threads but modified by only one).

Point.


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

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

#33274

On Wednesday, December 2, 2015 at 10:55:04 AM UTC-5, Eric Sosman wrote:
>      Use an AtomicInteger, not a volatile int.  The latter is not
> thread-safe (unless guarded by other synchronization, or unless it's
> read by many threads but modified by only one).

but thread-recklessness is such fun, eh?  I just wrote a test program today that crashed with a ConcurrentModificationException.

I've actually never used the keyword volatile or an AtomicInteger.
A standard int seems to work fine to track the number of clients as long as it's a single server object doing all the tracking.

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

#33275

On 12/2/2015 2:47 PM, Eric Douglas wrote:
> On Wednesday, December 2, 2015 at 10:55:04 AM UTC-5, Eric Sosman wrote:
>>       Use an AtomicInteger, not a volatile int.  The latter is not
>> thread-safe (unless guarded by other synchronization, or unless it's
>> read by many threads but modified by only one).
>
> but thread-recklessness is such fun, eh?  I just wrote a test program today that crashed with a ConcurrentModificationException.
>
> I've actually never used the keyword volatile or an AtomicInteger.
> A standard int seems to work fine to track the number of clients as long as it's a single server object doing all the tracking.

     If there's only one thread that looks at or modifies the counter,
a plain int is fine.

     If there are multiple threads looking at the counter but only one
modifying it, you need a volatile int.  (Modifying the counter inside
the only thread that modifies it is safe, but you need volatile to
ensure that the modifications are "published" to other threads.)

     If there are multiple threads modifying the counter, you need some
kind of synchronization for the writes (so they don't interfere with
each other) and for the reads (so the effect of the writes are made
visible to other threads).  There are lots of ways to do this, but
perhaps the three simplest are:

     - Use a plain int, but do all the reads and writes inside a block
       (or entire method) that synchronizes on one object,

     - Use a volatile int, synchronizing around all writes and letting
       the reads just rely on volatility to make the writes visible, or

     - Use an AtomicInteger, whose own methods provide all the necessary
       synchronization and publication without further work on your part.

     "Seems to work" is just "I haven't noticed the failures yet."  If
you want code that's more trustworthy than "Keep your fingers crossed,"
you'll need a bit more care.  It's not hard -- and if you're doing
multi-threaded stuff, you Really Really Should exercise care.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#33276

On Wednesday, December 2, 2015 at 3:31:07 PM UTC-5, Eric Sosman wrote:
>      - Use a plain int, but do all the reads and writes inside a block
>        (or entire method) that synchronizes on one object,
> 
>      - Use a volatile int, synchronizing around all writes and letting
>        the reads just rely on volatility to make the writes visible, or
> 
>      - Use an AtomicInteger, whose own methods provide all the necessary
>        synchronization and publication without further work on your part.
Sounds like good info there, I'll keep it in mind.  Normally my classes don't share any non-final info across threads, aside from the basic GUI thread managing the JTable kicking off a background thread to retrieve cell values.

>      "Seems to work" is just "I haven't noticed the failures yet."  If
> you want code that's more trustworthy than "Keep your fingers crossed,"
> you'll need a bit more care.  It's not hard -- and if you're doing
> multi-threaded stuff, you Really Really Should exercise care.
Ha, yeah sometimes it's pretty hard to write the test case that will crash code.  Sometimes you just say you know your system well enough to know how the code is used will never crash, ie client-server socket program crashes if we hit 1000 clients but will only ever be used here for 1 server and 1-3 clients.

[toc] | [prev] | [standalone]

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

csiph-web