Release Note 20141021

Table of Contents

Features & Improvements

This is a summary of the new features and improvements introduced in this release:

Console: File Uploader Handling of Invalid Characters and Quoting

We improved the File Uploader’s CSV/TSV handling of:

  • characters with invalid encoding
    If a character with encoding not matching the selected one are encountered, the file uploader does no longer error out and exits but simply substitutes the character with a unicode replacement character (�).
  • invalid quoting
    often times the format of CSV/TSV files uploaded don’t adhere to the file format specifications, hence they are flagged as invalid. If quoting is not specified as expected, it’s now treated as regular character instead of causing the parsing to error out and exit.

Infrastructure: Disabled SSLv3 To Avoid POODLE Vulnerability

We updated all our client libraries, client tools, and Treasure Agent to forcibly disable the SSLv3 protocol when accessing the Treasure Data servers. This is done to avoid the recently uncovered SSLv3 protocol POODLE vulnerability. Additionally, all our instances and databases systems where upgraded to prevent use of SSLv3 protocol.

Untitled-3
SSLv3 was not disabled server side for backwards compatibility reasons.

Backend: Retrying for Result Output to S3

We implemented automatic retrying in case of failures occurring while outputting the result of a query to the specified S3 target.


Bug Fixes

These are the most important Bug Fixes made in this release:

APIs: Equally Named Tables Mishandling

  • [Problem]
    We identified a problem in the changes deployed in last week’s release (141014) that caused some table operations to be performed on the wrong table, if more than one table existed with the indentical name (in the another database since there cannot be two equally named tables in the same database). This problem did not affect the Console but only the REST API – hence only those users using the td CLI, Ruby and Java client libraries, etc…
    [Solution]
    The problem was caused by mistakenly not requiring that a table matching the required name be part of the requested database. Hence if more than one table with the same name existed, the table belonging to the database with oldest creation date was returned instead.
    We fixed the table lookup method to require the table to belong to the correct database. Analysis of the access logs showed us that the few users affected by this problem already worked around it, remedied by performing the operation via the Console or they were only negligibly affected.

Console: Accepting An Invitation Doesn’t Log the User In

  • [Problem]
    When a newly invited user confirms its email address by clicking on the Invitation email’s link, it’s not automatically logged in into the Console.
    [Solution]
    This a trivial issue with the application’s routing that did not redirect the user to the Console’s home (the /jobs page) after the confirmation link was visited.
    We made the confirmation endpoint redirect to the home page.

Console: Browser’s localStorage Size Limitation

  • [Problem]
    When the Browser’s localStorage (window.localStorage) quota is exceeded for a certain view, the page starts misbehaving and eventually prevents the page from loading.
    [Solution]
    The problem is occurring when the amount of storage necessary to store one or more copies of the view/page data exceeds the allotted quota. In that situation, the Console was not handling the quota exception and simply exiting with an error, hence the tab in which the page was loaded could not be shown.
    We added handling of the localStorage quota exception to ensure that when the quota is exceeded the previously stored copies for the view are purged from localStorage to recover storage space for the current view.

Backend: Datetime Inconsistencies for Result Output to MySQL

  • [Problem]
    Integer time values in the result of a query are converted to Datetime type improperly when the result is written to MySQL.
    [Solution]
    This is due to some of the Worker instances using a reference timezone different from UTC. When the integer time values are converted to Datetime types in MySQL, the worker’s instance timezone is assumed by default, which leads to the the Datetime value being incorrect when interpreted in UTC timezone.
    We modified all the Worker instances to make sure the reference timezone is always UTC, thus preventing this issue from occurring.

Last modified: Oct 25 2014 02:06:43 UTC

If this article is incorrect or outdated, or omits critical information, please let us know. For all other issues, please see our support channels.