I'm currently using one Quickfix application to talk to another Quickfix application using FIX 4.2. Both applications are written by me in C++. I'm currently having an issue when I send an Order Cancel Request (FIX message type F). The receiving Quickfix application keeps rejecting my FIX message with "Incorrect data format for value:40".
The problem is, I'm not even sending Tag 40 in my Order Cancel Request message! I also checked my Data Dictionary and Tag 40 is not defined form Order Cancel Request messages.
Here is the Order Cancel Request message that I'm sending:
11032020-16:50:43.837819:(INFO) (outgoing): (FIX.4.2:TT->OMS) [8=FIX.4.2|9=118|35=F|34=68|49=TT|52=20201103-21:50:43.837|56=OMS|11=453000000025|41=453000000024|54=1|55=IBM|60=20201103-21:50:43.836|10=244|]
Here is what is being received by the server side and it's error message.
20201103-21:50:43.839340000 : Message 68 Rejected: Incorrect data format for value:40
Here is the FIX Reject message automatically generated by Quickfix:
11032020-16:50:43.839388:(INFO) (outgoing): (FIX.4.2:OMS->TT) [8=FIX.4.2|9=109|35=3|34=63|49=OMS|52=20201103-21:50:43.839|56=TT|45=68|58=Incorrect data format for value|371=40|372=F|373=6|10=176|]
As you can see, what I'm sending is exactly what's being received and there is no tag 40. Does anybody have any idea's what might be happening here??
Related
I have setup the HttpClient with ServiceUnavailableRetryStrategy. I am making a POST call to the server with JSON payload in InputStreamEntity.
When server returns with "503 Service Unavailable" the retry strategy kicks in and makes another request after a delay read from Retry-After header.
I have enabled the logs and what I observe is, in the first request the JSON payload is sent properly. But on the retry request no payload is sent to the server and I am receiving a "400 Bad Request".
I wonder why the payload is not sent on the retry request. In my implementation of ServiceUnavailableRetryStrategy I am not messing anything with HttpResponse or HttpContext. Is it because that once the content is read from InputStreamEntity, the Entity looses the data?
Is there anyway to prevent this from happening? Any help or suggestions will be appreciated.
thanks
The issue was actually with InputStreamEntity, which is a non-repeatable Entity. This means its content cannot be read more than once. So on retry the original Entity content was lost.
When I use a repeatable Enity like ByteArrayEntity, the issue was solved.
https://hc.apache.org/httpcomponents-client-4.5.x/current/tutorial/html/fundamentals.html#d5e119
I'm using the attach feature from Strophe.js, so when I lose my internet connection I can keep the same session alive.
Sometimes it works properly and I can do the attach, while I don't have any problem making different requests.
The problem apparently occurs when a request is pending, in queue, and is sent after the attach reconnection.
For example, I perform the attach with rid = 100 and when I perform a request (example: retrieve the roster) , the rid request is now 101, but when I check the console, I can see an stanza with rid = 98 has been sent, so I got an item-not-found error and the session closes. I know this error is because the rid is not correct.
Any idea where I can modify the code to avoid sending malformed rid stanzas? or any possible solution?
Thanks
I am using mongodb-queue to send the messages. To handle the errors, I'm using the separate channel which send the exceptions. When sending the exceptions, I need to retrieve the POJO.
Please let me know if you have any idea on how to do so.
You generally shouldn't be messing with the error-channel header with a header enricher - that is rarely needed; set an error-channel on the inbound endpoint. The message in the error channel will be an ErrorMessage with failedMessage and cause properties. The failedMessage is the message at the point of failure.
I made a Dynamic web project using Eclipse IDE. I made a simple web app for learning.
I also made a REST service (jersey implementation) which i am using for insert,update,delete and for listing records from mysql database.
Now i want that i've a registration form which has some fields. I want that before inserting the data into database using my REST service, the service should validate form data.
I searched a lot google. I understand how to validate data in my service. But i am not getting that how to show the error message to individual form field to client.
Is there any complete example of this which does not use maven and show me the whole working from submitting form to show the error messages.
Thanks in advance..please help me guys..
You should change your approach slightly to solve this problem and implement it in the following way:
First of all You should add validation mechanisms on the client side and send registration request only when this validation will be successful.
You will find form validation tutorial for AngularJS here:
https://docs.angularjs.org/guide/forms
http://www.ng-newsletter.com/posts/validations.html
and for jQuery here:
http://runnable.com/UZJ24Io3XEw2AABU/how-to-validate-forms-in-jquery-for-validation
Server should respond with propper HTTP statuses (with optional message). For example:
200 OK (or 201 Created) - when registration finished successfully;
400 Bad Request - when registration cannot be finished successfully;
So in Your actual use case:
User fills HTML form inputs;
Inserted data are validated on the client side;
When data are invalid, error message is shown in the propper place (individual form field);
When data are correct request is sent to the serwer;
Server application tries to insert supplied data to database;
If operation is finished properly, server will answer with 200 (or 201) status code. Registration is finished.
If operation is not finished properly, server will answer with 400. Client (AngularJS, jQuery, JS) will show error message.
Hopefully, my answer will help You. Ask if You need more explanation.
I need to know how we can restrict sending a "Resend Request". I'm copying the logs below. It appears that the "Resend Request" is being send from QuickFixEngine dll since we have not written any code for initiating a resend request. Please help me to solve how restrict a resend request. Also it appears that the MsgSeqNum is in correct order. Your help will be appreciated greatly.
8=FIX.4.29=5735=034=9949=UATENV52=20120717-16:31:28.29656=TRDUAT10=243
8=FIX.4.29=5835=049=TRDUAT56=UATENV52=20120717-16:28:34.24834=11910=029
8=FIX.4.29=37635=849=TRDUAT56=UATENV52=20120717-16:28:41.00434=12050=CBOEO57=Test_Trader37=1120716000006003150=139=120=060=20120717-16:28:40.00040=254=138=10442=2654=1167=OPT55=IBM44=-0.5077=O202=180.00201=1200=201207205=2121=359=01=TestAcct10115=USD14=56=0.50198=12280400019882=N17=071710150000128151=576=INCA30=CBOE75=2012071732=531=0.5011=82184825010=144
8=FIX.4.29=37935=849=TRDUAT56=UATENV52=20120717-16:28:41.00534=12150=CBOEO57=Test_Trader37=1120716000006004150=139=120=060=20120717-16:28:40.00040=254=238=20442=2654=2167=OPT55=IBM44=-0.5077=O202=185.00201=1200=201207205=2121=359=01=TestAcct10115=USD14=106=0.50198=12280400019882=N17=071720150000129151=1076=INCA30=CBOE75=2012071732=1031=0.5011=82184825010=036
8=FIX.4.29=6935=234=10049=UATENV52=20120717-16:31:35.50056=TRDUAT 7=120 *16=0* 10=230
8=FIX.4.29=37635=849=TRDUAT56=UATENV52=20120717-16:28:41.00534=12250=CBOEO57=Test_Trader37=1120716000006005150=139=120=060=20120717-16:28:40.00040=254=138=10442=2654=3167=OPT55=IBM44=-0.5077=O202=190.00201=1200=201207205=2121=359=01=TestAcct10115=USD14=56=0.50198=12280400019882=N17=071710150000130151=576=INCA30=CBOE75=2012071732=531=0.5011=82184825010=145
8=FIX.4.29=37935=834=12149=TRDUAT50=CBOEO52=20120717-16:28:41.00556=UATENV57=Test_Trader1=TestAcct1016=0.5011=82184825014=1015=USD17=07172015000012920=021=330=CBOE31=0.5032=1037=112071600000600438=2039=140=244=-0.5054=255=IBM59=060=20120717-16:28:40.00075=2012071776=INCA77=O150=1151=10167=OPT198=1228040001200=201207201=1202=185.00205=21442=2654=29882=N10=036
8=FIX.4.29=37635=834=12249=TRDUAT50=CBOEO52=20120717-16:28:41.00556=UATENV57=Test_Trader1=TestAcct1016=0.5011=82184825014=515=USD17=07171015000013020=021=330=CBOE31=0.5032=537=112071600000600538=1039=140=244=-0.5054=155=IBM59=060=20120717-16:28:40.00075=2012071776=INCA77=O150=1151=5167=OPT198=1228040001200=201207201=1202=190.00205=21442=2654=39882=N10=145
8=FIX.4.29=40735=849=TRDUAT56=UATENV52=20120717-16:28:41.444122=20120717-16:28:41.00443=Y34=12050=CBOEO57=Test_Trader37=1120716000006003150=139=120=060=20120717-16:28:40.00040=254=138=10442=2654=1167=OPT55=IBM44=-0.5077=O202=180.00201=1200=201207205=2121=359=01=TestAcct10115=USD14=56=0.50198=12280400019882=N17=071710150000128151=576=INCA30=CBOE75=2012071732=531=0.5011=82184825010=145
8=FIX.4.29=41035=849=TRDUAT56=UATENV52=20120717-16:28:41.444122=20120717-16:28:41.00543=Y34=12150=CBOEO57=Test_Trader37=1120716000006004150=139=120=060=20120717-16:28:40.00040=254=238=20442=2654=2167=OPT55=IBM44=-0.5077=O202=185.00201=1200=201207205=2121=359=01=TestAcct10115=USD14=106=0.50198=12280400019882=N17=071720150000129151=1076=INCA30=CBOE75=2012071732=1031=0.5011=82184825010=028
8=FIX.4.29=40735=849=TRDUAT56=UATENV52=20120717-16:28:41.444122=20120717-16:28:41.005
Thanks
Usually, you will get a resend request when reconnecting after a disconnect. It is important to make sure that you haven't missed any messages.
If you want to avoid it, you need to edit the quickfix config and set ResetOnLogon Logoff and disconnect to Y. That way it will not try to resend messages each time it disconnects.
I don't think this is a particularly good idea. You could miss messages. Why is the resend request a problem for you?
If you want to ignore ResendRequests (i.e you don't want to resend any messages) the correct way in FIX to do this is by responding with a SequenceReset.
You can achieve this in QuickFix be overriding the toApp() method and throwing a DoNotSend exception.
QuickFix will generate the correct SequenceReset response based on the ResendRequest that was issued.
Here's an example:
8=FIX.4.29=9135=234=349=MY-INITIATOR-SERVICE52=20160418-09:11:20.69456=MY-ACCEPTOR-SERVICE7=216=510=133
8=FIX.4.29=12435=434=243=Y49=MY-ACCEPTOR-SERVICE52=20160418-09:11:20.69756=MY-INITIATOR-SERVICE122=20160418-09:11:20.69736=2123=Y10=068