quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] isCorrectCompID

[Oren M. <or...@qu...>]

Yeah, this is just a quick workaround.  In the end we will probably need to 
add another validation config setting such as ValidateSenderCompID.

--oren

----- Original Message ----- 
From: "rho" <tia...@ya...>
To: <qui...@li...>
Sent: Wednesday, May 10, 2006 11:53 AM
Subject: Re: [Quickfix-developers] isCorrectCompID


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> The easy way to fix it is to modify the function one way or another. But 
> that
> would mean a change of the quickfix library. I tried not to change the
> quickfix library.
>
> --
> View this message in context: 
> http://www.nabble.com/isCorrectCompID-t1591767.html#a4323592
> Sent from the QuickFIX - Dev forum at Nabble.com.
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Oren M. <or...@qu...>]

There was, however it was overrun by WikiSpam and I never got around to 
researching solutions to the problem.

--oren

> p.s. Speaking of confusion, is there a QuickFIX wiki? While the existing 
> documentation is sufficient for getting started, in order to really 
> understand a lot of QF you have to read the mailing list archives. If we 
> had a wiki, I'd be tempted to transfer at least some of the mailing list 
> knowledge to the wiki, if only from an ongoing basis.

Re: [Quickfix-developers] isCorrectCompID

[rho <tia...@ya...>]

The easy way to fix it is to modify the function one way or another. But that
would mean a change of the quickfix library. I tried not to change the
quickfix library.

--
View this message in context: http://www.nabble.com/isCorrectCompID-t1591767.html#a4323592
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Brian E. <azz...@ya...>]

Oren -

From a simplicity viewpoint, I would vote for scrapping the "single-threaded" version of SocketInitiator. As the QF callbacks are inherently multithreaded, any QF user should be coding things in a thread-safe manner anyway. Granted, currently a SocketInitiator user only needs to make sure that the sending thread does not share a code path with the receive callback, but I've never seen the point of attempting to save the little bit of coding required to use ThreadedSocketInitiator - does anyone who has multiple active sessions at a time really rely on SocketAcceptor queuing the separate message streams? The problems that come using a single thread to satisfy multiple readers are so much more pervasive than handling a few more inbound threads. Currently, if you are only dealing with a single session, there doesn't appear to be a lick of difference between the behavior of the "threaded" vs. "unthreaded" classes.

The question becomes how to go forward? Do you deprecate SocketInitiator/Acceptor or simply make it a facade for ThreadedSocketInitiator/Acceptor? Deprecation highlights the fact that you will need to make code changes, but a lot of people using SocketInitiator are probably in that one-session-only mode that would be unaffected (and require no coding changes) if you went the facade route.

I also think it would be a very good idea to decouple the reads and writes - I was unaware that ThreadedXXX classes had the same deadlock issues as the nonthreaded versions.

- Brian Erst
Thynk Software, Inc.

p.s. Speaking of confusion, is there a QuickFIX wiki? While the existing documentation is sufficient for getting started, in order to really understand a lot of QF you have to read the mailing list archives. If we had a wiki, I'd be tempted to transfer at least some of the mailing list knowledge to the wiki, if only from an ongoing basis.

----- Original Message ----
From: Oren Miller <or...@qu...>
To: Caleb Epstein <cal...@gm...>; Nick Volpe <ni...@ad...>
Cc: quickfix-developers <qui...@li...>
Sent: Wednesday, May 10, 2006 11:01:28 AM
Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Yeah, I'm reading that in unix it is typical to do a fork and have each 
process treat it as unidirectional to avoid deadlocks.  So we would have to 
have a thread for sending and a thread for receiving.  This is actually 
something we had talked about in the past to prevent deadlocks when sending 
from callbacks.  Essentially creating a sending queue.  I am wondering 
however if we really do need the SocketInitiator/Acceptor or if it should be 
deprecated in favor of the threaded versions.  I think the precense of both 
of them has been one of the more confusing aspects of QuickFIX and not sure 
it really is advantageous to have both at this point.  Any thoughts on this?

--oren

----- Original Message ----- 
From: "Caleb Epstein" <cal...@gm...>
To: "Nick Volpe" <ni...@ad...>
Cc: "quickfix-developers" <qui...@li...>
Sent: Tuesday, May 09, 2006 11:08 AM
Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs 
SocketInitiator


QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

I don't think this made it through the first time.

On 5/9/06, Nick Volpe <ni...@ad...> wrote:
>
> Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a
> Socket Initiator?  I c an't seem to find much in the documentation or the
> mailing list archives.  Any help would be greatly appreciated.

The non-threaded SocketInitiator can actually get into a deadlock
situation whereby your application will block forever.  I would
recommend against anyone ever using it.

This deadlock will happen if your application fills up a socket's
sending buffer while the other side is doing the same (e.g. two
non-threaded QuickFIX apps generating heavy traffic).  Neither side
will end up reading from its side of the socket, being blocked in a
send() call, and both sides will deadlock.

--
Caleb Epstein
caleb dot epstein at gmail dot com


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job 
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Oren M. <or...@qu...>]

Yeah, I'm reading that in unix it is typical to do a fork and have each 
process treat it as unidirectional to avoid deadlocks.  So we would have to 
have a thread for sending and a thread for receiving.  This is actually 
something we had talked about in the past to prevent deadlocks when sending 
from callbacks.  Essentially creating a sending queue.  I am wondering 
however if we really do need the SocketInitiator/Acceptor or if it should be 
deprecated in favor of the threaded versions.  I think the precense of both 
of them has been one of the more confusing aspects of QuickFIX and not sure 
it really is advantageous to have both at this point.  Any thoughts on this?

--oren

----- Original Message ----- 
From: "Caleb Epstein" <cal...@gm...>
To: "Nick Volpe" <ni...@ad...>
Cc: "quickfix-developers" <qui...@li...>
Sent: Tuesday, May 09, 2006 11:08 AM
Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs 
SocketInitiator


QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

I don't think this made it through the first time.

On 5/9/06, Nick Volpe <ni...@ad...> wrote:
>
> Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a
> Socket Initiator?  I c an't seem to find much in the documentation or the
> mailing list archives.  Any help would be greatly appreciated.

The non-threaded SocketInitiator can actually get into a deadlock
situation whereby your application will block forever.  I would
recommend against anyone ever using it.

This deadlock will happen if your application fills up a socket's
sending buffer while the other side is doing the same (e.g. two
non-threaded QuickFIX apps generating heavy traffic).  Neither side
will end up reading from its side of the socket, being blocked in a
send() call, and both sides will deadlock.

--
Caleb Epstein
caleb dot epstein at gmail dot com


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job 
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] isCorrectCompID

[Oren M. <or...@qu...>]

I think the easiest work around for this would be to change isCorrectCompID 
to always return true.

--oren

----- Original Message ----- 
From: "rho" <tia...@ya...>
To: <qui...@li...>
Sent: Wednesday, May 10, 2006 8:34 AM
Subject: [Quickfix-developers] isCorrectCompID


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> In my logon message sent to ilink2, SenderCompID = I65789U, TargetCompID =
> CME.
> In the logon confirmation message,  TargetCompID =I65789P. The change from
> I65789U to I65789P is a business requirement.
>
> Now the Quickfix will verify the incoming fix message. since I65789U !=
> I65789P, the isCorrectCompID call fails and log me out.
>
> Is there a way that I can change the  TargetCompID right after the raw fix
> is read? I hoped to do so in fromAdmin and fromApp. But it seems that
> isCorrectCompID is called before the callback is involked.
>
> I am new to quickfix. Any help is appreciated.
> --
> View this message in context: 
> http://www.nabble.com/isCorrectCompID-t1591767.html#a4319622
> Sent from the QuickFIX - Dev forum at Nabble.com.
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

[Quickfix-developers] Minor glitch in build.xml for quickfixj

[Staffan U. <sta...@mu...>]

Patch follows.

Staffan


Index: build.xml
===================================================================
RCS file: /cvsroot/quickfix/quickfixj/build.xml,v
retrieving revision 1.31
diff -u -r1.31 build.xml
--- build.xml   14 Feb 2006 21:26:07 -0000      1.31
+++ build.xml   10 May 2006 15:33:14 -0000
@@ -343,7 +343,7 @@
                        <package name="quickfix.netty" />
                        <package name="quickfix.field.converter" />
                        <package name="quickfix.codegen" />
-                       <package name="quickfix.fields" />
+                       <package name="quickfix.field" />
                        <package name="quickfix.fix*" />
                </javadoc>
        </target>

[Quickfix-developers] Minor glitch in build.xml for quickfixj

[Staffan U. <st...@ul...>]

Patch follows.

Staffan


Index: build.xml
===================================================================
RCS file: /cvsroot/quickfix/quickfixj/build.xml,v
retrieving revision 1.31
diff -u -r1.31 build.xml
--- build.xml   14 Feb 2006 21:26:07 -0000      1.31
+++ build.xml   10 May 2006 15:33:14 -0000
@@ -343,7 +343,7 @@
                        <package name="quickfix.netty" />
                        <package name="quickfix.field.converter" />
                        <package name="quickfix.codegen" />
-                       <package name="quickfix.fields" />
+                       <package name="quickfix.field" />
                        <package name="quickfix.fix*" />
                </javadoc>
        </target>

[Quickfix-developers] Re: ThreadedSocketInitiator vs SocketInitiator

[Alexey Z. <ale...@gm...>]

Wow. I tried to get this information a year ago when I start using 
QuickFix. And now such a big surprise.
Thanks, Caleb.

Overall QF is doing pretty good but I do have dead locks in one heavy 
loaded multi-thread application.
In my application I have one (not threaded) initiator and an acceptor.
When I lost connection in the initiator, the application is stuck (not 
always, basically I can't reproduce it freely, but it happens often in 
production).
I stopped using ThreadedSocketInitiator because I have only one session 
in it.
Basically I thought the problem is that sessions list is static, and my 
acceptor and initiator share critical sections incorrectly.

I put threaded initiator to the production yesterday and will see if it 
help.

Thanks for the explanations again.

Regards,
		Alexey Zubko


>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator
> From:
> "Caleb Epstein" <cal...@gm...>
> Date:
> Tue, 9 May 2006 12:08:22 -0400
> To:
> "Nick Volpe" <ni...@ad...>
>
> To:
> "Nick Volpe" <ni...@ad...>
> CC:
> quickfix-developers <qui...@li...>
>
>
> I don't think this made it through the first time.
>
> On 5/9/06, Nick Volpe <ni...@ad...> wrote:
>>
>> Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a
>> Socket Initiator?  I c an't seem to find much in the documentation or 
>> the
>> mailing list archives.  Any help would be greatly appreciated.
>
> The non-threaded SocketInitiator can actually get into a deadlock
> situation whereby your application will block forever.  I would
> recommend against anyone ever using it.
>
> This deadlock will happen if your application fills up a socket's
> sending buffer while the other side is doing the same (e.g. two
> non-threaded QuickFIX apps generating heavy traffic).  Neither side
> will end up reading from its side of the socket, being blocked in a
> send() call, and both sides will deadlock.
>
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>   

RE: [Quickfix-developers] isCorrectCompID

[Fabien G. <fab...@pr...>]

Hi

I had same problem here, simply comment (dont use) this function and by =
now have no side-effect.
But if there is another way to handle this i am interrested too.


Fabien

-----Message d'origine-----
De : qui...@li...
[mailto:qui...@li...]De la part de
rho
Envoye : mercredi 10 mai 2006 15:34
A : qui...@li...
Objet : [Quickfix-developers] isCorrectCompID


QuickFIX Documentation: =
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


In my logon message sent to ilink2, SenderCompID =3D I65789U, =
TargetCompID =3D
CME.
In the logon confirmation message,  TargetCompID =3DI65789P. The change =
from
I65789U to I65789P is a business requirement.

Now the Quickfix will verify the incoming fix message. since I65789U =
!=3D
I65789P, the isCorrectCompID call fails and log me out.

Is there a way that I can change the  TargetCompID right after the raw =
fix
is read? I hoped to do so in fromAdmin and fromApp. But it seems that
isCorrectCompID is called before the callback is involked.

I am new to quickfix. Any help is appreciated.
--
View this message in context: =
http://www.nabble.com/isCorrectCompID-t1591767.html#a4319622
Sent from the QuickFIX - Dev forum at Nabble.com.



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, =
security?
Get stuff done quickly with pre-integrated technology to make your job =
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] isCorrectCompID

[rho <tia...@ya...>]

In my logon message sent to ilink2, SenderCompID = I65789U, TargetCompID =
CME.
In the logon confirmation message,  TargetCompID =I65789P. The change from
I65789U to I65789P is a business requirement.

Now the Quickfix will verify the incoming fix message. since I65789U !=
I65789P, the isCorrectCompID call fails and log me out.

Is there a way that I can change the  TargetCompID right after the raw fix
is read? I hoped to do so in fromAdmin and fromApp. But it seems that
isCorrectCompID is called before the callback is involked.

I am new to quickfix. Any help is appreciated.
--
View this message in context: http://www.nabble.com/isCorrectCompID-t1591767.html#a4319622
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] SessionScedule getters wanted

[Staffan U. <sta...@mu...>]

sta...@mu... writes:

> I would need to look ath the start and end times for the current
> session in a quickfixj application.  Is there a strong reason for not
> including:
> 
>     Date getStartTime() {
>         return startTime.getTime();
>     }
> 
>     Date getEndTime() {
>         return endTime.getTime();
>     }
> 
> In quickfixj.SessionScedule, or could this be added?

I realized that the class is not even public, and also that
startTime.getTime() does not return the time of the session start, if
it spans multiple days.

Anyway, it would be nice to have methods for this purpose on the
Session class, and I believe they should return the actual start and
end times for the session.  (This can be used, for example, for
pruning log files, and for scheduling things to happen at the end of a
session.)

Staffan

Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Staffan U. <sta...@mu...>]

"Caleb Epstein" <cal...@gm...> writes:

> The non-threaded SocketInitiator can actually get into a deadlock
> situation whereby your application will block forever.  I would
> recommend against anyone ever using it.
> 
> This deadlock will happen if your application fills up a socket's
> sending buffer while the other side is doing the same (e.g. two
> non-threaded QuickFIX apps generating heavy traffic).  Neither side
> will end up reading from its side of the socket, being blocked in a
> send() call, and both sides will deadlock.

Maybe I'm missing something obvious, but why won't the same deadlock
happen with the threaded version, if all it does is have one thread
per session?

I guess the above can also be asked as a question:

  Does ThreadedSocketInitiator work differently from SocketInitiator in
  the case where there is only one session?

Staffan

Re: [Quickfix-developers] Dynamic allocation of incoming sessions?

[Oren M. <or...@qu...>]

This is something that we have been looking into.  Like you said the =
work involved is not trivial.  We took on of the first steps to this =
(adding support for acceptor ports on a per session level).  The =
requirement of a global setting made the implementation of this idea =
much harder.  Now that all the settings are strictly per session with =
the global settings only used as defaults, this task should become much =
easier.

--oren
  ----- Original Message -----=20
  From: Dale Wilson=20
  To: Graham Miller=20
  Cc: qui...@li...=20
  Sent: Tuesday, May 09, 2006 8:43 AM
  Subject: Re: [Quickfix-developers] Dynamic allocation of incoming =
sessions?


  Hi Graham,

  I've looked into allowing dynamic configuration of sessions in C++.  =
It look feasable, but certainly not easy.  Since my company's business =
model  is doing sponsored work on open source projects, I probably won't =
tackle it until/unless we can find someone to sponsor the work.  I'd be =
interested to hear if Oren (or anyone else) has plans in that direction.

  Dale

  Graham Miller wrote:=20
    QuickFIX Documentation: =
http://www.quickfixengine.org/quickfix/doc/html/index.html=20
    QuickFIX Support: http://www.quickfixengine.org/services.html=20

    Hello all,=20
    I was looking at the implementation of DefaultSessionFactory, and=20
    thought it would be easy to subclass that to allow dynamic=20
    configuration of sessions (that is, configuring sessions on the fly=20
    based on parameters in a database or LDAP server at connect time). =
However it appears that quickfix expects to find entries for all the=20
    valid sessions in the configuration file, which is read only once at =

    startup.  Has anyone looked at making this more dynamic?  Is there =
any=20
    interest or opinions on how it should be done?=20

    For reference I'm looking only at the Quickfix/J code, because I'm=20
    living in Java-land right now.=20

    graham=20


    -------------------------------------------------------=20
    Using Tomcat but need to do more? Need to support web services, =
security?=20
    Get stuff done quickly with pre-integrated technology to make your =
job easier=20
    Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo=20
    =
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642=20
    _______________________________________________=20
    Quickfix-developers mailing list=20
    Qui...@li...=20
    https://lists.sourceforge.net/lists/listinfo/quickfix-developers=20

Re: [Quickfix-developers] Dynamic allocation of incoming sessions?

[Oren M. <or...@qu...>]

I've never seen the code.  I have a long string of emails regarding their 
progress, but I've not seen a deliverable.  Last status update I received 
was september of last year.

--oren

----- Original Message ----- 
From: "Caleb Epstein" <cal...@gm...>
To: "Graham Miller" <gra...@gm...>
Cc: <qui...@li...>
Sent: Tuesday, May 09, 2006 11:06 AM
Subject: Re: [Quickfix-developers] Dynamic allocation of incoming sessions?


QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

On 5/8/06, Graham Miller <gra...@gm...> wrote:

> I was looking at the implementation of DefaultSessionFactory, and
> thought it would be easy to subclass that to allow dynamic
> configuration of sessions (that is, configuring sessions on the fly
> based on parameters in a database or LDAP server at connect time).

Oren et al:

What ever happened to the alliance between QuickFIX and TransactTools
that was announced about a year ago?  If memory serves, there were
rumblings of JMX management interfaces and the like, but where is the
code?  Has anything materialized from this relationship aside from a
press release?

--
Caleb Epstein
caleb dot epstein at gmail dot com


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job 
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Caleb E. <cal...@gm...>]

I don't think this made it through the first time.

On 5/9/06, Nick Volpe <ni...@ad...> wrote:
>
> Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a
> Socket Initiator?  I c an't seem to find much in the documentation or the
> mailing list archives.  Any help would be greatly appreciated.

The non-threaded SocketInitiator can actually get into a deadlock
situation whereby your application will block forever.  I would
recommend against anyone ever using it.

This deadlock will happen if your application fills up a socket's
sending buffer while the other side is doing the same (e.g. two
non-threaded QuickFIX apps generating heavy traffic).  Neither side
will end up reading from its side of the socket, being blocked in a
send() call, and both sides will deadlock.

--
Caleb Epstein
caleb dot epstein at gmail dot com

Re: [Quickfix-developers] Dynamic allocation of incoming sessions?

[Caleb E. <cal...@gm...>]

On 5/8/06, Graham Miller <gra...@gm...> wrote:

> I was looking at the implementation of DefaultSessionFactory, and
> thought it would be easy to subclass that to allow dynamic
> configuration of sessions (that is, configuring sessions on the fly
> based on parameters in a database or LDAP server at connect time).

Oren et al:

What ever happened to the alliance between QuickFIX and TransactTools
that was announced about a year ago?  If memory serves, there were
rumblings of JMX management interfaces and the like, but where is the
code?  Has anything materialized from this relationship aside from a
press release?

--
Caleb Epstein
caleb dot epstein at gmail dot com

Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Dale W. <wil...@oc...>]

Nick Volpe wrote:
>
> Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus 
> a Socket Initiator?  I c an't seem to find much in the documentation 
> or the mailing list archives.  Any help would be greatly appreciated.
If you are connecting to a single counterparty (for example a trader 
connecting to one exchange), use SocketInitiator.

If you are connecting to more than one exchange then 
ThreadedSocketInitiator might make your program more responsive.   With 
SocketInitiator every incoming FIX message has to be completely 
processed -- including any application level message processing which 
might take a long time -- before any other connections are serviced.  
With ThreadedSocketInitiator messages from separate sources can be 
processed in parallel.

In *either* case you must write thread-safe code because incoming 
messages are processed on a separate thread (or threads) from outgoing 
messages (i.e if your main thread generates an order, the execution 
report(s) for that order will arrive courtesy of a different thread so 
if you have a common "Order Management" component in your application it 
needs to be thread-safe.)

HTH,

Dale
>
> Thanks.
> Nik

[Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Nick V. <ni...@ad...>]

Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a 
Socket Initiator?  I c an't seem to find much in the documentation or the 
mailing list archives.  Any help would be greatly appreciated.

Thanks.
Nik
**************************************************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any  unauthorized use of the information contained
in this email or its attachments is prohibited.  If this email is received in
error, please contact the sender and delete the material from your
computer systems. Do not use, copy, or disclose the contents of this
email or any attachments.
Abu Dhabi Investment Authority (ADIA) accepts no responsibility for
the content of this email to the extent that the same consists of
statements and opinions made which are the senders own and not
made on behalf of ADIA.  Nor does ADIA accept any liability for any
errors or omissions in the content of this email caused by electronic
and technical failures.
Although ADIA has taken reasonable precautions to ensure that no
viruses are present in this email, ADIA accepts no responsibility for
any loss or damage arising from the use of this email or its
attachments.
**************************************************************************************************************

RE: [Quickfix-developers] Dynamic allocation of incoming sessions?

[Steve B. <sb...@sm...>]

Graham and Dale and others,
=20
I've been considering this feature for QFJ. My current thinking is that
I'd create a new interface for a session definition repository. This
repository interface would support notifications for session definition
create, update and delete. SessionSettings would be refactored to
implement this interface. However, the implementation would only support
static init-time session definitions and the notification support would
not be used. The other QFJ classes would be modified to only use the
session repository interface. This would allow us to create alternative
dynamic session repositories using JDBC, LDAP, or whatever without
breaking the existing API. The acceptors and initiators would be
modified to respond to session definition change notifications so that
sessions could be created and deleted dynamically. I'm not sure yet
about the update. It may just be implemented as a session delete and
then create with the new configuration (for changing FIX version, data
dictionary, ...).
=20
This is the theory. I haven't created any prototypes yet. I'm definitely
interested in comments.
=20
Steve


________________________________

	From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Dale Wilson
	Sent: Tuesday, May 09, 2006 3:43 PM
	To: Graham Miller
	Cc: qui...@li...
	Subject: Re: [Quickfix-developers] Dynamic allocation of
incoming sessions?
=09
=09
	Hi Graham,
=09
	I've looked into allowing dynamic configuration of sessions in
C++.  It look feasable, but certainly not easy.  Since my company's
business model  is doing sponsored work on open source projects, I
probably won't tackle it until/unless we can find someone to sponsor the
work.  I'd be interested to hear if Oren (or anyone else) has plans in
that direction.
=09
	Dale
=09
	Graham Miller wrote:=20

		QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html=20
		QuickFIX Support:
http://www.quickfixengine.org/services.html=20
	=09
		Hello all,=20
		I was looking at the implementation of
DefaultSessionFactory, and=20
		thought it would be easy to subclass that to allow
dynamic=20
		configuration of sessions (that is, configuring sessions
on the fly=20
		based on parameters in a database or LDAP server at
connect time). However it appears that quickfix expects to find entries
for all the=20
		valid sessions in the configuration file, which is read
only once at=20
		startup.  Has anyone looked at making this more dynamic?
Is there any=20
		interest or opinions on how it should be done?=20
	=09
		For reference I'm looking only at the Quickfix/J code,
because I'm=20
		living in Java-land right now.=20
	=09
		graham=20
	=09
	=09
		-------------------------------------------------------=20
		Using Tomcat but need to do more? Need to support web
services, security?=20
		Get stuff done quickly with pre-integrated technology to
make your job easier=20
		Download IBM WebSphere Application Server v.1.0.1 based
on Apache Geronimo=20
=09
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642=20
		_______________________________________________=20
		Quickfix-developers mailing list=20
		Qui...@li...=20
=09
https://lists.sourceforge.net/lists/listinfo/quickfix-developers=20
	=09

Re: [Quickfix-developers] Dynamic allocation of incoming sessions?

[Dale W. <wil...@oc...>]

Hi Graham,

I've looked into allowing dynamic configuration of sessions in C++.  It 
look feasable, but certainly not easy.  Since my company's business 
model  is doing sponsored work on open source projects, I probably won't 
tackle it until/unless we can find someone to sponsor the work.  I'd be 
interested to hear if Oren (or anyone else) has plans in that direction.

Dale

Graham Miller wrote:
> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello all,
> I was looking at the implementation of DefaultSessionFactory, and
> thought it would be easy to subclass that to allow dynamic
> configuration of sessions (that is, configuring sessions on the fly
> based on parameters in a database or LDAP server at connect time). 
> However it appears that quickfix expects to find entries for all the
> valid sessions in the configuration file, which is read only once at
> startup.  Has anyone looked at making this more dynamic?  Is there any
> interest or opinions on how it should be done?
>
> For reference I'm looking only at the Quickfix/J code, because I'm
> living in Java-land right now.
>
> graham
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Dynamic allocation of incoming sessions?

[Graham M. <gra...@gm...>]

Hello all,
I was looking at the implementation of DefaultSessionFactory, and
thought it would be easy to subclass that to allow dynamic
configuration of sessions (that is, configuring sessions on the fly
based on parameters in a database or LDAP server at connect time).=20
However it appears that quickfix expects to find entries for all the
valid sessions in the configuration file, which is read only once at
startup.  Has anyone looked at making this more dynamic?  Is there any
interest or opinions on how it should be done?

For reference I'm looking only at the Quickfix/J code, because I'm
living in Java-land right now.

graham

[Quickfix-developers] SessionScedule getters wanted

[<sta...@mu...>]

Hello,

I would need to look ath the start and end times for the current
session in a quickfixj application.  Is there a strong reason for not
including:

    Date getStartTime() {
        return startTime.getTime();
    }

    Date getEndTime() {
        return endTime.getTime();
    }

In quickfixj.SessionScedule, or could this be added?

Staffan

[Quickfix-developers] Logon makes app. crash

[Jonatan K. <jo...@ly...>]

Hi,

=20

I'm trying to logon with quickfix but when I receive the logon message
(fromAdmin) the application crash. I'm new to fix so I hope this is a
simple problem.=20

=20

Below is my own log of the logon procedure:

=20

toAdmin:
8=3DFIX.4.29=3D8935=3DA34=3D149=3Dlynxfixstream52=3D20060508-10:51:11.351=
56=3DCURRENEX
-FXTRADES-FIX98=3D0108=3D3010=3D168

<20060508-10:51:11, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX, event>

  (Created session)

press <enter> to quit

<20060508-10:51:11, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX, event>

  (Connecting to integration-fix.currenex.com on port 442)

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX, event>

  (Connection succeeded)

toAdmin:
8=3DFIX.4.29=3D8935=3DA34=3D249=3Dlynxfixstream52=3D20060508-10:51:12.429=
56=3DCURRENEX
-FXTRADES-FIX98=3D0108=3D3010=3D176

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX,
outgoing>

=20
(8=3DFIX.4.29=3D8935=3DA34=3D249=3Dlynxfixstream52=3D20060508-10:51:12.42=
956=3DCURRENE
X-FXTRADES-FIX98=3D0108=3D3010=3D176)

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX, event>

  (Initiated logon request)

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX,
incoming>

=20
(8=3DFIX.4.29=3D8535=3DA49=3DCURRENEX-FXTRADES-FIX56=3Dlynxfixstream34=3D=
152=3D2006050
8-10:51:12108=3D3098=3D010=3D222)

fromAdmin:
8=3DFIX.4.29=3D8535=3DA34=3D149=3DCURRENEX-FXTRADES-FIX52=3D20060508-10:5=
1:1256=3Dlynx
fixstream98=3D0108=3D3010=3D222

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX, event>

  (Received logon response)

onLogon: FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX,
incoming>

=20
(8=3DFIX.4.29=3D8235=3D249=3DCURRENEX-FXTRADES-FIX56=3Dlynxfixstream34=3D=
252=3D2006050
8-10:51:127=3D116=3D110=3D048)

fromAdmin:
8=3DFIX.4.29=3D8235=3D234=3D249=3DCURRENEX-FXTRADES-FIX52=3D20060508-10:5=
1:1256=3Dlynx
fixstream7=3D116=3D110=3D048

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX, event>

  (Received ResendRequest FROM: 1 TO: 1)

toAdmin:
8=3DFIX.4.29=3D11935=3D434=3D143=3DY49=3Dlynxfixstream52=3D20060508-10:51=
:12.78956=3DCUR
RENEX-FXTRADES-FIX122=3D20060508-10:51:12.78936=3D2123=3DY10=3D201

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX,
outgoing>

=20
(8=3DFIX.4.29=3D11935=3D434=3D143=3DY49=3Dlynxfixstream52=3D20060508-10:5=
1:12.78956=3DCU
RRENEX-FXTRADES-FIX122=3D20060508-10:51:12.78936=3D2123=3DY10=3D201)

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX, event>

  (Sent SequenceReset TO: 2)

<20060508-10:51:12, FIX.4.2:lynxfixstream->CURRENEX-FXTRADES-FIX,
incoming>

=20
(8=3DFIX.4.29=3D8535=3Dh49=3DCURRENEX-FXTRADES-FIX56=3Dlynxfixstream34=3D=
352=3D2006050
8-10:51:12336=3D0340=3D210=3D255)

fromApp:
8=3DFIX.4.29=3D8535=3Dh34=3D349=3DCURRENEX-FXTRADES-FIX52=3D20060508-10:5=
1:1256=3Dlynx
fixstream336=3D0340=3D210=3D255

QuickFix42.TradingSessionStatus:
8=3DFIX.4.29=3D8535=3Dh34=3D349=3DCURRENEX-FXTRADES-FIX52=3D20060508-10:5=
1:1256=3Dlynx
fixstream336=3D0340=3D210=3D255

=20

Thanks!

=20

Regards,

Jonatan Karlman

Re: [Quickfix-developers] DB2 ODBC

[Oren M. <or...@qu...>]

Can't really give much help on your first question, I would need a lot =
more detail about what you are actually doint.  There is not enough =
information here to hazard a guess.

ODBC support is in testing and will be available in the next release.

There is not official support for the systems you listed.  QuickFIX may =
work on those systems, but we do not have any first hand experience with =
it.

--oren
  ----- Original Message -----=20
  From: Miguel Peralta=20
  To: qui...@li...=20
  Cc: qui...@li...=20
  Sent: Friday, May 05, 2006 12:16 PM
  Subject: [Quickfix-developers] DB2 ODBC


  QuickFIX Documentation: =
http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX =
Support: http://www.quickfixengine.org/services.html=20
  hello, I install quickfix, and I have tree cuestions:=20

  I cannot write in MYSQL database what I do wrong?=20
  I compile the examples and the database but when I try to configure to =
record in MYSQL nothing happens=20

  Fix can support DB2 or I need to do something more?=20
  Whit quickfix can use ODBC to use a external Database?=20
  Have support for the AS/400, ISERIES OR I5.=20




  And I thought that my president was stupid


-------------------------------------------------------------------------=
-----
  =C9xitos, grandes cl=E1sicos y novedades. Un mill=F3n de canciones en =
MSN Music. ------------------------------------------------------- Using =
Tomcat but need to do more? Need to support web services, security? Get =
stuff done quickly with pre-integrated technology to make your job =
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo =
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642 _______________________________________________ =
Quickfix-developers mailing list =
Qui...@li... =
https://lists.sourceforge.net/lists/listinfo/quickfix-developers