File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Tomcat and the fly likes Error in log: ...have started a TimerThread named Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Error in log: ...have started a TimerThread named" Watch "Error in log: ...have started a TimerThread named" New topic
Author

Error in log: ...have started a TimerThread named

Sch Natti
Greenhorn

Joined: Jul 07, 2010
Posts: 1
Hi,

I have a Webservice which input are two files. After processing these two files the service should return a result file. If I call the service I get the following error...

07.07.2010 18:26:26 org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
07.07.2010 18:26:27 org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
07.07.2010 18:26:29 org.apache.catalina.loader.WebappClassLoader clearReferencesStopTimerThread
SCHWERWIEGEND: A web application appears to have started a TimerThread named [Timer-0] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been forcibly cancelled.
07.07.2010 18:26:29 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SCHWERWIEGEND: A web application appears to have started a thread named [http-8080-2] but has failed to stop it. This is very likely to create a memory leak.
07.07.2010 18:26:29 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@3ab28980]) and a value of type [org.apache.xerces.parsers.SAXParser] (value [org.apache.xerces.parsers.SAXParser@7b34c5ff]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
07.07.2010 18:26:29 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1f61509b]) and a value of type [org.apache.axis2.context.MessageContext] (value [[MessageContext: logID=urn:uuid:31BD516B2713927A931278519986056]]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
07.07.2010 18:26:29 org.apache.catalina.loader.WebappClassLoader clearReferencesStopTimerThread
SCHWERWIEGEND: A web application appears to have started a TimerThread named [Timer-2] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been forcibly cancelled.
07.07.2010 18:26:29 org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080


I try to sketch the Service.

A class called SimplePartialModelService and the input are the two file as byte Array. In the createModel Method I use another
Java Class which reads a config file from the harddisk and creates a Socket on localhost:8000

The Service is available on localhost:8080 and should create a socket on localhost:8000.


SimplePartialModelWebservice {

public byte[] createModel(byte[] file1, byte[] file2) {

}

}

How can I avoid the error messages or switch of this leak detection? Regards and thanks



Roger F. Gay
Ranch Hand

Joined: Feb 16, 2007
Posts: 399
Who knows, maybe a month later, somebody will come along with an idea. I have a similar problem. I haven't personally started a thread called [HTTP-8080-1], and I doubt above started one called [HTTP-8080-2]. I don't know what this is and no clue where to look for an application error. Here's the error as reported in my catalina log:



Correlation does not prove causality.
Roger F. Gay
Ranch Hand

Joined: Feb 16, 2007
Posts: 399
Actually, maybe I do know what this is about.

I have made a URLConnection between an applet and a servlet. This, I am guessing is the mysterious [HTTP-8080-1] process.

The applet performs a doPost() via the URLConnection. The servlet waits for another process to provide input before responding to the request. When I close the webpage, it's always while the applet - servlet is in the middle of a request. Also, the other process connects to an object invoked by the servlet via a simple socket, so that's open and bound.

I haven't figured out how to ensure that it all shuts down .....
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

servlet requests should be processed as fast as possible. There are only a limited number of threads in the processing pool and while the servlet is handling a GET, POST, or other HTTP request, it's using one of those threads.

Officially, the request should neither block nor spawn child threads. In reality, a certain limited amount of blocking does occur - for example, while a JDBC operation is in progress, or when a servlet makes an internal URL connection for a web service on an external server. However, if the request is expected to take a long time, it should be transferred to a non-servletrequest thread so that the request thread can be freed up.


Customer surveys are for companies who didn't pay proper attention to begin with.
Roger F. Gay
Ranch Hand

Joined: Feb 16, 2007
Posts: 399
Tim Holloway wrote:servlet requests should be processed as fast as possible. There are only a limited number of threads in the processing pool and while the servlet is handling a GET, POST, or other HTTP request, it's using one of those threads.

Officially, the request should neither block nor spawn child threads. In reality, a certain limited amount of blocking does occur - for example, while a JDBC operation is in progress, or when a servlet makes an internal URL connection for a web service on an external server. However, if the request is expected to take a long time, it should be transferred to a non-servletrequest thread so that the request thread can be freed up.


Thank you for that explanation. I only get so far with tutorials and the API doc. I'm wondering if I should get out of servlets altogether on this one, or ---- maybe it would be helpful if I got a tip on how to "transfer" to a non-servletrequest. Now wait, let me explain first.

I'm not terribly concerned about the number of servlet threads being created. My application is not intended to serve a large number of users. I'm doing push. I'm doing it by allowing systems anywhere to contact a serversocket, and then the message is passed along - using the (waiting) servlet response to push the message into the browser.

Where I'm getting into trouble is when I close the web page. It cuts off an active URLConnection and things are not being closed down properly. This is where I believe I may be getting the error above. But also, if I then bring up the web page again, without restarting the server, some real trouble begins (because things weren't closed down properly).

So far, every time I've tried to think of a way to close things down when the web page closes, my logic gets chopped off. Servlets want to persist and don't care that a connection was lost. I've most recently tried using an onbeforeunload event in the browser to send a new output message to the servlet telling it to close the other server process, and maybe there's some tiny little nit picky reason why that's not working (Firefox), but so far it's not.

It may be that the URLConnection is just too limited. What I'd really like, rather than something designed for request / response, is just a way to keep the connection open both ways ready to receive messages, and to respond in whatever way my code says to respond. Then all I'd have to do is get the onbeforeunload to work, and there ya go - except if the computer crashes of course. So, maybe I should add that it needs to be nice re: broken connections / re-connect.
Roger F. Gay
Ranch Hand

Joined: Feb 16, 2007
Posts: 399
I should add that this version is intentionally 100% Java SE. Version 2 will use Java EE, and I'm hoping the switch to JMS will deal with this. As advertised, it seems like it should, but I have no experience with JMS yet. I intend however, to continue to make a light weight Java SE system available, so if there is some way this can be handled nicely, the need will always be there.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

Do be concerned about the number of threads used. There's not that many of them. You may die after as few as 10 users sign on.

HTTP is not a protocol suited for continuous client/server style communications. HTTP requires that the client open a socket connection on the server, establish a reply port, send the request, close the server connection, await a response on the reply port, close the reply connect, and process the received data. You cannot open the connections and leave them open.

So you'd need to establish an alternative server using a non-HTTP protocol to handle this continuous-connection traffic. That server can be a completely separate stand-alone program or it can be embedded in Tomcat, either as part of the Tomcat server, or as part of a web application.

Of the 2, it's easier to code in a web application, since otherwise you have to learn a fair number of things about Tomcat's internal architecture, but conversely, you're part of an application, and not part of the server as a whole.

I normally use what I call a "null servlet" for long-term processes. A Null servlet is simply a servet that has an init() method, but no doGet/doPost methods. It's not essential that the null servlet avoid implementing doGet/doPost, but usually it's cleaner that way. The servlet is configured to start at webapp initialization time instead of on-demand.

In the init() method, you're not running under a request thread, so you can spawn threads of your own. Generally what I spawn is "engine" threads, which work with a queue of requests which are added and monitored using servlet requests. However, you can spawn a custom network server thread(s) as well.

You should also code an onDestroy method so that this thread(s) are informed when the server is shutting down so that they may clean themselves up and terminate. If you don't then Tomcat will complain and/or hang on shutdown (waiting for all threads to terminate).
Roger F. Gay
Ranch Hand

Joined: Feb 16, 2007
Posts: 399
Right now, my demonstration application is a robot simulation. It's a demo for a system that can be used for a great variety of applications, that I have scheduled to be available as open-source - with documentation and demo by the end of the month. The browser GUI is just a special add-on, and not part of the general system. That's one of the reasons I'm going to so much pain here trying to implement a simple (does that deserve an LOL?) solution. I have to get my focus back on the general system ASAP. The browser GUI part stands alone. The general system, which does not use Tomcat, has to communicate with the GUI somehow. I think the greatness of the general application - middleware roughly, might get lost if people can't see anything appear on a screen when they first try it. Simple trace comments to a command window just don't seem good enough. Besides displaying trace information (which I explain is part of a good end-to-end development system right from the start of an application dev. project), I'm driving SVG graphics that move an icon through two rooms showing the robot (sim)'s position. Not too extravagant, but it's better than command line text, I think.

There's only one single client just now. I had this working with Multicasting to the browser applet, and had less trouble with it. The limitation there was that I only had it working in a LAN, with special dealings for java security. It was sort of nice though. I can certainly imagine that it could be useful for robot stuff; if for example, it's a security robot working at a site and all the humans involved are connected to the same LAN. I had been working on using a socket connection between the application and the applet, but don't even remember how that was going before I decided to try Multicasting instead. The advantage I was looking for with URLConnection is that it can be used from anywhere. If a homeowner has a mobile robot at home and wants to check what's going on there from work (or anywhere) they can just go to the nearest PC and go to their robot website. No software downloads or installations required. But that does limit me to one user as far as I can tell. At least, I would have to do more complex coding than is planned right now to broadcast anything back (like updating the robot's position).

The doDestroy() method appears to be something that I must absolutely look into. (I actually started this a couple of years ago, and now I've probably forgotten a lot of the details that I studied to get things started - part of the woe of working as a generalist as well - else, if I specialized, I'd be sure to have those kinds of details in mind.) What other non-HTTP methods might work here?


Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

You can use HTTP for things like this. But you have to use it as a messaging type of architecture where you drop off a "turn left, move 3 meters" command and don't wait for a response. Then you periodically sent HTTP requests to check on it.

Obviously this is a lot more overhead than a straight conversational connection, but there aren't any conversational protocol ports I can think of that you can depend on making it through firewalls.

It provides an incentive for a more intelligent backend, though, since the smarter the backend is, the more the GUI can drive things by hints as opposed to brute force.

When you do this kind of stuff, you do open things up more for multi-participant control. However, if you can have multiple users taking over the robot at the same time, it can potentially get a bit schizophrenic, so one of the things you might want to include is a serialization mechanism where a user can reserve exclusive control until explicitly released by that same user or a time limit has expired. Or some sequence of commands has completed. Whatever.
Adrian Bastholm
Greenhorn

Joined: Feb 01, 2010
Posts: 9
Tim Holloway wrote:...
I normally use what I call a "null servlet" for long-term processes. A Null servlet is simply a servet that has an init() method, but no doGet/doPost methods. It's not essential that the null servlet avoid implementing doGet/doPost, but usually it's cleaner that way. The servlet is configured to start at webapp initialization time instead of on-demand.

In the init() method, you're not running under a request thread, so you can spawn threads of your own. Generally what I spawn is "engine" threads, which work with a queue of requests which are added and monitored using servlet requests. However, you can spawn a custom network server thread(s) as well.

You should also code an onDestroy method so that this thread(s) are informed when the server is shutting down so that they may clean themselves up and terminate. If you don't then Tomcat will complain and/or hang on shutdown (waiting for all threads to terminate).


What about using a servlet filter, and scheduling a TimerTask under the doFilter() method ? I get warnings from Tomcat about this (SEVERE: A web application appears to have started a TimerThread named [Timer-0] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been forcibly cancelled. )


What I'm trying to do is to schedule calls to the garbage collector, in order to try and force a compaction at midnight every day.
Adrian Bastholm
Greenhorn

Joined: Feb 01, 2010
Posts: 9
OK, dammit, that means I start a new TimerTask with every incoming connection .. haha, I'm such an idiot :P
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Error in log: ...have started a TimerThread named