quickfix-developers Mailing List for QuickFIX (Page 240)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joerg T. <Joe...@ma...> - 2004-06-21 16:27:14
|
Hi Oren,
should it be
public class MDEntryDate extends UtcDate
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Brendan B. B. <br...@ka...> - 2004-06-16 14:28:12
|
Hello,
Wanting to dip my toe in XML parsing I decided to work w/QuickFIX's
DOM wrapper of {MS,LIB}XML to create a simple app which would walk
the document tree. In doing so I think I may have found a couple of
bugs.
1. Constructing a std::string based on a NULL ptr generates a
SIG<something> using gcc v3.3.x (Cygwin) and v3.4.0 (Fedora):
In DOMAttributes::map LIBXML_DOMAttributes::toMap()
{
...
#if 1
// brendan, 6/11/04
std::string name;
if (attr->name) name = (char*)attr->name;
#else
std::string name = (char*)attr->name;
#endif // #if 1
...
}
Same is true for:
std::string LIBXML_DOMNode::getName()
std::string LIBXML_DOMNode::getText()
2. Walking the tree is skipping nodes:
DOMNodePtr LIBXML_DOMNode::getFirstChildNode()
{
if( !m_pNode->children ) return DOMNodePtr();
// brendan, 6/12/04
// xmlNodePtr pNode = m_pNode->children->next;
xmlNodePtr pNode = m_pNode->children;
...
}
DOMNodePtr LIBXML_DOMNode::getNextSiblingNode()
{
if( !m_pNode->next ) return DOMNodePtr();
// brendan, 6/12/04
//xmlNodePtr pNode = m_pNode->next->next;
xmlNodePtr pNode = m_pNode->next;
...
}
3. Incorrect QF_PUSH_STACK e.g.
DOMNodePtr LIBXML_DOMNode::getFirstChildNode()
{ QF_STACK_PUSH(LIBXML_DOMAttributes::getFirstChildNode)
This is true for LIBXML_DOMNode and LIBXML_DOMDocument.
If I'm incorrect, please feel free to set me straight.
Thanks!
Brendan
|
|
From: Frano I. <fi...@fi...> - 2004-06-16 14:20:36
|
Hi Orwen... Thanks for your answer... My question was motivated by my will to master the Qnx development tools. So I would investigate on how to run QuickFix on this platform. I will post back to the list if I achieve something... Frano Frano ILICIC Transcribe>WORLD Limited Mail : fi...@fi... Web : http://file-saveas.com Tel Gibraltar : Tel Espana : +34 956 25 49 08 Fax Espana : +34 956 25 49 08 Tel France : +33 (0)610 185 369 > -----Original Message----- > From: Oren Miller [mailto:or...@qu...] > Sent: mercredi 16 juin 2004 11:41 > To: Frano ILICIC > Cc: qui...@li... > Subject: Re: [Quickfix-developers] QuickFix and QNX > > Yes. I have for a while believed that QNX would be an ideal OS for > running trading systems. I was seriously looking into this and > attempted a port about a year ago. At the time however they were still > using a compiler based on gcc v2.95, and there were some shortcomings. > I decided to put it on hold until a 3.x version came out. This was > taking them a long time so it fell off my radar. It looks like now > they have one so I may revisit this at some point. It may very well > compile without any modifications now (the automated tests can verify > if all is good), but have not tried this myself. > > --oren > > On Jun 16, 2004, at 2:43 AM, Frano ILICIC wrote: > > > QuickFIX Documentation: > > http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html > > > > Hi, > > > > I just wondered if anybody has ever envisaged running QuickFix(not java > > distrib) on the QNX os? Just curious > > > > > > > > Thanks in advance > > > > Frano > > > > > > > > Frano ILICIC > > Transcribe>WORLD Limited > > > > Mail : fi...@fi... > > Web : http://file-saveas.com > > > > Tel Gibraltar : > > Tel Espana : +34 956 25 49 08 > > Fax Espana : +34 956 25 49 08 > > Tel France : +33 (0)610 185 369 > > > > PGP PUBLIC KEY : > > mQGiBD27DucRBADTAvdHoAYGh493UIpuFcyFgglkv5Dsi3DNGJMdUyHeZDx/Z918 > > ZArIWtrBgDkH6oGNsu8oJ49waNU3D+oOE5sl3EWTa2rwi9mJSZ1Xufh13spIGLz8 > > TqjVF6ao+UMzD3zM9z/vpPF646hpIivCKLka/+7PLsKl+bora+VeBAxOiwCg/8DR > > zVaNfaunYQtxRRKWI4Qoz30D+wfmnh8DwpqRjokPe6HbtOwQpMssMmYr0hgIfvYg > > VIvm53Evqt+mIp7gXdNBDG3VnBtB/xowAn+MjCMlEw1RfuoI95mGxUZFqYbw3Poo > > eWOpyMOFrOFG/3nOfdAKWR3GBFmRogXFqDNb4kIqg+mbQ4jf8kV/0ahOzbs6aDI5 > > A6rcA/9WD2mHqqgkSe8L3G8/BbAhSHkqSineVAJzug4Pw6psCTV1taXr4XOzFUxw > > fMslCnkqEOYFdnLXsWen0Zwxuy+ayNfduy8wavOQ3Og3/HLDZ019kpSBzJziJ1D+ > > H7+k1pnHGhq498gLAEtc/V2P9kD8Cxd09Sd+t5C96vhPIPug6LQkZnJhbm8gSUxJ > > Q0lDIDxmcmFub0BmaWxlLXNhdmVhcy5jb20+iQBYBBARAgAYBQI9uw7nCAsJCAcD > > AgEKAhkBBRsDAAAAAAoJEFe4xnkok0cZXhcAnR3lY7jSdDGMaVSLk/WwQl/hcLAZ > > AKD6xq1dW7DBCevJ7Xi8mXjxc4NxG7kEDAQ9uw+xEA/6A6VO1cDyc0416wn7Cn5N > > ZYy8bHIFDG41Uz+XQtIQqREzKdEW/NS9Idy6WmEQuQcAop/gOdSA6cAL66/OItga > > T7YcWeZCuRF43VWnOm0C2AAS6Oi5sZJ3FDOSLQEwdlkWPl/O50fklOci9Pn0WSOI > > LKcbhulQsn3Qcb6SY2DpznnG2nvj68OnnKDYVV25Gzncx1lgOyt7kQbv21c2u+LS > > /qheLfewJ8zu3qKPUIVvHRqjgDwD1bTnIh1L7T2OprKtBKEJTekeIbYwzAl7/80J > > JaDNGnx/ah294FM6CH9jEKNqCWXhpMLN2QAMNO/pUmn4CIVvN1TcaFf804jcnZPu > > 9tkgQHa1DC9/RHZ8TUQzdRpWCtJyU5f+z3AU3qMYYn1eRvB/h7sWBsd2NjjZ5k1K > > BhO17LiYToix4hLjNY6dPGaY4Poe8MnFm3yY6QuYRVzQ726qncNyfLuTMrMYzNWy > > w2CWodzO4R5AIYVCpnERJn0qm7aR4zunjlXfP45gf19/wLACtILzownqzR/15dVC > > zws7a7BzdASrLhjE4CZJAIGxX5wu6Sdu1sBj6DDoh2pr8VQa7MaLsKdtuCVXOMbC > > aMa0bIvC9uJWDToFUyOcJP4a4SarXDiG2OvxkFIIqKBjHCAt+rpK/liUnS+1lH1+ > > gCh/rptFOCXbZTc5/aEbmecAAgIP+Ix29f9k33k1RHmLcnB2lOKvR62CPYzOE4Zd > > nI1lV+/moZ+IPxVdr2nTEfD4RPK3lvZ9HdKo6tScEM8Fi5XkQ5Y5aDFFvxY4jt3i > > IhfHz8Vg++6RzH69+xBNjSMKJkfjP6pUWelh3pJxZ8VmigsemHDKnH4njE9u0i0B > > ZGfYcDbauBgTSKy2GxW4PF55gu4jN1lfm4tHhbEQfPopi0FSlfHkL1AtPbHVc1v/ > > UyHe0ZHUrEf8ruuY5cEPhysCisQM6QsiZYJyFaKj2gc9Fp9tPrDnHOkRFuGYYXrj > > aX1/9/JGxrNirdieEoeWFDmTnFGKSgQxhCm3GhtrK+I+LDQtPLdSaHsgqtwnj/xT > > s3HnBQOfqPmvqtVApVfi2uIgxA/UoJJQzwqIfkhwwE+6upzirMjR+nTEdsxM+wzS > > Gm3QnYB4bpGQcyLVHVkN8/NhGF72HRo2r+QmKRkj7HL8iPV45+tP85AupdhTGFrJ > > D3DOTRRFOwt9v7urrLBM19kX7ZiHRw6pg6Ro8U/cnkOswBJo5BK/VvkBVNNCXI49 > > D0y4j9iaS9SWmeFO6cF2OG9BA2NGjVG0ogbE3S9ScSdYzMkaVQhN5kNo0sy8NZOG > > SNLeS/UxCdMGefLQ4thQjRW8+q6+xa0wEcPYGQNspuefOjE0X8cD4uIWjyVH8LAn > > SA02uuCJAEwEGBECAAwFAj27D7EFGwwAAAAACgkQV7jGeSiTRxklewCgkFqHBEjP > > Yf0OPH9C6qWpIsmB8/EAnR8hdAZj1N72q0YhoFC9YvKI+E90=Sv4k > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code > > NWMGYKND > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > |
|
From: Oren M. <or...@qu...> - 2004-06-16 10:41:37
|
Yes. I have for a while believed that QNX would be an ideal OS for running trading systems. I was seriously looking into this and attempted a port about a year ago. At the time however they were still using a compiler based on gcc v2.95, and there were some shortcomings. I decided to put it on hold until a 3.x version came out. This was taking them a long time so it fell off my radar. It looks like now they have one so I may revisit this at some point. It may very well compile without any modifications now (the automated tests can verify if all is good), but have not tried this myself. --oren On Jun 16, 2004, at 2:43 AM, Frano ILICIC wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html > > Hi, > > I just wondered if anybody has ever envisaged running QuickFix(not java > distrib) on the QNX os? Just curious > > > > Thanks in advance > > Frano > > > > Frano ILICIC > Transcribe>WORLD Limited > > Mail : fi...@fi... > Web : http://file-saveas.com > > Tel Gibraltar : > Tel Espana : +34 956 25 49 08 > Fax Espana : +34 956 25 49 08 > Tel France : +33 (0)610 185 369 > > PGP PUBLIC KEY : > mQGiBD27DucRBADTAvdHoAYGh493UIpuFcyFgglkv5Dsi3DNGJMdUyHeZDx/Z918 > ZArIWtrBgDkH6oGNsu8oJ49waNU3D+oOE5sl3EWTa2rwi9mJSZ1Xufh13spIGLz8 > TqjVF6ao+UMzD3zM9z/vpPF646hpIivCKLka/+7PLsKl+bora+VeBAxOiwCg/8DR > zVaNfaunYQtxRRKWI4Qoz30D+wfmnh8DwpqRjokPe6HbtOwQpMssMmYr0hgIfvYg > VIvm53Evqt+mIp7gXdNBDG3VnBtB/xowAn+MjCMlEw1RfuoI95mGxUZFqYbw3Poo > eWOpyMOFrOFG/3nOfdAKWR3GBFmRogXFqDNb4kIqg+mbQ4jf8kV/0ahOzbs6aDI5 > A6rcA/9WD2mHqqgkSe8L3G8/BbAhSHkqSineVAJzug4Pw6psCTV1taXr4XOzFUxw > fMslCnkqEOYFdnLXsWen0Zwxuy+ayNfduy8wavOQ3Og3/HLDZ019kpSBzJziJ1D+ > H7+k1pnHGhq498gLAEtc/V2P9kD8Cxd09Sd+t5C96vhPIPug6LQkZnJhbm8gSUxJ > Q0lDIDxmcmFub0BmaWxlLXNhdmVhcy5jb20+iQBYBBARAgAYBQI9uw7nCAsJCAcD > AgEKAhkBBRsDAAAAAAoJEFe4xnkok0cZXhcAnR3lY7jSdDGMaVSLk/WwQl/hcLAZ > AKD6xq1dW7DBCevJ7Xi8mXjxc4NxG7kEDAQ9uw+xEA/6A6VO1cDyc0416wn7Cn5N > ZYy8bHIFDG41Uz+XQtIQqREzKdEW/NS9Idy6WmEQuQcAop/gOdSA6cAL66/OItga > T7YcWeZCuRF43VWnOm0C2AAS6Oi5sZJ3FDOSLQEwdlkWPl/O50fklOci9Pn0WSOI > LKcbhulQsn3Qcb6SY2DpznnG2nvj68OnnKDYVV25Gzncx1lgOyt7kQbv21c2u+LS > /qheLfewJ8zu3qKPUIVvHRqjgDwD1bTnIh1L7T2OprKtBKEJTekeIbYwzAl7/80J > JaDNGnx/ah294FM6CH9jEKNqCWXhpMLN2QAMNO/pUmn4CIVvN1TcaFf804jcnZPu > 9tkgQHa1DC9/RHZ8TUQzdRpWCtJyU5f+z3AU3qMYYn1eRvB/h7sWBsd2NjjZ5k1K > BhO17LiYToix4hLjNY6dPGaY4Poe8MnFm3yY6QuYRVzQ726qncNyfLuTMrMYzNWy > w2CWodzO4R5AIYVCpnERJn0qm7aR4zunjlXfP45gf19/wLACtILzownqzR/15dVC > zws7a7BzdASrLhjE4CZJAIGxX5wu6Sdu1sBj6DDoh2pr8VQa7MaLsKdtuCVXOMbC > aMa0bIvC9uJWDToFUyOcJP4a4SarXDiG2OvxkFIIqKBjHCAt+rpK/liUnS+1lH1+ > gCh/rptFOCXbZTc5/aEbmecAAgIP+Ix29f9k33k1RHmLcnB2lOKvR62CPYzOE4Zd > nI1lV+/moZ+IPxVdr2nTEfD4RPK3lvZ9HdKo6tScEM8Fi5XkQ5Y5aDFFvxY4jt3i > IhfHz8Vg++6RzH69+xBNjSMKJkfjP6pUWelh3pJxZ8VmigsemHDKnH4njE9u0i0B > ZGfYcDbauBgTSKy2GxW4PF55gu4jN1lfm4tHhbEQfPopi0FSlfHkL1AtPbHVc1v/ > UyHe0ZHUrEf8ruuY5cEPhysCisQM6QsiZYJyFaKj2gc9Fp9tPrDnHOkRFuGYYXrj > aX1/9/JGxrNirdieEoeWFDmTnFGKSgQxhCm3GhtrK+I+LDQtPLdSaHsgqtwnj/xT > s3HnBQOfqPmvqtVApVfi2uIgxA/UoJJQzwqIfkhwwE+6upzirMjR+nTEdsxM+wzS > Gm3QnYB4bpGQcyLVHVkN8/NhGF72HRo2r+QmKRkj7HL8iPV45+tP85AupdhTGFrJ > D3DOTRRFOwt9v7urrLBM19kX7ZiHRw6pg6Ro8U/cnkOswBJo5BK/VvkBVNNCXI49 > D0y4j9iaS9SWmeFO6cF2OG9BA2NGjVG0ogbE3S9ScSdYzMkaVQhN5kNo0sy8NZOG > SNLeS/UxCdMGefLQ4thQjRW8+q6+xa0wEcPYGQNspuefOjE0X8cD4uIWjyVH8LAn > SA02uuCJAEwEGBECAAwFAj27D7EFGwwAAAAACgkQV7jGeSiTRxklewCgkFqHBEjP > Yf0OPH9C6qWpIsmB8/EAnR8hdAZj1N72q0YhoFC9YvKI+E90=Sv4k > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code > NWMGYKND > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Frano I. <fi...@fi...> - 2004-06-16 07:44:16
|
Hi, I just wondered if anybody has ever envisaged running QuickFix(not java distrib) on the QNX os? Just curious Thanks in advance Frano Frano ILICIC Transcribe>WORLD Limited Mail : fi...@fi... Web : http://file-saveas.com Tel Gibraltar : Tel Espana : +34 956 25 49 08 Fax Espana : +34 956 25 49 08 Tel France : +33 (0)610 185 369 PGP PUBLIC KEY : mQGiBD27DucRBADTAvdHoAYGh493UIpuFcyFgglkv5Dsi3DNGJMdUyHeZDx/Z918 ZArIWtrBgDkH6oGNsu8oJ49waNU3D+oOE5sl3EWTa2rwi9mJSZ1Xufh13spIGLz8 TqjVF6ao+UMzD3zM9z/vpPF646hpIivCKLka/+7PLsKl+bora+VeBAxOiwCg/8DR zVaNfaunYQtxRRKWI4Qoz30D+wfmnh8DwpqRjokPe6HbtOwQpMssMmYr0hgIfvYg VIvm53Evqt+mIp7gXdNBDG3VnBtB/xowAn+MjCMlEw1RfuoI95mGxUZFqYbw3Poo eWOpyMOFrOFG/3nOfdAKWR3GBFmRogXFqDNb4kIqg+mbQ4jf8kV/0ahOzbs6aDI5 A6rcA/9WD2mHqqgkSe8L3G8/BbAhSHkqSineVAJzug4Pw6psCTV1taXr4XOzFUxw fMslCnkqEOYFdnLXsWen0Zwxuy+ayNfduy8wavOQ3Og3/HLDZ019kpSBzJziJ1D+ H7+k1pnHGhq498gLAEtc/V2P9kD8Cxd09Sd+t5C96vhPIPug6LQkZnJhbm8gSUxJ Q0lDIDxmcmFub0BmaWxlLXNhdmVhcy5jb20+iQBYBBARAgAYBQI9uw7nCAsJCAcD AgEKAhkBBRsDAAAAAAoJEFe4xnkok0cZXhcAnR3lY7jSdDGMaVSLk/WwQl/hcLAZ AKD6xq1dW7DBCevJ7Xi8mXjxc4NxG7kEDAQ9uw+xEA/6A6VO1cDyc0416wn7Cn5N ZYy8bHIFDG41Uz+XQtIQqREzKdEW/NS9Idy6WmEQuQcAop/gOdSA6cAL66/OItga T7YcWeZCuRF43VWnOm0C2AAS6Oi5sZJ3FDOSLQEwdlkWPl/O50fklOci9Pn0WSOI LKcbhulQsn3Qcb6SY2DpznnG2nvj68OnnKDYVV25Gzncx1lgOyt7kQbv21c2u+LS /qheLfewJ8zu3qKPUIVvHRqjgDwD1bTnIh1L7T2OprKtBKEJTekeIbYwzAl7/80J JaDNGnx/ah294FM6CH9jEKNqCWXhpMLN2QAMNO/pUmn4CIVvN1TcaFf804jcnZPu 9tkgQHa1DC9/RHZ8TUQzdRpWCtJyU5f+z3AU3qMYYn1eRvB/h7sWBsd2NjjZ5k1K BhO17LiYToix4hLjNY6dPGaY4Poe8MnFm3yY6QuYRVzQ726qncNyfLuTMrMYzNWy w2CWodzO4R5AIYVCpnERJn0qm7aR4zunjlXfP45gf19/wLACtILzownqzR/15dVC zws7a7BzdASrLhjE4CZJAIGxX5wu6Sdu1sBj6DDoh2pr8VQa7MaLsKdtuCVXOMbC aMa0bIvC9uJWDToFUyOcJP4a4SarXDiG2OvxkFIIqKBjHCAt+rpK/liUnS+1lH1+ gCh/rptFOCXbZTc5/aEbmecAAgIP+Ix29f9k33k1RHmLcnB2lOKvR62CPYzOE4Zd nI1lV+/moZ+IPxVdr2nTEfD4RPK3lvZ9HdKo6tScEM8Fi5XkQ5Y5aDFFvxY4jt3i IhfHz8Vg++6RzH69+xBNjSMKJkfjP6pUWelh3pJxZ8VmigsemHDKnH4njE9u0i0B ZGfYcDbauBgTSKy2GxW4PF55gu4jN1lfm4tHhbEQfPopi0FSlfHkL1AtPbHVc1v/ UyHe0ZHUrEf8ruuY5cEPhysCisQM6QsiZYJyFaKj2gc9Fp9tPrDnHOkRFuGYYXrj aX1/9/JGxrNirdieEoeWFDmTnFGKSgQxhCm3GhtrK+I+LDQtPLdSaHsgqtwnj/xT s3HnBQOfqPmvqtVApVfi2uIgxA/UoJJQzwqIfkhwwE+6upzirMjR+nTEdsxM+wzS Gm3QnYB4bpGQcyLVHVkN8/NhGF72HRo2r+QmKRkj7HL8iPV45+tP85AupdhTGFrJ D3DOTRRFOwt9v7urrLBM19kX7ZiHRw6pg6Ro8U/cnkOswBJo5BK/VvkBVNNCXI49 D0y4j9iaS9SWmeFO6cF2OG9BA2NGjVG0ogbE3S9ScSdYzMkaVQhN5kNo0sy8NZOG SNLeS/UxCdMGefLQ4thQjRW8+q6+xa0wEcPYGQNspuefOjE0X8cD4uIWjyVH8LAn SA02uuCJAEwEGBECAAwFAj27D7EFGwwAAAAACgkQV7jGeSiTRxklewCgkFqHBEjP Yf0OPH9C6qWpIsmB8/EAnR8hdAZj1N72q0YhoFC9YvKI+E90=Sv4k |
|
From: Dipesh C. <dip...@in...> - 2004-06-15 11:04:24
|
hii Hey can you please tell me ur code having features for connecting to = SSL.Can please give me email address of developer list. regards dipesh Dipesh Chauhan Software Programmer InfraSoft Technologies Limited Email: dip...@in... Tel : 00 91-22 5678 0666 Fax : 00 91-22 5678 0678 Mobile: 9820632521 Website: www.infrasofttech.com=20 About InfraSoft Technologies : InfraSoft Technologies is a dedicated = software company for the Banking & Finance Industry. We help creating = new business models with our software products, solutions and = specialized services. We are an ISO9001 and CMM Level 5 Company having a = global foot print with operations in New York, London, Bahrain and = Mumbai. Notice: This correspondence may contain some privileged information. If = you are not the intended recipient of this email (including attachments = if any) and have received the same in error: 1) Please do not retain any = printed copy of this correspondence, 2) Kindly delete the same from all = your computers and 3) Please intimate us. We cannot be held responsible = in any manner for any misuse of this correspondence. |
|
From: Timothy Y. <Tim...@pa...> - 2004-06-14 15:33:39
|
The callstack is not enabled. Tim. -----Original Message----- From: Oren Miller [mailto:or...@qu...] Sent: Monday, June 14, 2004 9:32 AM To: Timothy Yates Cc: qui...@li... Subject: Re: [Quickfix-developers] MS VC++ release builds Do you have the callstack enabled? --oren On Jun 14, 2004, at 8:39 AM, Timothy Yates wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html > > Has anyone else had problems with apparently random crashes and memory > corruptions in quickfix when using MS VC++, specifically using the > default > release build options? > > We have a C++ production application that uses quickfix. We have had > to > build quickfix with all optimizations turned off. We were unable to > track > down the memory corruptions that occurred with a release build. > > Recently, I have been using the Java version of quickfix. I have a > test > application that generates MarketDataSnapshotFullRefresh messages and > populates them with essentially random price data. The receiving > application sends a subscribe message and the test application starts > sending refresh messages at a rate of about 20 per second. When using > a > release build of quickfix_jni.dll, the receiving application often > crashes > after several hundred messages due to an access violation. This > typically > occurs in the destructor call from Message.finalize(), other times in > Group.finalize(), and othertime some place else. I do a session reset > between test runs. Sometimes the application does not crash at all. > I > have tried disabling all processing of refresh messages by the > receiving > application (so it just returns from fromApp without doing anything), > and > the crashes still happen. > > The random nature of the crashes leads me to suspect a threading issue. > > When I use a debug build of quickfix_jni.dll, I can never get it to > crash. > This might just be luck, or it might indicate a problem with compiler > optimizations. > > I think this problem may have something to do with repeating groups as > I > have only started noticing it since implementing market data support. > However, it could just be that I have started stressing quickfix more > than > before. > > Interestingly, the corruptions we were experiencing in our production > C++ > application also occurred when there was a large amount of market data > traffic. > > I am using quickfix 1.7.0. > > Tim Yates > Lead Developer > Patsystems (US) LLC > 141 West Jackson Boulevard > Chicago 60604, USA > Tel +1 (312) 542-1336 > www.patsystems.com > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the > one installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Oren M. <or...@qu...> - 2004-06-14 14:31:58
|
Do you have the callstack enabled? --oren On Jun 14, 2004, at 8:39 AM, Timothy Yates wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html > > Has anyone else had problems with apparently random crashes and memory > corruptions in quickfix when using MS VC++, specifically using the > default > release build options? > > We have a C++ production application that uses quickfix. We have had > to > build quickfix with all optimizations turned off. We were unable to > track > down the memory corruptions that occurred with a release build. > > Recently, I have been using the Java version of quickfix. I have a > test > application that generates MarketDataSnapshotFullRefresh messages and > populates them with essentially random price data. The receiving > application sends a subscribe message and the test application starts > sending refresh messages at a rate of about 20 per second. When using > a > release build of quickfix_jni.dll, the receiving application often > crashes > after several hundred messages due to an access violation. This > typically > occurs in the destructor call from Message.finalize(), other times in > Group.finalize(), and othertime some place else. I do a session reset > between test runs. Sometimes the application does not crash at all. > I > have tried disabling all processing of refresh messages by the > receiving > application (so it just returns from fromApp without doing anything), > and > the crashes still happen. > > The random nature of the crashes leads me to suspect a threading issue. > > When I use a debug build of quickfix_jni.dll, I can never get it to > crash. > This might just be luck, or it might indicate a problem with compiler > optimizations. > > I think this problem may have something to do with repeating groups as > I > have only started noticing it since implementing market data support. > However, it could just be that I have started stressing quickfix more > than > before. > > Interestingly, the corruptions we were experiencing in our production > C++ > application also occurred when there was a large amount of market data > traffic. > > I am using quickfix 1.7.0. > > Tim Yates > Lead Developer > Patsystems (US) LLC > 141 West Jackson Boulevard > Chicago 60604, USA > Tel +1 (312) 542-1336 > www.patsystems.com > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the > one installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Timothy Y. <Tim...@pa...> - 2004-06-14 13:42:10
|
Has anyone else had problems with apparently random crashes and memory corruptions in quickfix when using MS VC++, specifically using the default release build options? We have a C++ production application that uses quickfix. We have had to build quickfix with all optimizations turned off. We were unable to track down the memory corruptions that occurred with a release build. Recently, I have been using the Java version of quickfix. I have a test application that generates MarketDataSnapshotFullRefresh messages and populates them with essentially random price data. The receiving application sends a subscribe message and the test application starts sending refresh messages at a rate of about 20 per second. When using a release build of quickfix_jni.dll, the receiving application often crashes after several hundred messages due to an access violation. This typically occurs in the destructor call from Message.finalize(), other times in Group.finalize(), and othertime some place else. I do a session reset between test runs. Sometimes the application does not crash at all. I have tried disabling all processing of refresh messages by the receiving application (so it just returns from fromApp without doing anything), and the crashes still happen. The random nature of the crashes leads me to suspect a threading issue. When I use a debug build of quickfix_jni.dll, I can never get it to crash. This might just be luck, or it might indicate a problem with compiler optimizations. I think this problem may have something to do with repeating groups as I have only started noticing it since implementing market data support. However, it could just be that I have started stressing quickfix more than before. Interestingly, the corruptions we were experiencing in our production C++ application also occurred when there was a large amount of market data traffic. I am using quickfix 1.7.0. Tim Yates Lead Developer Patsystems (US) LLC 141 West Jackson Boulevard Chicago 60604, USA Tel +1 (312) 542-1336 www.patsystems.com |
|
From: Clark S. <cla...@ya...> - 2004-06-11 18:37:40
|
oops sorry for the previous reply which was empty, It works perfect now, after I made that change Oren Miller <or...@qu...> wrote: It's probably the same issue really. Try changing the DEFAULT_USER in MySQLStore.cpp to "root". --oren On Jun 11, 2004, at 11:08 AM, Clark Sims wrote: > I have a debian Sarge machine, kernel 2.6.6-1 with two pentium 3 > cpu's > I am running g++ version 3.3.3 > > I get two failuers from runut. Do I need to worry about this? > > when I execute runut I get: > > > > ....................................................................... > .........................FF....................................... > > > > > > > > > > > > > > > > > > > > > > Do you Yahoo!? > Friends. Fun. Try the all-new Yahoo! Messenger --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger |
|
From: Clark S. <cla...@ya...> - 2004-06-11 18:37:12
|
Oren Miller <or...@qu...> wrote:It's probably the same issue really. Try changing the DEFAULT_USER in MySQLStore.cpp to "root". --oren On Jun 11, 2004, at 11:08 AM, Clark Sims wrote: > I have a debian Sarge machine, kernel 2.6.6-1 with two pentium 3 > cpu's > I am running g++ version 3.3.3 > > I get two failuers from runut. Do I need to worry about this? > > when I execute runut I get: > > > > ....................................................................... > .........................FF....................................... > > > > > > > > > > > > > > > > > > > > > > Do you Yahoo!? > Friends. Fun. Try the all-new Yahoo! Messenger --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger |
|
From: Oren M. <or...@qu...> - 2004-06-11 18:18:52
|
It's probably the same issue really. Try changing the DEFAULT_USER in =20= MySQLStore.cpp to "root". --oren On Jun 11, 2004, at 11:08 AM, Clark Sims wrote: > I have a debian Sarge machine, kernel 2.6.6-1=A0=A0 with two pentium 3 = =20 > cpu's > I am running g++ version 3.3.3 > =A0 > I get two failuers from runut.=A0 Do I need to worry about this? > =A0 > when I execute runut I get: > =A0 > <ut> > =A0 <output> > = .......................................................................=20= > .........................FF....................................... > =A0 </output> > =A0 <results total=3D"137" failures=3D"2"> > =A0=A0=A0 <failure=A0 line=3D "0" file=3D "unknown"> > =A0=A0=A0=A0=A0 <test> > =A0=A0=A0=A0=A0=A0=A0 <![CDATA[ = PN7CPPTest4TestIN3FIX12MessageStoreEEE]]> > =A0=A0=A0=A0=A0 </test> > =A0=A0=A0=A0=A0 <text> > =A0=A0=A0=A0=A0=A0=A0 <![CDATA[ assert(no futher information = available)]]> > =A0=A0=A0=A0=A0 </text> > =A0=A0=A0 </failure> > =A0=A0=A0 <failure=A0 line=3D "0" file=3D "unknown"> > =A0=A0=A0=A0=A0 <test> > =A0=A0=A0=A0=A0=A0=A0 <![CDATA[ = PN7CPPTest4TestIN3FIX12MessageStoreEEE]]> > =A0=A0=A0=A0=A0 </test> > =A0=A0=A0=A0=A0 <text> > =A0=A0=A0=A0=A0=A0=A0 <![CDATA[ assert(no futher information = available)]]> > =A0=A0=A0=A0=A0 </text> > =A0=A0=A0 </failure> > =A0 </results> > </ut> > > Do you Yahoo!? > Friends. Fun. Try the all-new Yahoo! Messenger= |
|
From: Clark S. <cla...@ya...> - 2004-06-11 16:08:46
|
I have a debian Sarge machine, kernel 2.6.6-1 with two pentium 3 cpu's
I am running g++ version 3.3.3
I get two failuers from runut. Do I need to worry about this?
when I execute runut I get:
<ut>
<output>
................................................................................................FF.......................................
</output>
<results total="137" failures="2">
<failure line= "0" file= "unknown">
<test>
<![CDATA[ PN7CPPTest4TestIN3FIX12MessageStoreEEE]]>
</test>
<text>
<![CDATA[ assert(no futher information available)]]>
</text>
</failure>
<failure line= "0" file= "unknown">
<test>
<![CDATA[ PN7CPPTest4TestIN3FIX12MessageStoreEEE]]>
</test>
<text>
<![CDATA[ assert(no futher information available)]]>
</text>
</failure>
</results>
</ut>
---------------------------------
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger |
|
From: Clark S. <cla...@ya...> - 2004-06-11 16:05:27
|
mysql -u root --execute="source mysql.sql" this worked :) --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger |
|
From: Clark S. <cla...@ya...> - 2004-06-10 11:26:18
|
when I ran create_mysql.sh I got: ERROR 1044 at line 1 in file: 'quickfix_database.sql': Access denied for user: '@localhost' to database 'quickfix' I have never used mysql before :( What is wrong here ? do I need to add the user to some group? am I supposed to run something as root? --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger |
|
From: Jon D. <jd...@wi...> - 2004-06-09 19:48:23
|
It's not, I just wanted to see what kind of failover scenarios we could setup based upon how the QF failover was designed. It's to be determined if we are going to reset the Sequence Numbers once in production. Thanks for the help JD > Oh, then why are sequence numbers a concern? If you are always > resetting to 1, then you should never have a situation where sequence > numbers are too high. Am I understanding this correctly? > > --oren > > On Jun 9, 2004, at 2:13 PM, Jon Dahl wrote: > >> Understood. However we are setting ResetOnDisconnect and ResetOnLogout >> to >> 1 so I would assume session state is not that big of a deal then. >> Unless >> of course I am reading the config documentation incorrectly. >> >> jd >> >>> Well you need to determine what it is exactly you are trying to make >>> redundant. If you are trying to make the FIX session redundant, than >>> you should have the same compids while making sure that only one >>> server >>> is active at any given time. These processes should share the same >>> source for the state of the session. This way no matter where they >>> connect to, the sequence numbers will be the same. In this case flat >>> file storage probably won't do, in which case you would likely want >>> to use a database. For extra reliability you would also want to make >>> the database redundant. >>> >>> Now if you are simply trying to provide redundant lines, then you >>> should use different compids. In this case you are not making the >>> session redundant, but you are making sure that they always have a >>> path >>> into the system. The upside is that these lines are always on and >>> are immediately available to accept traffic. In fact they can accept >>> traffic simultaneously (distributing the load), and the client can >>> reroute excess traffic to the other lines if one goes down. The >>> downside is that if a session goes down, lost messages won't be >>> retrieved until it can be brought back up. >>> >>> You can also combine these by having redundant paths into the system >>> which have redundant sessions. It all depends on what you are trying >>> to accomplish. But the thing that should remain solid is that if I >>> am connecting somewhere with the same compids, I should expect the >>> sequence numbers to carry over. If not, I can only assume something >>> is >>> catastrophically wrong and manual intervention is required. >>> >>> --oren >>> >>> On Jun 9, 2004, at 12:51 PM, Jon Dahl wrote: >>> >>>> I understand about having the same SenderCompID's. SenderLocationID >>>> can be >>>> used instead of the SenderCompID to indentify the source of the >>>> message. >>>> >>>> But in the case of a failover, won't sequence numbers be an issue? >>>> If the failover server sequence numbers for a client were higher >>>> than what >>>> the client was at, wouldn't there be a possiblity of a resend or >>>> locking >>>> the client out until the sequence numbers caught up? >>>> >>>> jd >>>> >>>>> John, >>>>> >>>>> When you have multiple connection points that share the same comp >>>>> id's, >>>>> cycling through the connections is a necessity because you can't >>>>> keep >>>>> the same session alive simultaneously on multiple hosts/ports. But >>>>> if you failover sessions with unique compids and unique sets of >>>>> sequence numbers, why would you not just keep these connections up >>>>> at >>>>> all times? >>>>> >>>>> --oren >>>>> >>>>> On Jun 9, 2004, at 10:46 AM, Jon Dahl wrote: >>>>> >>>>>> QuickFIX Documentation: >>>>>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>>>>> QuickFIX FAQ: >>>>>> http://www.quickfixengine.org/quickfix/doc/html/FAQ.html >>>>>> >>>>>> I have been asked to research QuickFIX's scalability/failover >>>>>> capabilities >>>>>> by our Ops center and have come upon an issue. I think I found a >>>>>> situation >>>>>> where the clients won't be able to connect to an alternate gateway >>>>>> in case >>>>>> of a failure. >>>>>> >>>>>> Let's say a client has two hosts(gateways) to connect to. Each one >>>>>> has >>>>>> a >>>>>> separate SenderCompID. If the client detects a failure and tries >>>>>> to connect to the secondary host, it will fail to connect because >>>>>> its TargetCompID is for the primary host and not the secondary >>>>>> one. >>>>>> >>>>>> I was wondering if there was a way to have the [SESSION] settings >>>>>> have >>>>>> alternate TargetCompID's to go a long with SocketConnectPort[n] >>>>>> and SocketConnectHost[n]? >>>>>> >>>>>> JD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> This SF.Net email is sponsored by: GNOME Foundation >>>>>> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. >>>>>> GNOME Users and Developers European Conference, 28-30th June in >>>>>> Norway >>>>>> http://2004/guadec.org >>>>>> _______________________________________________ >>>>>> Quickfix-developers mailing list >>>>>> Qui...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >>>> >>>> >>>> -- >>>> Jon Dahl >>>> jd...@wi... >> >> >> -- >> Jon Dahl >> jd...@wi... -- Jon Dahl jd...@wi... |
|
From: Oren M. <or...@qu...> - 2004-06-09 19:20:47
|
Oh, then why are sequence numbers a concern? If you are always resetting to 1, then you should never have a situation where sequence numbers are too high. Am I understanding this correctly? --oren On Jun 9, 2004, at 2:13 PM, Jon Dahl wrote: > Understood. However we are setting ResetOnDisconnect and ResetOnLogout > to > 1 so I would assume session state is not that big of a deal then. > Unless > of course I am reading the config documentation incorrectly. > > jd > >> Well you need to determine what it is exactly you are trying to make >> redundant. If you are trying to make the FIX session redundant, than >> you should have the same compids while making sure that only one >> server >> is active at any given time. These processes should share the same >> source for the state of the session. This way no matter where they >> connect to, the sequence numbers will be the same. In this case flat >> file storage probably won't do, in which case you would likely want to >> use a database. For extra reliability you would also want to make the >> database redundant. >> >> Now if you are simply trying to provide redundant lines, then you >> should use different compids. In this case you are not making the >> session redundant, but you are making sure that they always have a >> path >> into the system. The upside is that these lines are always on and are >> immediately available to accept traffic. In fact they can accept >> traffic simultaneously (distributing the load), and the client can >> reroute excess traffic to the other lines if one goes down. The >> downside is that if a session goes down, lost messages won't be >> retrieved until it can be brought back up. >> >> You can also combine these by having redundant paths into the system >> which have redundant sessions. It all depends on what you are trying >> to accomplish. But the thing that should remain solid is that if I am >> connecting somewhere with the same compids, I should expect the >> sequence numbers to carry over. If not, I can only assume something >> is >> catastrophically wrong and manual intervention is required. >> >> --oren >> >> On Jun 9, 2004, at 12:51 PM, Jon Dahl wrote: >> >>> I understand about having the same SenderCompID's. SenderLocationID >>> can be >>> used instead of the SenderCompID to indentify the source of the >>> message. >>> >>> But in the case of a failover, won't sequence numbers be an issue? If >>> the failover server sequence numbers for a client were higher than >>> what >>> the client was at, wouldn't there be a possiblity of a resend or >>> locking >>> the client out until the sequence numbers caught up? >>> >>> jd >>> >>>> John, >>>> >>>> When you have multiple connection points that share the same comp >>>> id's, >>>> cycling through the connections is a necessity because you can't >>>> keep >>>> the same session alive simultaneously on multiple hosts/ports. But >>>> if you failover sessions with unique compids and unique sets of >>>> sequence numbers, why would you not just keep these connections up >>>> at >>>> all times? >>>> >>>> --oren >>>> >>>> On Jun 9, 2004, at 10:46 AM, Jon Dahl wrote: >>>> >>>>> QuickFIX Documentation: >>>>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>>>> QuickFIX FAQ: >>>>> http://www.quickfixengine.org/quickfix/doc/html/FAQ.html >>>>> >>>>> I have been asked to research QuickFIX's scalability/failover >>>>> capabilities >>>>> by our Ops center and have come upon an issue. I think I found a >>>>> situation >>>>> where the clients won't be able to connect to an alternate gateway >>>>> in case >>>>> of a failure. >>>>> >>>>> Let's say a client has two hosts(gateways) to connect to. Each one >>>>> has >>>>> a >>>>> separate SenderCompID. If the client detects a failure and tries to >>>>> connect to the secondary host, it will fail to connect because its >>>>> TargetCompID is for the primary host and not the secondary one. >>>>> >>>>> I was wondering if there was a way to have the [SESSION] settings >>>>> have >>>>> alternate TargetCompID's to go a long with SocketConnectPort[n] and >>>>> SocketConnectHost[n]? >>>>> >>>>> JD >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------- >>>>> This SF.Net email is sponsored by: GNOME Foundation >>>>> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. >>>>> GNOME Users and Developers European Conference, 28-30th June in >>>>> Norway >>>>> http://2004/guadec.org >>>>> _______________________________________________ >>>>> Quickfix-developers mailing list >>>>> Qui...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >>> >>> >>> -- >>> Jon Dahl >>> jd...@wi... > > > -- > Jon Dahl > jd...@wi... > > > |
|
From: Jon D. <jd...@wi...> - 2004-06-09 19:15:08
|
Understood. However we are setting ResetOnDisconnect and ResetOnLogout to 1 so I would assume session state is not that big of a deal then. Unless of course I am reading the config documentation incorrectly. jd > Well you need to determine what it is exactly you are trying to make > redundant. If you are trying to make the FIX session redundant, than > you should have the same compids while making sure that only one server > is active at any given time. These processes should share the same > source for the state of the session. This way no matter where they > connect to, the sequence numbers will be the same. In this case flat > file storage probably won't do, in which case you would likely want to > use a database. For extra reliability you would also want to make the > database redundant. > > Now if you are simply trying to provide redundant lines, then you > should use different compids. In this case you are not making the > session redundant, but you are making sure that they always have a path > into the system. The upside is that these lines are always on and are > immediately available to accept traffic. In fact they can accept > traffic simultaneously (distributing the load), and the client can > reroute excess traffic to the other lines if one goes down. The > downside is that if a session goes down, lost messages won't be > retrieved until it can be brought back up. > > You can also combine these by having redundant paths into the system > which have redundant sessions. It all depends on what you are trying > to accomplish. But the thing that should remain solid is that if I am > connecting somewhere with the same compids, I should expect the > sequence numbers to carry over. If not, I can only assume something is > catastrophically wrong and manual intervention is required. > > --oren > > On Jun 9, 2004, at 12:51 PM, Jon Dahl wrote: > >> I understand about having the same SenderCompID's. SenderLocationID >> can be >> used instead of the SenderCompID to indentify the source of the >> message. >> >> But in the case of a failover, won't sequence numbers be an issue? If >> the failover server sequence numbers for a client were higher than >> what >> the client was at, wouldn't there be a possiblity of a resend or >> locking >> the client out until the sequence numbers caught up? >> >> jd >> >>> John, >>> >>> When you have multiple connection points that share the same comp >>> id's, >>> cycling through the connections is a necessity because you can't keep >>> the same session alive simultaneously on multiple hosts/ports. But >>> if you failover sessions with unique compids and unique sets of >>> sequence numbers, why would you not just keep these connections up at >>> all times? >>> >>> --oren >>> >>> On Jun 9, 2004, at 10:46 AM, Jon Dahl wrote: >>> >>>> QuickFIX Documentation: >>>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>>> QuickFIX FAQ: >>>> http://www.quickfixengine.org/quickfix/doc/html/FAQ.html >>>> >>>> I have been asked to research QuickFIX's scalability/failover >>>> capabilities >>>> by our Ops center and have come upon an issue. I think I found a >>>> situation >>>> where the clients won't be able to connect to an alternate gateway >>>> in case >>>> of a failure. >>>> >>>> Let's say a client has two hosts(gateways) to connect to. Each one >>>> has >>>> a >>>> separate SenderCompID. If the client detects a failure and tries to >>>> connect to the secondary host, it will fail to connect because its >>>> TargetCompID is for the primary host and not the secondary one. >>>> >>>> I was wondering if there was a way to have the [SESSION] settings >>>> have >>>> alternate TargetCompID's to go a long with SocketConnectPort[n] and >>>> SocketConnectHost[n]? >>>> >>>> JD >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by: GNOME Foundation >>>> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. >>>> GNOME Users and Developers European Conference, 28-30th June in >>>> Norway >>>> http://2004/guadec.org >>>> _______________________________________________ >>>> Quickfix-developers mailing list >>>> Qui...@li... >>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> >> >> -- >> Jon Dahl >> jd...@wi... -- Jon Dahl jd...@wi... |
|
From: Oren M. <or...@qu...> - 2004-06-09 18:38:33
|
Well you need to determine what it is exactly you are trying to make redundant. If you are trying to make the FIX session redundant, than you should have the same compids while making sure that only one server is active at any given time. These processes should share the same source for the state of the session. This way no matter where they connect to, the sequence numbers will be the same. In this case flat file storage probably won't do, in which case you would likely want to use a database. For extra reliability you would also want to make the database redundant. Now if you are simply trying to provide redundant lines, then you should use different compids. In this case you are not making the session redundant, but you are making sure that they always have a path into the system. The upside is that these lines are always on and are immediately available to accept traffic. In fact they can accept traffic simultaneously (distributing the load), and the client can reroute excess traffic to the other lines if one goes down. The downside is that if a session goes down, lost messages won't be retrieved until it can be brought back up. You can also combine these by having redundant paths into the system which have redundant sessions. It all depends on what you are trying to accomplish. But the thing that should remain solid is that if I am connecting somewhere with the same compids, I should expect the sequence numbers to carry over. If not, I can only assume something is catastrophically wrong and manual intervention is required. --oren On Jun 9, 2004, at 12:51 PM, Jon Dahl wrote: > I understand about having the same SenderCompID's. SenderLocationID > can be > used instead of the SenderCompID to indentify the source of the > message. > > But in the case of a failover, won't sequence numbers be an issue? > If the failover server sequence numbers for a client were higher than > what > the client was at, wouldn't there be a possiblity of a resend or > locking > the client out until the sequence numbers caught up? > > jd > >> John, >> >> When you have multiple connection points that share the same comp >> id's, >> cycling through the connections is a necessity because you can't keep >> the same session alive simultaneously on multiple hosts/ports. But if >> you failover sessions with unique compids and unique sets of sequence >> numbers, why would you not just keep these connections up at all >> times? >> >> --oren >> >> On Jun 9, 2004, at 10:46 AM, Jon Dahl wrote: >> >>> QuickFIX Documentation: >>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>> QuickFIX FAQ: >>> http://www.quickfixengine.org/quickfix/doc/html/FAQ.html >>> >>> I have been asked to research QuickFIX's scalability/failover >>> capabilities >>> by our Ops center and have come upon an issue. I think I found a >>> situation >>> where the clients won't be able to connect to an alternate gateway in >>> case >>> of a failure. >>> >>> Let's say a client has two hosts(gateways) to connect to. Each one >>> has >>> a >>> separate SenderCompID. If the client detects a failure and tries to >>> connect to the secondary host, it will fail to connect because its >>> TargetCompID is for the primary host and not the secondary one. >>> >>> I was wondering if there was a way to have the [SESSION] settings >>> have >>> alternate TargetCompID's to go a long with SocketConnectPort[n] and >>> SocketConnectHost[n]? >>> >>> JD >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: GNOME Foundation >>> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. >>> GNOME Users and Developers European Conference, 28-30th June in >>> Norway >>> http://2004/guadec.org >>> _______________________________________________ >>> Quickfix-developers mailing list >>> Qui...@li... >>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > -- > Jon Dahl > jd...@wi... > > > |
|
From: Jon D. <jd...@wi...> - 2004-06-09 17:55:23
|
I understand about having the same SenderCompID's. SenderLocationID can be used instead of the SenderCompID to indentify the source of the message. But in the case of a failover, won't sequence numbers be an issue? If the failover server sequence numbers for a client were higher than what the client was at, wouldn't there be a possiblity of a resend or locking the client out until the sequence numbers caught up? jd > John, > > When you have multiple connection points that share the same comp id's, > cycling through the connections is a necessity because you can't keep > the same session alive simultaneously on multiple hosts/ports. But if > you failover sessions with unique compids and unique sets of sequence > numbers, why would you not just keep these connections up at all times? > > --oren > > On Jun 9, 2004, at 10:46 AM, Jon Dahl wrote: > >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html >> >> I have been asked to research QuickFIX's scalability/failover >> capabilities >> by our Ops center and have come upon an issue. I think I found a >> situation >> where the clients won't be able to connect to an alternate gateway in >> case >> of a failure. >> >> Let's say a client has two hosts(gateways) to connect to. Each one has >> a >> separate SenderCompID. If the client detects a failure and tries to >> connect to the secondary host, it will fail to connect because its >> TargetCompID is for the primary host and not the secondary one. >> >> I was wondering if there was a way to have the [SESSION] settings have >> alternate TargetCompID's to go a long with SocketConnectPort[n] and >> SocketConnectHost[n]? >> >> JD >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: GNOME Foundation >> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. >> GNOME Users and Developers European Conference, 28-30th June in Norway >> http://2004/guadec.org >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers -- Jon Dahl jd...@wi... |
|
From: Scott H. <sco...@fo...> - 2004-06-09 16:59:11
|
At first glance you just need to construct an in-memory .cfg file in a String or StringBuffer, wrap that in a ByteArrayInputStream, and pass that to the SessionSettings constructor. HOWEVER, my experience with the Initiator under JNI is that you're limited to a single lifecycle per JVM, due to some tricky interactions of the destructors in Initiator.cpp as it's currently written. This means that you're stuck with the [SESSION]s defined in your initial .cfg file. I too would like to see this addressed in a future release. Your idea of using an empty default constructor for SessionSettings and then calling the various setString(), setLong() methods would be nice, but also will not work with the current code. For now, think of SessionSettings.java s simply a view of an already-parsed .cfg file. The interface would need to be extended (and the internal Dictionary objects passed around by reference instead of by value) for the Java SessionSettings to be "writable". On Wed, 9 Jun 2004, Shamanth wrote: > Hi > > I have a requirement, where we want to change or add new sessions or > providers dynamically. Or I would like to change the port for a given > provider. We are going to do this using an MBean. Basically we will have > an MBean which will read the SESSION and DEFAULT properties from a > custom property file. > > Problem: We want to create a new SocketInitiator for each provider. > Since a SocketInitiator expects a SessionSettings object we would > ideally like to create a new SessionSettings object dynamically. But as > the constructors of a SessionSettings object expects a inputstream, I > don't see how we could do this. > > I would like a empty default constructor for SessionSettings and then we > use the set methods to set any perticular property. Do you have any > plans to incorporate this in your future releases. > > Or is there an alternate way of acheiving the same result. > > I am using Java version of quickFix. > > thanks > R Shamanth |
|
From: Oren M. <or...@qu...> - 2004-06-09 16:10:25
|
John, When you have multiple connection points that share the same comp id's, cycling through the connections is a necessity because you can't keep the same session alive simultaneously on multiple hosts/ports. But if you failover sessions with unique compids and unique sets of sequence numbers, why would you not just keep these connections up at all times? --oren On Jun 9, 2004, at 10:46 AM, Jon Dahl wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html > > I have been asked to research QuickFIX's scalability/failover > capabilities > by our Ops center and have come upon an issue. I think I found a > situation > where the clients won't be able to connect to an alternate gateway in > case > of a failure. > > Let's say a client has two hosts(gateways) to connect to. Each one has > a > separate SenderCompID. If the client detects a failure and tries to > connect to the secondary host, it will fail to connect because its > TargetCompID is for the primary host and not the secondary one. > > I was wondering if there was a way to have the [SESSION] settings have > alternate TargetCompID's to go a long with SocketConnectPort[n] and > SocketConnectHost[n]? > > JD > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Shamanth <sha...@in...> - 2004-06-09 16:10:04
|
Hi I have a requirement, where we want to change or add new sessions or = providers dynamically. Or I would like to change the port for a given = provider. We are going to do this using an MBean. Basically we will have = an MBean which will read the SESSION and DEFAULT properties from a = custom property file. Problem:=20 We want to create a new SocketInitiator for each provider. Since a = SocketInitiator expects a SessionSettings object we would ideally like = to create a new SessionSettings object dynamically. But as the = constructors of a SessionSettings object expects a inputstream, I don't = see how we could do this.=20 I would like a empty default constructor for SessionSettings and then we = use the set methods to set any perticular property. Do you have any = plans to incorporate this in your future releases.=20 Or is there an alternate way of acheiving the same result. I am using Java version of quickFix. thanks R Shamanth > NOTICE > This e-mail message and any attachments, which may contain = confidential information, are to be viewed solely by the intended = recipient of Integral Development Corp. If the reader of this message = is not the intended recipient, you are hereby notified that any use, = dissemination, distribution or copying of this communication is strictly = prohibited. If you have received this message in error, please = immediately notify the sender and delete the mail and all attachments. >=20 |
|
From: Jon D. <jd...@wi...> - 2004-06-09 15:48:15
|
I have been asked to research QuickFIX's scalability/failover capabilities by our Ops center and have come upon an issue. I think I found a situation where the clients won't be able to connect to an alternate gateway in case of a failure. Let's say a client has two hosts(gateways) to connect to. Each one has a separate SenderCompID. If the client detects a failure and tries to connect to the secondary host, it will fail to connect because its TargetCompID is for the primary host and not the secondary one. I was wondering if there was a way to have the [SESSION] settings have alternate TargetCompID's to go a long with SocketConnectPort[n] and SocketConnectHost[n]? JD |
|
From: Oren M. <or...@qu...> - 2004-06-09 11:15:54
|
Ahh, I know why it is doing this but I would say it is not the correct behavior and should be changed. What is happening is you are getting some other type of message, say a logon, or a heartbeat, or whatever. Well the cracker's originally supported only Application messages and then Admin messages were added. Well the default behavior for cracking an application message that does not have an override method is to reject it as not supported, which makes sense. For application messages, however, this does not make sense and the message should really just be ignored. I'll modify the generator to make sure this is the new behavior. --oren On Jun 9, 2004, at 3:51 AM, Ramprakash Umapathy wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/quickfix/doc/html/FAQ.html > > Hi, > > Can anyone explain why I get error when I try to crack messages > fromAdmin > using the following code > > Public Sub fromAdmin(ByVal QFmessage As QuickFix.Message, ByVal > QFSession As > QuickFix.SessionID) Implements QuickFix.Application.fromAdmin > > 'Some code here > '--- > '--- > '--- > > crack(QFmessage, QFSession) > > > End Sub > > Public Overloads Overrides Sub onMessage(ByVal message As > QuickFix42.TestRequest, ByVal session As QuickFix.SessionID) > MsgBox(message.getTestReqID.getValue) > End Sub > > > The Error is, > > An unhandled exception of type 'QuickFix.UnsupportedMessageType' > occurred in > quickfix_net_messages.dll in the code where I is crack command. > > I use QF 1.7.1 with Microsoft.NET 1.1/Windows 2003/VS.NET 2003 > > Thanks in advance, > Ramprakash > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
98 messages has been excluded from this view by a project administrator.
