search

EsotericSoftware / kryonet

TCP/UDP client/server library for Java, based on Kryo
BSD 3-Clause "New" or "Revised" License
1.82k stars 419 forks source link

ExecutorService thread still running after client.close() #103

Closed Aperico-com closed 9 years ago

Aperico-com commented 9 years ago

I have a game server manager that spawns and closes servers on demand. Each server has one kryonet Server and also one kryonet Client (for communication with a data server). When I use server.stop() it works fine and all threads are disposed of, but when I do client.stop() I still have one running thread. In JavaMonitor I can see the thread as a "pool-1-thread-1" which is locked on sun.misc.unsafe.park(). I think it is the ThreadedListener class in kryonet that is causing this? Since it is using an ExecutorService? Is there any way I can get rid of these lingering threads? I would really need to since servers that I spawn are not up for more than 5 minutes a piece and eventually there are quite a few locked threads..

NathanSweet commented 9 years ago

You can provide ThreadedListener your own ExecutorService.

Aperico-com commented 9 years ago

Ok, I will try that. Thank you! Is there any reason to why you would wan't those threads to linger after Client.close()?

NathanSweet commented 9 years ago

Probably not. Someone needs to manage the thread pool's lifecycle though, which is application specific. If we used Executors.newCachedThreadPool() then the threads would die, but more than 1 thread could be created which could result in processing messages out of order. It's best to specify your own Executor.

On Tue, Jul 28, 2015 at 10:57 PM, Aperico-com notifications@github.com wrote:

Ok, I will try that. Thank you! Is there any reason to why you would wan't those threads to linger after Client.close()?

— Reply to this email directly or view it on GitHub https://github.com/EsotericSoftware/kryonet/issues/103#issuecomment-125752106 .