WWS Redesign

Motivation

• Improve stability. WWS occasionally leaks CommandHandlers. Every concurrent request requires a dedicated handler, thus each lost handler reduces the number of requests that can be fulfilled concurrently. As the number of handlers drops, WWS responsiveness also drops and some requests are unable to be fulfilled before the client times out. When the pool is completely exhausted, WWS stops fulfilling client requests until it has been restarted. This problem has been seen on multiple systems and is the primary failure mode of the pubavo1 wave server. Some causes of leaked handlers have been fixed, but more remain and those have proven elusive.
• Clients retain exclusive use of database connections until all data has been returned to the client. This causes clients communicating over slow or unreliable connections to slow apparent server responsiveness as seen by other clients. This has resulted in field staff experiencing difficulties accessing data while in the field.
• Bugfixes and new features have been added over the course of many years, exposing architectural trade-offs that no longer suit current usage.
• Limited HTTP support requires that all data be retrieved from the database before results can be returned to the client. This imposes a varying and unpredictable limit on the size of data requests that can be filled.
• Reduce the surface area of WWS code. There are now widely used, and well tested, libraries which provide similar services to portions of the Winston codebase. Using those libraries may make Winston easier to test and provide options to improve performance.

Externally visible changes

• -i and --no-intput flags are no longer supported. WWS will now auto-detect the presence of a console and do the right thing.
• A skeleton of Markdown-based documentation is in place. Documentation can be browsed in the source repository or through WWS.

Internal changes

• Home-grown network code has been replaced with Netty.
• Full HTTP support provided by Netty allows data to be returned to clients in chunks. This will allow support of arbitrary length data requests over HTTP to be added via FDSNWS.
• Commands no longer retain a database connection while sending data to a client. Database connections are pulled from a pool when database interaction is needed and returned as soon as the required queries have completed. This improves utilization of database resources, a common bottle neck for Winston installations.
• New classes are smaller and less complex. Specifics to be added once coding is complete. New packages have significantly reduced NCSS and CCN.