quickfix-developers Mailing List for QuickFIX (Page 86)
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: Motl <hi...@ma...> - 2008-04-29 07:25:43
|
Hi, I have a question regarding ClOrdId tag (11). The FIX specification only requires this field to be unique within a day (or across days for multi-day orders), but says nothing about "incremental" format of this field. But I'm working with a FIX implementation that only accepts orders with ClOrdId tag like "UNIQORDID1001", "UNIQORDID1002". Is this a common behavior? Thanks. -- View this message in context: http://www.nabble.com/ClOrdId-tag-tp16953721p16953721.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: <or...@qu...> - 2008-04-28 20:29:16
|
<html><body><div>The QuickFIX logviewer pulls FIX messages out of any file and ignores any extra noise, which is how it manages to work with other engines as well.</div> <div> </div> <div>--oren</div> <BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT: blue 2px solid" webmail="1">-------- Original Message --------<BR>Subject: Re: [Quickfix-developers] question about a change on the trunk<BR>to FileLog.h<BR>From: "Djalma Rosa dos Santos Filho" <drs...@gm...><BR>Date: Mon, April 28, 2008 12:49 pm<BR>To: "quickfix developers" <<a href="mailto:qui...@li...urceforge">qui...@li...urceforge</a>.net><BR><BR>QuickFIX Documentation: <A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>QuickFIX Support: <A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR><BR> <HR> The new format is very interesting, and I agree that it would be still better if controlled by configuration option.<BR><BR>But how about QuickFIX Log Viewer? Is it already prepared for the new format?<BR><BR>Thanks,<BR>Djalma<BR><BR> <DIV class=gmail_quote>On Mon, Apr 28, 2008 at 11:50 AM, Mark T. Kennedy <<A onclick="Popup.composeWindow('pcompose.php?sendto=mkennedy%40diamondbackcap.com');; return false;" href="mailto:mke...@di..." target=_blank><a href="mailto:mke...@di...">mke...@di...</a></A>> wrote:<BR> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">QuickFIX Documentation: <A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>QuickFIX Support: <A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR><BR><BR>i think mike gatny is in the process of adding a timestamp to the FIX message log.<BR>one request: can it be under the control of an option? i've got a pile of code<BR>that is driven off of the existing (simple) format. and while it isn't rocket<BR>science to consume or strip off a leading timestamp, i am lazy :-).<BR><BR>thanks in advance.<BR><BR>/mark<BR><BR>This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback.<BR><BR><BR>-------------------------------------------------------------------------<BR>This <a href="http://SF.net">SF.net</a> email is sponsored by the 2008 JavaOne(SM) Conference<BR>Don't miss this year's exciting event. There's still time to save $100.<BR>Use priority code J8TL2D2.<BR><A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?">http://ad.doubleclick.net/clk;198757673;13503038;p?</a><A href="http://java.sun.com/javaone" target=_blank><a href="http://java.sun.com/javaone">http://java.sun.com/javaone</a></A></A><BR>_______________________________________________<BR>Quickfix-developers mailing list<BR><A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%40lists.sourceforge.net');; return false;" href="mailto:Qui...@li..." target=_blank><a href="mailto:Qui...@li...">Qui...@li...</a></A><BR><A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A><BR></BLOCKQUOTE></DIV><BR> <HR> -------------------------------------------------------------------------<BR>This <a href="http://SF.net">SF.net</a> email is sponsored by the 2008 JavaOne(SM) Conference <BR>Don't miss this year's exciting event. There's still time to save $100. <BR>Use priority code J8TL2D2. <BR><A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A> <HR> _______________________________________________<BR>Quickfix-developers mailing list<BR><A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%40lists.sourceforge.net'); return false;" href="#Compose">Quickfix-developers<B></B>@lists.sourceforge.net</A><BR><A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A> </BLOCKQUOTE></body></html> |
|
From: Djalma R. d. S. F. <drs...@gm...> - 2008-04-28 17:49:46
|
The new format is very interesting, and I agree that it would be still better if controlled by configuration option. But how about QuickFIX Log Viewer? Is it already prepared for the new format? Thanks, Djalma On Mon, Apr 28, 2008 at 11:50 AM, Mark T. Kennedy < mke...@di...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > i think mike gatny is in the process of adding a timestamp to the FIX > message log. > one request: can it be under the control of an option? i've got a pile of > code > that is driven off of the existing (simple) format. and while it isn't > rocket > science to consume or strip off a leading timestamp, i am lazy :-). > > thanks in advance. > > /mark > > This communication and any attachments may contain > confidential/proprietary information and is intended for information > purposes only. It is not an invitation or offer to purchase interests from > Diamondback. Any representation to the contrary is unintentional. This > communication is intended only for the person(s) to whom it is addressed. > If you are not the intended recipient you are hereby notified that you have > received this document in error and that any review, dissemination, > distribution, or copying of this message or any attachments is not > permitted. If you have received this in error, please notify the sender > immediately by e-mail and delete this message. All e-mails sent to or > received from this address will be received by Diamondback's company e-mail > system and is subject to archival and possible review by someone other than > the recipient. This notice is automatically appended to each e-mail message > leaving Diamondback. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Mark T. K. <mke...@di...> - 2008-04-28 15:09:11
|
i think mike gatny is in the process of adding a timestamp to the FIX message log. one request: can it be under the control of an option? i've got a pile of code that is driven off of the existing (simple) format. and while it isn't rocket science to consume or strip off a leading timestamp, i am lazy :-). thanks in advance. /mark This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback. |
|
From: Rai, N. <nee...@ci...> - 2008-04-25 19:15:50
|
gcc 4.3.0 ========================== gcc --version gcc (GCC) 4.3.0 20080130 (Red Hat 4.3.0-0.7) _____ From: or...@qu... [mailto:or...@qu...] Sent: Friday, April 25, 2008 3:00 PM To: Rai, Neeraj [CAI] Cc: qui...@li... Subject: RE: [Quickfix-developers] Quickfix build errors on fedora 8 What version of gcc does fedora 8 use? -------- Original Message -------- Subject: [Quickfix-developers] Quickfix build errors on fedora 8 From: "Rai, Neeraj " <nee...@ci...> Date: Fri, April 25, 2008 11:46 am To: <qui...@li...> QuickFIX Documentation: <http://www.quickfixengine.org/quickfix/doc/html/index.html> http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: <http://www.quickfixengine.org/services.html> http://www.quickfixengine.org/services.html Hi, I have encountered 2 errors in building quickfix on fedora 8. The error log attached at the end of the email. ! 1. It seems std::strcmp etc are not found. These are being included if STLport is not used. If I define HAVE_STLPORT, it goes past this error. I didn't need STLPort when I worked on it last time (on RHEL), so I would like to avoid using it. 2. The 2nd one may be related. Upon defining HAVE_STLPORT, std::strerror" still cannot be found. I have to include string.h in couple of files to finish the build. I am sure, this is not the right way to fix these errors. can this be avoided by some configure options ? Any help, pointer in the right direction would be appreciated. Thanks Neeraj Error Log: Making all in test make[4]: Entering directory `/export/home/nr42835/Download/quickfix/src/C++/test' if /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -O2 -Wall -ansi -Wpointer-arith -Wwrite-strings -I/usr/include/libxml2 -O0 -g -MT FieldBaseTestCase.lo -MD -MP -MF ".deps/FieldB! aseTestCase.Tpo" \ -c -o FieldBaseTestCase.lo `test -f 'Fie! ldBaseTe stCase.cpp' || echo './'`FieldBaseTestCase.cpp; \ then mv ".deps/FieldBaseTestCase.Tpo" ".deps/FieldBaseTestCase.Plo"; \ else rm -f ".deps/FieldBaseTestCase.Tpo"; exit 1; \ fi mkdir .libs g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -O2 -Wall -ansi -Wpointer-arith -Wwrite-strings -I/usr/include/libxml2 -O0 -g -MT FieldBaseTestCase.lo -MD -MP -MF .deps/FieldBaseTestCase.Tpo -c FieldBaseTestCase.cpp -fPIC -DPIC -o .libs/FieldBaseTestCase.o In file included from ../FieldTypes.h:30, from ../FieldConvertors.h:26, from ../Field.h:33, from FieldBaseTestCase.h:27, from FieldBaseTestCase.cpp:28: ../Utility.h:179: error: 'std::strcmp' has not been declared ../Utility.h:181: error: 'std::strlen' has not been declared ../Utility.h:184: error: 'std::memcpy' has not been declared ../Utility.h:185: error: 'std::memset' has not been declared ../Utility.h:189: error: 'std::strerror' has not been declared In file included from .! ./FieldConvertors.h:27, from ../Field.h:33, from FieldBaseTestCase.h:27, from FieldBaseTestCase.cpp:28: ../Exceptions.h: In member function 'std::string FIX::SocketException::errorToWhat()': ../Exceptions.h:253: error: 'strerror' was not declared in this scope In file included from FieldBaseTestCase.h:27, from FieldBaseTestCase.cpp:28: ../Field.h: In member function 'void FIX::FieldBase::calculate() const': ../Field.h:110: error: 'memcpy' was not declared in this scope make[4]: *** [FieldBaseTestCase.lo] Error 1 ------------------------------------------------------------------------ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. <http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ javaone> http://ad.doub! leclick. net/clk;198757673;13503038;p?http://java.sun.com/javaone <http://ad.doubleclick.net/clk;19! 8757673;13503038;p?http://java.sun.com/javaone> _______________________________________________ Quickfix-developers mailing list Qui...@li... <https://lists.sourceforge.net/lists/listinfo/quickfix-developers> https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: <or...@qu...> - 2008-04-25 19:00:17
|
<html><body>What version of gcc does fedora 8 use?<BR><BR> <BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT: blue 2px solid" webmail="1">-------- Original Message --------<BR>Subject: [Quickfix-developers] Quickfix build errors on fedora 8<BR>From: "Rai, Neeraj " <nee...@ci...><BR>Date: Fri, April 25, 2008 11:46 am<BR>To: <<a href="mailto:qui...@li...urceforge">qui...@li...urceforge</a>.net><BR><BR>QuickFIX Documentation: <A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>QuickFIX Support: <A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR><BR>Hi,<BR><BR>I have encountered 2 errors in building quickfix on fedora 8. The error<BR>log attached at the end of the email.<BR><BR>1. It seems std::strcmp etc are not found. These are being included if<BR>STLport is not used. If I define HAVE_STLPORT, it goes past this error.<BR>I didn't need STLPort when I worked on it last time (on RHEL),<BR>so I would like to avoid using it.<BR>2. The 2nd one may be related. Upon defining HAVE_STLPORT,<BR>std::strerror" still cannot be found. <BR>I have to include string.h in couple of files to finish the<BR>build.<BR>I am sure, this is not the right way to fix these errors. can<BR>this be avoided by some configure options ? <BR>Any help, pointer in the right direction would be appreciated.<BR><BR>Thanks<BR>Neeraj<BR><BR>Error Log:<BR>Making all in test<BR>make[4]: Entering directory<BR>`/export/home/nr42835/Download/quickfix/src/C++/test'<BR>if /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.<BR>-I../../.. -I.. -g -O2 -Wall -ansi -Wpointer-arith -Wwrite-strings<BR>-I/usr/include/libxml2 -O0 -g -MT FieldBaseTestCase.lo -MD -MP -MF<BR>".deps/FieldBaseTestCase.Tpo" \<BR>-c -o FieldBaseTestCase.lo `test -f 'FieldBaseTestCase.cpp' ||<BR>echo './'`FieldBaseTestCase.cpp; \<BR>then mv ".deps/FieldBaseTestCase.Tpo"<BR>".deps/FieldBaseTestCase.Plo"; \<BR>else rm -f ".deps/FieldBaseTestCase.Tpo"; exit 1; \<BR>fi<BR>mkdir .libs<BR>g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -O2 -Wall -ansi<BR>-Wpointer-arith -Wwrite-strings -I/usr/include/libxml2 -O0 -g -MT<BR>FieldBaseTestCase.lo -MD -MP -MF .deps/FieldBaseTestCase.Tpo -c<BR>FieldBaseTestCase.cpp -fPIC -DPIC -o .libs/FieldBaseTestCase.o<BR>In file included from ../FieldTypes.h:30,<BR>from ../FieldConvertors.h:26,<BR>from ../Field.h:33,<BR>from FieldBaseTestCase.h:27,<BR>from FieldBaseTestCase.cpp:28:<BR>../Utility.h:179: error: 'std::strcmp' has not been declared<BR>../Utility.h:181: error: 'std::strlen' has not been declared<BR>../Utility.h:184: error: 'std::memcpy' has not been declared<BR>../Utility.h:185: error: 'std::memset' has not been declared<BR>../Utility.h:189: error: 'std::strerror' has not been declared<BR>In file included from ../FieldConvertors.h:27,<BR>from ../Field.h:33,<BR>from FieldBaseTestCase.h:27,<BR>from FieldBaseTestCase.cpp:28:<BR>../Exceptions.h: In member function 'std::string<BR>FIX::SocketException::errorToWhat()':<BR>../Exceptions.h:253: error: 'strerror' was not declared in this scope<BR>In file included from FieldBaseTestCase.h:27,<BR>from FieldBaseTestCase.cpp:28:<BR>../Field.h: In member function 'void FIX::FieldBase::calculate() const':<BR>../Field.h:110: error: 'memcpy' was not declared in this scope<BR>make[4]: *** [FieldBaseTestCase.lo] Error 1<BR><BR><BR>-------------------------------------------------------------------------<BR>This <a href="http://SF.net">SF.net</a> email is sponsored by the 2008 JavaOne(SM) Conference <BR>Don't miss this year's exciting event. There's still time to save $100. <BR>Use priority code J8TL2D2. <BR><A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A><BR>_______________________________________________<BR>Quickfix-developers mailing list<BR><A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%40lists.sourceforge.net'); return false;" href="#Compose">Quickfix-developers<B></B>@lists.sourceforge.net</A><BR><A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A><BR></BLOCKQUOTE></body></html> |
|
From: Rai, N. <nee...@ci...> - 2008-04-25 16:46:57
|
Hi,
I have encountered 2 errors in building quickfix on fedora 8. The error
log attached at the end of the email.
1. It seems std::strcmp etc are not found. These are being included if
STLport is not used. If I define HAVE_STLPORT, it goes past this error.
I didn't need STLPort when I worked on it last time (on RHEL),
so I would like to avoid using it.
2. The 2nd one may be related. Upon defining HAVE_STLPORT,
std::strerror" still cannot be found.
I have to include string.h in couple of files to finish the
build.
I am sure, this is not the right way to fix these errors. can
this be avoided by some configure options ?
Any help, pointer in the right direction would be appreciated.
Thanks
Neeraj
Error Log:
Making all in test
make[4]: Entering directory
`/export/home/nr42835/Download/quickfix/src/C++/test'
if /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I../../.. -I.. -g -O2 -Wall -ansi -Wpointer-arith -Wwrite-strings
-I/usr/include/libxml2 -O0 -g -MT FieldBaseTestCase.lo -MD -MP -MF
".deps/FieldBaseTestCase.Tpo" \
-c -o FieldBaseTestCase.lo `test -f 'FieldBaseTestCase.cpp' ||
echo './'`FieldBaseTestCase.cpp; \
then mv ".deps/FieldBaseTestCase.Tpo"
".deps/FieldBaseTestCase.Plo"; \
else rm -f ".deps/FieldBaseTestCase.Tpo"; exit 1; \
fi
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -O2 -Wall -ansi
-Wpointer-arith -Wwrite-strings -I/usr/include/libxml2 -O0 -g -MT
FieldBaseTestCase.lo -MD -MP -MF .deps/FieldBaseTestCase.Tpo -c
FieldBaseTestCase.cpp -fPIC -DPIC -o .libs/FieldBaseTestCase.o
In file included from ../FieldTypes.h:30,
from ../FieldConvertors.h:26,
from ../Field.h:33,
from FieldBaseTestCase.h:27,
from FieldBaseTestCase.cpp:28:
../Utility.h:179: error: 'std::strcmp' has not been declared
../Utility.h:181: error: 'std::strlen' has not been declared
../Utility.h:184: error: 'std::memcpy' has not been declared
../Utility.h:185: error: 'std::memset' has not been declared
../Utility.h:189: error: 'std::strerror' has not been declared
In file included from ../FieldConvertors.h:27,
from ../Field.h:33,
from FieldBaseTestCase.h:27,
from FieldBaseTestCase.cpp:28:
../Exceptions.h: In member function 'std::string
FIX::SocketException::errorToWhat()':
../Exceptions.h:253: error: 'strerror' was not declared in this scope
In file included from FieldBaseTestCase.h:27,
from FieldBaseTestCase.cpp:28:
../Field.h: In member function 'void FIX::FieldBase::calculate() const':
../Field.h:110: error: 'memcpy' was not declared in this scope
make[4]: *** [FieldBaseTestCase.lo] Error 1
|
|
From: <or...@qu...> - 2008-04-25 16:43:15
|
<html><body><div>So as many of you have noticed the old bugtrcker was causing a lot of problems and was becoming overrun by spam bots. We've axed the old bugtracker and deployed a new one which uses the Arctic bugtracker. It is available at the same location, <A href="http://www.quickfixengine.org/bugtracker"><a href="http://www.quickfixengine.org/bugtracker">http://www.quickfixengine.org/bugtracker</a></A></div></body></html> |
|
From: Rai, N. <nee...@ci...> - 2008-04-25 15:05:07
|
Rodrick , thanks for the resolution. the file actually turned out to be an html file ! I was using Right click -> Save As feature in firefox to download it. Now I just clicked on the file and followed the dialog, it downloads correctly. Neeraj _____ From: Rodrick Brown [mailto:rod...@gm...] Sent: Friday, April 25, 2008 10:42 AM To: Rai, Neeraj [CAI] Cc: qui...@li... Subject: Re: [Quickfix-developers] Cannot untar the latest .tar.gz on fedora 8 try using file <filename_you_downloaded> it will let you know if the file you downloaded is an actually gz file or tar format. My guess is its probably in tar format and still named file.tar.gz Using file should indicate if the file is corrupted, damaged or just named incorrectly. On Fri, Apr 25, 2008 at 8:45 AM, Rai, Neeraj <nee...@ci...> wrote: QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html Hi, I have worked with quick before on redhat. Now, I am trying to download and install quickfix on fedora 8. Each download seems to resulting in different size file for quickfix.tar.gz (6K or 21k) unzip, gunzip and tar cannot understand the file format. I can download the windows version, and unzip it. Any help, pointer in the right direction would be appreciated. Thanks Neeraj ------------------------------------------------------------------------ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j avaone _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown |
|
From: Siqing Z. <SZ...@Pe...> - 2008-04-25 14:47:47
|
Hi, I have one question for one market data provider application which sends price information to clients. When it sends the contracts information to the client, if there are too many contracts, then it breaks up into a number of smaller SecurityDefinition messages to send to the clients. I have a loop to go through these messages and calling FIX::Session::sendToTarget() to send each to the client. The messages for one product all have roughly the same timestamp in tag 52, SendingTime. But obviously it takes some time for the messages to get to the client. Eventually it can take longer than the MaxLatency (default to 120 seconds) specified in the config file and the client application generate a reject: "SendingTime accuracy problem". So the problems seems to be that the messages all get roughly the same timestamp in sendToTarget() function, but it could be 2 minutes later when the client really get it. Is there a way to more accurately timestamp the tag 52 for the messages going out? Thank you very much. Siqing Zhang |
|
From: Rodrick B. <rod...@gm...> - 2008-04-25 14:42:11
|
try using file <filename_you_downloaded> it will let you know if the file you downloaded is an actually gz file or tar format. My guess is its probably in tar format and still named file.tar.gz Using file should indicate if the file is corrupted, damaged or just named incorrectly. On Fri, Apr 25, 2008 at 8:45 AM, Rai, Neeraj <nee...@ci...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, > > I have worked with quick before on redhat. > Now, I am trying to download and install quickfix on fedora 8. > Each download seems to resulting in different size file for > quickfix.tar.gz (6K or 21k) > unzip, gunzip and tar cannot understand the file format. > > I can download the windows version, and unzip it. > Any help, pointer in the right direction would be appreciated. > > Thanks > Neeraj > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown |
|
From: Rai, N. <nee...@ci...> - 2008-04-25 12:46:02
|
Hi, I have worked with quick before on redhat. Now, I am trying to download and install quickfix on fedora 8. Each download seems to resulting in different size file for quickfix.tar.gz (6K or 21k) unzip, gunzip and tar cannot understand the file format. I can download the windows version, and unzip it. Any help, pointer in the right direction would be appreciated. Thanks Neeraj |
|
From: Mark T. K. <mke...@di...> - 2008-04-25 12:13:28
|
it wouldn't have any effect on the read side of the pipe (the m_interrupt socket) since m_interrupt is only consulted after select has said there is data to be read. on the write side (the side that can block), it isn't necessary if you go with the patch i sent earlier. not sure what would happen if you did turn it on since there is no message queueing scaffolding for the signals and you could potentially lose one if it simply ignored the EWOULDBLOCK. the underlying problem is that the signal should be sent *only* when the queue length transitions from zero to one and the current implementation can send it for transitions from a length of one to one. i've deployed the patch i sent and tested it a dozen times using my 6,000+ order test with no failures. my patch also passes all of the unit and app tests that are distributed with the source. /mark or...@qu... wrote: > I tried just making the signal and interrupt sockets non blocking. Can > you see if this also works for you? > > --- SocketMonitor.cpp (revision 1956) > +++ SocketMonitor.cpp (working copy) > @@ -41,6 +41,8 @@ > std::pair<int, int> sockets = socket_createpair(); > m_signal = sockets.first; > m_interrupt = sockets.second; > + socket_setnonblock( m_signal ); > + socket_setnonblock( m_interrupt ); > m_readSockets.insert( m_interrupt ); > m_timeval.tv_sec = 0; > > -------- Original Message -------- > Subject: Re: [Quickfix-developers] i'm seeing deadlocks... > From: "Mark T. Kennedy" <mke...@di...> > Date: Thu, April 24, 2008 4:25 pm > To: quickfix developers <qui...@li...urceforge > <mailto:qui...@li...urceforge>.net> > > QuickFIX Documentation: > <http://www.quickfixengine.org/quickfix/doc/html/index.html>http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: > <http://www.quickfixengine.org/services.html>http://www.quickfixengine.org/services.html > > > this patch seems to work around the problem and passes all of the > unit and app tests: > > Index: Sock etConnection.cpp > =================================================================== > --- SocketConnection.cpp (revision 1944) > +++ SocketConnection.cpp (working copy) > @@ -65,9 +65,11 @@ > > Locker l( m_mutex ); > > + int old_queue_size = m_sendQueue.size(); > m_sendQueue.push_back( msg ); > processQueue(); > - signal(); > + if ( old_queue_size == 0 && m_sendQueue.size() == 1 ) > + signal(); > return true; > > QF_STACK_POP > > /mark > > Mark T. Kennedy wrote: > > QuickFIX Documentation: > <http://www.quickfixengine.org/quickfix/doc/html/index.html>http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX Support: > <http://www.quickfixengine.org/services.html>http://www.quickfixengine.org/services.html > > > > > > the trans ition from a waiting-to-be-sent message queue length of > zero > > to a length of one triggers the writing of a notification byte to the > > Acceptor's select loop. this will eventually cause the Acceptor's > > select() call to return and setup a "can-do-a-write-without-blocking" > > callback so that the Acceptor thread can drain the message queue as > > TCP buffer space becomes available. > > > > what is perhaps not obvious is that a transition from a queue length > > of one to a queue length of one can also happen during a send > > operation by the main thread. and this transition also writes a > > notification byte. these 1=>1 transitions can happen repeatedly, > > eventually filling the notification buffer causing the main thread > > to block (thus triggering deadlock). > > > > this is because signal() writes its byte when the queue size == > 1, not > > when there is a transition from an old size of 0 to a new size of 1. > > > > consider the following sequence: > > > > 1) main thread queues a message to send (queue length goes from 0 > to 1) > > > > 2) kernel buffer is full, so no attempt to send the message > > directly on the main thread is made to avoid blocking the main > > thread. > > > > 3) the main thread writes a signal byte to trigger the asynchronous > > delivery of the queued message later by the Acceptor thread. > > > > 4) main thread queues another message (queue length goes from 1 > to 2). > > > > 5) kernel buffer space is now available (because the message receiver > > has read some messages), so the main thread can write without > > blocking. it dequeues message one (the old queued message) and > > sends all of it, leaving the new message (which was message 2) as > > the new message 1. > > > > 6) since the queue size is again just 1, a signal byte is > > written by the main t hread. > > > > when a large number of messages is sent from the main thread all at > > once, it is possible for this scenario to happen over and over again > > once a single message has been queued if the message receiver > suddenly > > opens up a lot of buffer space. > > > > /mark > > > > > > oren**@quickfixengine.org <#Compose> wrote: > > > Interesting. Didn't think about the signal socket blocking into a > > > deadlock. I'll look into that. > > > > > > -------- Original Message -------- > > > Subject: [Quickfix-developers] i'm seeing deadlocks... > > > From: "Mark T. Kennedy" <mkennedy**@diamondbackcap.com <#Compose>> > > > Date: Wed, April 23, 2008 3:43 pm > > > To: quickfix developers > <quickfix-developers**@lists.sourceforge <#Compose> > > > <mailto:quickfix-developers**@lists.sourceforge <#Compose>>.net> > > > > > > QuickFIX Documentation: > > > > > < > <http://www.quickfixengine.org/quickfix/doc/html/index.html>http://www.quickfixengine.org/quickfix/doc/html/index.html> > <http://www.quickfixengine.org/quickfix/doc/html/index.html>http://www.quickfixengine.org/quickfix/doc/html/index.html > > > QuickFIX Support: > > & gt; < > <http://www.quickfixengine.org/services.html>http://www.quickfixengine.org/services.html> > <http://www.quickfixengine.org/services.html>http://www.quickfixengine.org/services.html > > > > > > > ------------------------------------------------------------------------ > > > > > > ... while writing to the 'signal' socket (pipe) used to implement > > > non-blocking sends. > > > > > > i have a test where i send 6,000+ orders in a batch and receive > 6,000 > > > acks and 6,000 fills in response. in the middle of it, i shut down > > > and restart a proxy that sits between the sender and the exchange > > > simulator. every now and then, this triggers a deadlock in the > > > exchange simulator (see the attached stack trace). > > > ; > > > since a write to the 'signal' socket can block, sendToTarget can > > > still block, and that restores the oft-discussed deadlock scenario > > > that the non-blocking send implementation sought to avoid. > > > > > > thoughts/comments? i'm using the trunk for my tests, not 12.4. > > > > > > /mark > > > > > > > > > This communication and any attachments may contain > > > confidential/proprietary information and is intended for > information > > > purposes only. It is not an invitation or offer to purchase > > > interests from Diamondback. Any representation to the contrary is > > > unintentional. Th is communication is intended only for the > > > person(s) to whom it is addressed. If you are not the intended > > > recipient you are hereby notified that you have received this > > > document in error and that any review, dissemination, distribution, > > > or copying of this message or any attachments is not permitted. If > > > you have received this in error, please notify the sender > > > immediately by e-mail and delete this message. All e-mails sent to > > > or received from this address will be received by Diamondback's > > > company e-mail system and is subject to archival and possible > review > > > by someone other than the recipient. This notice is automatically > > > appended to each e-mail message leaving Diamondback. > > > > ------------------------------------------------------------------------ > > > Thread 3 (Thread 1084229952 (LWP 24498)): > > > #0 0x0000003a3ffc5882 in __select_nocancel () from /lib64/libc.so.6 > > > #1 0x00002aaaaf78315f in FIX::SocketMonitor::block () > > > #2 0x00002aaaaf770f74 in FIX::SocketServer::block () > > > #3 0x00002aaaaf7d60ac in FIX::HttpServer::onStart () > > > #4 0x00002aaaaf7d612f in FI X::HttpServer::startThread () > > > #5 0x0000003a40e06337 in start_thread () from > /lib64/libpthread.so.0 > > > #6 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6 > > > #7 0x0000000000000000 in ?? () > > > Thread 2 (Thread 1094719808 (LWP 24499)): > > > #0 0x0000003a40e0bb58 in __lll_mutex_lock_wait () from > > > /lib64/libpthread.so.0 > > > #1 0x0000003a40e0839e in _L_mutex_lock_65 () from > /lib64/libpthread.so.0 > > > #2 0x0000003a40e0813b in pthread_mutex_lock () from > > > /lib64/libpthread.so.0 > > > #3 0x00002aaaaf59aac2 in FIX::Mutex::lock () > > > #4 0x00002aaaaf59ab11 in FIX::Locker::Locker () > > > #5 0x00002aaaaf78678a in FIX::SocketConnection::processQueue () > > > #6 0x00002aaaaf77abca in FIX::Sock etAcceptor::onWrite () > > > #7 0x00002aaaaf771406 in FIX::ServerWrapper::onWrite () > > > #8 0x00002aaaaf782b25 in FIX::SocketMonitor::processWriteSet () > &g t; > #9 0x00002aaaaf7831c5 in FIX::SocketMonitor::block () > > > #10 0x00002aaaaf770f74 in FIX::SocketServer::block () > > > #11 0x00002aaaaf77b019 in FIX::SocketAcceptor::onStart () > > > #12 0x00002aaaaf773e1c in FIX::Acceptor::startThread () > > > #13 0x0000003a40e06337 in start_thread () from > /lib64/libpthread.so.0 > > > #14 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6 > > > #15 0x0000000000000000 in ?? () > > > Thread 1 (Thread 46912498585648 (LWP 24489)): > > > #0 0x0000003a3ffcd021 in send () from /lib64/libc.so.6 > > > #1 0x00002aaaaf7d75c3 in FIX::socket_send () > > > #2 0x00002aaaaf782bbc in FIX::SocketMonitor::signal () > > > #3 0x00002aaaaf788bcf in FIX::SocketConnection::signal () > > > #4 0x00002aaaaf786a71 in FIX::SocketConnection::send () > > > #5 0x00002aaaaf743375 in FIX::Session::send () > > > #6 0x00002aaaaf744978 in FIX::Session::sendRaw () > > ; > #7 0x00002aaaaf74a7ce in FIX::Session::send () > > > #8 0x00002aaaaf74a91e in FIX::Session::sendToTarget () > > > #9 0x00002aaaaf598698 in quickfix_wrapper::send () > > > #10 0x00002aaaaf59885f in stp_quickfix_send () > > > #11 0x00002aaaaf488b39 in XS_STP__QuickFIX_stp_quickfix_send () > > > #12 0x00002aaaaab30f3a in Perl_pp_entersub () > > > #13 0x00002aaaaab2f6ea in Perl_runops_standard () > > > #14 0x00002aaaaaadfd5d in Perl_call_sv () > > > #15 0x00002aaaae2e8090 in pe_event_invoke () > > > #16 0x00002aaaae2e8210 in pe_empty_queue () > > > #17 0x00002aaaae2e8df8 in one_event () > > > #18 0x00002aaaae2e900d in XS_Event__loop () > > > #19 0x00002aaaaab30f3a in Perl_pp_entersub () > > > #20 0x00002aaaaab2f6ea in Perl_runops_standard () > > > #21 0x00002aaaaaae05ec in perl_run () > > > #22 0x000000000040165c in main () > > > -------------------------------- > ---------------------------------------- > > > > ------------------------------------------------------------------------- > > > This SF.net <http://SF.net> < <http://sf.net/>http://SF.net> > email is sponsored by the 2008 > > > JavaOne(SM) Conference > > > Don't miss this year's exciting event. There's still time to > save $100. > > > Use priority code J8TL2D2. > > > > > < > <http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone> > <http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone>http://ad.doubleclick.n > et/clk;198757673;13503038;p?http://java.sun.com/javaone > <http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone> > > > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > > > Quickfix-developers mailing list > > > Quickfix-developers****@lists.sourceforge.net <#Compose> <#Compose> > > > > > < > <https://lists.sourceforge.net/lists/listinfo/quickfix-developers>https://lists.sourceforge.net/lists/listinfo/quickfix-developers> > <https://lists.sourceforge.net/lists/listinfo/quickfix-developers>https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > > > > This communication and any attachments may contain > confidential/proprietary information and is intended for information > purposes only. It is not an invitation or offer to purchase > interests from Diamondback. Any representation to the contrary is > unintentional. This communication is intended only for the person(s) > to whom it is addressed. If you are not the intended recipient you > are hereby notified that you have received this document in error > and that any review, dissemination, distribution, or copying of this > message or any attachments is not permitted. If you have received > this in error, please notify the sender immediately by e-mail and > delete this message. All e-mails sent to or received from this > address will be received by Diamondback's company e-mail system and > is subject to archival and possible review by someone other than the > recipient. This notice is automatically appended to each e-mail > message leaving Diamondback. > > > > > > > ------------------------------------------------------------------------- > > This SF.net <http://SF.net> email is sponsored by the 2008 > JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save > $100. > > Use priority code J8TL2D2. > > > <http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > Quickfix-developers mailing list > > Quickfix-developers**@lists.sourceforge.net <#Compose> > > > <https://lists.sourceforge.net/lists/listinfo/quickfix-developers>https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > This communication and any attachments may contain > confidential/proprietary information and is intended for information > purposes only. It is not an invitation or offer to purchase > interests from Diamondback. Any representation to the contrary is > unintentional. This communication is intended only for the person(s) > to whom it is addressed. If you are not the intended recipient you > are hereby notified that you have received this document in error > and that any review, dissemination, distribution, or copying of this > message or any attachments is not permitted. If you have received > this in error, please notify the sender immediately by e-mail and > delete this message. All e-mails sent to or received from this > address will be received by Diamondback's company e-mail system and > is subject to archival and possible review by someon e other than > the recipient. This notice is automatically appended to each e-mail > message leaving Diamondback. > > > ------------------------------------------------------------------------- > This SF.net <http://SF.net> email is sponsored by the 2008 > JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > <http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Quickfix-developers mailing list > Quickfix-developers**@lists.sourceforge.net <#Compose> > <https://lists.sourcef > orge.net/lists/listinfo/quickfix-developers>https://lists.sourceforge.net/lists/listinfo/quickfix-developers This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback. |
|
From: <or...@qu...> - 2008-04-24 22:36:08
|
<html><body><div>I tried just making the signal and interrupt sockets non blocking. Can you see if this also works for you?</div> <div> </div> <div>--- SocketMonitor.cpp (revision 1956)<BR>+++ SocketMonitor.cpp (working copy)<BR>@@ -41,6 +41,8 @@<BR> std::pair<int, int> sockets = socket_createpair();<BR> m_signal = sockets.first;<BR> m_interrupt = sockets.second;<BR>+ socket_setnonblock( m_signal );<BR>+ socket_setnonblock( m_interrupt );<BR> m_readSockets.insert( m_interrupt );</div> <div> m_timeval.tv_sec = 0;<BR></div> <BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT: blue 2px solid" webmail="1">-------- Original Message --------<BR>Subject: Re: [Quickfix-developers] i'm seeing deadlocks...<BR>From: "Mark T. Kennedy" <mke...@di...><BR>Date: Thu, April 24, 2008 4:25 pm<BR>To: quickfix developers <<a href="mailto:qui...@li...urceforge">qui...@li...urceforge</a>.net><BR><BR>QuickFIX Documentation: <A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>QuickFIX Support: <A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR><BR><BR>this patch seems to work around the problem and passes all of the unit and app tests:<BR><BR>Index: SocketConnection.cpp<BR>===================================================================<BR>--- SocketConnection.cpp (revision 1944)<BR>+++ SocketConnection.cpp (working copy)<BR>@@ -65,9 +65,11 @@<BR><BR>Locker l( m_mutex );<BR><BR>+ int old_queue_size = m_sendQueue.size();<BR>m_sendQueue.push_back( msg );<BR>processQueue();<BR>- signal();<BR>+ if ( old_queue_size == 0 && m_sendQueue.size() == 1 )<BR>+ signal();<BR>return true;<BR><BR>QF_STACK_POP<BR><BR>/mark<BR><BR>Mark T. Kennedy wrote:<BR>> QuickFIX Documentation: <A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>> QuickFIX Support: <A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR>> <BR>> <BR>> the transition from a waiting-to-be-sent message queue length of zero<BR>> to a length of one triggers the writing of a notification byte to the<BR>> Acceptor's select loop. this will eventually cause the Acceptor's<BR>> select() call to return and setup a "can-do-a-write-without-blocking"<BR>> callback so that the Acceptor thread can drain the message queue as<BR>> TCP buffer space becomes available.<BR>> <BR>> what is perhaps not obvious is that a transition from a queue length<BR>> of one to a queue length of one can also happen during a send<BR>> operation by the main thread. and this transition also writes a<BR>> notification byte. these 1=>1 transitions can happen repeatedly,<BR>> eventually filling the notification buffer causing the main thread<BR>> to block (thus triggering deadlock).<BR>> <BR>> this is because signal() writes its byte when the queue size == 1, not<BR>> when there is a transition from an old size of 0 to a new size of 1.<BR>> <BR>> consider the following sequence:<BR>> <BR>> 1) main thread queues a message to send (queue length goes from 0 to 1)<BR>> <BR>> 2) kernel buffer is full, so no attempt to send the message<BR>> directly on the main thread is made to avoid blocking the main<BR>> thread.<BR>> <BR>> 3) the main thread writes a signal byte to trigger the asynchronous<BR>> delivery of the queued message later by the Acceptor thread.<BR>> <BR>> 4) main thread queues another message (queue length goes from 1 to 2).<BR>> <BR>> 5) kernel buffer space is now available (because the message receiver<BR>> has read some messages), so the main thread can write without<BR>> blocking. it dequeues message one (the old queued message) and<BR>> sends all of it, leaving the new message (which was message 2) as<BR>> the new message 1.<BR>> <BR>> 6) since the queue size is again just 1, a signal byte is<BR>> written by the main thread.<BR>> <BR>> when a large number of messages is sent from the main thread all at<BR>> once, it is possible for this scenario to happen over and over again<BR>> once a single message has been queued if the message receiver suddenly<BR>> opens up a lot of buffer space.<BR>> <BR>> /mark<BR>> <BR>> <BR>> <A onclick="Popup.composeWindow('pcompose.php?sendto=oren%40quickfixengine.org'); return false;" href="#Compose">oren<B></B>@quickfixengine.org</A> wrote:<BR>> > Interesting. Didn't think about the signal socket blocking into a<BR>> > deadlock. I'll look into that.<BR>> ><BR>> > -------- Original Message --------<BR>> > Subject: [Quickfix-developers] i'm seeing deadlocks...<BR>> > From: "Mark T. Kennedy" <<A onclick="Popup.composeWindow('pcompose.php?sendto=mkennedy%40diamondbackcap.com'); return false;" href="#Compose">mkennedy<B></B>@diamondbackcap.com</A>><BR>> > Date: Wed, April 23, 2008 3:43 pm<BR>> > To: quickfix developers <<A onclick="Popup.composeWindow('pcompose.php?sendto=quickfix-developers%40lists.sourceforge'); return false;" href="#Compose">quickfix-developers<B></B>@lists.sourceforge</A><BR>> > <mailto:<A onclick="Popup.composeWindow('pcompose.php?sendto=quickfix-developers%40lists.sourceforge'); return false;" href="#Compose">quickfix-developers<B></B>@lists.sourceforge</A>>.net><BR>> ><BR>> > QuickFIX Documentation:<BR>> > <BR>> <<A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A>><A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>> > QuickFIX Support:<BR>> > <<A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A>><A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR>> ><BR>> > ------------------------------------------------------------------------<BR>> ><BR>> > ... while writing to the 'signal' socket (pipe) used to implement<BR>> > non-blocking sends.<BR>> ><BR>> > i have a test where i send 6,000+ orders in a batch and receive 6,000<BR>> > acks and 6,000 fills in response. in the middle of it, i shut down<BR>> > and restart a proxy that sits between the sender and the exchange<BR>> > simulator. every now and then, this triggers a deadlock in the<BR>> > exchange simulator (see the attached stack trace).<BR>> ><BR>> > since a write to the 'signal' socket can block, sendToTarget can<BR>> > still block, and that restores the oft-discussed deadlock scenario<BR>> > that the non-blocking send implementation sought to avoid.<BR>> ><BR>> > thoughts/comments? i'm using the trunk for my tests, not 12.4.<BR>> ><BR>> > /mark<BR>> ><BR>> ><BR>> > This communication and any attachments may contain<BR>> > confidential/proprietary information and is intended for information<BR>> > purposes only. It is not an invitation or offer to purchase<BR>> > interests from Diamondback. Any representation to the contrary is<BR>> > unintentional. Th is communication is intended only for the<BR>> > person(s) to whom it is addressed. If you are not the intended<BR>> > recipient you are hereby notified that you have received this<BR>> > document in error and that any review, dissemination, distribution,<BR>> > or copying of this message or any attachments is not permitted. If<BR>> > you have received this in error, please notify the sender<BR>> > immediately by e-mail and delete this message. All e-mails sent to<BR>> > or received from this address will be received by Diamondback's<BR>> > company e-mail system and is subject to archival and possible review<BR>> > by someone other than the recipient. This notice is automatically<BR>> > appended to each e-mail message leaving Diamondback.<BR>> > ------------------------------------------------------------------------<BR>> > Thread 3 (Thread 1084229952 (LWP 24498)):<BR>> > #0 0x0000003a3ffc5882 in __select_nocancel () from /lib64/libc.so.6<BR>> > #1 0x00002aaaaf78315f in FIX::SocketMonitor::block ()<BR>> > #2 0x00002aaaaf770f74 in FIX::SocketServer::block ()<BR>> > #3 0x00002aaaaf7d60ac in FIX::HttpServer::onStart ()<BR>> > #4 0x00002aaaaf7d612f in FIX::HttpServer::startThread ()<BR>> > #5 0x0000003a40e06337 in start_thread () from /lib64/libpthread.so.0<BR>> > #6 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6<BR>> > #7 0x0000000000000000 in ?? ()<BR>> > Thread 2 (Thread 1094719808 (LWP 24499)):<BR>> > #0 0x0000003a40e0bb58 in __lll_mutex_lock_wait () from<BR>> > /lib64/libpthread.so.0<BR>> > #1 0x0000003a40e0839e in _L_mutex_lock_65 () from /lib64/libpthread.so.0<BR>> > #2 0x0000003a40e0813b in pthread_mutex_lock () from<BR>> > /lib64/libpthread.so.0<BR>> > #3 0x00002aaaaf59aac2 in FIX::Mutex::lock ()<BR>> > #4 0x00002aaaaf59ab11 in FIX::Locker::Locker ()<BR>> > #5 0x00002aaaaf78678a in FIX::SocketConnection::processQueue ()<BR>> > #6 0x00002aaaaf77abca in FIX::Sock etAcceptor::onWrite ()<BR>> > #7 0x00002aaaaf771406 in FIX::ServerWrapper::onWrite ()<BR>> > #8 0x00002aaaaf782b25 in FIX::SocketMonitor::processWriteSet ()<BR>> > #9 0x00002aaaaf7831c5 in FIX::SocketMonitor::block ()<BR>> > #10 0x00002aaaaf770f74 in FIX::SocketServer::block ()<BR>> > #11 0x00002aaaaf77b019 in FIX::SocketAcceptor::onStart ()<BR>> > #12 0x00002aaaaf773e1c in FIX::Acceptor::startThread ()<BR>> > #13 0x0000003a40e06337 in start_thread () from /lib64/libpthread.so.0<BR>> > #14 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6<BR>> > #15 0x0000000000000000 in ?? ()<BR>> > Thread 1 (Thread 46912498585648 (LWP 24489)):<BR>> > #0 0x0000003a3ffcd021 in send () from /lib64/libc.so.6<BR>> > #1 0x00002aaaaf7d75c3 in FIX::socket_send ()<BR>> > #2 0x00002aaaaf782bbc in FIX::SocketMonitor::signal ()<BR>> > #3 0x00002aaaaf788bcf in FIX::SocketConnection::signal ()<BR>> > #4 0x00002aaaaf786a71 in FIX::SocketConnection::send ()<BR>> > #5 0x00002aaaaf743375 in FIX::Session::send ()<BR>> > #6 0x00002aaaaf744978 in FIX::Session::sendRaw ()<BR>> > #7 0x00002aaaaf74a7ce in FIX::Session::send ()<BR>> > #8 0x00002aaaaf74a91e in FIX::Session::sendToTarget ()<BR>> > #9 0x00002aaaaf598698 in quickfix_wrapper::send ()<BR>> > #10 0x00002aaaaf59885f in stp_quickfix_send ()<BR>> > #11 0x00002aaaaf488b39 in XS_STP__QuickFIX_stp_quickfix_send ()<BR>> > #12 0x00002aaaaab30f3a in Perl_pp_entersub ()<BR>> > #13 0x00002aaaaab2f6ea in Perl_runops_standard ()<BR>> > #14 0x00002aaaaaadfd5d in Perl_call_sv ()<BR>> > #15 0x00002aaaae2e8090 in pe_event_invoke ()<BR>> > #16 0x00002aaaae2e8210 in pe_empty_queue ()<BR>> > #17 0x00002aaaae2e8df8 in one_event ()<BR>> > #18 0x00002aaaae2e900d in XS_Event__loop ()<BR>> > #19 0x00002aaaaab30f3a in Perl_pp_entersub ()<BR>> > #20 0x00002aaaaab2f6ea in Perl_runops_standard ()<BR>> > #21 0x00002aaaaaae05ec in perl_run ()<BR>> > #22 0x000000000040165c in main ()<BR>> > ------------------------------------------------------------------------<BR>> > -------------------------------------------------------------------------<BR>> > This <a href="http://SF.net">SF.net</a> <<A href="http://sf.net/" target=_blank><a href="http://SF.net">http://SF.net</a></A>> email is sponsored by the 2008<BR>> > JavaOne(SM) Conference<BR>> > Don't miss this year's exciting event. There's still time to save $100.<BR>> > Use priority code J8TL2D2.<BR>> > <BR>> <<A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A>><A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A><BR>> ><BR>> > ------------------------------------------------------------------------<BR>> > _______________________________________________<BR>> > Quickfix-developers mailing list<BR>> > <A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%2A%2A%40lists.sourceforge.net'); return false;" href="#Compose">Quickfix-developers**<B></B>@lists.sourceforge.net</A> <#Compose><BR>> > <BR>> <<A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A>><A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A><BR>> ><BR>> <BR>> This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback.<BR>> <BR>> <BR>> -------------------------------------------------------------------------<BR>> This <a href="http://SF.net">SF.net</a> email is sponsored by the 2008 JavaOne(SM) Conference <BR>> Don't miss this year's exciting event. There's still time to save $100. <BR>> Use priority code J8TL2D2. <BR>> <A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A><BR>> _______________________________________________<BR>> Quickfix-developers mailing list<BR>> <A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%40lists.sourceforge.net'); return false;" href="#Compose">Quickfix-developers<B></B>@lists.sourceforge.net</A><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A><BR>> <BR><BR>This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback.<BR><BR><BR>-------------------------------------------------------------------------<BR>This <a href="http://SF.net">SF.net</a> email is sponsored by the 2008 JavaOne(SM) Conference <BR>Don't miss this year's exciting event. There's still time to save $100. <BR>Use priority code J8TL2D2. <BR><A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A><BR>_______________________________________________<BR>Quickfix-developers mailing list<BR><A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%40lists.sourceforge.net'); return false;" href="#Compose">Quickfix-developers<B></B>@lists.sourceforge.net</A><BR><A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A><BR></BLOCKQUOTE></body></html> |
|
From: Mark T. K. <mke...@di...> - 2008-04-24 21:28:48
|
this patch seems to work around the problem and passes all of the unit and app tests:
Index: SocketConnection.cpp
===================================================================
--- SocketConnection.cpp (revision 1944)
+++ SocketConnection.cpp (working copy)
@@ -65,9 +65,11 @@
Locker l( m_mutex );
+ int old_queue_size = m_sendQueue.size();
m_sendQueue.push_back( msg );
processQueue();
- signal();
+ if ( old_queue_size == 0 && m_sendQueue.size() == 1 )
+ signal();
return true;
QF_STACK_POP
/mark
Mark T. Kennedy wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> the transition from a waiting-to-be-sent message queue length of zero
> to a length of one triggers the writing of a notification byte to the
> Acceptor's select loop. this will eventually cause the Acceptor's
> select() call to return and setup a "can-do-a-write-without-blocking"
> callback so that the Acceptor thread can drain the message queue as
> TCP buffer space becomes available.
>
> what is perhaps not obvious is that a transition from a queue length
> of one to a queue length of one can also happen during a send
> operation by the main thread. and this transition also writes a
> notification byte. these 1=>1 transitions can happen repeatedly,
> eventually filling the notification buffer causing the main thread
> to block (thus triggering deadlock).
>
> this is because signal() writes its byte when the queue size == 1, not
> when there is a transition from an old size of 0 to a new size of 1.
>
> consider the following sequence:
>
> 1) main thread queues a message to send (queue length goes from 0 to 1)
>
> 2) kernel buffer is full, so no attempt to send the message
> directly on the main thread is made to avoid blocking the main
> thread.
>
> 3) the main thread writes a signal byte to trigger the asynchronous
> delivery of the queued message later by the Acceptor thread.
>
> 4) main thread queues another message (queue length goes from 1 to 2).
>
> 5) kernel buffer space is now available (because the message receiver
> has read some messages), so the main thread can write without
> blocking. it dequeues message one (the old queued message) and
> sends all of it, leaving the new message (which was message 2) as
> the new message 1.
>
> 6) since the queue size is again just 1, a signal byte is
> written by the main thread.
>
> when a large number of messages is sent from the main thread all at
> once, it is possible for this scenario to happen over and over again
> once a single message has been queued if the message receiver suddenly
> opens up a lot of buffer space.
>
> /mark
>
>
> or...@qu... wrote:
> > Interesting. Didn't think about the signal socket blocking into a
> > deadlock. I'll look into that.
> >
> > -------- Original Message --------
> > Subject: [Quickfix-developers] i'm seeing deadlocks...
> > From: "Mark T. Kennedy" <mke...@di...>
> > Date: Wed, April 23, 2008 3:43 pm
> > To: quickfix developers <qui...@li...urceforge
> > <mailto:qui...@li...urceforge>.net>
> >
> > QuickFIX Documentation:
> >
> <http://www.quickfixengine.org/quickfix/doc/html/index.html>http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support:
> > <http://www.quickfixengine.org/services.html>http://www.quickfixengine.org/services.html
> >
> > ------------------------------------------------------------------------
> >
> > ... while writing to the 'signal' socket (pipe) used to implement
> > non-blocking sends.
> >
> > i have a test where i send 6,000+ orders in a batch and receive 6,000
> > acks and 6,000 fills in response. in the middle of it, i shut down
> > and restart a proxy that sits between the sender and the exchange
> > simulator. every now and then, this triggers a deadlock in the
> > exchange simulator (see the attached stack trace).
> >
> > since a write to the 'signal' socket can block, sendToTarget can
> > still block, and that restores the oft-discussed deadlock scenario
> > that the non-blocking send implementation sought to avoid.
> >
> > thoughts/comments? i'm using the trunk for my tests, not 12.4.
> >
> > /mark
> >
> >
> > This communication and any attachments may contain
> > confidential/proprietary information and is intended for information
> > purposes only. It is not an invitation or offer to purchase
> > interests from Diamondback. Any representation to the contrary is
> > unintentional. Th is communication is intended only for the
> > person(s) to whom it is addressed. If you are not the intended
> > recipient you are hereby notified that you have received this
> > document in error and that any review, dissemination, distribution,
> > or copying of this message or any attachments is not permitted. If
> > you have received this in error, please notify the sender
> > immediately by e-mail and delete this message. All e-mails sent to
> > or received from this address will be received by Diamondback's
> > company e-mail system and is subject to archival and possible review
> > by someone other than the recipient. This notice is automatically
> > appended to each e-mail message leaving Diamondback.
> > ------------------------------------------------------------------------
> > Thread 3 (Thread 1084229952 (LWP 24498)):
> > #0 0x0000003a3ffc5882 in __select_nocancel () from /lib64/libc.so.6
> > #1 0x00002aaaaf78315f in FIX::SocketMonitor::block ()
> > #2 0x00002aaaaf770f74 in FIX::SocketServer::block ()
> > #3 0x00002aaaaf7d60ac in FIX::HttpServer::onStart ()
> > #4 0x00002aaaaf7d612f in FIX::HttpServer::startThread ()
> > #5 0x0000003a40e06337 in start_thread () from /lib64/libpthread.so.0
> > #6 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6
> > #7 0x0000000000000000 in ?? ()
> > Thread 2 (Thread 1094719808 (LWP 24499)):
> > #0 0x0000003a40e0bb58 in __lll_mutex_lock_wait () from
> > /lib64/libpthread.so.0
> > #1 0x0000003a40e0839e in _L_mutex_lock_65 () from /lib64/libpthread.so.0
> > #2 0x0000003a40e0813b in pthread_mutex_lock () from
> > /lib64/libpthread.so.0
> > #3 0x00002aaaaf59aac2 in FIX::Mutex::lock ()
> > #4 0x00002aaaaf59ab11 in FIX::Locker::Locker ()
> > #5 0x00002aaaaf78678a in FIX::SocketConnection::processQueue ()
> > #6 0x00002aaaaf77abca in FIX::Sock etAcceptor::onWrite ()
> > #7 0x00002aaaaf771406 in FIX::ServerWrapper::onWrite ()
> > #8 0x00002aaaaf782b25 in FIX::SocketMonitor::processWriteSet ()
> > #9 0x00002aaaaf7831c5 in FIX::SocketMonitor::block ()
> > #10 0x00002aaaaf770f74 in FIX::SocketServer::block ()
> > #11 0x00002aaaaf77b019 in FIX::SocketAcceptor::onStart ()
> > #12 0x00002aaaaf773e1c in FIX::Acceptor::startThread ()
> > #13 0x0000003a40e06337 in start_thread () from /lib64/libpthread.so.0
> > #14 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6
> > #15 0x0000000000000000 in ?? ()
> > Thread 1 (Thread 46912498585648 (LWP 24489)):
> > #0 0x0000003a3ffcd021 in send () from /lib64/libc.so.6
> > #1 0x00002aaaaf7d75c3 in FIX::socket_send ()
> > #2 0x00002aaaaf782bbc in FIX::SocketMonitor::signal ()
> > #3 0x00002aaaaf788bcf in FIX::SocketConnection::signal ()
> > #4 0x00002aaaaf786a71 in FIX::SocketConnection::send ()
> > #5 0x00002aaaaf743375 in FIX::Session::send ()
> > #6 0x00002aaaaf744978 in FIX::Session::sendRaw ()
> > #7 0x00002aaaaf74a7ce in FIX::Session::send ()
> > #8 0x00002aaaaf74a91e in FIX::Session::sendToTarget ()
> > #9 0x00002aaaaf598698 in quickfix_wrapper::send ()
> > #10 0x00002aaaaf59885f in stp_quickfix_send ()
> > #11 0x00002aaaaf488b39 in XS_STP__QuickFIX_stp_quickfix_send ()
> > #12 0x00002aaaaab30f3a in Perl_pp_entersub ()
> > #13 0x00002aaaaab2f6ea in Perl_runops_standard ()
> > #14 0x00002aaaaaadfd5d in Perl_call_sv ()
> > #15 0x00002aaaae2e8090 in pe_event_invoke ()
> > #16 0x00002aaaae2e8210 in pe_empty_queue ()
> > #17 0x00002aaaae2e8df8 in one_event ()
> > #18 0x00002aaaae2e900d in XS_Event__loop ()
> > #19 0x00002aaaaab30f3a in Perl_pp_entersub ()
> > #20 0x00002aaaaab2f6ea in Perl_runops_standard ()
> > #21 0x00002aaaaaae05ec in perl_run ()
> > #22 0x000000000040165c in main ()
> > ------------------------------------------------------------------------
> > -------------------------------------------------------------------------
> > This SF.net <http://SF.net> email is sponsored by the 2008
> > JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
> >
> <http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >
> > ------------------------------------------------------------------------
> > _______________________________________________
> > Quickfix-developers mailing list
> > Quickfix-developers**@lists.sourceforge.net <#Compose>
> >
> <https://lists.sourceforge.net/lists/listinfo/quickfix-developers>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
> This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback.
|
|
From: Mark T. K. <mke...@di...> - 2008-04-24 20:33:42
|
the transition from a waiting-to-be-sent message queue length of zero
to a length of one triggers the writing of a notification byte to the
Acceptor's select loop. this will eventually cause the Acceptor's
select() call to return and setup a "can-do-a-write-without-blocking"
callback so that the Acceptor thread can drain the message queue as
TCP buffer space becomes available.
what is perhaps not obvious is that a transition from a queue length
of one to a queue length of one can also happen during a send
operation by the main thread. and this transition also writes a
notification byte. these 1=>1 transitions can happen repeatedly,
eventually filling the notification buffer causing the main thread
to block (thus triggering deadlock).
this is because signal() writes its byte when the queue size == 1, not
when there is a transition from an old size of 0 to a new size of 1.
consider the following sequence:
1) main thread queues a message to send (queue length goes from 0 to 1)
2) kernel buffer is full, so no attempt to send the message
directly on the main thread is made to avoid blocking the main
thread.
3) the main thread writes a signal byte to trigger the asynchronous
delivery of the queued message later by the Acceptor thread.
4) main thread queues another message (queue length goes from 1 to 2).
5) kernel buffer space is now available (because the message receiver
has read some messages), so the main thread can write without
blocking. it dequeues message one (the old queued message) and
sends all of it, leaving the new message (which was message 2) as
the new message 1.
6) since the queue size is again just 1, a signal byte is
written by the main thread.
when a large number of messages is sent from the main thread all at
once, it is possible for this scenario to happen over and over again
once a single message has been queued if the message receiver suddenly
opens up a lot of buffer space.
/mark
or...@qu... wrote:
> Interesting. Didn't think about the signal socket blocking into a
> deadlock. I'll look into that.
>
> -------- Original Message --------
> Subject: [Quickfix-developers] i'm seeing deadlocks...
> From: "Mark T. Kennedy" <mke...@di...>
> Date: Wed, April 23, 2008 3:43 pm
> To: quickfix developers <qui...@li...urceforge
> <mailto:qui...@li...urceforge>.net>
>
> QuickFIX Documentation:
>
<http://www.quickfixengine.org/quickfix/doc/html/index.html>http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support:
> <http://www.quickfixengine.org/services.html>http://www.quickfixengine.org/services.html
>
> ------------------------------------------------------------------------
>
> ... while writing to the 'signal' socket (pipe) used to implement
> non-blocking sends.
>
> i have a test where i send 6,000+ orders in a batch and receive 6,000
> acks and 6,000 fills in response. in the middle of it, i shut down
> and restart a proxy that sits between the sender and the exchange
> simulator. every now and then, this triggers a deadlock in the
> exchange simulator (see the attached stack trace).
>
> since a write to the 'signal' socket can block, sendToTarget can
> still block, and that restores the oft-discussed deadlock scenario
> that the non-blocking send implementation sought to avoid.
>
> thoughts/comments? i'm using the trunk for my tests, not 12.4.
>
> /mark
>
>
> This communication and any attachments may contain
> confidential/proprietary information and is intended for information
> purposes only. It is not an invitation or offer to purchase
> interests from Diamondback. Any representation to the contrary is
> unintentional. Th is communication is intended only for the
> person(s) to whom it is addressed. If you are not the intended
> recipient you are hereby notified that you have received this
> document in error and that any review, dissemination, distribution,
> or copying of this message or any attachments is not permitted. If
> you have received this in error, please notify the sender
> immediately by e-mail and delete this message. All e-mails sent to
> or received from this address will be received by Diamondback's
> company e-mail system and is subject to archival and possible review
> by someone other than the recipient. This notice is automatically
> appended to each e-mail message leaving Diamondback.
> ------------------------------------------------------------------------
> Thread 3 (Thread 1084229952 (LWP 24498)):
> #0 0x0000003a3ffc5882 in __select_nocancel () from /lib64/libc.so.6
> #1 0x00002aaaaf78315f in FIX::SocketMonitor::block ()
> #2 0x00002aaaaf770f74 in FIX::SocketServer::block ()
> #3 0x00002aaaaf7d60ac in FIX::HttpServer::onStart ()
> #4 0x00002aaaaf7d612f in FIX::HttpServer::startThread ()
> #5 0x0000003a40e06337 in start_thread () from /lib64/libpthread.so.0
> #6 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6
> #7 0x0000000000000000 in ?? ()
> Thread 2 (Thread 1094719808 (LWP 24499)):
> #0 0x0000003a40e0bb58 in __lll_mutex_lock_wait () from
> /lib64/libpthread.so.0
> #1 0x0000003a40e0839e in _L_mutex_lock_65 () from /lib64/libpthread.so.0
> #2 0x0000003a40e0813b in pthread_mutex_lock () from
> /lib64/libpthread.so.0
> #3 0x00002aaaaf59aac2 in FIX::Mutex::lock ()
> #4 0x00002aaaaf59ab11 in FIX::Locker::Locker ()
> #5 0x00002aaaaf78678a in FIX::SocketConnection::processQueue ()
> #6 0x00002aaaaf77abca in FIX::Sock etAcceptor::onWrite ()
> #7 0x00002aaaaf771406 in FIX::ServerWrapper::onWrite ()
> #8 0x00002aaaaf782b25 in FIX::SocketMonitor::processWriteSet ()
> #9 0x00002aaaaf7831c5 in FIX::SocketMonitor::block ()
> #10 0x00002aaaaf770f74 in FIX::SocketServer::block ()
> #11 0x00002aaaaf77b019 in FIX::SocketAcceptor::onStart ()
> #12 0x00002aaaaf773e1c in FIX::Acceptor::startThread ()
> #13 0x0000003a40e06337 in start_thread () from /lib64/libpthread.so.0
> #14 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6
> #15 0x0000000000000000 in ?? ()
> Thread 1 (Thread 46912498585648 (LWP 24489)):
> #0 0x0000003a3ffcd021 in send () from /lib64/libc.so.6
> #1 0x00002aaaaf7d75c3 in FIX::socket_send ()
> #2 0x00002aaaaf782bbc in FIX::SocketMonitor::signal ()
> #3 0x00002aaaaf788bcf in FIX::SocketConnection::signal ()
> #4 0x00002aaaaf786a71 in FIX::SocketConnection::send ()
> #5 0x00002aaaaf743375 in FIX::Session::send ()
> #6 0x00002aaaaf744978 in FIX::Session::sendRaw ()
> #7 0x00002aaaaf74a7ce in FIX::Session::send ()
> #8 0x00002aaaaf74a91e in FIX::Session::sendToTarget ()
> #9 0x00002aaaaf598698 in quickfix_wrapper::send ()
> #10 0x00002aaaaf59885f in stp_quickfix_send ()
> #11 0x00002aaaaf488b39 in XS_STP__QuickFIX_stp_quickfix_send ()
> #12 0x00002aaaaab30f3a in Perl_pp_entersub ()
> #13 0x00002aaaaab2f6ea in Perl_runops_standard ()
> #14 0x00002aaaaaadfd5d in Perl_call_sv ()
> #15 0x00002aaaae2e8090 in pe_event_invoke ()
> #16 0x00002aaaae2e8210 in pe_empty_queue ()
> #17 0x00002aaaae2e8df8 in one_event ()
> #18 0x00002aaaae2e900d in XS_Event__loop ()
> #19 0x00002aaaaab30f3a in Perl_pp_entersub ()
> #20 0x00002aaaaab2f6ea in Perl_runops_standard ()
> #21 0x00002aaaaaae05ec in perl_run ()
> #22 0x000000000040165c in main ()
> ------------------------------------------------------------------------
> -------------------------------------------------------------------------
> This SF.net <http://SF.net> email is sponsored by the 2008
> JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
<http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>
> ------------------------------------------------------------------------
> _______________________________________________
> Quickfix-developers mailing list
> Quickfix-developers**@lists.sourceforge.net <#Compose>
>
<https://lists.sourceforge.net/lists/listinfo/quickfix-developers>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback.
|
|
From: <or...@qu...> - 2008-04-24 18:24:00
|
<html><body><div>There is a method in the C++ message called identifyType which looks at a string and parses it just enough to identify the type. We could expose this though that would still require converting the C++ string to a java string twice which isn't the most efficient thing in the world either. Probably the best thing to do would be to reimplement that method in java.</div>
<div> </div>
<div>The existing C++ method looks like this:</div>
<div> </div>
<div>inline MsgType identifyType( const std::string& message )<BR>throw( MessageParseError )<BR>{<BR> std::string::size_type pos = message.find( "\00135=" );<BR> if ( pos == std::string::npos ) throw MessageParseError();</div>
<div> std::string::size_type startValue = pos + 4;<BR> std::string::size_type soh = message.find_first_of( '\001', startValue );<BR> if ( soh == std::string::npos ) throw MessageParseError();</div>
<div> std::string value = message.substr( startValue, soh - startValue );<BR> return MsgType( value );<BR>}<BR></div>
<div>Basically just searches for the first instance of [SOH]35= and the following [SOH], everything in between is the msgtype. Pretty efficient since the MsgType is always guaranteed to be in the same place near the start of the message.</div>
<div> </div>
<div>--oren</div>
<BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT: blue 2px solid" webmail="1">-------- Original Message --------<BR>Subject: [Quickfix-developers] Efficient Message creation<BR>From: Mike Perik <mic...@ya...><BR>Date: Thu, April 24, 2008 12:05 pm<BR>To: <a href="mailto:qui...@li...">qui...@li...</a><BR><BR>QuickFIX Documentation: <A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>QuickFIX Support: <A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR><BR>If I have a raw FIX string what is the most efficient method for creating a Message object out of it using the Java API?<BR><BR>The way I was doing it was this:<BR><BR>// Have to do this to get the 'BeginString' and 'MsgType' fields<BR>// I guess I could do some manual field checking/lookup<BR>Message fixmsg = new Message(fixmsgstr);<BR>String beginString = fixmsg.getHeader().getString(BeginString.FIELD);<BR>String fixMsgType = fixmsg.getHeader().getString(MsgType.FIELD);<BR><BR>// m_messageFactory is an instance of the DefaultMessageFactory<BR>// This returns the FIX version specific message<BR>m_messageFactory.create(beginString, fixMsgType);<BR>fixmsg.initFromString(fixmsgstr, true);<BR><BR><BR>The problem with the way I doing it is that the raw FIX message string gets parsed twice. I need the FIX version specific Message object so when I call the crack() method the MessageCracker() can determine the version specific method to call. I'm getting a ClassCastException right now.<BR><BR>Is there another way to do this? 'This' being create a version specific Message object from a raw message string.<BR><BR>Thanks,<BR>Mike<BR><BR><BR><BR>____________________________________________________________________________________<BR>Be a better friend, newshound, and <BR>know-it-all with Yahoo! Mobile. Try it now. <A href="http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ" target=_blank><a href="http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ">http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ</a></A><BR><BR>-------------------------------------------------------------------------<BR>This <a href="http://SF.net">SF.net</a> email is sponsored by the 2008 JavaOne(SM) Conference <BR>Don't miss this year's exciting event. There's still time to save $100. <BR>Use priority code J8TL2D2. <BR><A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A><BR>_______________________________________________<BR>Quickfix-developers mailing list<BR><A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%40lists.sourceforge.net'); return false;" href="#Compose">Quickfix-developers<B></B>@lists.sourceforge.net</A><BR><A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A><BR></BLOCKQUOTE></body></html>
|
|
From: Mike P. <mic...@ya...> - 2008-04-24 17:05:19
|
If I have a raw FIX string what is the most efficient method for creating a Message object out of it using the Java API?
The way I was doing it was this:
// Have to do this to get the 'BeginString' and 'MsgType' fields
// I guess I could do some manual field checking/lookup
Message fixmsg = new Message(fixmsgstr);
String beginString = fixmsg.getHeader().getString(BeginString.FIELD);
String fixMsgType = fixmsg.getHeader().getString(MsgType.FIELD);
// m_messageFactory is an instance of the DefaultMessageFactory
// This returns the FIX version specific message
m_messageFactory.create(beginString, fixMsgType);
fixmsg.initFromString(fixmsgstr, true);
The problem with the way I doing it is that the raw FIX message string gets parsed twice. I need the FIX version specific Message object so when I call the crack() method the MessageCracker() can determine the version specific method to call. I'm getting a ClassCastException right now.
Is there another way to do this? 'This' being create a version specific Message object from a raw message string.
Thanks,
Mike
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|
|
From: <or...@qu...> - 2008-04-23 21:31:42
|
<html><body><div>It will go out into a release. I'm just trying to get some early feedback since it is an oft requested feature and I'm sure there are a lot of ideas about how this thing should work. The trunk is generally not recommended for production use unless there is something in there you really need. And in that case we recommend you upgrade as soon as an official release comes out.</div> <div> </div> <div>--oren</div> <BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT: blue 2px solid" webmail="1">-------- Original Message --------<BR>Subject: Re: [Quickfix-developers] Log rotation<BR>From: Rich Holm <rh...@wo...><BR>Date: Wed, April 23, 2008 2:50 pm<BR>To: <a href="mailto:qui...@li...">qui...@li...</a><BR><BR>QuickFIX Documentation: <A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>QuickFIX Support: <A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR><BR><BR>Very nice. Will this feature go out in a new release or is the svn <BR>repository the preferred way<BR>to get a production release? We have been using 1.12.4 for a long time <BR>and are very happy<BR>with it.<BR><BR>Thanks!<BR><BR>Cheers,<BR>Rich<BR><BR><BR><A onclick="Popup.composeWindow('pcompose.php?sendto=oren%40quickfixengine.org'); return false;" href="#Compose">oren<B></B>@quickfixengine.org</A> wrote:<BR>> QuickFIX Documentation: <A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>> QuickFIX Support: <A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR>><BR>> <BR>><BR>> ------------------------------------------------------------------------<BR>><BR>> I've added some basic log rotation support to the filelog. There is a <BR>> method call in the base log class called backup(), which will backup <BR>> the current log into a numbered backup. The existing log is then <BR>> truncated. This functionality is checked into the trunk. Right now <BR>> you need to manually call backup (which can be accessed by requesting <BR>> a pointer to the log from your session object). I'm looking to add <BR>> support for automated backups as well as backup support for databases.<BR>> ------------------------------------------------------------------------<BR>><BR>> -------------------------------------------------------------------------<BR>> This <a href="http://SF.net">SF.net</a> email is sponsored by the 2008 JavaOne(SM) Conference <BR>> Don't miss this year's exciting event. There's still time to save $100. <BR>> Use priority code J8TL2D2. <BR>> <A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A><BR>> ------------------------------------------------------------------------<BR>><BR>> _______________________________________________<BR>> Quickfix-developers mailing list<BR>> <A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%40lists.sourceforge.net'); return false;" href="#Compose">Quickfix-developers<B></B>@lists.sourceforge.net</A><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A><BR><BR><BR><BR>This message is intended only for the personal and confidential use of the recipients named above. <BR>If the reader of this email is not the intended recipient, you have received this email in error and any review, <BR>dissemination, distribution or copying is strictly prohibited. If you have received this email in error, <BR>please notify the sender immediately by return email and permanently delete the copy you received. <BR><BR>This message is provided for informational purposes and should not be construed as a solicitation or offer <BR>to buy or sell any securities or related financial instruments. Wolverine is not responsible for any <BR>recommendation, solicitation, offer or agreement or any information about any transaction, customer account <BR>or account activity that may be attached to or contained in this communication. Wolverine accepts no <BR>liability for any content contained in the email, or any errors or omissions arising as a result of <BR>email transmission. Any opinions contained in this email constitute the sender's best judgment at this <BR>time and are subject to change without notice.<BR><BR>-------------------------------------------------------------------------<BR>This <a href="http://SF.net">SF.net</a> email is sponsored by the 2008 JavaOne(SM) Conference <BR>Don't miss this year's exciting event. There's still time to save $100. <BR>Use priority code J8TL2D2. <BR><A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A><BR>_______________________________________________<BR>Quickfix-developers mailing list<BR><A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%40lists.sourceforge.net'); return false;" href="#Compose">Quickfix-developers<B></B>@lists.sourceforge.net</A><BR><A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A><BR></BLOCKQUOTE></body></html> |
|
From: <or...@qu...> - 2008-04-23 21:29:37
|
<html><body>Interesting. Didn't think about the signal socket blocking into a deadlock. I'll look into that.<BR><BR> <BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT: blue 2px solid" webmail="1">-------- Original Message --------<BR>Subject: [Quickfix-developers] i'm seeing deadlocks...<BR>From: "Mark T. Kennedy" <mke...@di...><BR>Date: Wed, April 23, 2008 3:43 pm<BR>To: quickfix developers <<a href="mailto:qui...@li...urceforge">qui...@li...urceforge</a>.net><BR><BR>QuickFIX Documentation: <A href="http://www.quickfixengine.org/quickfix/doc/html/index.html" target=_blank><a href="http://www.quickfixengine.org/quickfix/doc/html/index.html">http://www.quickfixengine.org/quickfix/doc/html/index.html</a></A><BR>QuickFIX Support: <A href="http://www.quickfixengine.org/services.html" target=_blank><a href="http://www.quickfixengine.org/services.html">http://www.quickfixengine.org/services.html</a></A><BR><BR> <HR> <BR>... while writing to the 'signal' socket (pipe) used to implement<BR>non-blocking sends.<BR><BR>i have a test where i send 6,000+ orders in a batch and receive 6,000<BR>acks and 6,000 fills in response. in the middle of it, i shut down<BR>and restart a proxy that sits between the sender and the exchange<BR>simulator. every now and then, this triggers a deadlock in the<BR>exchange simulator (see the attached stack trace).<BR><BR>since a write to the 'signal' socket can block, sendToTarget can<BR>still block, and that restores the oft-discussed deadlock scenario<BR>that the non-blocking send implementation sought to avoid.<BR><BR>thoughts/comments? i'm using the trunk for my tests, not 12.4.<BR><BR>/mark<BR><BR><BR>This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback. <HR> Thread 3 (Thread 1084229952 (LWP 24498)):<BR>#0 0x0000003a3ffc5882 in __select_nocancel () from /lib64/libc.so.6<BR>#1 0x00002aaaaf78315f in FIX::SocketMonitor::block ()<BR>#2 0x00002aaaaf770f74 in FIX::SocketServer::block ()<BR>#3 0x00002aaaaf7d60ac in FIX::HttpServer::onStart ()<BR>#4 0x00002aaaaf7d612f in FIX::HttpServer::startThread ()<BR>#5 0x0000003a40e06337 in start_thread () from /lib64/libpthread.so.0<BR>#6 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6<BR>#7 0x0000000000000000 in ?? ()<BR>Thread 2 (Thread 1094719808 (LWP 24499)):<BR>#0 0x0000003a40e0bb58 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0<BR>#1 0x0000003a40e0839e in _L_mutex_lock_65 () from /lib64/libpthread.so.0<BR>#2 0x0000003a40e0813b in pthread_mutex_lock () from /lib64/libpthread.so.0<BR>#3 0x00002aaaaf59aac2 in FIX::Mutex::lock ()<BR>#4 0x00002aaaaf59ab11 in FIX::Locker::Locker ()<BR>#5 0x00002aaaaf78678a in FIX::SocketConnection::processQueue ()<BR>#6 0x00002aaaaf77abca in FIX::SocketAcceptor::onWrite ()<BR>#7 0x00002aaaaf771406 in FIX::ServerWrapper::onWrite ()<BR>#8 0x00002aaaaf782b25 in FIX::SocketMonitor::processWriteSet ()<BR>#9 0x00002aaaaf7831c5 in FIX::SocketMonitor::block ()<BR>#10 0x00002aaaaf770f74 in FIX::SocketServer::block ()<BR>#11 0x00002aaaaf77b019 in FIX::SocketAcceptor::onStart ()<BR>#12 0x00002aaaaf773e1c in FIX::Acceptor::startThread ()<BR>#13 0x0000003a40e06337 in start_thread () from /lib64/libpthread.so.0<BR>#14 0x0000003a3ffcc38d in clone () from /lib64/libc.so.6<BR>#15 0x0000000000000000 in ?? ()<BR>Thread 1 (Thread 46912498585648 (LWP 24489)):<BR>#0 0x0000003a3ffcd021 in send () from /lib64/libc.so.6<BR>#1 0x00002aaaaf7d75c3 in FIX::socket_send ()<BR>#2 0x00002aaaaf782bbc in FIX::SocketMonitor::signal ()<BR>#3 0x00002aaaaf788bcf in FIX::SocketConnection::signal ()<BR>#4 0x00002aaaaf786a71 in FIX::SocketConnection::send ()<BR>#5 0x00002aaaaf743375 in FIX::Session::send ()<BR>#6 0x00002aaaaf744978 in FIX::Session::sendRaw ()<BR>#7 0x00002aaaaf74a7ce in FIX::Session::send ()<BR>#8 0x00002aaaaf74a91e in FIX::Session::sendToTarget ()<BR>#9 0x00002aaaaf598698 in quickfix_wrapper::send ()<BR>#10 0x00002aaaaf59885f in stp_quickfix_send ()<BR>#11 0x00002aaaaf488b39 in XS_STP__QuickFIX_stp_quickfix_send ()<BR>#12 0x00002aaaaab30f3a in Perl_pp_entersub ()<BR>#13 0x00002aaaaab2f6ea in Perl_runops_standard ()<BR>#14 0x00002aaaaaadfd5d in Perl_call_sv ()<BR>#15 0x00002aaaae2e8090 in pe_event_invoke ()<BR>#16 0x00002aaaae2e8210 in pe_empty_queue ()<BR>#17 0x00002aaaae2e8df8 in one_event ()<BR>#18 0x00002aaaae2e900d in XS_Event__loop ()<BR>#19 0x00002aaaaab30f3a in Perl_pp_entersub ()<BR>#20 0x00002aaaaab2f6ea in Perl_runops_standard ()<BR>#21 0x00002aaaaaae05ec in perl_run ()<BR>#22 0x000000000040165c in main ()<BR> <HR> -------------------------------------------------------------------------<BR>This <a href="http://SF.net">SF.net</a> email is sponsored by the 2008 JavaOne(SM) Conference <BR>Don't miss this year's exciting event. There's still time to save $100. <BR>Use priority code J8TL2D2. <BR><A href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone" target=_blank><a href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a></A> <HR> _______________________________________________<BR>Quickfix-developers mailing list<BR><A onclick="Popup.composeWindow('pcompose.php?sendto=Quickfix-developers%40lists.sourceforge.net'); return false;" href="#Compose">Quickfix-developers<B></B>@lists.sourceforge.net</A><BR><A href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers" target=_blank><a href="https://lists.sourceforge.net/lists/listinfo/quickfix-developers">https://lists.sourceforge.net/lists/listinfo/quickfix-developers</a></A> </BLOCKQUOTE></body></html> |
|
From: Mark T. K. <mke...@di...> - 2008-04-23 20:46:12
|
... while writing to the 'signal' socket (pipe) used to implement non-blocking sends. i have a test where i send 6,000+ orders in a batch and receive 6,000 acks and 6,000 fills in response. in the middle of it, i shut down and restart a proxy that sits between the sender and the exchange simulator. every now and then, this triggers a deadlock in the exchange simulator (see the attached stack trace). since a write to the 'signal' socket can block, sendToTarget can still block, and that restores the oft-discussed deadlock scenario that the non-blocking send implementation sought to avoid. thoughts/comments? i'm using the trunk for my tests, not 12.4. /mark This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback. |
|
From: Rich H. <rh...@wo...> - 2008-04-23 19:51:11
|
Very nice. Will this feature go out in a new release or is the svn repository the preferred way to get a production release? We have been using 1.12.4 for a long time and are very happy with it. Thanks! Cheers, Rich or...@qu... wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > > ------------------------------------------------------------------------ > > I've added some basic log rotation support to the filelog. There is a > method call in the base log class called backup(), which will backup > the current log into a numbered backup. The existing log is then > truncated. This functionality is checked into the trunk. Right now > you need to manually call backup (which can be accessed by requesting > a pointer to the log from your session object). I'm looking to add > support for automated backups as well as backup support for databases. > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ------------------------------------------------------------------------ > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. Wolverine is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity that may be attached to or contained in this communication. Wolverine accepts no liability for any content contained in the email, or any errors or omissions arising as a result of email transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice. |
|
From: <or...@qu...> - 2008-04-23 15:06:53
|
<html><body>I've added some basic log rotation support to the filelog. There is a method call in the base log class called backup(), which will backup the current log into a numbered backup. The existing log is then truncated. This functionality is checked into the trunk. Right now you need to manually call backup (which can be accessed by requesting a pointer to the log from your session object). I'm looking to add support for automated backups as well as backup support for databases.</body></html> |
|
From: <ern...@bn...> - 2008-04-23 11:07:29
|
We need to develop a simple fix engine to process between 1000-10000 daily
transactions. The team involved in this project can only perform the
developments with VB6, but they do have limited access to Java developers.
Since quickfix is not directly suitable for VB6 developments, we are
considering developing a small technical application in Java that will use
MQseries as middleware to link the functionality of the VB6 application to
the quickfix Java application.
Since at present we have very limited knowledge of quickfix functionality,
I would be interested to hear your opinions with regards to this. Will we
loose a lot of functionality ? Do you foresee any problems ?
The alternative to this solution would appear to be a comercial solution
that already has an mqseries or active X in place to link to VB6.
We have until the end of the month to decide which way to go, all your
comments would be greatly appreciated.
Many thanks, Ernesto
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
Do not print this message unless it is necessary,
consider the environment.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
N'imprimez ce message que si necessaire,
pensez a l'environnement.
|
|
From: Dale W. <wil...@oc...> - 2008-04-22 20:58:39
|
> On Tue, Apr 22, 2008 at 6:24 AM, Åsa Sandberg <asa...@ly...> wrote: > > > Hi all, > > Is there a way to turn off the display of all the FIX messages in the output window in Visual Studio? > Andrei Goldchleger wrote: > > You are probably using a ScreenLogFactory. Try changing that to a > FileLogFactory. > You have two more options available: You may turnoff individual types of log messages (input, output, event) by changing the boolean arguments to the ScreenLogFactory Or you can turn off logging altogether by omitting that argument to the SocketAcceptor and/or SocketInitiator constructors. Dale |
98 messages has been excluded from this view by a project administrator.
