×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Tomcat 7 Finalized

timothy posted more than 3 years ago | from the not-yet-spayed dept.

Java 103

alphadogg writes "The volunteer developers behind Apache Tomcat have released version 7.0.6 of the open-source Java servlet container. 'This is the first stable release of the Tomcat 7 branch,' developer Mark Thomas wrote in an e-mail announcing the release on various Tomcat developer mailing lists. While not a full application server, Tomcat implements the functionality described in the Java Enterprise Edition Web profile specifications. Most notably, it supports version 3.0 of the Servlet API (application programming interface) and version 2.2 of JavaServer Pages, both part of the recently ratified JEE 6. A servlet container manages Java-based applications that can be accessed from a Web browser. One big area of improvement is in configuration management for Web applications. Previous versions required all Web app configuration changes to be entered in a central file called web.xml, a process that led to unwieldy web.xml files as well as security risks."

Sorry! There are no comments related to the filter you selected.

fp (-1)

Anonymous Coward | more than 3 years ago | (#34895588)

suck my HUGE fat juicy NIGGER COCK!!!

Re:fp (-1)

Anonymous Coward | more than 3 years ago | (#34895604)

oh yeah, I'll suck it for you baby

Web.xml is the reason I hate Spring (3, Interesting)

euroq (1818100) | more than 3 years ago | (#34895608)

Large centralized files suck. At least they do when you have to deal with a real website with real, complex functionality.

Re:Web.xml is the reason I hate Spring (1)

Anonymous Coward | more than 3 years ago | (#34895652)

XML config files suck too. They managed to fail twice here.

XML devils & details (5, Insightful)

boorack (1345877) | more than 3 years ago | (#34895816)

I don't mind XML configuration file as long as it contains only things that are important and has little/no plumbing boilerplate. In most Java frameworks (especially in Spring) there are two things mixed into a single set of configuration files: items created once while developing application (for example Spring depencency injection bindings, Hibernate mappings etc. - let's call it plumbing) and factual configuration settings (for example: database URL, user and password for application). Mixing these two things is a major sin as plumbing and configuration have different characteristics.

Plumbing is like code. It is done while as part of application development and is tightly bound to development process - it should be easily testable, easy to refactor (IDEs should handle this - for example if you change name of some class/method, IDE refactoring features should also change it in all plumbing code). If possible - it should not change between development and production environments. That's why I prefer annotations rather than XML for binding everything into final application (eg. Guice over Spring). One notable exception I often is Hibernate and that's only because hibernate-annotations adds tons of additional JAR files and addidional complexity coming out of it doesn't justify convenience of using annotations instead of XML.

Configuration is a tool for administrators, not for developers. It should be as simple as possible and easy to change by hand. And yes, a generally prefer plain .properties files or YAML over XML, however as long as config file is simple enough and has no unnecessary overhead, I won't complain much about it. It is also important to keep major aspects of configuration separate (for example general server config vs. application specific config) and to keep application configuration separated from application itself (.war/.ear file).

So, in short: there are two things: "plumbing configuration" and real configuration. It is important to keep these two things separate and to keep real config as simple as possible.

Re:XML devils & details (2)

carpecerevisi (890252) | more than 3 years ago | (#34895916)

In most Java frameworks (especially in Spring) there are two things mixed into a single set of configuration files: items created once while developing application (for example Spring depencency injection bindings, Hibernate mappings etc. - let's call it plumbing) and factual configuration settings (for example: database URL, user and password for application)

So pull them out into a .properties file and use a PropertyPlaceholderConfigurer to inject them into your XML file of bindings and mappings

That's why I prefer annotations rather than XML for binding everything into final application (eg. Guice over Spring)

Except Spring has annotation-based config and it's fairly nice?

(Disclaimer, haven't actually used Guice, but do spend quite a bit of time using Spring - your comments look as though they're based on opinions and experiences from using Spring version $old?)

Re:XML devils & details (4, Informative)

Temujin_12 (832986) | more than 3 years ago | (#34897546)

GP and parent both make good points. However, GP perspective is a bit outdated. Spring < 2.0 an earlier was all (mostly) about XML config. You'd have dozens and dozens of lines of XML to do what was ultimately a fairly simple task (ie: quartz jobs or AOP).

Spring 2.0+ (especially 3.0) made two very fundamental changes in "preferred" methods for application configuration. 1) XML namespaces and 2) increased use of annotations.

1) Going back to the AOP example, what used to take around 50-80 lines of XML in Spring < 2.0 and earlier can now be done in roughly 1/3 - 1/4 the config by using the <aop:...> <tx:...> or <scheduling:...> namespaces. You can still do things the old, verbose way, but now there's no reason to do so unless your either reinventing the wheel or have highly specialized needs that require low-level customization.

2) Spring has gone through their framework and found so-called "sweet spots" where XML-based config simply doesn't make sense. URL mapping, AOP pointcuts, autowiring or init methods, transactional behavior, all become much easier to configure as you no longer need swaths of XML to do something that a simple annotation can do (@Transactional anyone?). And inasmuch as there exists a standard Java annotation or JSR which specifies the same thing, they support that (following their "light weight framework" mantra).

A particular note on the parent's mention of PropertyPlaceholderConfigurer: I extended that configurer a couple years ago for our team such that it dynamically loads different sets of properties depending on the environment it is running on (defined by an environment variable). We pull nearly everything out into those properties files (app variables, logging config, profiling, etc) such that a single WAR file can be deployed on any of our environments w/o the need for any post-deploy reconfiguration.

As for DB config, that's the job of the servlet container. By using JNDI binding, there's no need for the application to worry about DB config at all (why would you want your production creds in a build anyways).

As for the web.xml in particular, most web.xml's I've seen for applications that are built by developers who understand the Spring framework (again > 2.0) are very thin. They pretty much just point to DispatcherServlet and URL config inside Spring (again minimized by using URL mapping annotations) take care of the rest. No need for servlet filters since Spring request interceptors do the same thing and in a much more flexible way. This is very much in-line with most frameworks which redirect all requests to a single entry point inside the framework (ie: wordpress, rails, cakephp, etc.).

Bottom line, be careful when you make/see the "Spring requires loads of XML config" argument. It usually comes from those whose idea of Spring is several years old.

And yes, I'm a Spring fanboy. ;-)

Re:XML devils & details (1)

euroq (1818100) | more than 3 years ago | (#34900720)

Just so you know, my experience with Spring comes from 4 years ago. Sorry for making everyone go up in arms :)

Re:XML devils & details (1)

SplashMyBandit (1543257) | more than 3 years ago | (#34898164)

IMHO the plumbing part is like code (if you have to rebuild your WAR to change it then it is the same as code), so prefer to write anything smaller than the huge applications in code alone (or annotations), and minimize the funky XML dialects (Spring included) for the plumbing. You should be trying to write your systems so that the number of skills required to maintain it are minimized (you might have been tracking Spring since day 1 and know all the variations over the versions, but how likely is your maintainer in Mumbai to also know this?). By composing your system in XML it means that debuggers and the great wealth of code maintenance tools are of no use, and the developer must know which of the dozens of XML files scattered around their source tree coloborate to configure anything. I personally hate debugging systems where something is magically injected and you have to search the whole source tree to find which of the layers of Spring (further indirected using property injection) is doing the config. Any developer can write a complex app - only a few have been around enough to simplify ruthlessly.

The plumbing you are talking about is mostly singleton stuff and most people use Spring to put singletons in more places they should. Singletons should only be for precious resources that you have one of because they are restricted (eg. hardware access, where two would interfere) or very expensive to create (eg. database pool). Mostly people could be using POJOs on the heap instead - which would force the POJOs to have proper getters setters (lots of Spring folk hide these, which hampers testing [wanna set a property to configure it for testing (or even mis-configure it deliberately to test your system robustness/error handling)?] ). This promotes re-usability (you can use the POJO in ways the creator never envisaged as you are not bound by the straight-jacket of how they thought you might use it [this straight-jacket affects more development than developers mis-configuring properly documented class]). This also promotes code efficiency since you can create as many threads as you need with the POJOs created in the thread (without the overhead of synchronizing access to a singleton). POJOs are still underused by many developers as they are too simple for minds that love the latest and greatest (those who think they are great developers for building complex systems in multiple programming languages when a much more straightforward design could have been used [at the expense of slightly more lines of code]).

Re:XML devils & details (1)

xero314 (722674) | more than 3 years ago | (#34901976)

IMHO the plumbing part is like code (if you have to rebuild your WAR to change it then it is the same as code), so prefer to write anything smaller than the huge applications in code alone (or annotations), and minimize the funky XML dialects (Spring included) for the plumbing.

This is true unless you have multiple concurrent version of the same code running with different configurations. I have worked on applications that all shared the same internal api for data access (just as an example) but they connected to different databases with different internal schemas (because the application did not have control over the DB schema). So we would have different OR Mappings for each different implementation of the same application. So even though the OR Mappings where compiled in the final artifact (jar, war, ear, etc.) it does not mean that we should have had different sets of compiled code.

I have seen the same happen with spring, where different implementations of the application needed different spring configurations. Technically we could build these without including the spring context in the deployed artifact, but it's just easier to package it all up into a single artifact.

Mostly people could be using POJOs on the heap instead - which would force the POJOs to have proper getters setters (lots of Spring folk hide these, which hampers testing [wanna set a property to configure it for testing (or even mis-configure it deliberately to test your system robustness/error handling)?] ).

Again, another classic misuse of Spring. First of all spring promotes exposing getters and setters. The fact that by exposing getters and setters and using spring you have just created a fully configurable bean should be enough to push you toward exposing more properties. And more importantly, if you are considering spring while coding you classes, unless using specific spring helper libraries, then you are completely misunderstanding spring. The idea behind spring is to bind code together, in ways that were not explicitly hard coded.

And since you don't seem to get it, a spring bean is a POJO. There are no special API's you have to implement to create a spring bean. There is no special design pattern you have to follow. You don't even need to expose getters and setters if you don't want to, though that would be foolish. And it's up to you how flexible you what your POJOs to be. You can code to interfaces, or just create concrete POJOs, spring doesn't care.

And as I have said before, anyone can misuse a framework, but it takes real ignorance to blame the framework for that misuse.

Re:XML devils & details (1)

SplashMyBandit (1543257) | more than 3 years ago | (#34902222)

> And as I have said before, anyone can misuse a framework, but it takes real ignorance to blame the framework for that misuse.

Ignorance? no. You can mis-use any framework or language. The problem is not Spring per-se, IMHO it is the documentation and zealots that suggest dependency injection is the One True Way and Spring is the One True Path - to be used everywhere. In practice it is far less clear cut, but the Spring documentation is very poor on when *not* to use it, and it is poor on keeping things absolutely simple. Now, this is no worse than many other frameworks, but Spring holds itself as better than the others - yet it falls short.

While you could debate the merits of the implementation of BeanKeeper, you'd be pretty hard pressed to beat its philosophy. Have a think whether Spring is designed with the same philosophy in mind.

Re:XML devils & details (1)

xero314 (722674) | more than 3 years ago | (#34902368)

The problem is not Spring per-se, IMHO it is the documentation and zealots

I'm not going to argue about documentation of zealotry. Springs Documentation is very detailed, and very easy to understand, though certainly still plagued with the usual open source problems. And as for Zealots, well zealots suck in all walks of life.

While you could debate the merits of the implementation of BeanKeeper, you'd be pretty hard pressed to beat its philosophy. Have a think whether Spring is designed with the same philosophy in mind.

BeanKeepers philosophy is exactly why it's not in widespread use, and most programers would have to look it up, as opposed to Spring or Hibernate which are becoming household names. The BeanKeeper philosophy contains majors flaws that will continually hold back it's adoption. If the BeanKeeper philosophy worked, then most of us developers would be out of work. The problem with BeanKeeper is that they assume two things that are almost universally false. First is that there is one right way to handle object persistence, and second that the application developer has full control of the data store. Nevermind that the philosophy, of keeping things simple, is internally inconsistent. There is nothing simple about the domain specific language they use for data querying, as they seem to base it on well known SQL syntax, but make arbitrary changes to nomenclature with no gain in simplicity.

The basic philosophy of BeanKeeper is, If it's something simple then it should be simple to do. The problem with this is that what the philosophy should be is, If it's something simple, don't build a framework to handle it. Frameworks are for complex problems, easy problems are...well...easy.

Re:XML devils & details (1)

SplashMyBandit (1543257) | more than 3 years ago | (#34902882)

Bro, creating objects is easy. Configuring them can be trickier but you don't necessarily need something with the conceptual weight of Spring to do it. Spring certainly has its uses - it's just not a panacea. There are other ways of achieving the same thing without the bulk though.

Re:XML devils & details (0)

Anonymous Coward | more than 3 years ago | (#34898390)

factual configuration settings (for example: database URL, user and password for application). Mixing these two things is a major sin as plumbing and configuration have different characteristics.

Yes, it's a sin and it takes an incompetent developer to do so. There's a reason JNDI exists. The kinds of things you're talking about should be configured in the container and treated by the application as a special kind of dependency.

If you use this design pattern, it preserves the separation between application logic and operational concerns. It allows the sysadmins to change passwords, migrate services to or provision new servers and handle other non-development concerns without involving developers or pushing a new version of the application (or, worse yet, editing application xml files directly on the server.)

Spring (and probably other IoC containers) make JNDI lookups beyond trivial. And it's relatively simple to simulate the JNDI context in tests, if necessary. So if your application context has anything other than plumbing in it, you're doing it wrong.

Re:XML devils & details (1)

xero314 (722674) | more than 3 years ago | (#34901904)

Sounds like the ever so typical "I hate this framework because when I misuse it, it doesn't work very well," or is to hard to maintain or extend or whatever.

It's like my house, where the designer decided to put the hot water heater on one side of the house and then use a ton of plumbing to pipe it to the shower on the far side of the house which cause a huge waste in water to get hot water out of the shower, rather than build all the hot water appliance around a central location. Now I could blame indoor plumbing for making this possible, or I can accept that this particular design and usage of plumbing is done poorly.

I can make any useful framework into a monstrosity (and at times I have), but that doesn't make the framework any less useful, you just have to learn how to use it correctly.

I used to feel about annotations the way you feel about Spring, because I felt having run time processing directives hardcoded into compiled code was a bad idea. Annotating my bean as a Service, or as an Entity (for JPA/Hibernate) makes no sense, it's just a class and I should be able to use it as a service in one context and as a standard class in another, and the same goes for entities and any other runtime directives. But then I realized it's not the fault of the annotations framework, it's the fault of a specific implementation or usage of that framework. I hated Annotations so much it even turned me off from using spring config (which is annotation based spring configurations), but then I realized that the way spring config works, it doesn't have you putting runtime directives in you code, but only in dedicated configuration files that happen to be type safe and compiled.

If you learn how to use your tools correctly, you will find out that they usually work much better than if you try to use the wrong tool.

Re:Web.xml is the reason I hate Spring (0)

Anonymous Coward | more than 3 years ago | (#34895920)

Then you're obviously not doing it right. You can achieve decentralization by using resource includes. So if that's the single reason you hate spring (which has nothing to do with Tomcat) then you can love it again.

Re:Web.xml is the reason I hate Spring (1)

KermitTheFragger (776174) | more than 3 years ago | (#34896082)

At least they do when you have to deal with a real website with real, complex functionality.

Why do people always assume what they are doing is the 'real' thing. Just like all those MTV hip-hop videos with people talking about the 'real' world. If you want a modular webapplication with Spring use Spring Slices. If that's not modular enough you can click Slices onto an OSGi solution like Spring DM server. You can't get a cleaner separation between modules. And since your into the real world; Yes, I've made such an application in the 'real' world, a rather large one.

Re:Web.xml is the reason I hate Spring (1)

euroq (1818100) | more than 3 years ago | (#34900694)

LOL! How did you take that above comment, written in 2 seconds late at night, so personally? And how do you assume that I was telling you you've never done a large application in the real world? And how do you assume that I wasn't doing the real thing myself?

In any case, the web.xml file was thousands of lines long and I remember hating it. I'm sure there have been major improvements since then (about 4 or 5 years).

Re:Web.xml is the reason I hate Spring (1)

dlgeek (1065796) | more than 3 years ago | (#34896154)

Spring: If it 'aint broke, add more XML.

Re:Web.xml is the reason I hate Spring (1)

Tridus (79566) | more than 3 years ago | (#34896370)

XML is like violence. If it doesn't work, use more!

- Someone else's /. sig

Re:Web.xml is the reason I hate Spring (1)

s2jcpete (989386) | more than 3 years ago | (#34896880)

When was the last time you used spring? Most of it is configured via annotations now.

Re:Web.xml is the reason I hate Spring (1)

euroq (1818100) | more than 3 years ago | (#34900618)

4 years I think. It left a bad taste in my mouth. I should have left a disclaimer and a long-winded explanation so my fellow ./ers wouldn't have gone up in arms about me complaining about it.

Re:Web.xml is the reason I hate Spring (1)

xero314 (722674) | more than 3 years ago | (#34901988)

When was the last time you used spring? Most of it is configured via annotations now.

Correction, Most of it CAN be configured via annotations. Many people still chose to use other forms of configuration other than Annotations, and for good reasons.

Tomcat is as rock solid as it gets (4, Interesting)

BeforeCoffee (519489) | more than 3 years ago | (#34895640)

Tomcat 6 has been a rock solid server for me for years. It's fast, it's easy to roll out, it can scale, and it's real tough to break. (Has it been cracked in the wild?) The non-blocking I/O extensions to the servlet spec were genius, and I wish other vendors had picked that feature up.

I look forward to much more goodness with Tomcat 7, sounds like there are tons of refinements to security and the codebase.

Thank you Apache and thank you Tomcat team!

You broke the chain. (1, Funny)

Anonymous Coward | more than 3 years ago | (#34895670)

Your post, while well-written and pleasant, did not include the word "suck".

Re:Tomcat is as rock solid as it gets (3, Interesting)

whizzter (592586) | more than 3 years ago | (#34895766)

It's solid for normal serving of servlet stuff but that's about it sadly.

- Your "security record" comes from the fact that tomcat is written in a "safe" language, a security hole would have to come from some stupid manual hole, a JVM bug or the APR connector.

- The non-blocking extensions are non-standard, and much worse than that is that those extensions only works with the APR connector (IE NATIVE C CODE!) but are only experimental with the portable NIO connector (after alot of debugging my own code i finally found a blog post about NIO not working with tomcat async). So it means that you need to be compiling/installing the tomcat code for the target platform before deployment instead of just copying over the JAR's or something like that as you'd be expecting with a Java app.

- The internals are quite contrived, oh i'm sure there's a good reason and prolly has to do with the APR/NIO/"classic" multi-connector support but it made me drop the option of actually fixing the NIO support. (so the open source advantage goes out the door)

- Last i tried (autnum) the API for servlet 3 async was there in tomcat7 but it seems the implementation wasn't? gave me alot of headache and the APR only support for their propeitary async api finally broke most of my faith in tomcat as a future platform.

The most ironic part about all of this is that i decided to do a quick project with a "established" base system and not be hacking things up, but i'd say i rediscovered a truth. If you want to do something new with an established package you might just run into experimental features and/or features that would requie the entire system to be rearchitectured (both in the case of tomcat).

I've now taken a big leap to an "experimental" platform(Node.JS) and while not perfect at all it was built from day one for the kind of things i wanted to do. Oh and working with Javascript on a small project is an absolute pleasure compared to Java :)

Re:Tomcat is as rock solid as it gets (1)

BeforeCoffee (519489) | more than 3 years ago | (#34899514)

I disagree that Java's JVM is the sole reason Tomcat is the first choice for Java web containers. Look at some of the bug reports on the major commercial vendors' app servers, and you'll see just how complicated a situation it is to build out these JEE specs. Tomcat seems to avoid these kinds of exploits, and I think its a simple matter of: the team cares about security and they get massive feedback from the user base because they are so widely deployed.

Wow, you've had some problems with Tomcat! Truth be told, I haven't used plain Tomcat in years - I need JEE, so I run with Geronimo. But I wouldn't touch Geronimo with a 10 foot pole unless it ran atop Tomcat. Perhaps the way Geronimo embedded Tomcat fixed some issues with Tomcat when they embedded it? I've been doing NIO-based non-blocking servlets in my apps for years without failure. I run everything through the Http11NIOConnectorGBean, and all of my servlets got a massive performance increase just by configuring that.

As far as the code quality/architecture comments, I think you're probably right. Tomcat isn't the cleanest code. It's been so battle hardened, that I'll take it anyways. Tomcat is up there with JVM and Apache HTTPD in terms of trustiness for me.

Node.JS sounds interesting, and I agree JavaScript is a fun and productive language to write code in. I don't think I could deploy it however, the underlying binaries have a lot of new-ish moving parts which scare me away.

Dave

Re:Tomcat is as rock solid as it gets (1)

TheTurtlesMoves (1442727) | more than 3 years ago | (#34903116)

- Your "security record" comes from the fact that tomcat is written in a "safe" language, a security hole would have to come from some stupid manual hole, a JVM bug or the APR connector.

How is that a bad thing, or in anyway negate the original claim?

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34896206)

I agree with most of what you are saying, but I am having a problem I haven't been able to find a solution yet.

Here is the problem. I have just one straightforward web app on the server, and once in a while a request for data takes a bit too long and the user retries it, but the original request is still running in a tomcat thread, and it's not stopping.

Eventually what may happen is that the entire thing becomes useless until it's restarted.

Safe for implementing a proprietary thread management system and clustering a front end instance of Tomcat with back end instances executing working threads and then rotating between them and excluding the ones that are not responding and probably even killing/restarting them with scripts, has anybody found a simpler solution to this sort of a problem? Maybe I am just overlooking some simple way to use the Executor thread pool to time out and kill off Threads that do not have a live corresponding web request anymore somehow?

Basically how can execution of a thread be stopped if a user is no longer expecting this request to return (either by closing the browser, or losing the connection or using the app menu to go to another page, or even if the execution takes too long and should be timed out?) How do you even time out Executor threads after a fixed amount of time?

Re:Tomcat is as rock solid as it gets (-1)

Anonymous Coward | more than 3 years ago | (#34896410)

There is no way to know on the server-side without some javascript/polling mechanism that the browser has closed. Think of how HTTP works, everything is request and response. You are not qualified to write software, and the reason you need to restart the container is that your code is badly written.

Re:Tomcat is as rock solid as it gets (0)

roman_mir (125474) | more than 3 years ago | (#34897252)

yeah, yeah, asshole. You have any idea how to time out an executor thread after an amount of time has passed, or no? If not, shut your yap.

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34897830)

you just don't get it, there is no reliable way to know server side if the user closed his browser, disconnected his network adapter or went to another site, sure, you can use ThreadPoolExecutor#awaitTermination to timeout the thread. http://forum.springsource.org/showthread.php?t=87480 [springsource.org]

When you say "Eventually what may happen is that the entire thing becomes useless until it's restarted." means that your code is badly written and uses too much resources, just fix that code.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34897874)

ha ha ha ha, idiot, didn't I say: what is the way to time out an executor thread? What is the difficult thing to understand? You can sit there and yap and yelp about code as much as you want, but what is the way to kill a thread that is taking too long? How the fuck, do you, idiot, know what a thread is doing? It's creating a gigantic 3 year based report by running SQLs against a dabase and putting together a picture that's going to be placed an HTML page.

Clearly the web is screwed up so there is no state in HTTP and the server can't easily know that the client is no longer waiting for the response, but there has to be a way to deal with requests that do not need to be executed any longer.

So, idiot, again, yap away, or provide a solution based on Tomcat configuration, otherwise there will have to be plenty of code written.

Come on, do something USEFUL once.

Re:Tomcat is as rock solid as it gets (1)

Pieroxy (222434) | more than 3 years ago | (#34898132)

12 years of java coding behind me, and you look like the idiot, not the AC you're replying to. If an accumulation of threads (because of refreshes) bring your tomcat instance down, it means your code is crap. Or you need a cluster because you have high traffic. Deal with it. Having automated restarts of tomcat instances or timeouts is just going to destabilize your app, which does look like it doesn't need it.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34898216)

Yet with your 12 years you still didn't get the question, did you? How do you time out an executor thread that's no longer useful, if it's still doing work, type of work that takes long time to do? - so if this looks like an idiotic question to you, then you haven't had to do much in those 12 years.

Secondly, it's not 'refreshes' that cause this, it's dumped requests, that are still processing. Sometimes many dumped requests.

Clearly there can be more done, more memory, a cluster, etc. Most of it would be a waste because this particular issue is only with threads that are still going, sometimes going for 45 minutes, taking up processor and memory.

So in reality, if this is not though through by the Apache team, then the question is: have they ever had to write code to produce very large reports on very large data sets and if not, why not? I am sure this is not the first time somebody is doing it in real time.

The 45 minute requests are a rarity, all of the parameters are user set, so if a user chooses a very large data set to go through and then decides not to wait for it, or tries to change the parameters of the request and restart it again - that's a normal use case.

Yes, some reports take thousands of SQL executions and massive amounts of data to be held in memory. No, this is not an every day occurrence. Yes, there are more than 1 user, around 50 people doing various things. Yes, it would be nice to have a cluster, but most of the time this is not an issue so it's not really a hardware problem.

It is possible to have checks in the code itself, and verify between executions of SQL statements whether this request should be terminated, so that's one way of doing it. But if the servlet container is not helping by providing at the very minimum a time out mechanism for the Executor threads then why not? It should be.

--

So in short, with your 12 years of experience, you are the one who looks like a dumb ass to me if you can't imagine a situation where Executor thread timeouts could be used for good before ideas like clustering and distributed nodes are considered.

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34898964)

Your question was answered in one of the posts you replied to nastily. It can also be found in the API documentation. Apparently you read as well as you code.

Re:Tomcat is as rock solid as it gets (0)

roman_mir (125474) | more than 3 years ago | (#34898992)

Didn't I tell you to go fuck yourself in enough ways? Can't you take a hint?

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34899480)

slashdot seems to be full of god damn fucking nig nogs today. Must be all the jigaboos getting ready celebrate watermelon and fried chicken day. So I'll give you the god damn answer. It's so fucking simple you'll laugh: poll the fucking connection and check if it's still open. It's that fucking simple.

Re:Tomcat is as rock solid as it gets (0)

roman_mir (125474) | more than 3 years ago | (#34899664)

Another moron with a keyboard. Polling connection on what, you, nimrod? From the client it's useless, the thread is already running in the container, nothing can stop it until it's done with its task. From the thread itself - the client can still be there just fine, working on some other report. Go bang your stupid fucking head against the wall, maybe you'll set your brains straight.

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34899856)

I didn't realize you were a fucking bonehead. Do you need somebody to wipe your ass, too? This is basic shit, no wonder it's beyond your comprehension.

Re:Tomcat is as rock solid as it gets (0)

roman_mir (125474) | more than 3 years ago | (#34900040)

You can go ahead, asswipe, use your tongue.

Re:Tomcat is as rock solid as it gets (1)

Pieroxy (222434) | more than 3 years ago | (#34899840)

Yet with your 12 years you still didn't get the question, did you? How do you time out an executor thread that's no longer useful

Hold it! stop right there!!!

You cannot know whether it is no longer useful or not. There. Does that answer your question?

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34898136)

i won't do your homework, anyway, you will spend all next week or maybe more fixing your crappy code.

happy coding.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34898234)

ha ha ha ha, what a dumb ass, still not getting the question yet offering a useless, clueless comment here.

Re:Tomcat is as rock solid as it gets (1)

JonySuede (1908576) | more than 3 years ago | (#34899482)

for report like what you described a few post up, you should consider a BI tool to do the reporting on a denormalized database.
But for your rag tag "real world" system, a rapid fix would be to inject a bean that hold the Futures in the session attributes and then to cancel them when they are no longer needed.
I leave the implementation details to yourself, I have already said to much without getting paid.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34899626)

First: it's a normalized database.

Second: nobody can answer a simple question, is it possible to time out a running task through Executor thread. Your solution is not doing much good, is it? Since the user can have multiple reports running at once legitimately.

Third: I don't need your implementation, since you don't understand the question.

Re:Tomcat is as rock solid as it gets (1)

JonySuede (1908576) | more than 3 years ago | (#34900550)

First: it's a normalized database.

yeah and I said denormalized, you use a BI tool to do an ETL then from this dataset you do the analytics and the reporting. It is way faster that way.

I don't have your code but I am certain that changing the parameters you talk about is not a good solution since, assuming it exist, it binds you to a specific platform.

You wont find any good answer on a forum.

Pay a consultant that was there since java 1.0 for your solution, someone in BI with previous experience with servlet would do you good.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34900704)

Beautifully done, I love /. an entire number of assumptions, not backed by any reality, but made with complete certainty. It's an amazing site and sight.

1. I am no longer looking for a Tomcat provided solution, I am quite certain all of the changes must be in application.
2. Would you like to pay for the new tool? The transitioning to the new tool? Maintenance? Support? Training?
3. Are you sure that your tool would do a better job than what is currently done with that same data, regardless of how the data is structured? Good to be so sure. I wouldn't be so sure, but that's because I know what the data is, which parts of data are cached, what the structure is. Also, I have this tingling sensation in my left foot, can you tell me if a white pill would do more good for that than this green pill?
4. You are sure that you know everything about the requirements here, so your educated guess about my platform must be right, obviously.
5. I certainly know that I am not going to find any good answers on this forum, but that's not going to stop me from posting. I have an hour to waste.
6. I was there since java 1.0 :) working merrily on an AT&T-Canada project to process large files supplied by an old mainframe that had to be shipped to rebillers, I still remember the first time I had to use java, yes. But thank you.

7. I am sure that you have many many more wonderful suggestions and they are about to come.

Re:Tomcat is as rock solid as it gets (1)

JonySuede (1908576) | more than 3 years ago | (#34900998)

I am not selling a tool or anything else. I am just suggesting you to see a consultant, someone who solve that kind of problems for a living.

I specialize in J2EE application security, so I am not suggesting that you hire me. But hiring a good consultant for solving a specific problem is usually money well spent.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34901336)

Money well spent when I spend it on a vacation, everything else is a waste.

As to hiring a consultant - for what purpose? To solve a problem that happens 1-2 times a month on a system that is being used by 50 people 12 hours a day? I already have a solution, and it doesn't involve buying into nonsense.

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34901440)

thank you for posting so many details about your current assignment, tomorrow morning your boss will get a copy of this thread in his inbox.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34902654)

wow, another genius. So I am waiting for the email.

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34901034)

You are going to die miserable, angry, and alone.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34901228)

ha ha ha, well, anything to skip looking at your pathetic faces.

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34901326)

Sorry to step into this as an AC, but anyway...

If your solution already does what it is supposed to do, but twice a year things go pearshaped (due to heavy loads on your system by user queries) you should focus on that aspect of the probelm.

First line of tackling this would to be to apply what you already seem to have in your arsenal - i.e. AT&T-Canada reference to process large files in a batch environment - match that with your problem - and you will see that your "realtime" (5 min, 10min, 15min and 45min references given by you are not "realtime" by any stretch of that definition) solution can be improved.

I assume your users fill in some html page with query details, and press a button - staring at the screen until the result pops back into their web page.

My suggestion to you would be to add "job control overview" into that very same page (at the top maybe) that would give the user an overview of their outstanding job/query requests (it is vital that the jobs be listed with enough of the query parameters, so that the user can actually see which job does what query).
Adding checkboxes for deleting outstanding jobs and a "Remove job(s)" button.

This suggestion implies that you restructure your existing solution so that at "convenient" places in your report engine you check the job queue for updates on the user requests.

This gives you control over which users might be allowed to have many outstanding queries, depending on the load of the machines, importance of queries, importance of users, type of report for time of year (e.g. certain reports have priority, some users have priority ) etc. etc. etc.

Wishing for a solution from Tomcat/java so that you can simply assassinate thread jobs from the outside is not going to be successful - because it has been deemed not a technically sound/clean way.

On the other hand building job control support along the idea above:
- still make your existing solution as "real time" as it is today -
- does make your users "feel in control" as before (or more so to be honest)
- gives you control so that you can throttle/prioritise requests based on userid/reportid etc.,
- does highlight the problem to your "people" (both the technical ones and the report users)

It therefore takes you off the hook for "not delivering" as you now have a solution for both making the user understand, and in control of their part of the problem (each user could see the whole process pie, his part of the process pie, and maybe down to each of his processing jobs)

It gives you measurable statistics for arguing for bigger hardware for running the whole thing (you will be able to see how big your spikes are, of delivered jobs vs. all job requests and all broken down on user/department/report type etc.)

Sorry for posting AC - dont have account here - and no - I have not posted to your article/request before as an AC... dont like those unnecessary unhelpful comments

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34904222)

Yeah, let me post something here right now. This is a list of requests from today (the day is not over yet, it's not US timezone, so don't be surprised.)
I just cut that out of the log table, I am not showing the incoming IP addresses, user names, types of the reports that are executed, the parameters passed into the reports, etc.etc. Just times and milliseconds.

You think people, who are busy working, care about your idea of queues? You think it doesn't let the people to 'feel in control' in a system that does in seconds and in some cases in minutes, what they are used to be taking tens of minutes and hours, and in some cases not being able even to get that kind of data, because the solution is much bigger than just a silly small part that generates reports?

I feel the arrogance in this place, oozing through the pores. The people in my systems, they are working, not playing, they don't care about 'feeling in control', they care about getting stuff done. Many of them are running reports one after the other, after the other just because they adjust some very small filter detail
and need to see the result right away. Giving them one more thing to do - some job control queue, yeah, that'll make them happy.


17:44-1805 13:29-3 16:15-1536 10:32-4 17:09-11363 11:52-7703 14:38-1046 9:49-13427
17:43-856 13:28-13005 16:15-2141 10:32-17384 17:09-10 11:46-3127 14:38-11 9:49-13258
17:43-15421 13:28-13 16:15-5342 10:31-11 17:09-10922 11:46-3254 14:38-5 9:48-10
17:43-13283 13:28-2 16:15-1473 10:31-2 17:09-10 11:45-1662 14:38-779 9:48-4
17:43-13183 13:28-638 16:15-1476 10:31-10 17:08-11330 11:45-1716 14:38-775 9:48-16484
17:43-11 13:28-43 16:15-1541 10:31-3 17:08-10 11:44-7231 14:38-777 9:48-11
17:43-859 13:28-4 16:14-1541 10:30-866 17:07-11380 11:44-3501 14:38-1812 9:48-3
17:42-13182 13:27-58 16:14-1541 10:30-11 17:07-11 11:44-6752 14:38-6 9:47-10
17:42-11236 13:26-705 16:14-1541 10:30-3912 17:06-10909 11:41-4823 14:38-815 9:47-1668
17:42-11 13:26-71 16:14-1542 10:30-6 17:06-10 11:41-3155 14:37-12 9:47-4
17:42-795 13:25-3 16:13-1539 10:27-255 17:06-2 11:41-3178 14:37-6 9:47-11
17:42-13225 13:25-3 16:12-1542 10:27-6488 17:06-6 11:39-751 14:37-771 9:47-2813
17:42-11991 13:25-13804 16:12-1541 10:27-1401 17:06-11939 11:39-824 14:37-14232 9:47-3
17:42-13128 13:24-11 16:11-1542 10:27-844 17:06-2 11:37-3 14:37-12 9:46-10
17:42-10 13:24-5650 16:10-1542 10:27-562 17:06-10 11:37-4987 14:36-520 9:46-3
17:41-4581 13:24-4 16:10-1539 10:27-530 17:06-2 11:36-20852 14:36-4 9:46-7011
17:41-11378 13:23-10 16:09-1540 10:26-522 17:05-11367 11:36-11 14:36-1676 9:46-828
17:41-13104 13:23-3 16:09-1437 10:26-18443 17:05-11 11:35-4 14:35-807 9:46-10
17:41-10 13:22-47396 16:09-1438 10:26-1 17:04-10 11:35-2 14:35-11687 9:45-4
17:41-14738 13:21-2073 16:08-1437 10:26-10 17:04-11484 11:35-2 14:35-5 9:45-1554
17:41-12266 13:20-3 16:08-1434 10:26-2 17:04-10 11:35-2 14:35-4 9:45-2909
17:41-12834 13:20-3 16:08-2093 10:26-4 17:04-2 11:35-2 14:35-10 9:45-946
17:40-10 13:20-4 16:08-1435 10:26-4109 17:04-11057 11:34-2 14:34-795 9:45-10
17:40-848 13:20-3 16:07-1439 10:25-12 17:04-11 11:34-2 14:34-10 9:45-3
17:40-1636 13:20-3 16:07-1472 10:25-1395 17:03-5 11:33-48 14:34-4 9:45-5088
17:40-19147 13:20-2 16:06-1467 10:25-516 17:03-11655 11:33-11 14:33-799 9:45-7393
17:40-12187 13:20-3 16:06-1469 10:25-4 17:03-10 11:33-29 14:33-12729 9:44-776
17:40-11 13:20-4 16:06-1469 10:25-4604 17:02-11378 11:33-4 14:32-11 9:44-10
17:40-1464 13:20-3 16:06-1511 10:25-867 17:02-3 11:32-4 14:32-3 9:44-5
17:40-794 13:20-2 16:05-1490 10:25-15929 17:02-11 11:32-11 14:32-797 9:44-10
17:39-19530 13:19-10 16:05-8125 10:25-111 17:02-11066 11:32-4 14:32-12779 9:44-3
17:39-11817 13:19-3 16:05-1478 10:24-21164 17:02-10 11:32-4376 14:31-798 9:44-2
17:39-10 13:18-2651 16:03-1482 10:24-25281 17:01-11332 11:31-15634 14:31-11 9:43-10
17:38-986 13:18-14842 16:03-1483 10:24-15740 17:01-10 11:30-12 14:30-4 9:43-2
17:38-820 13:17-10 16:03-1480 10:24-525 17:00-11024 11:29-4 14:29-10 9:43-4
17:38-1470 13:17-3 16:02-1477 10:24-26473 17:00-10 11:27-1334 14:29-6 9:43-10
17:38-841 13:17-3399 16:02-1478 10:24-34673 17:00-11274 11:27-12705 14:29-850 9:42-4643
17:38-10861 13:15-71523 16:02-1483 10:23-38568 17:00-12 11:27-1518 14:28-11 9:42-5556
17:38-5 13:15-2732 16:01-1496 10:23-10 16:59-1735 11:27-821 14:27-4 9:42-4563
17:37-20344 13:13-293376 16:00-1443 10:23-4 16:59-1732 11:27-1396 14:27-787 9:41-2879
17:37-11894 13:10-17610 16:00-1445 10:23-11 16:59-1736 11:26-6 14:25-862 9:41-4
17:37-10 13:10-2720 15:59-1442 10:23-6 16:58-1812 11:25-11166 14:24-12 9:41-4574
17:37-842 13:10-11074 15:59-1448 10:22-18000 16:58-1673 11:24-5 14:24-790 9:41-10
17:37-12175 13:10-15343 15:58-1444 10:22-11 16:58-1810 11:24-12 14:24-4 9:41-3
17:37-11317 13:09-11 15:58-1455 10:22-4 16:57-1732 11:23-4235 14:24-61 9:41-4708
17:37-12951 13:09-281867 15:57-1556 10:21-12753 16:57-1735 11:23-4148 14:24-3 9:41-11
17:37-11 13:09-4 15:57-1559 10:21-13112 16:56-1729 11:23-4229 14:23-3 9:40-3
17:37-829 13:06-5 15:56-1556 10:21-11 16:56-1346 11:21-3917 14:23-4 9:40-10
17:36-11343 13:05-4 15:56-1549 10:21-557 16:56-1732 11:18-763 14:22-793 9:40-1
17:36-12987 13:05-11 15:53-3948 10:21-5130 16:56-1696 11:17-784 14:21-817 9:40-3
17:36-11 13:05-10 15:53-12949 10:21-3917 16:55-1691 11:17-1112 14:21-5231 9:39-2239
17:36-841 13:05-3 15:45-11 10:20-2000 16:55-1694 11:17-9006 14:20-1663 9:39-10
17:36-5 13:04-12 15:45-5 10:20-1144 16:55-1720 11:17-752 14:20-3 9:39-4
17:36-4 13:04-5 15:44-5 10:20-2039 16:55-1437 11:15-5 14:20-850 9:39-24722
17:36-14688 13:02-12 15:44-11 10:20-5338 16:54-11306 11:15-11 14:20-2881 9:39-11
17:36-11485 13:02-2 15:44-5 10:19-525 16:54-16 11:15-4 14:19-2142 9:39-5
17:36-12 13:01-5 15:42-5 10:19-1841 16:54-12799 11:15-765 14:19-1838 9:38-11
17:36-846 13:01-63457 15:42-5 10:18-3 16:54-10 11:15-12 14:19-2144 9:38-4
17:35-1736 13:01-7064 15:42-12 10:18-10 16:54-10 11:13-763 14:19-2154 9:38-1387
17:35-10941 12:59-2972 15:41-27 10:17-4 16:53-13257 11:13-771 14:18-5 9:38-832
17:35-847 12:58-11 15:40-774 10:17-4942 16:53-12 11:12-4 14:18-13495 9:38-5
17:35-11783 12:58-919 15:40-3144 10:17-486 16:53-8 11:12-3834 14:18-4 9:38-57
17:34-10 12:58-5 15:37-11027 10:17-10 16:52-11254 11:12-3910 14:18-11 9:38-578
17:34-19402 12:57-11 15:37-4 10:17-4 16:52-1550 11:11-1395 14:18-1626 9:37-5
17:34-12608 12:57-2 15:37-10772 10:17-12912 16:52-1655 11:11-1036 14:18-2237 9:37-12
17:34-10 12:56-4 15:36-2 10:17-11 16:52-14427 11:11-1307 14:18-813 9:37-11
17:34-865 12:55-7 15:36-2 10:16-4 16:52-1546 11:11-761 14:18-2209 9:37-8
17:33-11050 12:54-13 15:36-3 10:16-13045 16:52-1546 11:09-9435 14:18-1553 9:36-1306
17:33-10 12:54-5 15:36-2 10:16-11 16:51-1550 11:08-9628 14:17-2151 9:36-5
17:33-899 12:53-3365 15:34-10758 10:16-3 16:51-1601 11:08-11122 14:17-783 9:36-764
17:33-907 12:53-1559 15:32-4 10:15-10 16:51-1782 11:08-767 14:17-2152 9:36-11
17:33-11645 12:52-12769 15:32-4 10:15-3 16:51-1545 11:08-5 14:16-1941 9:36-4
17:32-17229 12:52-12 15:29-1064 10:15-10 16:50-1545 11:08-787 14:16-13735 9:36-11
17:32-10 12:52-4 15:25-1557 10:15-5 16:50-1548 11:07-24 14:16-786 9:36-9
17:32-10929 12:50-28 15:24-795 10:14-11 16:50-1552 11:07-5 14:15-30 9:36-793
17:32-6 12:50-2 15:24-778 10:14-3 16:50-1671 11:06-11845 14:14-798 9:36-379
17:32-10 12:49-5 15:23-1542 10:13-10 16:49-9077 11:06-11 14:14-20048 9:36-1064
17:32-5 12:47-11 15:23-1541 10:13-3 16:49-1547 11:05-4 14:13-16365 9:36-759
17:32-887 12:46-3 15:23-1543 10:11-10 16:49-3690 11:05-11 14:13-8043 9:36-779
17:32-5717 12:46-1640 15:22-783 10:11-3 16:48-1440 11:05-3 14:13-11 9:35-956
17:31-79 12:46-1385 15:22-1543 10:11-11 16:48-1444 11:02-1727 14:13-788 9:35-11900
17:31-11386 12:45-14868 15:22-1549 10:10-3 16:48-3972 11:02-5467 14:13-783 9:35-5
17:31-12196 12:45-10 15:21-1620 10:10-11 16:48-1439 11:02-774 14:13-778 9:35-4
17:31-11 12:45-942 15:21-1724 10:10-4 16:47-1439 11:01-8083 14:13-792 9:35-13
17:31-74 12:45-3 15:20-42284 10:09-10 16:47-1439 11:00-7987 14:12-7 9:35-1309
17:31-6 12:44-11 15:20-6325 10:09-3 16:47-1442 10:59-724 14:11-3 9:35-12
17:31-20088 12:44-4 15:20-1465 10:08-11 16:47-1438 10:59-1315 14:11-785 9:35-642
17:30-12813 12:43-10 15:20-1480 10:08-3 16:46-1480 10:58-762 14:11-3 9:34-5
17:30-10 12:43-3 15:19-656 10:08-10 16:46-1483 10:58-737 14:10-789 9:34-1341
17:30-16329 12:41-11 15:19-1436 10:08-609 16:46-1272 10:58-741 14:09-788 9:34-768
17:30-11 12:41-1331 15:19-664 10:08-12862 16:46-1478 10:57-720 14:08-785 9:34-10
17:30-3 12:41-761 15:19-3815 10:07-10 16:45-1318 10:56-719 14:08-3 9:33-9
17:30-6 12:40-4 15:19-1471 10:07-3 16:45-1476 10:55-766 14:08-3 9:33-1307
17:29-825 12:40-1319 15:18-1468 10:07-1329 16:45-5842 10:55-1308 14:08-795 9:33-766
17:29-829 12:40-772 15:18-1465 10:07-4 16:45-10227 10:55-703 14:06-869 9:33-712
17:29-4 12:40-780 15:17-1466 10:07-11 16:44-3682 10:55-699 14:05-792 9:33-5
17:29-827 12:39-1547 15:17-1466 10:06-4 16:44-3695 10:55-761 14:04-809 9:33-18205
17:29-821 12:39-923 15:16-2 10:06-11 16:44-3716 10:55-11659 14:03-11 9:33-523
17:29-858 12:39-12458 15:16-2 10:05-5 16:44-5063 10:54-11 14:03-4 9:32-4
17:29-1858 12:39-11 15:15-813 10:05-10 16:42-1482 10:54-4 14:02-12 9:32-11
17:28-1770 12:38-1384 15:15-1475 10:05-4 16:41-7054 10:54-1308 14:01-4 9:32-764
17:28-827 12:38-3 15:15-1477 10:05-11 16:40-4986 10:54-762 14:00-16008 9:32-6
17:28-4656 12:38-12268 15:14-1475 10:04-5 16:40-5437 10:54-755 13:59-6 9:32-1555
17:27-923 12:38-783 15:12-1471 10:04-10 16:39-8916 10:54-779 13:59-5 9:32-1039
17:27-11849 12:37-11 15:12-1478 10:04-4 16:38-2473 10:52-691 13:59-11 9:32-11
17:25-10963 12:37-5 15:12-964 10:04-1312 16:37-1471 10:52-11650 13:57-10732 9:32-4
17:25-11 12:36-12356 15:11-1441 10:04-772 16:37-2541 10:52-12 13:56-176 9:32-11647
17:25-10898 12:36-11 15:11-1153 10:04-10 16:37-1469 10:52-2 13:55-11 9:31-6
17:24-10 12:36-1346 15:11-1440 10:03-3 16:37-1469 10:51-5 13:55-5 9:31-2589
17:24-13168 12:36-4 15:10-1442 10:03-750 16:36-1467 10:51-753 13:54-12 9:31-4
17:24-11409 12:35-1171 15:09-1439 10:03-754 16:36-1593 10:50-11800 13:54-4 9:31-12
17:24-11 12:35-787 15:09-1445 10:03-11 16:36-2592 10:50-5 13:53-14229 9:31-13430
17:23-15786 12:35-12346 15:08-1555 10:03-3 16:36-1475 10:50-11 13:52-11 9:30-5
17:23-11230 12:35-12 15:07-1499 10:02-10 16:35-1445 10:50-4 13:52-5 9:30-10509
17:23-10 12:34-4 15:06-1546 10:02-4 16:35-1436 10:49-6 13:51-11 9:30-4
17:23-12918 12:34-786 15:06-1506 10:02-11 16:35-1483 10:49-684 13:51-3 9:30-11
17:22-11503 12:34-784 15:06-1551 10:01-4 16:34-1441 10:49-684 13:50-14730 9:30-6
17:22-10 12:34-1322 15:05-2 10:01-8315 16:34-144 10:49-9653 13:50-5 9:29-764
17:22-16714 12:33-780 15:05-4 10:01-11 16:34-1442 10:49-4 13:49-19 9:29-10
17:21-10929 12:33-783 15:05-2339 10:01-4 16:34-1617 10:49-11 13:49-6 9:29-4
17:21-10 12:33-1317 15:03-10787 10:01-8042 16:34-1439 10:48-11 13:48-11233 9:29-8260
17:21-11885 12:33-765 15:03-11115 10:00-10 16:34-941 10:48-7 13:48-10 9:29-5
17:21-11455 12:32-782 15:03-11098 10:00-3 16:33-985 10:47-712 13:47-3633 9:28-3
17:21-11 12:31-11 15:02-10777 10:00-11 16:33-1576 10:47-713 13:47-4 9:28-9
17:20-12495 12:31-5 15:02-2145 10:00-3 16:33-1043 10:47-672 13:47-793 9:28-829
17:20-11 12:30-39 15:01-1364 9:59-1304 16:33-474 10:47-14696 13:46-14403 9:28-5
17:20-3 12:30-855 15:01-1386 9:59-766 16:33-1068 10:47-11 13:46-10 9:28-198
17:20-17056 12:30-4 15:01-795 9:59-15127 16:33-1561 10:47-3845 13:46-6302 9:27-4
17:19-11318 12:30-826 15:00-11038 9:59-1301 16:33-4 10:46-5 13:46-10 9:27-11
17:19-10 12:29-11 14:59-1392 9:59-11 16:33-3 10:46-490 13:46-12064 9:27-35326
17:19-5 12:29-785 14:59-10841 9:59-765 16:33-1588 10:46-493 13:45-11 9:25-5
17:19-20727 12:29-4 14:59-788 9:59-4046 16:32-2 10:46-523 13:45-4 9:25-205
17:19-12481 12:29-10 14:50-5279619:58-3 16:32-1535 10:46-18615 13:44-791 9:25-1
17:19-14 12:29-3 14:50-782 9:58-15160 16:32-1533 10:45-521 13:44-11 9:25-2
17:18-6 12:28-12 14:49-11 9:58-10 16:32-11610 10:45-509 13:44-3 9:25-1
17:18-13730 12:28-3 14:49-3 9:58-4 16:32-1539 10:45-479 13:44-811 9:25-6
17:18-12 12:27-784 14:49-1509 9:58-15248 16:32-4 10:43-764 13:44-5 9:25-8
17:18-5 12:26-892 14:49-1568 9:58-1304 16:32-4 10:43-484 13:44-2366 9:25-13
17:18-18828 12:26-11819 14:49-6 9:58-11 16:31-1539 10:43-479 13:43-11 9:25-5
17:18-12817 12:26-11 14:48-6016 9:58-797 16:31-12144 10:42-786 13:43-2 9:25-836
17:18-10 12:26-4 14:48-12843 9:58-4 16:31-11764 10:41-5 13:43-4 9:24-11
17:17-14646 12:24-11 14:48-11 9:57-15454 16:30-2 10:41-788 13:43-1188999:24-3
17:17-11034 12:24-786 14:48-4 9:57-10 16:30-1562 10:41-785 13:42-6 9:23-4
17:17-11 12:24-4 14:48-1225 9:57-423 16:30-1556 10:41-11 13:41-6929 9:23-699
17:17-14362 12:23-11 14:47-1557 9:57-1821 16:29-13475 10:41-4 13:41-12 9:21-558
17:17-10 12:23-2 14:47-1557 9:57-3 16:29-5 10:40-780 13:41-5 9:20-6
17:16-4 12:23-785 14:47-102 9:57-15258 16:29-12308 10:40-9214 13:41-94888 9:20-11
17:16-15043 12:22-12 14:46-1559 9:57-11 16:29-15 10:39-478 13:41-3908 9:20-6
17:16-14217 12:21-5 14:46-97 9:56-5 16:29-26 10:39-481 13:41-1915 9:20-514
17:16-13 12:20-5 14:46-809 9:56-4033 16:28-1556 10:39-761 13:40-1913 9:20-3
17:16-5 12:20-13 14:46-6140 9:56-212 16:28-1437 10:39-784 13:40-2512 9:20-13
17:16-13125 12:20-5 14:45-3997 9:56-500 16:28-1435 10:39-781 13:40-1910 9:20-2
17:15-4 12:18-8044 14:45-1558 9:56-3938 16:27-1437 10:38-11861 13:40-585 9:19-8
17:15-12 12:17-7861 14:44-776 9:56-15918 16:27-1434 10:38-4023 13:40-2064 9:19-9
17:15-12 12:14-20953 14:44-1672 9:56-3967 16:27-1436 10:38-2648 13:39-2742 9:19-4
17:15-8 12:08-6191 14:44-210 9:55-3962 16:27-1440 10:37-20919 13:39-2138 9:18-311
17:15-10 12:06-2585 14:44-2349 9:55-1844 16:26-1449 10:37-10 13:38-540 9:18-11
17:15-5 12:05-11 14:43-12293 9:55-14983 16:25-1466 10:37-2 13:38-2075 9:18-5
17:15-12946 12:05-2 14:43-11 9:54-11 16:25-1470 10:37-765 13:38-2337 9:17-10
17:15-11670 12:05-954 14:43-4 9:54-3 16:25-1470 10:37-2 13:37-2289 9:17-7
17:15-11 12:04-2166 14:43-1449 9:54-18769 16:24-1472 10:37-2 13:37-7590 9:16-15
17:14-5 12:04-4 14:42-1454 9:54-13519 16:24-3600 10:37-4 13:37-2130 9:16-10
17:14-12746 12:03-12 14:42-12716 9:54-11 16:24-1468 10:36-2604 13:37-12468 9:07-8376
17:14-10923 12:03-5 14:42-5 9:53-6 16:23-25695 10:36-11 13:37-18047 9:05-2528
17:14-15 12:03-615 14:42-791 9:52-2 16:23-2 10:36-5 13:36-12 9:05-6987
17:13-11 12:00-649 14:41-11 9:52-2 16:21-6760 10:36-2574 13:36-734 8:47-10643
17:13-5 11:58-6190 14:41-4 9:52-1308 16:20-1644 10:36-867 13:36-5 8:46-11549
17:13-8 11:57-7 14:41-12666 9:52-833 16:19-1474 10:36-28690 13:36-736 8:45-3222
17:13-13118 11:57-7 14:41-6 9:51-220 16:19-1453 10:36-9784 13:36-11567 8:44-3220
17:13-11282 11:57-9 14:41-13 9:51-1318 16:19-1483 10:35-7899 13:35-11 8:42-3380
17:13-11 11:57-14854 14:41-4 9:51-973 16:18-1499 10:35-822 13:35-2945 8:41-17156
17:13-5 11:57-2404 14:41-547 9:51-12926 16:18-1472 10:35-20518 13:35-4 8:10-11756
17:11-11 11:57-8 14:40-1486 9:51-11 16:18-1469 10:35-793 13:34-306 8:01-11741
17:11-5 11:57-9 14:39-1945 9:50-5 16:17-1482 10:34-935 13:34-21141 7:04-45638
17:11-11424 11:57-6988 14:39-12640 9:50-15429 16:17-1454 10:34-19946 13:34-11 7:04-458
17:11-11 11:56-8 14:39-792 9:50-15016 16:17-1439 10:34-4018 13:34-3 7:03-331
17:10-11320 11:56-4457 14:39-836 9:50-12 16:17-1454 10:33-14827 13:33-11704 7:03-451
17:10-11 11:56-2 14:39-7 9:49-6 16:17-1446 10:33-783 13:33-11303 7:01-320
17:10-3 11:55-1740 14:39-789 9:49-11 16:16-1459 10:33-774 13:31-179 7:01-443
17:10-4 11:54-3380 14:38-12856 9:49-456 16:16-1443 10:33-3662 13:31-211 7:00-557
16:16-1446 10:33-3831 13:30-11102 3:53-482
16:16-1446 10:32-11 13:29-6401 3:49-197077
16:16-1492 10:32-791 13:29-558 3:49-478

Re:Tomcat is as rock solid as it gets (1)

rubycodez (864176) | more than 3 years ago | (#34898300)

after reading the rest of hot-headed thread, here's solution I use. Big-ass reports should be done as batch requests processed elsewhere than your web front end, it's a kind of middleware, you can e-mail the user when they are done or have a status page. Only a limited set of reports should be allowed to be interactively generated, and those should have implicit limits on size of data set returned.

This solution actually pre-dates the web, I'm old. Some things are just better done with batch jobs

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34898370)

Not good. The report interface is dynamic, allows the users to change filters and ordering in real time, the entire point of this app is to do this in real time. The only problem is they are not limited on what they can do in terms of the total size of the data set. Normally even the largest requests return within 2 minutes, it's actually good enough for them.

However in cases of graphs, they can choose too many data types to be on them. For example they can choose not just brands to be on the graph, but different products under brands to be all displayed all at once for a very large time period. It's not an unusual thing and they want the result in front of them once it's compiled. Even these things return quickly enough (under 7 minutes normally). But the problem appears sometimes when they start a graph, don't wait for it to finish, change some parameters and restart the graph, etc.

The server has 16G of ram, 15G are allocated to Tomcat, so there is no memory left to do these graphs somewhere else, they actually take a lot of space as well.

I am constrained on the total memory, on CPU, on total time, basically on everything, those are hard constraints, it's not like I have a bunch of servers standing there, only one. So no middleware, nowhere even to run it, and the graph is not good if it comes too late.

Again, the question is much simpler: is there a way to time out Executor threads in Tomcat or not?

If not, then that's another reality and I have to work around it. It is possible to work around it - it's possible to stop execution of a task in the middle between SQL requests. It's possible to have do what I did sometime earlier - start an asynchronous thread for each web request, put the current thread to sleep for a small amount of time, once the time passes and first thread wakes up, check if the worker thread is done.

This way I have the time out that I can enforce - I can kill the worker thread I started.

My question is about Tomcat Executor threads - can they be killed from the app? Can they be configured to time out?

I think my question is very simple, it doesn't require anything beyond those very simple specific answers, doesn't look like people understand the questions, everybody is trying to re-architecture everything or to be a smart ass (as the rest of the thread clearly shows.)

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34898768)

Maybe instead of being an ass on /. you should just post your question to the tomcat users email list (without the attitude).

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34898912)

If you are the original asshole (all of you, ACs, look the same to me,) then go fuck yourself. You are the one who was being the ass.

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34899176)

he is not the original AC, i'm the original AC.

Re:Tomcat is as rock solid as it gets (0)

Anonymous Coward | more than 3 years ago | (#34899200)

Yeah, and I am Spartacus.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34899206)

excellent, all of ACs can go fuck themselves.

Re:Tomcat is as rock solid as it gets (1)

rubycodez (864176) | more than 3 years ago | (#34900762)

We understand the question, but the answer is your architecture is poor. Killing the user's request will only anger them, it is the wrong way, your job is to make an architecture that works and fulfills the user's request. My batch-middleware suggestion (which to your clients could be made to look the same as real-time interactive with a job-status page), could even be implemented on the same server

Large enterprise applications will generally have a multi-tier, not a two-tier, architecture for solving the problems you are having and many others.

--- sincerely, Mr. 37 years software engineering experience

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34900824)

We understand the question, but the answer is your architecture is poor.

- all architecture can be improved.

Killing the user's request will only anger them

- I have explained a bit about it, the user expectations etc. [slashdot.org]

it is the wrong way

- are you providing money to buy, maintain, support more hardware and software?

your job is to make an architecture that works

- I explained in that link. It works.

and flfills the user's request.

- and I explained in that link, it fulfills them.

My batch-middleware suggestion (which to your clients could be made to look the same as real-time interactive with a job-status page), could even be implemented on the same server

- an irrelevant suggestion. There is no difference between a middleware solution and this one, when in fact all this solution does is generating reports, that's its purpose. All of the resources of the hardware are allocated to it. Every day of the month, 12 hours a day, 50 people use it to generate reports, that's all it's used for. 1-2 times a month (once in January and once in December at this point, from memory), the thing runs out of memory and CPU due to too many abandoned threads. As I explained in that link, near all requests finish under 7 minutes. Very few finish under 10, but that's the maximum, we shouldn't allow requests to run past 15, nobody is waiting past 10 anyway.

There is nothing that middleware would provide, except slowing everybody down in 99% of cases, because it would rely on queues, it would synchronize the work, most of which doesn't need to be synchronized. The problem presented? Stopping some abandoned work threads from going past 15 minutes.

The solution given on this site? Rewrite everything. The reason? apparently 37 years of experience. Too bad none of it is in business.

Re:Tomcat is as rock solid as it gets (1)

corsec67 (627446) | more than 3 years ago | (#34902172)

What you should do is have a background worker thread, with the user making requests that the background processes, so that the interface and the heavy report creation is done in different threads/processes. Then send the user immedately to a page where they can check the status, and download the result when it is done. Since you are talking more than a minute, a browser waiting isn't a good way to do this.

(Basically, this would be like BeOS worked, with the interface in a separate thread from the application itself.)

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34906836)

Yeah, I have one application working that way, it works, my basic question around here was whether Tomcat is doing anything about it or not.

Re:Tomcat is as rock solid as it gets (1)

BeforeCoffee (519489) | more than 3 years ago | (#34899708)

@roman_mir I'm sorry you got nasty responses to your post here. I've occasionally had to deal with the same kinds of issues, and I have come to terms with how to deal with the problem. As a rule of thumb, if a response takes time to generate and you're keeping your users waiting for more than 2 or 3 seconds, that's generally a sign that that work should be done as an asynchronous activity (like with a JMS queue for offline processing and the response going out to the user by email.) I don't think Threading tricks should be a regular weapon in your arsenal for this kind of problem, not worth the twizzling and inevitable bugs. Plus threading tricks don't scale up easily, and availability is probably the most important "-ility" we should be concerned with. Not to burst your bubble, try as you might, but IMHO brute force is usually not the answer.

Even so, there IS a class of problems on the web though that take a moderate amount of time to compute, so they can still be online activities, but consume a lot of CPU. I have to guard against users holding Refresh down and clobbering my Servlet worker threads. One strategy I employ is to use a distributed in-memory cache to store response payloads. If the user hits refresh, I don't go to the backend twice if I notice that the same request has already been launched and is in-flight to the cache - I just attach that response to the that entrant in the cache and put it to sleep.

If you're writing to a ServletOutputStream and you get a ClientAbortException, that means that you're writing to a socket that the user has closed (either they hit cancel or hit refresh). Do you ever see that? Perhaps there is something clever you can do with non-blocking extensions to decouple the servlet's socket handling from the backend processing to force TCP to tell you, while you're processing is still in-flight, that the user has canceled the request? I don't know if that's possible, because I've never tried it, but it might be something fun to experiment with.

Dave

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34899838)

Yeah, I don't care about /. AC crowd, they are clowns.

As to the issue at hand, it's not about the 'refresh' button, it is just people abandoning one report to try and generate another and it's not a normal occurrence, not something that happens all the time, but 1-2 times a month, hard to spot and slows everything to a halt. Normally it happens when the users start generating yearly graphs with too many data types on them, like sales for all products within a number of brands on a comparative graph over a period of 2-3 years for around ten stores at the same time.

So even a graph like that only takes maybe 10 minutes to create, but if they decide they want to change the parameters of the graph and abandon the first one to start generating a second, a third, and we have up to 50 users at the same time, all of a sudden there is a spike that's not normal for the app, and the tasks are still all going at the same time and the system runs out of memory and starts thrashing threads it looks like.

Unfortunately cashing responses is not what I can, since every report can be generated with tens of parameters, for arbitrary sets of stores, for arbitrary periods of time, etc. Also they are aggregate in many cases, what I means is that sales are added together in the DB based on filters, so again, I can't pre-generate discrete pieces of it to just join them together for a request.

So since this happens only on rare occasions I was thinking about timing out threads that are taking too long, that's an easy cop out, maybe just time out any task that goes on for more than 15 minutes, something like that.

I used to do that earlier - the main request thread creates a worker thread and is put to sleep for a short period of time, it wakes up, checks if the worker is done, if it's not and if it's not the timeout yet, it goes to sleep again, if it's past time out, it kills the worker thread and returns with application timeout error. It works, but too bad Tomcat doesn't allow for that itself.

Re:Tomcat is as rock solid as it gets (1)

BeforeCoffee (519489) | more than 3 years ago | (#34900258)

Yeah, well, you took the bait and fed the trolls with all the cussing.

If an in-memory cache is too hard to work out, then just consider a "job" metaphor. To make a graph, you start a job. The list of currently running jobs is a global. If you detect that a job requests' parameters exactly match those of an in-flight job, you can just wait for that job to complete and return the results. Obviously, if the user changes his parameters for his second request, that would mean another job is fired off - in which case, you're in the same boat you're in now.

Whether it's your users resubmitting or a refreshing, doesn't matter: you're making your users wait too long and they think their connection has stalled so that's why they're trying again. I just hope you understand my main point, let it sink in: most users have expectations that a response should return in 1-4 seconds any click (you can thank Google for that.) Response time is a dragon you have to slay. I get that users give some apps some slack, and displaying a throbber helps, but at the outside, you should never make a user wait more than 15 or 20 seconds for any response.

But, if two or three concurrent requests can clog/kill your server, you're doing something wrong. Also, training your users that your webapp just "takes a long time" isn't a very effective approach - grumbly users will turn on you eventually. It's your job to keep users happy and keep your reputation spot-free.

I agree with the other poster, perhaps you need to invest in a BI solution. Or, take the graph generation process offline with queues and email if BI's out of your range. What you are describing does not sound workable; trust me, it's rethink time, and there's no shame in that because you're making things better.

Dave

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34900462)

Yeah, well, you took the bait and fed the trolls with all the cussing.

- wasting some time, no question about it.

If an in-memory cache is too hard to work out, then just consider a "job" metaphor.

- I have 15G of RAM, 50 users. All product definitions are cashed, but cashing all receipts from all stores and years, etc. and still to allow the container to have enough space to generate all the reports.... I'll need much more space than that, an order of magnitude more space than that.

Whether it's your users resubmitting or a refreshing, doesn't matter: you're making your users wait too long and they think their connection has stalled so that's why they're trying again.

- the users know what amount of time their reports take normally. They know which reports take a few seconds, they know that sometimes they need to wait a few minutes, that's just normal for them, they've been using the system for a year.

In our case 70% of all requests come back in under 10 seconds, 25% last between 10 and 120 seconds, the last 4.99% take up to 7 minutes and then there are odd cases, when users set up a report that normally would return in about half an hour. Our system is used to generate very large reports, in fact before this system the users could wait for their reports for many hours, sometimes days, so they are spoiled now, but not 'Google' spoiled. Saying that "I should never" make a user wait for more than 20 seconds :) Have you ever dealt with retail?

But, if two or three concurrent requests can clog/kill your server, you're doing something wrong.

- as I said, we have 50 people working in various geographical locations and this problem comes up 1-2 times a month, a very specific set of circumstances.

Also, training your users that your webapp just "takes a long time" isn't a very effective approach - grumbly users will turn on you eventually. It's your job to keep users happy and keep your reputation spot-free.

- thank you for telling me my job, but you don't know my job :) I love /.

I agree with the other poster, perhaps you need to invest in a BI solution. Or, take the graph generation process offline with queues and email if BI's out of your range. What you are describing does not sound workable; trust me, it's rethink time, and there's no shame in that because you're making things better.

- I don't know why you are talking about shame, I have no reason to get anything new to solve this problem. It would be very silly and ineffective to buy more hardware and to transition all of the reports from one system to another, when in fact the entire system is created just to generate the reports.

The only issue that exists in this system, which works fine for the 50 users we have every day of the month, 12 hours a day, is that 1 or 2 times a month too many reports are created at once that are dumped and re-created again by enough people that the VM itself starts running low on memory and CPU, and this can be easily fixed by killing a few threads that go overtime.

Imagine you own a piece of equipment that does everything you need, much better than a piece of equipment you used to have for years, it's orders of magnitude faster, it's actually distributed geographically while the old systems weren't, it is really fast compared to previous systems, yet once in a while the system goes off-line simply due to too many requests that are not done yet, but that are really just run abandoned. Imagine that you are not 'Google', you are not going to be 'Google' either. It's a normal situation.

To come to a business and say: because of this specific issue the entire system needs to be recreated in some other way, rewritten, new hardware needs to be bought, supported, etc. That's all great, but the question is simple: why? It's a silly suggestion, no offense, but it's obviously made by somebody not running a business.

Re:Tomcat is as rock solid as it gets (1)

BeforeCoffee (519489) | more than 3 years ago | (#34901402)

I bring shame into it because you obviously get snippy when anyone comes close to hitting a nerve. If you've got the architecture of last resort or whatever and your clients are just so thankful they have what they have, good for you. I've encountered plenty of examples of people like yourself in my travels and a lot of 'em can just ride that wave for years until it crashes. Hang ten.

And I do know your business. Reporting, db's, Java, enterprise apps? It's like, uhm, I've been doing that for 12 years across 5 different industry categories for the consulting firm I work for. Ha, I'm dealing with retail right now! And, I've done POS and ecommerce for retail clients in the past.

If I produced a system that had performance characteristics like what you're describing, our clients would terminate our contracts. Before consulting, I was doing C++ and assembly systems-level stuff for another 6 years. So I know what brute force looks like, and I know what finesse looks like. Don't get cocky and think you have anything special or revolutionary there, there's no secret sauce anymore.

And I can't stand it ... it's CACHING! Not cashing. Sorry, but I couldn't let that slide.

Re:Tomcat is as rock solid as it gets (1)

roman_mir (125474) | more than 3 years ago | (#34902718)

Excuse me for the less than stellar writing here, but I make mistakes even when I type in my own language, so it's not surprise that I sometimes mistype homophones.

I bring shame into it because you obviously get snippy when anyone comes close to hitting a nerve.

- the place is full of geniuses here, everybody is happy to propose a total rewrite for something that works, citing their 'tens of years of experience' as a 'sound reason' for that idiocy.

If you've got the architecture of last resort or whatever and your clients are just so thankful they have what they have, good for you.

- nice jab, totally unfounded in reality, just like the rest of the comments here.

I've encountered plenty of examples of people like yourself in my travels and a lot of 'em can just ride that wave for years until it crashes. Hang ten.

- I'd be surprised if you found many 'people like me', you have no clue, again.

And I do know your business. Reporting, db's, Java, enterprise apps? It's like, uhm, I've been doing that for 12 years across 5 different industry categories for the consulting firm I work for. Ha, I'm dealing with retail right now! And, I've done POS and ecommerce for retail clients in the past.

- yes, and I have worked in more categories than that as a contractor, but have you ever started your own business, created all of your own software from scratch? For ONE category ever? All business software in about one and a half years, including SCM that ties together stores with office with suppliers with manufacturers? Have you had to sell your solution all by yourself to more than one supplier, more than one manufacturer? Yeah.

If I produced a system that had performance characteristics like what you're describing, our clients would terminate our contracts.

- another snark remark. You have no idea what you are talking about. You have no idea how many systems are tied together to produce a solution. But you are willing to continue display your supposed 'superiority' regardless of the total ignorance about the counter-party. As I said, I love /.

Before consulting, I was doing C++ and assembly systems-level stuff for another 6 years. So I know what brute force looks like, and I know what finesse looks like. Don't get cocky and think you have anything special or revolutionary there, there's no secret sauce anymore.

- I am happy for you, but not surprised. All this experience, but nothing useful to say.

Again, I see a lot of people here, proposing the same thing: -you have it all wrong, you need a rewrite, you need this, you need that. They are all bringing up their 'experience', totally oblivious about the counter-party, totally irrelevant to the question, sounding exactly as you just expressed it - cocky, and nothing useful.

No surprise so the people in this field have such a poor rap.

So much vitriol; so few answers (1)

dereference (875531) | more than 3 years ago | (#34900376)

Basically how can execution of a thread be stopped [...]?

The short answer is that a thread can never be both arbitrarily and safely stopped. That's why Thread.stop() has been deprecated since nearly its introduction in Java. There's an official summary [oracle.com] of the reasons, linked from the API. Essentially any forcible stoppage of a thread could silently compromise the thread-safety of the entire application.

How do you even time out Executor threads after a fixed amount of time?

If your worker threads happen to by blocked on IO or something similar, or they are waiting for a synchronization monitor, then you can indeed interrupt them. However, that doesn't seem to be the case in your situation; you seem to be saying that these threads aren't waiting, they're just merrily running along, doing productive work. You want them to be arbitrarily halted after some time or some event, but that's just not possible.

In those cases, your threads are supposed to police themselves, usually by polling some external signal (set by another thread) indicating that they should give up. Since threads can't kill other threads safely, the very mechanism has been deprecated. By the way, this has nothing to do with the (relatively new) Executor threads, nor with any particular version of Tomcat.

Re:So much vitriol; so few answers (1)

roman_mir (125474) | more than 3 years ago | (#34900586)

The short answer is that a thread can never be both arbitrarily and safely stopped. That's why Thread.stop() has been deprecated since nearly its introduction in Java.

- yes, I have been working with Java since 1997, I have already discovered this, thank you, you know.

Yes, in my case the threads are not blocked, they are doing whatever work they must, running hundreds, to thousands of SQL requests, yes I absolutely can have them implement their own way of timing out because of this specific way they are doing work.

Yes, my question was about whether Tomcat is doing anything about this, providing any interfaces/interrupting listeners for it, or whether this has to be done by the application on its own. So you believe that Tomcat is not doing anything in particular to address this, I couldn't find anything in Tomcat that did it so far, so I am beginning to believe that's how it is.

Thanks again.

Have fun upgrading... (3, Funny)

MrEricSir (398214) | more than 3 years ago | (#34895714)

...by editing thousands of lines of XML files by hand in various directories!

Re:Have fun upgrading... (0)

Anonymous Coward | more than 3 years ago | (#34895720)

...by editing thousands of lines of XML files by hand in various directories!

The horror...

Re:Have fun upgrading... (1)

Anonymous Coward | more than 3 years ago | (#34895800)

...by editing thousands of lines of XML files by hand in various directories!

The horror...

Not really. The idea behind web-fragments.xml is that individual libraries can have their own configuration that the user doesn't need to bother about. So if you're upgrading from Tomcat 7 to, say, Tomcat 8 at some point, then YOU as the user only need to bother about YOUR web.xml and web-fragment.xml. The other "thousands" of web-fragment.xmls will be the headache of the individual library developers. Well, that's even worse, you might say. But then think again: why would you even need to "upgrade" your web.xml?

Even if you're upgrading from Tomcat 6 to Tomcat 7, you don't need to touch your web.xml at all. It works. web-fragment.xml is a feature, don't use it if you don't want to.

PS: Read this: http://www.tomcatexpert.com/blog/2011/01/11/field-report-tomcat-7-action. It's a little "happy", and it's all fun and games for him. TC 7 and asynchrony isn't all that fun when you actually start using it for real production software like we've been doing.

Re:Have fun upgrading... (2)

whiteboy86 (1930018) | more than 3 years ago | (#34895938)

... a virtualization nightmare, definitely not recommended for production environments, needs lots of good (expensive) hardware to tame. Also, if you are running realtime OS on some low spec. board then the resource hoggishness and unpredictability is a major show stopper.

Re:Have fun upgrading... (1)

dshk (838175) | more than 3 years ago | (#34897262)

An HTTP server running on a low spec board on a realtime OS? Quite a strange idea. This is definitely not a typical scenario for web applications. Tomcat does need some memory, e.g. half gigabytes at us, on the other hand it scales very well.

API? Servlet! (1)

Anonymous Coward | more than 3 years ago | (#34895724)

Nice to see, that the acronym API was explained, but words like "servlet", "branch", "application server", "javaserver pages" were assumed to be understood by the reader.

Person who does understand those, maybe knows what API stands for in this context.

Re:API? Servlet! (1)

The End Of Days (1243248) | more than 3 years ago | (#34898982)

Anyone who doesn't get those terms also doesn't care about Tomcat. You can consider it the knowledge equivalent of the "you must be this tall" signs at amusement parks.

Re:API? Servlet! (1)

m50d (797211) | more than 3 years ago | (#34906268)

The GP's point was that anyone who knows all that will certainly know what an API is.

OK, I can't keep up (1, Funny)

symbolset (646467) | more than 3 years ago | (#34895762)

Oracle is evil, and I'm not going with anything that they've got or derived from anything they've got in a way that they can control, no matter where it came from. I don't care if it's Sun-based or whatever. If it's got the Oracle taint on it I ain't interested. A fork that ain't beholden to them might be interesting.

So where are we at with this?

Re:OK, I can't keep up (1)

Anonymous Coward | more than 3 years ago | (#34895876)

Just swallow your pills and move along.

Re:OK, I can't keep up (4, Informative)

brunes69 (86786) | more than 3 years ago | (#34896146)

Tomcat is managed and run by the ASF, has nothing to do with Oracle.... not sure what you are going on about here.

Re:OK, I can't keep up (0)

Anonymous Coward | more than 3 years ago | (#34898252)

I think he's referring to the the fact that tomcat is written in java, whose specification is governed by Oracle - we can just pray that it will remain royalty free, or bought by Google. At least they wouldn't classify java as "middleware".

Re:OK, I can't keep up (1)

sproketboy (608031) | more than 3 years ago | (#34899338)

The sad part is he gets modded up for saying something so stupid.

Re:OK, I can't keep up (1)

m50d (797211) | more than 3 years ago | (#34906320)

But you can't use it without the Oracle JVM.

(Well, almost; the ASF's implementation may or may not work, but they can't possibly show that it does because they don't have access to the test cases and never will. There are also a couple of nominally separate implementations - but IME they are all derived from the Oracle one to the extent that they all have the same bugs).

Re:OK, I can't keep up (0)

Anonymous Coward | more than 3 years ago | (#34896726)

Oracle is evil, and I'm not going with anything that they've got or derived from anything they've got in a way that they can control, no matter where it came from. I don't care if it's Sun-based or whatever. If it's got the Oracle taint on it I ain't interested. A fork that ain't beholden to them might be interesting.

So where are we at with this?

Shut up, Stallman. Go play your recorder.

Re:OK, I can't keep up (1)

larry bagina (561269) | more than 3 years ago | (#34899494)

I believe it's actually a skin flute.

http://artinyakehidupan.blogspot.com (-1)

Anonymous Coward | more than 3 years ago | (#34895914)

thnx..

nice article....

My "Real Production" experience with TC 7 (1)

Anonymous Coward | more than 3 years ago | (#34895932)

Just wanted to share my experience of building a real production product based on Tomcat 7. We've been using it for the past 8 months, ever since the release candidate, and specifically wanted to exploit the async servlets of Servlet 3.0 spec. Jetty didn't fit what we needed, so Continuations was out.

Why did I post the background? Read this: http://www.tomcatexpert.com/blog/2011/01/11/field-report-tomcat-7-action. It's just a play-toy for articles like that, but real production use of Tomcat's asynchrony is hard and I've spent weeks trying to track down strange race conditions occurring because of that. I had dreams where I saw NullPointerExceptions at times. Maybe I'm just a bad programmer, or maybe weird shit happens with asynchrony. So be cautious before you gleefully jump into the puddle. The problems with Asynchrony nearly cost us our planned release date. It did, however, cost countless weekends and nights of mine.

That said, the development of TC 7 has been really very rapid. There was a complete rewrite of how Asynchrony works from Tomcat 7.0.2 to 7.0.3. Not something usual for a minor version change. The server itself is fast and really stable (except for a bad memory leak they fixed in 7.0.3. That cost me four days trying to find the leak when I was with 7.0.2, before checking out the TC commit logs).

The annotations support in Servlet 3.0 makes life WAY easier, no messing around with web.xml and stuff anymore to configure servlets.

So my experience has been a mixed one. It probably will get better for new folks who're using TC 7 stable; a known tradeoff for using unstable beta server is that it's unstable :-) There have, however, been no problems whatsoever with using 7.0.5. So go ahead, try it out!

Re:My "Real Production" experience with TC 7 (0)

Anonymous Coward | more than 3 years ago | (#34897314)

writing asynchronous software is harder than synchronous, harder to debug and most of the time the benefits over a synchronous solution is marginal, stay away from asynchronous code unless it is the only option to solve your problem.

Tomcat still exists? (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34896084)

I remember when 10 years ago the Apache team turned a perfectly good and working mod_jk (for apache) into a external server project (Tomcat) because the lousy performance of Java would taint their httpd's reputation in the not so competent media.

There are certainly enough "professionals" in the IT media out there who would have compared junk like IIS (without extensions) with a bloated (all modules including mod_jk) apache install.

I am amazed Tomcat still exists. Good luck!

JBoss Version Features? (1)

Doc Ruby (173196) | more than 3 years ago | (#34897136)

I'm stuck developing and deploying apps to JBoss 4.0.5.GA . I have problems when I deploy a WAR file that contains struts jars and other jars that conflict with the jars already installed in the JBoss. Is there a chart of feature comparisons between all the version of JBoss (and the underlying Tomcat) that could show which version has features to help me avoid those problems? FWIW, I use Eclipse Helios for development and testing, while another group runs ant against a build.xml I supply to deploy (and I'd like Eclipse to automatically generate and maintain the build.xml ).

Key 7.0 feature (1)

RegTooLate (1135209) | more than 3 years ago | (#34897828)

I for one welcome our non-crashing on redeploy overlord. Lots of memory leaks due to deploying and removing individual webapps are now fixed.

TOMCAT? (1)

Kuukai (865890) | more than 3 years ago | (#34898394)

I work in IT, but my heart is in 1980s Japanese pop music. Whenever I use Tomcat, I think of this [youtube.com] .

fucking pussies (0)

Anonymous Coward | more than 3 years ago | (#34901442)

Fucking pussies whining about large XML files. You can save thousands, if not 10s of thousands of lines of code, by using dependency injection, and code reuse through pluggable interfaces with filter chains.

Re:fucking pussies (1)

m50d (797211) | more than 3 years ago | (#34906336)

You can, but only by replacing them with hundreds of thousands of lines of XML.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?