Ticket #590 (new enhancement)

Opened 3 years ago

Changes to wave_serverV

Reported by: baker Owned by: somebody
Priority: minor Milestone: All Platforms
Component: wave_serverV Version: 7.9
Keywords: Cc:

Description

In the past couple days I have made several changes to wave_serverV to fix logic errors and to change the amount and format of log messages. These include:

• Increase the length of the maximum tank file path to 255 (the minimum POSIX PATH_MAX) [r7012]
• Terminate the server thread when the main program has been terminated [r7014]
• In the writer thread, always hold the tank mutex when changing any part of the TANK struct (i.e., when closing the file) or the tank contents [r7018]
• Reset the tank file pointer to NULL when it is closed to prevent the server thread from using an invalid file pointer [r7018]
• In the server thread, always hold the tank mutex when reading any part of the TANK struct or the tank contents [r7019]
• Tank metadata (i.e., sample rate, data type) is not valid for an empty tank [r7019]
• In the server thread, return R_FAIL immediately in GetOffset?() instead of continuing [r7019]
• Use <S.C.N.L> SCNL format in messages for consistency [r7017, r7020]
• Use logit "et" for error messages, "t" for debugging messages and client-caused error messages [r7017, r7020]
• Log the client IP address for both the connection and disconnection [r7020]

The server thread writes a lot of error messages for client-caused conditions. Such as, when the client requests data from an empty tank, or requests data outside the time range of available data. These error messages are misleading since the wave_serverV is behaving correctly. These messages are noise on the Earthworm server system. I changed the server thread logit() request types so that they never appear on the console; they only appear in the wave_serverV log file(s). I suggest they be disabled unless debugging is enabled. They really belong in the client-side application.

Also, there is no indication in the log file of the server thread number. This makes it difficult to trace problematic client transactions. This is a general problem with log messages. Perhaps this can be dealt with in a general way in logit().

Except possibly when a module is first starting up, I recommend all log messages be time-stamped. This makes it much easier to trouble-shoot transactions between different modules or other clients.

Note: See TracTickets for help on using tickets.