diff3.txt
[QFJ-521] Support use of partial session ID for routing purposes Created: 10/May/10 Updated: 09/Jun/11 |
|
| Status: | Reopened |
| Project: | QuickFIX/J |
| Component/s: | Engine |
| Affects Version/s: | 1.3.1, 1.3.2, 1.3.3, 1.4.0 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Default |
| Reporter: | Rhys Yarranton | Assignee: | Grant Birchmeier |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Attachments: |
diff3.txt
|
| Description |
|
In 1.2.1 and below, MessageUtils.getReverseSessionID included only the comp IDs, not the sub-IDs and SenderLocationID. This breaks us in two ways. One is that we have been configuring our sessions by the comp IDs, which works well with the 1.2.1 code but mismatches with the 1.3.1+ code even if both sides get all their IDs right. The other, and more important, is that several of our customer gateways will vary the SenderSubID and/or TargetSubID. For example, the FIX spec describes SenderSubID as being useful to distinguish between traders, and that messages not intended for a particular trader may optionally be flagged as ADMIN. It seems to me that the changes in Fortunately there is a mechanism to provide your own AcceptorSessionProvider, which can be used to work around this issue. That said, the default behaviour is not ideal. Attached is a patch to replace StaticAcceptorSessionProvider with a new class, DefaultAcceptorProvider, which first tries a "strict" 1.3.1-style lookup, and if it fails, tries a 1.2.1-style lookup based on the Comp IDs only. If the maintainers have an objection to the patch, I would suggest at the least that something like DefaultAcceptorProvider (plus instructions) be included in the distribution for those who cannot use StaticAcceptorSessionProvider. |
| Comments |
| Comment by Steve Bate [ 10/May/10 ] |
|
The specifications include subID and locationID in information such as DeliverTo and OnBehalfOf, which are used for session routing. A route endpoint in this case is identified by CompID/SubID/LocationID in the originator sessionID and in the third-party routing cases. As you mentioned, I have seen the specification describe senderSubID as being useful to distinquish between traders, but this appears to me to still be in the context of message routing to a specific trader (or trading desk) within a broader organization (represented by the compID). Every counterparty I've worked with that used subIDs have used them for session identification and routing. That said, from what I've seen on the FPL forums there was confusion in FIX 4.2 and before about the use of session ID fields for non-routing purposes. In FIX 4.3 and later, the Parties component is recommended for identifying traders outside the context of message routing. I'm not the only one making the decision, but I'm open to to a feature that optionally ignores parts of the session ID for routing purposes. |
| Comment by Grant Birchmeier [ 19/Jul/10 ] |
|
I am having similar issues as Rhys. While reading the 4.4 spec to puzzle out my issues, I could not find where it says that SubID and LocationID should be used for anything substantial, let alone for message routing or session identification. Like Rhys, I'm not sure For now I'm integrating Rhys' patch into our local QF/J build, and being able to ignore the |
| Comment by Grant Birchmeier [ 19/Jul/10 ] |
|
To integrate this patch into r958, DefaultAcceptorSessionProvider::getSession() needs a slight update to match an updated AcceptorSessionProvider interface:
|
| Comment by Grant Birchmeier [ 12/Apr/11 ] |
|
Committed to 1015 |
| Comment by Jörg Thönnes [ 09/Jun/11 ] |
|
Re-opening the issue to document the changes introduced IMHO, the handling of sub IDs and location IDs in QF/J deserves an extra section in the manual. There was some |