Openfire on Oracle RAC

Openfire Openfire Support
1

Hi,

We are in the process of setting up openfire and wanted to validate with this community whether -

  • Openfire 3.6 version can run on Oracle RAC and does Openfire support a RAC-friendly connect string

  • Does Openfire support the use of Fast Connection Failover?

Thanks

Raghu

2

Would like to expand on this question a bit as we are leaning toward stacking our database with others in a shared RAC (10.2.0.4) environment with other databases related to the same project.

We are trying to confirm that OpenFire 3.6.4 supports the use of a RAC-friendly connect string, defined as any one of the following examples:

This connect string supports Transparent Application Failover (TAF) which will allow some types of connected sessions to fail over to the surviving nodes. The IP addresses represent Virtual IPs that can be brought up on a surviving node in case of failure. This type of connect string would be used by a JDBC Thick/OCI driver:

(DESCRIPTION =

  • (FAILOVER = ON)*

  • (LOAD_BALANCE = ON)*

  • (ADDRESS_LIST =*

  •    (ADDRESS = (PROTOCOL = TCP)(HOST = vip1) (PORT = 1525))*

  •   (ADDRESS = (PROTOCOL = TCP)(HOST = vip2) (PORT = 1525))*

  • )*

  • (CONNECT_DATA =*

  •    (SERVICE_NAME = LABXSERV)*

  •    (FAILOVER_MODE = (TYPE = SESSION) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))*

  • )*

  • )*

These connect strings specify a service name rather than an ORACLE_SID value and are valid for JDBC Thin driver connections. In both cases, the host address is a virtual IP address:

//vip-address:1525/RACXSERV

vip-address:1525:RACXSERV

This thread indicates that someone has had success with using a RAC database - would appreciate any additional feedback/confirmation:

http://www.igniterealtime.org/community/message/189884#189884

3

Hi Raghu,

as the connect string is handled by the JDBC driver it should be possible to use RAC. Anyhow I did not test this.

I guess that Openfire does not know what “Fast Connection Failover” means. At least old versions which did not use Proxool (connection pool) did have problems reconnecting to a database.

In any case I wonder why one would like to use a RAC for the Openfire database.

LG

4

Why use RAC for an OpenFire database? We use RAC to provide high availability and database session load balancing in our environment. If the application can be built out for high availability using clustered application servers, why not complete the configuration by making your database highly available as well?

In implementations where the availability of a suite of applications is considered critical to the operation of your business, RAC fills this gap very nicely and the database is no longer a single point of failure for the application suite. If the application layer can further leverage the additional features of RAC, such as FCF (Fast Connection Failover) or TAF (Transparent Application Failover), even better as the end user experience will not be impacted as much, if at all, in the event of the failure of a database server.

The other benefit of RAC is that we have the ability to make the most of our hardware resources - we don’t have servers sitting idle as we do in an active/passive cluster configuration. We can distribute the incoming database sessions across the RAC cluster transparently to the application.

I agree that since OpenFire is using Oracle’s JDBC driver that it is possible to use RAC for OpenFire’s database. There’s been at least one implementation of it thus far detailed on this board (referenced in my earlier post). At this point, I would be interested in hearing others’ experience, lessons learned, etc… with this particular configuration.

Just my $.02.