search

kpavlov / fixio

FIX Protocol Support for Netty
Apache License 2.0
103 stars 48 forks source link

Feature requests/questions #19

Open guidomedina opened 9 years ago

guidomedina commented 9 years ago

What happens when the connection is lost? Do I get an exception from FixApplicationAdapter in the following method?

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
        LOGGER.error("Uncaught application exception.", cause);
        ctx.close().sync();
    }

QuickFixJ has a retry mechanism when the connection is lost but I'm unsure there is one here, if there isn't I will probably retry myself with my own rate limiter.

Another question not related, will you give a name to the project with something more searchable? Maybe you can create a small user's list for questions @reactivefix or @netty-fix -suggestions-

As for Maven project maybe group ID something like io.fix

kpavlov commented 9 years ago

Currently there is no retry/reconnect/resend mechanism, like in QuickFixJ and this is one of limitation of the framework.

On disconnects now you'll get directly to fixio.netty.pipeline.AbstractSessionHandler#channelInactive so it's impossible to distingush expected and not expected disconnects to handle them on FixApplicationAdapter. I think the new DisconnectEvent extends AbstractAdminEvent should be added fired when disconnect is not expected. I can add this.

Sure, I'll rename a project, it's time

guidomedina commented 9 years ago

About disconnects, for the moment I think I can live with that, it is unlikely that in a production system fix connections will just drop out of the blue, but one must code for all possible scenarios, I experimented today with channelInactive by logging a message but got none, at least on the FixClient side.

On the FixServer what would be ideal is to detect that the connection for a session has dropped and be able to close such session via some event, I'm seriously trying to avoid using QuickFixJ since I find it too cluttered and complex with very old code, I like Fix IO because it is simple and based on Netty.

Suffice to say why I recommended you to rename the project so that we get more contributions.

_Question:_ Do you have case studies even for small companies that are using Fix IO? I checked LinkedIn and noticed you have a vast experience with Trading systems but I'm not completely sure you were able to push Fix IO framework into existing production environments, my current project which I'm developing from scratch was using QuickFixJ but I migrated to Fix IO and haven't found any issues, it is very easy and its simplicity bought me already, except for the mentioned issues.

I also noticed there are no timers for heartbeat sent by the client or server but not a biggy, I prefer to use Akka scheduler which will make them part of a big sub-system, I haven't implemented the FixServer part so I'm guessing it will be easy for me to find the right place to send a heartbit message per session connected to the server every 30 seconds so I'm not asking that question yet, to see if I can figure it out, surely like I said it will be easy to find the right place.