Menu
▾
▴
quickfixj-users
|
From: <Zol...@ss...> - 2006-11-30 19:49:46
|
Hello, Can someone tell me how I can see if a session is logged on from an Application? For some reason in my acceptor application Session.isLoggedOn() is not updating when the initiator disconnects. A line of code for this would be great. My application sends IOIs when an initiator logs on. I have a loop that's entered from onLogon(). At this point I would like my acceptor to send IOIs until the initiator logs off but I can't capture the logoff event. Your help is appreciated. Thank you, Zoltan |
|
From: Chris H. <chr...@ho...> - 2006-12-04 18:00:26
|
<html><div style='background-color:'><DIV class=RTE>Hi,</DIV>
<DIV class=RTE> Following Zoltan's mail something that has been concerning me is how thread safe the QuickFix libs are ???<BR> <BR> e.g. Session appears to have some thread safety but no comment on which parts are safe and not, normally if this was intended the class would be split in two and one class the thread safe derived from the other. I appreciate the minalibs appear thread safe but that doesn't necessarily make the code above it ok.<BR> <BR> I'm referring mainly to the setting of non volatile variables that appear to be used by more than one thread (this happens a lot), I appreciate this may be controlled by a synchronized class / layer I have identified yet, sorry I'm still quite new to<BR> the Quick lib's and there is a lot of code to trawl through it may be I missed something but I think at the very least wecould do with
some comments on what is thread safe or not.<BR> <BR> Looking at Zoltan's scenario posted (I'm not saying this is his problem i.e. he may have some completely unrelated problem and this could still be an issue), I'm just using his description of how he uses the code, to illustrate my point and providing a possible explanation for it.<BR> <BR> ... now in session next() will be called from whatever (mina?)threading stategy he uses\chooses (i.e. at least one other thread if not many) and eventually the true state of the session will be guaranteed to be written back to main memory (i.e memory barrier hit) by exiting<BR> the synchronized method (session state itself is not thread safe, perhaps a comment to that effect would be useful) ... but he is almost certainly using another thread e.g. the main one (e.g. code called from the java main method) to
poll is loggedOn in session but that isn't thread safe as is most of the public setter / getters i.e. unless his polling logged on involves a sync lock of some <BR> form (memory barrier) the JVM NEVER has to give him the real value written by the other thread i.e. one thread sees false the other sees true surely, though obviously this is JVM / OS / number of CPU whatever dependent (and indeed dependent on how the bespoke <BR> FIX application uses these method (i.e. does its synchronization)) i.e. it might work it might not.<BR> <BR> // assume you have a session variable you want to know is logged off<BR> <BR> /*<BR> Very bad ugly fix, that might work (untested \ compiled example for user code), which if it worked should be replaced with a QuickFix lib change<BR> */<BR> Object = new Object ();<BR>
boolean isLoggedOn = true;<BR> do<BR> {<BR> // force a memory barrier (Not recomended) i.e. I'm not using the sync as a lock but as</DIV>
<DIV class=RTE> // thread cache flush<BR> synchronized (obj) { isLoggedOn = session.isLoggedOn (); }<BR> }<BR> while (isLoggedOn); // exit when logged off<BR> <BR> <BR> (Note the lock I'm releasing isn't the one released in the one in session and the formal JVM Memory Model describes releasing\acquiring the same lock usually, i.e.<BR> what I've written is a very dirty hack.... )<BR> <BR> <BR> I've got a lot more thoughts concerns on this but I'll keep this short in case some one has spotted an obvious flaw in my initial observations (its happened before :-) ),<BR> at the very least some informative comments could be added to the code to point out what I've missed.<BR> <BR> (PS if anyone has an explanation for why getResponder is synchronized and setResponder isn't ...
)</DIV></div><br clear=all><hr>Be the first to hear what's new at MSN - <a href="http://g.msn.com/8HMBENUK/2740??PS=47575" target="_top">sign up to our free newsletters!</a> </html>
|
|
From: Steve B. <st...@te...> - 2006-12-05 04:27:52
|
Chris, I think that the QFJ source code needs to be reviewed in the context of multithreaded (or more specifically, multiprocessor) execution and the Java Memory Model. Would you be willing to help with that, even if it's just another set of eyes on the problem? Regards, Steve |
|
From: Joerg T. <Joe...@ma...> - 2006-12-05 10:23:08
|
Hi Steve,
> I think that the QFJ source code needs to be reviewed in the context
> of multithreaded (or more specifically, multiprocessor) execution
> and the Java Memory Model. Would you be willing to help with that,
> even if it's just another set of eyes on the problem?
You made a good point. Actually, missing memory barriers may introduce ha=
rdly to catch errors.
For long time already, I have the feeling that the state machine would pr=
ofit from some sort of the=20
state pattern. The actual state could then protected by synchronized meth=
ods to be propagated to all=20
processor caches.
Another idea would be to use the concurrent library of Doug Lea (java.con=
current nowadays).=20
Hopefully, this would not add to much overhead. Oren is already very keen=
to keep QuickFIX "small=20
and beautiful."
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: Alvin W. <AW...@FF...> - 2006-12-05 15:55:01
|
Maybe this state management framework is of interest to your guys. http://www.openwfe.org/ = =20 Joerg Thoennes = =20 <Joerg.Thoennes@m = =20 acd.com> To= =20 Sent by: qui...@li....n= =20 quickfixj-users-b et = =20 ou...@li... cc= =20 ceforge.net = =20 Subject= =20 Re: [Quickfixj-users] SessionStatus= =20 12/05/2006 05:22 question = =20 AM = =20 = =20 = =20 Please respond to = =20 quickfixj-users@l = =20 ists.sourceforge. = =20 net = =20 = =20 = =20 QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Steve, > I think that the QFJ source code needs to be reviewed in the context > of multithreaded (or more specifically, multiprocessor) execution > and the Java Memory Model. Would you be willing to help with that, > even if it's just another set of eyes on the problem? You made a good point. Actually, missing memory barriers may introduce hardly to catch errors. For long time already, I have the feeling that the state machine would profit from some sort of the state pattern. The actual state could then protected by synchronized methods to be propagated to all processor caches. Another idea would be to use the concurrent library of Doug Lea (java.concurrent nowadays). Hopefully, this would not add to much overhead. Oren is already very keen to keep QuickFIX "small and beautiful." Cheers, J=F6rg -- 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 ------------------------------------------------------------------------- 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=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV _______________________________________________ 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=20 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. ***************************************************************************= **** |
Thanks for helping keep SourceForge clean.
X