Posts in Category "General"

Be Aware of the Closed Captioning Pod Defaults

Last week we found out that Caption Colorado changed their IP address and port number for the Closed Captioning pod downloadable from the Connect Exchange Website. Here is the direct link to the Connect version 9 Closed Captioning Pod

The new Caption Colorado information includes:

If you are experiencing any trouble with the Closed Captioning pod while using it in a Connect Meeting with Caption Colorado, please set your host to “captionedtext.com” and to port 11100 in the adobe pod. Note that the new IP, 54.193.31.11, depending on your infrastructure’s network security settings, may need to be white-listed.

For an updated user’s guide referencing the Closed Caption Pod, see this PDF: http://platinum.adobeconnect.com/cc/

 

 

Estimating the Size of Archive Meeting Recordings

I was recently asked if I had any test data showing how big a recording becomes based on the use case during the Connect Meeting being recorded. While plenty of anecdotal information exists,  I thought it prudent to begin a list of use cases and show what the size was after five minutes of each use case. This article will be a work in progress as I add different use cases in order to offer various concrete examples to use as a basis to estimate recording size based on what is being recorded, whether multiple Video pod camera feeds or screen-sharing or VoIP, etc. Among its purposes, this exercise will help meeting hosts to avoid exceeding the 2GB limit on Adobe hosted clusters for recording size.

Most relevant among the variables considered is the notion that recording size is affected by the streams present in the meeting being recorded. Typically a Video pod with VoIP (640X480) shared per hour will result in an FLV of around 200MB. Sharing a screen in a meeting (1680X1050) will result in an FLV size of around 150 MB. PPT/PPTX files uploaded to a meeting room and displayed while recording will not play a significant part in recording size because the recordings link to external content rather than contain that content intrinsically. For example,  a meeting with two Video pod streams could have recording size of around 400MB and a meeting having a single Video pod stream with VoIP and screen-sharing could end up around 350MB. The actual results may differ as the screen resolution of the publisher, the type of sharing and the amount of movement are all variables that can affect recording size: If there is little movement on screen or in the Video pod stream, the recording size will be less than it would be with a lot of movement.

Here are some concrete examples to use for planning; each recording is approximately five minutes in length:

A meeting with a single video feed for the Presenter to display and scroll through an uploaded PowerPoint file while using integrated telephony:Title: Recording Size Test_0
Type: Recording
Duration: 00:05:31
Disk usage: 8335.3 KB

rec-size1.fw

 

A recording of a meeting with six video feeds and an uploaded PowerPoint file
Title: Planning Troubleshooting and Support Meeting Room _15
Type: Recording
Duration: 00:05:48
Disk usage: 13873.8 KB

rec-size2.fw

 

A recording of a meeting with four video feeds and screen sharing an application with normal activity
Title: Planning Troubleshooting and Support Meeting Room _16
Type: Recording
Duration: 00:05:56
Disk usage: 21660.8 KB

rec-size3.fw

More examples to follow.

How Meeting Folder Permissions Affect Access to a Meeting Room

The question keeps coming up, what happens to Meeting accessibility and permissions if I move a Meeting room from the a User Meeting folder to the Shared Meetings folder?

Let’s look at it from multiple angles beginning with the permissions on Shared Meeting folder itself and then moving to the Meeting room access options and then to the Meeting roles.

1. The Shared Meeting folder itself has two permissions options: Manage and Denied:

sharedfolderperm.fw

If a registered user is granted Manage permission over the Shared Meeting folder by an Administrator, then that registered user can gain (at a minimum), participant access to every meeting in the Shared Meetings folder. Of course, a participant can do very little within a room:

sharedfoldermeeting.fw

Manage permissions on the Shared Meetings folder does not, by itself, allow the power to change room settings. The settings will be viewable but cannot be changed:

editinfo.fw

Clicking save will quickly manifest insufficient permissions:

notauth.fw

Manage permissions on the Shared Meeting folder allows for deletion of  a meeting in the Shared Meetings folder:

delemeet.fw

delemeet1.fw

2. Separate from the Shared Folder permissions, are the room access options under Connect Central for any Meeting Room:

editinfoopt.fw

These Meeting access options do not override the folder options. While a user with Manage permissions over the Shared Meetings folder will still need to enter a passcode if one is set, the manage permissions allow the passcode to be viewed in Connect Central :

passcd.fw

 

passcdview.fw

3, Meeting roles set will not be affected by folder permissions even if the Denied Access is chosen at the Shared Meeting folder level:

denied.fw

A user who has Denied access to the Shared Meetings folder cannot view the the folder Connect Central:

notauth.fw

Meeting access permissions and roles apply however when directly hitting the Meeting URL even if the user is denied access to the Shared Meetings folder:

notstart.fw

in.fw

 

How to Find and Administer a Meeting by Searching on its URL

Problem: Sometimes the meeting library in Connect become quite large and it may be difficult for an administrator to find a Meeting room that has been created by a host.

Solution: Generally a meeting created by a host will be under the user directory of that host (My Meetings for that particular Host), but not always. The User Meeting folder can contain hundreds of different meeting folders and scrolling through them page by page by page in the Connect Central GUI can be laborious.

usermeetings.fw

Next Page…. Next Page…. Next Page…..

nextpage.fw

One simple search trick is to place a number directly in the start parameter of the URL to skip to subsequent pages and user meeting folders. Here I have replaced the starting number of “0″ with the number “500″ and when I refresh the screen it will skip folders and accelerate my search:

start.fw

start500.fw

Note: You may also adjust the rows URL parameter as well: rows=1000

When you want to find a specific meeting to administer and you know the URL, a quick way to find the meeting folder in Connect Central is to use the Custom URL Report under the Administration Tab>Reports>View Custom URL:

customurl.fw

Our labeling of  this search option, “View Custom URL” is really is a bit of a misnomer because you can search for any meeting by its URL whether the URL is custom or automatically generated by Connect in Connect Central; all URLs are obviously unique. Here I search for a meeting URL with the suffix “es” on the platinum domain and it shows me the meeting information which gives me a hook that makes it very easy to find that meeting folder to administer:

searchedge.fw

Now simply take the title of the meeting and place it into the Connect Central search parameter to find the meeting folder:

searchtitle.fw

Connect Central has some great tools even if the possibilities they offer are not always intuitive.

Connect on-premise Server: Configure additional ports for RTMP traffic

By default the meeting server (FMS) in Connect binds to port 1935.  Here’s how to add additional ports like port 80 for use with the meeting server.

This should work with all versions of Connect.  I am assuming you would like to use port 80 and 443 in addition to 1935  (all in rtmp, no encryption).
As Connect consists of two servers, the application server (Tomcat) and the meeting server (FMS) you need to configure a second IP address and FQDN in order to bind two services to port 80.  Make sure your new FQDN resolves to the new second IP address. The second IP and FQDN will be used for the meeting traffic.

I am using these values in my setup:

Application Server: connect912.adobe.com – IP 10.1.1.1
Meeting Server: connect912meeting.adobe.com – IP 10.1.1.2

So here we go:

  • Make sure you can ping both names and they resolve to the correct IP addresses.
  • Open the server console and set the new meeting server FQDN in the “external name” field and save your changes.

In my setup this is connect912meeting.adobe.com:

consoleExternalName

 

  • Configure the meeting server to listen on the new IP:Port.

In my setup I am adding port 80 and 443 in addition to the default port 1935.

Open the custom.ini (by deault  in C:\Connect\9.1.1\ if running Connect 9.1.x) and add these lines:

DEFAULT_FCS_HOSTPORT=10.1.1.2:80,443,1935
RTMP_SEQUENCE= rtmp://external-host:1935/?rtmp://localhost:8506/,rtmp://external-host:80/?rtmp://localhost:8506/,rtmp://external-host:443/?rtmp://localhost:8506/

Replace 10.1.1.2 with your meeting server IP address and also make sure the RTMP_SEQUENCE is in one line. Save the changes.

  • Restart the services, FMS and Adobe Connect service.

Once the services are back up and running you should be able to start a new meeting.  If there are no firewall restrictions a meeting should connect on the first port listed in the RTMP_SEQUENCE. In this example port 1935.
To test the connection on the other ports, block outgoing connections to port 1935 on your client firewall.  If the meeting is still open on your client it should briefly disconnect and reconnect on the next available port. In my setup this would be port 80.

You can check which port you are connected to in a meeting by holding down the shift key and clicking “About Adobe Connect” from the help menu (top right in your meeting).

AboutAdobeConnect_RTMPSequence

 

 

update (03/04/2014): 

It appears that with version 9.2 you also need to specify the IP address the application server binds to. By default it binds on 0.0.0.0:80, so on all available IPs on port 80.With Connect 9.2 I have come across an issue where the application server does not properly create a listener when port 80 is used for the meeting server as well.
The easiest way around this problem is to specify the IP in the application server config so it starts a listener on this one IP only.

In the server.xml in \appserv\conf\ find this section:

    <Connector port=”80″ protocol=”HTTP/1.1″
            executor=”httpThreadPool”    
           enableLookups=”false”
               acceptCount=”250″
               connectionTimeout=”20000″
               redirectPort=”443″
               URIEncoding=”utf-8″/>

And add your application server IP address:

    <Connector port=”80″ protocol=”HTTP/1.1″
            address=”10.1.1.1″
           executor=”httpThreadPool”    
           enableLookups=”false”
               acceptCount=”250″
               connectionTimeout=”20000″
               redirectPort=”443″
               URIEncoding=”utf-8″/>

Save the change and restart your services once again.

Where is my Engagement Dashboard?

At some point you may want to use the Engagement Dashboard to track your users’ attentiveness in an Adobe Connect Meeting room, but wonder where oh where it may be…  You glance up at your Pods menu (as a host) and see it is not listed.  You may wonder why.  Well, here’s why…

If you want to use the Engagement Dashboard, one of the following scenarios has to be true:

  • You are a Seminar Host and created a Seminar Room.  Seminar Rooms have the Engagement Dashboard in the Presenter Only Area.
  • You are an Event Manager and created an Event that points to a meeting, seminar room, or virtual classroom, in the Event Management area of Adobe Connect.  If you point an Event to any meeting, virtual classroom, or seminar room, it will have the Engagement Dashboard in the Presenter Only Area.
  • You are a Training Manager AND Meeting Host and you create a Virtual Classroom (you must be both to even create a VC in the first place), it will have the Engagement Dashboard in the Presenter Only Area.
  • You are an Meeting Host AND Event Manager and you create a Meeting (just being a Meeting Host will NOT give you access to the Engagement Dashboard).  Only then will the Meeting have an Engagement Dashboard in the Presenter Only Area.

Situation where you will have a room open and you won’t have the Engagement Dashboard as a Pod option:

  • You are a Meeting Host but NOT an Event Manager as well.  You will not see the Engagement Dashboard in the available pods and it will not be in the Presenter Only Area.

Additional Resources around the Engagement Dashboard…

http://blogs.adobe.com/adobeconnect/2012/06/sneak-peek-the-engagement-dashboard.html

https://www.connectusers.com/tutorials/2013/06/rules_of_engagement/index.php

engage1

engagement2

How to completely delete content from a Meeting room

To completely delete content from any meeting room there are at least two places and possibly a third place in Connect from which you must delete it.

The first place is the most obvious and it is in the Meeting room itself under the Pods menu and Manage Pods option:

del-con.fw

del-con1.fw

The second place is in the Uploaded Content directory under the Meeting Information. To get there from a Meeting room, a host and owner can click Manage Meeting Information under the Meeting tab:

del-con2.fw

Then go to the Uploaded Content tab:

del-con3.fw

The third possible place is the Content Library. If you uploaded or published to the Content Library and pointed the share pod to it, you will need to go to the Content Library to delete it. If you uploaded directly to the Meeting room then you may skip this step:

del-con4.fw

Adobe Connect Database Disaster Recovery Options

Having a good recovery strategy allows for recovery of data in case of unforeseen events such as user error, hardware failure, drone strikes and fecal tsunamis. There are three recovery models:

  • Simple Recovery
  • Bulked Logged Recovery
  • Full Recovery

Simple Recovery is the most rudimentary. When the DB recovery mode is set to simple, the transaction log does not get backed up. It is auto-truncated and you can only ever recover to a full db backup; this builds-in the potential for data loss as a point-in-time recovery is not possible. Generally, the Simple Recovery option is recommended for development or test environments where data recovery is not critical. It is also a good strategy for a novice DBA as you don’t have to worry about a detailed backup and restore plan/jobs. Mission critical databases should never be in simple mode, but for non-mission critical deployments it is a low-overhead alternative.

The Bulk Logged Mode is not very commonly used. When the DB recovery mode is set to Bulk Logged, bulk operations are only minimally logged (Select Into, Create Index, etc.). This results in in reduced log space consumption. The shortfall is that if the last transaction log has bulk operations in it, then point in time recovery is not possible; if it does not have bulk operations in it, then point in time recovery is possible. While it may be prudent to switch full recovery databases temporarily into Bulk Logged Mode for the purpose of re-indexing a very large database, be sure to always switch them back as critical databases probably shouldn’t be in Bulk Logged recovery mode.

Full Recovery Mode is the default recovery model and is the most granular. When the database recovery mode is set to full, everything get’s logged to the Transaction Log resulting in greater log space consumption. Point in time recovery is possible in full recovery mode. This is the recovery model most users should choose for production data. By using this recovery model with regularly scheduled full backups, differential backups and transaction log backups, it allows for quicker point in time recovery.

Choosing a backup and recovery plan is relevant to the following criteria:

  • How important is the Data? The more important the data, the more likely you will choose full recovery and schedule regular full backups, differential backups and log backups.
  • How often does the data change? How busy is the Connect server?
    If the data only changes frequently during normal business hours, scheduling log backups closer together during these times and further apart during non business hours might work out.
  • How much space do you have available for backups? This could determine how many backups will you store and how often will you back up.
  • How quickly do you need to recover data? If recovery speed is not important, but point in time is, you might choose not to do any differential backups and just do Full nightly backups and regular transaction log backups.

Based on the answers to the previous questions, you should be able to determine a backup plan that fits your needs. Remember to test the recovery of your backups regularly.  Backing up is useless if backups are corrupt or not working correctly.

Another important consideration is with the timing of backups. Keep in mind that performing backups is resource intensive.  To help determine an appropriate schedule of your backups, consider the ongoing activities on the Connect servers.

If  you want to focus on recovering data in case of fire or natural disaster then you you should consider storing the backups offsite.  Many savvy DBA’s they keep a predetermined number of current backups on site and also ship the backups offsite (tape or network).  They might choose to keep five current backups onsite and as many as 30 offsite.

SQL 2008 has backup compression allowing you to save on disk space, but it comes with a cost of speed. Choose the compression level that suits your speed of backup. Third-party products offer backup compression as well.

Consider also the various high availability options:

  • SQL clustering relies on Windows clustering. It clusters the entire server not just the database. The fail-over is slower than mirroring and doesn’t provide a fail-over against disk failure.
  • Mirroring (http://msdn.microsoft.com/en-us/library/ms189852.aspx) is a faster fail-over solution. The Connect SQL driver has the ability to choose a fail-over server. This can be done at the DB level.
  • Log Shipping ships completed transactions to the log shipped database; this can be done on the database level and requires manual intervention to fail-over as the log-shipped db is considered a warm DB

Note: Replication is not a recommended option.

Adobe’s Hosted infrastructure uses a hybrid high-availability strategy. We use database mirroring as the primary fail-over solution.It provides faster fail-over and does not have a single point of failure as does clustering which relies on the single disk. We also use log shipping as a secondary fail-over solution. In the extreme case that all mirrored databases go down, the log shipped database can be used with some user intervention: Break the log shipping, take the database out of standby mode and point the Connect server to it.

Adobe Connect Database Performance and Monitoring

Following SQL database performance best practices and monitoring the health of you Connect database will help to insure a responsive Connect server providing excellent end user experience.

It is best to always place the operating system, data and log directories on separate disk drives; this will result in improved performance. If you must put Connect on the same server as the DB (never a best practice but sometimes a practical necessity), you should ensure that the Connect installation and content directories are on a different disk drive than is the database data. The Temp DB should also be on a separate disk drive. Putting the SQL data on striped disks,  provides a tuning benefit as well.

Be sure to aggressively re-index and update statistics. De-fragment the operating system data and log files on a regular schedule. Ensure that there is minimal latency between the Connect server and the SQL Server. Be wary of  network maintenance and backups that can produce latency between the Connect server and the SQL server and be sure to avoid heavy Connect use during any such maintenance.

Make sure that the SQL server has plenty of RAM; the more RAM the better.  Everything works much faster in memory.  The more of the database that you can keep in memory the better off you will be. Only virtualize the DB server if absolutely required.While Connect runs fine on supported VMWare servers, the SQL database server is best run on a dedicated platform

With reference to the use of separate disks, here is a prioritized list of what should have its own disk:

  1. Operating System
  2. Adobe Connect (Separate Server if possible)
  3. SQL database
  4. Data
  5. Log
  6. TempDB
  7. Transaction logs

For best performance, set the initial size of the transaction log file based on estimated use.  This avoids unnecessary fragmentation. The transaction log should be on a different drive than is your data file, temp database and operating system. Manually shrink the transaction log files based on monitoring.  If you try to do this as a nightly or weekly job, you will end up with unnecessary fragmentation. De-fragment the transaction log file as necessary and consider putting transaction logs on striped disks. Ensure regular backups as transaction log backups empty the space inside the log file and prevent it from continuing to grow.

Manage the memory by setting the minimum server memory for SQL server.  Remember to leave enough for the operating system and any other applications running on the server:

db3.fw

SQL Server uses the tempdb database as a working area for temporary tables, sorting, sub-queries etc.; the tempdb should be stored on its own drive away from other DBs whenever possible.  The default location is on the SQL install disk. Increase the size of the tempdb database based on expected usage and available space. SQL Server automatically adjusts the size over time, but each change causes a performance hit and causes fragmentation. By increasing the size, you avoid constant growth. SQL 2008 uses the tempdb more than prior versions of SQL. Never try to backup the tempdb.

Monitor the disk space of the data files and log files. Disk space is inexpensive when compared with the benefits it provides when available in abundance.  You should aim to keep at least 30% free disk space in case you need to expand the data/log files, or if they are set to autogrow.  Sudden increases in size should  be cause for investigation.

Monitor the fragmentation levels. If the database and log were set to autogrow at small intervals, there is a high likelihood that they are fragmented. If you regularly shrink the DB data files or log files, that could also lead to fragmentation

Monitor for slow queries; you can see slow queries in the Connect debug log.  Just search for Slow Query. Query times are returned in msec. Also look for lock timeouts in the debug log.  Generally this is a sign of database problems. A lock timeout is a query that attempts to get a lock on a database resource.  It times out because something else is already holding a lock. A lock is usually held until the transaction has completed, so if there is a long running query it could cause lock timeouts. You can also run traces against the database to gather information on long running queries.  In SQL 2008 you can query dynamic management views to get this information.

Monitor indexes liberally keeping in mind that re-indexing regularly should decrease the need to monitor indexes. Sometimes re-indexing may start taking too long to complete and you will want to be more selective about what to target. Knowing which tables or indices are most fragmented allows you to only re-index them. You can query dynamic management views in SQL Server to get this information (see SQL Server books online). Many 3rd party products offer monitoring of SQL server and you might consider these products if you want a more automated GUI interface to monitoring indexes. Some of the products offer monitoring for other areas of SQL Server as well.

Windows performance monitor or perfmon is useful; you can use perfmon to monitor SQL counters.  Here are 3 common counters which, if they reveal something will warrant further scrutiny.

  • Pages/sec  -  How much your SQL server is paging in and out of memory
  • Disk Queues -  If the write or read disk queues are too high, you will need more RAM
  • CPU Queue length -  If the CPU queue is consistently over 2 per CPU for an extended period of time, you might have a CPU bottleneck.

Be aware of  load and activity when monitoring with perfmon as database backups and other maintenance activities can cause spikes in these numbers. It is best to connect to the server from a different PC if you intend to monitor it with perfmon.

A good maintenance plan will include scheduled re indexing during off hours. Fragmented indices can cause Connect to become sluggish and might even cause fast-fails in a Connect cluster. If you start to see a lot of slow queries in the debug log, you should ensure that the Connect DB is being re-indexed regularly: Index maintenance is one of the easiest ways to keep your DB healthy and SQL Server provides wizards that help make index maintenance easy.

Open SQL Server Management Studio and open the management folder.

  • Right Click on the Maintenance Folder
  • Choose Maintenance Wizard

Give the Maintenance plan a name:

db4.fw

Choose the desired maintenance tasks: Rebuild Index & Update Statistics

db5.fw

Choose the Database you want to re-index:

db6.fw

Reorganize with the default amount of free space; the default amount is what it was initially created with.

db7.fw

Choose the same database to update statistics after you re-index.

db8.fw

Schedule a job to run the maintenance plan; provide a name and choose a schedule that suits your infrastructure:

db9.fw

Database performance and monitoring best practices will insure a responsive Connect server providing excellent end user experience.

FAQs on Adobe Connect SQL Database Installation, Startup, Connection and Pooling

The following is a summary of Adobe Connect 9 database installation tips

1. What do I need to start?

Always check the updated system requirements page prior to installing: http://www.adobe.com/products/adobeconnect/tech-specs.html
As of the writing of this article it reads: Microsoft SQL Server 2008 SP3, 2008 R2

While it is best to have sa permissions, you are required to use a username and password with dbcreator privileges.  We highly recommend recommend using an sa account. After the install you may use a dbo account for normal use, but during any upgrade or updater application, you must switch back to sa.

2. When does the installer create the database for Connect?

All current Connect versions (after 7.5SP1) create the database during installation. Typically the DB creation process takes about 50 seconds. First the schema get created and then the seed data are inserted. After the DB is created, Connect is still not fully functional until you download and apply the license.txt file. The license file will insert additional seed data into the Connect database including templates and folders.

3. How should I troubleshooting database login failures during installation?

db1.fw

This error can mean several things:

  • The username incorrect
  • The password could be incorrect
  • SQL Server Authentication might not be on.

Entries in the debug.log will provide some answers:

db2.fw

  • java.sql.SQLException… Login failed for user ‘sa’ usually means it is a mistype in the username or password
  • java.sql.SQLException… Login failed for user ‘sa’. The user is not associated with a trusted SQL Server connection usually indicates SQL Authentication is disabled
  • java.sql.SQLException…Cannot open database “dbname” requested by the login,  usually indicates that the login exists, but does not have permission to open the DB
  • java.sql.SQLException…CREATE TABLE permission denied in database ‘dbname, this usually indicates the login has permission to login to the DB, but does not have permission to create schema objects.

Note: During install and upgrade and during minor updates of point releases, the DB user must have permissions create, alter or drop schema objects.

Note also that log errors are discussed on page 83 of the Adobe Connect Installation Guide: http://help.adobe.com/en_US/connect/9.0/installconfigure/connect_9_install.pdf

If you encounter any of these errors, stop all of the Connect services, correct the user privileges in SQL and start the services again.

4. What happens during a successful startup?

During startup, Connect tries to login to the SQL database, if it can’t connect, the service stays running but enters into a dormant state. You will be able to gain access to local port 8510 to configure the Connect server through its wizard, but  not the application front end. If it the connection is successful then Connect
makes multiple connections to the SQL database (connection pool). The initial connection pool and max connection pool is configurable. Connect checks the DB Version and determines if it needs to apply updates and then the Connect Host updates a row in the DB (PPS_ENUM_DATA_HOSTS) and sets itself active.

5. How does Connect monitor the health of the SQL database? What is the HealthCheck function for?

Connect relies heavily on the SQL databse. it is safe to call the SQL database the heart of any Adobe Connect installation. Connect contsnatly checks to see if there is a valid connection to the SQL database. Loss of connection can lead to data corruption. To avoid this, Connect runs a haelthcheck on the SQL database; it pings the SQL Server and checks to see if it has been more than 40 seconds since the Connect Server has updated the PPS_ENUM_DATA_HOSTS table. If it is greater than 40 seconds, the Connect Pro Host is marked inactive and the services for that Connect server will restart and then reattempt  to connect to the SQL database.

If you are running the Connect SQL database in a SQL cluster rather than in a mirrored environment, you will want to make sure that Connect makes multiple database connection attempts during SQL fail-over. If Connect loses its SQL database, the entire Connect cluster will go down and it will wait for an administrator to manually reconnect to the database through launching the Connect configuration console on port 8510. Add the following to the custom.ini file to support any delays in clustered SQL fail-over:

DB_URL_CONNECTION_RETRY_COUNT = 15
DB_URL_CONNECTION_RETRY_DELAY= 30

The actual JDBC string is in the config.ini file so you do not need to put it into the custom.ini; double check the config.ini if you are running into any problems with the JDBC reconnection string:

DB_URL=jdbc:macromedia:sqlserver://{DB_HOST}:{DB_PORT};databaseName={DB_NAME};user={DB_USER};password={DB_PASSWORD};ConnectionRetryCount={DB_URL_CONNECTION_RETRY_COUNT};ConnectionRetryDelay={DB_URL_CONNECTION_RETRY_DELAY}

6. What is the purpose of the Connection Pool and why do it the way we do?

Adobe Connect makes use of a connection pool. Every time the Application needs to communicate with the SQL database, it checks for the next available idle connection and uses it. If there isn’t one available, it will create a new connection unless it has reached the connection pool max. Once the application has finished it’s transaction, it releases the connection back into the pool.

  • Default initial DB_POOL_INITIAL_SIZE=20
  • Default Max DB_POOL_MAX_SIZE=40

This prevents the overhead of creating new connections each time a call to the SQL database is required. The connections are made at start-up. Since Connect relies heavily on the DB, having available connections is essential.