AO Logo
 English Japanese
Developer Tools
Life Cycle
Company Info
AOServ Platform
Data Centers
Client Area
Contact Us
AO Industries, Inc.
Application Infrastructure ProviderApplication Infrastructure Provider
Sign Up What's New Client Area Contact Us Site Map
your location:   home page···what's old
What's Old
See What's New instead.

Date Description

Created a new servlet filter to automatically strip invalid XML characters from all inputs. GET requests are 301 redirected to a URL with the characters stripped. POST, and all other methods, are simply filtered and passed along to the rest of the application.

We have added this new filter to all JSP-based web applications we are currently maintaining.

Please see com.aoindustries.servlet.filter.StripInvalidXmlCharactersFilter for more information.


Separated our set of reusable servlet filters into their own project. Please see the new ao-servlet-filter project at Downloads.


The default Tomcat maxPostSize setting of 2 MiB is too small for real-world data, such as pictures from modern digital cameras. We have specified a maxPostSize of 16 MiB for all Tomcat 6, 7, and 8 installations.

Please see Apache Tomcat 8 Configuration Reference, Common Attributes for more information.


We now support PHP 5.6 in both 32-bit and 64-bit builds. We have compiled PHP against PostgreSQL 9.4 and MySQL 5.7.

In this build we have switched to the 2.* version of the HTTP extension. Older applications may need to be updated for this change before switching to PHP 5.6.


We now support MySQL 5.7 in both 32-bit and 64-bit builds.


We now support PostgreSQL 9.4 in both 32-bit and 64-bit builds. We have included the following modules in our build:

  1. cube - Used by the earthdistance module.
  2. earthdistance - Allows spatial indexing of geographical coordinates - (latitude, longitude) pairs.
  3. tsearch2 - Backwards compatibility for applications developed for versions of PostgreSQL prior to 8.3.

We are now using Stripe for our credit card processing. Sage Payments has served us well over the years and may remain a good option for some merchants, but we are attracted to the more predictable fee structure of Stripe.


Our family of sites are now all running 100% over HTTPS. Previous releases of our system supported a mixture of HTTP and HTTPS. Now all communication is encrypted for maximum security.


We have increased our port speed with Hurricane Electric at our Fremont, California data center from 100 Mbps to 1 Gbps. With this upgrade and related renegotiation, we are able to pass on lower bandwidth rates. So, if you have some steaming media or higher resolution images that you have been hesistating to post due to bandwidth cost concerns, open the flood gates and let the data flow.

Please see Fremont, CA Bandwidth Rates for updated rates.


Working with straight JDBC in a robust way can be very tedious. Granted, there are many different ways to represent databases using frameworks and abstractions above JDBC, but sometimes you just want to access or manipulate a database with a simple, direct, and intuitive mechanism. Our com.aoindustries.sql package meets these requirements.

We have recently added an alternate constructor to be able to create a com.aoindustries.sql.Database instance providing it a instance of javax.sql.DataSource. This combination works well with data sources configured in our Web Sites Control Panel and accessed using JNDI.


Since our inception in late 1999 and our initial entry to commercial web hosting in mid 2000, we have provided full source code to the aocode-public Java library. This is our catch-all bag of tricks for any code that may be useful to others and requires no external dependencies. This code is heavily used in our projects and well tested and supported.

It has been our intent all along to allow anybody to use this code for any project. Our licensing, however, did not make this clear. We have released the latest versions of aocode-public and the related ao-taglib under the GNU Lesser General Public License Version 3.


We have created a simple, efficient auto-escaping JSP taglib. The basic premise is to let the tags do the work. The tags interoperate to properly escape data and code, even in complex situations. For example, it is easy and natural to embed arbitrary data from a database into a JavaScript string, contained in a multi-line script inside the onclick attribute of a button. In fact, through careful encoding that tags maintain binary transparency from Java through to JavaScript in this scenario.

The ao-taglib is available for download:

It depends on the aocode-public library:


The Payflow Pro connector for our Processor-Neutral Java Credit Card Processing API has been updated to use PayPal's Payflow SDK version 4.3.1. Please download the updated ao-credit-cards library from the following links:


Our monitoring system now watches all MySQL replications and alerts administrators when replication is delayed or halted.


We have added a routine CHECK TABLE `table_name` FAST QUICK of all MySQL tables to our monitoring systems in order to automatically recover MyISAM tables after an unexpected shutdown. MySQL installations with a typical number of tables will be checked once every five minutes while those with many tables will be scanned less frequently. Administrators will be alerted when any table is in need of manual repair.


We have greatly increased the scalability of our generic pooling code AOPool and its derivative AOConnectionPool. The old version dated back to 1999 and was designed for a relatively low number of connections (in the hundreds) across low-latency links. Over the years, our AOServ management software installation has become larger and more distributed. The system now maintains pools of thousands of connections over higher latency links. This usage pattern exposed the weaknesses in the old, simple design and implementation.

The new version uses many Java features not available in version 1.1, such as generics, AtomicLong, HashSet, PriorityQueue, and ThreadLocal. The improved connection pool data structures, combined with more fine-grained locking, provides a more scalable connection pool.


We have added support for MySQL 5.1. The two most compelling reasons we have found to switch to MySQL 5.1 are mixed-mode replication and table partitioning.

Prior to mixed-mode replication, replication was performed using either statement-based or row-based logging, each having its own limitations. When using statement-based replication, developers had to be concerned about any statement that may yield different results between the master and slave. They also had to be cautious about statements that may not work correctly when the slave restarts - namely temporary tables. This places more of a burden on the application developers to avoid these pitfalls.

Mixed-mode replication doesn't solve both of these issues, but it puts a big dent in the first, and more common, issue. When configured to use mixed-mode replication, statement-level replication will be performed until MySQL determines that a statement includes something that may yield different results between master and slave, such as the UUID function, then it switches to binary replication for the remainder of the transaction. Ideally, you get the replication efficiency of statement-based logging and the accuracy of row-based logging.

Finally, table partitioning allows a single table to be split behind the scenes into multiple pieces, or partitions. This allows for greater lock granularity and distribution of a single table across multiple filesystems, which implies multiple block devices, logical volumes, physical volumes, RAID devices, physical media… Together this means higher levels of scalability and concurrency. This is especially important for heavily updated MyISAM tables.

Our standard server hardware currently consists of eight CPU cores, 32 GB of RAM, and a total of 18 hard drives (two internal Xen Dom0 OS drives and 16 hot-swap drives for Xen DomU OS data). Our next generation of machines will provide even more cores, RAM, and storage. Table partioning helps MySQL scale with our virtual servers, which currently range from 256 MB RAM with 30 GB storage all the way up to 32 GB RAM with 16 TB on 7200 RPM disks or 4.8 TB on 15000 RPM disks.

We can install a MySQL 5.1 instance on a separate port to not interfere with any running 4.0, 4.1, or 5.0 installations. This allows time for testing, benchmarking, tuning and migration. Please submit a customer support ticket if you would like MySQL 5.1 enabled on your servers.


We have added the ability to connect directly to virtual server consoles/desktops using VNC. One may use either the Java applet provided in our control panels or any SSL-enabled VNC client of their choice. The Java applet and VNC connection details are provided in the Remote Desktop Control Panel.

This type of direct desktop/console access is important because it is outside the virtual server and does not depend on any aspect of the guest operating system. The virtual servers are accessible even if their networking is disabled. In fact, one may use these connections to reboot servers, safely reconfigure networking, and even install or upgrade operating systems.


We've switched our site over to XHTML 1.0. We are using the Strict DOCTYPE to make any deviations from the standards more immediately noticeable, so if you see anything strange please let us know. We are currently serving the pages as MIME type text/html to all clients to avoid the XML validation. After a couple of months with HTML Validator not reporting any problems we will enable the application/xhtml+xml MIME type for compatible browsers.

We have also changed the character encoding on our entire site to UTF-8. This should help when performing tasks with non-Latin characters, such as dumping databases from the MySQL control panels. Previously our site would use ISO-8859-1, Shift_JIS, or UTF-8 depending on which internal framework the page uses (the older aoweb-framework or the newer aoweb-struts) and which language was active.


You may now manage stored credit cards in order to configure them for automatic monthly payments or expedite manual payments. We have also developed a new payment form allowing the use of stored cards, connecting to the bank immediately for transaction results, and providing the option of storing cards during the payment process.

These forms run on top of a bank-independent Java credit card processing API. This API simplifies the process of connecting to merchant services. It also allows applications to be developed against a consistent interface, while we provide connectors for different banks. This results in an application being able to switch merchant accounts quickly and easily.

If supported by the merchant services provider, the Java API enables securely storing credit cards and initiating transactions using the stored cards. This facilitates Payment Card Industry (PCI) compliance by eliminating the need to store credit card numbers for any reason. We use this mechanism for our stored card manager.

Finally, we will soon be providing merchant services to round-out our services. Combining our merchant services with these supported Java APIs will greatly simplify the process of obtaining merchant services and integrating card processing to applications. However, you can be assured of no vendor or provider lock-in because we provide the source code for the Java API, and the API is designed to allow applications to easily switch providers.


We now support MySQL replication as an extension to our existing file-based fail-over systems. With this option, all files are replicated by scanning the filesystem periodically while MySQL database contents are replicated, near real-time, to the fail-over server(s). Transactions will typically be replicated within a second. This results in little or no transactional data loss in the event of a catastrophic hardware failure.

We have also developed a monitoring interface allowing our clients to see the current state of the MySQL replication(s).

Those who subscribe to Managed Servers may request this additional feature either during sign up or by requesting the option through our support channels.

We have been performing operating system upgrades on all virtual hosting servers. The most significant change for customers is an upgrade to Apache 2.0. We will start upgrades of managed servers in November.
We have added TXT entries to our DNS Control Panel in order to support SPF records.
We have expanded our Web Sites Control Panel to allow the configuration of parameters and data sources on a per-context basis.
We now support the latest MySQL 4.1 and 5.0.
We have installed ZendOptimizer 2.6.2. It is not yet turned on by default. Those who would like to try it, please contact us to have it enabled. In our benchmarks, it provided about 25% more throughput.
We now support the lastest PostgreSQL version 8.1.2. Anybody needing this version on either virtual hosting or managed servers, please contact us to have it configured.
We have installed the latest of PHP 4.4 and PHP 5.1. We no longer support PHP 4.0, 4.2, 4.3, and 5.0. Those using now-unsupported versions have been upgraded.
We have improved our firewall rules in three significant ways:
  1. All services must be registered with AO Industries and opened on our firewall prior to clients being able to connect. Previously, any service on ports above 1024 were allowed unless blocked. We have switched to a block-unless-allowed policy for all ports.
  2. All servers now route their packets through our firewalls, even when on the same network. Previously all servers on the same physical network had unfiltered access to other servers on the same physical network, where each physical network is comprised of servers of the same type (virtual, dedicated, managed, colocation, ...). Now, each server is isolated from one another by the firewalls just like they are isolated from other networks. This has somewhat reduced the efficiency of inter-server communication, but we believe the loss of efficiency is well worth the added security.
  3. We have restricted all outbound UDP traffic from all of our networks. If you need to provide of access any UDP service please contact us with the specific list of IP addresses and ports you will need to allow access to or from.
We are happy to announce the installation and support of AWStats, Java 5, and Tomcat 5.5.


Many of you have noticed that we turned off Analog reporting a couple of months ago on some servers due to Analog causing high load averages. We have now integrated AWStats into our Control Panels. We have parsed all log files back about one year. You may see your reports in our HTTP Servers Control Panel, or at this URL:

Java 5:

Java 5 may be used for any existing application by updating your profile script to include /opt/aoserv-client/scripts/ See this FAQ for more details on how to change Java versions:

Tomcat 5.5:

New sites may now be created running Tomcat 5.5. We cannot upgrade existing sites automatically. So in the case of an upgrade please create a new installation (Web Sites Control Panel), install your content, test, and then switch the DNS settings to the new IP address.

We have reduced the number of cache invalidation signals being sent from the AOServ Master to the AOServ Clients. Previously, certain API calls would result in all connected clients being notified of the update. This would result in all servers verifying their configurations concurrently, causing a short-term, high load on the master server.
We have completed our new Reseller Package Builder. This new tool allows our resellers to define custom packages. Once approved by AO Industries, the package definitions may be used for new accounts.
As part of our operating system upgrades, we are now running SpamAssassin 3. SpamAssassin 3 will help us keep up with the latest efforts of bulk mailers.

We have also greatly improved the performance of the IMAP server when training the SpamAssassin Bayesian filters. Previously the IMAP server would directly call sa-learn, the SpamAssassin Bayesian filter training tool, and only complete its task when the sa-learn process completed. Now the IMAP server places a copy of the relevant messsages into a temporary directory, and another processes trains SpamAssassin in the background. As far as a user can distinguish, our modified IMAP server is now as fast as an unmodified server.

When an email inbox has its SpamAssassin integration mode set to "POP3", any emails considered to be junk by SpamAssassin will now have "*****SPAM*****" prepended to the subject lines.

The required_score may now be set on a per-inbox basis in either our Email Inbox Control Panel or WebMail Interface. Our default value of 3.0 is fairly aggressive. Individuals who want less chance of valid emails being flagged as junk may raise this value to 5.0 or 10.0.
Upgraded our MySQL installation to MySQL-Max to support InnoDB and transactions.
Our WebMail interface now supports nested IMAP folders and is more tightly integrated with our new SpamAssassin installation.
We have now implemented SpamAssassin on all of our servers. We have also modified our IMAP server to automatically train the Bayesian filters for SpamAssassin based on email use. Please see our Anti-Spam FAQ for more details.

See What's New instead.
Copyright © 2000-2019 AO Industries, Inc.