Support Uploads

Owned by Hannah Petty
Last updated: Aug 11, 2015Version comment
4 min read

In this section:

Upload Process

  1. Immediately after the user presses the button, an empty "transfer.started" file is uploaded. If this file cannot be successfully uploaded, no support upload will be performed, but the files that would be uploaded are still created in the staging area. If the user presses the button and the folder and file are not created within a few seconds you know the upload will not work.
  2. The upload is now broken into several files instead of just one big one. Each file is created in a staging area and regardless of whether they can actually be uploaded, the files are created and remain in the staging area until the next support upload is performed.
  3. The staging area is under <ESS_HOME>/.tmp/.supportUpload. Whenever a new support upload is initiated, the staging area is cleaned out prior to new staged support upload files being created there.
  4. A directory is created in the staging area that is named the same as the directory where files are uploaded on sftpupload.echo360.com.
  5. The upload files are created one by one and are uploaded as they are created:
    • config.zip contains the contents of the <ESS_HOME>/etc dir and the wowza configuration dir (if applicable).
    • sysInfo.zip contains various system information, such as Java system properties, environment variables, a summary of the relevant file systems, and a file that shows the number of records in each of the database tables.
    • Zip files are created that contain log files covering three day periods. The first, logs_00-03_daysAgo.zip, contains the log files with a last modified time from now until three days ago. The second, logs_03-06_daysAgo.zip, contains the log files with a last modified time from three to six days ago. Zip files are created and named following this pattern. The oldest file, logs-27-30_daysAgo.zip, contains the log files with a last modified time from 27 to 30 days ago.
    • database.zip contains the Derby database (if applicable).
  6. The log file archives will only be produced if there are logs from those days. Also, there is a 200 MB limit, so as soon as the cumulative size of the log archives exceeds that limit, no more will be produced.
  7. Files (like log files, files in etc, database files) now retain their last modified date when extracted from the zip.
  8. If all of the files upload successfully, an empty "transfer.complete" file is uploaded as before.
  9. No longer allow multiple overlapping simultaneous uploads at the same time. Give user a message that one is already in progress if they keep hitting the button before the first one is finished.

Logging

  1. There is a new "jetty.log" file that logs some jetty-specific stuff, especially during startup. This will be very useful troubleshooting cases where the EchoSystem Server (ESS) will not start up correctly. It should no longer be necessary to start the ESS from the command prompt in these cases. In fact, most logging is no longer directed to stdout/stderr so will not appear in the console when starting from a command prompt.
  2. wrapper.log is now capturing stdout/stderr from the java virtual machine. This will allow it to capture thread dumps and other debugging information that can be provided by the JVM.
  3. The logging configuration file (<ESS_HOME>/etc/logging.cfg.xml) can now be changed on a running system and the changes will be picked up without restarting the ESS
  4. Logging should now resume soon after correcting a problem that prevents logging, such as interruption of an NFS share or a permissions issue. Until now, when logging stopped due to such an issue, an ESS restarted was required to get it going again.
  5. The request.log file entries are now in the local time zone of the ESS machine like all of the other logs, instead of GMT. The naming pattern of the request log files is now consistent with the other logs.
  6. The active log files are now named using the same pattern as the rolled-over log files, so the name will no longer change when it gets rolled over. This was previously the case with the wrapper log file and now applies to all of the log files.

Cached Files

  1. The <ESS_HOME>/cache dir, where the device software files are cached, has been moved to <ESS_HOME>/.tmp/.deviceFileCache.
  2. The place where the device software jar file is unzipped (staged) was previously in a temporary folder under the system temp dir, but has now been moved to <ESS_HOME>/.tmp/.deviceFileStaging.
  3. The place where plugins are staged during run time was previously in a temporary folder under the system temp dir, but has now been moved to <ESS_HOME>/.tmp/.deviceFileStaging

Other

  1. The name of the executable jar for command line utilities has changed from "ess-lib-util.jar" to "ess-command.jar". For example, to run a database script, you will now do this:
  2. <ESS_HOME>/etc/wrapper.conf no longer is required to have numbered entries be in strict numerical order without gaps. In the past, when adding Java Additional Parameters, for instance, you had to number them consecutively. This is no longer needed and the default wrapper.conf now has these parameters organized into logical groups.
  3. JConsole is now included with the Java Runtime Environment installed with the ESS and the MBean support for monitoring Jetty is configured by default. New installations as of 2.6 include the lines needed to enable monitoring with JConsole commented out in the Java Additional Parameters section of jre/bin/java -Xmx1024m -jar lib/ess-command.jar ExecuteScript --script somescript.sql <ESS_HOME> /etc/wrapper.conf. For new installations, monitoring with JConsole merely requires uncommenting three lines from wrapper.conf, restarting the ESS, and starting JConsole (<ESS_HOME>/bin/jconsole).

Â