search

xinbc / jdiameter

Automatically exported from code.google.com/p/jdiameter
0 stars 0 forks source link

Number of threads keeps on increasing during stack start and stop #62

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Configure diameter client. Leave the server offline.
2. Start client with method StackImpl.start(Mode mode, long timeOut,
TimeUnit timeUnit)
3. The stack is in state CONFIGURED.
4. Call StackImpl.stop(). Nothing happens.
5. If you do that in a loop, the thread (FSM peer) count goes up and never 
comes down.

What is the expected output? What do you see instead?
After stop()the allocated thread pool is still active and is
not released. If the server is started all the stopped and destroyed client 
threads connects to the server.

What version of the product are you using? On what operating system?
jdiameter-1.5.10
Linux

Original issue reported on code.google.com by mail2gop...@gmail.com on 3 Jul 2014 at 12:40

GoogleCodeExporter commented 9 years ago 
Thanks for reporting this.

I have made some tests and I do not observe the same behavior. Could you please 
provide more information ? When stopping a peer it does not mean the FSM 
threads will be destroyed, but I don't see them increasing either.

It would be good if you could replicate your problem in a testcase, you may use 
https://code.google.com/p/jdiameter/source/browse/testsuite/tests/src/test/java/
org/mobicents/diameter/stack/StackConnectTest.java as base for it.

Original comment by brainslog on 5 Jul 2014 at 1:44

GoogleCodeExporter commented 9 years ago 
  Thanks for the quick reply.

  If we are doing stack start and stop in a loop, getting number of FSM threads keeps on increasing which causes Out of Memory Error. Have used almost the same kind of standalone code which you have mentioned in the previous post.

  Attached the snapshot of the ThreadCount for the corresponding process id.

Original comment by mail2gop...@gmail.com on 7 Jul 2014 at 2:30

Attachments:

GoogleCodeExporter commented 9 years ago 
Sorry but I just don't see the same behavior so I'm guessing we really are 
trying different situations. If you can, please provide the code which 
generated the thread count growth (just remove anything that is private or 
unneeded).

It may be a difference with JVM implementation.. in the issue you mentioned 
Linux, but it seems it's happening on Windows, as well?

Original comment by brainslog on 8 Jul 2014 at 1:45