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
|
|
From: Øyvind M. W. <oyv...@om...> - 2018-06-20 07:20:56
|
Hi Eric, If you control both the acceptor and initiator, make sure both run the same version of Java. Also check that the ciphers and MAC used in your certificate are supported in that version of Java. If you only control one side, check your counterpart’s TLS requirements, and upgrade or configure Java as needed. Weaker ciphers may be disabled in newer version of Java, while stronger ciphers are not supported in older versions. The following is a good resource for finding supported TLS versions and ciphers: https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https -Øyvind > 19. jun. 2018 kl. 23:00 skrev <eri...@th...> <eri...@th...>: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > I’m on 1.6.4. (Mainly because I am waiting for 2.1, which should have my PR) and Java 8. > > I have looked at the same page for 1.6.4. > > When you say the counterparty provided a certificate, do you mean a certificate that you put in the trusted store? > > I want to accept connection and force them to be encrypted. Nothing more complicated than that. > > >> On Jun 19, 2018, at 16:56, Christoph John <chr...@ma...> wrote: >> >> Hi, >> >> I assume you have already checked the following page: https://urldefense.proofpoint.com/v2/url?u=https-3A__quickfixj.org_usermanual_2.0.0__usage_secure-5Fcommunications.html&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=sSTe4DlDhQjgPuMO6k1XaWyj_YJaVQNxr23Nq_KlCy4&e= >> >> There also is a test SSLCertificateTest in the repo that has some examples. >> >> IIRC I only configured the Initiator side of a FIX connection for SSL and used a keystore. The counterparty provided the certificate. >> >> I also assume that you use a current Java version on both sides of the connection? Older versions might not support some ciphers. >> >> Cheers, >> Chris. >> >> Am 19. Juni 2018 20:39:30 MESZ schrieb eri...@th...: >>> QuickFIX/J Documentation: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=t3i5fJeH8OU0DExXAnJs9PdrGsSq3SXfroHRSfEOPEY&e= >>> QuickFIX/J Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_support_&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=bn2FO12yz_pzSSVMVK3cBu_Z2a7WbEu-Dl3FqIivpU0&e= >>> >>> >>> I’m having a hard time getting SSL working on Linux. >>> >>> I’m trying to use a self-signed certificate on a Acceptor. >>> >>> I generated a keystore with: >>> >>> keytool -genkey -keyalg RSA -alias foobar -keystore foobar.jks >>> -storepass foobar -validity 360 -keysize 2048 >>> >>> And I am configuring the acceptor to use it with: >>> >>> SocketUseSSL=Y >>> SocketKeyStore=foobar.jks >>> SocketKeyStorePassword=foobar >>> >>> It seems to be opening the keystore ok, but regardless of what I try I >>> end up with: >>> >>> Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in >>> common >>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) >>> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) >>> >>> When I try to accept a session. >>> >>> 1) Do I need to configure CipherSuites? Which ones? I am having trouble >>> figuring out how to figure that out. >>> >>> 2) Does the client need a keystore? I’m only trying to encrypt, not >>> authenticate. I’ve tried it with and without, same result. >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=Fk532B4FE9KmFkWCh_DwlzbuM70u46buQAy50WlI5sE&e= >>> _______________________________________________ >>> Quickfixj-users mailing list >>> Qui...@li... >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_quickfixj-2Dusers&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=q6T7mJGRH34yJiwvNAP2vP6_7UHrAgiLFg3eV_n9_-k&e= > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Christoph J. <chr...@ma...> - 2018-06-19 21:11:22
|
The counterparty provided a certificate and we put it into a Java keystore and used that in the config. Chris. Am 19. Juni 2018 23:00:57 MESZ schrieb eri...@th...: >I’m on 1.6.4. (Mainly because I am waiting for 2.1, which should have >my PR) and Java 8. > >I have looked at the same page for 1.6.4. > >When you say the counterparty provided a certificate, do you mean a >certificate that you put in the trusted store? > >I want to accept connection and force them to be encrypted. Nothing >more complicated than that. > > >> On Jun 19, 2018, at 16:56, Christoph John <chr...@ma...> >wrote: >> >> Hi, >> >> I assume you have already checked the following page: >https://urldefense.proofpoint.com/v2/url?u=https-3A__quickfixj.org_usermanual_2.0.0__usage_secure-5Fcommunications.html&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=sSTe4DlDhQjgPuMO6k1XaWyj_YJaVQNxr23Nq_KlCy4&e= > >> >> There also is a test SSLCertificateTest in the repo that has some >examples. >> >> IIRC I only configured the Initiator side of a FIX connection for SSL >and used a keystore. The counterparty provided the certificate. >> >> I also assume that you use a current Java version on both sides of >the connection? Older versions might not support some ciphers. >> >> Cheers, >> Chris. >> >> Am 19. Juni 2018 20:39:30 MESZ schrieb >eri...@th...: >>> QuickFIX/J Documentation: >https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=t3i5fJeH8OU0DExXAnJs9PdrGsSq3SXfroHRSfEOPEY&e= > >>> QuickFIX/J Support: >https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_support_&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=bn2FO12yz_pzSSVMVK3cBu_Z2a7WbEu-Dl3FqIivpU0&e= > >>> >>> >>> I’m having a hard time getting SSL working on Linux. >>> >>> I’m trying to use a self-signed certificate on a Acceptor. >>> >>> I generated a keystore with: >>> >>> keytool -genkey -keyalg RSA -alias foobar -keystore foobar.jks >>> -storepass foobar -validity 360 -keysize 2048 >>> >>> And I am configuring the acceptor to use it with: >>> >>> SocketUseSSL=Y >>> SocketKeyStore=foobar.jks >>> SocketKeyStorePassword=foobar >>> >>> It seems to be opening the keystore ok, but regardless of what I try >I >>> end up with: >>> >>> Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in >>> common >>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) >>> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) >>> >>> When I try to accept a session. >>> >>> 1) Do I need to configure CipherSuites? Which ones? I am having >trouble >>> figuring out how to figure that out. >>> >>> 2) Does the client need a keystore? I’m only trying to encrypt, not >>> authenticate. I’ve tried it with and without, same result. >>> >>> >>> >------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! >https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=Fk532B4FE9KmFkWCh_DwlzbuM70u46buQAy50WlI5sE&e= > >>> _______________________________________________ >>> Quickfixj-users mailing list >>> Qui...@li... >>> >https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_quickfixj-2Dusers&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=q6T7mJGRH34yJiwvNAP2vP6_7UHrAgiLFg3eV_n9_-k&e= > |
|
From: <eri...@th...> - 2018-06-19 21:01:20
|
I’m on 1.6.4. (Mainly because I am waiting for 2.1, which should have my PR) and Java 8. I have looked at the same page for 1.6.4. When you say the counterparty provided a certificate, do you mean a certificate that you put in the trusted store? I want to accept connection and force them to be encrypted. Nothing more complicated than that. > On Jun 19, 2018, at 16:56, Christoph John <chr...@ma...> wrote: > > Hi, > > I assume you have already checked the following page: https://urldefense.proofpoint.com/v2/url?u=https-3A__quickfixj.org_usermanual_2.0.0__usage_secure-5Fcommunications.html&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=sSTe4DlDhQjgPuMO6k1XaWyj_YJaVQNxr23Nq_KlCy4&e= > > There also is a test SSLCertificateTest in the repo that has some examples. > > IIRC I only configured the Initiator side of a FIX connection for SSL and used a keystore. The counterparty provided the certificate. > > I also assume that you use a current Java version on both sides of the connection? Older versions might not support some ciphers. > > Cheers, > Chris. > > Am 19. Juni 2018 20:39:30 MESZ schrieb eri...@th...: >> QuickFIX/J Documentation: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=t3i5fJeH8OU0DExXAnJs9PdrGsSq3SXfroHRSfEOPEY&e= >> QuickFIX/J Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_support_&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=bn2FO12yz_pzSSVMVK3cBu_Z2a7WbEu-Dl3FqIivpU0&e= >> >> >> I’m having a hard time getting SSL working on Linux. >> >> I’m trying to use a self-signed certificate on a Acceptor. >> >> I generated a keystore with: >> >> keytool -genkey -keyalg RSA -alias foobar -keystore foobar.jks >> -storepass foobar -validity 360 -keysize 2048 >> >> And I am configuring the acceptor to use it with: >> >> SocketUseSSL=Y >> SocketKeyStore=foobar.jks >> SocketKeyStorePassword=foobar >> >> It seems to be opening the keystore ok, but regardless of what I try I >> end up with: >> >> Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in >> common >> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) >> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) >> >> When I try to accept a session. >> >> 1) Do I need to configure CipherSuites? Which ones? I am having trouble >> figuring out how to figure that out. >> >> 2) Does the client need a keystore? I’m only trying to encrypt, not >> authenticate. I’ve tried it with and without, same result. >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=Fk532B4FE9KmFkWCh_DwlzbuM70u46buQAy50WlI5sE&e= >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_quickfixj-2Dusers&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeNUy9E1BdEn0Yexsn39zMH1c1bf_uqj8xspuBPRHBi8O&m=3HYYWXGXrELFp0n0n6F73-FIYlJqp8jYN8qFwrCjnlw&s=q6T7mJGRH34yJiwvNAP2vP6_7UHrAgiLFg3eV_n9_-k&e= |
|
From: Christoph J. <chr...@ma...> - 2018-06-19 20:57:00
|
Hi, I assume you have already checked the following page: https://quickfixj.org/usermanual/2.0.0//usage/secure_communications.html There also is a test SSLCertificateTest in the repo that has some examples. IIRC I only configured the Initiator side of a FIX connection for SSL and used a keystore. The counterparty provided the certificate. I also assume that you use a current Java version on both sides of the connection? Older versions might not support some ciphers. Cheers, Chris. Am 19. Juni 2018 20:39:30 MESZ schrieb eri...@th...: >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ > > >I’m having a hard time getting SSL working on Linux. > >I’m trying to use a self-signed certificate on a Acceptor. > >I generated a keystore with: > >keytool -genkey -keyalg RSA -alias foobar -keystore foobar.jks >-storepass foobar -validity 360 -keysize 2048 > >And I am configuring the acceptor to use it with: > >SocketUseSSL=Y >SocketKeyStore=foobar.jks >SocketKeyStorePassword=foobar > >It seems to be opening the keystore ok, but regardless of what I try I >end up with: > >Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in >common > at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) > at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) > >When I try to accept a session. > >1) Do I need to configure CipherSuites? Which ones? I am having trouble >figuring out how to figure that out. > >2) Does the client need a keystore? I’m only trying to encrypt, not >authenticate. I’ve tried it with and without, same result. > > >------------------------------------------------------------------------------ >Check out the vibrant tech community on one of the world's most >engaging tech sites, Slashdot.org! http://sdm.link/slashdot >_______________________________________________ >Quickfixj-users mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: <eri...@th...> - 2018-06-19 18:40:10
|
I’m having a hard time getting SSL working on Linux. I’m trying to use a self-signed certificate on a Acceptor. I generated a keystore with: keytool -genkey -keyalg RSA -alias foobar -keystore foobar.jks -storepass foobar -validity 360 -keysize 2048 And I am configuring the acceptor to use it with: SocketUseSSL=Y SocketKeyStore=foobar.jks SocketKeyStorePassword=foobar It seems to be opening the keystore ok, but regardless of what I try I end up with: Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) When I try to accept a session. 1) Do I need to configure CipherSuites? Which ones? I am having trouble figuring out how to figure that out. 2) Does the client need a keystore? I’m only trying to encrypt, not authenticate. I’ve tried it with and without, same result. |
|
From: Christoph J. <chr...@ma...> - 2018-06-08 14:45:58
|
AFAIK FIX itself has no concept of session time. Maybe your counterparty's FIX session does not support the definition of start and end time. But if you agreed with them that a new session will start at a defined time then they should set up a cronjob or whatever to have their session reset then. Maybe double check that their time is equal to your time. E.g. we once had a problem with Bloomberg where the session was reset after a disconnection during the day and it turned out that they had configured a different time zone. Your proposed solution seems to be fine. Cheers, Chris. On 08/06/18 03:10, Robert Nicholson wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > We don’t want to configure 141=Y on every logon but my counterparty seems to only reset if I’m logged on at the time of the reset > and not at any particular agreed schedule. My understanding is that quickfixj will logoff at session end and my counterparty isn’t > expecting this. > > So should they reset at the agreed time whether I’m logged on or not and accept the sequence number I send on my next logon? > > They seem to need to coordinate a logout before they will recognize a reset. > > Session is daily. > > I’m likely to have to trap a logon when nextsenderseqnum is 1 via toAdmin and add 141=Y since I do not want to reset on every logon. -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Colin D. <co...@ma...> - 2018-06-08 13:55:36
|
I agree. It is my understanding that there is an implied sequence reset between session end and session start. On 06/08/2018 12:22 AM, Philip Whitehouse wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > >> So should they reset at the agreed time whether I’m logged on or not and accept the sequence number I send on my next logon? > Yes. > > Best, > > Philip Whitehouse > >> On 8 Jun 2018, at 02:10, Robert Nicholson <rob...@gm...> wrote: >> >> So should they reset at the agreed time whether I’m logged on or not and accept the sequence number I send on my next logon? > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Philip W. <ph...@wh...> - 2018-06-08 07:39:03
|
> So should they reset at the agreed time whether I’m logged on or not and accept the sequence number I send on my next logon? Yes. Best, Philip Whitehouse > On 8 Jun 2018, at 02:10, Robert Nicholson <rob...@gm...> wrote: > > So should they reset at the agreed time whether I’m logged on or not and accept the sequence number I send on my next logon? |
|
From: Øyvind M. W. <oyv...@om...> - 2018-06-08 07:27:25
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I am not sure I understands your counterparts specification and
behaviour. You also mention that the session is daily.</p>
<p>Is the problem that their implementation differs from how they
specify it?<br>
</p>
<p><br>
</p>
<div class="moz-signature">
<title></title>
<font face="Verdana"><small>Best regards<br>
<br>
<b><font color="#003366">Øyvind Matheson Wergeland</font></b><br>
CTO</small><br>
<small>
<br>
Mobile: (+47) 95 16 16 88<br>
E-mail: <a class="moz-txt-link-abbreviated" href="mailto:oyv...@om...">oyv...@om...</a><br>
<br>
<b><font color="#003366">Oslo Market Solutions</font></b><br>
PO Box 4, 0051 Oslo, Norway<br>
Telephone: (+47) 40 00 23 13<br>
<a class="moz-txt-link-abbreviated" href="http://www.oms.no">www.oms.no</a></small><br>
</font>
</div>
<div class="moz-cite-prefix">On 06/08/2018 03:10 AM, Robert
Nicholson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:142...@gm...">
<pre wrap="">QuickFIX/J Documentation: <a class="moz-txt-link-freetext" href="http://www.quickfixj.org/documentation/">http://www.quickfixj.org/documentation/</a>
QuickFIX/J Support: <a class="moz-txt-link-freetext" href="http://www.quickfixj.org/support/">http://www.quickfixj.org/support/</a>
We don’t want to configure 141=Y on every logon but my counterparty seems to only reset if I’m logged on at the time of the reset
and not at any particular agreed schedule. My understanding is that quickfixj will logoff at session end and my counterparty isn’t
expecting this.
So should they reset at the agreed time whether I’m logged on or not and accept the sequence number I send on my next logon?
They seem to need to coordinate a logout before they will recognize a reset.
Session is daily.
I’m likely to have to trap a logon when nextsenderseqnum is 1 via toAdmin and add 141=Y since I do not want to reset on every logon.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! <a class="moz-txt-link-freetext" href="http://sdm.link/slashdot">http://sdm.link/slashdot</a>
_______________________________________________
Quickfixj-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qui...@li...">Qui...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/quickfixj-users">https://lists.sourceforge.net/lists/listinfo/quickfixj-users</a>
</pre>
</blockquote>
<br>
</body>
</html>
|
|
From: Robert N. <rob...@gm...> - 2018-06-08 01:10:30
|
We don’t want to configure 141=Y on every logon but my counterparty seems to only reset if I’m logged on at the time of the reset and not at any particular agreed schedule. My understanding is that quickfixj will logoff at session end and my counterparty isn’t expecting this. So should they reset at the agreed time whether I’m logged on or not and accept the sequence number I send on my next logon? They seem to need to coordinate a logout before they will recognize a reset. Session is daily. I’m likely to have to trap a logon when nextsenderseqnum is 1 via toAdmin and add 141=Y since I do not want to reset on every logon. |
|
From: <th...@ft...> - 2018-05-31 18:53:51
|
We are also using QF/J SSL with several Bloomberg FIX sessions. Bloomberg will provide you with the keystore and it is really simple to configure. They can do it thru existing VPN connection or public internet. Good luck! -Tommy > On May 30, 2018, at 7:51 PM, dan...@or... wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > We're using qfj's built in SSL to establish session with Bloomberg. There seem to be no issues. > > > > On Wed, May 30, 2018 at 7:04 PM -0400, "Robert Nicholson" <rob...@gm... <mailto:rob...@gm...>> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > What are the options for TLS 1.2 with Bloomberg? > > Can VPN site to site be used for that? > > We also have to use socks proxy so is anybody using anything external to quickfixj to do their proxying? > > Ie local connection that’s then routed thru socks proxy without using any socks proxy support within quickfixj? > > Sent from my iPhone > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Colin D. <co...@ma...> - 2018-05-31 13:10:34
|
We've used both QFJ's built-in SSL for BBerg and also stunnel. A site-to-site VPN would not help. The VPN would provide connectivity between network segments, but the connection itself would still need to be encrypted. STunnel is very easy to use and configure. On 05/30/2018 05:51 PM, dan...@or... wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > We're using qfj's built in SSL to establish session with Bloomberg. > There seem to be no issues. > > > > On Wed, May 30, 2018 at 7:04 PM -0400, "Robert Nicholson" > <rob...@gm... <mailto:rob...@gm...>> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > What are the options for TLS 1.2 with Bloomberg? > > Can VPN site to site be used for that? > > We also have to use socks proxy so is anybody using anything external to quickfixj to do their proxying? > > Ie local connection that’s then routed thru socks proxy without using any socks proxy support within quickfixj? > > Sent from my iPhone > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: <dan...@or...> - 2018-05-31 01:03:42
|
We're using qfj's built in SSL to establish session with Bloomberg. There seem to be no issues. On Wed, May 30, 2018 at 7:04 PM -0400, "Robert Nicholson" <rob...@gm...> wrote: QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ What are the options for TLS 1.2 with Bloomberg? Can VPN site to site be used for that? We also have to use socks proxy so is anybody using anything external to quickfixj to do their proxying? Ie local connection that’s then routed thru socks proxy without using any socks proxy support within quickfixj? Sent from my iPhone ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Ramon E. <su...@ra...> - 2018-05-31 00:12:58
|
You can use OpenSSH to create a socks proxy and connect your existing software through it. Not sure what OS you're running but here are some instructions to look into for Linux: https://linux-tips.com/t/how-to-create-a-socks-proxy-tunnel-with-ssh/365 I know Putty on Windows can do the same as well. On Wed, May 30, 2018 at 7:05 PM Robert Nicholson <rob...@gm...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > What are the options for TLS 1.2 with Bloomberg? > > Can VPN site to site be used for that? > > We also have to use socks proxy so is anybody using anything external to > quickfixj to do their proxying? > > Ie local connection that’s then routed thru socks proxy without using any > socks proxy support within quickfixj? > > Sent from my iPhone > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
|
From: Robert N. <rob...@gm...> - 2018-05-30 23:03:31
|
What are the options for TLS 1.2 with Bloomberg? Can VPN site to site be used for that? We also have to use socks proxy so is anybody using anything external to quickfixj to do their proxying? Ie local connection that’s then routed thru socks proxy without using any socks proxy support within quickfixj? Sent from my iPhone |
|
From: Christoph J. <chr...@ma...> - 2018-05-25 07:33:41
|
Hi, in theory it should work. I only recall that there were changes done in https://www.quickfixj.org/jira/browse/QFJ-821 and https://www.quickfixj.org/jira/browse/QFJ-256 regarding client certificates and trust stores. If you do not require these changes then it should work. But I have never tested it and would recommend at least QFJ 1.6.3. Cheers, Chris. On 25/05/18 03:11, Robert Nicholson wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Which version of quickfixj after 1.52 supports TLS1.2? > > Can 1.52 with jdk8 work with TLS1.2? -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Christoph J. <chr...@ma...> - 2018-05-25 07:27:39
|
Hi Aleksander, oh, I even commented on that PR. But it is over three years old, so no wonder I forgot. ;) Cheers, Chris. On 24/05/18 17:06, Aleksander Fular wrote: > > Hello Chris, > > Thank you kindly for your prompt answer! > > I dug a little big deeper and the issue was fixed here: > > https://github.com/quickfix-j/quickfixj/commit/f8442f6 > > Well, I guess its time to upgrade! J > > Thanks, > > Aleksander Fular > > *From:*Christoph John [mailto:chr...@ma...] > *Sent:* Thursday, May 24, 2018 2:17 PM > *To:* qui...@li...; Aleksander Fular <Ale...@ig...> > *Cc:* Marcin Byszewski <Mar...@ig...> > *Subject:* Re: [Quickfixj-users] Similar issue to QFJ-592 but on the initiator side > > Hi, > > this could very well be an issue, although no-one has reported it for Initiators. I guess only > fixing it for the Acceptor was simply an oversight. > > IMHO a JIRA issue is not needed if you submit a PR directly. It would be great if you could add a > unit test also (in a similar manner as it was done for QFJ-592). If you need help just ask. > But please note that this can only be incorporated into 2.0.x and 2.x milestone. We will not do > any backports. Just saying because you are using a rather old version of QFJ. ;) > > Thanks in advance and best regards > Chris. > > On 24/05/18 10:39, Aleksander Fular wrote: > > QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ > > QuickFIX/J Support:http://www.quickfixj.org/support/ > > > > > Hello Quickfixj users, > > I am currently using an Application that uses quickfix 1.5.3. > > It seems that we have stumbled across an issue similar to the one mentioned in QFJ-592, > however this one is on the initiator side. > > The acceptor party that we connect to, sends us immediately a message after logon. > > Because of that we are sometimes left with an error from quickfix: > > */Invalid message: Can't determine ApplVerID for message …/* > > This only happens when we receive the message very shortly after receiving logon. > > I’ve taken a brief look at the code and the issue seems to be exactly the same as the issue > fixed In QFJ-592 however this one is on the initiator side. > > Where applVerId is set in the ‘*next(Message)*’ function, - line 908 Session.java file – > during processing messages in the queue > > it is required to be present in the *parse* method – invoked from messageReceived - > AbstractIoHandler – and this is invoked before putting message to queue. > > To me this looks exactly the same as issue solved in QFJ-592, and I am wondering why that > change was only applied to Acceptor. > > Can you guys please shed some light on this? > > Is this issue fixed in different branches? > > Is this something that you are aware of? > > If this is indeed an issue, do you want me to raise an issue on your jira & do a PR? > > Thanks, > > Aleksander Fular > > ---------------------------------------------------------------------------------------------------- > > > The information contained in this email is strictly confidential and for the use of the > addressee only, unless otherwise indicated. If you are not the intended recipient, please do > not read, copy, use or disclose to others this message or any attachment. Please also notify > the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the > email and any copies of it. Opinions, conclusions (etc) that do not relate to the official > business of this company shall be understood as neither given nor endorsed by it. IG Group > Holdings plc is a company registered in England and Wales under number 04677092. VAT > registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, > London EC4R 2YA. Listed on the London Stock Exchange. Its subsidiaries IG Markets Limited and > IG Index Limited are authorised and regulated by the Financial Conduct Authority (IG Markets > Limited FCA registration number 195355 and IG Index Limited FCA registration number 114059).- > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org!http://sdm.link/slashdot > > > > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... <mailto:Qui...@li...> > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Vipin C. <vip...@gm...> - 2018-05-25 04:08:05
|
I have used1.64 and it works with TLS1.2 On Fri, May 25, 2018 at 6:41 AM, Robert Nicholson < rob...@gm...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Which version of quickfixj after 1.52 supports TLS1.2? > > Can 1.52 with jdk8 work with TLS1.2? > > > Sent from my iPhone > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
|
From: Robert N. <rob...@gm...> - 2018-05-25 01:11:31
|
Which version of quickfixj after 1.52 supports TLS1.2? Can 1.52 with jdk8 work with TLS1.2? Sent from my iPhone |
|
From: Aleksander F. <Ale...@ig...> - 2018-05-24 15:06:38
|
Hello Chris, Thank you kindly for your prompt answer! I dug a little big deeper and the issue was fixed here: https://github.com/quickfix-j/quickfixj/commit/f8442f6 Well, I guess its time to upgrade! :) Thanks, Aleksander Fular From: Christoph John [mailto:chr...@ma...] Sent: Thursday, May 24, 2018 2:17 PM To: qui...@li...; Aleksander Fular <Ale...@ig...> Cc: Marcin Byszewski <Mar...@ig...> Subject: Re: [Quickfixj-users] Similar issue to QFJ-592 but on the initiator side Hi, this could very well be an issue, although no-one has reported it for Initiators. I guess only fixing it for the Acceptor was simply an oversight. IMHO a JIRA issue is not needed if you submit a PR directly. It would be great if you could add a unit test also (in a similar manner as it was done for QFJ-592). If you need help just ask. But please note that this can only be incorporated into 2.0.x and 2.x milestone. We will not do any backports. Just saying because you are using a rather old version of QFJ. ;) Thanks in advance and best regards Chris. On 24/05/18 10:39, Aleksander Fular wrote: QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Hello Quickfixj users, I am currently using an Application that uses quickfix 1.5.3. It seems that we have stumbled across an issue similar to the one mentioned in QFJ-592, however this one is on the initiator side. The acceptor party that we connect to, sends us immediately a message after logon. Because of that we are sometimes left with an error from quickfix: Invalid message: Can't determine ApplVerID for message ... This only happens when we receive the message very shortly after receiving logon. I've taken a brief look at the code and the issue seems to be exactly the same as the issue fixed In QFJ-592 however this one is on the initiator side. Where applVerId is set in the 'next(Message)' function, - line 908 Session.java file - during processing messages in the queue it is required to be present in the parse method - invoked from messageReceived - AbstractIoHandler - and this is invoked before putting message to queue. To me this looks exactly the same as issue solved in QFJ-592, and I am wondering why that change was only applied to Acceptor. Can you guys please shed some light on this? Is this issue fixed in different branches? Is this something that you are aware of? If this is indeed an issue, do you want me to raise an issue on your jira & do a PR? Thanks, Aleksander Fular ________________________________ The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Group Holdings plc is a company registered in England and Wales under number 04677092. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Listed on the London Stock Exchange. Its subsidiaries IG Markets Limited and IG Index Limited are authorised and regulated by the Financial Conduct Authority (IG Markets Limited FCA registration number 195355 and IG Index Limited FCA registration number 114059).- ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list Qui...@li...<mailto:Qui...@li...> https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma...<mailto:chr...@ma...> MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com<http://www.macd.com> Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Christoph J. <chr...@ma...> - 2018-05-24 12:17:21
|
Hi, this could very well be an issue, although no-one has reported it for Initiators. I guess only fixing it for the Acceptor was simply an oversight. IMHO a JIRA issue is not needed if you submit a PR directly. It would be great if you could add a unit test also (in a similar manner as it was done for QFJ-592). If you need help just ask. But please note that this can only be incorporated into 2.0.x and 2.x milestone. We will not do any backports. Just saying because you are using a rather old version of QFJ. ;) Thanks in advance and best regards Chris. On 24/05/18 10:39, Aleksander Fular wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Hello Quickfixj users, > > I am currently using an Application that uses quickfix 1.5.3. > > It seems that we have stumbled across an issue similar to the one mentioned in QFJ-592, however > this one is on the initiator side. > > The acceptor party that we connect to, sends us immediately a message after logon. > > Because of that we are sometimes left with an error from quickfix: > > */Invalid message: Can't determine ApplVerID for message …/* > > This only happens when we receive the message very shortly after receiving logon. > > I’ve taken a brief look at the code and the issue seems to be exactly the same as the issue fixed > In QFJ-592 however this one is on the initiator side. > > Where applVerId is set in the ‘*next(Message)*’ function, - line 908 Session.java file – during > processing messages in the queue > > it is required to be present in the *parse* method – invoked from messageReceived - > AbstractIoHandler – and this is invoked before putting message to queue. > > To me this looks exactly the same as issue solved in QFJ-592, and I am wondering why that change > was only applied to Acceptor. > > Can you guys please shed some light on this? > > Is this issue fixed in different branches? > > Is this something that you are aware of? > > If this is indeed an issue, do you want me to raise an issue on your jira & do a PR? > > Thanks, > > Aleksander Fular > > ---------------------------------------------------------------------------------------------------- > > The information contained in this email is strictly confidential and for the use of the addressee > only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, > use or disclose to others this message or any attachment. Please also notify the sender by > replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any > copies of it. Opinions, conclusions (etc) that do not relate to the official business of this > company shall be understood as neither given nor endorsed by it. IG Group Holdings plc is a > company registered in England and Wales under number 04677092. VAT registration number 761 2978 > 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Listed on the London > Stock Exchange. Its subsidiaries IG Markets Limited and IG Index Limited are authorised and > regulated by the Financial Conduct Authority (IG Markets Limited FCA registration number 195355 > and IG Index Limited FCA registration number 114059).- > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Aleksander F. <Ale...@ig...> - 2018-05-24 09:15:19
|
Hello Quickfixj users, I am currently using an Application that uses quickfix 1.5.3. It seems that we have stumbled across an issue similar to the one mentioned in QFJ-592, however this one is on the initiator side. The acceptor party that we connect to, sends us immediately a message after logon. Because of that we are sometimes left with an error from quickfix: Invalid message: Can't determine ApplVerID for message ... This only happens when we receive the message very shortly after receiving logon. I've taken a brief look at the code and the issue seems to be exactly the same as the issue fixed In QFJ-592 however this one is on the initiator side. Where applVerId is set in the 'next(Message)' function, - line 908 Session.java file - during processing messages in the queue it is required to be present in the parse method - invoked from messageReceived - AbstractIoHandler - and this is invoked before putting message to queue. To me this looks exactly the same as issue solved in QFJ-592, and I am wondering why that change was only applied to Acceptor. Can you guys please shed some light on this? Is this issue fixed in different branches? Is this something that you are aware of? If this is indeed an issue, do you want me to raise an issue on your jira & do a PR? Thanks, Aleksander Fular ________________________________ The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Group Holdings plc is a company registered in England and Wales under number 04677092. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Listed on the London Stock Exchange. Its subsidiaries IG Markets Limited and IG Index Limited are authorised and regulated by the Financial Conduct Authority (IG Markets Limited FCA registration number 195355 and IG Index Limited FCA registration number 114059).- |
|
From: Christoph J. <chr...@ma...> - 2018-05-16 11:32:16
|
It is up again. Thanks for the notice. You mean to migrate the site to github pages? I don't know how we could mirror it (automatically). I think there is not much information on quickfixj.org website, so it should not be too much effort (but anyway volunteers wanted ;)). But actually I'll have to ask the guys at SmartTrade who still manage the website if it is OK for them. Cheers, Chris. On 15/05/18 21:40, Philip Whitehouse wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Nope it’s down for me too. > > Have we considered a github.io <http://github.io> mirror? > > Best regards, > > Philip Whitehouse > > On 15 May 2018, at 19:23, Pontus Ullgren <ul...@gm... <mailto:ul...@gm...>> wrote: > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> <http://www.quickfixj.org/documentation/> >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Hello, >> >> I get a 503 response when trying to access https://www.quickfixj.org// >> >> Looking in Google cache I can see that it was atleast able to cache the page May 13:th. >> >> Is his a local problem for me or is there a problem with the site ? >> >> Best regards >> Pontus Ullgren >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org <http://Slashdot.org>! http://sdm.link/slashdot >> <http://sdm.link/slashdot> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Philip W. <Phi...@fl...> - 2018-05-15 21:13:14
|
Nope it’s down for me too. Have we considered a github.io<http://github.io> mirror? Best regards, Philip Whitehouse On 15 May 2018, at 19:23, Pontus Ullgren <ul...@gm...<mailto:ul...@gm...>> wrote: QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Hello, I get a 503 response when trying to access https://www.quickfixj.org// Looking in Google cache I can see that it was atleast able to cache the page May 13:th. Is his a local problem for me or is there a problem with the site ? Best regards Pontus Ullgren ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list Qui...@li...<mailto:Qui...@li...> https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Pontus U. <ul...@gm...> - 2018-05-15 18:22:56
|
Hello, I get a 503 response when trying to access https://www.quickfixj.org// Looking in Google cache I can see that it was atleast able to cache the page May 13:th. Is his a local problem for me or is there a problem with the site ? Best regards Pontus Ullgren |
103 messages has been excluded from this view by a project administrator.
