![]() ![]() I've read all those same explanations, and I truly appreciate the effort. ![]() It's another reason not to hold onto connections for too long, though, since the more you do with a connection, the easier it is to lose track of where it ends up. Knowing where the connection was allocated often helps track down what happened to it afterwards. If the timer expires, this exception's stack is then printed out, which indicates what the calling path from the application to the pool manager was when the connection was allocated. Instead it stores it next to the connection id along with a timeout timer. So by forbidding servlets to spawn threads you avoid those problems.Ī servlet's init() method doesn't run under a pooled thread, so it can spawn children and in the past we sometimes did, but there are better places these days.Īs far as detecting orphan connections, what happens is that the pool manager constructs an Exception as part of the connection allocation process, but doesn't throw it. Either of which means poor performance and/or unpredictable results. Contrariwise, if you hold off returning from the service() method until all child threads have terminated, you're starving other users because while waiting, your thread cannot be returned to the pool. Since all assets in a pool should be interchangeable, but the thread you've been using has lint hanging off of it, the state of the thread being handed to the next requester is polluted. If you don't terminate that child thread before you return from service(), then you've just handed a "dirty" thread to the pool. Now consider what happens if you spawn a child thread during a service() method call. Returning from the service() method results in the execution thread being returned to the thread pool for re-use.Īs with database connections, there are only a limited number of Threads in the service thread pool, so a servlet should do its job and return as soon as possible so that the thread can be returned to the pool and used for some other incoming Request - which may or may not be from the same user. It pulls a free thread from the pool, uses that thread to call the servlet's service() method, and at that point user application code runs until it returns from the service() method (which may in turn have called doGet(), doPost() or whatever. The webapp server has a pool of execution threads. ![]() When an HTTP(S) request comes in to a JEE webapp server, the server digests it and decodes the URL to determine which servlet within which webapp the request should call. Instead they're collections of servlets (including JSPs, which compile to become servlets) and the servlets are code, not executable threads. ![]() They don't consist of a main task (thread) that sits around and runs. The J2EE and JEE specifications explicitly forbid that servlets or EJBs should spawn threads. So it makes me think that it's getting confused about something else, and reporting this erroneously? When I go check these out, the code is very obviously doing the right thing. And it even gives you the class and line number. At times, I've seen in the logs during/after a crash that it claimed a certain connection was not returned to the pool. But if you're spawning off a thread to simply fire off an email to someone without holding up the page response to them - is there really any harm in that?Ģ) What's the best way to detect connection leaks? I have removeAbandonedOnBorrow="true", removeAbandonedTimeout="60", and logAbandoned="true" set up in the connection pool. It's all too easy to get into race conditions, etc. I've had some conversations with some Java developers, and also read in some places that it's actually fine, as long as you are careful and understand what you're doing. But I've never read a convincing argument of *why*. Hi Tim - all very good advice, and among the the things I've read while trying to figure this out.ġ) Spawning threads from servlets - I've read a lot about this, and although a lot (most) of the voices out there assert the same thing: that you're not supposed to spawn your own (native Java) threads from a servlet. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |