quickfix-users Mailing List for QuickFIX (Page 37)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-users — QuickFIX user support
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(4) |
Mar
(6) |
Apr
(2) |
May
(4) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(11) |
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(7) |
Feb
(3) |
Mar
(10) |
Apr
(40) |
May
(63) |
Jun
(12) |
Jul
(26) |
Aug
(13) |
Sep
(6) |
Oct
(13) |
Nov
(17) |
Dec
(28) |
| 2004 |
Jan
(13) |
Feb
(6) |
Mar
(9) |
Apr
(20) |
May
(15) |
Jun
(29) |
Jul
(22) |
Aug
(11) |
Sep
(32) |
Oct
(34) |
Nov
(22) |
Dec
(33) |
| 2005 |
Jan
(17) |
Feb
(8) |
Mar
(3) |
Apr
(20) |
May
(19) |
Jun
(29) |
Jul
(30) |
Aug
(10) |
Sep
(24) |
Oct
|
Nov
(17) |
Dec
(11) |
| 2006 |
Jan
(32) |
Feb
(54) |
Mar
(34) |
Apr
(43) |
May
(14) |
Jun
(11) |
Jul
(10) |
Aug
(43) |
Sep
(37) |
Oct
(44) |
Nov
(16) |
Dec
(11) |
| 2007 |
Jan
(26) |
Feb
(5) |
Mar
(23) |
Apr
(3) |
May
(22) |
Jun
(17) |
Jul
(22) |
Aug
(34) |
Sep
(17) |
Oct
(18) |
Nov
(4) |
Dec
(8) |
| 2008 |
Jan
(28) |
Feb
(28) |
Mar
(23) |
Apr
(37) |
May
(53) |
Jun
(20) |
Jul
(30) |
Aug
(12) |
Sep
(19) |
Oct
(16) |
Nov
(15) |
Dec
(10) |
| 2009 |
Jan
(19) |
Feb
(8) |
Mar
(21) |
Apr
(8) |
May
(15) |
Jun
(22) |
Jul
(34) |
Aug
(18) |
Sep
(23) |
Oct
(26) |
Nov
(16) |
Dec
(13) |
| 2010 |
Jan
(38) |
Feb
(17) |
Mar
(39) |
Apr
(34) |
May
(5) |
Jun
(15) |
Jul
(7) |
Aug
(18) |
Sep
(4) |
Oct
(16) |
Nov
(3) |
Dec
(17) |
| 2011 |
Jan
(28) |
Feb
(12) |
Mar
(36) |
Apr
(9) |
May
(26) |
Jun
(27) |
Jul
(6) |
Aug
(10) |
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(9) |
Jun
(4) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(9) |
Nov
(10) |
Dec
(8) |
| 2013 |
Jan
(3) |
Feb
(2) |
Mar
(7) |
Apr
(2) |
May
|
Jun
(7) |
Jul
(22) |
Aug
(5) |
Sep
(3) |
Oct
(3) |
Nov
(3) |
Dec
(2) |
| 2014 |
Jan
(4) |
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(4) |
Dec
|
| 2016 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(5) |
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: J. M. <jul...@pr...> - 2008-05-22 21:31:09
|
I have this error while I'm trying to send a login messege with an ICE session in Visual Studio. Any idea? line: ** *QuickFix.**Session.sendToTarget(message, iceId);* ** error: *No se puede pasar GCHandle entre dominios de aplicación. Nombre del parámetro: handle* |
|
From: Oren M. <or...@qu...> - 2008-05-22 16:55:27
|
We can certainly add to them. What do you have in mind? On May 22, 2008, at 11:10 AM, "Julián Mendiola" <jul...@pr....a r> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Are there any manual or totorial about the basic functionality of > QuickFix, the documentation and examples in the QuickFix page are to > short... > > Thanks, Julian. > --- > ---------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users |
|
From: J. M. <jul...@pr...> - 2008-05-22 16:21:57
|
Are there any manual or totorial about the basic functionality of QuickFix, the documentation and examples in the QuickFix page are to short... Thanks, Julian. |
|
From: C. G. <let...@gm...> - 2008-05-22 09:53:29
|
I'm happily using quickfix and it works great. Every evening, at 22.00, the remote side turns off it's systems, and I need to wait until next morning when they come up again. My application attempts to reconnect continously but fails. The remote side say they never see any connection attempt at all, so I'm guessing for some reason, I fail to open a new socket during morning. My log simply says 20080522-08:46:09 : Connecting to xxx.xxx.xxx.xxx on port yyyyy 20080522-08:46:31 : Connection failed Since "Connection Failed" doesn't tell me much, I started looking for where the error occured, so I could add some extra error handling code. The only place I can find this message "Connection Failed" is in the c++ source files. I use .net, so I'm guessing that's not really relevant in my case. Could anyone give me some ideas about what to look for, so I can gather more information about my problem? |
|
From: Vincent P. <vpr...@ph...> - 2008-05-22 02:54:20
|
On May 20, 2008, at 2:50 PM, Jonathan Kalbfeld wrote: > You'll probably want to use an OrderStatusRequest and then have your > match server respond with an ExecutionReport. > > jonathan Is there a FIX message that will query for the total number of contracts available for a particular commodity on the system? -- Vincent |
|
From: Mike P. <mic...@ya...> - 2008-05-21 18:08:53
|
Do you have a session in your configuration file that has a 'ConnectionType=acceptor'? If you don't then you shouldn't be using the SocketAcceptor. The SocketAcceptor classes expects at least one of the sessions to be of that type. Mike --- On Wed, 5/21/08, Julián Mendiola <jul...@pr...> wrote: > From: Julián Mendiola <jul...@pr...> > Subject: [Quickfix-users] config exception > To: qui...@li... > Date: Wednesday, May 21, 2008, 12:53 PM > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: > http://www.quickfixengine.org/services.html------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users |
|
From: <or...@qu...> - 2008-05-21 18:07:05
|
I would imagine posting your configuration file might be helpful. > -------- Original Message -------- > Subject: [Quickfix-users] config exception > From: "Julián_Mendiola" <jul...@pr...> > Date: Wed, May 21, 2008 12:53 pm > To: qui...@li... > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html<hr>I keep on reciving this exeption; {"Configuration failed: No sessions > defined for acceptor"}. > on this line: > SocketAcceptor acceptor = new SocketAcceptor( application, storeFactory, > settings, logFactory, messageFactory ); > Anyone can tell what is it about.... > Thanks, Julian.<hr>------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/<hr>_______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users |
|
From: J. M. <jul...@pr...> - 2008-05-21 17:53:25
|
I keep on reciving this exeption; {"Configuration failed: No sessions
defined for acceptor"}.
on this line:
SocketAcceptor acceptor = new SocketAcceptor( application, storeFactory,
settings, logFactory, messageFactory );
Anyone can tell what is it about....
Thanks, Julian.
|
|
From: Vincent P. <vpr...@ph...> - 2008-05-21 02:33:30
|
On May 20, 2008, at 2:58 PM, John Haldi wrote:
>
> If I understand your question, the answer is "it depends on the
> other side's protocol implementation".
>
> For example, when I send a NewOrderSingle to ARCA, I initially get
> an ExecutionReport back from ARCA with OrdStatus=A ("Pending New")
> which means they got my order but it hasn't gone "live" in their
> trading engine. Almost immediately afterwards I get another
> ExecutionReport with OrdStatus=0 ("New") meaning my order is now
> live. Every now and then I get OrdStatus=A and then I get
> OrdStatus=8 ("Rejected"), which means 1) the FIX group got my
> message, but 2) it was rejected for some reason (usually because
> the stock is halted).
>
> As another example, one of the brokers we work with has their
> system configured so that I don't get the OrdStatus=A messages. I
> only get a notification once my order is rejected or it goes live.
>
> And then we have another broker who doesn't send anything back to
> me when an order goes live. They only send me notifications when I
> get filled, partially filled, or I cancel the order.
>
> It really just depends on what the other system is doing. If you
> are building a test broker app, I would recommend that you try to
> implement the more verbose scenario as described in the first example.
We're building a trade match system. My test client is designed to
make sure the match server works like it should. I used a number of
STL containers to store the data sent to the match server, so it can
make sure the responses from the match server are correct.
I might add that I was using my own version of FIXML, which was far
from the standard.
--
Vincent
|
|
From: Vincent P. <vpr...@ph...> - 2008-05-21 02:31:11
|
On May 20, 2008, at 2:58 PM, John Haldi wrote:
>
> If I understand your question, the answer is "it depends on the
> other side's protocol implementation".
>
> For example, when I send a NewOrderSingle to ARCA, I initially get
> an ExecutionReport back from ARCA with OrdStatus=A ("Pending New")
> which means they got my order but it hasn't gone "live" in their
> trading engine. Almost immediately afterwards I get another
> ExecutionReport with OrdStatus=0 ("New") meaning my order is now
> live. Every now and then I get OrdStatus=A and then I get
> OrdStatus=8 ("Rejected"), which means 1) the FIX group got my
> message, but 2) it was rejected for some reason (usually because
> the stock is halted).
>
> As another example, one of the brokers we work with has their
> system configured so that I don't get the OrdStatus=A messages. I
> only get a notification once my order is rejected or it goes live.
>
> And then we have another broker who doesn't send anything back to
> me when an order goes live. They only send me notifications when I
> get filled, partially filled, or I cancel the order.
>
> It really just depends on what the other system is doing. If you
> are building a test broker app, I would recommend that you try to
> implement the more verbose scenario as described in the first example.
We're building a trade match system. My test client is designed to
make sure the match server works like it should. I used a number of
STL containers to store the data sent to the match server, so it can
make sure the responses from the match server are correct.
--
Vincent
|
|
From: Dale W. <wil...@oc...> - 2008-05-20 21:32:35
|
Hi Vincent, Vincent Predoehl wrote: > > Is there a response message we're supposed to send in response to a > NewOrderSingle message? If you look toward the back of the FIX protocol specification for the version of FIX you are using you see something called Order State Change Matrixes. (Appendix D in Fix 4.2) I think a better term for these would be "order handling scenarios" because they are far from complete state tables, but they will give you a good feel for the typical sequence of events when an order is submitted, modified, canceled, etc. Dale |
|
From: Karl S. <kr...@co...> - 2008-05-20 21:03:34
|
Hello, I would like to use the Synchronized Application class for my C# app, but I do not see a wrapper. Is there a way to use the synchronized app, or should I simply recreate it out of the application class in C#? -Karl |
|
From: Jonathan K. <jon...@gm...> - 2008-05-20 19:50:09
|
You'll probably want to use an OrderStatusRequest and then have your match server respond with an ExecutionReport. jonathan On Tue, May 20, 2008 at 12:43 PM, Vincent Predoehl <vpr...@ph...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > On May 20, 2008, at 2:38 PM, Jonathan Kalbfeld wrote: > >> The answer is -- it depends on the rules of engagement. I believe my >> system just sends back an execution report with a 0 quantity fill. > > is there a quote message I can use to verify the data is stored on > the match server in my test code? > >> >> jonathan >> >> On Tue, May 20, 2008 at 12:37 PM, Vincent Predoehl >> <vpr...@ph...> wrote: >>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ >>> html/index.html >>> QuickFIX Support: http://www.quickfixengine.org/services.html >>> >>> >>> Is there a response message we're supposed to send in response to >>> a NewOrderSingle message? >>> > > -- > Vincent > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > -- -- Jonathan Kalbfeld ThoughtWave Technologies LLC www.thoughtwave.com +1 424 354 1814 Learn UNIX For Free at unixlessons.com |
|
From: Vincent P. <vpr...@ph...> - 2008-05-20 19:42:15
|
On May 20, 2008, at 2:38 PM, Jonathan Kalbfeld wrote: > The answer is -- it depends on the rules of engagement. I believe my > system just sends back an execution report with a 0 quantity fill. is there a quote message I can use to verify the data is stored on the match server in my test code? > > jonathan > > On Tue, May 20, 2008 at 12:37 PM, Vincent Predoehl > <vpr...@ph...> wrote: >> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ >> html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> >> Is there a response message we're supposed to send in response to >> a NewOrderSingle message? >> -- Vincent |
|
From: Jonathan K. <jon...@gm...> - 2008-05-20 19:38:44
|
The answer is -- it depends on the rules of engagement. I believe my system just sends back an execution report with a 0 quantity fill. jonathan On Tue, May 20, 2008 at 12:37 PM, Vincent Predoehl <vpr...@ph...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > Is there a response message we're supposed to send in response to a NewOrderSingle message? > -- > Vincent > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > > -- -- Jonathan Kalbfeld ThoughtWave Technologies LLC www.thoughtwave.com +1 424 354 1814 Learn UNIX For Free at unixlessons.com |
|
From: Vincent P. <vpr...@ph...> - 2008-05-20 19:36:24
|
Which field in new order single is supposed to hold the delivery date of a commodity ( month, year )? -- Vincent |
|
From: Vincent P. <vpr...@ph...> - 2008-05-20 19:35:53
|
Is there a response message we're supposed to send in response to a NewOrderSingle message? -- Vincent |
|
From: Jonathan A. <ja...@fi...> - 2008-05-16 23:52:47
|
If I hand-calculate it, it looks like my partner company is sending me the correct checksum. Also, the checksums are only off if the message size is huge. For example, when the message size is about 6232 bytes and their sum is around 351,991. For the time being, how do I ignore checksum validation? Jonathan ________________________________ From: Oren Miller [mailto:or...@qu...] Sent: Friday, May 16, 2008 4:12 PM To: Jonathan Allen Cc: qui...@li... Subject: Re: [Quickfix-users] Debugging help needed - checksums are off My guess is that they are using the BeginString field as part of the checksum calculation. They are not supposed to do this because only fields appearing after the length fuels and before the checksum field itself should be included in the checksum calculation. You can verify this by doing a checksum on just the begin stein itself ( add up the charachter values +1 for the son, mid by 256). If you get 20, that's probably your culprit. At this point they can either fix the problem, which is best, or you can use the configuration setting in quickfix to ignore checksum validation. On May 16, 2008, at 5:18 PM, "Jonathan Allen" <ja...@fi...> wrote: QuickFIX Documentation: <http://www.quickfixengine.org/quickfix/doc/html/index.html> http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: <http://www.quickfixengine.org/services.html> http://www.quickfixengine.org/services.html I am having a problem with checksums being off. As you can see from my log snippet, they seem to be consistently off by +20. My partner company is not using QuickFix, though I don't know what they are using. Recently they added a couple of stipulations, but that is just a repeating group whose fields we already know. 1. What can cause this besides them sending me the wrong checksum? 2. Is there a way to calculate the checksums by hand? 3. Is there a history of different FIX engines calculating the checksum differently? 20080516-22:07:34 : Invalid message: Expected CheckSum=34, Recieved CheckSum=54 20080516-22:07:34 : Invalid message: Expected CheckSum=201, Recieved CheckSum=221 20080516-22:07:34 : Invalid message: Expected CheckSum=35, Recieved CheckSum=55 20080516-22:07:34 : Invalid message: Expected CheckSum=169, Recieved CheckSum=189 20080516-22:07:34 : Invalid message: Expected CheckSum=47, Recieved CheckSum=67 20080516-22:07:34 : Invalid message: Expected CheckSum=204, Recieved CheckSum=224 20080516-22:07:34 : Invalid message: Expected CheckSum=151, Recieved CheckSum=171 20080516-22:07:35 : Invalid message: Expected CheckSum=148, Recieved CheckSum=168 20080516-22:07:35 : Invalid message: Expected CheckSum=212, Recieved CheckSum=232 20080516-22:07:35 : Invalid message: Expected CheckSum=216, Recieved CheckSum=236 20080516-22:07:35 : Invalid message: Expected CheckSum=238, Recieved CheckSum=2 20080516-22:07:35 : Invalid message: Expected CheckSum=28, Recieved CheckSum=48 20080516-22:07:35 : Invalid message: Expected CheckSum=226, Recieved CheckSum=246 20080516-22:07:35 : Invalid message: Expected CheckSum=72, Recieved CheckSum=92 20080516-22:07:35 : Invalid message: Expected CheckSum=205, Recieved CheckSum=225 20080516-22:07:35 : Invalid message: Expected CheckSum=84, Recieved CheckSum=104 20080516-22:07:35 : Invalid message: Expected CheckSum=200, Recieved CheckSum=220 20080516-22:07:35 : Invalid message: Expected CheckSum=59, Recieved CheckSum=79 20080516-22:07:35 : Invalid message: Expected CheckSum=183, Recieved CheckSum=203 20080516-22:07:35 : Invalid message: Expected CheckSum=245, Recieved CheckSum=9 20080516-22:07:35 : Invalid message: Expected CheckSum=67, Recieved CheckSum=87 20080516-22:07:35 : Invalid message: Expected CheckSum=45, Recieved CheckSum=65 20080516-22:07:35 : Invalid message: Expected CheckSum=196, Recieved CheckSum=216 20080516-22:07:35 : Invalid message: Expected CheckSum=218, Recieved CheckSum=238 20080516-22:07:35 : Invalid message: Expected CheckSum=18, Recieved CheckSum=38 20080516-22:07:35 : Invalid message: Expected CheckSum=237, Recieved CheckSum=1 20080516-22:07:35 : Invalid message: Expected CheckSum=123, Recieved CheckSum=143 20080516-22:07:35 : Invalid message: Expected CheckSum=93, Recieved CheckSum=113 Jonathan Allen Software Developer Fixed Income Securities, Inc. 858-547-7731 7720 Trade Street, Suite 310 San Diego, CA 92121 www.fisbonds.com Member FINRA/SIPC INFORMATION REGARDING SECURITIES IS FOR BROKER/DEALER AND REGISTERED ADVISOR USE ONLY - NOT FOR USE WITH THE PUBLIC If the reader of this message is not the intended recipient, you are notified that any disclosure, distribution or copying is prohibited. Please click here <http://www.fisbonds.com/FISBonds/PublicSite/EmailDisclosures.aspx> for additional disclosures. http://www.fisbonds.com/FISBonds/PublicSite/EmailDisclosures.aspx ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Quickfix-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-users INFORMATION REGARDING SECURITIES IS FOR BROKER/DEALER AND REGISTERED ADVISOR USE ONLY - NOT FOR USE WITH THE PUBLIC If the reader of this message is not the intended recipient, you are notified that any disclosure, distribution or copying is prohibited. Please click here for additional disclosures. http://www.fisbonds.com/FISBonds/PublicSite/EmailDisclosures.aspx |
|
From: Oren M. <or...@qu...> - 2008-05-16 23:12:10
|
My guess is that they are using the BeginString field as part of the checksum calculation. They are not supposed to do this because only fields appearing after the length fuels and before the checksum field itself should be included in the checksum calculation. You can verify this by doing a checksum on just the begin stein itself ( add up the charachter values +1 for the son, mid by 256). If you get 20, that's probably your culprit. At this point they can either fix the problem, which is best, or you can use the configuration setting in quickfix to ignore checksum validation. On May 16, 2008, at 5:18 PM, "Jonathan Allen" <ja...@fi...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > I am having a problem with checksums being off. As you can see from > my log snippet, they seem to be consistently off by +20. > > > > My partner company is not using QuickFix, though I don’t know what t > hey are using. Recently they added a couple of stipulations, but tha > t is just a repeating group whose fields we already know. > > > > 1. What can cause this besides them sending me the wrong checksum? > > 2. Is there a way to calculate the checksums by hand? > > 3. Is there a history of different FIX engines calculating the > checksum differently? > > > > 20080516-22:07:34 : Invalid message: Expected CheckSum=34, Recieved > CheckSum=54 > > 20080516-22:07:34 : Invalid message: Expected CheckSum=201, Recieved > CheckSum=221 > > 20080516-22:07:34 : Invalid message: Expected CheckSum=35, Recieved > CheckSum=55 > > 20080516-22:07:34 : Invalid message: Expected CheckSum=169, Recieved > CheckSum=189 > > 20080516-22:07:34 : Invalid message: Expected CheckSum=47, Recieved > CheckSum=67 > > 20080516-22:07:34 : Invalid message: Expected CheckSum=204, Recieved > CheckSum=224 > > 20080516-22:07:34 : Invalid message: Expected CheckSum=151, Recieved > CheckSum=171 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=148, Recieved > CheckSum=168 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=212, Recieved > CheckSum=232 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=216, Recieved > CheckSum=236 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=238, Recieved > CheckSum=2 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=28, Recieved > CheckSum=48 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=226, Recieved > CheckSum=246 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=72, Recieved > CheckSum=92 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=205, Recieved > CheckSum=225 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=84, Recieved > CheckSum=104 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=200, Recieved > CheckSum=220 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=59, Recieved > CheckSum=79 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=183, Recieved > CheckSum=203 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=245, Recieved > CheckSum=9 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=67, Recieved > CheckSum=87 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=45, Recieved > CheckSum=65 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=196, Recieved > CheckSum=216 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=218, Recieved > CheckSum=238 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=18, Recieved > CheckSum=38 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=237, Recieved > CheckSum=1 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=123, Recieved > CheckSum=143 > > 20080516-22:07:35 : Invalid message: Expected CheckSum=93, Recieved > CheckSum=113 > > > > Jonathan Allen > > Software Developer > > Fixed Income Securities, Inc. > > 858-547-7731 > > 7720 Trade Street, Suite 310 > > San Diego, CA 92121 > > www.fisbonds.com > > Member FINRA/SIPC > > INFORMATION REGARDING SECURITIES IS FOR BROKER/DEALER AND REGISTERED > ADVISOR USE ONLY - NOT FOR USE WITH THE PUBLIC If the reader of this > message is not the intended recipient, you are notified that any > disclosure, distribution or copying is prohibited. Please click here > for additional disclosures. > > http://www.fisbonds.com/FISBonds/PublicSite/EmailDisclosures.aspx > > --- > ---------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users |
|
From: Jonathan A. <ja...@fi...> - 2008-05-16 22:18:43
|
I am having a problem with checksums being off. As you can see from my log snippet, they seem to be consistently off by +20. My partner company is not using QuickFix, though I don't know what they are using. Recently they added a couple of stipulations, but that is just a repeating group whose fields we already know. 1. What can cause this besides them sending me the wrong checksum? 2. Is there a way to calculate the checksums by hand? 3. Is there a history of different FIX engines calculating the checksum differently? 20080516-22:07:34 : Invalid message: Expected CheckSum=34, Recieved CheckSum=54 20080516-22:07:34 : Invalid message: Expected CheckSum=201, Recieved CheckSum=221 20080516-22:07:34 : Invalid message: Expected CheckSum=35, Recieved CheckSum=55 20080516-22:07:34 : Invalid message: Expected CheckSum=169, Recieved CheckSum=189 20080516-22:07:34 : Invalid message: Expected CheckSum=47, Recieved CheckSum=67 20080516-22:07:34 : Invalid message: Expected CheckSum=204, Recieved CheckSum=224 20080516-22:07:34 : Invalid message: Expected CheckSum=151, Recieved CheckSum=171 20080516-22:07:35 : Invalid message: Expected CheckSum=148, Recieved CheckSum=168 20080516-22:07:35 : Invalid message: Expected CheckSum=212, Recieved CheckSum=232 20080516-22:07:35 : Invalid message: Expected CheckSum=216, Recieved CheckSum=236 20080516-22:07:35 : Invalid message: Expected CheckSum=238, Recieved CheckSum=2 20080516-22:07:35 : Invalid message: Expected CheckSum=28, Recieved CheckSum=48 20080516-22:07:35 : Invalid message: Expected CheckSum=226, Recieved CheckSum=246 20080516-22:07:35 : Invalid message: Expected CheckSum=72, Recieved CheckSum=92 20080516-22:07:35 : Invalid message: Expected CheckSum=205, Recieved CheckSum=225 20080516-22:07:35 : Invalid message: Expected CheckSum=84, Recieved CheckSum=104 20080516-22:07:35 : Invalid message: Expected CheckSum=200, Recieved CheckSum=220 20080516-22:07:35 : Invalid message: Expected CheckSum=59, Recieved CheckSum=79 20080516-22:07:35 : Invalid message: Expected CheckSum=183, Recieved CheckSum=203 20080516-22:07:35 : Invalid message: Expected CheckSum=245, Recieved CheckSum=9 20080516-22:07:35 : Invalid message: Expected CheckSum=67, Recieved CheckSum=87 20080516-22:07:35 : Invalid message: Expected CheckSum=45, Recieved CheckSum=65 20080516-22:07:35 : Invalid message: Expected CheckSum=196, Recieved CheckSum=216 20080516-22:07:35 : Invalid message: Expected CheckSum=218, Recieved CheckSum=238 20080516-22:07:35 : Invalid message: Expected CheckSum=18, Recieved CheckSum=38 20080516-22:07:35 : Invalid message: Expected CheckSum=237, Recieved CheckSum=1 20080516-22:07:35 : Invalid message: Expected CheckSum=123, Recieved CheckSum=143 20080516-22:07:35 : Invalid message: Expected CheckSum=93, Recieved CheckSum=113 Jonathan Allen Software Developer Fixed Income Securities, Inc. 858-547-7731 7720 Trade Street, Suite 310 San Diego, CA 92121 www.fisbonds.com Member FINRA/SIPC INFORMATION REGARDING SECURITIES IS FOR BROKER/DEALER AND REGISTERED ADVISOR USE ONLY - NOT FOR USE WITH THE PUBLIC If the reader of this message is not the intended recipient, you are notified that any disclosure, distribution or copying is prohibited. Please click here for additional disclosures. http://www.fisbonds.com/FISBonds/PublicSite/EmailDisclosures.aspx |
|
From: <or...@qu...> - 2008-05-16 13:41:41
|
No, but you could generate your own warnings by comparing the times of the messages against the current time. --oren > -------- Original Message -------- > Subject: Re: [Quickfix-users] SendingTime accuracy problem causes > client disconnect. > From: "Rodrick Brown" <rod...@gm...> > Date: Thu, May 15, 2008 5:38 pm > To: "Djalma Rosa dos Santos Filho" <drs...@gm...> > Cc: qui...@li..., > qui...@li... > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > It seems with this option in place we're no longer seeing the reject > message. Is there anyway to still have this reject message generated > and not drop the client? > On Thu, May 15, 2008 at 4:22 PM, Djalma Rosa dos Santos Filho > <drs...@gm...> wrote: > > Yes, this is quickfix behavior, but you can set CheckLatency=N or increase > > the MaxLatency value. > > > > On Thu, May 15, 2008 at 3:33 PM, Rodrick Brown <rod...@gm...> > > wrote: > >> > >> QuickFIX Documentation: > >> http://www.quickfixengine.org/quickfix/doc/html/index.html > >> QuickFIX Support: http://www.quickfixengine.org/services.html > >> > >> We're processing orders from queue which can get fairly large some > >> orders end up being processed after the default SendingTime (120s). We > >> then send back "Message 569 Rejected: SendingTime accuracy problem" > >> back to the client which causes our client to disconnect is this the > >> correct behavior? > >> > >> We dont want our client to be disconnected on these types of rejects. > >> Has anyone else seen this? > >> > >> 20080515-17:55:58: Acceptor heartbeat set to 45 seconds > >> 20080515-17:55:58: Logon contains ResetSeqNumFlag=Y, resetting > >> sequence numbers to 1 > >> 20080515-17:55:58: Received logon request > >> 20080515-17:55:58: Responding to logon request > >> 20080515-18:00:20: Message 569 Rejected: SendingTime accuracy problem > >> 20080515-18:00:20: Message 570 Rejected: SendingTime accuracy problem > >> 20080515-18:00:20: Disconnecting > >> > >> > >> -- > >> [ Rodrick R. Brown ] > >> http://www.linkedin.com/in/rodrickbrown > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Quickfix-users mailing list > >> Qui...@li... > >> https://lists.sourceforge.net/lists/listinfo/quickfix-users > > > > > -- > [ Rodrick R. Brown ] > http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users |
|
From: Rodrick B. <rod...@gm...> - 2008-05-15 22:38:27
|
It seems with this option in place we're no longer seeing the reject message. Is there anyway to still have this reject message generated and not drop the client? On Thu, May 15, 2008 at 4:22 PM, Djalma Rosa dos Santos Filho <drs...@gm...> wrote: > Yes, this is quickfix behavior, but you can set CheckLatency=N or increase > the MaxLatency value. > > On Thu, May 15, 2008 at 3:33 PM, Rodrick Brown <rod...@gm...> > wrote: >> >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> We're processing orders from queue which can get fairly large some >> orders end up being processed after the default SendingTime (120s). We >> then send back "Message 569 Rejected: SendingTime accuracy problem" >> back to the client which causes our client to disconnect is this the >> correct behavior? >> >> We dont want our client to be disconnected on these types of rejects. >> Has anyone else seen this? >> >> 20080515-17:55:58: Acceptor heartbeat set to 45 seconds >> 20080515-17:55:58: Logon contains ResetSeqNumFlag=Y, resetting >> sequence numbers to 1 >> 20080515-17:55:58: Received logon request >> 20080515-17:55:58: Responding to logon request >> 20080515-18:00:20: Message 569 Rejected: SendingTime accuracy problem >> 20080515-18:00:20: Message 570 Rejected: SendingTime accuracy problem >> 20080515-18:00:20: Disconnecting >> >> >> -- >> [ Rodrick R. Brown ] >> http://www.linkedin.com/in/rodrickbrown >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Quickfix-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-users > > -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown |
|
From: Rodrick B. <rod...@gm...> - 2008-05-15 21:46:25
|
This was a stress test thanks to all for the fix works like a charm. On Thu, May 15, 2008 at 4:21 PM, Ted Graham <tg...@co...> wrote: > > It appears from your mail that you are taking more than 2 minutes to process > a message. > > Am I understanding you correctly that incoming messages are staying in the > inbound queue for 120 seconds? If so, I think you should investigate why it > is taking so long to process messages, rather than raise your SendingTime > threshold. > > Ted > > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On Behalf Of Rodrick > Brown > Sent: Thursday, May 15, 2008 12:34 PM > To: qui...@li...; > qui...@li... > Subject: [Quickfix-users] SendingTime accuracy problem causes > clientdisconnect. > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > We're processing orders from queue which can get fairly large some > orders end up being processed after the default SendingTime (120s). We > then send back "Message 569 Rejected: SendingTime accuracy problem" > back to the client which causes our client to disconnect is this the > correct behavior? > > We dont want our client to be disconnected on these types of rejects. > Has anyone else seen this? > > 20080515-17:55:58: Acceptor heartbeat set to 45 seconds > 20080515-17:55:58: Logon contains ResetSeqNumFlag=Y, resetting > sequence numbers to 1 > 20080515-17:55:58: Received logon request > 20080515-17:55:58: Responding to logon request > 20080515-18:00:20: Message 569 Rejected: SendingTime accuracy problem > 20080515-18:00:20: Message 570 Rejected: SendingTime accuracy problem > 20080515-18:00:20: Disconnecting > > > -- > [ Rodrick R. Brown ] > http://www.linkedin.com/in/rodrickbrown > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > > > -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown |
|
From: Djalma R. d. S. F. <drs...@gm...> - 2008-05-15 20:23:15
|
Yes, this is quickfix behavior, but you can set CheckLatency=N or increase the MaxLatency value. On Thu, May 15, 2008 at 3:33 PM, Rodrick Brown <rod...@gm...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > We're processing orders from queue which can get fairly large some > orders end up being processed after the default SendingTime (120s). We > then send back "Message 569 Rejected: SendingTime accuracy problem" > back to the client which causes our client to disconnect is this the > correct behavior? > > We dont want our client to be disconnected on these types of rejects. > Has anyone else seen this? > > 20080515-17:55:58: Acceptor heartbeat set to 45 seconds > 20080515-17:55:58: Logon contains ResetSeqNumFlag=Y, resetting > sequence numbers to 1 > 20080515-17:55:58: Received logon request > 20080515-17:55:58: Responding to logon request > 20080515-18:00:20: Message 569 Rejected: SendingTime accuracy problem > 20080515-18:00:20: Message 570 Rejected: SendingTime accuracy problem > 20080515-18:00:20: Disconnecting > > > -- > [ Rodrick R. Brown ] > http://www.linkedin.com/in/rodrickbrown > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > |
|
From: Ted G. <tg...@Co...> - 2008-05-15 20:22:05
|
It appears from your mail that you are taking more than 2 minutes to process a message. Am I understanding you correctly that incoming messages are staying in the inbound queue for 120 seconds? If so, I think you should investigate why it is taking so long to process messages, rather than raise your SendingTime threshold. Ted -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Rodrick Brown Sent: Thursday, May 15, 2008 12:34 PM To: qui...@li...; qui...@li... Subject: [Quickfix-users] SendingTime accuracy problem causes clientdisconnect. QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html We're processing orders from queue which can get fairly large some orders end up being processed after the default SendingTime (120s). We then send back "Message 569 Rejected: SendingTime accuracy problem" back to the client which causes our client to disconnect is this the correct behavior? We dont want our client to be disconnected on these types of rejects. Has anyone else seen this? 20080515-17:55:58: Acceptor heartbeat set to 45 seconds 20080515-17:55:58: Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1 20080515-17:55:58: Received logon request 20080515-17:55:58: Responding to logon request 20080515-18:00:20: Message 569 Rejected: SendingTime accuracy problem 20080515-18:00:20: Message 570 Rejected: SendingTime accuracy problem 20080515-18:00:20: Disconnecting -- [ Rodrick R. Brown ] http://www.linkedin.com/in/rodrickbrown ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Quickfix-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-users |
38 messages has been excluded from this view by a project administrator.
