Quantcast

FixContext instead fo static Session

classic Classic list List threaded Threaded
18 messages Options
lb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FixContext instead fo static Session

lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi all,

in the pas I've hacked quickfixj to replace static Session objects
with a FixContext so as example the classic onMessage would become:

    public void fromApp(FixContext context, Message message, SessionID
sessionID) {
        ...
        context.sendToTarget(...);
    }


The reason of that was:
- add probes and additional validations/enrichments for messages sent
by one target to another one
- add a distributed FixContext so targets on different JVMs can talk
(i.e. via hazelcast)


If it make sense for anyone I can work to merge my work in main code base.


Regards,
Luca

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


The SessionID implies a specific session...

What you want to do is make Session extensible with a factory so different implementations can be used....

> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi all,
>
> in the pas I've hacked quickfixj to replace static Session objects
> with a FixContext so as example the classic onMessage would become:
>
>    public void fromApp(FixContext context, Message message, SessionID
> sessionID) {
>        ...
>        context.sendToTarget(...);
>    }
>
>
> The reason of that was:
> - add probes and additional validations/enrichments for messages sent
> by one target to another one
> - add a distributed FixContext so targets on different JVMs can talk
> (i.e. via hazelcast)
>
>
> If it make sense for anyone I can work to merge my work in main code base.
>
>
> Regards,
> Luca
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
lb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Yes SessionID identifies a session but you may want to as example
enrich the message and send it to another fix session, this is quite
common for FIX hubs that may aggregate spit messagese according to
some rules.
Yes I'd like to have Session as an interface and not static so I may
also have multiple session in the same process.

On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <[hidden email]> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> The SessionID implies a specific session...
>
> What you want to do is make Session extensible with a factory so different implementations can be used....
>
>> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi all,
>>
>> in the pas I've hacked quickfixj to replace static Session objects
>> with a FixContext so as example the classic onMessage would become:
>>
>>    public void fromApp(FixContext context, Message message, SessionID
>> sessionID) {
>>        ...
>>        context.sendToTarget(...);
>>    }
>>
>>
>> The reason of that was:
>> - add probes and additional validations/enrichments for messages sent
>> by one target to another one
>> - add a distributed FixContext so targets on different JVMs can talk
>> (i.e. via hazelcast)
>>
>>
>> If it make sense for anyone I can work to merge my work in main code base.
>>
>>
>> Regards,
>> Luca
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


But there is no difference in what you are doing then just handling the “context” higher up - as all of the application code needs to know about and pass around the context… plus it has to worry about context to session mapping.

All you’ve done is change Session for FixContext and make FixContext extensible - just make Session instances “extensible" and you’ve accomplished the same thing in a far cleaner way.

Just not the best design IMO.


> On Jan 4, 2016, at 8:18 AM, lb <[hidden email]> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Yes SessionID identifies a session but you may want to as example
> enrich the message and send it to another fix session, this is quite
> common for FIX hubs that may aggregate spit messagese according to
> some rules.
> Yes I'd like to have Session as an interface and not static so I may
> also have multiple session in the same process.
>
> On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <[hidden email]> wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> The SessionID implies a specific session...
>>
>> What you want to do is make Session extensible with a factory so different implementations can be used....
>>
>>> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Hi all,
>>>
>>> in the pas I've hacked quickfixj to replace static Session objects
>>> with a FixContext so as example the classic onMessage would become:
>>>
>>>   public void fromApp(FixContext context, Message message, SessionID
>>> sessionID) {
>>>       ...
>>>       context.sendToTarget(...);
>>>   }
>>>
>>>
>>> The reason of that was:
>>> - add probes and additional validations/enrichments for messages sent
>>> by one target to another one
>>> - add a distributed FixContext so targets on different JVMs can talk
>>> (i.e. via hazelcast)
>>>
>>>
>>> If it make sense for anyone I can work to merge my work in main code base.
>>>
>>>
>>> Regards,
>>> Luca
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
lb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Yes that's correct, FixContext is just a non static and extensible
Session I pass to the initiator/acceptors and I've added to
Application methods :

    Acceptor acceptor = new SocketAcceptor(
        session,
        application,
        storeFactory,
        settings,
        logFactory,
        messageFactory
    );

The reason I need an non static class is as example I want to load
multiple fix engines inside a container (i.e. OSGi) and I do not want
the sessions to mess up each others.


On Mon, Jan 4, 2016 at 3:31 PM, Robert Engels <[hidden email]> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> But there is no difference in what you are doing then just handling the “context” higher up - as all of the application code needs to know about and pass around the context… plus it has to worry about context to session mapping.
>
> All you’ve done is change Session for FixContext and make FixContext extensible - just make Session instances “extensible" and you’ve accomplished the same thing in a far cleaner way.
>
> Just not the best design IMO.
>
>
>> On Jan 4, 2016, at 8:18 AM, lb <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Yes SessionID identifies a session but you may want to as example
>> enrich the message and send it to another fix session, this is quite
>> common for FIX hubs that may aggregate spit messagese according to
>> some rules.
>> Yes I'd like to have Session as an interface and not static so I may
>> also have multiple session in the same process.
>>
>> On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <[hidden email]> wrote:
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> The SessionID implies a specific session...
>>>
>>> What you want to do is make Session extensible with a factory so different implementations can be used....
>>>
>>>> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>>>>
>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> in the pas I've hacked quickfixj to replace static Session objects
>>>> with a FixContext so as example the classic onMessage would become:
>>>>
>>>>   public void fromApp(FixContext context, Message message, SessionID
>>>> sessionID) {
>>>>       ...
>>>>       context.sendToTarget(...);
>>>>   }
>>>>
>>>>
>>>> The reason of that was:
>>>> - add probes and additional validations/enrichments for messages sent
>>>> by one target to another one
>>>> - add a distributed FixContext so targets on different JVMs can talk
>>>> (i.e. via hazelcast)
>>>>
>>>>
>>>> If it make sense for anyone I can work to merge my work in main code base.
>>>>
>>>>
>>>> Regards,
>>>> Luca
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Quickfixj-users mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
lb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


So I can work it out to have a better Session class if ok for you

On Mon, Jan 4, 2016 at 4:23 PM, lb <[hidden email]> wrote:

> Yes that's correct, FixContext is just a non static and extensible
> Session I pass to the initiator/acceptors and I've added to
> Application methods :
>
>     Acceptor acceptor = new SocketAcceptor(
>         session,
>         application,
>         storeFactory,
>         settings,
>         logFactory,
>         messageFactory
>     );
>
> The reason I need an non static class is as example I want to load
> multiple fix engines inside a container (i.e. OSGi) and I do not want
> the sessions to mess up each others.
>
>
> On Mon, Jan 4, 2016 at 3:31 PM, Robert Engels <[hidden email]> wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> But there is no difference in what you are doing then just handling the “context” higher up - as all of the application code needs to know about and pass around the context… plus it has to worry about context to session mapping.
>>
>> All you’ve done is change Session for FixContext and make FixContext extensible - just make Session instances “extensible" and you’ve accomplished the same thing in a far cleaner way.
>>
>> Just not the best design IMO.
>>
>>
>>> On Jan 4, 2016, at 8:18 AM, lb <[hidden email]> wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Yes SessionID identifies a session but you may want to as example
>>> enrich the message and send it to another fix session, this is quite
>>> common for FIX hubs that may aggregate spit messagese according to
>>> some rules.
>>> Yes I'd like to have Session as an interface and not static so I may
>>> also have multiple session in the same process.
>>>
>>> On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <[hidden email]> wrote:
>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>
>>>>
>>>> The SessionID implies a specific session...
>>>>
>>>> What you want to do is make Session extensible with a factory so different implementations can be used....
>>>>
>>>>> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>>>>>
>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> in the pas I've hacked quickfixj to replace static Session objects
>>>>> with a FixContext so as example the classic onMessage would become:
>>>>>
>>>>>   public void fromApp(FixContext context, Message message, SessionID
>>>>> sessionID) {
>>>>>       ...
>>>>>       context.sendToTarget(...);
>>>>>   }
>>>>>
>>>>>
>>>>> The reason of that was:
>>>>> - add probes and additional validations/enrichments for messages sent
>>>>> by one target to another one
>>>>> - add a distributed FixContext so targets on different JVMs can talk
>>>>> (i.e. via hazelcast)
>>>>>
>>>>>
>>>>> If it make sense for anyone I can work to merge my work in main code base.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Luca
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Quickfixj-users mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Quickfixj-users mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

Robert Engels-2
In reply to this post by lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



This does not resolve the static class issue - as I assume beneath the hood you still use Session - so, for example, there may be two different implementations that use two different version of QuickFixJ - that is why the OSGI needs to handle this using class loaders.

On Mon, Jan 4, 2016 at 9:23 AM, lb <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Yes that's correct, FixContext is just a non static and extensible
Session I pass to the initiator/acceptors and I've added to
Application methods :

    Acceptor acceptor = new SocketAcceptor(
        session,
        application,
        storeFactory,
        settings,
        logFactory,
        messageFactory
    );

The reason I need an non static class is as example I want to load
multiple fix engines inside a container (i.e. OSGi) and I do not want
the sessions to mess up each others.


On Mon, Jan 4, 2016 at 3:31 PM, Robert Engels <[hidden email]> wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> But there is no difference in what you are doing then just handling the “context” higher up - as all of the application code needs to know about and pass around the context… plus it has to worry about context to session mapping.
>
> All you’ve done is change Session for FixContext and make FixContext extensible - just make Session instances “extensible" and you’ve accomplished the same thing in a far cleaner way.
>
> Just not the best design IMO.
>
>
>> On Jan 4, 2016, at 8:18 AM, lb <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Yes SessionID identifies a session but you may want to as example
>> enrich the message and send it to another fix session, this is quite
>> common for FIX hubs that may aggregate spit messagese according to
>> some rules.
>> Yes I'd like to have Session as an interface and not static so I may
>> also have multiple session in the same process.
>>
>> On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <[hidden email]> wrote:
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> The SessionID implies a specific session...
>>>
>>> What you want to do is make Session extensible with a factory so different implementations can be used....
>>>
>>>> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>>>>
>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> in the pas I've hacked quickfixj to replace static Session objects
>>>> with a FixContext so as example the classic onMessage would become:
>>>>
>>>>   public void fromApp(FixContext context, Message message, SessionID
>>>> sessionID) {
>>>>       ...
>>>>       context.sendToTarget(...);
>>>>   }
>>>>
>>>>
>>>> The reason of that was:
>>>> - add probes and additional validations/enrichments for messages sent
>>>> by one target to another one
>>>> - add a distributed FixContext so targets on different JVMs can talk
>>>> (i.e. via hazelcast)
>>>>
>>>>
>>>> If it make sense for anyone I can work to merge my work in main code base.
>>>>
>>>>
>>>> Regards,
>>>> Luca
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Quickfixj-users mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--

Robert Engels

 

OptionsCity Software
200 W. Adams St., Suite 1010
Chicago, IL 60606

O. +1 (312) 605-4500 | F. +1 (312) 635-1751 

 

All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.

 

Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook

 

 


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
lb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Obviously the Session interface is then used in onMessage(Session
session , ....)

On Mon, Jan 4, 2016 at 5:17 PM, Robert Engels <[hidden email]> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> This does not resolve the static class issue - as I assume beneath the hood you still use Session - so, for example, there may be two different implementations that use two different version of QuickFixJ - that is why the OSGI needs to handle this using class loaders.
>
> On Mon, Jan 4, 2016 at 9:23 AM, lb <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Yes that's correct, FixContext is just a non static and extensible
>> Session I pass to the initiator/acceptors and I've added to
>> Application methods :
>>
>>     Acceptor acceptor = new SocketAcceptor(
>>         session,
>>         application,
>>         storeFactory,
>>         settings,
>>         logFactory,
>>         messageFactory
>>     );
>>
>> The reason I need an non static class is as example I want to load
>> multiple fix engines inside a container (i.e. OSGi) and I do not want
>> the sessions to mess up each others.
>>
>>
>> On Mon, Jan 4, 2016 at 3:31 PM, Robert Engels <[hidden email]> wrote:
>> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> > QuickFIX/J Support: http://www.quickfixj.org/support/
>> >
>> >
>> > But there is no difference in what you are doing then just handling the “context” higher up - as all of the application code needs to know about and pass around the context… plus it has to worry about context to session mapping.
>> >
>> > All you’ve done is change Session for FixContext and make FixContext extensible - just make Session instances “extensible" and you’ve accomplished the same thing in a far cleaner way.
>> >
>> > Just not the best design IMO.
>> >
>> >
>> >> On Jan 4, 2016, at 8:18 AM, lb <[hidden email]> wrote:
>> >>
>> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>
>> >>
>> >> Yes SessionID identifies a session but you may want to as example
>> >> enrich the message and send it to another fix session, this is quite
>> >> common for FIX hubs that may aggregate spit messagese according to
>> >> some rules.
>> >> Yes I'd like to have Session as an interface and not static so I may
>> >> also have multiple session in the same process.
>> >>
>> >> On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <[hidden email]> wrote:
>> >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>>
>> >>>
>> >>> The SessionID implies a specific session...
>> >>>
>> >>> What you want to do is make Session extensible with a factory so different implementations can be used....
>> >>>
>> >>>> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>> >>>>
>> >>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>>>
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> in the pas I've hacked quickfixj to replace static Session objects
>> >>>> with a FixContext so as example the classic onMessage would become:
>> >>>>
>> >>>>   public void fromApp(FixContext context, Message message, SessionID
>> >>>> sessionID) {
>> >>>>       ...
>> >>>>       context.sendToTarget(...);
>> >>>>   }
>> >>>>
>> >>>>
>> >>>> The reason of that was:
>> >>>> - add probes and additional validations/enrichments for messages sent
>> >>>> by one target to another one
>> >>>> - add a distributed FixContext so targets on different JVMs can talk
>> >>>> (i.e. via hazelcast)
>> >>>>
>> >>>>
>> >>>> If it make sense for anyone I can work to merge my work in main code base.
>> >>>>
>> >>>>
>> >>>> Regards,
>> >>>> Luca
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> _______________________________________________
>> >>>> Quickfixj-users mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> _______________________________________________
>> >>> Quickfixj-users mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >>
>> >> ------------------------------------------------------------------------------
>> >> _______________________________________________
>> >> Quickfixj-users mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Quickfixj-users mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
>
>
> --
>
> Robert Engels
>
>
>
> OptionsCity Software
> 200 W. Adams St., Suite 1010
> Chicago, IL 60606
>
> O. +1 (312) 605-4500 | F. +1 (312) 635-1751
>
>
>
> All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>
>
>
> Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
lb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Obvuously this may be confusing as a session is bound to a single session and that is why I've initially added the FixContext as it is where sessions and runtime information about a particular fix engine instance are registered.

A FixContext can then be shareable or provided externally i.e. it can be provided as an osgi service or via dependency injection in spring.

This could also be named SessionManager but imho context would make it clearer.

In any case let me know if there is any interest in such development which imp would make quickfixj more flexible and I will work on it.

On Monday, 4 January 2016, lb <[hidden email]> wrote:
Obviously the Session interface is then used in onMessage(Session
session , ....)

On Mon, Jan 4, 2016 at 5:17 PM, Robert Engels <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;rengels@optionscity.com&#39;)">rengels@...> wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> This does not resolve the static class issue - as I assume beneath the hood you still use Session - so, for example, there may be two different implementations that use two different version of QuickFixJ - that is why the OSGI needs to handle this using class loaders.
>
> On Mon, Jan 4, 2016 at 9:23 AM, lb <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;lburgazzoli@gmail.com&#39;)">lburgazzoli@...> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Yes that's correct, FixContext is just a non static and extensible
>> Session I pass to the initiator/acceptors and I've added to
>> Application methods :
>>
>>     Acceptor acceptor = new SocketAcceptor(
>>         session,
>>         application,
>>         storeFactory,
>>         settings,
>>         logFactory,
>>         messageFactory
>>     );
>>
>> The reason I need an non static class is as example I want to load
>> multiple fix engines inside a container (i.e. OSGi) and I do not want
>> the sessions to mess up each others.
>>
>>
>> On Mon, Jan 4, 2016 at 3:31 PM, Robert Engels <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;rengels@optionscity.com&#39;)">rengels@...> wrote:
>> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> > QuickFIX/J Support: http://www.quickfixj.org/support/
>> >
>> >
>> > But there is no difference in what you are doing then just handling the “context” higher up - as all of the application code needs to know about and pass around the context… plus it has to worry about context to session mapping.
>> >
>> > All you’ve done is change Session for FixContext and make FixContext extensible - just make Session instances “extensible" and you’ve accomplished the same thing in a far cleaner way.
>> >
>> > Just not the best design IMO.
>> >
>> >
>> >> On Jan 4, 2016, at 8:18 AM, lb <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;lburgazzoli@gmail.com&#39;)">lburgazzoli@...> wrote:
>> >>
>> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>
>> >>
>> >> Yes SessionID identifies a session but you may want to as example
>> >> enrich the message and send it to another fix session, this is quite
>> >> common for FIX hubs that may aggregate spit messagese according to
>> >> some rules.
>> >> Yes I'd like to have Session as an interface and not static so I may
>> >> also have multiple session in the same process.
>> >>
>> >> On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;rengels@optionscity.com&#39;)">rengels@...> wrote:
>> >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>>
>> >>>
>> >>> The SessionID implies a specific session...
>> >>>
>> >>> What you want to do is make Session extensible with a factory so different implementations can be used....
>> >>>
>> >>>> On Jan 4, 2016, at 3:56 AM, lb <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;lburgazzoli@gmail.com&#39;)">lburgazzoli@...> wrote:
>> >>>>
>> >>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>>>
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> in the pas I've hacked quickfixj to replace static Session objects
>> >>>> with a FixContext so as example the classic onMessage would become:
>> >>>>
>> >>>>   public void fromApp(FixContext context, Message message, SessionID
>> >>>> sessionID) {
>> >>>>       ...
>> >>>>       context.sendToTarget(...);
>> >>>>   }
>> >>>>
>> >>>>
>> >>>> The reason of that was:
>> >>>> - add probes and additional validations/enrichments for messages sent
>> >>>> by one target to another one
>> >>>> - add a distributed FixContext so targets on different JVMs can talk
>> >>>> (i.e. via hazelcast)
>> >>>>
>> >>>>
>> >>>> If it make sense for anyone I can work to merge my work in main code base.
>> >>>>
>> >>>>
>> >>>> Regards,
>> >>>> Luca
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> _______________________________________________
>> >>>> Quickfixj-users mailing list
>> >>>> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Quickfixj-users@lists.sourceforge.net&#39;)">Quickfixj-users@...
>> >>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> _______________________________________________
>> >>> Quickfixj-users mailing list
>> >>> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Quickfixj-users@lists.sourceforge.net&#39;)">Quickfixj-users@...
>> >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >>
>> >> ------------------------------------------------------------------------------
>> >> _______________________________________________
>> >> Quickfixj-users mailing list
>> >> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Quickfixj-users@lists.sourceforge.net&#39;)">Quickfixj-users@...
>> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Quickfixj-users mailing list
>> > <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Quickfixj-users@lists.sourceforge.net&#39;)">Quickfixj-users@...
>> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Quickfixj-users@lists.sourceforge.net&#39;)">Quickfixj-users@...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
>
>
> --
>
> Robert Engels
>
>
>
> OptionsCity Software
> 200 W. Adams St., Suite 1010
> Chicago, IL 60606
>
> O. +1 (312) 605-4500 | F. +1 (312) 635-1751
>
>
>
> All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>
>
>
> Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Quickfixj-users mailing list
> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Quickfixj-users@lists.sourceforge.net&#39;)">Quickfixj-users@...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Why not just have the static Session.send() perform a lookup (if registered) of the implementation (assigned to the SessionID), and defer to it, rather than changing the top-level API for an optional (and probably rarely needed) feature, and move the session guts to the base/default implementation.

On Mon, Jan 4, 2016 at 12:39 PM, lb <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Obvuously this may be confusing as a session is bound to a single session and that is why I've initially added the FixContext as it is where sessions and runtime information about a particular fix engine instance are registered.

A FixContext can then be shareable or provided externally i.e. it can be provided as an osgi service or via dependency injection in spring.

This could also be named SessionManager but imho context would make it clearer.

In any case let me know if there is any interest in such development which imp would make quickfixj more flexible and I will work on it.

On Monday, 4 January 2016, lb <[hidden email]> wrote:
Obviously the Session interface is then used in onMessage(Session
session , ....)

On Mon, Jan 4, 2016 at 5:17 PM, Robert Engels <[hidden email]> wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> This does not resolve the static class issue - as I assume beneath the hood you still use Session - so, for example, there may be two different implementations that use two different version of QuickFixJ - that is why the OSGI needs to handle this using class loaders.
>
> On Mon, Jan 4, 2016 at 9:23 AM, lb <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Yes that's correct, FixContext is just a non static and extensible
>> Session I pass to the initiator/acceptors and I've added to
>> Application methods :
>>
>>     Acceptor acceptor = new SocketAcceptor(
>>         session,
>>         application,
>>         storeFactory,
>>         settings,
>>         logFactory,
>>         messageFactory
>>     );
>>
>> The reason I need an non static class is as example I want to load
>> multiple fix engines inside a container (i.e. OSGi) and I do not want
>> the sessions to mess up each others.
>>
>>
>> On Mon, Jan 4, 2016 at 3:31 PM, Robert Engels <[hidden email]> wrote:
>> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> > QuickFIX/J Support: http://www.quickfixj.org/support/
>> >
>> >
>> > But there is no difference in what you are doing then just handling the “context” higher up - as all of the application code needs to know about and pass around the context… plus it has to worry about context to session mapping.
>> >
>> > All you’ve done is change Session for FixContext and make FixContext extensible - just make Session instances “extensible" and you’ve accomplished the same thing in a far cleaner way.
>> >
>> > Just not the best design IMO.
>> >
>> >
>> >> On Jan 4, 2016, at 8:18 AM, lb <[hidden email]> wrote:
>> >>
>> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>
>> >>
>> >> Yes SessionID identifies a session but you may want to as example
>> >> enrich the message and send it to another fix session, this is quite
>> >> common for FIX hubs that may aggregate spit messagese according to
>> >> some rules.
>> >> Yes I'd like to have Session as an interface and not static so I may
>> >> also have multiple session in the same process.
>> >>
>> >> On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <[hidden email]> wrote:
>> >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>>
>> >>>
>> >>> The SessionID implies a specific session...
>> >>>
>> >>> What you want to do is make Session extensible with a factory so different implementations can be used....
>> >>>
>> >>>> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>> >>>>
>> >>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>>>
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> in the pas I've hacked quickfixj to replace static Session objects
>> >>>> with a FixContext so as example the classic onMessage would become:
>> >>>>
>> >>>>   public void fromApp(FixContext context, Message message, SessionID
>> >>>> sessionID) {
>> >>>>       ...
>> >>>>       context.sendToTarget(...);
>> >>>>   }
>> >>>>
>> >>>>
>> >>>> The reason of that was:
>> >>>> - add probes and additional validations/enrichments for messages sent
>> >>>> by one target to another one
>> >>>> - add a distributed FixContext so targets on different JVMs can talk
>> >>>> (i.e. via hazelcast)
>> >>>>
>> >>>>
>> >>>> If it make sense for anyone I can work to merge my work in main code base.
>> >>>>
>> >>>>
>> >>>> Regards,
>> >>>> Luca
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> _______________________________________________
>> >>>> Quickfixj-users mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> _______________________________________________
>> >>> Quickfixj-users mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >>
>> >> ------------------------------------------------------------------------------
>> >> _______________________________________________
>> >> Quickfixj-users mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Quickfixj-users mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
>
>
> --
>
> Robert Engels
>
>
>
> OptionsCity Software
> 200 W. Adams St., Suite 1010
> Chicago, IL 60606
>
> O. <a href="tel:%2B1%20%28312%29%20605-4500" value="+13126054500" target="_blank">+1 (312) 605-4500 | F. <a href="tel:%2B1%20%28312%29%20635-1751" value="+13126351751" target="_blank">+1 (312) 635-1751
>
>
>
> All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>
>
>
> Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users




--

Robert Engels

 

OptionsCity Software
200 W. Adams St., Suite 1010
Chicago, IL 60606

O. +1 (312) 605-4500 | F. +1 (312) 635-1751 

 

All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.

 

Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook

 

 


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

Jose Chavez
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I've been following the discussion. It seems to me that the FIXContext is not a good design for QuickFIX/J. QFJ by itself is a FIX engine; the FIXContent aims to hold information about a set of FIX engines for the purpose of FIX routing.

The Camel QFJ component does something similar, where it route messages between endpoints. The developer has control over routing and message transformation. Maybe you can give Apache Camel a try, and see if this would be a good fit for your problem?


On Mon, Jan 4, 2016 at 12:50 PM Robert Engels <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


Why not just have the static Session.send() perform a lookup (if registered) of the implementation (assigned to the SessionID), and defer to it, rather than changing the top-level API for an optional (and probably rarely needed) feature, and move the session guts to the base/default implementation.

On Mon, Jan 4, 2016 at 12:39 PM, lb <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/



Obvuously this may be confusing as a session is bound to a single session and that is why I've initially added the FixContext as it is where sessions and runtime information about a particular fix engine instance are registered.

A FixContext can then be shareable or provided externally i.e. it can be provided as an osgi service or via dependency injection in spring.

This could also be named SessionManager but imho context would make it clearer.

In any case let me know if there is any interest in such development which imp would make quickfixj more flexible and I will work on it.

On Monday, 4 January 2016, lb <[hidden email]> wrote:
Obviously the Session interface is then used in onMessage(Session
session , ....)

On Mon, Jan 4, 2016 at 5:17 PM, Robert Engels <[hidden email]> wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> This does not resolve the static class issue - as I assume beneath the hood you still use Session - so, for example, there may be two different implementations that use two different version of QuickFixJ - that is why the OSGI needs to handle this using class loaders.
>
> On Mon, Jan 4, 2016 at 9:23 AM, lb <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Yes that's correct, FixContext is just a non static and extensible
>> Session I pass to the initiator/acceptors and I've added to
>> Application methods :
>>
>>     Acceptor acceptor = new SocketAcceptor(
>>         session,
>>         application,
>>         storeFactory,
>>         settings,
>>         logFactory,
>>         messageFactory
>>     );
>>
>> The reason I need an non static class is as example I want to load
>> multiple fix engines inside a container (i.e. OSGi) and I do not want
>> the sessions to mess up each others.
>>
>>
>> On Mon, Jan 4, 2016 at 3:31 PM, Robert Engels <[hidden email]> wrote:
>> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> > QuickFIX/J Support: http://www.quickfixj.org/support/
>> >
>> >
>> > But there is no difference in what you are doing then just handling the “context” higher up - as all of the application code needs to know about and pass around the context… plus it has to worry about context to session mapping.
>> >
>> > All you’ve done is change Session for FixContext and make FixContext extensible - just make Session instances “extensible" and you’ve accomplished the same thing in a far cleaner way.
>> >
>> > Just not the best design IMO.
>> >
>> >
>> >> On Jan 4, 2016, at 8:18 AM, lb <[hidden email]> wrote:
>> >>
>> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>
>> >>
>> >> Yes SessionID identifies a session but you may want to as example
>> >> enrich the message and send it to another fix session, this is quite
>> >> common for FIX hubs that may aggregate spit messagese according to
>> >> some rules.
>> >> Yes I'd like to have Session as an interface and not static so I may
>> >> also have multiple session in the same process.
>> >>
>> >> On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <[hidden email]> wrote:
>> >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>>
>> >>>
>> >>> The SessionID implies a specific session...
>> >>>
>> >>> What you want to do is make Session extensible with a factory so different implementations can be used....
>> >>>
>> >>>> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>> >>>>
>> >>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> >>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> >>>>
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> in the pas I've hacked quickfixj to replace static Session objects
>> >>>> with a FixContext so as example the classic onMessage would become:
>> >>>>
>> >>>>   public void fromApp(FixContext context, Message message, SessionID
>> >>>> sessionID) {
>> >>>>       ...
>> >>>>       context.sendToTarget(...);
>> >>>>   }
>> >>>>
>> >>>>
>> >>>> The reason of that was:
>> >>>> - add probes and additional validations/enrichments for messages sent
>> >>>> by one target to another one
>> >>>> - add a distributed FixContext so targets on different JVMs can talk
>> >>>> (i.e. via hazelcast)
>> >>>>
>> >>>>
>> >>>> If it make sense for anyone I can work to merge my work in main code base.
>> >>>>
>> >>>>
>> >>>> Regards,
>> >>>> Luca
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> _______________________________________________
>> >>>> Quickfixj-users mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> _______________________________________________
>> >>> Quickfixj-users mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >>
>> >> ------------------------------------------------------------------------------
>> >> _______________________________________________
>> >> Quickfixj-users mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Quickfixj-users mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
>
>
> --
>
> Robert Engels
>
>
>
> OptionsCity Software
> 200 W. Adams St., Suite 1010
> Chicago, IL 60606
>
> O. <a href="tel:%2B1%20%28312%29%20605-4500" value="+13126054500" target="_blank">+1 (312) 605-4500 | F. <a href="tel:%2B1%20%28312%29%20635-1751" value="+13126351751" target="_blank">+1 (312) 635-1751
>
>
>
> All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>
>
>
> Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users




--

Robert Engels

 

OptionsCity Software
200 W. Adams St., Suite 1010
Chicago, IL 60606

O. +1 (312) 605-4500 | F. +1 (312) 635-1751 

 

All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.

 

Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook

 

 

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
--
Jose E. Chavez

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
lb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I'm very familiar with camel-quickfix as I've been using it for quite
a few time now but for some context it is not flexible enough, that
also true for quickfix-j and that is the reason of my proposal however
I clearly see the point so I'm wondering if adding a session factory
and a delegate for session operation would be acceptable with the
constraints that for an enduser not interested in such advanced
features, the behaviour won't change.



On Mon, Jan 4, 2016 at 9:05 PM, Jose Chavez <[hidden email]> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> I've been following the discussion. It seems to me that the FIXContext is not a good design for QuickFIX/J. QFJ by itself is a FIX engine; the FIXContent aims to hold information about a set of FIX engines for the purpose of FIX routing.
>
> The Camel QFJ component does something similar, where it route messages between endpoints. The developer has control over routing and message transformation. Maybe you can give Apache Camel a try, and see if this would be a good fit for your problem?
>
> http://camel.apache.org/quickfix.html
>
>
> On Mon, Jan 4, 2016 at 12:50 PM Robert Engels <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Why not just have the static Session.send() perform a lookup (if registered) of the implementation (assigned to the SessionID), and defer to it, rather than changing the top-level API for an optional (and probably rarely needed) feature, and move the session guts to the base/default implementation.
>>
>> On Mon, Jan 4, 2016 at 12:39 PM, lb <[hidden email]> wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>>
>>> Obvuously this may be confusing as a session is bound to a single session and that is why I've initially added the FixContext as it is where sessions and runtime information about a particular fix engine instance are registered.
>>>
>>> A FixContext can then be shareable or provided externally i.e. it can be provided as an osgi service or via dependency injection in spring.
>>>
>>> This could also be named SessionManager but imho context would make it clearer.
>>>
>>> In any case let me know if there is any interest in such development which imp would make quickfixj more flexible and I will work on it.
>>>
>>> On Monday, 4 January 2016, lb <[hidden email]> wrote:
>>>>
>>>> Obviously the Session interface is then used in onMessage(Session
>>>> session , ....)
>>>>
>>>> On Mon, Jan 4, 2016 at 5:17 PM, Robert Engels <[hidden email]> wrote:
>>>> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> > QuickFIX/J Support: http://www.quickfixj.org/support/
>>>> >
>>>> >
>>>> >
>>>> > This does not resolve the static class issue - as I assume beneath the hood you still use Session - so, for example, there may be two different implementations that use two different version of QuickFixJ - that is why the OSGI needs to handle this using class loaders.
>>>> >
>>>> > On Mon, Jan 4, 2016 at 9:23 AM, lb <[hidden email]> wrote:
>>>> >>
>>>> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> >> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>> >>
>>>> >>
>>>> >> Yes that's correct, FixContext is just a non static and extensible
>>>> >> Session I pass to the initiator/acceptors and I've added to
>>>> >> Application methods :
>>>> >>
>>>> >>     Acceptor acceptor = new SocketAcceptor(
>>>> >>         session,
>>>> >>         application,
>>>> >>         storeFactory,
>>>> >>         settings,
>>>> >>         logFactory,
>>>> >>         messageFactory
>>>> >>     );
>>>> >>
>>>> >> The reason I need an non static class is as example I want to load
>>>> >> multiple fix engines inside a container (i.e. OSGi) and I do not want
>>>> >> the sessions to mess up each others.
>>>> >>
>>>> >>
>>>> >> On Mon, Jan 4, 2016 at 3:31 PM, Robert Engels <[hidden email]> wrote:
>>>> >> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> >> > QuickFIX/J Support: http://www.quickfixj.org/support/
>>>> >> >
>>>> >> >
>>>> >> > But there is no difference in what you are doing then just handling the “context” higher up - as all of the application code needs to know about and pass around the context… plus it has to worry about context to session mapping.
>>>> >> >
>>>> >> > All you’ve done is change Session for FixContext and make FixContext extensible - just make Session instances “extensible" and you’ve accomplished the same thing in a far cleaner way.
>>>> >> >
>>>> >> > Just not the best design IMO.
>>>> >> >
>>>> >> >
>>>> >> >> On Jan 4, 2016, at 8:18 AM, lb <[hidden email]> wrote:
>>>> >> >>
>>>> >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> >> >> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>> >> >>
>>>> >> >>
>>>> >> >> Yes SessionID identifies a session but you may want to as example
>>>> >> >> enrich the message and send it to another fix session, this is quite
>>>> >> >> common for FIX hubs that may aggregate spit messagese according to
>>>> >> >> some rules.
>>>> >> >> Yes I'd like to have Session as an interface and not static so I may
>>>> >> >> also have multiple session in the same process.
>>>> >> >>
>>>> >> >> On Mon, Jan 4, 2016 at 2:34 PM, Robert Engels <[hidden email]> wrote:
>>>> >> >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> >> >>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> The SessionID implies a specific session...
>>>> >> >>>
>>>> >> >>> What you want to do is make Session extensible with a factory so different implementations can be used....
>>>> >> >>>
>>>> >> >>>> On Jan 4, 2016, at 3:56 AM, lb <[hidden email]> wrote:
>>>> >> >>>>
>>>> >> >>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> >> >>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> Hi all,
>>>> >> >>>>
>>>> >> >>>> in the pas I've hacked quickfixj to replace static Session objects
>>>> >> >>>> with a FixContext so as example the classic onMessage would become:
>>>> >> >>>>
>>>> >> >>>>   public void fromApp(FixContext context, Message message, SessionID
>>>> >> >>>> sessionID) {
>>>> >> >>>>       ...
>>>> >> >>>>       context.sendToTarget(...);
>>>> >> >>>>   }
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> The reason of that was:
>>>> >> >>>> - add probes and additional validations/enrichments for messages sent
>>>> >> >>>> by one target to another one
>>>> >> >>>> - add a distributed FixContext so targets on different JVMs can talk
>>>> >> >>>> (i.e. via hazelcast)
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> If it make sense for anyone I can work to merge my work in main code base.
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> Regards,
>>>> >> >>>> Luca
>>>> >> >>>>
>>>> >> >>>> ------------------------------------------------------------------------------
>>>> >> >>>> _______________________________________________
>>>> >> >>>> Quickfixj-users mailing list
>>>> >> >>>> [hidden email]
>>>> >> >>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>> >> >>>
>>>> >> >>> ------------------------------------------------------------------------------
>>>> >> >>> _______________________________________________
>>>> >> >>> Quickfixj-users mailing list
>>>> >> >>> [hidden email]
>>>> >> >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>> >> >>
>>>> >> >> ------------------------------------------------------------------------------
>>>> >> >> _______________________________________________
>>>> >> >> Quickfixj-users mailing list
>>>> >> >> [hidden email]
>>>> >> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>> >> >
>>>> >> >
>>>> >> > ------------------------------------------------------------------------------
>>>> >> > _______________________________________________
>>>> >> > Quickfixj-users mailing list
>>>> >> > [hidden email]
>>>> >> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>> >>
>>>> >> ------------------------------------------------------------------------------
>>>> >> _______________________________________________
>>>> >> Quickfixj-users mailing list
>>>> >> [hidden email]
>>>> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > Robert Engels
>>>> >
>>>> >
>>>> >
>>>> > OptionsCity Software
>>>> > 200 W. Adams St., Suite 1010
>>>> > Chicago, IL 60606
>>>> >
>>>> > O. +1 (312) 605-4500 | F. +1 (312) 635-1751
>>>> >
>>>> >
>>>> >
>>>> > All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>>>> >
>>>> >
>>>> >
>>>> > Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> >
>>>> > _______________________________________________
>>>> > Quickfixj-users mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>
>>
>>
>> --
>>
>> Robert Engels
>>
>>
>>
>> OptionsCity Software
>> 200 W. Adams St., Suite 1010
>> Chicago, IL 60606
>>
>> O. +1 (312) 605-4500 | F. +1 (312) 635-1751
>>
>>
>>
>> All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>>
>>
>>
>> Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> --
> Jose E. Chavez
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

Tod Harter
In reply to this post by lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Well, the 'classic' solution is pretty straightforward, which is to simply provide a lookup table for application context that indexed on SessionID. This will allow you to keep track of any per-session state independent of QF/J itself. You could probably use a thread local for this if you wished, though I'm not sure why it would really be beneficial, it would still have to be assigned via a lookup in a table, just at some other point in the code...

On Mon, Jan 4, 2016 at 8:53 AM, <[hidden email]> wrote:
Message: 5
Date: Mon, 4 Jan 2016 08:31:25 -0600
From: Robert Engels <[hidden email]>
Subject: Re: [Quickfixj-users] FixContext instead fo static Session
To: "[hidden email]"
        <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

But there is no difference in what you are doing then just handling the ?context? higher up - as all of the application code needs to know about and pass around the context? plus it has to worry about context to session mapping.

All you?ve done is change Session for FixContext and make FixContext extensible - just make Session instances ?extensible" and you?ve accomplished the same thing in a far cleaner way.

Just not the best design IMO.



“Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened.” -Winston Churchill

"Sometimes I wonder whether the world is being run by smart people who are putting us on, or by imbeciles who really mean it." - Mark Twain

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Correct, that can be done without change the quickfix API... which is what I was suggesting...

On Mon, Jan 4, 2016 at 5:22 PM, Tod Harter <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Well, the 'classic' solution is pretty straightforward, which is to simply provide a lookup table for application context that indexed on SessionID. This will allow you to keep track of any per-session state independent of QF/J itself. You could probably use a thread local for this if you wished, though I'm not sure why it would really be beneficial, it would still have to be assigned via a lookup in a table, just at some other point in the code...

On Mon, Jan 4, 2016 at 8:53 AM, <[hidden email]> wrote:
Message: 5
Date: Mon, 4 Jan 2016 08:31:25 -0600
From: Robert Engels <[hidden email]>
Subject: Re: [Quickfixj-users] FixContext instead fo static Session
To: "[hidden email]"
        <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

But there is no difference in what you are doing then just handling the ?context? higher up - as all of the application code needs to know about and pass around the context? plus it has to worry about context to session mapping.

All you?ve done is change Session for FixContext and make FixContext extensible - just make Session instances ?extensible" and you?ve accomplished the same thing in a far cleaner way.

Just not the best design IMO.



“Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened.” -Winston Churchill

"Sometimes I wonder whether the world is being run by smart people who are putting us on, or by imbeciles who really mean it." - Mark Twain

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users




--

Robert Engels

 

OptionsCity Software
200 W. Adams St., Suite 1010
Chicago, IL 60606

O. +1 (312) 605-4500 | F. +1 (312) 635-1751 

 

All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.

 

Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook

 

 


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
lb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I can do everything in my application logic as I always did, but here
the goal is to provide something to community so maybe other people do
not need to write it again.

If Session were an interface and I had the possibility to customize
how sessions are managed, I would work to implement an open source
distributes session manager that allow different quickfix-j engines to
talk together whatever they are in the same JVM or distributed across
different servers.

Anyway, I will do so in my application logic.



On Tue, Jan 5, 2016 at 12:32 AM, Robert Engels <[hidden email]> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Correct, that can be done without change the quickfix API... which is what I was suggesting...
>
> On Mon, Jan 4, 2016 at 5:22 PM, Tod Harter <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>>
>> Well, the 'classic' solution is pretty straightforward, which is to simply provide a lookup table for application context that indexed on SessionID. This will allow you to keep track of any per-session state independent of QF/J itself. You could probably use a thread local for this if you wished, though I'm not sure why it would really be beneficial, it would still have to be assigned via a lookup in a table, just at some other point in the code...
>>
>> On Mon, Jan 4, 2016 at 8:53 AM, <[hidden email]> wrote:
>>>
>>> Message: 5
>>> Date: Mon, 4 Jan 2016 08:31:25 -0600
>>> From: Robert Engels <[hidden email]>
>>> Subject: Re: [Quickfixj-users] FixContext instead fo static Session
>>> To: "[hidden email]"
>>>         <[hidden email]>
>>> Message-ID: <[hidden email]>
>>> Content-Type: text/plain; charset=utf-8
>>>
>>> But there is no difference in what you are doing then just handling the ?context? higher up - as all of the application code needs to know about and pass around the context? plus it has to worry about context to session mapping.
>>>
>>> All you?ve done is change Session for FixContext and make FixContext extensible - just make Session instances ?extensible" and you?ve accomplished the same thing in a far cleaner way.
>>>
>>> Just not the best design IMO.
>>
>>
>>
>>
>> “Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened.” -Winston Churchill
>>
>> "Sometimes I wonder whether the world is being run by smart people who are putting us on, or by imbeciles who really mean it." - Mark Twain
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>
>
>
> --
>
> Robert Engels
>
>
>
> OptionsCity Software
> 200 W. Adams St., Suite 1010
> Chicago, IL 60606
>
> O. +1 (312) 605-4500 | F. +1 (312) 635-1751
>
>
>
> All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>
>
>
> Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


There's no need to take your ball and go home...

First, different quickfixj engines can already communicate in process, intra process and inter machine. They use TCP...

You were planning on posting "changes" to offer new features. I was attempting to show you a way to do so that wouldn't break all existing code... That is the concern. If you're intent on doing that it will probably never be accepted into the mainline unless it solved difficult problems that are not solvable any other way...

You can make Session extensible/replaceable without affecting existing code...

> On Jan 5, 2016, at 2:34 AM, lb <[hidden email]> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> I can do everything in my application logic as I always did, but here
> the goal is to provide something to community so maybe other people do
> not need to write it again.
>
> If Session were an interface and I had the possibility to customize
> how sessions are managed, I would work to implement an open source
> distributes session manager that allow different quickfix-j engines to
> talk together whatever they are in the same JVM or distributed across
> different servers.
>
> Anyway, I will do so in my application logic.
>
>
>
>> On Tue, Jan 5, 2016 at 12:32 AM, Robert Engels <[hidden email]> wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>>
>> Correct, that can be done without change the quickfix API... which is what I was suggesting...
>>
>>> On Mon, Jan 4, 2016 at 5:22 PM, Tod Harter <[hidden email]> wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>>
>>> Well, the 'classic' solution is pretty straightforward, which is to simply provide a lookup table for application context that indexed on SessionID. This will allow you to keep track of any per-session state independent of QF/J itself. You could probably use a thread local for this if you wished, though I'm not sure why it would really be beneficial, it would still have to be assigned via a lookup in a table, just at some other point in the code...
>>>
>>>> On Mon, Jan 4, 2016 at 8:53 AM, <[hidden email]> wrote:
>>>>
>>>> Message: 5
>>>> Date: Mon, 4 Jan 2016 08:31:25 -0600
>>>> From: Robert Engels <[hidden email]>
>>>> Subject: Re: [Quickfixj-users] FixContext instead fo static Session
>>>> To: "[hidden email]"
>>>>        <[hidden email]>
>>>> Message-ID: <[hidden email]>
>>>> Content-Type: text/plain; charset=utf-8
>>>>
>>>> But there is no difference in what you are doing then just handling the ?context? higher up - as all of the application code needs to know about and pass around the context? plus it has to worry about context to session mapping.
>>>>
>>>> All you?ve done is change Session for FixContext and make FixContext extensible - just make Session instances ?extensible" and you?ve accomplished the same thing in a far cleaner way.
>>>>
>>>> Just not the best design IMO.
>>>
>>>
>>>
>>>
>>> “Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened.” -Winston Churchill
>>>
>>> "Sometimes I wonder whether the world is being run by smart people who are putting us on, or by imbeciles who really mean it." - Mark Twain
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>>
>>
>> --
>>
>> Robert Engels
>>
>>
>>
>> OptionsCity Software
>> 200 W. Adams St., Suite 1010
>> Chicago, IL 60606
>>
>> O. +1 (312) 605-4500 | F. +1 (312) 635-1751
>>
>>
>>
>> All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>>
>>
>>
>> Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
lb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I'm not going home, I've still some code that might be merged :-) but
I won't go ahead with this "enhancement proposal"



On Tue, Jan 5, 2016 at 1:52 PM, Robert Engels <[hidden email]> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> There's no need to take your ball and go home...
>
> First, different quickfixj engines can already communicate in process, intra process and inter machine. They use TCP...
>
> You were planning on posting "changes" to offer new features. I was attempting to show you a way to do so that wouldn't break all existing code... That is the concern. If you're intent on doing that it will probably never be accepted into the mainline unless it solved difficult problems that are not solvable any other way...
>
> You can make Session extensible/replaceable without affecting existing code...
>
>> On Jan 5, 2016, at 2:34 AM, lb <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> I can do everything in my application logic as I always did, but here
>> the goal is to provide something to community so maybe other people do
>> not need to write it again.
>>
>> If Session were an interface and I had the possibility to customize
>> how sessions are managed, I would work to implement an open source
>> distributes session manager that allow different quickfix-j engines to
>> talk together whatever they are in the same JVM or distributed across
>> different servers.
>>
>> Anyway, I will do so in my application logic.
>>
>>
>>
>>> On Tue, Jan 5, 2016 at 12:32 AM, Robert Engels <[hidden email]> wrote:
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>>
>>> Correct, that can be done without change the quickfix API... which is what I was suggesting...
>>>
>>>> On Mon, Jan 4, 2016 at 5:22 PM, Tod Harter <[hidden email]> wrote:
>>>>
>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>
>>>>
>>>>
>>>> Well, the 'classic' solution is pretty straightforward, which is to simply provide a lookup table for application context that indexed on SessionID. This will allow you to keep track of any per-session state independent of QF/J itself. You could probably use a thread local for this if you wished, though I'm not sure why it would really be beneficial, it would still have to be assigned via a lookup in a table, just at some other point in the code...
>>>>
>>>>> On Mon, Jan 4, 2016 at 8:53 AM, <[hidden email]> wrote:
>>>>>
>>>>> Message: 5
>>>>> Date: Mon, 4 Jan 2016 08:31:25 -0600
>>>>> From: Robert Engels <[hidden email]>
>>>>> Subject: Re: [Quickfixj-users] FixContext instead fo static Session
>>>>> To: "[hidden email]"
>>>>>        <[hidden email]>
>>>>> Message-ID: <[hidden email]>
>>>>> Content-Type: text/plain; charset=utf-8
>>>>>
>>>>> But there is no difference in what you are doing then just handling the ?context? higher up - as all of the application code needs to know about and pass around the context? plus it has to worry about context to session mapping.
>>>>>
>>>>> All you?ve done is change Session for FixContext and make FixContext extensible - just make Session instances ?extensible" and you?ve accomplished the same thing in a far cleaner way.
>>>>>
>>>>> Just not the best design IMO.
>>>>
>>>>
>>>>
>>>>
>>>> “Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened.” -Winston Churchill
>>>>
>>>> "Sometimes I wonder whether the world is being run by smart people who are putting us on, or by imbeciles who really mean it." - Mark Twain
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Quickfixj-users mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>>
>>>
>>> --
>>>
>>> Robert Engels
>>>
>>>
>>>
>>> OptionsCity Software
>>> 200 W. Adams St., Suite 1010
>>> Chicago, IL 60606
>>>
>>> O. +1 (312) 605-4500 | F. +1 (312) 635-1751
>>>
>>>
>>>
>>> All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>>>
>>>
>>>
>>> Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FixContext instead fo static Session

Tod Harter
In reply to this post by lb
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Well, our product basically fits this discription, in part. Lets say at least that we move FIX messages back and forth between various points, some of which are clients (initiators) and some of which are servers (acceptors). Everything flows up to the application layer, and each class of endpoint has its own initiator/acceptor, and possibly its own classloader if necessary. Any state that needs to be carried between QF/J stacks is attached to the messages, which are normally translated into an internal application-neutral format.
Now, maybe not everyone has so much application logic, maybe they simply need to reflect a FIX message to another client (IE make a drop copy), so perhaps you want something closer to the FIX layer, but it seems to me that if you were likely to have different FIX protocol versions and whatnot on different connections, then there's little or nothing to be gained by sharing session info. At the application level everything is keyed on 'internal identifiers', which are mapped to 'external identifiers' at each gateway and back as needed. In fact we completely divorce all the internal handling logic from questions of HOW it was received, so FIX, FIXML, SOAP over HTTP or JMS, JSON transported by various methods, etc are all brokered in and out as needed, and different clients can subscribe to each order flow in a protocol-independent manner.

Truthfully what would be most valuable in terms of dealing with a lot of different FIX endpoints is improvements in class structure within QF/J so that different versions of FIX can be handled within the scope of a single classloader, or at least that you don't have to chew up megabytes of permgen because of loading 12 different flavors of QF/J at one time.

“Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened.” -Winston Churchill

"Sometimes I wonder whether the world is being run by smart people who are putting us on, or by imbeciles who really mean it." - Mark Twain

On Tue, Jan 5, 2016 at 2:34 AM, lb <[hidden email]> wrote:
I can do everything in my application logic as I always did, but here
the goal is to provide something to community so maybe other people do
not need to write it again.

If Session were an interface and I had the possibility to customize
how sessions are managed, I would work to implement an open source
distributes session manager that allow different quickfix-j engines to
talk together whatever they are in the same JVM or distributed across
different servers.

Anyway, I will do so in my application logic.



On Tue, Jan 5, 2016 at 12:32 AM, Robert Engels <[hidden email]> wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Correct, that can be done without change the quickfix API... which is what I was suggesting...
>
> On Mon, Jan 4, 2016 at 5:22 PM, Tod Harter <[hidden email]> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>>
>> Well, the 'classic' solution is pretty straightforward, which is to simply provide a lookup table for application context that indexed on SessionID. This will allow you to keep track of any per-session state independent of QF/J itself. You could probably use a thread local for this if you wished, though I'm not sure why it would really be beneficial, it would still have to be assigned via a lookup in a table, just at some other point in the code...
>>
>> On Mon, Jan 4, 2016 at 8:53 AM, <[hidden email]> wrote:
>>>
>>> Message: 5
>>> Date: Mon, 4 Jan 2016 08:31:25 -0600
>>> From: Robert Engels <[hidden email]>
>>> Subject: Re: [Quickfixj-users] FixContext instead fo static Session
>>> To: "[hidden email]"
>>>         <[hidden email]>
>>> Message-ID: <[hidden email]>
>>> Content-Type: text/plain; charset=utf-8
>>>
>>> But there is no difference in what you are doing then just handling the ?context? higher up - as all of the application code needs to know about and pass around the context? plus it has to worry about context to session mapping.
>>>
>>> All you?ve done is change Session for FixContext and make FixContext extensible - just make Session instances ?extensible" and you?ve accomplished the same thing in a far cleaner way.
>>>
>>> Just not the best design IMO.
>>
>>
>>
>>
>> “Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened.” -Winston Churchill
>>
>> "Sometimes I wonder whether the world is being run by smart people who are putting us on, or by imbeciles who really mean it." - Mark Twain
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>
>
>
> --
>
> Robert Engels
>
>
>
> OptionsCity Software
> 200 W. Adams St., Suite 1010
> Chicago, IL 60606
>
> O. <a href="tel:%2B1%20%28312%29%20605-4500" value="+13126054500">+1 (312) 605-4500 | F. <a href="tel:%2B1%20%28312%29%20635-1751" value="+13126351751">+1 (312) 635-1751
>
>
>
> All new Metro NOW widget downloads will be free for the month of December! Visit our City Store to download now.
>
>
>
> Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Loading...