People are still discovering the benefits of the free tool from VMware SpringSource, called Spring Insight Developer. This post provides an explanation of what Spring Insight Developer does, how to set it up with Apache Tomcat, and an example of available plugins. For a better visual, there is also a video of the new Spring Insight 1.8.3 GUI embedded below.
Spring Insight is an extremely useful, time-saving, free tool for Spring developers and also has plugins for Grails, GemFire, Hadoop, Hibernate, JMS, JNDI, LDAP, MongoDB, RabbitMQ, Redis, Spring Batch, Spring Integration, Tomcat, and many more on Github. In the latest release of Spring Insight, VMware introduced a new "split-agent" architecture that will enable this tool to be extended to more runtime languages besides Java, such as .NET, Ruby, PHP, Python, etc. There is also a bounty program where you can get paid to develop new plugin or offer to pay others.
In a nutshell, Spring Insight Developer lets you see what your code is doing. When, as a developer, you press a button in your application’s GUI, you can see what Java code is invoked, how it translates into SQL, and quite a bit more. Before we show it in action, it’s worth mentioning a few of the benefits.
Let’s take a look at a simple example of tracing your app, viewing the details, and seeing the code in action.
Traditional Java EE (JEE) app servers bring complexity to the mix. In addition, they are costly and consume a lot of resources. Forrester wrote an article in 2011 about the costs saying, “Use Apache Tomcat. It is free.” IDC’s research from 2011 points how enterprises are moving “toward lower-cost application platforms that shift them closer to private, public, and hybrid cloud offerings.” Of course, you can find plenty of historical posts and debates from practitioners on costs and resources from past years.
So, if you are looking at middleware support for mobile apps, in-memory databases, auto- scaling, and virtual/cloud infrastructure, then you might want to check out our webinar coming up on Thursday, October 25th. In this session, we will cover quite a bit about vFabric tc Server:
Tomcat supports multiple instances, and you should consider installing Tomcat so that a single binary runtime directory supports multiple instances as a means of adhering to security best practices.
While the documentation on multiple instances is in the RUNNNING.txt file at the root of the Tomcat binary distribution file hierarchy, many people aren’t necessarily aware of the feature or why you might use it. To provide some insight, let’s look at how this functionality works and provide some insight to the related best practice for security.
Secure Socket Layer, or SSL, certificates are frequently used to confirm the identity of a server before consuming its services and to secure communications with the server. Typically, when an Apache web server is used to load balance requests to one or more Apache Tomcat servers (including VMware’s commercial version, tc Server), the SSL encryption and certificate authentication is terminated at the web server. Communication between the Apache web server and Tomcat is then trusted and in clear text.
However, there are organizational security policies and B2B scenarios that could mandate secure communication between Apache web server and Tomcat. Furthermore, it could be important to restrict access to Tomcat to known instances of Apache web server.
This tutorial will provide details for a configuration option that enables SSL communication and client certificate authentication between Apache Web Server and Tomcat.
At a high level, this tutorial provides instructions to
We are having issues with tomcat on production. Tomcat hangs on production and doesn’t respond to new http requests.
7.0.11 was a very early release and most likely you are running into a bug. I would upgrade to 7.0.27. Even in that release, there are reports of the system hanging -
The bug above shows how a newly introduced feature in Tomcat 7, has had an issue in all released versions.
There are a few work arounds
For development and operations teams, a presentation that covers undocumented secrets of Apache Tomcat with various tips and tricks for managing Tomcat.
Do you spend too much time sifting through Google results to find answers to your Apache Tomcat Questions? Now is your chance to learn undocumented secrets of Apache Tomcat. If you are using or considering using Apache Tomcat and would like to improve your knowledge, join Apache experts and committers Mark Thomas and Filip Hanik as they outline the top Tips and Tricks to make management and administration of Apache Tomcat easier, faster and more productive.
EMBEDDED PRESENTATION SLIDES (i.e. user can click “Next” thru slides)
Our configuration consists of the following components (all of them are running on a single Windows Server 2003 machine):
We are load testing the server with relatively simple requests.
It seems that under load (~8000 requests we are sending per minute from our load simulator) - we have a delay between apache web server and the mod_jk component.
Make sure you configure both Apache httpd and mod_jk to handle the traffic.
This means, the number of threads(workers) that httpd has will impact your system.
Also, in high concurrency, how you configure KeepAlive is important. There is a chance that Apache is using its threads waiting for the next request on idle connections, while active connections are not being handled.
Posting your configuration files may be a good idea.
Hi, I have Tomcat 5.0.28 running on more than one client with a SSL connector that allows identification with spanish certificates FNMT, DNIe and Camerfirma (among others).
The first thing to note is that you are currently running an unsupported version of Tomcat, which in Apache terms means that it's extremely unlikely to get any more upgrades or patches. It's in beta now, but a stable release of Tomcat 7.0 is likely to happen towards the end of this year, which will put you a full 3 versions behind the current release.
A detailed answer to the question requires more information, such as the exact versions of the server operating system, the JVM type and version, how you've configured the SSL connector and whether you're using APR or not.
This type of problem most often appears when a client has unexpectedly terminated the request, or disconnected before the request has completed, implying that the source is at the client end of the connection - it's often an unintended consequence of a user deciding to view a different page before a previous request has finished.
In your case, you state that some clients are not having the same problem; in order to track down the source you should monitor the access, error and application logs and match individual requests to the log entries. Look for commonalities between source IP address, User-agent and try to get exact details of the environment of the client which has identified the problem. If there is definitely only one client experiencing the problem, then you'll need to determine what's different about their configuration. It's possible that there's nothing wrong with your application, but that a server or network misconfiguration is the cause of the fault.
Even recent releases of the Sun JDK/JRE don't have all of the Certificate Authorities in use currently, which is another possibility for the cause - though I wouldn't expect to see a connection reset event as a symptom - but still, check the client isn't using a certificate from a new CA.
I can't guarantee it would make any difference, but I'd strongly recommend putting a testing and deployment plan together to bring your environment up to reasonably current versions, particularly as there are vulnerabilities in SSL which are likely to unpatched in the setup you describe. Tomcat 5.5 should be the minimum version you're running on, if upgrading the JVM to a recent version is a problem.
Setting up Apache Web Server and Tomcat Application Server for load balancing using mod_proxy_balancer.
This example uses mod_proxy_balancer as the load balancer. This configuration is useful for applications that are stateless and therefore do not require clustering or sticky-sessions. For more information, you can also check the page:
What led to my use of Tomcat started years before I had ever heard of Jakarta or Tomcat. I think it was late 1999 or early 2000 and inside E*TRADE there was a lively discussion going on for weeks in our hallways, in the conference rooms, and over email about standardizing on either servlets or enterprise java beans (EJB). I was crazy busy trying to get single sign-on and application federation server infrastructure installed at the time and was just hoping that the EJB/Servlet issue would resolve without any violence. The java application team standardized on servlets and the the resulting products were highly successful!
Around 2001, many of our peers in the industry went with EJBs and were having failed project after failed project. Our servlet-based software was running great, but was too expensive as we were on proprietary frameworks deployed over many nodes. To address costs we moved to open source, with Tomcat being a central part of that strategy. At that point, we really started feeling like we dodged a bullet by not adopting EJBs.
Open source EJBs were years away from being deployable and commercial ones were sketchy. Remember, this was the time of the PetStore reference EJB app and all of the theater around it. If you don’t remember PetStore, it's the app that made .NET look fantastic and allowed SpringSource to become a $362 million company!