Issue #378 has been resolved, culminating in the 3.1.* releases of the memcached extension, which have allowed us to activate it in our PHP 7.3 build.

We have updated the memcached extension from version 3.0.4 to version 3.1.3 for our PHP 7.0, PHP 7.1, PHP 7.2, and PHP 7.3 builds.

PHP 7.0 will be end-of-life on 2019-01-10 per PHP: Supported Versions.

The following versions of PHP will be supported at the time PHP 7.0 becomes end-of-life:

1. PHP 5.4 (CentOS 7)
2. PHP 7.1
3. PHP 7.2
4. PHP 7.3

Please review the following migration guides in preparation for this upgrade:

1. Migrating from PHP 7.0.x to PHP 7.1.x
2. Migrating from PHP 7.1.x to PHP 7.2.x
3. Migrating from PHP 7.2.x to PHP 7.3.x

We will communicate with you individually to coordinate any required upgrades before PHP 7.0 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of PHP 7.0 to PHP 7.1.

We will carefully review all php.ini files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

We have enabled the citext module in all our active PostgreSQL builds:

• PostgreSQL 9.4: citext
• PostgreSQL 9.5: citext
• PostgreSQL 9.6: citext
• PostgreSQL 10: citext
• PostgreSQL 11: citext

We have improved our packaging of Apache Ant:

1. Added Provides "ant" to SPEC file.
2. Now including library dependencies per installation recommendations.
3. Added environment variable ANT_HOME to profile scripts.

PHP 7.1 will be end-of-life on 2019-12-01 per PHP: Supported Versions.

The following versions of PHP will be supported at the time PHP 7.1 becomes end-of-life:

1. PHP 5.4 (CentOS 7)
2. PHP 7.2
3. PHP 7.3
4. PHP 7.4

Please review the following migration guides in preparation for this upgrade:

1. Migrating from PHP 7.1.x to PHP 7.2.x
2. Migrating from PHP 7.2.x to PHP 7.3.x
3. Migrating from PHP 7.3.x to PHP 7.4.x

We will communicate with you individually to coordinate any required upgrades before PHP 7.1 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of PHP 7.1 to PHP 7.2.

We will carefully review all php.ini files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

We now support PostgreSQL 11. 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.

We now support Java 11.

Java 11 may be used for any existing application by updating your profile script to include /opt/jdk-11/profile.sh (for Bourne shells) or /opt/jdk-11/profile.csh (for C shells). See this FAQ for more details on how to change Java versions:

/clientarea/FAQ.ao?category=jvms&page=profile

This is a LTS version and is expected to be supported until September 2023.

In this version, we have switched to the OpenJDK builds. We are no longer using the commercial build from Oracle.

PHP 5.6 will be end-of-life on 2018-12-31 per PHP: Supported Versions.

The following versions of PHP will be supported at the time PHP 5.6 becomes end-of-life:

1. PHP 5.4 (CentOS 7)
2. PHP 7.1
3. PHP 7.2
4. PHP 7.3

Please review the following migration guides in preparation for this upgrade:

1. Migrating from PHP 5.6.x to PHP 7.0.x
2. Migrating from PHP 7.0.x to PHP 7.1.x
3. Migrating from PHP 7.1.x to PHP 7.2.x
4. Migrating from PHP 7.2.x to PHP 7.3.x

We will communicate with you individually to coordinate any required upgrades before PHP 5.6 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of PHP 5.6 to PHP 7.1.

We will carefully review all php.ini files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

Java 10 will be end-of-life in September 2018 per Oracle Java SE Support Roadmap.

Please review the following resources in preparation for this upgrade:

1. JDK 11

Once end-of-life is reached:

1. Applications that use /opt/jdk-current/profile.* will switch from Java 10 to Java 11 on their next restart.
2. For all managed servers, we will replace /opt/jdk-10/profile.* with /opt/jdk-11/profile.*. We will also restart all applications currently running Java 10, so their profile scripts can select a newer version of Java.

As usual, we will perform these updates during your scheduled maintenance times.

We now support Python 3.6.

Python 3.6 may be used for any existing user or application by updating your profile script to include /opt/python-3.6/profile.sh (for Bourne shells) or /opt/python-3.6/profile.csh (for C shells).

We now support Python 3.4.

Python 3.4 may be used for any existing user or application by updating your profile script to include /opt/python-3.4/profile.sh (for Bourne shells) or /opt/python-3.4/profile.csh (for C shells).

Please note that Supported Versions is 2019-03-16. Please consider going to Python 3.5, Python 3.6, or Python 3.7 now.

We now support Tomcat 9.0 in both single-site and multi-site configurations. We have included the latest PostgreSQL JDBC Driver built for Java 8. We have also included the latest MySQL JDBC Driver 8.0.*.

We now support PHP 7.2. We have compiled PHP against PostgreSQL 10.

We now support PHP 7.0. We have compiled PHP against PostgreSQL 9.4.

We now build with mysqlnd instead of depending on MySQL native libraries.

We have removed the dbase extension from this build. If this extension is required by your application, please contact us.

In this build, we have made the following changes to extension versions:

1. memcached extension is now 3.*
2. propro extension is now 2.*
3. raphf extension is now 2.*
4. HTTP extension is now 3.*

Older applications may need to be updated for these extension version changes before switching to PHP 7.0.

For both efficiency and security, we have switched to a more modular build of PHP, where some of the built-in extensions are built as shared libraries, packaged as separate RPMs, and only installed and enabled as-needed on a per-Apache/per-site basis. This means some extensions that were on by default in PHP 5 are now off by default in PHP 7.

We moved the default php.ini file from /opt/php-X.Y/lib/php.ini to /etc/opt/php-X.Y/php.ini, where X and Y are the major and minor versions, respectively.

We have also enabled Scan Directories with a default of /etc/opt/php-7.0/conf.d. For mod_php, this is overridden to /etc/httpd/conf/php[@instance]/conf.d for per-Apache configuration. For CGI, this is overridden to /var/www/site_name/webapps/ROOT/cgi-bin/php.d for per-site configuration.

We now support PostgreSQL 10. 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.

We now support PostgreSQL 9.5. 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.

Tomcat 8.0 is now end-of-life.

The following versions of Tomcat are currently supported:

1. Tomcat 7.0
2. Tomcat 8.5
3. Tomcat 9.0

Please review the following migration guides for this upgrade:

1. Tomcat 7.0.x Migration Guide
2. Tomcat 8.5.x Migration Guide
3. Tomcat 9.0.x Migration Guide

We now support in-place Tomcat upgrades to Tomcat 8.5 and above. This capability is available in AOSH through the following commands:

• set_httpd_shared_tomcat_version (for a Multi-Site Tomcat JVM)
• set_httpd_tomcat_std_site_version (for a Standard Tomcat JVM)

After performing the upgrade, please refer to the README.txt file in either /var/opt/apache-tomcat/…/README.txt (for a Multi-Site Tomcat JVM) or /var/www/…/README.txt (for a Standard Tomcat JVM). The README.txt file includes details about the auto-backup files named *.bak along with a generated command you may use to clean-up the backup files.

For all managed servers, we are upgrading any remaining uses of Tomcat 8.0 to Tomcat 8.5.

We will carefully review all *.bak files to maintain any customizations through the upgrade. Applications will be restarted, possibly more than once, during this process.

As usual, we will perform these updates during your scheduled maintenance times.

Java 10 will be end-of-life in September 2018 per Oracle Java SE Support Roadmap.

Please review the following resources in preparation for this upgrade:

1. JDK 11

Once end-of-life is reached:

1. Applications that use /opt/jdk-current/profile.* will switch from Java 10 to Java 11 on their next restart.
2. For all managed servers, we will replace /opt/jdk-10/profile.* with /opt/jdk-11/profile.*. We will also restart all applications currently running Java 10, so their profile scripts can select a newer version of Java.

As usual, we will perform these updates during your scheduled maintenance times.

Tomcat 8.0 will be end-of-life on 2018-06-30 per End of life for Apache Tomcat 8.0.x.

The following versions of Tomcat will be supported at the time Tomcat 8.0 becomes end-of-life:

1. Tomcat 7.0
2. Tomcat 8.5
3. Tomcat 9.0

Please review the following migration guides in preparation for this upgrade:

1. Tomcat 7.0.x Migration Guide
2. Tomcat 8.5.x Migration Guide
3. Tomcat 9.0.x Migration Guide

We will communicate with you individually to coordinate any required upgrades before Tomcat 8.0 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of Tomcat 8.0 to Tomcat 8.5.

We will carefully review all server.xml and web.xml files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

PHP 7.0 will be end-of-life on 2019-01-10 per PHP: Supported Versions.

The following versions of PHP will be supported at the time PHP 7.0 becomes end-of-life:

1. PHP 5.4 (CentOS 7)
2. PHP 7.1
3. PHP 7.2
4. PHP 7.3

Please review the following migration guides in preparation for this upgrade:

1. Migrating from PHP 7.0.x to PHP 7.1.x
2. Migrating from PHP 7.1.x to PHP 7.2.x
3. Migrating from PHP 7.2.x to PHP 7.3.x

We will communicate with you individually to coordinate any required upgrades before PHP 7.0 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of PHP 7.0 to PHP 7.1.

We will carefully review all php.ini files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

Tomcat 8.0 will be end-of-life on 2018-06-30 per End of life for Apache Tomcat 8.0.x.

The following versions of Tomcat will be supported at the time Tomcat 8.0 becomes end-of-life:

1. Tomcat 7.0
2. Tomcat 8.5
3. Tomcat 9.0

Please review the following migration guides in preparation for this upgrade:

1. Tomcat 7.0.x Migration Guide
2. Tomcat 8.5.x Migration Guide
3. Tomcat 9.0.x Migration Guide

We will communicate with you individually to coordinate any required upgrades before Tomcat 8.0 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of Tomcat 8.0 to Tomcat 8.5.

We will carefully review all server.xml and web.xml files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

Tomcat 6.0 is now end-of-life.

The following versions of Tomcat are currently supported:

1. Tomcat 7.0
2. Tomcat 8.0
3. Tomcat 8.5

Please review the following migration guides for this upgrade:

1. Tomcat 7.0.x Migration Guide
2. Tomcat 8.0.x Migration Guide
3. Tomcat 8.5.x Migration Guide

For all managed servers, we are upgrading any remaining uses of Tomcat 6.0 to Tomcat 7.0.

We will carefully review all server.xml and web.xml files to maintain any customizations through the upgrade. Applications will be restarted, possibly more than once, during this process.

As usual, we will perform these updates during your scheduled maintenance times.

Tomcat 6.0 will be end-of-life on 2016-12-31 per End of life for Apache Tomcat 6.0.x.

The following versions of Tomcat will be supported at the time Tomcat 6.0 becomes end-of-life:

1. Tomcat 7.0
2. Tomcat 8.0
3. Tomcat 8.5

Please review the following migration guides in preparation for this upgrade:

1. Tomcat 7.0.x Migration Guide
2. Tomcat 8.0.x Migration Guide
3. Tomcat 8.5.x Migration Guide

We will communicate with you individually to coordinate any required upgrades before Tomcat 6.0 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of Tomcat 6.0 to Tomcat 7.0.

We will carefully review all server.xml and web.xml files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

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 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.

We have developed a Bandwidth Cost Calculator for the Fremont, California data center.

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.dbc package meets these requirements.

We have recently added an alternate constructor to be able to create a com.aoindustries.dbc.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.

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 tags maintain full binary transparency from Java through to JavaScript in this scenario.

We have updated the Javatator Database Administration Tool to work better with our PostgreSQL 8.1 and PostgreSQL 8.3 installations.

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 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'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 ao-web-framework or the newer aoweb-struts) and which language was active.

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.

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.