Technical Specifications
- Pure Java. Flux is written in pure Java. As a result, the same Flux code runs on any platform that has a supported version of Java. Flux runs equally well on IBM mainframes, PCs, and Macs.
- Supported Java Versions. Flux 8.3 requires Java 8, 9, 10, or 11 from Oracle. Users have found Flux works with Java versions from other vendors, although those alternate Java implementations are not explicitly supported.
- Supported Databases. Note: The JDBC Database Drivers being used must match the release of the database being used. Using database drivers that pre-date the database version is not supported. As an example, using JDBC Drivers for SQL Server 2000 is not supported when using SQL Server 2008.
- Oracle 11g, 10g, 9i, and 8i
- IBM DB2 10.1, 9.7, 9.5, 9.1, 9.0, and 8.1
- SQL Server 2012, 2008, and 2005 with row versioning enabled using the Microsoft JDBC drivers
- PostgreSQL 9.2, 8.4, 8.3, 8.2, and 8.1
- MySQL 5.6, 5.5, and 5.0 using the com.mysql.jdbc.Driver JDBC driver with InnoDB tables
- Apache Derby (Built into Flux. Does not cluster. Only appropriate for light-duty use.)
- H2 (In-memory database built into Flux. Data is lost on restart. Does not cluster. Only appropriate for light-duty use.)
- Supported Application Servers. Using an application server is optional.
- WebLogic Server 12, 10.3, 9.2, 9.1, 8.1, 7.0, and 6.1
- WebSphere 8.5, 8.0, 7.5, 6.1, 6.0, 5.1, 5.0, and 4.0
- JBoss 7.1 and 7.0 (both with RestEasy disabled)
- Tomcat 8.0, 7.0, 6.0, 5.5, and 5.0
- Jetty 9
- Other application servers may be used with Flux, however they have not been tested.
- Supported Web Browsers. Using the Web-based Operations Console is optional. It supports the following web browsers.
- Google Chrome 15 and newer
- Firefox 7 and newer
- Microsoft Edge
- Supported LDAP Servers. Using LDAP for security authentication is optional.
- Microsoft Active Directory
- Apache Directory Server
- Supported Operating Systems. Flux works on any operating system that supports Oracle’s JVM. Specifically, Flux is known to work on 64-bit and 32-bit Windows, Linux, Mac OS X, Solaris, HP-UX, AIX, AS/400, and OpenVMS systems.
- Minimum Memory Requirements. Flux Engine: 512 MB RAM. Flux Agent: 512 MB RAM. Flux Operations Console: 512 MB RAM. A cluster of Flux engines and their agents is managed from a single Operations Console instance.
- Apache Derby and H2. If you are using the default Apache Derby database or the in-memory H2 database, Flux will typically require an additional 300 MB of memory to run.
- Minimum CPU requirements. Flux requires an equivalent CPU of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor (or equivalent to a 2006 1.7 GHz Xeon processor). NOTE: Memory and CPU requirements may increase as the usage of Flux increases. As the usage, size, and complexity of your Flux workflows increase, CPU and memory usage may scale accordingly.
- Apache Derby and H2. If you are using the default Apache Derby database or the in-memory H2 database, Flux will typically require an additional CPU equivalent to the type described above.
- Minimum Screen Resolution. The Flux Operations Console requires a minimum screen resolution of 1280 x 1024.
- Virtualized Environments. Flux can run in any virtualized environment (including VMWare and VirtualBox) where a stable JVM is available. Note that many virtual environments have virtual disk I/O subsystems that are substantially less performant than physical machines. In such instances, the performance of Flux may be adversely (sometimes extremely) impacted.
- Active-Active Clustering. Engines automatically cluster when pointed to the same database. Flux supports clusters of a dozen or more engines. NOTE: If using a cluster of more than 4 engines, the cluster networking engine configuration option should be disabled for best performance.
Network and Firewall Ports
Flux requires access to certain TCP-IP ports when operating. Please ensure the following ports are open between the Flux engine and Operations console and external servers/services.
- Outbound 21 for FTP
- Outbound 22 for SFTP
- Outbound 25 or 587 or … for Mail
- Outbound 139 for UNC
- Outbound 389 or 10389 for LDAP and Active Directory
- Outbound 636 or 10636 for LDAPS
- Outbound 445 for SMB
- Inbound 7186 for the Flux Operations Console
- Inbound 7520 for the Flux Engine
- Outbound Database ports (e.g., 1433 for SQL Server, 50000 for DB2)
What Does it Mean for a Component to be “Supported” within Flux?
In Flux, a supported component is a software component that Flux has performed testing against, using the component’s default configuration, and Flux has verified that all core Flux features are known to work while using the component.
If a user encounters any defect in the core Flux features, and the defect can be reproduced using the component’s default configuration, the defect will be covered under the Flux support and maintenance agreement.
Errors that occur within a customer’s environment using supported components that do not impact core Flux features (i.e., errors in custom actions or code that Flux invokes) or that result from non-default configuration changes, may not be considered as bugs in Flux. Such customer-specific debugging and troubleshooting will generally be considered billable and outside the scope of the support and maintenance agreement. Reviewing customer-specific code or configuration settings to ensure they will run smoothly with Flux is also generally considered billable.
Flux Maintenance Policy
The following versions of Flux continue to be supported and will be supported indefinitely: Flux 8.x, 7.x, 6.5, 5.3, and 3.1.
Java Technology Support Information
Flux depends on Java technology. From time to time, new versions of Java technology appear and older versions are retired. Because Flux runs in a Java environment, we encourage you to take proactive measures to ensure that Flux is not running in an obsolete software environment. However, we recognize and accommodate the above listed application servers that use older versions of Java.
Certain REST Constraints
In Flux 8.0 we transitioned how Flux provides remote engine services. Those changes are present in 8.2 as well. In releases prior to 8.0, these services were provided via RMI through TCP/IP. Starting in 8.0, the Flux engine’s cluster networking and remote engine invocations all now utilize REST via HTTP or HTTPS. These engine services are core to the processing of Flux and its failover, configuration, and monitoring facilities. While cluster networking can be disabled with a small performance impact (instead relying on the shared database for failover and load balancing), turning off remote engine invocation disables the Flux Operations Console and remote engine calls via the Java API.
Flux, in its selection of REST implementation technology, selected a well-supported, production-proven, and open-source library called Apache Jersey. With the selection of any implementation technology there comes potential constraints. The selection of Apache Jersey to provide Flux REST support comes with the following identified constraints.
- There is a known conflict with JBoss 7 and deploying servlets that use different libraries implementing REST. JBoss only allows one implementation of REST within its servlets. JBoss’s default implementation is RestEasy, while Flux uses Apache Jersey. If a customer-provided servlet requires a different REST implementation than Flux and the other application will conflict within JBoss, the only resolution to this is to either run Flux as a standalone engine, outside of JBoss, or run it only with non-conflicting servlets in one instance of JBoss, and place the conflicting servlet in its own instance of JBoss.
- There is also a known conflict between Flux and a Java developer adding their own Apache Jersey jar files to the classpath of a program utilizing Flux. In such instances, the Flux engine will fail to start. The workaround is to disable Flux cluster networking and server mode before starting the engine.