The community forums are in BETA and closed to the public.

Java api - thousands of threads waiting - architecture feedback?

Hi all,

I have a Java and JavaScript integration with PubNub in a JavaEE environment. I'm having an issue where I have thousands of threads that are all waiting at the same place and I'm wondering if I'm not doing something correctly or have an architecture that isn't correct.

On the subscriber side, I have a singleton that listens for messages on a single channel. This singleton subscribes to the channel on startup and remains in existence for the life of the application - days or weeks usually. I am getting messages correctly from both the Java and JavaScript side.

On the publisher side, in Java I create a new Pubnub object when needed and publish. Because this is an EE environment and this is in a Stateless EJB this object may get reused as needed by the container. I do nothing on destruction of the bean. On the JavaScript side I just publish from the JavaScript API.

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.

My message source is probably 50/50 or so between Java and JavaScript. The subscriber doesn't care where the messages were sent from.

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.

Any thoughts?

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.


Comments to this discussion are now closed!