0

I have made test WebService which starts Thread, which writes to file timestamp every 10 second. I intentionally don't have Thread stop mehanism. Now, if I stop test WebService, and even delete it, the Thread live in Jboss forever (needs JBoss restart). Is this normal that JBoss isn't aware of Threads made within WebService context ?

Within JVM, when app shuts down, all threads are killed, but here is JVM owned by Jboss, which dynamically loads classes.

Is this a "feature" or bug ?

I am asking this, cause we have 3rd party application doing threading, and I noticed they're not shutted down on WebService destructor, so after re-publish, we have an issue.

Marvin
  • 598
  • 5
  • 14

2 Answers2

0

Cleaning up resources used by a WebService, is the responsibility of the WebService itself.

Tomcat will help you by logging warnings when a WebService is not doing this properly (e.g. when the MySQL JDBC driver is leaving a thread hanging) and it will even try to clean ThreadLocals for you (see also comments in this utility class).

In your case, since you are using the 3rd party application in a WebService, you are responsible for cleaning up resources used by the 3rd party application when your WebService is unplugged. It would be nice if JBoss could at least report "resource leakage" like Tomcat does, but that would be a feature and not a bug.

Community
  • 1
  • 1
vanOekel
  • 6,358
  • 1
  • 21
  • 56
0

I have made test WebService which starts Thread, which writes to file timestamp every 10 second. I intentionally don't have Thread stop mehanism. Now, if I stop test WebService, and even delete it, the Thread live in Jboss forever (needs JBoss restart). Is this normal that JBoss isn't aware of Threads made within WebService context ?

You aren't supposed to launch your own threads, so JBoss won't clean your stuff up for you.

See also why spawning threads in Java EE is discouraged (mostly applies to Enterprise Java Beans) or "Java EE specification and multi threading".

If the 3rd party application does its own threading and you can't change it, then it might not be a good fit for an application server. An old trick to graft an old application into Java EE is to manage its lifecycle using a ServletContextListener, which has an init and destroy method.

If you can change it though, check the Concurrency Utils API example from the question / answer I linked to above, using an ExecutorService is the modern way to manage threads so that the server is aware of your handywork.

Community
  • 1
  • 1
JBert
  • 3,311
  • 24
  • 37
  • Yeah, as I assumed. It could have mehanism to registering thread within the JBoss somehow though. – Marvin Jan 28 '14 at 18:13
  • @Marvin You [certainly can](https://community.jboss.org/wiki/ThreadPoolConfiguration) and I highly recommend it: if you stop/start your own threads, funky stuff will happen. I've successfully managed threads in JBoss 5.1 (for a custom service) using JBoss' threadpools. Without the use of JBoss' threadpool, it would not function properly. – vanOekel Jan 28 '14 at 19:33
  • Mine WS are working as they should with own old fashion threading managment, as within jvm (after all, jboss is just "another" java application :) But since its not new software, and the logic is that threads always live withing the webservice context, they should think about it also. It's ok with me, that they write, its your own how you will handle, but to tell users to avoid threads, that means that their webservices are to be "hello world" alike :P – Marvin Jan 28 '14 at 23:14
  • @Marvin: I don't get your point about "tell users to avoid threads". Did you mean "other programmers on my team making webservices"? – JBert Jan 29 '14 at 14:11
  • I've read about it on some JBoss page, that making own threads in webservice is discouraging. It shouldn't been as far as you have control over them (start/stop) – Marvin Jan 29 '14 at 16:09