Version 0.2

Critical Issues

• None at the moment.

Severe Issues

• No checks on object type when opening it.

  There is no validity check for the type of object when opening it. In other words, vdsHashMap::Open( "Name of a queue" ) will succeed in opening the queue.

  This issue is for both the C APi and the C++ API. It is resolved in subversion (revision 530).

• Crashes when using objects after session exit

  Attempts to use objects like queues and maps, after the session they belong to exited, provoke crashes (memory violations).

  This issue is for both the C APi and the C++ API. It is resolved in subversion (revision 534).

Other Issues

• No i18n for Windows.

  This issue will be looked at before the next release.

Version 0.1

Critical Issues

• Watchdog cannot use an existing shared memory.

  The watchdog cannot use an existing VDS (shared memory) - it simply exits (no error message but this is another issue). A simple "if" gone wrong (the test was inversed):

  In src/Watchdog/VDSHandler.cpp, replace lines 195-196

  if ( fileStatus.fileReadable && fileStatus.fileWritable && fileStatus.lenghtOK )

  with

  if ( ! fileStatus.fileReadable || ! fileStatus.fileWritable || ! fileStatus.lenghtOK )

  This bug is fixed in subversion (revision 374).

Severe Issues

• Memory leak in the engine

  Explanation: if an object was not deleted during a commit or a rollback because of a reference counter being non-zero, the object "destructor" (Fini() functions) was never called later on when the reference counter went to zero (the entry in the hash of the folder was removed, hidden the problem somewhat).

  Fix in subversion, revision 396.

• The top folder ("/") cannot be opened.

  The function calls vdsFolderOpen() and vdsGetStatus are failing with the error "invalid name" when trying to access the folder "/", at the top of the hierarchy.

  This bug is fixed in subversion (revision 401).

Other Issues

• Reference counters are not reset at startup.

  Any programs that quits while still holding resources will leave the VDS in a corrupted state. A crashed application will likely do this. As would any application that exit without calling vdsExitSession (or at least vdsExit).

  Current workaround: none. You must remove the VDS and start over. This issue was resolved for version 0.2.

• Missing RunQueue.sh from vdsf-0.1.0.tar.gz

  This file is used to run the Queue examples and is missing from the tar file. You can get a copy here (revision 343 or later).

Last updated on April 07, 2008.