| VOV-18212 |
Accelerator |
CS0612030, CS0667075 |
Fixes an issue with Accelerator DP jobs. Occasionally, one of the partial jobs would hang and not start. |
| VOV-18266 |
All |
CS0691078 |
Control of the internal REST/HTTP server was made asynchronous to avoid potential deadlock
scenarios when the HTTP port was under heavy load from web/cgi clients. Users will
note that changing some HTTP related settings via vovservermgr
config may happen after the command returns.
httpserver.log will contain more verbose logging of the HTTP
server configuration changes. |
| VOV-18334 |
Accelerator Plus |
CS0670861, CS0685590 |
Fixed a bug that caused a stalled bucket after restarting vovwxd with a
modified CONFIG(tasker,max) parameter. |
| VOV-18380 |
FlowTracer |
CS0675981, CS0736393 |
Fixed issue which could cause auto rescheduled jobs to attempt to run multiple instances of
the same job simultaneously, resulting in failures. |
| VOV-18409 |
Accelerator Plus |
CS0657184 |
Fixed a bug in wxagent that caused a "Tcl version conflict" error when running with an old (2021.1.1) version of the base queue. |
| VOV-18428 |
All |
None |
Fix an issue whereby the VOV project metrics staging directory in
/tmp/<PROJECT>* was not deleted by
vovproject destroy. With the fix, the vovproject
destroy" operation will remove this /tmp
directory as long as vovproject destroy is executed on the host
where the VOV project server had been running. |
| VOV-18455 |
Accelerator, Accelerator Plus |
None |
Fixed an error which caused a failure to establish a pty connection for an interactive job to
disconnect/reconnect the controlling client from vovserver. |
| VOV-18492 |
Accelerator Plus |
CS0685590 |
Fixed an issue in Accelerator that caused foreign buckets (Direct Drive) coming from an
Accelerator Plus queue to not honor a new CONFIG(tasker,max) setting from
vovwxd when vovwxd was restarted. This
could cause buckets to get stuck when the parameter was increased after a restart
of vovwxd. |
| VOV-18541 |
Monitor |
CS0690013 |
Fixed an issue in Monitor with the listing of alphanumeric checkout handles. The fix was
achieved by converting the Handle column of PostreSQL DB to CHAR size 20. This
allows alphanumeric values of Handle to be stored properly. An existing Database
will be converted on next vovdb_util startdb call. |
| VOV-18544 |
Accelerator, Accelerator Plus |
CS0691023 |
Fixed issue when submitting jobs via nc run with both the
-array and -atomic options which broke
quote wrapping resulting in unrunnable jobs. |
| VOV-18572 |
Accelerator |
CS0650887, CS0719377 |
Improved vovserver hostname lookups with retry throttling, skip patterns, and max retry
limits. Previously, failed hostname resolutions would be retried frequently. With
this change, a 60 second (by default, see hostnameResolution.baseRetryInterval
below) delay will be inserted between hostname resolution attempts. New server
configuration parameters are introduced to allow tuning of the hostname lookup
behavior when failures to resolve are encountered. The new server configuration
parameters added are as follows:
- hostnameResolution.baseRetryInterval
Base delay (in seconds) between
failed hostname resolution attempts, increasing linearly with each attempt.
(Default is 60 seconds)
- hostnameResolution.maxAttempts
Maximum number of hostname resolution
attempts per hostname. -1 means keep trying indefinitely. 0 means never try
to resolve hostnames. (Default is -1)
- hostnameResolution.skipRegex
Never try to resolve hostnames that match
this regex pattern. For example the following matches all hostnames
beginning with "dockit" or "example" (case-insensitive) --
"^(DOCKIT|example).*" . The empty string value "" matches nothing, which
means that no hostnames will be skipped. (Default is "")
- hostnameResolution.failUponReachingMaxAttempts
If set to 1, exit vovserver
if hostname is still unresolved after hostnameResolution.maxAttempts
attempts. (Default is 0) (Setting to 1 is not recommended)
- hostnameResolution.clearUnresolvedCache
When set to any value, clears the
unresolved hostname resolution cache, thereby resetting failed resolution
attempt counts to 0.
|
| VOV-18580 |
Monitor |
CS0682621 |
Fixed a problem starting projects when Federal Information Processing Standards (FIPS) is
enabled. With some licensing modes, Accelerator, FlowTracer or Hero instances may
need to communicate license usage to Monitor. To ensure this works correctly in a
network environment where FIPS has been enabled, be sure to enable FIPS
consistently across all the project hosts. A FIPS enabled Accelerator, FlowTracer,
or Hero instance will be unable to communicate license usage to a Monitor instance
on a non-FIPS enabled host due to some cryptography restrictions. |
| VOV-18682 |
Accelerator |
CS0703571 |
Fixed an issue where taskers would release resources that had not yet been consumed when a
container's setup failed. |
| VOV-18724 |
Accelerator, Accelerator Plus |
CS0705500 |
Fixed an issue whereby jobs with container resources that were run with jetstreams enabled
would not activate the container hooks properly. |
| VOV-18730 |
Accelerator |
CS0709099 |
Improved partialTool monitoring of tasks started by the script, so that partialTool exits only after all the background tasks have completed. |
| VOV-18742 |
Accelerator, Accelerator Plus |
CS0709004 |
Fixed an issue in Accelerator Plus whereby a SIGSEGV abort in vovwxd could
occur when handling a deleted bucket connected with multiple queues. |
| VOV-18744 |
All |
CS0687196, CS0710232 |
Fixed a possible crash when issuing multiple delete requests for the same set. |
| VOV-18857 |
FlowTracer |
None |
Fixed a performance degradation in FlowTracer when building large flows, caused by WebSocket events. |
| VOV-18988 |
FlowTracer |
None |
Added documentation for a Flow Description Notation (FDN) REST endpoint. |
| VOV-19072 |
FlowTracer |
None |
Fixed an issue with Flow Description Notation (FDN) where error messages were returned even
for well-written flows in some cases. |
| VOV-19164 |
All |
None |
Fixed an issue that caused an SSL-enabled vovserver to hang when communicating with a slow client that was not able to keep up with the amount of messages being sent to it. |
