Skip to content
  1. Nov 13, 2018
  2. Nov 08, 2018
  3. Nov 07, 2018
    • Grégory Mantelet's avatar
      [TAP] Fix memory issues for the 'text/plain' format. · 3e65794d
      Grégory Mantelet authored
      The previous text formatting process was storing the entire table in memory....
      hence OutOfMemoryError when dealing with large table.
      Now, this process is done entirely in memory only for a table having less than
      1000 lines. For a larger table, its content is stored in a temporary file. This
      file is deleted after usage or in case of error.
      This formatting process has been tested under JVM monitoring (both JConsole and
      VisualVM) and tables larger than 3,000,000 rows, with success.
      This commit fixes the GitHub issue #40
  4. Nov 02, 2018
    • Grégory Mantelet's avatar
      [TAP] Fix cancellation of a text formatting process. · f912c20a
      Grégory Mantelet authored
      Before this fix, cancelling a TAP job (async or not) which was formatting the
      result in ASCII may failed, especially for large results. This was due to a
      non interruptible alignment process. This process is now checking whether a
      cancellation has been requested before formatting a new result line/row ; if so,
      the process is immediately stopped and the job can be cleaning declared as
  5. Oct 26, 2018
    • Grégory Mantelet's avatar
    • Grégory Mantelet's avatar
      [TAP] Fix the TAP_SCHEMA mapping. · a5406513
      Grégory Mantelet authored
      When defining in the configuration file a different name for TAP_SCHEMA content,
      the service implementor was also forced to define the same mapping in the
      database with the column `dbName`.
      This is no longer necessary. From now on, the `dbName` column will be ignored
      for all standard TAP_SCHEMA content. Instead, the name specified in the
      configuration file (if any) will be used instead. This way, the mapping for
      standard TAP_SCHEMA content is only specified once and at only one place:
      the configuration file.
      _This commit resolves the GitHub issue #98_
  6. Oct 22, 2018
  7. Sep 05, 2018
    • Grégory Mantelet's avatar
      [UWS,TAP] Fix the configuration file for the UPLOAD feature. · 7bd91a1c
      Grégory Mantelet authored
      The property `upload_default_db_limit` has been deprecated. Indeed, in the
      current state of the TAP protocol, this makes no sense: the user can not change
      the limit size (in bytes or rows) for uploaded tables.
      The property `upload_max_file_size` has been deprecated. It is actually
      duplicated: `upload_max_db_limit`, if expressed in bytes already lets put a
      limit on the maximum size of an uploaded table/file.
      The property `upload_max_request_size` has been added. It lets set a maximum
      size for a whole HTTP Multipart Request. By default it is set to 250MB.
      The default value of `upload_max_db_size` is now 1 million rows.
      The UPLOAD feature is still disabled by default (i.e. `upload_enabled=false`).
    • Grégory Mantelet's avatar
      [UWS,TAP] Fix destruction of a job: error files were never deleted. · 02a4a7f5
      Grégory Mantelet authored
      This bug occurred "just" due to an un-desired inverted test, since UWS-1.1 is
      implemented (UWSLib-4.3 and TAPLib-2.2).
  8. Aug 21, 2018
  9. Aug 20, 2018
  10. Aug 10, 2018
    • Grégory Mantelet's avatar
      [TAP] Return a clear error message in case of duplicated items in UPLOADs. · e447a487
      Grégory Mantelet authored
      Before correction, if two uploaded tables have been submitted by the user with
      the same name, or if one uploaded table contained duplicated column names, an
      obscure error message coming from the database was returned to the user.
      Now, duplicated items (tables and columns) are searched before ingestion in the
      database. When one is detected, an error is immediately returned to the user and
      the query is aborted.
    • Grégory Mantelet's avatar
      [TAP] Fix disk space consumption with UPLOAD for synchronous jobs. · 25f373f6
      Grégory Mantelet authored
      Files uploaded by the user when creating/executing a synchronous job were never
      deleted after the job execution.
      The same problem applied for the tables already uploaded in the database (in
      `TAP_UPLOAD`) when an error occurred before the end of the UPLOAD process.
      Now, in case of error when uploading one or more files, or in case of success of
      the job, all uploaded files and their corresponding database tables are deleted
      after the end of the job.
    • Grégory Mantelet's avatar
  11. Aug 07, 2018
  12. Jul 30, 2018
    • Grégory Mantelet's avatar
      [UWS] Fix recurrent ConcurrentModificationException during service overload. · ded9cead
      Grégory Mantelet authored
      This error occurred generally during the backup process while trying to
      backup the job list of a specific user. If several of his jobs were running
      and changing state during the backup process, this
      ConcurrentModificationException was thrown. This generally happens when the same
      user submits a lot of shorts jobs in the same time.
      This exception was due to a non thread-safe usage of
      UWSParameters.additionalParams. To fix this issue, instead of creating it as a
      normal HashMap, it is now created as a ConcurrentHashMap.
      The same modification has also been applied to UWSParameters.params. In addition
      of the replacement of HashMap into ConcurrentHashMap, all `synchronized` blocks
      have been removed....there should not be needed any more.
  13. Jul 27, 2018
    • Grégory Mantelet's avatar
      [UWS,TAP] Fix the weekly log file rotation. · 1f4bc6b1
      Grégory Mantelet authored
      When enabled, it was generating a file each minute on the day before the
      specified day of week.
      For instance: if the log rotation frequency was `W 1 0 0` (so, weekly on Sunday
      at 00:00). The rotation was performed on Saturday midnight. But, because of a
      bad index correction, the rotation kept going on the whole day of Saturday.
      Since the rotated file is suffixed by the timestamp with hours and minutes
      (no seconds), it actually generated a new log file for each minute of the
      saturday. Of course, each time the file contained only one line (or 2 with some
      luck)...which is pretty useless.
  14. Jul 04, 2018
  15. Jul 03, 2018
  16. Jul 02, 2018
    • Grégory Mantelet's avatar
      [UWS,TAP] Fix the backup file writing. · 474da7f4
      Grégory Mantelet authored
      Instead of writing the new backup content in the final backup file directly,
      write it first in a temporary file and then change the files name.
      This fix prevents incomplete backup files (particularly in case of one backup
      file per user) when stopping/restarting by force.
  17. May 18, 2018
  18. May 09, 2018
  19. Apr 23, 2018
  20. Apr 09, 2018
  21. Mar 21, 2018
  22. Mar 07, 2018
    • gmantele's avatar
      Fix UDF parsing from the configuration file. · 96df1d5a
      gmantele authored
      The end of the description of a UDF was not detected when this UDF was followed
      by another UDF definition. This was due to an incorrect double quote escape in
      the regular expression of a UDF's definition.
  23. Mar 02, 2018
    • gmantele's avatar
      [UWS] Fix Javadoc · a959db1f
      gmantele authored
    • gmantele's avatar
      [UWS] Fix the quote serialization. · 855a805b
      gmantele authored
      The UWS-1.x standard defines the quote as an ISO-8601 date. UWS-Lib stores it
      as a number of seconds (i.e. estimated job duration).
      This fix ensures that this integer/long quote value is returned as a date.
      Note: The backup and restoration processes are not affected by this change.
            The backup file format is still the same: a quote stored as a long value.
  24. Feb 26, 2018