Menu
▾
▴
quickfixj-users — General mailing list for QuickFIX/J topics.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(21) |
Jul
(14) |
Aug
(29) |
Sep
(39) |
Oct
(47) |
Nov
(70) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(43) |
Feb
(50) |
Mar
(90) |
Apr
(96) |
May
(84) |
Jun
(40) |
Jul
(58) |
Aug
(55) |
Sep
(55) |
Oct
(52) |
Nov
(38) |
Dec
(75) |
| 2008 |
Jan
(49) |
Feb
(72) |
Mar
(49) |
Apr
(55) |
May
(21) |
Jun
(31) |
Jul
(47) |
Aug
(59) |
Sep
(59) |
Oct
(77) |
Nov
(51) |
Dec
(54) |
| 2009 |
Jan
(52) |
Feb
(57) |
Mar
(17) |
Apr
(27) |
May
(44) |
Jun
(46) |
Jul
(69) |
Aug
(38) |
Sep
(39) |
Oct
(45) |
Nov
(38) |
Dec
(37) |
| 2010 |
Jan
(49) |
Feb
(35) |
Mar
(21) |
Apr
(33) |
May
(52) |
Jun
(28) |
Jul
(39) |
Aug
(34) |
Sep
(21) |
Oct
(82) |
Nov
(36) |
Dec
(20) |
| 2011 |
Jan
(28) |
Feb
(64) |
Mar
(93) |
Apr
(75) |
May
(151) |
Jun
(77) |
Jul
(35) |
Aug
(53) |
Sep
(56) |
Oct
(36) |
Nov
(94) |
Dec
(59) |
| 2012 |
Jan
(105) |
Feb
(43) |
Mar
(68) |
Apr
(91) |
May
(45) |
Jun
(18) |
Jul
(103) |
Aug
(77) |
Sep
(45) |
Oct
(59) |
Nov
(58) |
Dec
(43) |
| 2013 |
Jan
(48) |
Feb
(65) |
Mar
(63) |
Apr
(22) |
May
(41) |
Jun
(60) |
Jul
(43) |
Aug
(17) |
Sep
(20) |
Oct
(20) |
Nov
(42) |
Dec
(43) |
| 2014 |
Jan
(54) |
Feb
(34) |
Mar
(34) |
Apr
(20) |
May
(31) |
Jun
(39) |
Jul
(66) |
Aug
(22) |
Sep
(52) |
Oct
(22) |
Nov
(67) |
Dec
(70) |
| 2015 |
Jan
(18) |
Feb
(5) |
Mar
(40) |
Apr
(32) |
May
(62) |
Jun
(28) |
Jul
(86) |
Aug
(44) |
Sep
(61) |
Oct
(65) |
Nov
(8) |
Dec
(19) |
| 2016 |
Jan
(50) |
Feb
(22) |
Mar
(38) |
Apr
(55) |
May
(30) |
Jun
(42) |
Jul
(11) |
Aug
(9) |
Sep
(4) |
Oct
(51) |
Nov
(38) |
Dec
(31) |
| 2017 |
Jan
(40) |
Feb
(40) |
Mar
(23) |
Apr
(35) |
May
(121) |
Jun
(55) |
Jul
(37) |
Aug
(16) |
Sep
(27) |
Oct
(109) |
Nov
(67) |
Dec
(23) |
| 2018 |
Jan
(52) |
Feb
(6) |
Mar
(23) |
Apr
(28) |
May
(32) |
Jun
(20) |
Jul
(20) |
Aug
(22) |
Sep
(8) |
Oct
(33) |
Nov
(32) |
Dec
(13) |
| 2019 |
Jan
(16) |
Feb
(29) |
Mar
(17) |
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
(25) |
Aug
(50) |
Sep
(17) |
Oct
(29) |
Nov
(16) |
Dec
(7) |
| 2020 |
Jan
|
Feb
|
Mar
(29) |
Apr
(64) |
May
(25) |
Jun
(49) |
Jul
(15) |
Aug
(10) |
Sep
(37) |
Oct
(20) |
Nov
(19) |
Dec
(9) |
| 2021 |
Jan
(33) |
Feb
(10) |
Mar
(67) |
Apr
(40) |
May
(70) |
Jun
(33) |
Jul
(14) |
Aug
(10) |
Sep
|
Oct
(7) |
Nov
(6) |
Dec
(16) |
| 2022 |
Jan
(27) |
Feb
(2) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(10) |
| 2023 |
Jan
(1) |
Feb
(2) |
Mar
(21) |
Apr
(3) |
May
(15) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2024 |
Jan
(7) |
Feb
(2) |
Mar
(8) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2025 |
Jan
(10) |
Feb
(4) |
Mar
(9) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2026 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chris M. <chr...@ne...> - 2026-02-03 17:06:40
|
Hi,We are trying to connect quickfixj to a venue via a http/connect based proxy.This link worked fine using SOCKS and a curl command also connects through to the client with http/connect without problem In the log Im seeing this error, it looks very similar to previous support mails, I believe from reading them that the first 407 is expected but it should then try to authenticate with the username/pwd? Does quickfixj support HTTP/CONNECT and if so which version ?Is it possible to turn on logging in the Apache mina component as well ?Thanks,Chris 2026-02-03 11:58:43.156 [main] INFO quickfix.mina.ProtocolFactory: Creating proxy request: type = HTTP user = GFFSRVCD pwd = (thepassword) 2026-02-03 11:58:43.161 [main] INFO quickfix.ThreadedSocketInitiator: SessionTimer started 2026-02-03 11:58:43.177 [main] INFO com.baml.gffrepoet.quickfixj.QuickFIXJClient: Started QuickFIXJClient in 3.511 seconds (JVM running for 7.342) 2026-02-03 11:58:43.317 [NioProcessor-2] ERROR quickfix.mina.initiator.InitiatorIoHandler: Socket (appproxy.emea.bank.com/165.34.124.114:8080): org.apache.mina.proxy.ProxyAuthException: Received error response code (407 authenticationrequired). org.apache.mina.proxy.ProxyAuthException: Received error response code (407 authenticationrequired). at org.apache.mina.proxy.handlers.http.basic.HttpNoAuthLogicHandler.handleResponse(HttpNoAuthLogicHandler.java:70) at org.apache.mina.proxy.handlers.http.HttpSmartProxyHandler.handleResponse(HttpSmartProxyHandler.java:206) at org.apache.mina.proxy.handlers.http.AbstractHttpLogicHandler.messageReceived(AbstractHttpLogicHandler.java:268) at org.apache.mina.proxy.filter.ProxyFilter.messageReceived(ProxyFilter.java:168) . |
|
From: Christoph J. <chr...@fo...> - 2026-02-02 18:08:44
|
Hi Ankit, The NewSeqNo on the incoming SequenceReset sets the incoming seqnum from to 62002. So between 60489 and 62002 the counterparty did not send any application messages, just session messages (e.g. heartbeats). Can you confirm this from the logs? Actually QFJ should realise that setting the seqnum to 62002 should satsify the resend request. Your QFJ version seems to be relatively current, so it *might* be a bug. I don’t know how many users are using the chunked resend requests, so this might be a corner case that no-one else ran into. Can you provide the related event and message logs? But better send them privately, NOT to the list. Cheers Chris -- Christoph John Software Engineering [cid:image001.png@01DC946B.039F5F20] Foconis Trading GmbH Oppenhoffallee 103 52066 Aachen Web: https://foconis.com<https://foconis.com/> E-Mail: chr...@fo...<mailto:chr...@fo...> Tel.: +49 241 557080 28 / Zentrale-0 Geschäftsführer: Peter Kretzmann, George Macdonald Amtsgericht Hamburg: HRB 46346 | USt-IDNr.: DE118680003 Unsere Hinweise zum Datenschutz sind hier zu entnehmen (Artikel 13, 14 und 21 EU-DSGVO): https://group.foconis.com/datenschutz From: Ankit Mehta <ank...@gm...> Sent: 31 January 2026 17:04 To: qui...@li... Subject: Re: [Quickfixj-users] Issue related to message recovery You don't often get email from ank...@gm...<mailto:ank...@gm...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Thanks Chris for coming back. Analysed further by looking the INCOMING and EVENTS logs and this is what I think happened, could you please check and confirm if this is correct understanding- 1. Gap Detected: Expected 57989, received 61989 2. Resend Requests Sent: 57989 -> 60488 and then 60489 -> 61989 (since they are chunked) 3. Live/New messages arrived that gets queued up: 61993/61994-61995…. 4. Sequence Reset received from their end with tag 34=60489 and tag 36=62002 And this in my understanding caused the queued message from being processed, since they asked us to reset to 62002. The new seq no tag on the sequence reset message here was the culprit? Let me know your thoughts on this. Thanks, Ankit On Sat, 31 Jan 2026 at 9:11 PM, Christoph John via Quickfixj-users <qui...@li...<mailto:qui...@li...>> wrote: Hi Queued messages are not processed until the resend request has been satisfied. E.g. if you are waiting for a resend of messages up to seqnum 1000, all seqnums lower than 1000 are not processed until message seqnum 1000 has been received. Cheers Chris -- Christoph John Software Engineering Foconis Trading GmbH Oppenhoffallee 103<https://www.google.com/maps/search/Oppenhoffallee+103+%0D%0A+%0D%0A+52066+Aachen?entry=gmail&source=g> 52066 Aachen<https://www.google.com/maps/search/Oppenhoffallee+103+%0D%0A+%0D%0A+52066+Aachen?entry=gmail&source=g> Web: https://foconis.com<https://foconis.com/> E-Mail: chr...@fo...<mailto:chr...@fo...> Tel.: +49 241 557080 28 / Zentrale-0 Geschäftsführer: Peter Kretzmann, George Macdonald Amtsgericht Hamburg: HRB 46346 | USt-IDNr.: DE118680003 Unsere Hinweise zum Datenschutz sind hier zu entnehmen (Artikel 13, 14 und 21 EU-DSGVO): https://group.foconis.com/datenschutz ________________________________ From: Ankit Mehta <ank...@gm...<mailto:ank...@gm...>> Sent: 31 January 2026 09:25 To: qui...@li...<mailto:qui...@li...> <qui...@li...<mailto:qui...@li...>> Subject: [Quickfixj-users] Issue related to message recovery You don't often get email from ank...@gm...<mailto:ank...@gm...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> hi team, We had an issue recently wherein there was a disconnection on the acceptor side. The initiator rightly failed over to the second host and sent a resend request, which was fulfilled by the server as well. The instability persisted and we noticed multiple resend requests were sent in between. What we noticed though, during the time the application was catering to processing re-sent messages, when new messages were coming in at the same time they were getting queued up. We saw lines like below in the events logs: MsgSeqNum too high expecting <> but received <> .... Enqueued at pos: <num> In ideal scenarios, which I can see for certain messages in the beginning, we see log like this: Processing queued message: <num> But we do not see this happening for the majority of these new trade messages causing the messages to be eventually missed. We are on quickfix all version 2.3.0. Would anyone have seen such an issue and can opine what could have happened? Regards, Ankit |
|
From: Ankit M. <ank...@gm...> - 2026-01-31 16:04:48
|
Thanks Chris for coming back. Analysed further by looking the INCOMING and EVENTS logs and this is what I think happened, could you please check and confirm if this is correct understanding- 1. Gap Detected: Expected 57989, received 61989 2. Resend Requests Sent: 57989 -> 60488 and then 60489 -> 61989 (since they are chunked) 3. Live/New messages arrived that gets queued up: 61993/61994-61995…. 4. Sequence Reset received from their end with tag 34=60489 and tag 36=62002 And this in my understanding caused the queued message from being processed, since they asked us to reset to 62002. The new seq no tag on the sequence reset message here was the culprit? Let me know your thoughts on this. Thanks, Ankit On Sat, 31 Jan 2026 at 9:11 PM, Christoph John via Quickfixj-users < qui...@li...> wrote: > Hi > > > Queued messages are not processed until the resend request has been > satisfied. E.g. if you are waiting for a resend of messages up to seqnum > 1000, all seqnums lower than 1000 are not processed until message seqnum > 1000 has been received. > > Cheers > Chris > > *--* > > *Christoph John* > > Software Engineering > > > > > <https://www.google.com/maps/search/Oppenhoffallee+103+%0D%0A+%0D%0A+52066+Aachen?entry=gmail&source=g> > <https://www.google.com/maps/search/Oppenhoffallee+103+%0D%0A+%0D%0A+52066+Aachen?entry=gmail&source=g> > > Foconis Trading GmbH > > Oppenhoffallee 103 > <https://www.google.com/maps/search/Oppenhoffallee+103+%0D%0A+%0D%0A+52066+Aachen?entry=gmail&source=g> > > 52066 Aachen > <https://www.google.com/maps/search/Oppenhoffallee+103+%0D%0A+%0D%0A+52066+Aachen?entry=gmail&source=g> > > > > Web: *https://foconis.com <https://foconis.com/>* > > E-Mail: *chr...@fo... <chr...@fo...>* > > Tel.: +49 241 557080 28 / Zentrale-0 > > > > Geschäftsführer: Peter Kretzmann, George Macdonald > > Amtsgericht Hamburg: HRB 46346 | USt-IDNr.: DE118680003 > Unsere Hinweise zum Datenschutz sind hier zu entnehmen (Artikel 13, 14 und > 21 EU-DSGVO): > > https://group.foconis.com/datenschutz > > > ------------------------------ > *From:* Ankit Mehta <ank...@gm...> > *Sent:* 31 January 2026 09:25 > *To:* qui...@li... < > qui...@li...> > *Subject:* [Quickfixj-users] Issue related to message recovery > > You don't often get email from ank...@gm.... Learn why this > is important <https://aka.ms/LearnAboutSenderIdentification> > hi team, > > We had an issue recently wherein there was a disconnection on the acceptor > side. > The initiator rightly failed over to the second host and sent a resend > request, which was fulfilled by the server as well. > The instability persisted and we noticed multiple resend requests were > sent in between. > What we noticed though, during the time the application was catering to > processing re-sent messages, when new messages were coming in at the same > time they were getting queued up. > > We saw lines like below in the events logs: > > MsgSeqNum too high expecting <> but received <> .... > Enqueued at pos: <num> > > In ideal scenarios, which I can see for certain messages in the beginning, > we see log like this: > Processing queued message: <num> > > But we do not see this happening for the majority of these new trade > messages causing the messages to be eventually missed. > > We are on quickfix all version 2.3.0. > Would anyone have seen such an issue and can opine what could > have happened? > > Regards, > Ankit > |
|
From: Christoph J. <chr...@fo...> - 2026-01-31 15:40:18
|
Hi Queued messages are not processed until the resend request has been satisfied. E.g. if you are waiting for a resend of messages up to seqnum 1000, all seqnums lower than 1000 are not processed until message seqnum 1000 has been received. Cheers Chris -- Christoph John Software Engineering [X] Foconis Trading GmbH Oppenhoffallee 103 52066 Aachen Web: https://foconis.com<https://foconis.com/> E-Mail: chr...@fo...<mailto:chr...@fo...> Tel.: +49 241 557080 28 / Zentrale-0 Geschäftsführer: Peter Kretzmann, George Macdonald Amtsgericht Hamburg: HRB 46346 | USt-IDNr.: DE118680003 Unsere Hinweise zum Datenschutz sind hier zu entnehmen (Artikel 13, 14 und 21 EU-DSGVO): https://group.foconis.com/datenschutz ________________________________ From: Ankit Mehta <ank...@gm...> Sent: 31 January 2026 09:25 To: qui...@li... <qui...@li...> Subject: [Quickfixj-users] Issue related to message recovery You don't often get email from ank...@gm.... Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> hi team, We had an issue recently wherein there was a disconnection on the acceptor side. The initiator rightly failed over to the second host and sent a resend request, which was fulfilled by the server as well. The instability persisted and we noticed multiple resend requests were sent in between. What we noticed though, during the time the application was catering to processing re-sent messages, when new messages were coming in at the same time they were getting queued up. We saw lines like below in the events logs: MsgSeqNum too high expecting <> but received <> .... Enqueued at pos: <num> In ideal scenarios, which I can see for certain messages in the beginning, we see log like this: Processing queued message: <num> But we do not see this happening for the majority of these new trade messages causing the messages to be eventually missed. We are on quickfix all version 2.3.0. Would anyone have seen such an issue and can opine what could have happened? Regards, Ankit |
|
From: Ankit M. <ank...@gm...> - 2026-01-31 08:26:07
|
hi team, We had an issue recently wherein there was a disconnection on the acceptor side. The initiator rightly failed over to the second host and sent a resend request, which was fulfilled by the server as well. The instability persisted and we noticed multiple resend requests were sent in between. What we noticed though, during the time the application was catering to processing re-sent messages, when new messages were coming in at the same time they were getting queued up. We saw lines like below in the events logs: MsgSeqNum too high expecting <> but received <> .... Enqueued at pos: <num> In ideal scenarios, which I can see for certain messages in the beginning, we see log like this: Processing queued message: <num> But we do not see this happening for the majority of these new trade messages causing the messages to be eventually missed. We are on quickfix all version 2.3.0. Would anyone have seen such an issue and can opine what could have happened? Regards, Ankit |
|
From: Philip W. <Phi...@fl...> - 2025-05-22 16:48:59
|
Hi folks, I'm looking into a string-encoding problem and one solution might be to enhance the QFJ support for charsets - ideally allowing UTF-8 on one side and Latin-1 on the other. I'm trying to wrap my head around why 'isStringEquivalent' works in practice As I understand it the binary representation of $ is: Latin-1 / ISO-8859-1 24 UTF-16BE 0024 UTF-8 24 And the binary representation of ÿ is: Latin-1 / ISO-8859-1 FF UTF-16BE 00FF UTF-8 C5 B8 I assume that it's related to the second byte being equivalent to the single byte in Latin-1? How does QFJ get away with ignoring the leading byte? Is this dealt with by MINA? Best, Philip Whitehouse FlexTrade Ltd. This communication is for informational purposes only. The contents of this transmission are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the sender by return email and delete this message from your system. FlexTrade Systems Inc., its subsidiaries and affiliates do not guarantee the completeness and accuracy of this transmission's contents. Moreover, FlexTrade Systems Inc., its subsidiaries and affiliates do not guarantee this communication to be free of viruses and accept no liability for any damage caused thereof. |
|
From: Christoph J. <chr...@ma...> - 2025-05-21 12:29:48
|
Hi The store only stores outgoing messages to fulfill resend requests. You need to store incoming messages by yourself if you want to do that. Cheers Chris -- Christoph John Software Engineering D +49 241 557080 28<tel:+4924155708028> chr...@ma...<mailto:chr...@ma...> [image] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [image]<https://www.linkedin.com/company/macd/> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald und Florian Festner ________________________________ From: M J <mje...@gm...> Sent: Wednesday, May 21, 2025 9:58:36 AM To: qui...@li... <qui...@li...> Subject: [Quickfixj-users] message not in .body Hi, I have FileStorePath set up. All fine, .body and other .(dot) files are there. BUT in messages received are not reflected / stored in .body or elsewhere. In .body I only see 35=0 and 35=5 messages. Pls for guidance. I am using 2.2.0 version Kind regards Matjaž |
|
From: M J <mje...@gm...> - 2025-05-21 07:59:23
|
Hi, I have FileStorePath set up. All fine, .body and other .(dot) files are there. BUT in messages received are not reflected / stored in .body or elsewhere. In .body I only see 35=0 and 35=5 messages. Pls for guidance. I am using 2.2.0 version Kind regards Matjaž |
|
From: Christoph J. <chr...@ma...> - 2025-03-26 12:27:13
|
Hi, I don’t know how you build your project, but it sounds like by default the MINA dependency is pulled in but not when you build your custom JAR? However, adding the MINA dependency should solve your problem. Best regards Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB9E38.3099BAE0] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB9E38.3099BAE0]<https://www.linkedin.com/company/macd/> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: M J <mje...@gm...> Sent: 24 March 2025 19:47 To: qui...@li... Subject: [Quickfixj-users] rebuild mina error Hi quickfixj 2.2.0 I modified fix44.modified.xml and rebuild all together. Now, if I include quickfix-core and messages-all from rebuild, I get below error Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/mina/core/buffer/IoBufferAllocator at si.nlb.mj.fixacceptor.FixAcceptor.main(FixAcceptor.java:35) Caused by: java.lang.ClassNotFoundException: org.apache.mina.core.buffer.IoBufferAllocator at java.net.URLClassLoader.findClass(URLClassLoader.java:382) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) If I leave the original quickfix-core (from maven) and only use rebuilt messages-all, it is fine. What am I missing? Thanks. Regards Matjaž |
|
From: M J <mje...@gm...> - 2025-03-24 18:47:52
|
Hi
quickfixj 2.2.0
I modified fix44.modified.xml and rebuild all together. Now, if I include
quickfix-core and messages-all from rebuild, I get below error
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/mina/core/buffer/IoBufferAllocator
at si.nlb.mj.fixacceptor.FixAcceptor.main(FixAcceptor.java:35)
Caused by: java.lang.ClassNotFoundException:
org.apache.mina.core.buffer.IoBufferAllocator
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
If I leave the original quickfix-core (from maven) and only use rebuilt
messages-all, it is fine.
What am I missing?
Thanks.
Regards
Matjaž
|
|
From: M J <mje...@gm...> - 2025-03-23 20:14:18
|
Good evening, Yes, it helps. Thanks for pointing this out for me. I will continue to work on 2.3.2. for the time being. Kind regards Matjaž On Sun, 23 Mar 2025 at 11:55, Christoph John <chr...@ma...> wrote: > Hi Matjaž, > > There were some changes made to the code generation, mainly to incorporate > support for Orchestra and to get rid of the dependencies that the core > module had on the message module. > However, could you please check this discussion and let me know if it > helps. https://github.com/quickfix-j/quickfixj/issues/883 > > Cheers > Chris > > > ------------------------------ > *From:* M J <mje...@gm...> > *Sent:* Saturday, March 22, 2025 10:32:19 PM > *To:* qui...@li... < > qui...@li...> > *Subject:* Re: [Quickfixj-users] new module > > Sie erhalten nicht häufig E-Mails von mje...@gm.... Erfahren Sie, > warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification> > Forgot to add: but it is listed under > > [INFO] Reactor Build Order > > Regards > > On Sat, 22 Mar 2025 at 22:30, M J <mje...@gm...> wrote: > >> Just picked up the latest from github. >> Could not get it done. Codegenerator is skipping it: >> >> quickfixj-codegenerator:3.0.0-SNAPSHOT:generate (<version>) ---> this >> part is not present for my custom module nor are classes for new fields >> generated. >> >> Regards >> Matjaž >> >> >> >> On Sat, 22 Mar 2025 at 21:34, Christoph John <chr...@ma...> >> wrote: >> >>> Which QFJ version are you using? >>> But basically it should work as you suggested. >>> Cheers >>> Chris >>> >>> ------------------------------ >>> *From:* M J <mje...@gm...> >>> *Sent:* Saturday, March 22, 2025 4:38:40 PM >>> *To:* qui...@li... < >>> qui...@li...> >>> *Subject:* [Quickfixj-users] new module >>> >>> Sie erhalten nicht häufig E-Mails von mje...@gm.... Erfahren >>> Sie, warum dies wichtig ist >>> <https://aka.ms/LearnAboutSenderIdentification> >>> Hi to all, >>> >>> I have a new DD xml, a lot of additional fields compared to 44. Could I >>> just create a new module e. g. quickfixj-messages-fixMY and rebuild? I >>> guess not, but have to ask. Thanks. >>> >>> Kind regards >>> Matjaž >>> >> > |
|
From: Christoph J. <chr...@ma...> - 2025-03-23 10:54:49
|
Hi Matjaž, There were some changes made to the code generation, mainly to incorporate support for Orchestra and to get rid of the dependencies that the core module had on the message module. However, could you please check this discussion and let me know if it helps. https://github.com/quickfix-j/quickfixj/issues/883 Cheers Chris ________________________________ From: M J <mje...@gm...> Sent: Saturday, March 22, 2025 10:32:19 PM To: qui...@li... <qui...@li...> Subject: Re: [Quickfixj-users] new module Sie erhalten nicht häufig E-Mails von mje...@gm.... Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification> Forgot to add: but it is listed under [INFO] Reactor Build Order Regards On Sat, 22 Mar 2025 at 22:30, M J <mje...@gm...<mailto:mje...@gm...>> wrote: Just picked up the latest from github. Could not get it done. Codegenerator is skipping it: quickfixj-codegenerator:3.0.0-SNAPSHOT:generate (<version>) ---> this part is not present for my custom module nor are classes for new fields generated. Regards Matjaž On Sat, 22 Mar 2025 at 21:34, Christoph John <chr...@ma...<mailto:chr...@ma...>> wrote: Which QFJ version are you using? But basically it should work as you suggested. Cheers Chris ________________________________ From: M J <mje...@gm...<mailto:mje...@gm...>> Sent: Saturday, March 22, 2025 4:38:40 PM To: qui...@li...<mailto:qui...@li...> <qui...@li...<mailto:qui...@li...>> Subject: [Quickfixj-users] new module Sie erhalten nicht häufig E-Mails von mje...@gm...<mailto:mje...@gm...>. Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification> Hi to all, I have a new DD xml, a lot of additional fields compared to 44. Could I just create a new module e. g. quickfixj-messages-fixMY and rebuild? I guess not, but have to ask. Thanks. Kind regards Matjaž |
|
From: M J <mje...@gm...> - 2025-03-22 21:31:39
|
Forgot to add: but it is listed under [INFO] Reactor Build Order Regards Matjaž On Sat, 22 Mar 2025 at 22:30, M J <mje...@gm...> wrote: > Just picked up the latest from github. > Could not get it done. Codegenerator is skipping it: > > quickfixj-codegenerator:3.0.0-SNAPSHOT:generate (<version>) ---> this part > is not present for my custom module nor are classes for new fields > generated. > > Regards > Matjaž > > > > On Sat, 22 Mar 2025 at 21:34, Christoph John <chr...@ma...> > wrote: > >> Which QFJ version are you using? >> But basically it should work as you suggested. >> Cheers >> Chris >> >> ------------------------------ >> *From:* M J <mje...@gm...> >> *Sent:* Saturday, March 22, 2025 4:38:40 PM >> *To:* qui...@li... < >> qui...@li...> >> *Subject:* [Quickfixj-users] new module >> >> Sie erhalten nicht häufig E-Mails von mje...@gm.... Erfahren Sie, >> warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification> >> Hi to all, >> >> I have a new DD xml, a lot of additional fields compared to 44. Could I >> just create a new module e. g. quickfixj-messages-fixMY and rebuild? I >> guess not, but have to ask. Thanks. >> >> Kind regards >> Matjaž >> > |
|
From: M J <mje...@gm...> - 2025-03-22 21:30:50
|
Just picked up the latest from github. Could not get it done. Codegenerator is skipping it: quickfixj-codegenerator:3.0.0-SNAPSHOT:generate (<version>) ---> this part is not present for my custom module nor are classes for new fields generated. Regards Matjaž On Sat, 22 Mar 2025 at 21:34, Christoph John <chr...@ma...> wrote: > Which QFJ version are you using? > But basically it should work as you suggested. > Cheers > Chris > > ------------------------------ > *From:* M J <mje...@gm...> > *Sent:* Saturday, March 22, 2025 4:38:40 PM > *To:* qui...@li... < > qui...@li...> > *Subject:* [Quickfixj-users] new module > > Sie erhalten nicht häufig E-Mails von mje...@gm.... Erfahren Sie, > warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification> > Hi to all, > > I have a new DD xml, a lot of additional fields compared to 44. Could I > just create a new module e. g. quickfixj-messages-fixMY and rebuild? I > guess not, but have to ask. Thanks. > > Kind regards > Matjaž > |
|
From: Christoph J. <chr...@ma...> - 2025-03-22 20:33:46
|
Which QFJ version are you using? But basically it should work as you suggested. Cheers Chris ________________________________ From: M J <mje...@gm...> Sent: Saturday, March 22, 2025 4:38:40 PM To: qui...@li... <qui...@li...> Subject: [Quickfixj-users] new module Sie erhalten nicht häufig E-Mails von mje...@gm.... Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification> Hi to all, I have a new DD xml, a lot of additional fields compared to 44. Could I just create a new module e. g. quickfixj-messages-fixMY and rebuild? I guess not, but have to ask. Thanks. Kind regards Matjaž |
|
From: M J <mje...@gm...> - 2025-03-22 19:59:52
|
Hi, when I change fix44.modified.xml with some additional fields, why are java classes for these new fields being created in all, fixlates, fix50, fix50sp1 and sp2 BUT NOT in fix44? What am I missing? Thanks. Kind regards Matjaž |
|
From: M J <mje...@gm...> - 2025-03-22 15:39:29
|
Hi to all, I have a new DD xml, a lot of additional fields compared to 44. Could I just create a new module e. g. quickfixj-messages-fixMY and rebuild? I guess not, but have to ask. Thanks. Kind regards Matjaž |
|
From: Christoph J. <chr...@ma...> - 2025-02-04 14:39:30
|
TLS1.3 is supported from JDK 1.8_261 or 262 onwards. That's why I said "older JDK 8 versions" do not work... Cheers Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB771A.F470CD90] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB771A.F470CD90]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB771A.F470CD90] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Gaurav Kumar <kum...@gm...> Sent: 04 February 2025 05:02 To: qui...@li... Subject: Re: [Quickfixj-users] Erorr with TLSv1.3 Sie erhalten nicht häufig E-Mails von kum...@gm...<mailto:kum...@gm...>. Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification> TLSv1.3 is supported in Java 8, I have updated Quickfix to version 2.3.2 and it's working fine. I will monitor for next couple of days. On Mon, 3 Feb 2025, 20:45 Christoph John, <chr...@ma...<mailto:chr...@ma...>> wrote: Hi Which QFJ version are you using? Which exact JDK distribution? TLS 1.3 will not work with older JDK 8 versions if I remember correctly. Cheers Chris ________________________________ From: Gaurav Kumar <kum...@gm...<mailto:kum...@gm...>> Sent: Monday, February 3, 2025 2:48:48 PM To: qui...@li...<mailto:qui...@li...> <qui...@li...<mailto:qui...@li...>> Subject: [Quickfixj-users] Erorr with TLSv1.3 Sie erhalten nicht häufig E-Mails von kum...@gm...<mailto:kum...@gm...>. Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification> Hi I'm trying to use TLSv1.3 to connect to the FIX session with my Java 8 application. However, I'm encountering the error below. Can anyone suggest what I need to do to resolve this? AEDT | TransportContext.java:3471 s close_notify ( "throwable": { javax.net.ssl.SSLException: closing inbound before receiving peer's close_notify at sun.security.ssl.Alert.createSSLException (Alert.java:133) at sun.security.ssl.Alert.createSSLException (Alert.java:117) at sun.security.ssl.TransportContext.fatal (TransportContext.java:342) at sun.security.ssl.TransportContext.fatal (TransportContext.java:298) TransportContext.fatal at sun.security.ssl.TransportContext. (TransportContext.java:289) at sun.security.ssl.SSLEngineImpl.closeInbound (SSLEngineImpl.java:640) at org.apache.mina.filter.ssl. lHandler.destroy (SslHandler.java:212) at org.apache.mina.filter.ssl.SslFilter.sessionClosed (SslFilter.java:471) at org.apache.mina.core.filterchain. DefaultIoFilterChain.callNextSessionClosed (DefaultIoFil at org.apache.mina.core.filterchain. DefaultIoFilterChain.access$900 (DefaultIoFilterChain.ja at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed DefaultIc -- Regards Gaurav |
|
From: Gaurav K. <kum...@gm...> - 2025-02-04 04:02:27
|
TLSv1.3 is supported in Java 8, I have updated Quickfix to version 2.3.2 and it's working fine. I will monitor for next couple of days. On Mon, 3 Feb 2025, 20:45 Christoph John, <chr...@ma...> wrote: > Hi > > Which QFJ version are you using? > Which exact JDK distribution? TLS 1.3 will not work with older JDK 8 > versions if I remember correctly. > > Cheers > Chris > > > ------------------------------ > *From:* Gaurav Kumar <kum...@gm...> > *Sent:* Monday, February 3, 2025 2:48:48 PM > *To:* qui...@li... < > qui...@li...> > *Subject:* [Quickfixj-users] Erorr with TLSv1.3 > > Sie erhalten nicht häufig E-Mails von kum...@gm.... Erfahren > Sie, warum dies wichtig ist > <https://aka.ms/LearnAboutSenderIdentification> > Hi > > I'm trying to use TLSv1.3 to connect to the FIX session with my Java 8 > application. However, I'm encountering the error below. Can anyone suggest > what I need to do to resolve this? > > > AEDT | TransportContext.java:3471 > s close_notify ( > "throwable": { > javax.net.ssl.SSLException: closing inbound before receiving peer's > close_notify > at sun.security.ssl.Alert.createSSLException (Alert.java:133) > at sun.security.ssl.Alert.createSSLException (Alert.java:117) > at sun.security.ssl.TransportContext.fatal (TransportContext.java:342) > at sun.security.ssl.TransportContext.fatal (TransportContext.java:298) > TransportContext.fatal at sun.security.ssl.TransportContext. > (TransportContext.java:289) > at sun.security.ssl.SSLEngineImpl.closeInbound (SSLEngineImpl.java:640) > at org.apache.mina.filter.ssl. lHandler.destroy (SslHandler.java:212) > > at org.apache.mina.filter.ssl.SslFilter.sessionClosed (SslFilter.java:471) > > at org.apache.mina.core.filterchain. > DefaultIoFilterChain.callNextSessionClosed (DefaultIoFil > > at org.apache.mina.core.filterchain. DefaultIoFilterChain.access$900 > (DefaultIoFilterChain.ja > > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed > DefaultIc > > > -- > Regards > Gaurav > > |
|
From: Christoph J. <chr...@ma...> - 2025-02-03 15:13:35
|
Hi Which QFJ version are you using? Which exact JDK distribution? TLS 1.3 will not work with older JDK 8 versions if I remember correctly. Cheers Chris ________________________________ From: Gaurav Kumar <kum...@gm...> Sent: Monday, February 3, 2025 2:48:48 PM To: qui...@li... <qui...@li...> Subject: [Quickfixj-users] Erorr with TLSv1.3 Sie erhalten nicht häufig E-Mails von kum...@gm.... Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification> Hi I'm trying to use TLSv1.3 to connect to the FIX session with my Java 8 application. However, I'm encountering the error below. Can anyone suggest what I need to do to resolve this? AEDT | TransportContext.java:3471 s close_notify ( "throwable": { javax.net.ssl.SSLException: closing inbound before receiving peer's close_notify at sun.security.ssl.Alert.createSSLException (Alert.java:133) at sun.security.ssl.Alert.createSSLException (Alert.java:117) at sun.security.ssl.TransportContext.fatal (TransportContext.java:342) at sun.security.ssl.TransportContext.fatal (TransportContext.java:298) TransportContext.fatal at sun.security.ssl.TransportContext. (TransportContext.java:289) at sun.security.ssl.SSLEngineImpl.closeInbound (SSLEngineImpl.java:640) at org.apache.mina.filter.ssl. lHandler.destroy (SslHandler.java:212) at org.apache.mina.filter.ssl.SslFilter.sessionClosed (SslFilter.java:471) at org.apache.mina.core.filterchain. DefaultIoFilterChain.callNextSessionClosed (DefaultIoFil at org.apache.mina.core.filterchain. DefaultIoFilterChain.access$900 (DefaultIoFilterChain.ja at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed DefaultIc -- Regards Gaurav |
|
From: Gaurav K. <kum...@gm...> - 2025-02-03 13:47:33
|
Hi
I'm trying to use TLSv1.3 to connect to the FIX session with my Java 8
application. However, I'm encountering the error below. Can anyone suggest
what I need to do to resolve this?
AEDT | TransportContext.java:3471
s close_notify (
"throwable": {
javax.net.ssl.SSLException: closing inbound before receiving peer's
close_notify
at sun.security.ssl.Alert.createSSLException (Alert.java:133)
at sun.security.ssl.Alert.createSSLException (Alert.java:117)
at sun.security.ssl.TransportContext.fatal (TransportContext.java:342)
at sun.security.ssl.TransportContext.fatal (TransportContext.java:298)
TransportContext.fatal at sun.security.ssl.TransportContext.
(TransportContext.java:289)
at sun.security.ssl.SSLEngineImpl.closeInbound (SSLEngineImpl.java:640)
at org.apache.mina.filter.ssl. lHandler.destroy (SslHandler.java:212)
at org.apache.mina.filter.ssl.SslFilter.sessionClosed (SslFilter.java:471)
at org.apache.mina.core.filterchain.
DefaultIoFilterChain.callNextSessionClosed (DefaultIoFil
at org.apache.mina.core.filterchain. DefaultIoFilterChain.access$900
(DefaultIoFilterChain.ja
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed
DefaultIc
--
Regards
Gaurav
|
|
From: Jalal K. <jk...@gr...> - 2025-01-27 16:56:26
|
No problem John. You answered my question. QFJ was not recycling the files because the session was configured as a nonStopSession, meaning it never gets reset From: Christoph John <chr...@ma...> Sent: 25 January 2025 21:04 To: Jalal Kharsa <jk...@gr...>; qui...@li... Subject: Re: Messages resend request problem [WARNING] External Email Hi Jalal, actually, I'd expect that the files get overwritten as soon as the session gets reset. But hard to tell without the information I asked for in my earlier mail. Cheers Chris ________________________________ From: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Sent: Friday, January 24, 2025 11:33:44 AM To: Christoph John <chr...@ma...<mailto:chr...@ma...>>; qui...@li...<mailto:qui...@li...> <qui...@li...<mailto:qui...@li...>> Subject: RE: Messages resend request problem No problem, Chris. Let me rephrase the question: Are there any QFJ configurations to clear down or set a maximum size limit for the FileStoreFactory files, particularly the .body and .header files? Regards, Jalal From: Christoph John <chr...@ma...<mailto:chr...@ma...>> Sent: 23 January 2025 16:25 To: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem [WARNING] External Email I’m even more confused now. 😊 Could you please post your session config and the messages in question with the seqnums 6988 till 7000 from that day and the log output where the wrong messages are resent. You have a file store you say. Are you accessing it concurrently, i.e. do you have several (standby) processes? Are you resetting your seqnums manually? Thanks Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB70CF.3C678500] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB70CF.3C678500]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB70CF.3C678500] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Sent: 23 January 2025 17:12 To: Christoph John <chr...@ma...<mailto:chr...@ma...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem Hi, The sequence numbers are being reset daily, and the sequence numbers requested for the resend have repeatedly appeared over the past two months, as approximately 15,000 to 20,000 messages are exchanged daily. However, instead of retrieving messages with the requested sequence numbers from the most recent date, QuickFIX/J retrieves messages from two months ago. I hope this provides further clarification. Regards, From: Christoph John <chr...@ma...<mailto:chr...@ma...>> Sent: 23 January 2025 15:59 To: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem You don't often get email from chr...@ma...<mailto:chr...@ma...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [WARNING] External Email Hi, ok, but what is the issue? The messages that have been asked for were delivered. QFJ or FIX protocol respectively do not care about the date but only about the seqnum. Do you never reset your seqnums? Or do you mean there were other messages resent that were not in the store? How should QFJ get messages from the store that are two months old? Shouldn’t the seqnum advance more than 22 seqnums in two months? I don’t get the whole picture it seems. Maybe you can elaborate? Thanks in advance and best regards Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB70CF.3C678500] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB70CF.3C678500]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB70CF.3C678500] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Sent: 23 January 2025 09:13 To: Christoph John <chr...@ma...<mailto:chr...@ma...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem Hi Chris, Sure, here we go 2025-01-16 17:29:58,554 O 8=FIX.4.4 9=73 35=A 34=6999 49=XXXXXXX 52=20250116-17:29:58.553 56=YYYYYY 98=0 108=30 10=231 2025-01-16 17:30:28,555 O 8=FIX.4.4 9=73 35=A 34=7000 49=XXXXXXX 52=20250116-17:30:28.555 56=YYYYYY 98=0 108=30 10=196 2025-01-16 17:30:28,636 I 8=FIX.4.4 9=0069 35=A 49=YYYYYY 56=XXXXXXX 34=6903 52=20250116-17:30:28 98=0 108=30 10=103 2025-01-16 17:30:28,637 I 8=FIX.4.4 9=0069 35=2 49=YYYYYY 56=XXXXXXX 34=6904 52=20250116-17:30:28 7=6988 16=0 10=105 2025-01-16 17:30:28,637 O 8=FIX.4.4 9=73 35=2 34=7001 49=XXXXXXX 52=20250116-17:30:28.637 56=YYYYYY 7=6900 16=0 10=183 And as I mentioned before, QFJ responded by sending the messages 6988 to 7000 from different date (from two months ago!) Regards, Jalal From: Christoph John <chr...@ma...<mailto:chr...@ma...>> Sent: 22 January 2025 17:03 To: qui...@li...<mailto:qui...@li...> Cc: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Subject: RE: Messages resend request problem You don't often get email from chr...@ma...<mailto:chr...@ma...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [WARNING] External Email Hi, I assume QFJ responded with a resend that matches the ResendRequest that the other side sent. Can you post the ResendRequest message that you received along with the Logon messages that were exchanged directly before the resend occurred? Thanks Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB70CF.3C678500] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB70CF.3C678500]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB70CF.3C678500] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa via Quickfixj-users <qui...@li...<mailto:qui...@li...>> Sent: 22 January 2025 16:22 To: qui...@li...<mailto:qui...@li...> Cc: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Subject: [Quickfixj-users] Messages resend request problem Hi All, I have established a connection as an Initiator that is communicating with an Acceptor (Server). I configured only the 'FileStorePath' element within the session's Storage settings, leaving the rest at their default values (FileStoreMaxCachedMsgs = 1000 and FileStoreSync=N). Recently, a network blip occurred, causing the Acceptor to send a message resend request. However, instead of retrieving and resending the most recent messages, Quickfixj responded by sending messages from two months ago. Can you provide any insight into the reason for this behavior and how it can be addressed? Regards, Jalal Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Gresham does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Gresham does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Gresham are neither given nor endorsed by the company or its directors. Gresham Technologies plc Registered in England and Wales. Company No. 01072032 Registered Office: Aldermary House, 10-15 Queen Street, London, EC4N 1TX. Further information about Gresham Technologies can be found on our website: www.greshamtech.com<http://www.greshamtech.com/> |
|
From: Christoph J. <chr...@ma...> - 2025-01-25 21:19:53
|
Hi Jalal, actually, I'd expect that the files get overwritten as soon as the session gets reset. But hard to tell without the information I asked for in my earlier mail. Cheers Chris ________________________________ From: Jalal Kharsa <jk...@gr...> Sent: Friday, January 24, 2025 11:33:44 AM To: Christoph John <chr...@ma...>; qui...@li... <qui...@li...> Subject: RE: Messages resend request problem No problem, Chris. Let me rephrase the question: Are there any QFJ configurations to clear down or set a maximum size limit for the FileStoreFactory files, particularly the .body and .header files? Regards, Jalal From: Christoph John <chr...@ma...> Sent: 23 January 2025 16:25 To: Jalal Kharsa <jk...@gr...>; qui...@li... Subject: RE: Messages resend request problem [WARNING] External Email I’m even more confused now. 😊 Could you please post your session config and the messages in question with the seqnums 6988 till 7000 from that day and the log output where the wrong messages are resent. You have a file store you say. Are you accessing it concurrently, i.e. do you have several (standby) processes? Are you resetting your seqnums manually? Thanks Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB6E4B.550BA270] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB6E4B.550BA270]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB6E4B.550BA270] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Sent: 23 January 2025 17:12 To: Christoph John <chr...@ma...<mailto:chr...@ma...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem Hi, The sequence numbers are being reset daily, and the sequence numbers requested for the resend have repeatedly appeared over the past two months, as approximately 15,000 to 20,000 messages are exchanged daily. However, instead of retrieving messages with the requested sequence numbers from the most recent date, QuickFIX/J retrieves messages from two months ago. I hope this provides further clarification. Regards, From: Christoph John <chr...@ma...<mailto:chr...@ma...>> Sent: 23 January 2025 15:59 To: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem You don't often get email from chr...@ma...<mailto:chr...@ma...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [WARNING] External Email Hi, ok, but what is the issue? The messages that have been asked for were delivered. QFJ or FIX protocol respectively do not care about the date but only about the seqnum. Do you never reset your seqnums? Or do you mean there were other messages resent that were not in the store? How should QFJ get messages from the store that are two months old? Shouldn’t the seqnum advance more than 22 seqnums in two months? I don’t get the whole picture it seems. Maybe you can elaborate? Thanks in advance and best regards Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB6E4B.550BA270] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB6E4B.550BA270]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB6E4B.550BA270] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Sent: 23 January 2025 09:13 To: Christoph John <chr...@ma...<mailto:chr...@ma...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem Hi Chris, Sure, here we go 2025-01-16 17:29:58,554 O 8=FIX.4.4 9=73 35=A 34=6999 49=XXXXXXX 52=20250116-17:29:58.553 56=YYYYYY 98=0 108=30 10=231 2025-01-16 17:30:28,555 O 8=FIX.4.4 9=73 35=A 34=7000 49=XXXXXXX 52=20250116-17:30:28.555 56=YYYYYY 98=0 108=30 10=196 2025-01-16 17:30:28,636 I 8=FIX.4.4 9=0069 35=A 49=YYYYYY 56=XXXXXXX 34=6903 52=20250116-17:30:28 98=0 108=30 10=103 2025-01-16 17:30:28,637 I 8=FIX.4.4 9=0069 35=2 49=YYYYYY 56=XXXXXXX 34=6904 52=20250116-17:30:28 7=6988 16=0 10=105 2025-01-16 17:30:28,637 O 8=FIX.4.4 9=73 35=2 34=7001 49=XXXXXXX 52=20250116-17:30:28.637 56=YYYYYY 7=6900 16=0 10=183 And as I mentioned before, QFJ responded by sending the messages 6988 to 7000 from different date (from two months ago!) Regards, Jalal From: Christoph John <chr...@ma...<mailto:chr...@ma...>> Sent: 22 January 2025 17:03 To: qui...@li...<mailto:qui...@li...> Cc: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Subject: RE: Messages resend request problem You don't often get email from chr...@ma...<mailto:chr...@ma...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [WARNING] External Email Hi, I assume QFJ responded with a resend that matches the ResendRequest that the other side sent. Can you post the ResendRequest message that you received along with the Logon messages that were exchanged directly before the resend occurred? Thanks Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB6E4B.550BA270] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB6E4B.550BA270]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB6E4B.550BA270] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa via Quickfixj-users <qui...@li...<mailto:qui...@li...>> Sent: 22 January 2025 16:22 To: qui...@li...<mailto:qui...@li...> Cc: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Subject: [Quickfixj-users] Messages resend request problem Hi All, I have established a connection as an Initiator that is communicating with an Acceptor (Server). I configured only the 'FileStorePath' element within the session's Storage settings, leaving the rest at their default values (FileStoreMaxCachedMsgs = 1000 and FileStoreSync=N). Recently, a network blip occurred, causing the Acceptor to send a message resend request. However, instead of retrieving and resending the most recent messages, Quickfixj responded by sending messages from two months ago. Can you provide any insight into the reason for this behavior and how it can be addressed? Regards, Jalal Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Gresham does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Gresham does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Gresham are neither given nor endorsed by the company or its directors. Gresham Technologies plc Registered in England and Wales. Company No. 01072032 Registered Office: Aldermary House, 10-15 Queen Street, London, EC4N 1TX. Further information about Gresham Technologies can be found on our website: www.greshamtech.com<http://www.greshamtech.com/> |
|
From: Jalal K. <jk...@gr...> - 2025-01-24 10:48:31
|
No problem, Chris. Let me rephrase the question: Are there any QFJ configurations to clear down or set a maximum size limit for the FileStoreFactory files, particularly the .body and .header files? Regards, Jalal From: Christoph John <chr...@ma...> Sent: 23 January 2025 16:25 To: Jalal Kharsa <jk...@gr...>; qui...@li... Subject: RE: Messages resend request problem [WARNING] External Email I’m even more confused now. 😊 Could you please post your session config and the messages in question with the seqnums 6988 till 7000 from that day and the log output where the wrong messages are resent. You have a file store you say. Are you accessing it concurrently, i.e. do you have several (standby) processes? Are you resetting your seqnums manually? Thanks Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB6E4B.550BA270] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB6E4B.550BA270]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB6E4B.550BA270] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Sent: 23 January 2025 17:12 To: Christoph John <chr...@ma...<mailto:chr...@ma...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem Hi, The sequence numbers are being reset daily, and the sequence numbers requested for the resend have repeatedly appeared over the past two months, as approximately 15,000 to 20,000 messages are exchanged daily. However, instead of retrieving messages with the requested sequence numbers from the most recent date, QuickFIX/J retrieves messages from two months ago. I hope this provides further clarification. Regards, From: Christoph John <chr...@ma...<mailto:chr...@ma...>> Sent: 23 January 2025 15:59 To: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem You don't often get email from chr...@ma...<mailto:chr...@ma...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [WARNING] External Email Hi, ok, but what is the issue? The messages that have been asked for were delivered. QFJ or FIX protocol respectively do not care about the date but only about the seqnum. Do you never reset your seqnums? Or do you mean there were other messages resent that were not in the store? How should QFJ get messages from the store that are two months old? Shouldn’t the seqnum advance more than 22 seqnums in two months? I don’t get the whole picture it seems. Maybe you can elaborate? Thanks in advance and best regards Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB6E4B.550BA270] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB6E4B.550BA270]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB6E4B.550BA270] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Sent: 23 January 2025 09:13 To: Christoph John <chr...@ma...<mailto:chr...@ma...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem Hi Chris, Sure, here we go 2025-01-16 17:29:58,554 O 8=FIX.4.4 9=73 35=A 34=6999 49=XXXXXXX 52=20250116-17:29:58.553 56=YYYYYY 98=0 108=30 10=231 2025-01-16 17:30:28,555 O 8=FIX.4.4 9=73 35=A 34=7000 49=XXXXXXX 52=20250116-17:30:28.555 56=YYYYYY 98=0 108=30 10=196 2025-01-16 17:30:28,636 I 8=FIX.4.4 9=0069 35=A 49=YYYYYY 56=XXXXXXX 34=6903 52=20250116-17:30:28 98=0 108=30 10=103 2025-01-16 17:30:28,637 I 8=FIX.4.4 9=0069 35=2 49=YYYYYY 56=XXXXXXX 34=6904 52=20250116-17:30:28 7=6988 16=0 10=105 2025-01-16 17:30:28,637 O 8=FIX.4.4 9=73 35=2 34=7001 49=XXXXXXX 52=20250116-17:30:28.637 56=YYYYYY 7=6900 16=0 10=183 And as I mentioned before, QFJ responded by sending the messages 6988 to 7000 from different date (from two months ago!) Regards, Jalal From: Christoph John <chr...@ma...<mailto:chr...@ma...>> Sent: 22 January 2025 17:03 To: qui...@li...<mailto:qui...@li...> Cc: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Subject: RE: Messages resend request problem You don't often get email from chr...@ma...<mailto:chr...@ma...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [WARNING] External Email Hi, I assume QFJ responded with a resend that matches the ResendRequest that the other side sent. Can you post the ResendRequest message that you received along with the Logon messages that were exchanged directly before the resend occurred? Thanks Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB6E4B.550BA270] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB6E4B.550BA270]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB6E4B.550BA270] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa via Quickfixj-users <qui...@li...<mailto:qui...@li...>> Sent: 22 January 2025 16:22 To: qui...@li...<mailto:qui...@li...> Cc: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Subject: [Quickfixj-users] Messages resend request problem Hi All, I have established a connection as an Initiator that is communicating with an Acceptor (Server). I configured only the 'FileStorePath' element within the session's Storage settings, leaving the rest at their default values (FileStoreMaxCachedMsgs = 1000 and FileStoreSync=N). Recently, a network blip occurred, causing the Acceptor to send a message resend request. However, instead of retrieving and resending the most recent messages, Quickfixj responded by sending messages from two months ago. Can you provide any insight into the reason for this behavior and how it can be addressed? Regards, Jalal Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Gresham does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Gresham does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Gresham are neither given nor endorsed by the company or its directors. Gresham Technologies plc Registered in England and Wales. Company No. 01072032 Registered Office: Aldermary House, 10-15 Queen Street, London, EC4N 1TX. Further information about Gresham Technologies can be found on our website: www.greshamtech.com<http://www.greshamtech.com/> |
|
From: Christoph J. <chr...@ma...> - 2025-01-23 16:25:22
|
I’m even more confused now. 😊 Could you please post your session config and the messages in question with the seqnums 6988 till 7000 from that day and the log output where the wrong messages are resent. You have a file store you say. Are you accessing it concurrently, i.e. do you have several (standby) processes? Are you resetting your seqnums manually? Thanks Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB6DBB.C1D3B270] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB6DBB.C1D3B270]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB6DBB.C1D3B270] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa <jk...@gr...> Sent: 23 January 2025 17:12 To: Christoph John <chr...@ma...>; qui...@li... Subject: RE: Messages resend request problem Hi, The sequence numbers are being reset daily, and the sequence numbers requested for the resend have repeatedly appeared over the past two months, as approximately 15,000 to 20,000 messages are exchanged daily. However, instead of retrieving messages with the requested sequence numbers from the most recent date, QuickFIX/J retrieves messages from two months ago. I hope this provides further clarification. Regards, From: Christoph John <chr...@ma...<mailto:chr...@ma...>> Sent: 23 January 2025 15:59 To: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem You don't often get email from chr...@ma...<mailto:chr...@ma...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [WARNING] External Email Hi, ok, but what is the issue? The messages that have been asked for were delivered. QFJ or FIX protocol respectively do not care about the date but only about the seqnum. Do you never reset your seqnums? Or do you mean there were other messages resent that were not in the store? How should QFJ get messages from the store that are two months old? Shouldn’t the seqnum advance more than 22 seqnums in two months? I don’t get the whole picture it seems. Maybe you can elaborate? Thanks in advance and best regards Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB6DBB.C1D3B270] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB6DBB.C1D3B270]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB6DBB.C1D3B270] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Sent: 23 January 2025 09:13 To: Christoph John <chr...@ma...<mailto:chr...@ma...>>; qui...@li...<mailto:qui...@li...> Subject: RE: Messages resend request problem Hi Chris, Sure, here we go 2025-01-16 17:29:58,554 O 8=FIX.4.4 9=73 35=A 34=6999 49=XXXXXXX 52=20250116-17:29:58.553 56=YYYYYY 98=0 108=30 10=231 2025-01-16 17:30:28,555 O 8=FIX.4.4 9=73 35=A 34=7000 49=XXXXXXX 52=20250116-17:30:28.555 56=YYYYYY 98=0 108=30 10=196 2025-01-16 17:30:28,636 I 8=FIX.4.4 9=0069 35=A 49=YYYYYY 56=XXXXXXX 34=6903 52=20250116-17:30:28 98=0 108=30 10=103 2025-01-16 17:30:28,637 I 8=FIX.4.4 9=0069 35=2 49=YYYYYY 56=XXXXXXX 34=6904 52=20250116-17:30:28 7=6988 16=0 10=105 2025-01-16 17:30:28,637 O 8=FIX.4.4 9=73 35=2 34=7001 49=XXXXXXX 52=20250116-17:30:28.637 56=YYYYYY 7=6900 16=0 10=183 And as I mentioned before, QFJ responded by sending the messages 6988 to 7000 from different date (from two months ago!) Regards, Jalal From: Christoph John <chr...@ma...<mailto:chr...@ma...>> Sent: 22 January 2025 17:03 To: qui...@li...<mailto:qui...@li...> Cc: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Subject: RE: Messages resend request problem You don't often get email from chr...@ma...<mailto:chr...@ma...>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [WARNING] External Email Hi, I assume QFJ responded with a resend that matches the ResendRequest that the other side sent. Can you post the ResendRequest message that you received along with the Logon messages that were exchanged directly before the resend occurred? Thanks Chris -- Christoph John Software Engineering D +49 241 557080 28 chr...@ma...<mailto:chr...@ma...> [cid:image001.png@01DB6DBB.C1D3B270] MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com/> [cid:image002.png@01DB6DBB.C1D3B270]<https://www.linkedin.com/company/macd/> [cid:image003.png@01DB6DBB.C1D3B270] <https://www.xing.com/pages/macd> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald From: Jalal Kharsa via Quickfixj-users <qui...@li...<mailto:qui...@li...>> Sent: 22 January 2025 16:22 To: qui...@li...<mailto:qui...@li...> Cc: Jalal Kharsa <jk...@gr...<mailto:jk...@gr...>> Subject: [Quickfixj-users] Messages resend request problem Hi All, I have established a connection as an Initiator that is communicating with an Acceptor (Server). I configured only the 'FileStorePath' element within the session's Storage settings, leaving the rest at their default values (FileStoreMaxCachedMsgs = 1000 and FileStoreSync=N). Recently, a network blip occurred, causing the Acceptor to send a message resend request. However, instead of retrieving and resending the most recent messages, Quickfixj responded by sending messages from two months ago. Can you provide any insight into the reason for this behavior and how it can be addressed? Regards, Jalal Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Gresham does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Gresham does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Gresham are neither given nor endorsed by the company or its directors. Gresham Technologies plc Registered in England and Wales. Company No. 01072032 Registered Office: Aldermary House, 10-15 Queen Street, London, EC4N 1TX. Further information about Gresham Technologies can be found on our website: www.greshamtech.com<http://www.greshamtech.com/> |
103 messages has been excluded from this view by a project administrator.
