Notes

Tick History successfully provides your calling program with the entire output file. Therefore,
Tick
History does not generate an error.
The problem is with how your HTTP client handles that output file. In most cases, an HTTP client
that does not support concatenated gzip files does not generate an error message when it fails to
process part of a concatenated file. The HTTP client therefore “fails silently.” You will not be
aware that your client did not read and decompress some of your output, unless you notice a
difference in the expected size of the file, or unless you notice that data which you had expected
to see is missing.
Note that some HTTP clients, such as the native Java client, are inconsistent with respect to
whether they fail to fully decompress a concatenated gzip file. This means that even if your HTTP
client delivers all the decompressed output to you some of the time, there is no guarantee that it
will do so all of the time.
• How can I find out if my HTTP client or decompression function supports concatenated gzip
files?
If your HTTP client’s documentation, or your decompression function’s documentation, is not
explicit about its support, the safest choice is to disable decompression in your client, and to
switch to a decompression function that explicitly supports concatenated gzip files.
But if you want to test your client or function, we recommend that you do so with concatenated gzip
files of known size and content, and that you run the test multiple times to account for clients or
functions that fail inconsistently.
• What if my HTTP client does not support concatenated gzip files?
There is a simple workaround:
1. Disable decompression in your HTTP client.
2. Download the gzip file using your HTTP client.
3. Decompress the gzip file using a function that supports concatenated gzip files.
Confirm that the access method (such as Read Line, or End of Stream Asynchronous) that you use to
read the downloaded gzip stream into the decompression function works
at function in your environment.

Thomson Reuters Tick History REST API Advisory: Avoid Incomplete Output by Decompressing After
Downloading Page 3 of 6
You can decompress a concatenated gzip file using the transient-streaming method or the
persistent-streaming method. We recommend decompressing it using the transient-streaming method for
better performance. However, if you need to save a copy of the gzip file (for example, as a
backup), then you may want to decompress it using persistent streaming.
The sections below provide code examples and suggested decompression functions for C# and Java. If
you use a different language, you need to find a decompression function that supports concatenated
gzip files.
• Is this a concern when I use the Tick History GUI?
This is not a concern when you generate Tick History reports using Tick History’s web-based
graphical user interface (GUI). When the GUI delivers a gzip output file to you, you use a gzip
tool to directly decompress the gzip file. Such tools always support concatenated gzip files.

Transient Streaming and Persistent Streaming
This is a generic description of these two methods of processing a decompression stream. Your
process and your performance may vary from what is described here due to the specifics of your
environment.
• Transient streaming:
HTTP client → decompression stream → output stream
Merged gzip files are read and processed sequentially via streaming without caching. This method is
faster and uses fewer resources than persistent streaming, because it does not maintain a lock on
the memory used for each read.
In Java, you could use GzipCompressorInputStream to implement transient streaming.
• Persistent streaming:
HTTP client → memory stream → decompression stream → output stream
The complete gzip file is stored in memory before decompressing it, enabling you to make a copy of
it to back up or use later. However, this memory cannot be reclaimed until the entire file has been
read and the stream has been closed, making the persistent streaming method more resource
intensive.
By the end of the decompression process, you would have allocated and locked memory corresponding
to the size of the entire compressed gzip file and the entire decompressed file, if you choose to
decompress the file at the same time.
On tests performed with a 1MB compressed file, decompression using persistent streaming was two to
three times slower than using transient streaming.
In Java, you could use ByteArrayOutputStream to implement persistent streaming.