What I'm seeing are thousands of threads - "Non-Subscribe-Manager" and "Subscribe-Manager" - with the same basic stacktrace:
java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at com.pubnub.api.Worker.run(Unknown Source) - locked (a java.util.Vector) at java.lang.Thread.run(Thread.java:745)
When I say thousands, a server started about 30 hours ago, has 8270 of each "type" for a total of 16k+ threads. I'm not sure exactly how many messages I've interacted with since I started the server but I can see that since April 1 I've send a bit over 84,000 messages.
I've obviously got a resource leak but I'm not sure where to go. I see an unsubscribeAll() method on the Pubnub object - perhaps I should be calling that on destruction of the publisher? Should I instead create a single publisher and not reuse it on the Java side (arguably a bit more efficient)?
I'm digging through the code but have not quite followed it enough to understand why I have so many Worker threads. I'm still digging and will be turning up the logging to help.
This is purely a publish/subscribe system. No presence or any other "extras". This is JDK 8 on a Wildfly 8.2 server under Ubuntu 14.10.
For reference, this was a bad design on my part. There was no need to create a new publisher for every event and, especially, to not do anything with it in the @PreDestroy method.
My new code creates a @Singleton as the publisher and subscriber. That means that there is one publisher and one subscriber in the entire process. It ends up with a total of 4 threads, regardless of how long the server runs.