quickfix-developers Mailing List for QuickFIX (Page 15)
Brought to you by:
orenmnero
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: Neeraj R. <rn...@ya...> - 2013-08-20 02:45:43
|
It is the other way around as per Hei Chan reply to original question: See also: SocketConnection::send : SocketConnection.cpp:68 queue message for quickfix thread. ThreadedSocketConnection::send : ThreadedSocketConnection.cpp:70 write to socket in user thread thanks Neeraj |
From: Viktor P. <pohrebnyak@i.ua> - 2013-08-16 18:52:00
|
Hi, aupadras. I've checked your output but it contains nothing suspicious. Are you sure you do not create an excessive amount of SocketInitiators in your main loop? Each SocketInitiator creates a DataDictionary instances which consume a lot of memory so if used without caution they can waste lots of RAM. Regards, Viktor -- View this message in context: http://quickfix.13857.n7.nabble.com/Memory-Allocation-tp6541p6548.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: Viktor P. <pohrebnyak@i.ua> - 2013-08-15 16:06:25
|
Hi, aupadras. I can see that your application has crashed in Message class constructor. Thing is that std::bad_alloc() exception was thrown before Message::setString() method got invoked which means that message hasn't even started parsing the FIX string. I can only suggest you to run a memory leak detector to see what the problem is. Regards, Viktor -- View this message in context: http://quickfix.13857.n7.nabble.com/Memory-Allocation-tp6541p6546.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: Viktor P. <pohrebnyak@i.ua> - 2013-08-14 05:40:34
|
Hi, aupadras. So you are running a clean '1.13.3' release version from here <http://sourceforge.net/projects/quickfix/files/latest/download> ? If so then I suggest you to run a memory leak detector ( IBM Purify, Intel Inspector XE etc ) to see what's leaking memory in your app. We run the same clean '1.13.3' release ( Windows XP 32bit, VS2005 ) in Production with pretty heavy incoming market data traffic ( 2000+ MarketDataIncrementalRefresh msgs/sec ) and we have no issues with memory leaks. Regards, Viktor -- View this message in context: http://quickfix.13857.n7.nabble.com/Memory-Allocation-tp6541p6544.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: Viktor P. <pohrebnyak@i.ua> - 2013-08-13 20:13:00
|
Hi, aupadras. What quickfix revision do you use? Do you use a MemoryStoreFactory or a FileStoreFactory for message persistance? If you use a MemoryStoreFactory then the answer to your question you might find here: Memory Being Consumed <http://quickfix.13857.n7.nabble.com/Memory-Being-Consumed-td6507.html> Regards, Viktor -- View this message in context: http://quickfix.13857.n7.nabble.com/Memory-Allocation-tp6541p6542.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: Viktor P. <pohrebnyak@i.ua> - 2013-08-09 19:10:48
|
Hi, ukarick. It looks like "FileLogBackupPath" parameter has no effect. You have to explicitly provide a backup path in FileStoreFactory object constructor. Also, I can't find a place in the code where log backup is actually called - SessionState::backup() method is never invoked. This might explain troubles you have with log file backup. P.S. There are test cases that verify that FileLog::backup() method actually works though. But in reality it is never invoked by framework. Regards, Viktor -- View this message in context: http://quickfix.13857.n7.nabble.com/FileLogBackupPath-does-not-backup-the-log-file-tp6539p6540.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: olamide o. <kra...@gm...> - 2013-08-01 08:55:35
|
Hi all, I get and occassional ACCESS_VIOLATION Exception while cleaning up the threaded socket initiator in my application. I digged in the source and found the destructor only calls WSACleanup(). I'll like to know if any one else experiences this and any possible suggestions to solve the issue. Thanks. Ola |
From: Viktor P. <pohrebnyak@i.ua> - 2013-07-25 18:10:24
|
Would like to thank Oren for accepting my patch to the trunk. In case someone will experience any issues - let me know. -- View this message in context: http://quickfix.13857.n7.nabble.com/Unresolved-stability-issue-in-rev-2300-tp6495p6536.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: <or...@qu...> - 2013-07-24 17:37:20
|
As promised, the QuickFIX repository has been moved over to github. The subversion repository on sourceforge is now locked and will no longer receive updates. The new repository is located at https://github.com/quickfix/quickfix Among other things, this should make code submissions much easier. |
From: Daniel M. <dmo...@ya...> - 2013-06-28 16:35:45
|
This process runs without issue at startup. It seems if I keep restarting the connections, it cores. The gdb shows the following. Can someone help me decide what is this? Thanks in advance gdb) where #0 0x00439028 in std::ostream::sentry::sentry () from /usr/lib/libstdc++.so.6 #1 0x00439176 in std::operator<< <std::char_traits<char> > () from /usr/lib/libstdc++.so.6 #2 0x400d98f1 in FIX::socket_accept (s=29) at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/ostream:193 #3 0x40081823 in FIX::ThreadedSocketAcceptor::socketAcceptorThread (p=0xae8f018) at Acceptor.h:87 #4 0x008983cc in start_thread () from /lib/tls/libpthread.so.0 #5 0x007831ae in clone () from /lib/tls/libc.so.6 (gdb) -- View this message in context: http://quickfix.13857.n7.nabble.com/quickfix-1-13-3-src-C-Core-ThreadedSocketAcceptor-socketAcceptorThread-tp6510.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: Viktor P. <pohrebnyak@i.ua> - 2013-06-28 08:46:31
|
hi, Michael. If you use MemoryStore ( PersistMessages=N ) then you code suffers from missing MessageStore truncate functionality. This issue is not so visible when you use FileStore since quickfix stored just file offsets in memory. But MemoryStore keeps ALL outgoing messages in memory which eats a lot of RAM when your outgoing message rate is high. So to solve your troubles you might want to inherit from MemoryStore class and add truncate functionality into MessageStore::set() method e.g. keep in memory just N last sent messages. Hope this helps, Viktor -- View this message in context: http://quickfix.13857.n7.nabble.com/Memory-Being-Consumed-tp6507p6509.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: James D. <jc...@co...> - 2013-06-21 21:14:21
|
Oren, Thanks for putting forth the plan. I too will not make an argument for or against a fork of the project. After all it is an open source project. Connamara is ready to help. We currently host the builders, Jenkins and are willing to continue doing so. We would also welcome another administrator. We can take the lead on making the move to GitHub and a new release. Jim On Fri, Jun 21, 2013 at 9:22 AM, <or...@qu...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi Brian, > > Thank you for your comment, and I would first like to point out you are > 100% correct that the level of participation from myself lately has been > unacceptable. I don't want to go into to much detail about why I > haven't been able to commit the time, but would like to propose an > action plan that will put QuickFIX in a better situation as either a > going concern or a forked project. I'm not going to put forward an > argument for or against a fork as a fork is beyond my control, so I will > only propose what I can control. > > First though I would like to point out that I make exactly $0 from > QuickFIX. I do not work for Connamara. They have been a valuable > partner, but ultimately management of the project lies with me and it is > my fault not theirs that the project has remained inactive. > > So what do I propose? Here is a mini plan that I would like to see > enacted going forward. > > 1) Wrap up the release ready to go in source control. There are many > fixes that are just sort of sitting in the repository that haven't made > it into a formal release. So let's get that out there first. > > 2) Complete move to github. Frankly svn and SourceForge are a huge pain > working with patches submitted to the bug tracker. It will be wayyyyyy > easier to accept patches if we are working through git. The added > advantage is that it will become trivial to for QuickFIX once on github. > > 3) Close out open bugs in the bug tracker. > > 4) Recruit an additional admin or 2 to help with the project. I'm sure > Connamara would be willing to help with this, another community member > that uses QuickFIX daily would be a welcome addition. > > 5) Move to a regular release cycle. The release cycle currently is at > my whim. As you can tell that's not a very motivating deadline to hit. > I'm thinking of moving to something like regular 6 month release cycles. > > 6) remove .NET support from standard QuickFIX. We killed the JNI api a > while ago as QuickFIX/J matured, and now QuickFIX/n is mature enough as > well. I spent probably 50% of project time maintaining these two APIs > and that is demoralizing. Chopping the project down to just bare C++ > and letting the satellite projects do their thing should improve > productivity. > > So that's all I have for now. Comments? > > > -------- Original Message -------- > > Subject: Re: [Quickfix-developers] Unresolved stability issue in rev > > 2300 > > From: Brian Erst <azz...@ya...> > > Date: Mon, June 17, 2013 10:14 am > > To: Lolrim <pohrebnyak@i.ua>, > > "qui...@li..." > > <qui...@li...> > > > > > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX Support: http://www.quickfixengine.org/services.html<hr>As > much as I hate to say it (as QF has been very good), the only time you get > traction on fixes/releases is when someone threatens to fork the project. > > > > > > This project lay pretty fallow from 2006-2009, stuck on 1.12.4 (which > didn't even support FIX 5.0, released in 2006) until, in March of 2009, > developers got so frustrated that a fork was discussed pretty seriously. > Suddenly, there was renewed interest by Oren/Connamara, but QuickFix 1.13.0 > still took an entire year (Feb 26, 2010) to be released. A couple of quick > bug fix releases over the next few months and then... nothing again for > three years. > > > > Connamara is a busy consulting firm and has long since moved on from any > sort of active management/development of QuickFIX. Oren hasn't even > participated in the forum since January of 2011. I don't blame them - they > have lots of paying customers for their projects and are quite busy. Their > bread and butter comes from .Net development - look at the change log of > QuickFIX/n (https://github.com/connamara/quickfixn/commits/master) and > see the frequent, active development of that system (four pages of commits > this year alone). > > > > > > Management of traditional QuickFIX should be moved to a more active > developer community with thanks to Oren and Connamara for getting it to > where it is. > > > > - Brian Erst > > > > > > > > ________________________________ > > From: Lolrim <pohrebnyak@i.ua> > > To: qui...@li... > > Sent: Sunday, June 16, 2013 2:24 PM > > Subject: [Quickfix-developers] Unresolved stability issue in rev 2300 > > > > > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX Support: http://www.quickfixengine.org/services.html > > > > Hi, team. > > > > There is an unresolved stability issue caused by rev [2300] which > contained > > my code changes. > > > > I’ve uploaded a patch more than a year ago: > > https://sourceforge.net/p/quickfix/patches/23/ but unfortunately it is > not > > reviewed yet. Could some of you take a look, please? There are a lot of > > complaints about stability on forum and I would like to resolve the > issue. > > > > Best regards, > > Viktor Pogrebnyak > > > > > > > > > > -- > > View this message in context: > http://quickfix.13857.n7.nabble.com/Unresolved-stability-issue-in-rev-2300-tp6495.html > > Sent from the QuickFIX - Dev mailing list archive at Nabble.com. > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > <hr>------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > <hr>_______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > -- *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less.* * http://www.connamara.com <http://connamara.com/> |
From: Viktor P. <pohrebnyak@i.ua> - 2013-06-21 15:37:30
|
Hi, Oren. Your idea to drop support for .NET and more to GitHub sounds great. Until you find more admins/devs to support project it would be nice if someone could review patches twice a month to avoid pressure. There are a few patches being submitted anyway, mostly bug reports. If one of the devs will have any questions/suggestions about my fix(es) - I'll be glad to discuss them and remove any problems as soon as I can. Best regards, Viktor -- View this message in context: http://quickfix.13857.n7.nabble.com/Unresolved-stability-issue-in-rev-2300-tp6495p6502.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: <or...@qu...> - 2013-06-21 14:39:05
|
Hi Brian, Thank you for your comment, and I would first like to point out you are 100% correct that the level of participation from myself lately has been unacceptable. I don't want to go into to much detail about why I haven't been able to commit the time, but would like to propose an action plan that will put QuickFIX in a better situation as either a going concern or a forked project. I'm not going to put forward an argument for or against a fork as a fork is beyond my control, so I will only propose what I can control. First though I would like to point out that I make exactly $0 from QuickFIX. I do not work for Connamara. They have been a valuable partner, but ultimately management of the project lies with me and it is my fault not theirs that the project has remained inactive. So what do I propose? Here is a mini plan that I would like to see enacted going forward. 1) Wrap up the release ready to go in source control. There are many fixes that are just sort of sitting in the repository that haven't made it into a formal release. So let's get that out there first. 2) Complete move to github. Frankly svn and SourceForge are a huge pain working with patches submitted to the bug tracker. It will be wayyyyyy easier to accept patches if we are working through git. The added advantage is that it will become trivial to for QuickFIX once on github. 3) Close out open bugs in the bug tracker. 4) Recruit an additional admin or 2 to help with the project. I'm sure Connamara would be willing to help with this, another community member that uses QuickFIX daily would be a welcome addition. 5) Move to a regular release cycle. The release cycle currently is at my whim. As you can tell that's not a very motivating deadline to hit. I'm thinking of moving to something like regular 6 month release cycles. 6) remove .NET support from standard QuickFIX. We killed the JNI api a while ago as QuickFIX/J matured, and now QuickFIX/n is mature enough as well. I spent probably 50% of project time maintaining these two APIs and that is demoralizing. Chopping the project down to just bare C++ and letting the satellite projects do their thing should improve productivity. So that's all I have for now. Comments? > -------- Original Message -------- > Subject: Re: [Quickfix-developers] Unresolved stability issue in rev > 2300 > From: Brian Erst <azz...@ya...> > Date: Mon, June 17, 2013 10:14 am > To: Lolrim <pohrebnyak@i.ua>, > "qui...@li..." > <qui...@li...> > > > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html<hr>As much as I hate to say it (as QF has been very good), the only time you get traction on fixes/releases is when someone threatens to fork the project. > > > This project lay pretty fallow from 2006-2009, stuck on 1.12.4 (which didn't even support FIX 5.0, released in 2006) until, in March of 2009, developers got so frustrated that a fork was discussed pretty seriously. Suddenly, there was renewed interest by Oren/Connamara, but QuickFix 1.13.0 still took an entire year (Feb 26, 2010) to be released. A couple of quick bug fix releases over the next few months and then... nothing again for three years. > > Connamara is a busy consulting firm and has long since moved on from any sort of active management/development of QuickFIX. Oren hasn't even participated in the forum since January of 2011. I don't blame them - they have lots of paying customers for their projects and are quite busy. Their bread and butter comes from .Net development - look at the change log of QuickFIX/n (https://github.com/connamara/quickfixn/commits/master) and see the frequent, active development of that system (four pages of commits this year alone). > > > Management of traditional QuickFIX should be moved to a more active developer community with thanks to Oren and Connamara for getting it to where it is. > > - Brian Erst > > > > ________________________________ > From: Lolrim <pohrebnyak@i.ua> > To: qui...@li... > Sent: Sunday, June 16, 2013 2:24 PM > Subject: [Quickfix-developers] Unresolved stability issue in rev 2300 > > > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, team. > > There is an unresolved stability issue caused by rev [2300] which contained > my code changes. > > I’ve uploaded a patch more than a year ago: > https://sourceforge.net/p/quickfix/patches/23/ but unfortunately it is not > reviewed yet. Could some of you take a look, please? There are a lot of > complaints about stability on forum and I would like to resolve the issue. > > Best regards, > Viktor Pogrebnyak > > > > > -- > View this message in context: http://quickfix.13857.n7.nabble.com/Unresolved-stability-issue-in-rev-2300-tp6495.html > Sent from the QuickFIX - Dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers<hr>------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev<hr>_______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
From: Brian E. <azz...@ya...> - 2013-06-17 17:26:08
|
Grant - I should have put "It seems that" in front of "Their bread and butter", as I don't know the internal sales of Connamara. Having an interested developer who just finds a project fun is another valid reason for lots of commits! :D Thanks for the QuickFix/n work. I do think that QuickFIX/C++ should be moved to a different project structure. What that may be is up to Connamara and the QF/C++ developer community. - Brian ________________________________ From: Grant Birchmeier <gbi...@co...> As the guy in charge of QF/n, I need to point out that your comment about .NET being Connamara's "bread and butter" is incorrect. We use a wide variety of technologies, including .NET, but also Ruby/Rails, Erlang, C++, and more. (I'm personally knee-deep in Rails right now.) The increased attention to QF/n is simply because I personally enjoy it, and I try to find time for it. We actually don't have that many projects that use QF/n (though it'd be nice if we could get more). I'll leave the formal QF/C++ response to one of my colleagues, but you are right, it is obvious that this project has been lacking attention. -Grant On Mon, Jun 17, 2013 at 10:14 AM, Brian Erst <azz...@ya...> wrote: QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html >QuickFIX Support: http://www.quickfixengine.org/services.html > > > >As much as I hate to say it (as QF has been very good), the only time you get traction on fixes/releases is when someone threatens to fork the project. > > > >This project lay pretty fallow from 2006-2009, stuck on 1.12.4 (which didn't even support FIX 5.0, released in 2006) until, in March of 2009, developers got so frustrated that a fork was discussed pretty seriously. Suddenly, there was renewed interest by Oren/Connamara, but QuickFix 1.13.0 still took an entire year (Feb 26, 2010) to be released. A couple of quick bug fix releases over the next few months and then... nothing again for three years. > > >Connamara is a busy consulting firm and has long since moved on from any sort of active management/development of QuickFIX. Oren hasn't even participated in the forum since January of 2011. I don't blame them - they have lots of paying customers for their projects and are quite busy. Their bread and butter comes from .Net development - look at the change log of QuickFIX/n (https://github.com/connamara/quickfixn/commits/master) and see the frequent, active development of that system (four pages of commits this year alone). > > > >Management of traditional QuickFIX should be moved to a more active developer community with thanks to Oren and Connamara for getting it to where it is. > > >- Brian Erst > > > > >________________________________ > From: Lolrim <pohrebnyak@i.ua> >To: qui...@li... >Sent: Sunday, June 16, 2013 2:24 PM >Subject: [Quickfix-developers] Unresolved stability issue in rev 2300 > > >QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html >QuickFIX Support: http://www.quickfixengine.org/services.html > >Hi, team. > >There is an unresolved stability issue caused by rev [2300] which contained >my code changes. > >I’ve uploaded a patch more than a year ago: >https://sourceforge.net/p/quickfix/patches/23/ but unfortunately it is not >reviewed yet. Could some of you take a look, please? There are a lot of >complaints about stability on forum and I would like to resolve the issue. > >Best regards, >Viktor Pogrebnyak > > > > >-- >View this message in context: http://quickfix.13857.n7.nabble.com/Unresolved-stability-issue-in-rev-2300-tp6495.html >Sent from the QuickFIX - Dev mailing list archive at Nabble.com. > >------------------------------------------------------------------------------ >This SF.net email is sponsored by Windows: > >Build for Windows Store. > >http://p.sf.net/sfu/windows-dev2dev >_______________________________________________ >Quickfix-developers mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > >------------------------------------------------------------------------------ >This SF.net email is sponsored by Windows: > >Build for Windows Store. > >http://p.sf.net/sfu/windows-dev2dev >_______________________________________________ >Quickfix-developers mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfix-developers > -- Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com |
From: K. F. <kfr...@gm...> - 2013-06-17 16:12:05
|
Hello Brian - Thank you for this information. I have a question and some comments, below. On Mon, Jun 17, 2013 at 11:14 AM, Brian Erst <azz...@ya...> wrote: > > As much as I hate to say it (as QF has been very good), the only time you get traction on fixes/releases is when someone threatens to fork the project. Please let me also express my thanks for QuickFix. It is good and useful. Although not as good as the very best open-source projects, it is much better than the vast majority of them. > This project lay pretty fallow from 2006-2009, stuck on 1.12.4 (which didn't even support FIX 5.0, released in 2006) until, in March of 2009, developers got so frustrated that a fork was discussed pretty seriously. Suddenly, there was renewed interest by Oren/Connamara, but QuickFix 1.13.0 still took an entire year (Feb 26, 2010) to be released. A couple of quick bug fix releases over the next few months and then... nothing again for three years. > > Connamara is a busy consulting firm and has long since moved on from any sort of active management/development of QuickFIX. Oren hasn't even participated in the forum since January of 2011. I don't blame them - they have lots of paying customers for their projects and are quite busy. Their bread and butter comes from .Net development - look at the change log of QuickFIX/n (https://github.com/connamara/quickfixn/commits/master) and see the frequent, active development of that system (four pages of commits this year alone). > > Management of traditional QuickFIX should be moved to a more active developer community with thanks to Oren and Connamara for getting it to where it is. My question is whether the problem is that Connamara hasn't been doing the core work (i.e., fixing the bugs and writing the code for new features), or whether they haven't been managing the open-source project in a way that it is practical for others in the community to do the work (i.e., submit patches). If the QuickFix project is being managed in a way that it is practical and reasonably convenient for, for example, me to submit a patch, and if the patch is legitimate, have it reviewed, upstreamed, and released in a timely manner, then I would see no need to fork and/or move to a different community. As long as Connamara is managing the project effectively (as distinct from doing the work), and if Connamara feels (their decision, of course) that they don't have the resources to fix a bug or implement a new feature, I don't see why forking or moving the project would cause those missing resources to suddenly appear. (Now if Connamara were impeding progress, either though inattention or by rejecting legitimate patches, then that would be a good reason to fork the project or change its governance. I do see that Viktor was asking after a patch of his that hadn't been reviewed in over a year. Is Connamara the only entity that can review / accept / merge patches? If so, perhaps that's a problem, and the governance should be tweaked.) If you want or need something in an open-source project, you generally: hope someone else does it; do it yourself; pay somebody to do it; or do without. For example, I wanted to be able to use QuickFix on windows, but have it built with a windows port of gcc (mingw-w64), rather than with msvc. QuickFix wouldn't build with mingw-w64 out of the box, so I "ported" it from msvc to mingw-w64. When I had questions about bits of code I wasn't sure about I got the support I needed on this list, primarily from Connamara. (I had the sense that I was all alone out here in left field trying to use mingw-w64 -- my sense is that everybody using QuickFix on windows wants to use msvc -- so I did not do the additional work that would have been needed to turn my port into a clean patch and try to get it merged into the official QuickFix release.) > - Brian Erst Happy QuickFix Hacking! K. Frank |
From: Grant B. <gbi...@co...> - 2013-06-17 16:07:15
|
As the guy in charge of QF/n, I need to point out that your comment about .NET being Connamara's "bread and butter" is incorrect. We use a wide variety of technologies, including .NET, but also Ruby/Rails, Erlang, C++, and more. (I'm personally knee-deep in Rails right now.) The increased attention to QF/n is simply because I personally enjoy it, and I try to find time for it. We actually don't have that many projects that use QF/n (though it'd be nice if we could get more). I'll leave the formal QF/C++ response to one of my colleagues, but you are right, it is obvious that this project has been lacking attention. -Grant On Mon, Jun 17, 2013 at 10:14 AM, Brian Erst <azz...@ya...>wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > As much as I hate to say it (as QF has been very good), the only time you > get traction on fixes/releases is when someone threatens to fork the > project. > > This project lay pretty fallow from 2006-2009, stuck on 1.12.4 (which > didn't even support FIX 5.0, released in 2006) until, in March of 2009, > developers got so frustrated that a fork was discussed pretty seriously. > Suddenly, there was renewed interest by Oren/Connamara, but QuickFix 1.13.0 > still took an entire year (Feb 26, 2010) to be released. A couple of quick > bug fix releases over the next few months and then... nothing again for > three years. > > Connamara is a busy consulting firm and has long since moved on from any > sort of active management/development of QuickFIX. Oren hasn't even > participated in the forum since January of 2011. I don't blame them - they > have lots of paying customers for their projects and are quite busy. Their > bread and butter comes from .Net development - look at the change log of > QuickFIX/n (https://github.com/connamara/quickfixn/commits/master) and > see the frequent, active development of that system (four pages of commits > this year alone). > > Management of traditional QuickFIX should be moved to a more active > developer community with thanks to Oren and Connamara for getting it to > where it is. > > - Brian Erst > > ------------------------------ > *From:* Lolrim <pohrebnyak@i.ua> > *To:* qui...@li... > *Sent:* Sunday, June 16, 2013 2:24 PM > *Subject:* [Quickfix-developers] Unresolved stability issue in rev 2300 > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, team. > > There is an unresolved stability issue caused by rev [2300] which contained > my code changes. > > I’ve uploaded a patch more than a year ago: > https://sourceforge.net/p/quickfix/patches/23/ but unfortunately it is not > reviewed yet. Could some of you take a look, please? There are a lot of > complaints about stability on forum and I would like to resolve the issue. > > Best regards, > Viktor Pogrebnyak > > > > > -- > View this message in context: > http://quickfix.13857.n7.nabble.com/Unresolved-stability-issue-in-rev-2300-tp6495.html > Sent from the QuickFIX - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less.* * http://connamara.com |
From: Brian E. <azz...@ya...> - 2013-06-17 15:14:21
|
As much as I hate to say it (as QF has been very good), the only time you get traction on fixes/releases is when someone threatens to fork the project. This project lay pretty fallow from 2006-2009, stuck on 1.12.4 (which didn't even support FIX 5.0, released in 2006) until, in March of 2009, developers got so frustrated that a fork was discussed pretty seriously. Suddenly, there was renewed interest by Oren/Connamara, but QuickFix 1.13.0 still took an entire year (Feb 26, 2010) to be released. A couple of quick bug fix releases over the next few months and then... nothing again for three years. Connamara is a busy consulting firm and has long since moved on from any sort of active management/development of QuickFIX. Oren hasn't even participated in the forum since January of 2011. I don't blame them - they have lots of paying customers for their projects and are quite busy. Their bread and butter comes from .Net development - look at the change log of QuickFIX/n (https://github.com/connamara/quickfixn/commits/master) and see the frequent, active development of that system (four pages of commits this year alone). Management of traditional QuickFIX should be moved to a more active developer community with thanks to Oren and Connamara for getting it to where it is. - Brian Erst ________________________________ From: Lolrim <pohrebnyak@i.ua> To: qui...@li... Sent: Sunday, June 16, 2013 2:24 PM Subject: [Quickfix-developers] Unresolved stability issue in rev 2300 QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html Hi, team. There is an unresolved stability issue caused by rev [2300] which contained my code changes. I’ve uploaded a patch more than a year ago: https://sourceforge.net/p/quickfix/patches/23/ but unfortunately it is not reviewed yet. Could some of you take a look, please? There are a lot of complaints about stability on forum and I would like to resolve the issue. Best regards, Viktor Pogrebnyak -- View this message in context: http://quickfix.13857.n7.nabble.com/Unresolved-stability-issue-in-rev-2300-tp6495.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
From: Lolrim <pohrebnyak@i.ua> - 2013-06-16 19:40:50
|
Hi, team. There is an unresolved stability issue caused by rev [2300] which contained my code changes. I’ve uploaded a patch more than a year ago: https://sourceforge.net/p/quickfix/patches/23/ but unfortunately it is not reviewed yet. Could some of you take a look, please? There are a lot of complaints about stability on forum and I would like to resolve the issue. Best regards, Viktor Pogrebnyak -- View this message in context: http://quickfix.13857.n7.nabble.com/Unresolved-stability-issue-in-rev-2300-tp6495.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: Gunnar H. <gh...@hi...> - 2013-06-13 11:48:28
|
Hello, We have an acceptor type application and sometimes we wish to logout and disconnect a client of our app. What is the best way to do this? Now we have the code that is below and it seems to work. But our code does not call methods on the Session's m_state member as does Session itself when sending logout messages (I would like to do the same but m_state and also methods like genrateLogout() from Session class are private). Could our implementation lead to issues eg. when client reconnects later etc.? Logout and disconnect a client: if (MFIXSession != NULL) { if (MFIXSession->receivedLogon()) { FIX42::Logout message; message.set(text); FIX::Session::sendToTarget(message, MFIXSessionID); } MFIXSession->disconnect(); return true; } else { ... } Thanks, Gunnar Harms HiQ Invest Herengracht 442 1017 BZ Amsterdam |
From: Mike G. <mg...@co...> - 2013-06-11 13:44:24
|
On Jun 11, 2013 8:26 AM, "Daniel Mounessa" <dmo...@ya...> wrote: > 1. Do we know home many site are in Production with this version? Hard to say, but Quickfix/c++ has been downloaded over a quarter of a million times. > 2. What is the process of bug fixes? Submit a report/patch to the developer mailing list. > Who would fix any bugs that are found > and how long does it take to get a new release? > 3. How do we go about adding new features to quickfix-1.13.3/src/C++? Anyone can submit a patch. One of the devs will review/merge it. This is an open source project, so timing depends on when a dev can get to it -- to expedite your bug fix or feature request, you can pay for support. > 4. Are there companies who release quickfix-/C++ officially and maintain it? Connamara Systems helps maintain the project and offers paid support. There are others as well. -- Mike Gatny Connamara Systems, LLC |
From: Daniel M. <dmo...@ya...> - 2013-06-11 13:22:53
|
I have started using quickfix-1.13.3/src/C++ library. My questions are as follows: 1. Do we know how many sites are in Production with this version? 2. What is the process of bug fixes? Who would fix any bugs that are found and how long does it take to get a new release? 3. How do we go about adding new features to quickfix-1.13.3/src/C++? 4. Are there companies who release quickfix-/C++ officially and maintain it? Thanks for your response. -- View this message in context: http://quickfix.13857.n7.nabble.com/quickfix-1-13-3-src-C-Upgrade-Maintenance-etc-tp6489p6490.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: Daniel M. <dmo...@ya...> - 2013-06-11 13:20:42
|
I have started using quickfix-1.13.3/src/C++ library. My questions are as follows: 1. Do we know home many site are in Production with this version? 2. What is the process of bug fixes? Who would fix any bugs that are found and how long does it take to get a new release? 3. How do we go about adding new features to quickfix-1.13.3/src/C++? 4. Are there companies who release quickfix-/C++ officially and maintain it? Thanks for your response. -- View this message in context: http://quickfix.13857.n7.nabble.com/quickfix-1-13-3-src-C-Upgrade-Maintenance-etc-tp6489.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
From: Gunnar H. <gh...@hi...> - 2013-06-10 11:18:11
|
Hi Mike, I agree. And thanks for the Message::identifyType() hint. Regards, Gunnar Gunnar Harms HiQ Invest Herengracht 442 1017 BZ Amsterdam On May 30, 2013, at 7:27 PM, Mike Gatny wrote: > On Thu, May 30, 2013 at 2:52 AM, Gunnar Harms <gh...@hi...> wrote: > Deriving from the FileLogFactory and from FileLog to create my own derived FileLog is probably easy but in the onOutgoing method of the Log object the message type is not available > > I've run into this before myself and I agree that it might be nice to have access to something other than the raw string in the Log interface. However, it is also desirable to log the message immediately (and therefore raw) so that we have a record of it in case an error occurs when we try to process it. Maybe the answer is to augment the Log interface to have onIncoming/onOutgoing and additionally onIncomingRaw/onOutgoingRaw callbacks. Then you could implement whatever makes sense for your app. > > In the meantime, however: see Message::identifyType() in Message.h, which takes a raw string and returns the MsgType. > > -- > Mike Gatny > Connamara Systems, LLC |
From: Daniel M. <dmo...@ya...> - 2013-06-06 19:54:55
|
Problem was with LD_LIBRARY Path -- the code worked without any issue with my own local built copy except in this case, it was not able to find the method -- When I changed to a newer built version it seems okay. -- View this message in context: http://quickfix.13857.n7.nabble.com/symbol-lookup-error-quickfix-1-13-3-src-C-libs-libquickfix-so-14-undefined-symbol-Z10-tp6483p6485.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |