Re: [Quickfix-developers] Semi OT : QF internal data hotbackup

[Jain, A. <Ani...@rb...>]

Oren Miller wrote:
> QuickFIX does a write and flush with every message as it is stored.

On Soalris 8 with NFS, I'm not sure, how effective is std::flush which is d=
one with every message for it's FileLog files. I know of one instance where=
 all dozen or so instances of QF FileLog files lost their tail part, on fil=
e system full error. I did not look into FileStore files, as we do not use =
it for recovery/resend.
The sequence number file is flushed with std::fflush, still the sequence we=
 recovered was out of quie old.
Maybe NFS cache takes over here and does actual physical writes based on it=
's own cache usage configuration.

It would be interesting to know the effectiveness of fsync(3C)/fdatasync(3R=
T) in such situation.

Caleb Epstein wrote:
> Rather than complicating the FileStore, wouldn't a better solution be
> to use one of the more "transactional" message stores, like the
> MySQLStore, or the OdbcStore backed by <pick your database>?

Looks like an interesting solution, if not for real time, then atleast for =
subsequent quick availability of messages in non-NFS systems. Or maybe fssn=
ap will be sufficient, for situation not requiring all those lots of featur=
es that come with MySQL etc?

Anil Jain
_______________________________________________________________________

This E-Mail (including any attachments) may contain privileged or confident=
ial information.  It is intended only for the addressee(s) indicated above.
The sender does not waive any of its rights, privileges or other protection=
s respecting this information. =20
Any distribution, copying or other use of this E-Mail or the information it=
 contains, by other than an intended recipient, is not sanctioned and is pr=
ohibited.
If you received this E-Mail in error, please delete it and advise the sende=
r (by return E-Mail or otherwise) immediately.

This E-Mail (including any attachments) has been scanned for viruses.=20
It is believed to be free of any virus or other defect that might affect an=
y computer system into which it is received and opened.=20
However, it is the responsibility of the recipient to ensure that it is vir=
us free.=20
The sender accepts no responsibility for any loss or damage arising in any =
way from its use.

E-Mail received by or sent from RBC Capital Markets is subject to review by=
 Supervisory personnel.=20
Such communications are retained and may be produced to regulatory authorit=
ies or others with legal rights to the information.