This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Un-kill Thread keeping adding

 
Jeansonne Pierre
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all, i have no experience in Threading. It took me few days to figure out why but still failed.
Problem Statement :
I have two simple java class as below and deployed to server as a .war file in tomcat. but after i remove the .war file, seems like the Thread is still running in the background.
i have no idea why even after i remove my .war file, the Thread is still running. Whenever i redeploy my .war file, then the Thread will keep adding and adding.
what code should i add in to make sure the Thread will be killed when i remove my .war file?







Below are the Tomcat Log that i can see when i remove my .war file. and seems like the Thread is not being killed.

 
L Foster
Ranch Hand
Posts: 185
10
Android Java Netbeans IDE
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Jeansonne,

What you may wish to do is review the URL below.  It has the description of that method.

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html

You should be aware that when you call that, you are creating an executor, with a single thread.  The executor is expecting some workloads to be pushed into it (your yodlee runnables).  Although I am not familiar with the use of BVServices (???), it looks like you are calling a RESTful service and that RESTful service is then starting this singleton thread pool.  Is that correct?

That being the case, you may wish to add some kind of termination strategy.  Assuming it is good practice to start a thread pool inside the server (I may be out of the loop on this one--it is not considered good practice for EJB servers, but you have a Servlet runner, here), you could add another method to call the shutdown method.  In that case, you might need a singleton holding a statically-defined reference to the returned object.

Further, one parameter for these factory methods is a thread factory.
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadFactory.html
You may be able to specify a thread that is a "Daemon" thread.  It may allow Tomcat to kill the threads from the thread pool.

That being said, I would not try and make this happen, if there was an alternative defined by the technology.  I would try and find out if your chosen RESTful technology does support asynchronous processing.  Jersey has a documented mechanism for doing this, as below.  Unfortunately, it requires the client to await the return (it just makes the server processing faster).

https://jersey.java.net/documentation/latest/async.html

Of course, if you are using some other RESTful implementation (such as RESTEasy), you will need to find out how or if that works.

I just recently implemented a RESTful service that does very heavy (several hours) of processing.  I do not want my client waiting on that.  When I run this, it is submitted via JMS to an MDB.  There's your muti-threading, and there is the asynchronous aspect.  I am not saying that is necessarily what you need, but it may help.
 
Jeansonne Pierre
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Foster,

Thanks for the guidance. appreciate it so much. actually my goal is to make sure the "cobSession" got refreshed within a fixed period continueosly. But the problem come when i redeploy my .war file, the previous thread still running together with the newly instantiated thread. the more i redeploy, the more numbers of thread running until my server crashed.
what i need is just a single thread. hmmm. i have no idea how to achieve that. please help. i know something to do with service.shutdown(). but the problem how can i link it with war file removal? means when war file remove, then kill the running thread.
 
Jeansonne Pierre
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,

does something like this solve the issue? But how can i check when the war file removed, the thread must be killed as well?

 
L Foster
Ranch Hand
Posts: 185
10
Android Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, Jeannesonne,

Please consider whether it is a good idea to refresh that "cobSession".  It may be the code is trying to tell you something.  Maybe it is not meant (not a good idea) to keep this session alive so long.

Be that as it may, what you want when synchronizing with war undeploy, is a listener.  Here is something from the servlet documentation.  What you want to listen to are lifecycle events.

http://docs.oracle.com/cd/B14099_19/web.1012/b14017/filters.htm#i1000654

I think you may also wish to read up a lot on the technologies you are using, here.  If your code is well-written, it is going to gain something from the APIs, rather than fighting with them.  Your continual refreshing should not be necessary--if I were doing the task, I'd be asking myself:
1. is this timing out because it is really not that heavy, and hence it would not be wasteful to just get a new session?
2. is this timing out rather, because this resource is VERY heavy to maintain, and hence, I might want to better leave this to the server (using API at wrong level)?
3. am I fooling myself about just how heavy this application really is, and should I wade in and go for those bigger technologies that had put me off earlier?

I hope it helps! 
 
L Foster
Ranch Hand
Posts: 185
10
Android Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sigh!

Sorry, upon re-reading, I realize it would time out because you *told* it to.  D'oh!  So I should have phrased my answer differently.  Instead you should ask yourself why you are fighting with getting rid of the threads in the first place.

If you decide to continue with the thread pool, the lifecycle listeners will work, as long as they can find that thread pool to shut it down.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic