RE: [Quickfix-developers] [qfj] move to MINA?

[Steve B. <sb...@sm...>]

Barry Kaplan had been working on a MINA initiator and acceptor. He's
recently started a
new job and is very busy so the work has stalled. We haven't put the code
into the quickfixj
repository because it's still very experimental. However, if some other
people are seriously
interested in working on it (I don't have some at the moment), maybe I could
create a 
MINA-related branch and add the experimental code there for people to work
on.
 
If we create a MINA initiator and acceptor I'd suggest removing the
poll/block methods
from the classic initiator/acceptor pair. My understanding is they are
intended for single
threaded applications. However, no Java application is truly single threaded
and most
networking application are multithreaded in the Java world.
 
What does everyone think about this? I've noticed a few posts that imply
that some
people are using block and/or poll with Java. I'm interested in hearing what
benefit
people are getting from those methods (since they don't really reduce the
number
of threads in pure Java implementation).
 
Steve Bate
Smart Trade Technologies
Phone: +33 4 42 90 03 97
http://www.smart-trade.net/
 


  _____  

From: qui...@li...
[mailto:qui...@li...] On Behalf Of Ian
Johnson
Sent: Thursday, December 01, 2005 5:44 PM
To: qui...@li...
Subject: [Quickfix-developers] [qfj] Hexdumps under Netty2 1.8.0, move to
MINA?


Hi,
 
Definitely a vote for this. My requirement is for better latency management
and embedded SSL - both of which can be done fairly easily in MINA (or so it
says). If you have a MINA version of the Initiatior and FIXMessage I would
definitely be interested.
 
Any change of posting the changes?
 
I was also seeing buffer underflow issues until I patched the parsing code
(I see thats changed recently, but I haven't examnined the changes)
 
My requirements is for latency rather than high throughput (FX arbitrage
where most of what matters is latency)
 
Good work chaps
 
Ian