Changes between Version 1 and Version 2 of v5.1


Ignore:
Timestamp:
01/19/12 16:36:08 (10 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • v5.1

    v1 v2  
    194194Wave_serverV: If a tank file is closed by the main thread while a server thread is accessing it, the next I/O error that the server thread saw would send it to the "abort" section of _writeTraceDataAscii or _writeTraceDataRaw. Here a call to fseek() would fail and lead to an endless loop of failed fseek calls. 
    195195 
    196 Startstop_solaris: There MAY be a problem with the signal that startstop sends to modules during the shutdown sequence. The shutdown sequence is started (after typing "quit" to startstop or running "pau") by startstop placing a terminate message on all transport rings. Modules should see this message and start their own shutdown. After a configurable delay, startstop checks to see that all modules have exitted. Any that are still running are sent a signal to terminate them. Currently that signal is SIG_TERM. But since wave_serverV has a handler for SIG_TERM, wave_serverV sees that as essentially the same as a terminate message. So if wave_serverV is having problems completing its shutdown, SIG_TERM won't do anything. The result is that startstop may give up and exit, leaving wave_serverV running. If that happens, the operator will have to terminate wave_serverV by doing "kill -9 <wave_serverV-pid>". That may leave shared memory and semaphores stranded in the kernel: run the command "ipcs -a" to see. If necessary, the stranded shared memory and semaphores may be cleaned up with the ipcrc command; must be run as root; see the man page. This problem only exists on Solaris/Unix, not on WindowsNT. 
     196Startstop_solaris: There MAY be a problem with the signal that startstop sends to modules during the shutdown sequence. The shutdown sequence is started (after typing "quit" to startstop or running "pau") by startstop placing a terminate message on all transport rings. Modules should see this message and start  
     197their own shutdown. After a configurable delay, startstop checks to see that all modules have exitted. Any that are still running are sent a signal to terminate them. Currently that signal is SIG_TERM. But since wave_serverV has a handler for SIG_TERM, wave_serverV sees that as essentially the same as a terminate message. So if wave_serverV is having problems completing its shutdown, SIG_TERM won't do anything. The result is that startstop may give up and exit, leaving wave_serverV running. If that happens, the operator will have to terminate wave_serverV by doing "kill -9 <wave_serverV-pid>". That may leave shared memory and semaphores stranded in the kernel: run the command "ipcs -a" to see. If necessary, the stranded shared memory and semaphores may be cleaned up with the ipcrc command; must be run as root; see the man page. This problem only exists on Solaris/Unix, not on WindowsNT. 
    197198 
    198199NUMBER OF RINGS LIMITED ON SOLARIS: