quickfixj-users — General mailing list for QuickFIX/J topics.

Re: [Quickfixj-users] Quickfix Java Throttle limit

[Christoph J. <chr...@ma...>]

Hi,

please always reply to the group. Other users might have the same problem/question now or in the future.

For incoming messages you can pass a high and a low watermark queue limit when constructing your 
connector.
If the high limit is reached the reads from the socket will be suspended and if the low limit is 
reached, reads from the socket will be resumed. Of course if the socket buffer will overflow the 
connection could be terminated.

Example:
ThreadedSocketAcceptor.newBuilder()
                                      .withApplication( acceptorApplication )
                                      .withMessageStoreFactory( messageStoreFactory )
                                      .withSettings( settings )
                                      .withLogFactory( fileLog )
                                      .withMessageFactory( messageFactory )
                                      .withQueueWatermarks( LOW_WATERMARK, HIGH_WATERMARK ).build();

For outgoing messages there is the setting MaxScheduledWriteRequests. 
https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html
If there are more than the configured write requests, the session is disconnected. So this is no 
real throttling per se but does the trick in most cases.

Cheers,
Chris.



On 26.07.21 16:36, Ajit Gautam wrote:
> Hi Chris,
>
> I want limit for incoming message.
>
> It would be good to know if outgoing stream also has some configuration throttle limit.
>
>
> Regards
> Ajit Gautam
>
> On Mon, Jul 26, 2021, 16:44 Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi,
>
>     for incoming or outgoing messages??
>
>     Cheers,
>     Chris.
>
>     On 26.07.21 13:11, Ajit Gautam wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/  <http://www.quickfixj.org/documentation/>
>>     QuickFIX/J Support:http://www.quickfixj.org/support/  <http://www.quickfixj.org/support/>
>>
>>
>>
>>     Hi,
>>
>>     Is there any configuration available for setting the throttle limit in Quickfix Java?
>>
>>     Also, is there any max throttle limit in Quickfix Java.
>>
>>     Regards
>>     Ajit Gautam
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Quickfix Java Throttle limit

[Christoph J. <chr...@ma...>]

Hi,

for incoming or outgoing messages??

Cheers,
Chris.

On 26.07.21 13:11, Ajit Gautam wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> Is there any configuration available for setting the throttle limit in Quickfix Java?
>
> Also, is there any max throttle limit in Quickfix Java.
>
> Regards
> Ajit Gautam
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

[Quickfixj-users] Quickfix Java Throttle limit

[Ajit G. <aji...@gm...>]

Hi,

Is there any configuration available for setting the throttle limit in
Quickfix Java?

Also, is there any max throttle limit in Quickfix Java.

Regards
Ajit Gautam

Re: [Quickfixj-users] SuppressRejects=Y

[Christoph J. <chr...@ma...>]

 I don't know. Where did you get that from? This is not a supported configuration. I couldn't even find it for other QuickFIX variants. 

Cheers
Chris. 

Am 15. Juli 2021 22:19:09 MESZ schrieb ak jh <ak...@gm...>:
>QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>What does this configuration do ?
>
>
>_______________________________________________
>Quickfixj-users mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfixj-users

[Quickfixj-users] SuppressRejects=Y

[ak jh <ak...@gm...>]

What does this configuration do ?

Re: [Quickfixj-users] Support for XMLNonFIX message(35=n)

[Christoph J. <chr...@ma...>]

I've never used that kind of message type but don't know why it shouldn't be possible. What did you try so far? Were there errors?

Cheers
Chris. 

Am 1. Juli 2021 17:58:14 MESZ schrieb Gaurav Kumar <kum...@gm...>:
>QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>QuickFIX/J Support: http://www.quickfixj.org/support/

[Quickfixj-users] Support for XMLNonFIX message(35=n)

[Gaurav K. <kum...@gm...>]

Hi Team

We need to create a drop copy session with exchange CME but CME drop copy
4.0 session does not provide execution report message (35=8) directly
instead it encapsulates execution report in  (XML_Non_FIX)  *35=n* message
containing the actual business message as a payload.

Is there any support available in quickfixj to process 35=n message,
extract the payload and process it.

I am using quickfixj 2.2.0
-- 
Regards
Gaurav

Re: [Quickfixj-users] QuickFIX - Query on multi tenant support

[Christoph J. <chr...@ma...>]

Hi Sumanth,

this is nothing QuickFIX specific. Rather this is specific to the FIX protocol. QuickFIX is only one 
of many engines implementing the FIX protocol.

You can read more about it here: https://www.fixtrading.org/standards/ and especially here 
https://www.fixtrading.org/standards/fix-session-layer-online/#fix-session

Quote: "A FIX session is a bidirectional stream of ordered messages between two peers within a 
continuous sequence number series beginning with 1. A single FIX session can exist across multiple 
sequential (not concurrent) FIX connections, which means that peers may intentionally or 
unintentionally connect and disconnect multiple times while maintaining a single FIX session. The 
FIX session can be thought of as a bi-directional durable session sharing characteristics of the 
guaranteed delivery and durable subscriber enterprise integration architecture patterns."

Hope that helps.
Cheers,
Chris.

On 15.06.21 06:39, krishna sumanth Rachamadugu wrote:
> Hi Chris,
>
> Thanks for clarifying.
>
> I didn't understand the concept of LogOn and LogOut in QuickFIX clearly from documentation. 
> Although we had started the connection with initiator.start, which will help us to determine 
> whether a session connection has been established or not, in which context LogOn and LogOut will 
> help us?
>
> Why and when an initiator / acceptor will do this operation.
>
> I'm under the impression that even though an initiator/acceptor does LogOut, the session 
> associated with the acceptor/initiator will still be alive but the connection established with 
> that session will be closed.
>
> Thanks,
> Sumanth.
>
> On Tue, Jun 15, 2021 at 3:53 AM Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi Sumanth,
>
>     if you have your message store on some shared medium (e.g. a data base or distributed file
>     system) you could have several acceptors for the same SessionID, albeit only one of them must
>     be active at any time. Actually this would work out of the box given that the connection will
>     only be tried against one of the acceptors at the same time.
>     I have to admit that there might be cases (due to network timeouts for example) when the
>     counterparty already tries to connect against another node while the connection still seems
>     active for the original node. This could then of course lead to a corruption or inconsistency
>     of the store. So you might be better off if your application implemented a more robust way of
>     determining the active node.
>     See also https://www.quickfixj.org/usermanual/2.3.0/usage/acceptor_failover.html
>     <https://www.quickfixj.org/usermanual/2.3.0/usage/acceptor_failover.html>
>
>     When you're all set, the configuration "RefreshOnLogon=Y" will cause to reload the message
>     store from the shared medium on the next logon so that the active connector can continue where
>     the now inactive connector left off.
>
>     Hope that helps.
>     Cheers,
>     Chris.
>
>
>     On 14.06.21 20:41, krishna sumanth Rachamadugu wrote:
>>     Hi Chris,
>>
>>     Here, I'm trying to achieve the availability. Lets say, if the machine which is running
>>     QuickFIX Engine went down, We won't be able to communicate with other parties until we bring
>>     it up.
>>
>>     Thanks,
>>     Sumanth.
>>
>>     On Mon, Jun 14, 2021 at 3:42 PM Christoph John <chr...@ma...
>>     <mailto:chr...@ma...>> wrote:
>>
>>         Hi,
>>
>>         a FIX Session is more or less a point-to-point connection. That means the same SessionID
>>         cannot be active on two different machines at the same time. The message store (with
>>         sequence numbers and messages) should be accessed exclusively by one connector.
>>
>>         Let me ask this way: what do you want to achieve? You could of course set up separate
>>         Sessions that access the same order management system for example.
>>
>>         Cheers,
>>         Chris.
>>
>>
>>         On 14.06.21 07:32, krishna sumanth Rachamadugu wrote:
>>>         QuickFIX/J Documentation:http://www.quickfixj.org/documentation/  <http://www.quickfixj.org/documentation/>
>>>         QuickFIX/J Support:http://www.quickfixj.org/support/  <http://www.quickfixj.org/support/>
>>>
>>>
>>>
>>>         Hi,
>>>
>>>         I'm new to FIX. I understood that it works on message sequence numbers and felt a more
>>>         tightly coupled way of communication between two parties.
>>>
>>>         1. Can we have a number of acceptors/initiators with the same session id running on two
>>>         different machines?. To be more precise, does it support multi-tenant systems?
>>>
>>>
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] QuickFIX - Query on multi tenant support

[krishna s. R. <won...@gm...>]

 Hi Chris,

Thanks for clarifying.

I didn't understand the concept of LogOn and LogOut in QuickFIX clearly
from documentation. Although we had started the connection with
initiator.start, which will help us to determine whether a session
connection has been established or not, in which context LogOn and LogOut
will help us?

Why and when an initiator / acceptor will do this operation.

I'm under the impression that even though an initiator/acceptor does
LogOut, the session associated with the acceptor/initiator will still be
alive but the connection established with that session will be closed.

Thanks,
Sumanth.

On Tue, Jun 15, 2021 at 3:53 AM Christoph John <chr...@ma...>
wrote:

> Hi Sumanth,
>
> if you have your message store on some shared medium (e.g. a data base or
> distributed file system) you could have several acceptors for the same
> SessionID, albeit only one of them must be active at any time. Actually
> this would work out of the box given that the connection will only be tried
> against one of the acceptors at the same time.
> I have to admit that there might be cases (due to network timeouts for
> example) when the counterparty already tries to connect against another
> node while the connection still seems active for the original node. This
> could then of course lead to a corruption or inconsistency of the store. So
> you might be better off if your application implemented a more robust way
> of determining the active node.
> See also
> https://www.quickfixj.org/usermanual/2.3.0/usage/acceptor_failover.html
>
> When you're all set, the configuration "RefreshOnLogon=Y" will cause to
> reload the message store from the shared medium on the next logon so that
> the active connector can continue where the now inactive connector left off.
>
> Hope that helps.
> Cheers,
> Chris.
>
>
> On 14.06.21 20:41, krishna sumanth Rachamadugu wrote:
>
> Hi Chris,
>
> Here, I'm trying to achieve the availability. Lets say, if the machine
> which is running QuickFIX Engine went down, We won't be able to communicate
> with other parties until we bring it up.
>
> Thanks,
> Sumanth.
>
> On Mon, Jun 14, 2021 at 3:42 PM Christoph John <chr...@ma...>
> wrote:
>
>> Hi,
>>
>> a FIX Session is more or less a point-to-point connection. That means the
>> same SessionID cannot be active on two different machines at the same time.
>> The message store (with sequence numbers and messages) should be accessed
>> exclusively by one connector.
>>
>> Let me ask this way: what do you want to achieve? You could of course set
>> up separate Sessions that access the same order management system for
>> example.
>>
>> Cheers,
>> Chris.
>>
>>
>> On 14.06.21 07:32, krishna sumanth Rachamadugu wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi,
>>
>> I'm new to FIX. I understood that it works on message sequence numbers
>> and felt a more tightly coupled way of communication between two parties.
>>
>> 1. Can we have a number of acceptors/initiators with the same session id
>> running on two different machines?. To be more precise, does it support
>> multi-tenant systems?
>>
>>
>>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Re: [Quickfixj-users] QuickFIX - Query on multi tenant support

[Christoph J. <chr...@ma...>]

Hi Sumanth,

if you have your message store on some shared medium (e.g. a data base or distributed file system) 
you could have several acceptors for the same SessionID, albeit only one of them must be active at 
any time. Actually this would work out of the box given that the connection will only be tried 
against one of the acceptors at the same time.
I have to admit that there might be cases (due to network timeouts for example) when the 
counterparty already tries to connect against another node while the connection still seems active 
for the original node. This could then of course lead to a corruption or inconsistency of the store. 
So you might be better off if your application implemented a more robust way of determining the 
active node.
See also https://www.quickfixj.org/usermanual/2.3.0/usage/acceptor_failover.html

When you're all set, the configuration "RefreshOnLogon=Y" will cause to reload the message store 
from the shared medium on the next logon so that the active connector can continue where the now 
inactive connector left off.

Hope that helps.
Cheers,
Chris.


On 14.06.21 20:41, krishna sumanth Rachamadugu wrote:
> Hi Chris,
>
> Here, I'm trying to achieve the availability. Lets say, if the machine which is running QuickFIX 
> Engine went down, We won't be able to communicate with other parties until we bring it up.
>
> Thanks,
> Sumanth.
>
> On Mon, Jun 14, 2021 at 3:42 PM Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi,
>
>     a FIX Session is more or less a point-to-point connection. That means the same SessionID
>     cannot be active on two different machines at the same time. The message store (with sequence
>     numbers and messages) should be accessed exclusively by one connector.
>
>     Let me ask this way: what do you want to achieve? You could of course set up separate Sessions
>     that access the same order management system for example.
>
>     Cheers,
>     Chris.
>
>
>     On 14.06.21 07:32, krishna sumanth Rachamadugu wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/  <http://www.quickfixj.org/documentation/>
>>     QuickFIX/J Support:http://www.quickfixj.org/support/  <http://www.quickfixj.org/support/>
>>
>>
>>
>>     Hi,
>>
>>     I'm new to FIX. I understood that it works on message sequence numbers and felt a more
>>     tightly coupled way of communication between two parties.
>>
>>     1. Can we have a number of acceptors/initiators with the same session id running on two
>>     different machines?. To be more precise, does it support multi-tenant systems?
>>
>>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] QuickFIX - Query on multi tenant support

[krishna s. R. <won...@gm...>]

Hi Chris,

Here, I'm trying to achieve the availability. Lets say, if the machine
which is running QuickFIX Engine went down, We won't be able to communicate
with other parties until we bring it up.

Thanks,
Sumanth.

On Mon, Jun 14, 2021 at 3:42 PM Christoph John <chr...@ma...>
wrote:

> Hi,
>
> a FIX Session is more or less a point-to-point connection. That means the
> same SessionID cannot be active on two different machines at the same time.
> The message store (with sequence numbers and messages) should be accessed
> exclusively by one connector.
>
> Let me ask this way: what do you want to achieve? You could of course set
> up separate Sessions that access the same order management system for
> example.
>
> Cheers,
> Chris.
>
>
> On 14.06.21 07:32, krishna sumanth Rachamadugu wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> I'm new to FIX. I understood that it works on message sequence numbers and
> felt a more tightly coupled way of communication between two parties.
>
> 1. Can we have a number of acceptors/initiators with the same session id
> running on two different machines?. To be more precise, does it support
> multi-tenant systems?
>
>
>
>
> _______________________________________________
> Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Re: [Quickfixj-users] QuickFIX - Query on multi tenant support

[Colin D. <co...@ma...>]

The answer is yes, but no.

Yes, it's technically possible to have acceptors and initiators running 
on different machines that use the same session ids (assuming the 
machines aren't somehow participating in a cluster that makes them a 
single logical unit).

No, you probably shouldn't do that, unless you have a very particular 
use-case. The point of session ids are to identify senders and targets. 
It's hard for me to imagine a scenario where it makes sense to have the 
same target id (which is part of the session id) hosted on different 
acceptors. The same session id shouldn't be in use on different 
acceptors/initiators at the same time. It defeats the purpose of the 
sequence numbers used within a session.

On 6/13/21 10:32 PM, krishna sumanth Rachamadugu wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> I'm new to FIX. I understood that it works on message sequence numbers 
> and felt a more tightly coupled way of communication between two parties.
>
> 1. Can we have a number of acceptors/initiators with the same session 
> id running on two different machines?. To be more precise, does it 
> support multi-tenant systems?
>
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884
https://www.marketcetera.com

Re: [Quickfixj-users] QuickFIX - Query on multi tenant support

[Christoph J. <chr...@ma...>]

Hi,

a FIX Session is more or less a point-to-point connection. That means the same SessionID cannot be 
active on two different machines at the same time. The message store (with sequence numbers and 
messages) should be accessed exclusively by one connector.

Let me ask this way: what do you want to achieve? You could of course set up separate Sessions that 
access the same order management system for example.

Cheers,
Chris.


On 14.06.21 07:32, krishna sumanth Rachamadugu wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> I'm new to FIX. I understood that it works on message sequence numbers and felt a more tightly 
> coupled way of communication between two parties.
>
> 1. Can we have a number of acceptors/initiators with the same session id running on two different 
> machines?. To be more precise, does it support multi-tenant systems?
>
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

[Quickfixj-users] QuickFIX - Query on multi tenant support

[krishna s. R. <won...@gm...>]

Hi,

I'm new to FIX. I understood that it works on message sequence numbers and
felt a more tightly coupled way of communication between two parties.

1. Can we have a number of acceptors/initiators with the same session id
running on two different machines?. To be more precise, does it support
multi-tenant systems?

Re: [Quickfixj-users] One port for all clients

[Christoph J. <chr...@ma...>]

Hi Ajit,

I am no security expert, but all servers that are reachable via one dedicated port would have this 
problem, right?
When a counter-party has an established session to your server then there is a TCP point-to-point 
connection via a socket between the two parties. I don't think it is easily possible for another 
connection to get data that is not meant for its own socket connection. However, if you fear that 
this might happen it would be advisable to use SSL/TLS for each connection (of course with a 
separate key for each connection).

I still don't know what you are doing in the first place. Since you are implementing an acceptor: do 
you want to create an own trading venue or are you just creating a routing service? In any case, I 
would strongly advise to make yourself acquainted with the following:
https://www.fixtrading.org/technical-guidelines/
https://www.fixtrading.org/standards/fixs/

Cheers,
Chris.


On 06.06.21 13:02, Ajit Gautam wrote:
> Hi Chris,
>
> I have implemented Quickfix acceptor with one port assigned to all clients and it's working fine. 
> Each inbound and outbound transactions are processed with respect to the session ID.
>
> I was just wondering, is there way possible while assigning one port for all client which can 
> result into malicious activity or raise any security concern.
>
> As acceptor is sending response over one port, but is it possible by  programmatically or any 
> other way such that whatever information of different sessions are going over that port can be 
> received by a session such that it can get the information of all other sessions.
>
> I don't have much information on this.
> I tried to run various transaction and each transaction is following its own session ID.
>
> Just wondering about the security concern.
>
> Any help would be appreciated.
>
> Regards
> Ajit Gautam
>
> On Tue, Jun 1, 2021, 10:19 Ajit Gautam <aji...@gm... <mailto:aji...@gm...>> 
> wrote:
>
>     Thanks Chris.
>     That's really helpful.
>
>     Regards
>     Ajit Gautam
>
>     On Tue, Jun 1, 2021, 03:45 Christoph John <chr...@ma...
>     <mailto:chr...@ma...>> wrote:
>
>         Hi Ajit,
>
>         On 31.05.21 15:37, Ajit Gautam wrote:
>>         Thanks chris. It was a configuration problem. But, mostly I see in FIX manuals,
>>         institutions follow one port per session.
>>         Is this option available only with Quickfix/J?
>         I am pretty sure that more FIX engines than QFJ offer this option.
>         Probably it is more convenient to have clients separated per port, e.g. for a tcp dump or
>         to create a specific allow-rule in a firewall.
>>
>>         Apart from heavy traffic on a single port, I cannot see any problem.
>>         Does this approach of one port for all sessions have any disadvantages?
>         See above. Moreover, most of the time one port means one process. I.e. when you only have
>         one process listening on that port and that process goes down, all clients have a problem.
>>
>>         Also, I was curious to know how quickfix handles all sessions on one port. I will
>>         appreciate it if you elaborate on the concept behind it.
>         I mean the concept is not new. Every server component handles clients on the same port... ;)
>         If you mean how QFJ can tell the different sessions apart: it simply looks at the
>         SessionID of the FIX message and forwards the message to that Session instance.
>         The relevant code is here:
>         https://github.com/quickfix-j/quickfixj/blob/7e3a07104cd8bfaf7e704896dd668b767c9aa13b/quickfixj-core/src/main/java/quickfix/mina/acceptor/AcceptorIoHandler.java#L62
>         <https://github.com/quickfix-j/quickfixj/blob/7e3a07104cd8bfaf7e704896dd668b767c9aa13b/quickfixj-core/src/main/java/quickfix/mina/acceptor/AcceptorIoHandler.java#L62>
>>
>>         Adding to the same approach, can we create a setting which can differentiate identical
>>         sessions(Same sender ID, TargetID and port).
>         You could use a SessionQualifier, but that is only available for initiators. I would also
>         not recommend to use it. At the beginning of this document there are a few words about it:
>         https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html
>         <https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html>
>         The SessionID should be unique, so there shouldn't be any identical sessions. You could
>         add e.g. a SenderSubID to tell different sessions apart.
>
>         Cheers,
>         Chris.
>
>>
>>
>>         Regards
>>         Ajit Gautam
>>
>>         On Mon, May 31, 2021 at 5:16 PM Christoph John <chr...@ma...
>>         <mailto:chr...@ma...>> wrote:
>>
>>             Hi,
>>
>>             we are doing something similar and run almost 100 sessions all via the same acceptor
>>             port. So if something is "blocking" on your side it most likely is a configuration or
>>             application problem.
>>
>>             Cheers,
>>             Chris.
>>
>>
>>             On 31.05.21 13:10, Ajit Gautam wrote:
>>>             Hi Chris,
>>>
>>>             Thanks for acknowledging.
>>>             I will share the log soon.
>>>
>>>             Just to confirm you, I am running one FIX acceptor with multiple sessions. Each
>>>             session is established by a Unique SenderID and XYZ Target ID (Target ID is the same
>>>             for all sessions) and a dedicated port for each session.
>>>
>>>             I ran a FIX acceptor with multiple sessions configured on the *same port *with a
>>>             unique Sender ID of each session and Target ID XYZ same for all sessions.
>>>
>>>             Regards
>>>             Ajit Gautam
>>>
>>>             On Mon, May 31, 2021 at 3:17 PM Christoph John <chr...@ma...
>>>             <mailto:chr...@ma...>> wrote:
>>>
>>>                 Are you maybe starting multiple Acceptors? I definitely works when using one
>>>                 Acceptor with multiple configured sessions.
>>>                 What do you mean by "gets blocked"? A log file would be helpful.
>>>
>>>                 Cheers,
>>>                 Chris.
>>>
>>>                 On 31.05.21 11:44, Ajit Gautam wrote:
>>>>                 Hi,
>>>>
>>>>                 I have a FIX Acceptor trading session with each port assigned to one member.
>>>>                 This results in opening multiple ports at the firewall which doesn't look a
>>>>                 viable option.
>>>>                 I tried keeping the same port for a few members(different sender ID connecting
>>>>                 to the same port), but the session I start second gets blocked by the first.
>>>>
>>>>                 Any help would be appreciated.
>>>>
>>>>                 Regards
>>>>                 Ajit Gautam
>>>>
>>>>                 On Thu, May 27, 2021 at 10:15 PM Christoph John <chr...@ma...
>>>>                 <mailto:chr...@ma...>> wrote:
>>>>
>>>>                     What keeps you from configuring the same SocketAcceptPort for all sessions
>>>>                     in your acceptor config file?
>>>>
>>>>                     Chris
>>>>
>>>>                     Am 27. Mai 2021 17:50:22 MESZ schrieb Ajit Gautam <aji...@gm...
>>>>                     <mailto:aji...@gm...>>:
>>>>
>>>>                         Hi,
>>>>
>>>>                         I have a FIX acceptor which connects with Client FIX initiators with a
>>>>                         separate port for each session assigned to each client.
>>>>                         I was thinking of modifying the approach of having a separate port for
>>>>                         each session to one port for all the members.
>>>>
>>>>                         Is there an implementation available in Quickfix/J for such a setup
>>>>                         which assigns single port and IP to all the Client FIX initiators?
>>>>
>>>>
>>>>                         Regards
>>>>                         Ajit Gautam
>>>>
>>>
>>>                 -- 
>>>                 Christoph John
>>>                 Software Engineering
>>>                 T +49 241 557080-28
>>>                 chr...@ma...  <mailto:chr...@ma...>
>>>
>>>                 MACD GmbH
>>>                 Oppenhoffallee 103
>>>                 52066 Aachen, Germany
>>>                 www.macd.com  <http://www.macd.com>
>>>
>>>                 Amtsgericht Aachen: HRB 8151
>>>                 Ust.-Id: DE 813021663
>>>                 Geschäftsführer: George Macdonald
>>>
>>
>>             -- 
>>             Christoph John
>>             Software Engineering
>>             T +49 241 557080-28
>>             chr...@ma...  <mailto:chr...@ma...>
>>
>>             MACD GmbH
>>             Oppenhoffallee 103
>>             52066 Aachen, Germany
>>             www.macd.com  <http://www.macd.com>
>>
>>             Amtsgericht Aachen: HRB 8151
>>             Ust.-Id: DE 813021663
>>             Geschäftsführer: George Macdonald
>>
>
>         -- 
>         Christoph John
>         Software Engineering
>         T +49 241 557080-28
>         chr...@ma...  <mailto:chr...@ma...>
>
>         MACD GmbH
>         Oppenhoffallee 103
>         52066 Aachen, Germany
>         www.macd.com  <http://www.macd.com>
>
>         Amtsgericht Aachen: HRB 8151
>         Ust.-Id: DE 813021663
>         Geschäftsführer: George Macdonald
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Quickfix logging

[Ajit G. <aji...@gm...>]

Okay, Thanks chris.


Regards
Ajit Gautam

On Mon, Jun 7, 2021 at 4:32 PM Christoph John <chr...@ma...>
wrote:

> OK, altering that file should be no problem but I would advise anyway to
> implement your own quickfix.Log and change the fields on the fly.
>
> Cheers,
> Chris.
>
> On 07.06.21 13:00, Ajit Gautam wrote:
>
> Hi Chris,
>
> Thanks for your reply.
> I was talking about the quickfix log file at FileLogPath. The message log
> file which logs all the FIX transactions.
>
> FileStorePath will be untouched as it contains session level details.
>
> Regards
> Ajit Gautam
>
>
>
> On Mon, Jun 7, 2021 at 4:21 PM Christoph John <chr...@ma...>
> wrote:
>
>> Hi Ajit,
>>
>> I thought I gave the answer to this some days ago already. Implement your
>> own quickfix.Log interface and replace the fields on the fly as messages
>> come in or go out.
>>
>> As far as I am aware there is no lock on the log files but I think this
>> is OS-dependent.
>>
>> When you talk about "logs" you mean the log file, right? So the file
>> where INFO, DEBUG, WARN messages etc are printed along with the FIX
>> messages that are sent out.
>> Why should the content of the FIX messages change because you change a
>> text file?
>> Or do you mean the real message store? These are files that are stored in
>> the directory that is pointed to in the config "FileStorePath". If you
>> change something in there, then this will change the FIX messages in case
>> of a resend. I strongly advise to NOT touch these files.
>>
>> Cheers,
>> Chris.
>>
>>
>> On 07.06.21 09:44, Ajit Gautam wrote:
>>
>> Hi Chris,
>>
>> I am logging my own logs as well as quickfix logs which are automatically
>> generated.
>> Since quickfix logs are logging passwords as well, I was wondering about
>> an approach at application level to run a cron which can replace the
>> password field with xxxx.
>>
>> But there were two points which I was not sure whether they would get
>> impacted or not.
>> Firstly, is there any locking mechanism on quickfix log or I can change
>> it runtime?
>> Secondly, if I change the log, does in the resend request, xxxx will be
>> sent in serving recovery request?
>>
>>
>> Regards
>> Ajit Gautam
>>
>>
>> On Sat, May 29, 2021 at 2:53 AM Christoph John <chr...@ma...>
>> wrote:
>>
>>> You could implement your own quickfix.Log and obfuscate the unwanted
>>> tags in the onIncoming/onOutgoing callbacks.
>>>
>>> Chris.
>>>
>>>
>>> On 28.05.21 13:38, Ajit Gautam wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Hi,
>>>
>>> I have a Quickfix acceptor and a custom message for user logon and
>>> response.
>>> I am using Quickfix libraries and logging the messages. In the quickfix
>>> message log, user name and password are getting logged. But, I don't want
>>> to log the password field
>>> Is there a way or work around that avoids logging only the password
>>> field on a user logon request message?
>>>
>>>
>>>
>>> Regards
>>> Ajit Gautam
>>>
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>>
>>> --
>>> Christoph John
>>> Software Engineering
>>> T +49 241 557...@ma...
>>>
>>> MACD GmbH
>>> Oppenhoffallee 103
>>> 52066 Aachen, Germanywww.macd.com
>>>
>>> Amtsgericht Aachen: HRB 8151
>>> Ust.-Id: DE 813021663
>>> Geschäftsführer: George Macdonald
>>>
>>>
>> --
>> Christoph John
>> Software Engineering
>> T +49 241 557...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germanywww.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Re: [Quickfixj-users] Quickfix logging

[Christoph J. <chr...@ma...>]

OK, altering that file should be no problem but I would advise anyway to implement your own 
quickfix.Log and change the fields on the fly.

Cheers,
Chris.

On 07.06.21 13:00, Ajit Gautam wrote:
> Hi Chris,
>
> Thanks for your reply.
> I was talking about the quickfix log file at FileLogPath. The message log file which logs all the 
> FIX transactions.
>
> FileStorePath will be untouched as it contains session level details.
>
> Regards
> Ajit Gautam
>
>
>
> On Mon, Jun 7, 2021 at 4:21 PM Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi Ajit,
>
>     I thought I gave the answer to this some days ago already. Implement your own quickfix.Log
>     interface and replace the fields on the fly as messages come in or go out.
>
>     As far as I am aware there is no lock on the log files but I think this is OS-dependent.
>
>     When you talk about "logs" you mean the log file, right? So the file where INFO, DEBUG, WARN
>     messages etc are printed along with the FIX messages that are sent out.
>     Why should the content of the FIX messages change because you change a text file?
>     Or do you mean the real message store? These are files that are stored in the directory that
>     is pointed to in the config "FileStorePath". If you change something in there, then this will
>     change the FIX messages in case of a resend. I strongly advise to NOT touch these files.
>
>     Cheers,
>     Chris.
>
>
>     On 07.06.21 09:44, Ajit Gautam wrote:
>>     Hi Chris,
>>
>>     I am logging my own logs as well as quickfix logs which are automatically generated.
>>     Since quickfix logs are logging passwords as well, I was wondering about an approach at
>>     application level to run a cron which can replace the password field with xxxx.
>>
>>     But there were two points which I was not sure whether they would get impacted or not.
>>     Firstly, is there any locking mechanism on quickfix log or I can change it runtime?
>>     Secondly, if I change the log, does in the resend request, xxxx will be sent in serving
>>     recovery request?
>>
>>
>>     Regards
>>     Ajit Gautam
>>
>>
>>     On Sat, May 29, 2021 at 2:53 AM Christoph John <chr...@ma...
>>     <mailto:chr...@ma...>> wrote:
>>
>>         You could implement your own quickfix.Log and obfuscate the unwanted tags in the
>>         onIncoming/onOutgoing callbacks.
>>
>>         Chris.
>>
>>
>>         On 28.05.21 13:38, Ajit Gautam wrote:
>>>         QuickFIX/J Documentation:http://www.quickfixj.org/documentation/  <http://www.quickfixj.org/documentation/>
>>>         QuickFIX/J Support:http://www.quickfixj.org/support/  <http://www.quickfixj.org/support/>
>>>
>>>
>>>
>>>         Hi,
>>>
>>>         I have a Quickfix acceptor and a custom message for user logon and response.
>>>         I am using Quickfix libraries and logging the messages. In the quickfix message log,
>>>         user name and password are getting logged. But, I don't want to log the password field
>>>         Is there a way or work around that avoids logging only the password field on a user
>>>         logon request message?
>>>
>>>
>>>
>>>         Regards
>>>         Ajit Gautam
>>>
>>>
>>>         _______________________________________________
>>>         Quickfixj-users mailing list
>>>         Qui...@li...  <mailto:Qui...@li...>
>>>         https://lists.sourceforge.net/lists/listinfo/quickfixj-users  <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>>
>>         -- 
>>         Christoph John
>>         Software Engineering
>>         T +49 241 557080-28
>>         chr...@ma...  <mailto:chr...@ma...>
>>
>>         MACD GmbH
>>         Oppenhoffallee 103
>>         52066 Aachen, Germany
>>         www.macd.com  <http://www.macd.com>
>>
>>         Amtsgericht Aachen: HRB 8151
>>         Ust.-Id: DE 813021663
>>         Geschäftsführer: George Macdonald
>>
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Quickfix logging

[Ajit G. <aji...@gm...>]

Hi Chris,

Thanks for your reply.
I was talking about the quickfix log file at FileLogPath. The message log
file which logs all the FIX transactions.

FileStorePath will be untouched as it contains session level details.

Regards
Ajit Gautam



On Mon, Jun 7, 2021 at 4:21 PM Christoph John <chr...@ma...>
wrote:

> Hi Ajit,
>
> I thought I gave the answer to this some days ago already. Implement your
> own quickfix.Log interface and replace the fields on the fly as messages
> come in or go out.
>
> As far as I am aware there is no lock on the log files but I think this is
> OS-dependent.
>
> When you talk about "logs" you mean the log file, right? So the file where
> INFO, DEBUG, WARN messages etc are printed along with the FIX messages that
> are sent out.
> Why should the content of the FIX messages change because you change a
> text file?
> Or do you mean the real message store? These are files that are stored in
> the directory that is pointed to in the config "FileStorePath". If you
> change something in there, then this will change the FIX messages in case
> of a resend. I strongly advise to NOT touch these files.
>
> Cheers,
> Chris.
>
>
> On 07.06.21 09:44, Ajit Gautam wrote:
>
> Hi Chris,
>
> I am logging my own logs as well as quickfix logs which are automatically
> generated.
> Since quickfix logs are logging passwords as well, I was wondering about
> an approach at application level to run a cron which can replace the
> password field with xxxx.
>
> But there were two points which I was not sure whether they would get
> impacted or not.
> Firstly, is there any locking mechanism on quickfix log or I can change it
> runtime?
> Secondly, if I change the log, does in the resend request, xxxx will be
> sent in serving recovery request?
>
>
> Regards
> Ajit Gautam
>
>
> On Sat, May 29, 2021 at 2:53 AM Christoph John <chr...@ma...>
> wrote:
>
>> You could implement your own quickfix.Log and obfuscate the unwanted tags
>> in the onIncoming/onOutgoing callbacks.
>>
>> Chris.
>>
>>
>> On 28.05.21 13:38, Ajit Gautam wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi,
>>
>> I have a Quickfix acceptor and a custom message for user logon and
>> response.
>> I am using Quickfix libraries and logging the messages. In the quickfix
>> message log, user name and password are getting logged. But, I don't want
>> to log the password field
>> Is there a way or work around that avoids logging only the password field
>> on a user logon request message?
>>
>>
>>
>> Regards
>> Ajit Gautam
>>
>>
>> _______________________________________________
>> Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>>
>> --
>> Christoph John
>> Software Engineering
>> T +49 241 557...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germanywww.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Re: [Quickfixj-users] Quickfix logging

[Christoph J. <chr...@ma...>]

Hi Ajit,

I thought I gave the answer to this some days ago already. Implement your own quickfix.Log interface 
and replace the fields on the fly as messages come in or go out.

As far as I am aware there is no lock on the log files but I think this is OS-dependent.

When you talk about "logs" you mean the log file, right? So the file where INFO, DEBUG, WARN 
messages etc are printed along with the FIX messages that are sent out.
Why should the content of the FIX messages change because you change a text file?
Or do you mean the real message store? These are files that are stored in the directory that is 
pointed to in the config "FileStorePath". If you change something in there, then this will change 
the FIX messages in case of a resend. I strongly advise to NOT touch these files.

Cheers,
Chris.


On 07.06.21 09:44, Ajit Gautam wrote:
> Hi Chris,
>
> I am logging my own logs as well as quickfix logs which are automatically generated.
> Since quickfix logs are logging passwords as well, I was wondering about an approach at 
> application level to run a cron which can replace the password field with xxxx.
>
> But there were two points which I was not sure whether they would get impacted or not.
> Firstly, is there any locking mechanism on quickfix log or I can change it runtime?
> Secondly, if I change the log, does in the resend request, xxxx will be sent in serving recovery 
> request?
>
>
> Regards
> Ajit Gautam
>
>
> On Sat, May 29, 2021 at 2:53 AM Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     You could implement your own quickfix.Log and obfuscate the unwanted tags in the
>     onIncoming/onOutgoing callbacks.
>
>     Chris.
>
>
>     On 28.05.21 13:38, Ajit Gautam wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/  <http://www.quickfixj.org/documentation/>
>>     QuickFIX/J Support:http://www.quickfixj.org/support/  <http://www.quickfixj.org/support/>
>>
>>
>>
>>     Hi,
>>
>>     I have a Quickfix acceptor and a custom message for user logon and response.
>>     I am using Quickfix libraries and logging the messages. In the quickfix message log, user
>>     name and password are getting logged. But, I don't want to log the password field
>>     Is there a way or work around that avoids logging only the password field on a user logon
>>     request message?
>>
>>
>>
>>     Regards
>>     Ajit Gautam
>>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li...  <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users  <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Quickfix logging

[Ajit G. <aji...@gm...>]

Hi Chris,

I am logging my own logs as well as quickfix logs which are automatically
generated.
Since quickfix logs are logging passwords as well, I was wondering about an
approach at application level to run a cron which can replace the
password field with xxxx.

But there were two points which I was not sure whether they would get
impacted or not.
Firstly, is there any locking mechanism on quickfix log or I can change it
runtime?
Secondly, if I change the log, does in the resend request, xxxx will be
sent in serving recovery request?


Regards
Ajit Gautam


On Sat, May 29, 2021 at 2:53 AM Christoph John <chr...@ma...>
wrote:

> You could implement your own quickfix.Log and obfuscate the unwanted tags
> in the onIncoming/onOutgoing callbacks.
>
> Chris.
>
>
> On 28.05.21 13:38, Ajit Gautam wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> I have a Quickfix acceptor and a custom message for user logon and
> response.
> I am using Quickfix libraries and logging the messages. In the quickfix
> message log, user name and password are getting logged. But, I don't want
> to log the password field
> Is there a way or work around that avoids logging only the password field
> on a user logon request message?
>
>
>
> Regards
> Ajit Gautam
>
>
> _______________________________________________
> Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Re: [Quickfixj-users] One port for all clients

[Ajit G. <aji...@gm...>]

Hi Chris,

I have implemented Quickfix acceptor with one port assigned to all clients
and it's working fine. Each inbound and outbound transactions are processed
with respect to the session ID.

I was just wondering, is there way possible while assigning one port for
all client which can result into malicious activity or raise any security
concern.

As acceptor is sending response over one port, but is it possible by
programmatically or any other way such that whatever information of
different sessions are going over that port can be received by a session
such that it can get the information of all other sessions.

I don't have much information on this.
I tried to run various transaction and each transaction is following its
own session ID.

Just wondering about the security concern.

Any help would be appreciated.

Regards
Ajit Gautam

On Tue, Jun 1, 2021, 10:19 Ajit Gautam <aji...@gm...> wrote:

> Thanks Chris.
> That's really helpful.
>
> Regards
> Ajit Gautam
>
> On Tue, Jun 1, 2021, 03:45 Christoph John <chr...@ma...> wrote:
>
>> Hi Ajit,
>>
>> On 31.05.21 15:37, Ajit Gautam wrote:
>>
>> Thanks chris. It was a configuration problem. But, mostly I see in FIX
>> manuals, institutions follow one port per session.
>> Is this option available only with Quickfix/J?
>>
>> I am pretty sure that more FIX engines than QFJ offer this option.
>> Probably it is more convenient to have clients separated per port, e.g.
>> for a tcp dump or to create a specific allow-rule in a firewall.
>>
>>
>> Apart from heavy traffic on a single port, I cannot see any problem.
>> Does this approach of one port for all sessions have any disadvantages?
>>
>> See above. Moreover, most of the time one port means one process. I.e.
>> when you only have one process listening on that port and that process goes
>> down, all clients have a problem.
>>
>>
>> Also, I was curious to know how quickfix handles all sessions on one
>> port. I will appreciate it if you elaborate on the concept behind it.
>>
>> I mean the concept is not new. Every server component handles clients on
>> the same port... ;)
>> If you mean how QFJ can tell the different sessions apart: it simply
>> looks at the SessionID of the FIX message and forwards the message to that
>> Session instance.
>> The relevant code is here:
>> https://github.com/quickfix-j/quickfixj/blob/7e3a07104cd8bfaf7e704896dd668b767c9aa13b/quickfixj-core/src/main/java/quickfix/mina/acceptor/AcceptorIoHandler.java#L62
>>
>>
>> Adding to the same approach, can we create a setting which can
>> differentiate identical sessions(Same sender ID, TargetID and port).
>>
>> You could use a SessionQualifier, but that is only available for
>> initiators. I would also not recommend to use it. At the beginning of this
>> document there are a few words about it:
>> https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html
>> The SessionID should be unique, so there shouldn't be any identical
>> sessions. You could add e.g. a SenderSubID to tell different sessions apart.
>>
>> Cheers,
>> Chris.
>>
>>
>>
>> Regards
>> Ajit Gautam
>>
>> On Mon, May 31, 2021 at 5:16 PM Christoph John <chr...@ma...>
>> wrote:
>>
>>> Hi,
>>>
>>> we are doing something similar and run almost 100 sessions all via the
>>> same acceptor port. So if something is "blocking" on your side it most
>>> likely is a configuration or application problem.
>>>
>>> Cheers,
>>> Chris.
>>>
>>>
>>> On 31.05.21 13:10, Ajit Gautam wrote:
>>>
>>> Hi Chris,
>>>
>>> Thanks for acknowledging.
>>> I will share the log soon.
>>>
>>> Just to confirm you, I am running one FIX acceptor with multiple
>>> sessions. Each session is established by a Unique SenderID and XYZ Target
>>> ID (Target ID is the same for all sessions) and a dedicated port for each
>>> session.
>>>
>>> I ran a FIX acceptor with multiple sessions configured on the *same
>>> port *with a unique Sender ID of each session and Target ID XYZ same
>>> for all sessions.
>>>
>>> Regards
>>> Ajit Gautam
>>>
>>> On Mon, May 31, 2021 at 3:17 PM Christoph John <chr...@ma...>
>>> wrote:
>>>
>>>> Are you maybe starting multiple Acceptors? I definitely works when
>>>> using one Acceptor with multiple configured sessions.
>>>> What do you mean by "gets blocked"? A log file would be helpful.
>>>>
>>>> Cheers,
>>>> Chris.
>>>>
>>>> On 31.05.21 11:44, Ajit Gautam wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have a FIX Acceptor trading session with each port assigned to one
>>>> member. This results in opening multiple ports at the firewall which
>>>> doesn't look a viable option.
>>>> I tried keeping the same port for a few members(different sender ID
>>>> connecting to the same port), but the session I start second gets blocked
>>>> by the first.
>>>>
>>>> Any help would be appreciated.
>>>>
>>>> Regards
>>>> Ajit Gautam
>>>>
>>>> On Thu, May 27, 2021 at 10:15 PM Christoph John <
>>>> chr...@ma...> wrote:
>>>>
>>>>> What keeps you from configuring the same SocketAcceptPort for all
>>>>> sessions in your acceptor config file?
>>>>>
>>>>> Chris
>>>>>
>>>>> Am 27. Mai 2021 17:50:22 MESZ schrieb Ajit Gautam <
>>>>> aji...@gm...>:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have a FIX acceptor which connects with Client FIX initiators with
>>>>>> a separate port for each session assigned to each client.
>>>>>> I was thinking of modifying the approach of having a separate port
>>>>>> for each session to one port for all the members.
>>>>>>
>>>>>> Is there an implementation available in Quickfix/J for such a setup
>>>>>> which assigns single port and IP to all the Client FIX initiators?
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Ajit Gautam
>>>>>>
>>>>>
>>>> --
>>>> Christoph John
>>>> Software Engineering
>>>> T +49 241 557...@ma...
>>>>
>>>> MACD GmbH
>>>> Oppenhoffallee 103
>>>> 52066 Aachen, Germanywww.macd.com
>>>>
>>>> Amtsgericht Aachen: HRB 8151
>>>> Ust.-Id: DE 813021663
>>>> Geschäftsführer: George Macdonald
>>>>
>>>>
>>> --
>>> Christoph John
>>> Software Engineering
>>> T +49 241 557...@ma...
>>>
>>> MACD GmbH
>>> Oppenhoffallee 103
>>> 52066 Aachen, Germanywww.macd.com
>>>
>>> Amtsgericht Aachen: HRB 8151
>>> Ust.-Id: DE 813021663
>>> Geschäftsführer: George Macdonald
>>>
>>>
>> --
>> Christoph John
>> Software Engineering
>> T +49 241 557...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germanywww.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>

Re: [Quickfixj-users] SenderSubID

[Ajit G. <aji...@gm...>]

Hey Chris,

Thanks for your reply.

Mostly PartyID is available in FIX standard messages.
But in the case of a few messages, like Security List Request, FIX doesn't
provide any user related field.
In my case of FIX acceptor, only authorized users get the security list.

Thus, I am in a dilemma whether I should go for the SenderSubID field or
not. Because if I use SenderSubID, then it has to be part of the Standard
Message header.

Any help would be appreciated.


Regards
Ajit Gautam.


On Thu, Jun 3, 2021 at 5:53 PM Christoph John <chr...@ma...>
wrote:

> If you want to use this field for separation of users, then you must not
> use it as part of the session configuration but need to set it to the
> desired value on a per message basis.
>
> Cheers,
> Chris.
>
>
>
> On 02.06.21 12:48, Ajit Gautam wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> As per the quickfix manual, the SenderSubID field can be set in session
> configuration.
> This means, one user per session can take login and send the request from
> quickfix initiator.
>
> But in case of multiple users per session, how will this setting work or
> any different setting is required?
>
> Any help will be appreciated.
>
> Regards
> Ajit Gautam
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Re: [Quickfixj-users] SenderSubID

[Ajit G. <aji...@gm...>]

Hey Grant,

I am working on the acceptor side.

Actually, I have a business message, a security list message, which needs
authorised user to access it.
Not every user is authorized to get the security of the list.
As per the standard message, Security list request message doesn't have
PartyID or User ID field.
With this information, the dilemma of partyID and SenderSubID arised.
I am not sure existing FIX client available in market will like which
approach to follow.

In the above scenario, how can I get the details of the user in the
security list request message.

Any help would be appreciated.

Regards
Ajit Gautam


On Wed, Jun 2, 2021 at 6:55 PM Grant Birchmeier <gbi...@co...>
wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> Are you writing code for the acceptor side or for the initiator side?
>
> My advice is:
>
> If on initiator side: Follow your counterparty's instructions.  Use this
> field only as much as you have to.
>
> If on acceptor side: Don't use it.
>
> On Wed, Jun 2, 2021 at 5:49 AM Ajit Gautam <aji...@gm...>
> wrote:
>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>> http://www.quickfixj.org/support/
>>
>>
>> Hi,
>>
>> As per the quickfix manual, the SenderSubID field can be set in session
>> configuration.
>> This means, one user per session can take login and send the request from
>> quickfix initiator.
>>
>> But in case of multiple users per session, how will this setting work or
>> any different setting is required?
>>
>> Any help will be appreciated.
>>
>> Regards
>> Ajit Gautam
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>
>
> --
> Grant Birchmeier
> *Connamara Systems, LLC*
> *Made-To-Measure Trading Solutions.*
> Exactly what you need. No more. No less.
> http://connamara.com
>
> This email, along with any attachments, is confidential. If you believe
> you received this message in error, please contact the sender immediately
> and delete all copies of the message. Thank you from Connamara Systems, LLC.
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] QUICK FIX REPONSES

[Christoph J. <chr...@ma...>]

Hi,

I think Philip literally meant the "FIX Trading Community Forum".
You can access it here https://forum.fixtrading.org/ and need to register here 
https://www.fixtrading.org/register/ .

Cheers,
Chris.


On 01.06.21 19:38, Taysay Shaguy wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Thank you so much,
>
> Please, is there any forum you can suggest?
>
> 	
>
> Terseer (taysay)Shaguy
>
> Coding & Digitalization Enthusiast
>
> Email: tay...@ya... <mailto:tay...@ya...>
>
> Phone(s): +2348036533888 <tel:+2348036533888>
>
> <https://www.twitter.com/taysay>
>
> 	
> <https://www.linkedin.com/terseer-shaguy>
>
> 	
>
> 	
> <https://www.apple.com/tay>
>
>
>
> On Tue, Jun 1, 2021 at 5:22 PM Philip Whitehouse <ph...@wh... <mailto:ph...@wh...>> wrote:
>
>     QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>     QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>     http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>
>
>     I agree that I’d expect a response to an order status request.
>
>     This is something you need to discuss with your counter-party after reviewing your agreement
>     with them.
>
>     It may, for example, be that they don’t provide an order status service and expect you to
>     maintain your own state and will just send you updates when the state changes.
>
>     In that scenario I would hope for a reject but there’s no protocol guarantee.
>
>     For detailed discussions about FIX as a protocol, rather than technical concerns with QFJ you
>     might benefit from asking on the FIX Trading Community forums.
>
>     Best,
>
>     Philip Whitehouse
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] SenderSubID

[Christoph J. <chr...@ma...>]

If you want to use this field for separation of users, then you must not use it as part of the 
session configuration but need to set it to the desired value on a per message basis.

Cheers,
Chris.



On 02.06.21 12:48, Ajit Gautam wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> As per the quickfix manual, the SenderSubID field can be set in session configuration.
> This means, one user per session can take login and send the request from quickfix initiator.
>
> But in case of multiple users per session, how will this setting work or any different setting is 
> required?
>
> Any help will be appreciated.
>
> Regards
> Ajit Gautam

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald