nats-io / nats-streaming-server
94%
main: 92%

LAST BUILD BRANCH: add-eol-note
DEFAULT BRANCH: main
Repo Added
Files 24
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH handle_zeros_at_end_of_files
branch: handle_zeros_at_end_of_files
CHANGE BRANCH
x

1232

push

travis-ci

kozlovic 
[IMPROVED] Handle end of files filled with null bytes

There have been 2 reports that server fails to start due to a
subscription record of type 0, which is not possible. Without
access to store files, the suspicion is that the file has for some
reason zeros at the end of the file. If there are enough zeros to
fill the record header (8 bytes), then the function readRecord()
would return no error but a record type of 0, which would cause
calling code to return an error.

Files that are recovered have now the following logic:
- If the expected record header (or message index record) is fully
  read but all zero, the file is rewinded to prior this record and
  truncated and no error is reported.
- If there is less bytes that needed, the "unexpected EOF" is now
  augmented with information about how many bytes were expected
  and how many were actually read.

With the second item on the list, one can possibly fix the file
by truncating it. For instance, suppose that the subscriptions
file for channel foo is 3 bytes too long. This can be artificially
done with:

truncate -s +3 datastore/foo/subs.dat

The server would report this failure:

[FTL] STREAM: Failed to start: unable to recover subscription store for [foo]: unexpected EOF (record header expected to be 8 bytes, only read 3)

Truncating the file (reverse command) would allow the server to
properly recover:

truncate -s -3 datastore/foo/subs.dat

If there were more than 8 null bytes, the server would correctly
truncate the file and not even report an error. That is, say that
you stop the server and issue the following command:

truncate -s +13 datstore/foo/subs.dat

The server should not have a problem starting. Without this fix,
it would complain about unknown record type:

[FTL] STREAM: Failed to start: unable to create subscription store for [foo]: unexpected record type: 0

Resolves #440

8345 of 8923 relevant lines covered (93.52%)

48140.4 hits per line

Relevant lines Covered
8923 RELEVANT LINES 8345 COVERED LINES
48140.4 HITS PER LINE
Source Files on handle_zeros_at_end_of_files
Coverage ∆ File Lines Relevant Covered Missed Hits/Line

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
1232 handle_zeros_at_end_of_files [IMPROVED] Handle end of files filled with null bytes There have been 2 reports that server fails to start due to a subscription record of type 0, which is not possible. Without access to store files, the suspicion is that the file has for some r... push kozlovic travis-ci pending completion  
See All Builds (1649)