Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature requests/questions #19

Open
guidomedina opened this issue Mar 10, 2015 · 2 comments
Open

Feature requests/questions #19

guidomedina opened this issue Mar 10, 2015 · 2 comments

Comments

@guidomedina
Copy link

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
Copy link
Owner

kpavlov commented Mar 11, 2015

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants