***********************************
*           XWHEP-7.4.0           *
*---------------------------------*
* Release date : 23 fevrier 2011  *
* Author : Oleg Lodygensky        *
*          lodygens@lal.in2p3.fr  *
***********************************


This version dramatically improves performances.
This version introduces corrections and new features for performance improvements only.

-A- Corrections
-A.1- The communication layer now accepts both connected and non connected mode
      The default is as it used to be : non connected mode (one message per socket)
      But the communication layer can now be used in connected mode : it accepts up to 2000 messages per socket.
      To protect the platform against too easy DoS attacks, the server :
        * closes socket after 2000 messages (the client is written so that it is transparent)
        * sets a socket time out (SOTIMEOUT from config file)


-B- New features
-B.1- amount of simultaneous connections to DB is now read from server config file
-B.2- introducing SORETRIES (from config file) : max times trying to connect on socket error
-B.3- reintroducing (from former versions 5) write through cache in front of DB to improve perfs
-B.4- reintroducing (from former versions 5) pool of TCP and DB handlers to reduce malloc/dealloc


-C- Known Bugs

-C.1- Result download errors reported using 'xwdownload', but not with 'xwresult'
  We have not been able to reproduce them
  If you encounter these, please send us log file in DEBUG mode
-C.2- xtremweb.gmond.pl does not scale
-C.3- windows 7 not supported
-C.4- the scheduler is not fair
-C.5- there may be some concurrent access problems leading to some errors
      There may be two concurrent accesses problems
        - on server side, DB access may lead to inconsistency between works and tasks tables
	  This could certainly be solved using SQL transactions
	  But we would then need MySQL >=5
	  There are sime issues withe transactions with hsqldb
	- on worker side, file access if a worker is configured to run jobs in parallel (default one thread per CPU core)

	We have observed that these concurrent access problems may lead to up to 6% erroneous jobs.
	Until further notification, we consider this rate acceptable.


- Versionning -

Versionning is as follow
	- X is a major part of the version
	- Y is a minor part of the version
	- Z is the micro part of the version

(*) X reports a very important change : for example the communication protocol changes or a major new feature is modified/introduced/removed
When X changes, backward compatibility is not ensured

(*) Y reports a important but not critical change : backward compatibility is ensured

(*) Z reports a minor change : bug correction, documentation changes etc.