Menu
▾
▴
quickfixj-users — General mailing list for QuickFIX/J topics.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(21) |
Jul
(14) |
Aug
(29) |
Sep
(39) |
Oct
(47) |
Nov
(70) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(43) |
Feb
(50) |
Mar
(90) |
Apr
(96) |
May
(84) |
Jun
(40) |
Jul
(58) |
Aug
(55) |
Sep
(55) |
Oct
(52) |
Nov
(38) |
Dec
(75) |
| 2008 |
Jan
(49) |
Feb
(72) |
Mar
(49) |
Apr
(55) |
May
(21) |
Jun
(31) |
Jul
(47) |
Aug
(59) |
Sep
(59) |
Oct
(77) |
Nov
(51) |
Dec
(54) |
| 2009 |
Jan
(52) |
Feb
(57) |
Mar
(17) |
Apr
(27) |
May
(44) |
Jun
(46) |
Jul
(69) |
Aug
(38) |
Sep
(39) |
Oct
(45) |
Nov
(38) |
Dec
(37) |
| 2010 |
Jan
(49) |
Feb
(35) |
Mar
(21) |
Apr
(33) |
May
(52) |
Jun
(28) |
Jul
(39) |
Aug
(34) |
Sep
(21) |
Oct
(82) |
Nov
(36) |
Dec
(20) |
| 2011 |
Jan
(28) |
Feb
(64) |
Mar
(93) |
Apr
(75) |
May
(151) |
Jun
(77) |
Jul
(35) |
Aug
(53) |
Sep
(56) |
Oct
(36) |
Nov
(94) |
Dec
(59) |
| 2012 |
Jan
(105) |
Feb
(43) |
Mar
(68) |
Apr
(91) |
May
(45) |
Jun
(18) |
Jul
(103) |
Aug
(77) |
Sep
(45) |
Oct
(59) |
Nov
(58) |
Dec
(43) |
| 2013 |
Jan
(48) |
Feb
(65) |
Mar
(63) |
Apr
(22) |
May
(41) |
Jun
(60) |
Jul
(43) |
Aug
(17) |
Sep
(20) |
Oct
(20) |
Nov
(42) |
Dec
(43) |
| 2014 |
Jan
(54) |
Feb
(34) |
Mar
(34) |
Apr
(20) |
May
(31) |
Jun
(39) |
Jul
(66) |
Aug
(22) |
Sep
(52) |
Oct
(22) |
Nov
(67) |
Dec
(70) |
| 2015 |
Jan
(18) |
Feb
(5) |
Mar
(40) |
Apr
(32) |
May
(62) |
Jun
(28) |
Jul
(86) |
Aug
(44) |
Sep
(61) |
Oct
(65) |
Nov
(8) |
Dec
(19) |
| 2016 |
Jan
(50) |
Feb
(22) |
Mar
(38) |
Apr
(55) |
May
(30) |
Jun
(42) |
Jul
(11) |
Aug
(9) |
Sep
(4) |
Oct
(51) |
Nov
(38) |
Dec
(31) |
| 2017 |
Jan
(40) |
Feb
(40) |
Mar
(23) |
Apr
(35) |
May
(121) |
Jun
(55) |
Jul
(37) |
Aug
(16) |
Sep
(27) |
Oct
(109) |
Nov
(67) |
Dec
(23) |
| 2018 |
Jan
(52) |
Feb
(6) |
Mar
(23) |
Apr
(28) |
May
(32) |
Jun
(20) |
Jul
(20) |
Aug
(22) |
Sep
(8) |
Oct
(33) |
Nov
(32) |
Dec
(13) |
| 2019 |
Jan
(16) |
Feb
(29) |
Mar
(17) |
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
(25) |
Aug
(50) |
Sep
(17) |
Oct
(29) |
Nov
(16) |
Dec
(7) |
| 2020 |
Jan
|
Feb
|
Mar
(29) |
Apr
(64) |
May
(25) |
Jun
(49) |
Jul
(15) |
Aug
(10) |
Sep
(37) |
Oct
(20) |
Nov
(19) |
Dec
(9) |
| 2021 |
Jan
(33) |
Feb
(10) |
Mar
(67) |
Apr
(40) |
May
(70) |
Jun
(33) |
Jul
(14) |
Aug
(10) |
Sep
|
Oct
(7) |
Nov
(6) |
Dec
(16) |
| 2022 |
Jan
(27) |
Feb
(2) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(10) |
| 2023 |
Jan
(1) |
Feb
(2) |
Mar
(21) |
Apr
(3) |
May
(15) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2024 |
Jan
(7) |
Feb
(2) |
Mar
(8) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2025 |
Jan
(10) |
Feb
(4) |
Mar
(9) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Martin E. <me...@sc...> - 2007-01-16 15:12:29
|
I seem to be approaching a viable solution, so I thought I'd better follow this up... On 12/01/2007 14:21, Chris Hurst wrote: > Never used the Sun App server mostly apache tomcat , weblogic . It > doesn't use the mina libs itself does it I guessed not, but it may do. It's not important now. > I think basically the start up from within the web container is just a > bad idea , thats certainly not the way the technology is meant to work I tend to agree. The solution I now have involves passing FIX messages between the app server and Quickfix/J, which run in separate processes. It turns out to be very simple with JMS, because the quickfix.Message type implements Serializable. This meaning that you just pass the object, and it gets reconstructed in the remote process automagically. Brilliant. I needed to implement a 'synchronous' API (that can be used in a web page) on top of the asynchronous (event-driven) API that quickfix provides, with receive callbacks. The difficult bit turns out to be matching received messages (say, ExecutionReports) with the relevant thread (the one that generated the order, say), which has to block until the FIX reply is available. It kinda works, but I haven't got an elegant solution to that yet. Anyway, thanks for your thoughts. Martin |
|
From: Chris H. <chr...@ho...> - 2007-01-12 14:21:57
|
<html><div style='background-color:'><DIV class=RTE> <P>Never used the Sun App server mostly apache tomcat , weblogic . It doesn't use the mina libs itself does it (i.e. I believe they are used with Apache as an example and that would then cause the sympoms you describe just a wild stab in the dark) as that would give you similar problems if your versions don't line up.<BR><BR>I think basically the start up from within the web container is just a bad idea , thats certainly not the way the technology is meant to work :-) though weblogic definitely does support that kind of thing as some J2EE architects tried to push me down that route with a design but thats basically because J2EE guys don't write a lot of threads I find as their containers do that for them which is not a bad thing at all :-) !</P> <P>I think your heading towards some Jave 5 tech , it would be nice if it all still worked in Java 1.4 world and the J2EE stuff was quite seperate so that hooking in future QuickLib updates was easy.</P> <P>What I had in mind was a simple test tool , rather than what your describing which I think means you want a full blown application framework which would be nice but more work. I guess in some ways I decided it a simple J2ee servlet was just an alternative to the JMX way of doing things i.e. web page vs jconsole or the like. I presume you could subvert JMX to do the same thing i.e. create your own JMX bean to create fix messages and have your servlet attach to that . The JMX bean would be useful and sounds like several guys on here are working on something similar ??? though obviously JMX is meant for debugging \ monitoring Surely that would be quite straight foward all be it a little on the evil side ! obviously proper socket \ RMI \ web service solutions exist :-) wouldn't it be quite \ easy straight forward to do if you went Java 1.5 all the way and probably fine for a debugging test tool point of view for Quicklib.</P> <P>If you want a really big heavy weight solution , we currently have FIXML messages arriving over MQ for which we act as a JMS reciever (we're a NON J2EE multi threaded process in this case) now obviously you can point a J2EE container at the queue end to generate message beans , so you'll get a message bean (potentially in its own thread) per fix message each message will have to sequence with each other so your probably looking at central server with maybe a sequence manager EJB if you have clustering enabled and you could send back in a similar manner (i.e. you kinda want to be the reverse the sender rather than the reciever) ... but note the architecture is still FIX based but not a lot to do with Quick fix :-) ... and what I thought you were after and what I was thinking of is completely the other end of the scale ;-)</P> <P> </P> <P> </P> <P> </P></DIV> <DIV></DIV> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c6e5 2px solid; MARGIN-RIGHT: 0px"><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif"> <HR color=#a0c6e5 SIZE=1> <DIV></DIV>From: <I>Martin Ellis <me...@sc...></I><BR>Reply-To: <I>qui...@li...</I><BR>To: <I>chr...@ho..., qui...@li...</I><BR>Subject: <I>Re: [Quickfixj-users] Deploying QuickFIX/J in or alongsideJava EEcontainer</I><BR>Date: <I>Fri, 12 Jan 2007 09:08:20 +0000</I><BR>>QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<BR>>QuickFIX/J Support: http://www.quickfixj.org/support/<BR>>Hi Chris,<BR>><BR>>Thanks for your comments.<BR>><BR>>On 11/01/2007 17:59, Chris Hurst wrote:<BR>> > I kinda thought about doing the same thing with a tomcat (J2EE) server ,<BR>> > if you do it give me the source code :-)<BR>><BR>>Well, I tried the servlet idea yesterday, and it was a miserable<BR>>failure. Quickfix/J just didn't want to run in the app server at all.<BR>>I had to set the VM to use a larger PermGen size, and even then I got<BR>>all sorts of errors from mina in the FIX event log that didn't really<BR>>seem to make sense.<BR>><BR>>You're welcome to the source code for my test if you'd like to see for<BR>>yourself what goes wrong.<BR>><BR>>I guess that means that my only option is to run QuickFIX/J in a<BR>>separate process.<BR>><BR>> > I suspect you'ed end up writing a quick message to JMS adaptor and then<BR>> > have your messages processed by message beans but that would be a<BR>> > serious amount of work redesign and I don't think thats what you have in<BR>> > mind.<BR>><BR>>No, but I think I'll probably end up shuffling FIX messages to and from<BR>>the separate process using JMS (see below).<BR>><BR>> > QuickFix is a multithreaded<BR>> > application, you can split it into beans but it requires some redisgn<BR>> > thought which I think is unecessary in your case.<BR>><BR>>Right.<BR>><BR>> > (you could<BR>> > have your quickfix app run as is (non J2EE process), as a container<BR>> > start up process (rather than the servlet method you described)<BR>><BR>>I'm not sure I've heard of them. Do you know if the Sun App Server<BR>>supports them, and what they're called in that (excuse the pun) context?<BR>><BR>>I tend to agree that it'll be easier to just start the process<BR>>separately though.<BR>><BR>> > Anyway basically the really simple version is to run your quickfix app<BR>> > serperate, store your messages in a databse, your servlet just qives<BR>> > you a view of your quick fix messages stored in a database and you have<BR>> > another table for messages from your web page i.e. when your user<BR>> > submits a send a fix message by clicking a button, it creates a row in<BR>> > the database. Add a new thread to the quick fix app that polls the table<BR>> > (yes I know you could do this faster by listening on a socket, RMI etc<BR>> > but this is the simple / easy way and I presume you don't need that<BR>> > level of speed ??) to the quickfix app that then removes your new<BR>> > messages from the table and sends them out.<BR>><BR>>I think we will need that speed eventually, hence my new plan to use JMS<BR>>to shuttle FIX messages around.<BR>><BR>> > As for marshalling if you wanted you could use something like hibernate<BR>> > to store your message objects created by your servlet on the database as<BR>> > that can even generate the database schema etc , handle the writing to<BR>> > the database etc.<BR>><BR>>For marshalling, I'm hoping the fact that quickfix.Message is a<BR>>Serializable will allow it to be sent straightforwardly as a JMS message<BR>>(but I'm a JMS virgin, right now). For persistence, I'm actually quite<BR>>a fan of the new Java Persistence API, which seems to be very much<BR>>hibernate-inspired.<BR>><BR>>Cheers<BR>>Martin<BR>><BR>>-------------------------------------------------------------------------<BR>>Take Surveys. Earn Cash. Influence the Future of IT<BR>>Join SourceForge.net's Techsay panel and you'll get the chance to share your<BR>>opinions on IT & business topics through brief surveys - and earn cash<BR>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV<BR>>_______________________________________________<BR>>Quickfixj-users mailing list<BR>>Qui...@li...<BR>>https://lists.sourceforge.net/lists/listinfo/quickfixj-users<BR></FONT></BLOCKQUOTE></div><br clear=all><hr> <a href="http://g.msn.com/8HMBENUS/2752??PS=47575" target="_top">Type your favorite song. Get a customized station. Try MSN Radio powered by Pandora.</a> </html> |
|
From: Martin E. <me...@sc...> - 2007-01-12 09:09:12
|
Hi Chris, Thanks for your comments. On 11/01/2007 17:59, Chris Hurst wrote: > I kinda thought about doing the same thing with a tomcat (J2EE) server , > if you do it give me the source code :-) Well, I tried the servlet idea yesterday, and it was a miserable failure. Quickfix/J just didn't want to run in the app server at all. I had to set the VM to use a larger PermGen size, and even then I got all sorts of errors from mina in the FIX event log that didn't really seem to make sense. You're welcome to the source code for my test if you'd like to see for yourself what goes wrong. I guess that means that my only option is to run QuickFIX/J in a separate process. > I suspect you'ed end up writing a quick message to JMS adaptor and then > have your messages processed by message beans but that would be a > serious amount of work redesign and I don't think thats what you have in > mind. No, but I think I'll probably end up shuffling FIX messages to and from the separate process using JMS (see below). > QuickFix is a multithreaded > application, you can split it into beans but it requires some redisgn > thought which I think is unecessary in your case. Right. > (you could > have your quickfix app run as is (non J2EE process), as a container > start up process (rather than the servlet method you described) I'm not sure I've heard of them. Do you know if the Sun App Server supports them, and what they're called in that (excuse the pun) context? I tend to agree that it'll be easier to just start the process separately though. > Anyway basically the really simple version is to run your quickfix app > serperate, store your messages in a databse, your servlet just qives > you a view of your quick fix messages stored in a database and you have > another table for messages from your web page i.e. when your user > submits a send a fix message by clicking a button, it creates a row in > the database. Add a new thread to the quick fix app that polls the table > (yes I know you could do this faster by listening on a socket, RMI etc > but this is the simple / easy way and I presume you don't need that > level of speed ??) to the quickfix app that then removes your new > messages from the table and sends them out. I think we will need that speed eventually, hence my new plan to use JMS to shuttle FIX messages around. > As for marshalling if you wanted you could use something like hibernate > to store your message objects created by your servlet on the database as > that can even generate the database schema etc , handle the writing to > the database etc. For marshalling, I'm hoping the fact that quickfix.Message is a Serializable will allow it to be sent straightforwardly as a JMS message (but I'm a JMS virgin, right now). For persistence, I'm actually quite a fan of the new Java Persistence API, which seems to be very much hibernate-inspired. Cheers Martin |
|
From: Chris H. <chr...@ho...> - 2007-01-11 17:59:44
|
<html><div style='background-color:'><DIV class=RTE> <P>I kinda thought about doing the same thing with a tomcat (J2EE) server , if you do it give me the source code :-)</P> <P>I've done a lot of multithreaded process vs J2EE projects , a full J2EE solution would bring a raft of REALLY lovely stuff like clustering, transactions, remote adminstration etc etc but be a serious bit of work I suspect you'ed end up writing a quick message to JMS adaptor and then have your messages processed by message beans but that would be a serious amount of work redesign and I don't think thats what you have in mind. Remember the idea with EJB's is each runs in its own thread the container is meant to generate manage your threads (which is nice but you have to design in a J2EE type way) QuickFix is a multithreaded application, you can split it into beans but it requires some redisgn thought which I think is unecessary in your case.</P> <P>The simple pattern which I've implemented a few times (the pattern not as this application) is to have the quick fix as a controller, the J2EE server as your view and a database in between as the model. (you could have your quickfix app run as is (non J2EE process), as a container start up process (rather than the servlet method you described) but we decided that was not worth it last time i.e. its simpler to just have it run seperately.</P> <P>Anyway basically the really simple version is to run your quickfix app serperate, store your messages in a databse, your servlet just qives you a view of your quick fix messages stored in a database and you have another table for messages from your web page i.e. when your user submits a send a fix message by clicking a button, it creates a row in the database. Add a new thread to the quick fix app that polls the table (yes I know you could do this faster by listening on a socket, RMI etc but this is the simple / easy way and I presume you don't need that level of speed ??) to the quickfix app that then removes your new messages from the table and sends them out.</P> <P>As for marshalling if you wanted you could use something like hibernate to store your message objects created by your servlet on the database as that can even generate the database schema etc , handle the writing to the database etc.<BR></P> <P>Just my thoughts.<BR></P></DIV> <DIV></DIV> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c6e5 2px solid; MARGIN-RIGHT: 0px"><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif"> <HR color=#a0c6e5 SIZE=1> <DIV></DIV>From: <I>Martin Ellis <me...@sc...></I><BR>Reply-To: <I>qui...@li...</I><BR>To: <I>qui...@li...</I><BR>Subject: <I>[Quickfixj-users] Deploying QuickFIX/J in or alongside Java EEcontainer</I><BR>Date: <I>Thu, 11 Jan 2007 09:52:27 +0000</I><BR>>QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<BR>>QuickFIX/J Support: http://www.quickfixj.org/support/<BR>>Hi,<BR>><BR>>I'm looking for suggestions about ways to run a FIX engine such that it<BR>>can be used from a web application in a Java EE container. The aim<BR>>being to have a web page that allows FIX messages to be sent, and<BR>>received messages to be displayed.<BR>><BR>>Here are my notes on the advantages (+) and disadvantages (-) of the<BR>>different approaches I've considered so far:<BR>><BR>>* Run the FIX engine in a separate process<BR>><BR>> + Life cycle of FIX engine is independent of application container.<BR>> - Complexity due to IPC mechanism required to pass messages between<BR>> app server and FIX engine.<BR>> - QuickFIX/J seems to have no means for marshalling messages in this<BR>> way.<BR>><BR>>* Run the FIX engine as an EJB:<BR>>Caveat: I've never used EJBs before.<BR>><BR>> + Simpler deployment than using a separate process<BR>> - I'm not clear whether the EJB lifecycle supports 'always on'<BR>> services as would be required by a FIX engine.<BR>><BR>>* Run the FIX engine in a servlet container, using a ContextListener to<BR>>manage its lifecycle.<BR>>In this method, initiator.start() would be called in a<BR>>contextInitialized() method, and initiator.stop() would be called in a<BR>>contextDestroyed() method().<BR>><BR>> + Simple deployment.<BR>> + FIX engine life cycle determined by that of application container.<BR>> - Doesn't seem conceptually right to run a FIX engine in a container<BR>> designed for running servlets.<BR>><BR>>Has anyone tried such a deployment before?<BR>>Could anyone offer any experience about what works well, and what to<BR>>avoid here?<BR>><BR>>TIA for any advice offered,<BR>>Martin<BR>><BR>>-------------------------------------------------------------------------<BR>>Take Surveys. Earn Cash. Influence the Future of IT<BR>>Join SourceForge.net's Techsay panel and you'll get the chance to share your<BR>>opinions on IT & business topics through brief surveys - and earn cash<BR>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV<BR>>_______________________________________________<BR>>Quickfixj-users mailing list<BR>>Qui...@li...<BR>>https://lists.sourceforge.net/lists/listinfo/quickfixj-users<BR></FONT></BLOCKQUOTE></div><br clear=all><hr>MSN Hotmail is evolving check out the new <a href="http://g.msn.com/8HMAENUK/2740??PS=47575" target="_top">Windows Live Mail</a> </html> |
|
From: Martin E. <me...@sc...> - 2007-01-11 09:53:17
|
Hi,
I'm looking for suggestions about ways to run a FIX engine such that it
can be used from a web application in a Java EE container. The aim
being to have a web page that allows FIX messages to be sent, and
received messages to be displayed.
Here are my notes on the advantages (+) and disadvantages (-) of the
different approaches I've considered so far:
* Run the FIX engine in a separate process
+ Life cycle of FIX engine is independent of application container.
- Complexity due to IPC mechanism required to pass messages between
app server and FIX engine.
- QuickFIX/J seems to have no means for marshalling messages in this
way.
* Run the FIX engine as an EJB:
Caveat: I've never used EJBs before.
+ Simpler deployment than using a separate process
- I'm not clear whether the EJB lifecycle supports 'always on'
services as would be required by a FIX engine.
* Run the FIX engine in a servlet container, using a ContextListener to
manage its lifecycle.
In this method, initiator.start() would be called in a
contextInitialized() method, and initiator.stop() would be called in a
contextDestroyed() method().
+ Simple deployment.
+ FIX engine life cycle determined by that of application container.
- Doesn't seem conceptually right to run a FIX engine in a container
designed for running servlets.
Has anyone tried such a deployment before?
Could anyone offer any experience about what works well, and what to
avoid here?
TIA for any advice offered,
Martin
|
|
From: Hristo K. <hr...@ri...> - 2007-01-10 14:07:17
|
Hi, I have problems understanding how to deal with the following situation: 1) my session is lost for some reason, for example a heartbeat timeout: FXXApplication -- toAdmin. Message [0], session [FIX.4.4:TRADEP2->FXX:1168432286997] FXXApplication -- fromAdmin. Message [0], session [FIX.4.4:TRADEP2->FXX:1168432286997] FXXApplication -- toAdmin. Message [1], session [FIX.4.4:TRADEP2->FXX:1168432286997] FIX.4.4:TRADEP2->FXX:1168432286997, event> (Sent test request TEST) FIX.4.4:TRADEP2->FXX:1168432286997, event> (Timed out waiting for heartbeat) FIX.4.4:TRADEP2->FXX:1168432286997, event> (Disconnecting) FXXApplication logout: FIX.4.4:TRADEP2->FXX:1168432286997 ---------------------------------------------------------------------------------------------------------------------- 2) a new session is created, but this fails because of a message sequence number validation 14:39:34,461 INFO [STDOUT] Jan 10, 2007 2:39:34 PM quickfix.mina.initiator.InitiatorIoHandler sessionCreated INFO: MINA session created: /192.168.0.12:1834 FXXApplication -- toAdmin. Message [A], session [FIX.4.4:TRADEP2->FXX:1168432286997] FIX.4.4:TRADEP2->FXX:1168432286997, event> (Initiated logon request) FXXApplication -- fromAdmin. Message [A], session [FIX.4.4:TRADEP2->FXX:1168432286997] FIX.4.4:TRADEP2->FXX:1168432286997, event> (Received logon response) FXXApplication new logon. Session: FIX.4.4:TRADEP2->FXX:1168432286997 FXXApplication -- toAdmin. Message [5], session [FIX.4.4:TRADEP2->FXX:1168432286997] FIX.4.4:TRADEP2->FXX:1168432286997, event> (quickfix.SessionException MsgSeqNum too low, expecting 342 but received 2) ---------------------------------------------------------------------------------------------------------------------- To me the problem is not with the validation, but possibly because I am still using the old session for some reason. Could anyone help? many thanks, Hristo |
|
From: Andre M. <an...@gm...> - 2007-01-07 03:56:21
|
everything you need to know is here: http://fixprotocol.org/specifications/ On 1/6/07, Shahbaz <sha...@gm...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Does any one know of any resources for someone who wants to learn how > FIX works (from a developer's perspective)? > > I'll be spending some time going through quickficj, however reading > code doesn't always give the big picture. The same is true of couple > of specification documents I've looked at: they explain all the fields > but not enough high level stuff. > > I'd like to know what messages are exchanged when a trader wants to > buy a security, when the trade 'goes through,' when it is cancelled. > What happens when a market maker wants to change his quotes. What are > the most often used messages, which fields are almost never used. > What fields might be of interest to hedge funds, exchanges, retail > brokers, ecns, etc., etc. > > Basically I'd like to get an intuitive feel for FIX (and through FIX, > the digital nervous system of Wall Street.). > > May I also suggest that some of the gurus on this list write up a few > articles, for those of us who are programmers in the financial world, > but haven't dealt with FIX yet. > > Thanks. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > -- Thanks, -Andre |
|
From: Shahbaz <sha...@gm...> - 2007-01-06 17:12:40
|
Does any one know of any resources for someone who wants to learn how FIX works (from a developer's perspective)? I'll be spending some time going through quickficj, however reading code doesn't always give the big picture. The same is true of couple of specification documents I've looked at: they explain all the fields but not enough high level stuff. I'd like to know what messages are exchanged when a trader wants to buy a security, when the trade 'goes through,' when it is cancelled. What happens when a market maker wants to change his quotes. What are the most often used messages, which fields are almost never used. What fields might be of interest to hedge funds, exchanges, retail brokers, ecns, etc., etc. Basically I'd like to get an intuitive feel for FIX (and through FIX, the digital nervous system of Wall Street.). May I also suggest that some of the gurus on this list write up a few articles, for those of us who are programmers in the financial world, but haven't dealt with FIX yet. Thanks. |
|
From: Andre M. <an...@gm...> - 2007-01-05 16:36:15
|
Hey All, Trying to figure out why I'm seeing this body length discrepancy. anybody have any ideas? I'm in control of both the server and client code, it used to work I'm not sure what has changed with this particular message to raise an exception. I'm using a custom data dictionary. <20070105-16:31:03, FIX.4.4:TestClient2->XXX, incoming> (8=3D FIX.4.4=019=3D455=0135=3DW=0134=3D118=0149=3DXXX=0152=3D20070105-16:31:03.0= 93=0156=3DTestClient2=0155=3DGBP/USD=019000=3D3=019001=3D4=019002=3D0.0001= =019005=3D3=019011=3D0=019020=3D0=01268=3D5=01269=3D0=01270=3D1.9280=0115= =3DGBP=01272=3D20070105=01273=3D16:30:06=01336=3DXXX=01625=3DU100D5=01276= =3DA=01282=3DU100D5_DESK=01299=3DXXX_U100D5_DESK_00000000000301162674=01537= =3D1=01269=3D1=01270=3D1.9285=0115=3DGBP=01272=3D20070105=01273=3D16:30:06= =01336=3DXXX=01625=3DU100D5=01276=3DA=01282=3DU100D5_DESK=01299=3DXXX_U100D= 5_DESK_00000000000301162674=01537=3D1=01269=3D8=01270=3D1.9262=01269=3D7=01= 270=3D1.9448=01269=3D4=01270=3D1.9280=0110=3D201=01 ) [QFIX] ERROR (2007-01-05 11:31:03,093) [SocketIoProcessor-0] ( AbstractIoHandler.messageReceived) - Invalid message: Actual body length=3D398, Expected body length=3D455 --=20 Thanks, -Andre |
|
From: Steve B. <st...@te...> - 2007-01-02 14:03:46
|
Hi Chris, Thanks again for the help. I've committed most of the changes you suggested. Session: I've removed the volatile declarations and synchronized everything. The reason I was preferring volatile was not because of synchronization overhead per se, but I was trying to minimize the potential side effects like deadlocks when interacting with application callbacks. I also try to not have unnecessary synchronization because the resulting CPU cache flushes can impact performance in some situations. However, I agree that if a QFJ user is using a file store or JDBC store then that store will limit the performance, not the QFJ engine or any synchronization in it. >From what I've heard, much of the Java 5 memory model was incorporated into 1.4 at some point. However, I haven't found specifics about what was and what wasn't incorporated (and in what minor version of 1.4) so I agree with you suggestion to not use volatile until we have more specific information. SessionConnector: I made the session map effectively immutable (unmodifiable) and synchronized access to the reference. I also synchronized access to the scheduler future reference. SingleThreadedEventHandlingStrategy: Synchronized stopTime instead of using volatile. AbstractSocketConnector: I made the changes you suggeste. Banzai: I don't plan to make any changes to Banzai in the branch unless there is a serious problem with it. If anybody would like to submit patches for the trunk I'll make changes there. Anything else? Thanks again, Steve > -----Original Message----- > From: qui...@li... [mailto:quickfixj- > use...@li...] On Behalf Of Chris Hurst > Sent: Thursday, December 21, 2006 12:59 PM > To: qui...@li... > Subject: Re: [Quickfixj-users] Thread safety and MINA upgrade > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ |
|
From: Steve B. <st...@te...> - 2006-12-29 03:33:36
|
Hi Toli, After the 1.0.5 maintenance release, I'm hoping that that QFJ 1.1 release with the JMX MBeans will happen before the end of January. Of course, I can't guarantee anything. As for help, using the MBeans and providing feedback will help. I'll want to revisit the thread safety issues in the context of multithreaded JMX access. Steve > -----Original Message----- > From: qui...@li... [mailto:quickfixj- > use...@li...] On Behalf Of Toli Kuznets > Sent: Friday, December 22, 2006 9:11 PM > To: qui...@li... > Subject: Re: [Quickfixj-users] Adding JMX visibility to QuickfixJ > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Steve, > > Thanks, these are very helpful. I was able to create access the simple > JmxExporter, which provided me with enough visibility into what i > needed. > > Any roadmap on when the next release including the JMX code is planned? > What can I do to help it along? what tests/functionality do you have > planned that's missing right now? > > thanks! > > -- > Toli Kuznets > http://www.marketcetera.com: Open-Source Trading Platform > download.run.trade. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: <Zol...@ss...> - 2006-12-28 22:11:33
|
Thanks Steve!
steve@technoetic.
com
Sent by: To
quickfixj-users-b qui...@li....n
ou...@li... et
ceforge.net cc
Subject
12/28/2006 02:49 Re: [Quickfixj-users] Populating
PM OnBehalfOfCompID
Please respond to
quickfixj-users@l
ists.sourceforge.
net
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Hi Zoltan,
You can add the fields in your Application.toApp() callback. See...
http://www.quickfixj.org/confluence/display/qfj/Using+Custom+Settings
for more information on using custom settings.
Steve
> Can someone tell me how I would populate OnBehalfOfCompID on all outgoing
> messages from an acceptor application? It would be great if I could
> define this at the session level in the config file. Something like...
>
> [session]
> SenderCompID=SND42
> TargetCompID=TGT42
> OnBehalfOfCompID=BROKERx
>
> Thoughts?
>
> Thanks,
> Zoltan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
|
|
From: <st...@te...> - 2006-12-28 19:49:21
|
Hi Zoltan, You can add the fields in your Application.toApp() callback. See... http://www.quickfixj.org/confluence/display/qfj/Using+Custom+Settings for more information on using custom settings. Steve > Can someone tell me how I would populate OnBehalfOfCompID on all outgoing > messages from an acceptor application? It would be great if I could > define this at the session level in the config file. Something like... > > [session] > SenderCompID=SND42 > TargetCompID=TGT42 > OnBehalfOfCompID=BROKERx > > Thoughts? > > Thanks, > Zoltan |
|
From: Alvin W. <AW...@FF...> - 2006-12-28 15:56:22
|
I had similar request and i just wrote something that can read and parse
the custom configuration.
Zoltan_Feledy@ssg
a.com
Sent by: To
quickfixj-users-b qui...@li....n
ou...@li... et
ceforge.net cc
Subject
12/28/2006 10:53 [Quickfixj-users] Populating
AM OnBehalfOfCompID
Please respond to
quickfixj-users@l
ists.sourceforge.
net
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Hello,
Can someone tell me how I would populate OnBehalfOfCompID on all outgoing
messages from an acceptor application? It would be great if I could define
this at the session level in the config file. Something like...
[session]
SenderCompID=SND42
TargetCompID=TGT42
OnBehalfOfCompID=BROKERx
Thoughts?
Thanks,
Zoltan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
*******************************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and
confidential.
Disclosure to anyone other than the intended recipient is prohibited.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise. Instead,
please notify us immediately by return e-mail(including the original
message with your reply) and then delete and discard all copies of the
message. We have taken precautions to minimize the risk of transmitting
software viruses but nevertheless advise you to carry out your own
virus checks on any attachment to this message. We accept
no liability for any loss or damage caused by software viruses.
*******************************************************************************
|
|
From: <Zol...@ss...> - 2006-12-28 15:53:53
|
Hello, Can someone tell me how I would populate OnBehalfOfCompID on all outgoing messages from an acceptor application? It would be great if I could define this at the session level in the config file. Something like... [session] SenderCompID=SND42 TargetCompID=TGT42 OnBehalfOfCompID=BROKERx Thoughts? Thanks, Zoltan |
|
From: Toli K. <to...@ma...> - 2006-12-23 02:11:04
|
Steve, Thanks, these are very helpful. I was able to create access the simple JmxExporter, which provided me with enough visibility into what i needed. Any roadmap on when the next release including the JMX code is planned? What can I do to help it along? what tests/functionality do you have planned that's missing right now? thanks! -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Toli K. <to...@ma...> - 2006-12-22 19:01:07
|
Steve, i'm attaching a small set of changes for allowing filtering of heartbeats in the JdbcLog. It's probably going to be the first step towards fixing QFJ-75 (http://www.quickfixj.org/jira/browse/QFJ-75) I've just added a skipHeartbeats() setter to JdbcLog sine i didn't want to modify the API, created a LogBase class both for ScreenLog and JdbcLog and added a few rudimentary unit tests. see the attached patch file, it's from the quickfixj/core directory. toli -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Toli K. <to...@ma...> - 2006-12-22 00:27:24
|
Steve, i spoke too soon - my apologies. My IDE was obtuse and didn't reload everything correctly until i restarted it for some reason. the code compiles/runs/passes tests just fine on the command line. On 12/21/06, Toli Kuznets <to...@ma...> wrote: > Steve, > > Thanks for the check-in - i'll start using it as a base for what i'm > workign on, and maybe send you the changes i'll make. > > btw, the mbean.connector.SocketInitiatorAdmin and > mbean.session.SessionAdmin classes don't conmpile - they are referring > to some missing function calls. > > but i can fake it for now to get going. > > thanks! > > > > I've been working on JMX MBeans and supporting code for QFJ. It's not > > complete yet, but I've gone ahead and committed what I currently have > > into SVN. It's in the org.quickfixj.jmx package in the trunk. I have > > JMX instrumented versions of Banzai and the order executor, but they > > aren't committed yet. I'll be adding those very soon. > -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Toli K. <to...@ma...> - 2006-12-21 23:31:46
|
Steve, Thanks for the check-in - i'll start using it as a base for what i'm workign on, and maybe send you the changes i'll make. btw, the mbean.connector.SocketInitiatorAdmin and mbean.session.SessionAdmin classes don't conmpile - they are referring to some missing function calls. but i can fake it for now to get going. thanks! > I've been working on JMX MBeans and supporting code for QFJ. It's not > complete yet, but I've gone ahead and committed what I currently have > into SVN. It's in the org.quickfixj.jmx package in the trunk. I have > JMX instrumented versions of Banzai and the order executor, but they > aren't committed yet. I'll be adding those very soon. |
|
From: Chris H. <chr...@ho...> - 2006-12-21 18:04:16
|
<html><div style='background-color:'><DIV class=RTE> <P>I am also a bit supsicious of AbstractSocketAcceptor in that startAcceptingConnections is synchronized and stopAcceptingConnections isn't my instict is that either both should be or shouldn't be though I haven't followed this code through yet i.e. if one requires it you exepct the other to ??</P></DIV> <DIV></DIV> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c6e5 2px solid; MARGIN-RIGHT: 0px"><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif"> <HR color=#a0c6e5 SIZE=1> <DIV></DIV>From: <I>st...@te...</I><BR>Reply-To: <I>qui...@li...</I><BR>To: <I>qui...@li...</I><BR>Subject: <I>Re: [Quickfixj-users] Thread safety and MINA upgrade</I><BR>Date: <I>Wed, 20 Dec 2006 11:50:59 -0500 (EST)</I><BR>>QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<BR>>QuickFIX/J Support: http://www.quickfixj.org/support/<BR>>The SVN branch for the 1.0.x release is...<BR>><BR>>https://svn.sourceforge.net/svnroot/quickfixj/branches/QFJ_RELEASE_1_0_x<BR>><BR>>Steve<BR>><BR>> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<BR>> > QuickFIX/J Support: http://www.quickfixj.org/support/<BR>> > Hi Chris,<BR>> ><BR>> > I've committed the MINA 1.0.1 upgrade to the 1.0.x branch. I've also<BR>> > modified several classes to improve thread safety. The good news was<BR>> > that primary message processing paths appeared to be in good shape.<BR>> > It was other access to the session state that might have caused some<BR>> > inter-thread visibility problems.<BR>> ><BR>> > My strategy was to fully encapsulate the SessionState within<BR>> > the Session and protect thread access to it via the Session. I didn't<BR>> > want to synchronize all methods on SessionState and/or make all the fields<BR>> > volatile because it would hurt performance unnecessarily. I've also made<BR>> > the SessionSchedule immutable and removed some object caching that it<BR>> > was doing. This was thread safe caching but could cause unnecessary<BR>> > synchronization between threads. I've also generally tried to minimize<BR>> > any mutable state in the thread safe classes to make it easier to<BR>> > analyze (and because it's a good design practice anyway).<BR>> ><BR>> > All the public methods on Session are now either synchronized or refer to<BR>> > final or volatile fields. The extra synchronization is primarily for<BR>> > public session state getter methods that are for external use. I don't<BR>> > expect the internal session performance to be impacted.<BR>> ><BR>> > I've also refactored the initiator connection code (as you suggested).<BR>> > I've encapsulated most of the mutable state within the periodic<BR>> > connection management task and made the task thread safe.<BR>> ><BR>> > If you and others would like to review the changes, I'd appreciate it. The<BR>> > tests are all passing but I'd like a few more people to try it before I do<BR>> > a 1.0.5 release.<BR>> ><BR>> > Thanks!<BR>> ><BR>> > Steve<BR>> ><BR>> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<BR>> >> QuickFIX/J Support: http://www.quickfixj.org/support/<BR>> >> <html><div style='background-color:'><DIV class=RTE><BR>> >> <P>Would it be possible to move forward a little mina lib wise, I've<BR>> >> moved<BR>> >> my personal copy of the source to 0.95 (obviously the newer the better I<BR>> >> see they are up to 1.01) with little effort (one small class change) and<BR>> >> I'm running tests now and all seems well, Java 1.4 &amp; 1.5.<BR><BR>I<BR>> >> was<BR>> >> trying to give myself a back out, in case we had the hung port issue<BR>> >> previously listed by Christian (and listed as a bug fix against mina,<BR>> >> 0.95<BR>> >> has the necessary fix) we haven't seen this issue for a long time and<BR>> >> it'll be very hard to prove, reproduce, we intend to have a go. If I can<BR>> >> prove its there obviously I'll raise this as a proper bug , if we can<BR>> >> figure out a way to reliably reproduce it I'll try the new mina and<BR>> >> hopefully that will fix it but it is very rare at best.</P></DIV><BR>> >> <DIV></DIV></div><br clear=all><hr>It's Hotmail's 10th Birthday! Come<BR>> >> and<BR>> >> play <a href="http://g.msn.com/8HMBENUK/2728??PS=47575"<BR>> >> target="_top">Pass the Parcel</a> </html><BR>> >><BR>> >><BR>> >> -------------------------------------------------------------------------<BR>> >> Take Surveys. Earn Cash. Influence the Future of IT<BR>> >> Join SourceForge.net's Techsay panel and you'll get the chance to share<BR>> >> your<BR>> >> opinions on IT & business topics through brief surveys - and earn cash<BR>> >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________<BR>> >> Quickfixj-users mailing list<BR>> >> Qui...@li...<BR>> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users<BR>> >><BR>> ><BR>> ><BR>> ><BR>> > -------------------------------------------------------------------------<BR>> > Take Surveys. Earn Cash. Influence the Future of IT<BR>> > Join SourceForge.net's Techsay panel and you'll get the chance to share<BR>> > your<BR>> > opinions on IT & business topics through brief surveys - and earn cash<BR>> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV<BR>> > _______________________________________________<BR>> > Quickfixj-users mailing list<BR>> > Qui...@li...<BR>> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users<BR>> ><BR>><BR>><BR>><BR>>-------------------------------------------------------------------------<BR>>Take Surveys. Earn Cash. Influence the Future of IT<BR>>Join SourceForge.net's Techsay panel and you'll get the chance to share your<BR>>opinions on IT & business topics through brief surveys - and earn cash<BR>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV<BR>>_______________________________________________<BR>>Quickfixj-users mailing list<BR>>Qui...@li...<BR>>https://lists.sourceforge.net/lists/listinfo/quickfixj-users<BR></FONT></BLOCKQUOTE></div><br clear=all><hr>Think you're a film buff? Play the <a href="http://g.msn.com/8HMBENUK/2746??PS=47575" target="_top">Movie Mogul quiz </a> for a chance to win fantastic prizes</html> |
|
From: Chris H. <chr...@ho...> - 2006-12-21 17:58:59
|
<html><div style='background-color:'><DIV class=RTE>
<P>Hi Steve,</P>
<P> Thats for the hard work, I'll try and build it and give it a run, this is some points I'ved made so far, I'll keep digging.</P>
<P><BR> Personally i wouldn't get too hung up on the cost of synchronisation I think a lot of book authors who wrote in the early days of Java have back tracked significantly and are now promoting more synchronisation, look up the double check idiom for lazy initialisation for examples of what I'm rabitting on about. I've written a lot of big buisness critical 24 by 7 systems <BR> for blue chips that run a lot of threads on a lot of processors that run very fast and its not ususally over synchronization thats the problem with preformance.<BR> The lastest JVM's can do some insane optimisations on the fly and ignoring the very early ones their all not that bad, though as an aside it would be interesting on what impact having the same log file for all threads has if any as the threads contest to write to the log file, I've never seen the internals of PrinterWriter so I
can't on its implemenation, i may run some test over Christmas.<BR> <BR> In general I know we weren't going for a state machine and I understand why but if a class has two conflicting state methods I think it would be good to synchronize them e.g. log off / logon messages as this would enforce you can't be logging on and off at the same time this kind of things usually occur where you log off and another reconnect thread automatically logs <BR> you back in, if this kinda of thing was ok you would be better off with a full state machine that supported additional states like logging on an logging off in addition to logged on and logged off. <BR> <BR> example : e.g. start and stop in ThreadedSocketAcceptor i.e. in this case I'ed just ban stopping and starting at the same instant with a sync as<BR> the result would be a race at best anyway there are a few of
these, I haven't checked if it can happen in a real world scenario yet.<BR> <BR> <BR> Generally I try to avoid volatile (as its a very advanced technique).<BR> <BR> Session<BR> -------<BR> <BR> You've changed responder to volatile, I have a couple of points about this ...<BR> <BR> Instinctively I don't like this as you can never be 100 per cent sure its not null, i.e. in other bits of the code where it tests for null obviously another thread can immediately set it to null, which I don't think was possible before with the sync, as I can't find a real world example of this its not a show stopper but instinctively I wouldn't do it that way.<BR> <BR> The second point is a bit nastier and revolves around which version of the Java Memory Model we can guarantee the code will run against prior to JSR 133 (new Memoey
Model) which I believe was only full implemented with Java 1.5 using of volatile references was a bit dangerous,<BR> the issue being although the reference is volatile (can't be cached) so hasResponder is always ok , using the reference isn't ok i.e. there was no guarantee of unsynchronised writes prior to the volatile write being visible several books \ web sites cover this, obviously this was<BR> a bit of a flaw in the language so they fixed it (see the new memory model but if you want to support pre 1.5 (Java 5) then you have to be exteremely careful. If we were to just <BR> say 1.5 and above only we could use the read\write locks to do this better.<BR> <BR> Basically I avoid volatile references like the plague for this reason. <BR><BR> SessionConnector<BR> ----------------<BR> <BR> We definitely still have at least two threads
(the class creates its own thread) sharing a Map (the session member) which isn't threadsafe, the reference or the collection.<BR> Generally the advice is if a collection is shared it should be synchronized e.g. call the approprite Collections method or all methods that use it synchronized. Its not particularly likely to go wrong as it is I think (though it could) and there is always the danger some one<BR> would re jig this functionality at a later stage and provoke a bug.<BR> <BR> Nice to have : startSessionTimer should sync against stopSessionTimer .<BR> <BR> <BR> SingleThreadedEventHandlingStrategy<BR> ------------------------------------<BR> <BR> Change to ...<BR> <BR> private volatile long stopTime = 0L;<BR> <BR> This is actually correct ... however apparently their are a lot of pre 1.5 JVM's that
don't implement this correctly i.e. my understanding is that although the reference is guaranteed (if volatile) to point to a bit of memory with the right words in it, get and set operations are not guaranteed automic. For the less thread obsessive readers objects bigger than int<BR> e.g. long can be set read in two operations (not atomic) by the JVM (int's and smaller are guaranteed atomic) what this means is another thread can get in half way between a set or get operation and see gibberish (actually you can predict what it'll see). Note the code is strcitly correct it would be the JVM that would be wrong . in this case as declaring it volatile should have guaranteed atomic set / get unfortunately I'm led to believe this can happen (i.e. the thread forums have discussion on it) , the way round it is to put a sync in and avoid the issue (note other better solutions exist but
require certain versions of Java). A bug caused by this would be very rare but possible.<BR> <BR> Example : Banzai.java (Not sure if this is still current)<BR> -------------------------------------------------<BR> <BR> This is open to suprious thread wake up (gets worse with newer JVM's) basically this can just come out of the wait with no notify (see the JLS), i.e.you should never call wait when not in a loop, i.e. you shold set a boolean in the stop amd test for it in a loop round the following (haven't checked banzai to see if it has more user threads that could out live the first thread, but its still bad form as people often copy examples) ...<BR> <BR> synchronized (banzai) {<BR> banzai.wait();<BR>
}<BR> <BR> <BR>This appears in other tests as well (not sure if they'll be shipped) e.g. AtServer.java and others may have the same problem (I think).<BR> <BR><BR></P></DIV>
<DIV></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c6e5 2px solid; MARGIN-RIGHT: 0px"><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif">
<HR color=#a0c6e5 SIZE=1>
<DIV></DIV>From: <I>st...@te...</I><BR>Reply-To: <I>qui...@li...</I><BR>To: <I>qui...@li...</I><BR>Subject: <I>Re: [Quickfixj-users] Thread safety and MINA upgrade</I><BR>Date: <I>Wed, 20 Dec 2006 11:50:59 -0500 (EST)</I><BR>>QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<BR>>QuickFIX/J Support: http://www.quickfixj.org/support/<BR>>The SVN branch for the 1.0.x release is...<BR>><BR>>https://svn.sourceforge.net/svnroot/quickfixj/branches/QFJ_RELEASE_1_0_x<BR>><BR>>Steve<BR>><BR>> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<BR>> > QuickFIX/J Support: http://www.quickfixj.org/support/<BR>> > Hi Chris,<BR>> ><BR>> > I've committed the MINA 1.0.1 upgrade to the 1.0.x branch. I've
also<BR>> > modified several classes to improve thread safety. The good news was<BR>> > that primary message processing paths appeared to be in good shape.<BR>> > It was other access to the session state that might have caused some<BR>> > inter-thread visibility problems.<BR>> ><BR>> > My strategy was to fully encapsulate the SessionState within<BR>> > the Session and protect thread access to it via the Session. I didn't<BR>> > want to synchronize all methods on SessionState and/or make all the fields<BR>> > volatile because it would hurt performance unnecessarily. I've also made<BR>> > the SessionSchedule immutable and removed some object caching that it<BR>> > was doing. This was thread safe caching but could cause unnecessary<BR>> > synchronization between threads. I've also generally tried to minimize<BR>>
> any mutable state in the thread safe classes to make it easier to<BR>> > analyze (and because it's a good design practice anyway).<BR>> ><BR>> > All the public methods on Session are now either synchronized or refer to<BR>> > final or volatile fields. The extra synchronization is primarily for<BR>> > public session state getter methods that are for external use. I don't<BR>> > expect the internal session performance to be impacted.<BR>> ><BR>> > I've also refactored the initiator connection code (as you suggested).<BR>> > I've encapsulated most of the mutable state within the periodic<BR>> > connection management task and made the task thread safe.<BR>> ><BR>> > If you and others would like to review the changes, I'd appreciate it. The<BR>> > tests are all passing but I'd like a few more people to try it
before I do<BR>> > a 1.0.5 release.<BR>> ><BR>> > Thanks!<BR>> ><BR>> > Steve<BR>> ><BR>> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<BR>> >> QuickFIX/J Support: http://www.quickfixj.org/support/<BR>> >> <html><div style='background-color:'><DIV class=RTE><BR>> >> <P>Would it be possible to move forward a little mina lib wise, I've<BR>> >> moved<BR>> >> my personal copy of the source to 0.95 (obviously the newer the better I<BR>> >> see they are up to 1.01) with little effort (one small class change) and<BR>> >> I'm running tests now and all seems well, Java 1.4 &amp; 1.5.<BR><BR>I<BR>> >> was<BR>> >> trying to give myself a back out, in case we had the hung port issue<BR>> >> previously
listed by Christian (and listed as a bug fix against mina,<BR>> >> 0.95<BR>> >> has the necessary fix) we haven't seen this issue for a long time and<BR>> >> it'll be very hard to prove, reproduce, we intend to have a go. If I can<BR>> >> prove its there obviously I'll raise this as a proper bug , if we can<BR>> >> figure out a way to reliably reproduce it I'll try the new mina and<BR>> >> hopefully that will fix it but it is very rare at best.</P></DIV><BR>> >> <DIV></DIV></div><br clear=all><hr>It's Hotmail's 10th Birthday! Come<BR>> >> and<BR>> >> play <a href="http://g.msn.com/8HMBENUK/2728??PS=47575"<BR>> >> target="_top">Pass the Parcel</a> </html><BR>> >><BR>> >><BR>> >>
-------------------------------------------------------------------------<BR>> >> Take Surveys. Earn Cash. Influence the Future of IT<BR>> >> Join SourceForge.net's Techsay panel and you'll get the chance to share<BR>> >> your<BR>> >> opinions on IT & business topics through brief surveys - and earn cash<BR>> >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________<BR>> >> Quickfixj-users mailing list<BR>> >> Qui...@li...<BR>> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users<BR>> >><BR>> ><BR>> ><BR>> ><BR>> > -------------------------------------------------------------------------<BR>> > Take Surveys. Earn Cash. Influence the Future of IT<BR>> > Join
SourceForge.net's Techsay panel and you'll get the chance to share<BR>> > your<BR>> > opinions on IT & business topics through brief surveys - and earn cash<BR>> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV<BR>> > _______________________________________________<BR>> > Quickfixj-users mailing list<BR>> > Qui...@li...<BR>> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users<BR>> ><BR>><BR>><BR>><BR>>-------------------------------------------------------------------------<BR>>Take Surveys. Earn Cash. Influence the Future of IT<BR>>Join SourceForge.net's Techsay panel and you'll get the chance to share your<BR>>opinions on IT & business topics through brief surveys - and earn
cash<BR>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV<BR>>_______________________________________________<BR>>Quickfixj-users mailing list<BR>>Qui...@li...<BR>>https://lists.sourceforge.net/lists/listinfo/quickfixj-users<BR></FONT></BLOCKQUOTE></div><br clear=all><hr> <a href="http://g.msn.com/8HMBENUS/2752??PS=47575" target="_top">Type your favorite song. Get a customized station. Try MSN Radio powered by Pandora.</a> </html>
|
|
From: Steve B. <st...@te...> - 2006-12-21 13:46:40
|
Hi Toli, I've been working on JMX MBeans and supporting code for QFJ. It's not complete yet, but I've gone ahead and committed what I currently have into SVN. It's in the org.quickfixj.jmx package in the trunk. I have JMX instrumented versions of Banzai and the order executor, but they aren't committed yet. I'll be adding those very soon. See the org.quickfixj.jmx.mbean package for MBeans for managing Sessions, acceptor and initiator endpoints, and a generic MBean for collecting and providing QFJ and application statistics. You need have the MX4J library in your classpath for Java 1.4. For Java 5+ you shouldn't need any extra libraries. The org.quickfixj.jmx.JmxExporter class is what you'd use to export an acceptor or connector as a collection of JMX MBeans. If you like to help with this, that would be great. I'll let everybody know when the examples have been committed. Regards, Steve > -----Original Message----- > From: qui...@li... [mailto:quickfixj- > use...@li...] On Behalf Of Toli Kuznets > Sent: Wednesday, December 20, 2006 8:28 PM > To: qui...@li... > Subject: [Quickfixj-users] Adding JMX visibility to QuickfixJ > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Steve and others, > > the QuickfixJ wiki page at > http://www.quickfixj.org/confluence/display/qfj/JMX%2BInstrumentation > lists a few goals for implementing JMX. > > We'd like to add some more visibility to our QuickfixJ connections in > our app through JMX, so i was thinking of adding a few MBeans to > quickfixj to show some basic stuff to begin with: whether or not it's > logged on, and the sender/targetCompID. > > Steve, any suggestions on the best way to start integrating that? > Ideally, i'd have some QuickfixJ object implement an MBean interface > to expose those 3 values, and my app will be able to export that to > JMX as well. > > i'd be happy to take the first crack at exposing that, and have others > review and add to that later. > > any other thoughts? any other approaches someone would recommend? > > -- > Toli Kuznets > http://www.marketcetera.com: Open-Source Trading Platform > download.run.trade. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Toli K. <to...@ma...> - 2006-12-21 01:29:01
|
Steve and others, the QuickfixJ wiki page at http://www.quickfixj.org/confluence/display/qfj/JMX%2BInstrumentation lists a few goals for implementing JMX. We'd like to add some more visibility to our QuickfixJ connections in our app through JMX, so i was thinking of adding a few MBeans to quickfixj to show some basic stuff to begin with: whether or not it's logged on, and the sender/targetCompID. Steve, any suggestions on the best way to start integrating that? Ideally, i'd have some QuickfixJ object implement an MBean interface to expose those 3 values, and my app will be able to export that to JMX as well. i'd be happy to take the first crack at exposing that, and have others review and add to that later. any other thoughts? any other approaches someone would recommend? -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: <st...@te...> - 2006-12-20 16:51:12
|
The SVN branch for the 1.0.x release is... https://svn.sourceforge.net/svnroot/quickfixj/branches/QFJ_RELEASE_1_0_x Steve > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Hi Chris, > > I've committed the MINA 1.0.1 upgrade to the 1.0.x branch. I've also > modified several classes to improve thread safety. The good news was > that primary message processing paths appeared to be in good shape. > It was other access to the session state that might have caused some > inter-thread visibility problems. > > My strategy was to fully encapsulate the SessionState within > the Session and protect thread access to it via the Session. I didn't > want to synchronize all methods on SessionState and/or make all the fields > volatile because it would hurt performance unnecessarily. I've also made > the SessionSchedule immutable and removed some object caching that it > was doing. This was thread safe caching but could cause unnecessary > synchronization between threads. I've also generally tried to minimize > any mutable state in the thread safe classes to make it easier to > analyze (and because it's a good design practice anyway). > > All the public methods on Session are now either synchronized or refer to > final or volatile fields. The extra synchronization is primarily for > public session state getter methods that are for external use. I don't > expect the internal session performance to be impacted. > > I've also refactored the initiator connection code (as you suggested). > I've encapsulated most of the mutable state within the periodic > connection management task and made the task thread safe. > > If you and others would like to review the changes, I'd appreciate it. The > tests are all passing but I'd like a few more people to try it before I do > a 1.0.5 release. > > Thanks! > > Steve > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> <html><div style='background-color:'><DIV class=RTE> >> <P>Would it be possible to move forward a little mina lib wise, I've >> moved >> my personal copy of the source to 0.95 (obviously the newer the better I >> see they are up to 1.01) with little effort (one small class change) and >> I'm running tests now and all seems well, Java 1.4 & 1.5.<BR><BR>I >> was >> trying to give myself a back out, in case we had the hung port issue >> previously listed by Christian (and listed as a bug fix against mina, >> 0.95 >> has the necessary fix) we haven't seen this issue for a long time and >> it'll be very hard to prove, reproduce, we intend to have a go. If I can >> prove its there obviously I'll raise this as a proper bug , if we can >> figure out a way to reliably reproduce it I'll try the new mina and >> hopefully that will fix it but it is very rare at best.</P></DIV> >> <DIV></DIV></div><br clear=all><hr>It's Hotmail's 10th Birthday! Come >> and >> play <a href="http://g.msn.com/8HMBENUK/2728??PS=47575" >> target="_top">Pass the Parcel</a> </html> >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
|
From: <st...@te...> - 2006-12-20 15:54:07
|
Hi Chris, I've committed the MINA 1.0.1 upgrade to the 1.0.x branch. I've also modified several classes to improve thread safety. The good news was that primary message processing paths appeared to be in good shape. It was other access to the session state that might have caused some inter-thread visibility problems. My strategy was to fully encapsulate the SessionState within the Session and protect thread access to it via the Session. I didn't want to synchronize all methods on SessionState and/or make all the fields volatile because it would hurt performance unnecessarily. I've also made the SessionSchedule immutable and removed some object caching that it was doing. This was thread safe caching but could cause unnecessary synchronization between threads. I've also generally tried to minimize any mutable state in the thread safe classes to make it easier to analyze (and because it's a good design practice anyway). All the public methods on Session are now either synchronized or refer to final or volatile fields. The extra synchronization is primarily for public session state getter methods that are for external use. I don't expect the internal session performance to be impacted. I've also refactored the initiator connection code (as you suggested). I've encapsulated most of the mutable state within the periodic connection management task and made the task thread safe. If you and others would like to review the changes, I'd appreciate it. The tests are all passing but I'd like a few more people to try it before I do a 1.0.5 release. Thanks! Steve > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > <html><div style='background-color:'><DIV class=RTE> > <P>Would it be possible to move forward a little mina lib wise, I've moved > my personal copy of the source to 0.95 (obviously the newer the better I > see they are up to 1.01) with little effort (one small class change) and > I'm running tests now and all seems well, Java 1.4 & 1.5.<BR><BR>I was > trying to give myself a back out, in case we had the hung port issue > previously listed by Christian (and listed as a bug fix against mina, 0.95 > has the necessary fix) we haven't seen this issue for a long time and > it'll be very hard to prove, reproduce, we intend to have a go. If I can > prove its there obviously I'll raise this as a proper bug , if we can > figure out a way to reliably reproduce it I'll try the new mina and > hopefully that will fix it but it is very rare at best.</P></DIV> > <DIV></DIV></div><br clear=all><hr>It's Hotmail's 10th Birthday! Come and > play <a href="http://g.msn.com/8HMBENUK/2728??PS=47575" > target="_top">Pass the Parcel</a> </html> > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
103 messages has been excluded from this view by a project administrator.
