quickfix-developers Mailing List for QuickFIX (Page 147)
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
|
| 2026 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mike G. <qui...@go...> - 2006-06-03 06:59:34
|
<html> <body> <font size=3>Hi developers,<br><br> I downloaded and installed the quickfix source for the first time ever a few days ago on a PC running Windows XP. I am trying to make sure the example apps in the /bin directory run properly. I can get ./run_ordermatch.bat and ./run_tradeclient.bat to run with no problem. But when I try to run the ./run_executor_java.bat, I get exactly the same error message as above:<br><br> <blockquote type=cite class=cite cite="">Exception in thread "main" java.lang.UnsatisfiedLinkError: create<br> at quickfix.SessionSettings.create(Native Method)<br> at quickfix.SessionSettings.<init>(Unknown Source)<br> at Executor.main(Executor.java:40)</blockquote><br> I have jdk1.5.0_07 installed, but my java knowledge is virtually nil. The PC version doesn't have a quickfix.jar file in an Extensions directory to remove, so I don't know how to fix this. Any suggestions of what to try next?<br><br> Thanks,<br> Mike Gossland<br><br> PS Sorry if this a duplicate email.<br><br> <br> At 03:43 PM 6/2/2006, Brendan Boerner wrote:<br><br> <br> <blockquote type=cite class=cite cite="">QuickFIX Documentation: <a href="http://www.quickfixengine.org/quickfix/doc/html/index.html" eudora="autourl"> http://www.quickfixengine.org/quickfix/doc/html/index.html</a><br> QuickFIX Support: <a href="http://www.quickfixengine.org/services.html" eudora="autourl"> http://www.quickfixengine.org/services.html</a><br><br> Hi,<br><br> While I've used QF off and on for about ~3.5 years it was not until<br> this Spring that I used it on a MacBook.<br><br> On the MacBook (and presumably the PPC versions as well) quickfix.jar<br> is installed to /Library/Java/Extensions.<br><br> I don't have a PPC to test this but this apparently is a problem on<br> the Intel machine:<br><br> $ cd quickfix/bin<br> $ ./run_executor_java<br> Exception in thread "main" java.lang.UnsatisfiedLinkError: create<br> at quickfix.SessionSettings.create(Native Method)<br> at quickfix.SessionSettings.<init>(Unknown Source)<br> at Executor.main(Executor.java:40)<br><br> # removing quickfix.jar from /Library/Java/Extensions is needed<br> $ rm /Library/Java/Extensions/quickfix.jar<br> $ ./run_executor_java<br> press <enter> to quit<br><br> I thought I'd mention this in case others run into the same problem.</blockquote><br><br> <br> </font></body> </html> |
|
From: Oren M. <or...@qu...> - 2006-06-02 22:37:38
|
I just noticed this the other day with the MacBooks. It had been working fine on the PowerBooks, but I haven't checked in a while. --oren On Jun 2, 2006, at 2:43 PM, Brendan Boerner wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ > html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, > > While I've used QF off and on for about ~3.5 years it was not until > this Spring that I used it on a MacBook. > > On the MacBook (and presumably the PPC versions as well) quickfix.jar > is installed to /Library/Java/Extensions. > > I don't have a PPC to test this but this apparently is a problem on > the Intel machine: > > $ cd quickfix/bin > $ ./run_executor_java > Exception in thread "main" java.lang.UnsatisfiedLinkError: create > at quickfix.SessionSettings.create(Native Method) > at quickfix.SessionSettings.<init>(Unknown Source) > at Executor.main(Executor.java:40) > > # removing quickfix.jar from /Library/Java/Extensions is needed > $ rm /Library/Java/Extensions/quickfix.jar > $ ./run_executor_java > press <enter> to quit > > I thought I'd mention this in case others run into the same problem. > > Regards, > Brendan > > > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Oren M. <or...@qu...> - 2006-06-02 22:33:56
|
Well, according to that article, there is a -stack-size parameter that can be passed to the linker. So adding it to your LDFLAGS before running configure should do the trick. Are you really reaching the default limit? --oren On Jun 2, 2006, at 4:52 PM, John Muehlhausen wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ > html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > Given that the QuickFIX queue mechanism is based on recursion, > plenty of stack space is needed for large queues. > > I would appreciate a way to tune the pthreads stack space on OS X > without needing to hack each new version of the library. There > appears to be no way to tune the default pthreads stack space from > the OS. > > http://developer.apple.com/qa/qa2005/qa1419.html > > Could this be either a build time or runtime option in a future > version of QuickFIX? Is the recursion still slated for elimination? > > Thanks, > John > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Oren M. <or...@qu...> - 2006-06-02 22:27:56
|
BTW, I had looked into getting rid of it, but we can't do it just yet due to the python API. Python requires a accessing global lock before calling to the virtual machine, otherwise the whole thing blows up. SWIG does not take care of this automatically, so it will require some lower level work like we needed to do for handling exceptions. In the meantime the only way to use the Python API is with the SocketInitiator in block mode, as that will run the whole engine entirely in one thread. And to those who asked previously, a Ruby API is in the works and coming along fairly well. I think exception handling, repeating groups support, and some issues with callbacks are left. Once we get these basics out we will put it out for release and then work on making the API more ruby like. We are not currently working on a Perl API and can't say if or when we will do such a thing. --oren On Jun 2, 2006, at 5:10 PM, Oren Miller wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ > html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Did you go to subversion or are you still using cvs? > > --oren > > On Jun 2, 2006, at 4:50 PM, Francis Gingras wrote: > >> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ >> html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> I downloaded the latest sources from SVN and there is no >> QuickFix.ThreadedSocketInitiator anymore, only a SocketInitiator. >> >> Does this mean it's not threaded by default? >> Or do I now have to use the non-threaded version? >> >> Thanks, >> >> Francis >> >> >> >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> > > > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Oren M. <or...@qu...> - 2006-06-02 22:20:48
|
Argh. You do pay a price for coding too late into the night. Interestingly enough this did not crash under windows. --oren On Jun 2, 2006, at 4:36 PM, Caleb Epstein wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ > html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > The Exception class constructor has a nasty bug. Can you spot it? > > /// Base QuickFIX exception type. > struct Exception : public std::logic_error > { > Exception( const std::string& t, const std::string& d ) > : std::logic_error( detail.size() ? t + ": " + d : t ), > type( t ), detail( d ) > {} > > std::string type; > std::string detail; > }; > > > > > > > > > > > > > > > > SPOILER: > > The ternary operator is using the "detail" class member, but it hasn't > been constructed yet! Boom! > > -- > Caleb Epstein > > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Oren M. <or...@qu...> - 2006-06-02 22:11:18
|
Did you go to subversion or are you still using cvs? --oren On Jun 2, 2006, at 4:50 PM, Francis Gingras wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ > html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > I downloaded the latest sources from SVN and there is no > QuickFix.ThreadedSocketInitiator anymore, only a SocketInitiator. > > Does this mean it's not threaded by default? > Or do I now have to use the non-threaded version? > > Thanks, > > Francis > > > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: John M. <jg...@ra...> - 2006-06-02 21:55:28
|
Given that the QuickFIX queue mechanism is based on recursion, plenty of = stack space is needed for large queues. I would appreciate a way to tune the pthreads stack space on OS X = without needing to hack each new version of the library. There appears = to be no way to tune the default pthreads stack space from the OS. http://developer.apple.com/qa/qa2005/qa1419.html Could this be either a build time or runtime option in a future version = of QuickFIX? Is the recursion still slated for elimination? Thanks, John |
|
From: Francis G. <fr...@at...> - 2006-06-02 21:50:41
|
I downloaded the latest sources from SVN and there is no QuickFix.ThreadedSocketInitiator anymore, only a SocketInitiator. Does this mean it's not threaded by default? Or do I now have to use the non-threaded version? Thanks, Francis |
|
From: Ajay K. <Aja...@tr...> - 2006-06-02 21:45:22
|
I suppose you are referring to the bug that the Exception ctor is calling detail.size() before detail itself is constructed. -----Original Message----- From: Caleb Epstein [mailto:cal...@gm...]=20 Sent: Friday, June 02, 2006 5:37 PM To: quickfix-developers Subject: [Quickfix-developers] r1491: nasty bug in Exception class QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html The Exception class constructor has a nasty bug. Can you spot it? /// Base QuickFIX exception type. struct Exception : public std::logic_error { Exception( const std::string& t, const std::string& d ) : std::logic_error( detail.size() ? t + ": " + d : t ), type( t ), detail( d ) {} std::string type; std::string detail; }; SPOILER: The ternary operator is using the "detail" class member, but it hasn't been constructed yet! Boom! --=20 Caleb Epstein _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers -------------------------------------------------------------------------= -- The information in this email is confidential and may be legally = privileged. It is intended solely for the addressee. Access to this email by anyone = else is unauthorized. If you are not the intended recipient, any disclosure, = copying, distribution or any action taken or omitted to be taken in reliance on = it, is prohibited and may be unlawful. TradeWeb reserves the right to monitor and review the content of all = messages sent to or from this e-mail address. Messages sent to or from this e-mail = address may be stored on the TradeWeb e-mail system. |
|
From: Caleb E. <cal...@gm...> - 2006-06-02 21:36:38
|
The Exception class constructor has a nasty bug. Can you spot it?
/// Base QuickFIX exception type.
struct Exception : public std::logic_error
{
Exception( const std::string& t, const std::string& d )
: std::logic_error( detail.size() ? t + ": " + d : t ),
type( t ), detail( d )
{}
std::string type;
std::string detail;
};
SPOILER:
The ternary operator is using the "detail" class member, but it hasn't
been constructed yet! Boom!
--
Caleb Epstein
|
|
From: Brendan B. <br...@ka...> - 2006-06-02 19:43:36
|
Hi,
While I've used QF off and on for about ~3.5 years it was not until
this Spring that I used it on a MacBook.
On the MacBook (and presumably the PPC versions as well) quickfix.jar
is installed to /Library/Java/Extensions.
I don't have a PPC to test this but this apparently is a problem on
the Intel machine:
$ cd quickfix/bin
$ ./run_executor_java
Exception in thread "main" java.lang.UnsatisfiedLinkError: create
at quickfix.SessionSettings.create(Native Method)
at quickfix.SessionSettings.<init>(Unknown Source)
at Executor.main(Executor.java:40)
# removing quickfix.jar from /Library/Java/Extensions is needed
$ rm /Library/Java/Extensions/quickfix.jar
$ ./run_executor_java
press <enter> to quit
I thought I'd mention this in case others run into the same problem.
Regards,
Brendan
|
|
From: Ferran C. <fer...@vi...> - 2006-06-02 16:54:26
|
Hi, I was sending and receiving messages when a "SessionNotFound" exception was thrown when calling to "sendToTarget()". After that, the communication was reestablished but one message was missing because my application didn't handle this exception. Any want knows when the session can be destroyed during a communication? I tried to reproduce cutting the connection but it never happens again. Regards, -- Ferran Casarramona Dep. Broker Visual Chart Group |
|
From: Staffan U. <sta...@mu...> - 2006-06-02 15:57:50
|
Hello, We moved a FIX gateway server built on quickfixj into production a few days ago, and it quickly became quite clear that the java program leaked menory somehow, and so did the mysql server. Both servers grew to about 2GB each in a few hours. After that, we had to restart the processes because of performance problems. Anyway, I traced the problem to the JdbcStore class, which allocates a new statement for each call. The statement is never closed. Depending on the Jdbc driver, these statements might or might not be garbage collected, but in our case they were at least not. After patching the code everything seems to run really well and fast. Anyway, I'm a bit reluctant to post a patch since the one I made is so ugly... It seems that someone started work on caching prepared statements in the JdbcStore class (using the statementCache member), but since it is not finished, it results in the leak. The JdbcLog class does not have this problem. At first glance it seems very easy to make the cache work (the only missing statement is one that actually adds the statement to the cache). It seems to me that thread safety needs to be taken into account, which might not be trivial. Maybe that's why the cache mechanism was never finished? Btw, my current patch just adds a close() call to a number of places. Staffan |
|
From: Brendan B. <bbo...@rg...> - 2006-06-01 20:01:52
|
Oren,
Here is NullStore.tar.bz2 containing:
./src/.NET/NullMessageStore.cpp
./src/.NET/NullMessageStore.h
./src/C++/NullStore.cpp
./src/C++/NullStore.h
./src/java/quickfix_NullStore.cpp
./src/java/quickfix_NullStore.h
./src/java/quickfix_NullStoreFactory.cpp
./src/java/quickfix_NullStoreFactory.h
./src/java/src/quickfix/NullStore.java
./src/java/src/quickfix/NullStoreFactory.java
Regards,
Brendan
On Jun 1, 2006, at 2:41 PM, or...@qu... wrote:
> Thank you for the contribution. You can post it to the
> quickfix-developers mailing list.
On Thu, June 01, 2006 1:18 pm Brendan wrote:
> Thanks for the reply and direction. Based on your feedback I created
> a NullStore C++ class and Java & C# wrappers (haven't tested the C#
> wrapper).
>
> I apologize for the delay in reply - I thought I'd have this done
> 'real quick' and be able to provide my implementation along with it
> (for inclusion in QuickFIX).
>
> My company is ok with my making this source available - how
> can I contribute it? (It consists of 10 files).
> On Apr 11, 2006, @ 17:50 oren replied:
> >
> > Yeah, I've implemented this sort of thing for market data projects
> > (not sure where it is at the moment unfortunately). It would
probably
> > be useful to distribute such a thing with quickfix.
> >
> > If you don't care about overhead (either memory or disk writes),
then
> > you can use either of those stores if you use the ResetOnDisconnect
> > and ResetOnLogout settings. These will make sure your sequence
> > numbers get reset to 1 no matter what store you use. If you are
> > worried about the overhead, then what should work would be to
> > implement some sort of NullStore which implements the sequence/
> > creation time methods like the memory store. Then just make the
set
> > () method do nothing, and have the get() method always return an
empty
> > vector. Then using those two configuration settings you should get
> > the effect you are looking for.
>
> > On Apr 11, 2006, at 7:23 PM, Brendan Boerner wrote:
> >
> > > In our application using QuickFIX I'm creating a FIX 4.2
server which
> > > will send MarketDataSnapshotFullRefresh messages to a client.
> > >
> > > In this application we don't wish to store messages if the
client is
> > > disconnected - the client will simply receive current
> > > MarketDataSnapshotFullRefresh messages as become available
after it
> > > connects, restarting with MsgSeqNum=1.
> > >
> > > I didn't see anything in {File,Memory}MessageStore which would
> > > implement this. I wanted to check w/the list to see if I'll
need to
> > > implement my own implementation of MessageStoreFactory and
> > > MessageStore or have I overlooked something?
|
|
From: Oren M. <or...@qu...> - 2006-06-01 15:19:55
|
FYI, it's probably worth mentioning that Subversion works a bit =20 differently with it's checkouts. The checkout command provided by =20 sourceforge: svn co https://svn.sourceforge.net/svnroot/quickfixj =20 quickfixj, is probably not what you want. This will essentially =20 check out not just the development version, but *every* branch in the =20= source code tree as well. For this reason most people will probably =20 want to use a command more like this: svn co https://=20 svn.sourceforge.net/svnroot/quickfixj/trunk quickfixj --oren On Jun 1, 2006, at 9:38 AM, Steve Bate wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20 > html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi Staffan, > > QuickFIX/J is in it's own Subversion repository now. See the following > page > for information on accessing it. > > http://sourceforge.net/svn/?group_id=3D163099 > > Regards, > > Steve > >> -----Original Message----- >> From: qui...@li... >> [mailto:qui...@li...] On >> Behalf Of Staffan Ulfberg >> Sent: Thursday, June 01, 2006 4:28 PM >> To: Oren Miller >> Cc: qui...@li... >> Subject: Re: [Quickfix-developers] Subversion Repository >> >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> "Oren Miller" <or...@qu...> writes: >> >>> The QuickFIX source has migrated from CVS to a Subversion >> repository. >>> The conversion was done with cvs2svn, so all the history has been >>> transfered. Directions on accessing the repository are on the >>> developer page: http://www.quickfixengine.org/developers.html >>> >>> Unlike with CVS, everybody hits the same repository, so >> there are no >>> delays between commiter checkins and public checkouts. >> >> I tried to check out the sources a few minutes ago, but I'm >> not able to find the Java sources (quickfixj). I can find a >> lot of native code, but not the (newer?) java code. Am I >> doing something wrong? >> >> Staffan >> >> >> ------------------------------------------------------- >> All the advantages of Linux Managed Hosting--Without the Cost >> and Risk! >> Fully trained technicians. The highest number of Red Hat >> certifications in the hosting industry. Fanatical Support. >> Click to learn more >> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729& >> dat=3D121642 >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and =20 > Risk! > Fully trained technicians. The highest number of Red Hat =20 > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=107521&bid$8729&dat=121642= > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Steve B. <sb...@sm...> - 2006-06-01 14:37:47
|
Hi Staffan, QuickFIX/J is in it's own Subversion repository now. See the following page for information on accessing it. http://sourceforge.net/svn/?group_id=3D163099 Regards, Steve > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Staffan Ulfberg > Sent: Thursday, June 01, 2006 4:28 PM > To: Oren Miller > Cc: qui...@li... > Subject: Re: [Quickfix-developers] Subversion Repository >=20 > QuickFIX Documentation:=20 > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html >=20 > "Oren Miller" <or...@qu...> writes: >=20 > > The QuickFIX source has migrated from CVS to a Subversion=20 > repository. > > The conversion was done with cvs2svn, so all the history has been=20 > > transfered. Directions on accessing the repository are on the=20 > > developer page: http://www.quickfixengine.org/developers.html > >=20 > > Unlike with CVS, everybody hits the same repository, so=20 > there are no=20 > > delays between commiter checkins and public checkouts. >=20 > I tried to check out the sources a few minutes ago, but I'm=20 > not able to find the Java sources (quickfixj). I can find a=20 > lot of native code, but not the (newer?) java code. Am I=20 > doing something wrong? >=20 > Staffan >=20 >=20 > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost=20 > and Risk! > Fully trained technicians. The highest number of Red Hat=20 > certifications in the hosting industry. Fanatical Support.=20 > Click to learn more > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729& > dat=3D121642 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers >=20 |
|
From: Staffan U. <sta...@mu...> - 2006-06-01 14:28:32
|
"Oren Miller" <or...@qu...> writes: > The QuickFIX source has migrated from CVS to a Subversion repository. > The conversion was done with cvs2svn, so all the history has been > transfered. Directions on accessing the repository are on the > developer page: http://www.quickfixengine.org/developers.html > > Unlike with CVS, everybody hits the same repository, so there are no > delays between commiter checkins and public checkouts. I tried to check out the sources a few minutes ago, but I'm not able to find the Java sources (quickfixj). I can find a lot of native code, but not the (newer?) java code. Am I doing something wrong? Staffan |
|
From: Oren M. <or...@qu...> - 2006-05-30 16:17:58
|
Not exactly. As an optimization the sequence numbers are cached in =20 memory (otherwise each sequence number lookup would require a round-=20 trip to the database). So with the current implementation you need =20 to start the Acceptor in order to read the state from the database. =20 So you are required to failover all sessions at once since you must =20 start the new acceptor and probably stop the old one. The failover implementation described by Steve is now in the QuickFIX =20= subversion tree and will go out with the next release. --oren On May 30, 2006, at 8:07 AM, Sean Kirkpatrick wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20 > html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi Oren / Steve, > > Prior to this thread of posts, I had been under the impression that =20= > when utilizing a database message store a system could be set up =20 > such that you have a backend database server to house the message =20 > store / logs with a layer above containing an array of servers, =20 > each running a quickfix acceptor that is configured to know about =20 > all of the sessions. A load balancer would then sit in front of =20 > the array of acceptors round-robinning FIX connections to them. If =20= > a session were to be logged in to box A for 3 hours, lose =20 > connectivity, and come back in to box C, then because each acceptor =20= > is working with the same database the session could continue as if =20 > it had reconnected to box A. Is this not the case? > > If not, where does the failover / farming support fall in the list =20 > of to-dos? > > Thanks, > Sean > > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...]On Behalf Of > Steve Bate > Sent: Monday, May 29, 2006 4:19 PM > Cc: qui...@li...; > qui...@li... > Subject: RE: [Quickfix-developers] QuickFix FailOver/Farming Support. > > > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20 > html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > >> I don't really see why the no-op results in incorrect runtime >> behavior. My view of the method is that it sets the state >> of the session to the persisted state. In the case of the >> memory store, it is persisted into memory. I >> could copy the state in memory from one place to another, it >> just happens that a no-op is a more efficient implementation. >> I don't really see it any different than if I refreshed against >> a database with store that is already in sync with the database. >> Nothing has changed (state wise), so it essentially acted like >> a no-op memory store refresh, but the end result is >> correct since the state of the session is correct. > > Hi Oren, > > Can you explain your view a little further? With a memory > store, how do you refresh the failed over session with the > session state that was previously stored in memory in a > separate process? When you say you could copy the state in > memory from one place to another are you talking about some > form of ongoing synchronization (vs. refresh at logon) > that updates the remote memory store every time the local > state changes? > >> As to the name, I had always seen the settings as sitting in >> the [SESSION] section. So I never thought that the settings >> required additional clarification any more then methods on >> the Session class are prefixed with Session. Pretty much >> every setting is like this. StartTime, EndTime, >> ConnectionType, ReconnectInterval etc. etc. None of these >> settings explicitly state they are session settings, but >> that is implied by the name >> of the section. > > OK, I understand. I agree about the shorter name. A > different question... did you envision the configuration > file eventually having section types other than "Session" > (and the pseudo-session for defaults)? > > Steve > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and =20 > Risk! > Fully trained technicians. The highest number of Red Hat =20 > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=107521&bid$8729&dat=121642 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and =20 > Risk! > Fully trained technicians. The highest number of Red Hat =20 > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=107521&bid$8729&dat=121642= > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Joerg T. <Joe...@ma...> - 2006-05-30 15:06:24
|
Hi Ajay,
> One useful property of QuickFIX's current processing of outbound
> messages is that the application can rely upon the knowledge that the
> message has been written written to the message store to the socket and
> by the time send() returns. This makes it relatively simple to make sur=
e
> all messages that the application thinks it has sent successfully will
> get to the counterparty.
Agreed, actually this is a very important property. As soon as QF sendToT=
arget() has=20
returned, QF has taken responsibility for the message.
> If an intermediate queue is introduced between the application and the
> processing of the message within the FIX engine, then depending upon
> whether the queue is introduced before QF writes to the message store o=
r
> after, there might be a need to invent additional mechanisms to allow
> the application to be informed when a message gets persisted so that it
> can track the message's progress through the engine. Otherwise messages
> that the application thought it had sent might still be waiting to be
> processed by a worker thread in an in-memory queue and might be lost in
> case of an engine failover.
The correct implementation would make the outbound queue and the message =
store identical.
sendToTarget() just writes the message to the (persistent) message store =
and then returns.=20
A separate thread picks up messages from the message store to be (re-)sen=
d.
Cheers, J=F6rg
--=20
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Caleb E. <cal...@gm...> - 2006-05-30 14:57:49
|
On 5/30/06, Ajay Kamdar <Aja...@tr...> wrote: > Otherwise messages > that the application thought it had sent might still be waiting to be > processed by a worker thread in an in-memory queue and might be lost in > case of an engine failover. Clearly this would not be an acceptable implementation. -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Ajay K. <Aja...@tr...> - 2006-05-30 14:41:26
|
One useful property of QuickFIX's current processing of outbound messages is that the application can rely upon the knowledge that the message has been written written to the message store to the socket and by the time send() returns. This makes it relatively simple to make sure all messages that the application thinks it has sent successfully will get to the counterparty. If an intermediate queue is introduced between the application and the processing of the message within the FIX engine, then depending upon whether the queue is introduced before QF writes to the message store or after, there might be a need to invent additional mechanisms to allow the application to be informed when a message gets persisted so that it can track the message's progress through the engine. Otherwise messages that the application thought it had sent might still be waiting to be processed by a worker thread in an in-memory queue and might be lost in case of an engine failover. - Ajay -----Original Message----- From: Sean Kirkpatrick [mailto:sea...@pi...]=20 Sent: Tuesday, May 30, 2006 8:58 AM To: Steve Bate Cc: quickfix-developers Subject: RE: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html Hi Steve, I understand your concerns. Guaranteeing message sequencing for a session becomes more complicated with a thread pool and message queue. Each session would need some kind of locking mechanism (a mutex would do the trick), that could be locked when a worker thread is processing the session's message queue. My thoughts were that it would be useful to have a set of incoming worker threads and outgoing worker threads. Each session could then have both an incoming and outgoing queue for messages that would be processed the same way. That way, any outgoing messages (even those sent from callback functions) would be written to the outgoing queue and picked up by a worker thread when all prior outgoing messages have been sent. This would hopefully eliminate the possibility of deadlocks. It's just very important not to starve any of the sessions while processing a queue for a very busy connection... Anyone have additional thoughts / comments / concerns? --Sean -------------------------------------------------------------------------= -- The information in this email is confidential and may be legally = privileged. It is intended solely for the addressee. Access to this email by anyone = else is unauthorized. If you are not the intended recipient, any disclosure, = copying, distribution or any action taken or omitted to be taken in reliance on = it, is prohibited and may be unlawful. TradeWeb reserves the right to monitor and review the content of all = messages sent to or from this e-mail address. Messages sent to or from this e-mail = address may be stored on the TradeWeb e-mail system. |
|
From: Sean K. <sea...@pi...> - 2006-05-30 13:07:27
|
Hi Oren / Steve, Prior to this thread of posts, I had been under the impression that when = utilizing a database message store a system could be set up such that = you have a backend database server to house the message store / logs = with a layer above containing an array of servers, each running a = quickfix acceptor that is configured to know about all of the sessions. = A load balancer would then sit in front of the array of acceptors = round-robinning FIX connections to them. If a session were to be logged = in to box A for 3 hours, lose connectivity, and come back in to box C, = then because each acceptor is working with the same database the session = could continue as if it had reconnected to box A. Is this not the case? If not, where does the failover / farming support fall in the list of = to-dos? Thanks, Sean -----Original Message----- From: qui...@li... [mailto:qui...@li...]On Behalf Of Steve Bate Sent: Monday, May 29, 2006 4:19 PM Cc: qui...@li...; qui...@li... Subject: RE: [Quickfix-developers] QuickFix FailOver/Farming Support. QuickFIX Documentation: = http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html > I don't really see why the no-op results in incorrect runtime=20 > behavior. My view of the method is that it sets the state=20 > of the session to the persisted state. In the case of the=20 > memory store, it is persisted into memory. I=20 > could copy the state in memory from one place to another, it=20 > just happens that a no-op is a more efficient implementation. =20 > I don't really see it any different than if I refreshed against=20 > a database with store that is already in sync with the database. =20 > Nothing has changed (state wise), so it essentially acted like=20 > a no-op memory store refresh, but the end result is=20 > correct since the state of the session is correct. Hi Oren, Can you explain your view a little further? With a memory store, how do you refresh the failed over session with the session state that was previously stored in memory in a=20 separate process? When you say you could copy the state in memory from one place to another are you talking about some form of ongoing synchronization (vs. refresh at logon) that updates the remote memory store every time the local state changes? > As to the name, I had always seen the settings as sitting in=20 > the [SESSION] section. So I never thought that the settings=20 > required additional clarification any more then methods on=20 > the Session class are prefixed with Session. Pretty much=20 > every setting is like this. StartTime, EndTime,=20 > ConnectionType, ReconnectInterval etc. etc. None of these=20 > settings explicitly state they are session settings, but=20 > that is implied by the name=20 > of the section. OK, I understand. I agree about the shorter name. A different question... did you envision the configuration=20 file eventually having section types other than "Session"=20 (and the pseudo-session for defaults)? Steve =20 ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications = in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=107521&bid$8729&dat=121642 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Sean K. <sea...@pi...> - 2006-05-30 12:57:44
|
Hi Steve, I understand your concerns. Guaranteeing message sequencing for a = session becomes more complicated with a thread pool and message queue. = Each session would need some kind of locking mechanism (a mutex would do = the trick), that could be locked when a worker thread is processing the = session's message queue. My thoughts were that it would be useful to = have a set of incoming worker threads and outgoing worker threads. Each = session could then have both an incoming and outgoing queue for messages = that would be processed the same way. That way, any outgoing messages = (even those sent from callback functions) would be written to the = outgoing queue and picked up by a worker thread when all prior outgoing = messages have been sent. This would hopefully eliminate the possibility = of deadlocks. It's just very important not to starve any of the = sessions while processing a queue for a very busy connection... Anyone have additional thoughts / comments / concerns? --Sean -----Original Message----- From: qui...@li... [mailto:qui...@li...]On Behalf Of Steve Bate Sent: Monday, May 29, 2006 4:32 AM Cc: quickfix-developers Subject: RE: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator QuickFIX Documentation: = http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html Hi Sean, One complication of a thread pool approach is that we must be sure that the messages for each session are processed in sequence. We can't just dispatch each received message to a thread in the=20 pool. One solution is to maintain a queue for each session and=20 then dispatch the queues to a thread pool. The worker threads=20 would process one or more messages (could be configurable)=20 each time they take a session queue for processing. Do you have any other ideas how to implement an thread pool initiator/acceptor? Do any of the threading experts out there know of an applicable pattern for this scenario? Steve > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Sean Kirkpatrick > Sent: Friday, May 12, 2006 11:00 PM > To: Oren Miller; Brian Erst; Caleb Epstein; Nick Volpe > Cc: quickfix-developers > Subject: RE: [Quickfix-developers] ThreadedSocketInitiator vs=20 > SocketInitiator >=20 > QuickFIX Documentation:=20 > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html >=20 > May I suggest that there also be a thread pool option? If an=20 > acceptor has hundreds of sessions configured, it won't be a=20 > good idea to spawn a thread per session... >=20 > --Sean >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...]On=20 > Behalf Of Oren Miller > Sent: Wednesday, May 10, 2006 12:56 PM > To: Brian Erst; Caleb Epstein; Nick Volpe > Cc: quickfix-developers > Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs=20 > SocketInitiator >=20 >=20 > QuickFIX Documentation:=20 > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html >=20 > There was, however it was overrun by WikiSpam and I never got=20 > around to researching solutions to the problem. >=20 > --oren >=20 > > p.s. Speaking of confusion, is there a QuickFIX wiki? While the=20 > > existing documentation is sufficient for getting started,=20 > in order to=20 > > really understand a lot of QF you have to read the mailing list=20 > > archives. If we had a wiki, I'd be tempted to transfer at=20 > least some=20 > > of the mailing list knowledge to the wiki, if only from an=20 > ongoing basis. >=20 >=20 >=20 > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web=20 > services, security? > Get stuff done quickly with pre-integrated technology to make=20 > your job easier Download IBM WebSphere Application Server=20 > v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& > dat=3D121642 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers >=20 >=20 > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web=20 > services, security? > Get stuff done quickly with pre-integrated technology to make=20 > your job easier Download IBM WebSphere Application Server=20 > v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers >=20 ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications = in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=107521&bid$8729&dat=121642 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Steve B. <sb...@sm...> - 2006-05-29 20:24:58
|
> I don't really see why the no-op results in incorrect runtime=20 > behavior. My view of the method is that it sets the state=20 > of the session to the persisted state. In the case of the=20 > memory store, it is persisted into memory. I=20 > could copy the state in memory from one place to another, it=20 > just happens that a no-op is a more efficient implementation. =20 > I don't really see it any different than if I refreshed against=20 > a database with store that is already in sync with the database. =20 > Nothing has changed (state wise), so it essentially acted like=20 > a no-op memory store refresh, but the end result is=20 > correct since the state of the session is correct. Hi Oren, Can you explain your view a little further? With a memory store, how do you refresh the failed over session with the session state that was previously stored in memory in a=20 separate process? When you say you could copy the state in memory from one place to another are you talking about some form of ongoing synchronization (vs. refresh at logon) that updates the remote memory store every time the local state changes? > As to the name, I had always seen the settings as sitting in=20 > the [SESSION] section. So I never thought that the settings=20 > required additional clarification any more then methods on=20 > the Session class are prefixed with Session. Pretty much=20 > every setting is like this. StartTime, EndTime,=20 > ConnectionType, ReconnectInterval etc. etc. None of these=20 > settings explicitly state they are session settings, but=20 > that is implied by the name=20 > of the section. OK, I understand. I agree about the shorter name. A different question... did you envision the configuration=20 file eventually having section types other than "Session"=20 (and the pseudo-session for defaults)? Steve =20 |
|
From: Jochen M. de L. <jm...@bm...> - 2006-05-29 19:05:29
|
Hello, =20 I looked at the latest Quickfix documentation and code, it seems that = there isn=B4t a way to programatically set the DataDictionary for a session. = It can be set only via an URL passed on by the config file. =20 Are there any plans to allow for something like a stream to init the DataDictionary, maybe available through the SessionSettings class? My rationale is that I=B4d like to store the data dictionary in a database instead of a plain ASCII file, as I am already doing with the config = file (SessionSettings accepts a stream in the ctor).=20 =20 Thanks in advance =20 Jochen Mielke de Lima Bolsa de Mercadorias & Futuros Diretoria de Sistema e Tecnologia - Divis=E3o de Neg=F3cios (55 11) 3119-2524=20 =20 Esta mensagem pode conter informa=E7=E3o confidencial e/ou = privilegiada. Se voc=EA n=E3o for o destinat=E1rio ou a pessoa autorizada a receber esta = mensagem, n=E3o dever=E1 utilizar, copiar, alterar, divulgar a informa=E7=E3o nela = contida ou tomar qualquer a=E7=E3o baseada nessas informa=E7=F5es. Se voc=EA = recebeu esta mensagem por engano, por favor avise imediatamente o remetente, = respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera=E7=E3o. This message may contain confidential and/or privileged information. If = you are not the addressee or authorized to receive this for the addressee, = you must not use, copy, disclose, change, take any action based on this = message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. |
98 messages has been excluded from this view by a project administrator.
