I am sending a Trade capture report request with 35 = AD. I am getting an acknowledge message back with 35=AQ(TradeCaptureReportRequestAck) with 750 =0 and another acknowledge message 35=AQ with 750=1. However I am not getting any 35=AE(TradeCaptureReport) messages even though there are trades booked on ICE.
I am using quickfixj.
You need to read the ICE FIX Trade Capture interface documentation.
If you don't see any AE messages in your message log, then they're not being sent to you. If you get an AQ/750=0 followed by a AQ/750=1 with no AEs in between, that means you've successfully received a TCR set of size 0.
I am quite familiar with the ICE FIX Trade Capture API. Their documentation is pretty good; please review it to make sure you understand how requests are honored.
As Grant pointed out it is important to differentiate between message received in log file and message received in your application. If the latter is not happening although you are seeing the messages in your log then you need to look at your MessageCracker implementation.
Related
I'm using the simple-slack.api to send and receive Slack messages.
Is there a way to decide if a message was read?
I found that I can get the history of a channel, but the SlackMessagePosted does not contain any field if the message was read or not (the MessageSubType does not include it)
Its not possible.
The Slack API (e.g. channels.history or conversations.history) does not provide any information about which messages are unread and by whom.
The only thing you get is the total number of unread messages for your current user as defined by the token you are using (by setting the parameter unreads to true), but I guess that is not what you are looking for.
I have a problem with my client , I dont know where to look or pinpoint the problem but as far as I know im using qos 2 and my broker is mosquitto. Does anyone have any problem with messages that are not received but delivered?
My process is like these
ClientServer(acts as a bridge to the database) subscribed to "topic1"
Client publishes a payload to "topic1"
Something went wrong then ClientServer then send back to Client that it has not been saved.
Client receives the message and send the message with correct payload again.
ClientServer doesn't receive anymore (Mostly 2 - multiple times publish)
Then i use another client to send some mqtt-client statistics to send a payload message to the ClientServer and in the ClientServer publish tokens most ImqttDeliveryToken data is pending. I dont know why is it because of QOS 2?
So is there a problem with my current pseudo-code when using qos 2 with Client(having the same unique client-id) and ClientServer(having the same unique-client-id)?
PS: What i meant about same unique client-id is that since runtime my clients dont use generated client-id to allow qos 2 to work.
I think i found my answer.
Seems like in order to get over from this problem is to enter higher number of
max_inflight_messages
(in mosquitto.conf )
to N number of messages that makes the ClientServer accommodate, it was its default was 10 that i think thats why 100+ records sent asynchonously will be pending or i don't know what happened but it stopped processing incoming messages.
As for my testing I set it temporarily to 1000.
Hope some people might enlighten me for additional information about this inflight messages?
I'm building a client for trading with a remote server using FIX protocol and QuickFix/J API.
I can send order, receive price updates, cancel orders etc...
I'm asked now to "query API for current position of an instrument".
So let's say I can submit an order for buying an instrument, and it doesn't get executed, I would like to receive from the server some information like "you are LONG on intrument X with quantity Y etc".
Is it possible using QuickFix/J API?
I have written a method like this
static void positionReport() throws SessionNotFound{
quickfix.fix50.PositionReport order = new quickfix.fix50.PositionReport();
SessionID sessionId = (SessionID) initiator.getSessions().get(0);
order.set(new Account("1005390"));
order.set(new SecurityID("4663789"));
order.set(new SecurityExchange("XETR"));
order.set(new Symbol("SAP"));
Session.sendToTarget(order, sessionId);
}
which sends FIX messages like this
8=FIX.4.29=9835=AP34=4949=HIQ6_ORDER52=20140324-
15:54:10.14256=HIQFIX1=100539048=466378955=SAP207=XETR10=199
and receives messages like this:
8=FIX.4.29=9935=334=6949=HIQFIX52=20140324-15:54:10.89156=HIQ6_ORDER45=4958=Invalid
MsgType372=AP373=1110=242
As you can see I get "Invalid message" error
Check your counterparty's documentation.
FIX is a fairly "dumb" protocol. It just provides a communication infrastructure. The default message definitions are best thought of as a list of suggested messages that you can use. Even if one message type is supported by two counterparties, it's possible that each of the two counterparties could use it in totally different ways.
Most connection providers only use a subset of these messages. You should check their documentation to see if they support the PositionRequest message, and to see how they want you to set the fields in it.
No you cannot do that using Quickfix, unless and until the counterparty is modelled to give you FIX acknowledgements to your specific liking. That is why you can add your customized FIX fields to the FIX XML config file.
373 tag says 11 -> 11 = Invalid MsgType
58 confirms it for you again.
Check your FIX XML config and check if your message is complete and if your counterparty allows the messages of type AP.
I am trying to handle a FIX Reject (MsgType 35=3), but I am unclear on how to retrieve the message that is referred to by the FIX Reject message.
The FIX Reject refers to the rejected message by MsgSeqNum, in the RefSeqNum field (tag 45). However I don't know how to get the rejected message by its sequence number. I think it should be possible because the FIX engine can resend messages in a sequence number range (in response to a resend request), so if the engine can do it so should I.
The question: how do I get the message that is referenced by the reject message in the RefSeqNum field?
Do you want to programmatically handle this failure? Generally the lower level rejects should never happen in the production environment. I have always dealt with them while testing and manual inspection of messages to identify the actual message and the tag having the problem.
In any case you can programmatically get the message by:
First looking up the session using Session Session.lookupSession(SessionID sessionId)
Get the MessageStore associated with the Session using MessageStore Session.getStore()
Obtain the actual message using MemoryStore.get(int startSequence, int endSequence, Collection<String> messsages)
You can find API documentation for QuickFIX/J here, or visit the documentation folder.
Note that in step 3 you will have to pass the same sequence number as the start and the end sequence number.
I have a scenario whereby I want to inform users of my site that someone has commented on an article on which they have also commented. This is a lot like the way that SO notifies me when someone responds to a question!
Server side, I persist the comment and then look up all users who commented on the same article. I then broadcast (I'm using Atmosphere):
PushContext pushContext = PushContextFactory.getDefault().getPushContext();
for(User u : users){
// channel name, message
pushContext.push("/user_" + u.id, "someone commented! blah blah");
}
The "channel" I am broadcasting to is the user's "own" channel, since I don't want every user to be notified. I use the user's ID in the channel name to achieve this.
Is this the right way to do ensure only relevant users get notified?
I guess I also want to do two more things:
Only push to users whom I believe are still online. If they aren't online, then it's a waste of resources pushing to them.
Encrypt the message, because otherwise anybody could listen for my messages, if they know my user ID.
Is there anything else I need to think of?
SO uses WebSockets, for example when a comment is made on this posting, you get a notification in your status bar at the top left of the SO page.
When the page is loaded, the browser makes a protocol upgrade request which looks like this:
Request URL:ws://sockets-se.or.stackexchange.com/
Request Method:GET
Status Code:101 Switching Protocols
Request Headersview source
Connection:Upgrade
Cookie:__qca=P0-1697817643-1763440830313; __utma=27376923.959753990.1338240830.1353943751.1384115154.33; __utmc=27693525; __utmz=27699983.1356175156.31.31.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Host:sockets-se.or.stackexchange.com
Origin:http://stackoverflow.com
Sec-WebSocket-Extensions:x-webkit-deflate-frame
Sec-WebSocket-Key:6qFl45+6gZ526yMMo79zWQ==
Sec-WebSocket-Version:13
Upgrade:websocket
(Key3):00:00:00:00:00:00:00:00
Response Headersview source
Connection:Upgrade
Sec-WebSocket-Accept:B4h2G+gi78iNZZXg+o6iAztgF1I=
Upgrade:websocket
(Challenge Response):00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
The socket is then open, and the server can send updates to the browser. For example, a notification of my comment is received by the browser as:
{"action":"1-question-12993099","data":"{\"a\":\"comment-add\",\"id\":12993099,\"commentid\":19334206,\"acctid\":1298157}"}
It doesn't contain the actual comment; it appears that this is simply used to tell the browser to show the red icon. When you then click, it makes a request to get the page, including the comment. The question ID (12993099), comment ID (19334206) and account ID (1298157) is contained in that frame.
I cannot see anything in the above which would stop some hacker creating a web socket to listen to your notifications. The cookies look to me to be Google Analytics cookies to me, or at least the second and third ones do. Perhaps the first is some code which you wouldn't know, had I not just published it (no worries, I change it!).
In your example of Atmosphere, I know that when Web Sockets does not work, it defaults to long polling, which then requests a URL with the channel name in it. So you could get the client to generate a channel name which only it would know and associate that with the logged in user. But anyone sniffing the network would again have access to your traffic, so you'd have to secure it using secure web sockets (WSS) and HTTPS (for long polling fallback).