[Zope] [Report] SQLRelay experiences

[Dieter Maurer]

Recently, I promoted SQLRelay <http://www.firstworks.com>
a bit: as a means to connect from Unix to an MS SQL Server.
I now have more experience that I want to share:

  SQLRelay seems quite complex and very sensible to disruptions.

  It consists of a set of processes that communicate via
  shared memory and synchronize via semaphores.
  These communication resources are allocated and initialized
  by the first process that needs them.

  This works fine when everything goes well. However, when
  there are faults causing a process to abort, the
  semaphores are in an inconsistent state and almost
  surely, you will get a deadlock.
  As SQLRelay is very quiet, the deadlock may not be
  obvious. In case of a deadlock, it is necessary
  to delete the communication resources manually (using
  "ipcs" and "ipcrm").


SQLRelay has problems with processor architectures that
have alignment requirements (such as e.g. SPARC):

  When writing the communication ports into shared memory,
  it may make a word access on a byte aligned address.
  This will give a SIGBUS exception when the processor
  does not support such accesses. The process dies
  and the semaphores become inconsistent.


Rudiments, a base of SQLRelay, has some "short read issues" (at least
when used together with SQLRelay):

  It assumes that when a writer writes an n byte message,
  then the reader will be able to read this entire n byte
  message in a single read.
  But this is not guaranteed by Unix. It may split the message
  in many subpackets.
  
  SQLRelay raises an error in this case: something went wrong.
  You can choose from about several dozen possible reasons.

  When it does, it seems that some data structures are not in a
  clean state, such that destructors can enter infinite
  loops, crash or release indeterminate memory.


I will package some patches addressing some of the issues
above and submit them to Firstworks.


Dieter