ALL

Updated version of the document following feedback.

Committed in Rev#1041.
A new setting has been added: EnableNextExpectedMsgSeqNum
By default,set to false. When set to true, the field 789 is sent on the logon message.

Hi,

I don't think this issue is resolved, can we change the status.

I supplied a fully tested 789 implementation all we've done in the released implementation is set to the 789 (which could have been added to a QFJ client application) to the next expected sequence number but the current implementation can't cope with any implicit resend or 789 being sent back in the logon response. Any performance benefits of 789 are lost.

The issue is you can't add this on top of QuickFIX this has to go into the core fix engine so I'm forced to branch QFJ.

I tried 1.5.1 with a sever that supports 789 and it actually failed to recover a session with the tag on (not sure why yet I'll have to dig). The server responded to the implicit logon but QFJ are requested an unnecessary resend.

Code changes requited.

Just proposed a small change that would push things forward just a little bit:

http://www.quickfixj.org/jira/browse/QFJ-705

Chris,

If you could comment on it, it would be great. (We're trying to connect to your MAPI engine with QuickFIX/J.)

Hi,

I would suggest the ideal solution was to fully support 789 (albeit optionally), I supplied a fully working solution all scenarios supported / scenario tested and soak tested against (1.5.0).
For reasons I'm not aware of, my solution wasn't used and a less than complete simplistic solution was added in its place (personally I would have suggested all or nothing was the better option in general).
As 789 functionality was added in the version I expected it to be, I assumed it was fully compliant until I later had time to inspect the code.
The less than full solution in a way complicates the problem in that we have to extend our test cases to partial support of 789.

As 789 is incomplete and required by us I had to do a less than trivial merge for 1.5.2 to enable my internal branch to work correctly again.

If you look at the code I originally submitted you can see the work I did on 1.5.0 nextLogon to compare and contrast with the suggested changes.

Chris

hi,
so I think we should do the complete solution in QFJ-705
Do you agree?
cheers
Christoph

Hi,

I proposed the yet another partial solution under QFJ-705 because of the already taken incremental approach. And those 2 proposed lines of code seem to sort out our use case, in our tests.

The fact that this QFJ-567 was marked as fixed is a bit surprising, because it wasn't. At least someone could have commented on the reasons why only a fraction of the proposed solution was used.

I agree that the full solution proposed here would be best, although it will require additional work now.

Regards,
Andrzej

Hi,
First I suggest the initial closed report is re-opened ASAP as it holds useful detail and would preclude opening of new reports on the same issue.

I still think the full solution is the simplest. We're in a strong position to test this at the moment; that may not be the case in the future as it requires I can shadow the current builds and have access to the same test resources.

If we extend the existing acceptance scenarios in the existing 789 tests to all the scenarios in the original document we uploaded we should have full acceptance coverage.
Those scenarios were tested by hand and sanity checked between two 789 compliant engines (one QFJ 1.5.0).

I currently have a version of QF/J with my 789 changes, which I can soak test against another compliant FIX engine for increased confidence.

Obviously 789 is optional by (default) configuration so we should have no harms.
As 789 is optional and not used by default, some additional no-harms tests will be required to prove interoperability

Chris

Hi,

I agree with CH - QFJ-705 is not meant to replace QFJ-567. It is meant as a little step towards proper implementation of this QFJ-567.

The two line chane I proposed will not provide the full support for tag 789. This QFJ-567 is the best place to register and discuss the 789 support as such.

In fact it would be better to close QFJ-705 and resurrect this QFJ-567, as it was incorrectly marked as fixed in the past.

Regards,
Andrzej

BTW:

I wouldn't ignore Christopher's offer to test the full change. As far as I'm aware he's already got a production version of his COMPLETE fix running.

(Especially after he was being ignored since March .

Andrzej

Agreed.

Hi,

We have the requirement to support this behaviour on logon for MAPI.
Is there a tested patch that can be applied to Quickfix 1.5.2 - if not, what are other people doing? When is 1.5.3 due?

Thanks

Gemma

We plan to release end of October/beginning of November.

Committed as rev #1094. Thanks to Christopher Hurst for suggested patch against 1.5.0 and doing quite some tests.