Entries Tagged as 'Java'

Methods to address a slow Tomcat/Railo startup

Recently my technicians and I encountered an issue with a hosting customer who had an interesting situation between two VPS Accounts that he owns. The first VPS had a relatively quick startup time (under a minute), and the second VPS had an extremely slow startup time (above 5 minutes). Both VM's were relatively similar, and both served a great number of sites. The following are the two options that corrected the issue:


Slow Railo/Tomcat Server

Option 1

Set property in TOMCAT_HOME/conf/catalina.properties:

org.apache.catalina.startup.ContextConfig.jarsToSkip=*.jar

This will turn off jar scanning during the Tomcat startup.

Option 2

Configure the number of concurrent threads for Tomcat to use to create new contexts by adding the "startStopThreads" attribute to the <engine> tag in the Tomcat server.xml file. The number of threads should not be higher the number of CPU cores available to your server or the threads might overlap and you probably won't get the speed boost you were hoping for.

 

Once these options were implemented, both servers started up in just a few seconds.

Railo CGI remote_addr/remote_host says 127.0.0.1

When installed on to a Linux/Apache machine, the Railo installers will install mod_proxy_http as the default connector for Apache to Tomcat/Railo. The result is the same as you'd get with any other proxy, where the remote host is replaced with the address of the proxy (in this case 127.0.0.1) and the original requester's IP address is placed in the "X-Forward-For" header.

simplicityIf you need to find the original requestors IP address you can accomplish this in one of two easy ways.

Pull the IP from the X-Forward-For Header
This can be done easily using the following single line of code:

GetHttpRequestData().headers['X-Forwarded-For']

Use the Tomcat Remote IP Valve
This can be done simply by opening up your Tomcat server.xml file and adding a single line of code right under your "<Engine>" tag:

Change this:

<Engine name="Catalina" defaultHost="127.0.0.1">

To this:

<Engine name="Catalina" defaultHost="127.0.0.1">
<Valve className="org.apache.catalina.valves.RemoteIpValve" />

Restart Tomcat and you'll now see the IP address of the original requesting client populate your CGI scopes.

The Latest mod_cfml Update is Actually Pretty Important

For those of you who may not follow these things, users of the open-source CFML context creation software known as "mod_cfml" should know that the latest release is actually pretty important with regards to security. The mod_cfml software is a group of programs that work together in order to automate the process of creating contexts within Tomcat. Usually the process of creating contexts is a manual job, which is accomplished by editing various configuration files in order to tell Tomcat where to find the files for specific sites and directories (or contexts) when Tomcat receives requests for them. The idea behind mod_cfml is to simplify server management, and make creating contexts in Tomcat happen automatically by passing off configuration information from Apache or IIS to Tomcat so a new context can be made if it doesn't exist yet. Pretty basic stuff.

ddosThe problem is that, before this latest release, this process of automating the context creation using mod_cfml could be exploited to create a Denial of Service attack on the system that is running mod_cfml. Using a specially crafted attack that is targeted at mod_cfml, an attacker could potentially issue multiple requests in rapid succession to a vulnerable system. This process would cause many contexts to be created simultaniously, and could potentially overload and/or crash the server.

The newest version of the mod_cfml Tomcat Valve corrects this problem by adding limitors to how quickly new contexts could be created, and how many contexts can be created within a single day time frame. These limitors protect users from the danger that previously existed and the possibility of a DoS attack that specifically targets this issue.

You can install the latest mod_cfml Tomcat valve by shutting down Tomcat, removing the mod_cfml Tomcat valve from the [tomcat]/lib/ directory, and dropping the latest mod_cfml Tomcat valve back into the [tomcat]/lib/ directory. Now, restart Tomcat and you're good to go. Documentation on adjusting the new limitors in the Tomcat valve can be found here:

http://www.modcfml.org/index.cfm/documentation/modcfml-tomcat-valve/config-options/

Railo users who have installed Railo 4.0.3 or newer will already have the latest version of mod_cfml, and OpenBD installers version 3.0 and up will have the latest release. If you are running with an earlier release and haven't updated your mod_cfml Tomcat Valve, you should consider doing so.

How To Fix Windows Java Error 1723

Just recently I experienced a problem with both installing or uninstalling Java (the JRE) on a Windows 2003 system. I had to research this quite a bit and there were no clear answers anywhere, so I though I'd post here on how I was able to fix it. In my case, I was using Windows Server 2003 64-bit, but this should apply to other Windows versions as well.

Windows JRE Error 1723The error I was getting was as follows:

"Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor."

This error is caused when you delete the JRE directory without running the uninstallation program. The reason this causes a problem is due to the registry entries that the installer creates when the JRE is installed. There is a DLL that the installer uses to make (and remove during an uninstall) the registry entries. Without this DLL, both the install and the uninstall will fail. This error may also prevent you from installing updated versions of the JRE to your system - which is a security risk.

You can find the path to the DLL that the installer (or uninstaller) is looking for in your Application log. You can get to your Application log (at least on a Windows Server 2003 system) by going to Start - Administrative Tools - Event Viewer, and then selecting Application from the list on the left.

Once you're looking at the Application log, find the error message generated from the "MSI Installer" (It's probably the most recent error there if you just encountered the error.) and bring it up. In the "Description" text area, you should be able to see where the installer or uninstaller was looking for the DLL file it needs. This is important because it will tell you how to fix it.

Finding the DLL

The FIX:

The Fix for this is to give the uninstaller what it wants, and replace the deleted DLL files with ones that can be used by the install/uninstall process to edit the registry, etc. For convenience, I've uploaded a bin zip file that can be used for this purpose.

DOWNLOAD: => bin.zip  (md5: b2594fa66d12a9e8fafb0a1ba3ca555f)

In my case above, you can see where I installed the JRE to the desktop (and then probably deleted it to remove the clutter). Only later, when I tried to install a new version, did it become a problem. So, I downloaded the above zip file, extracted it to my desktop, created a "jdk" directory and moved the "bin" folder inside it, then ran the uninstaller again. I got a few more errors about other files that couldn't be found, but the uninstaller worked and I was able to install an updated version like I wanted to afterwards.

So... the next time you install the JRE or JDK, remember that you can't delete it by hand without problems!

Hope this helps!

-Jordan

metre