Section 6.3.6.4 and the bottom of section 7.2 of the CometD documentation discuss how to establish a Listener on the /meta/handshake channel to map user IDs to ServerSessions/ServerSession IDs for use in private messaging. However, when listening on the /meta/handshake channel, the ServerSession received is null, so there is no way to create the map. Any thoughts?
UPDATE:
My assumption at this point is that the HandshakeHandler Listener (added to the /meta/handshake channel in the initializeMetaChannels method of BayeuxServerImpl.java) is getting invoked after or at the same time as the custom Listener that I have created on the same channel. Since the HandshakeHandler is what actually creates the ServerSession, this results in my custom Listener receiving a null ServerSession. This is supported by the fact that the BayeuxServer SecurityPolicy's canHandshake method, which gets invoked by the HandshakeHandler after it creates the ServerSession, is getting invoked after my custom listener. I presume that the CometD documentation stating that a ServerSession to UserID map can be constructed from within a /meta/handshake Listener is in error.
Your updated analysis is correct.
The documentation should be updated, since the first point where the session will be available is in SecurityPolicy.canHandshake().
I tracked this issue with http://bugs.cometd.org/browse/COMETD-522.
Related
Have investigated sample code to subscribe DataLogger to move sensors.
https://bitbucket.org/suunto/movesense-mobile-lib/src/master/android/samples/DataLoggerSample/
But failed to subscribe to my own whiteboard resource.
As example used jump counter from jump count sample.
https://bitbucket.org/suunto/movesense-device-lib/src/master/samples/jumpmeter_app/
WB_RES::LOCAL::SAMPLE_JUMPCOUNTER_JUMPCOUNT::LID
And have tried to connect to it by
DataLoggerConfig.DataEntry[] entries = {new DataLoggerConfig.DataEntry('/Sample/JumpCounter/JumpCount')};
But get only last value, not all the values.
What need to do else?
Or have some sample of DataLogger service to be configured to subscribe to your own whiteboard resource?
There is a bug in the SBEM to JSON conversion (or the .../Descriptors) that causes this if the resource notification type is a simple primitive type (like integer). Change the API to return a complex type and it will work.
Full Disclosure: I work for the movesense team
I am sending messages to ASB using WCF NetMessaging.
The message can contain any number of custom data contracts.
I have a Service Fabric stateless service with a custom listener for ASB delivering messages pushed onto the queue. All examples I’ve seen are able to only handle a single type of message (seems most guidance is to serializable to JSON but that’s not what I need to do here). I want the subscriber to the queue be able to handle a number of messages (any message sent to any action of the service).
I am able to add the Action to the BrokeredMessage.Properties so I know where to send it. The problem is I haven’t figured out how deserialize the message body in any way that works.
I can read it from a stream and get it to a string, but can’t do this:
var myDTO = message.GetBody();
That throws serialization exceptions. I’ve also tried a variant of that passing in a DataContractSerializer - even though I think that is the default.
Furthermore, what I really need is a way to do this without knowing the type of data in the body - I could, conceivably, add more message.Properties for the types serialized in the body but I figure there has to be a direct way to do it using only the data in the body - after all WCF and similar techs do this with ease. But how?
Thanks for any help,
Will
To have a stand-alone message body:
Create an envelope type that describes the content (Type name, sender, timestamp, etc.), and holds a payload (string) property to contain the serialized object.
To send out messages, you serialize (compress, encrypt) the object, assign the result to the payload property of an Envelope instance. Serialize the Envelope and send that out.
To receive messages, deserialize the message body into an Envelope, examine the type information, and deserialzie the payload.
This is more or less how SOAP based WCF services do/did it.
Make sure your DTO is datacontract-serializable, by creating some unit tests.
Keep in mind that the message body size is limited in ASB, XML may not be your best choice of serialization.
You may also be hitting this issue.
I'm currently writing a distributed application with a microservice architecture.
For that I am applying the CQRS pattern and event sourcing with the help of the axon framework. Therefore the data is eventual consistent.
Both, the write and the read side, are accessible over HTTP; REST specifically.
The initial problem:
After updating/creating an entity, the user [1] should be able to see the results. Because the events are handled asynchronously, the client/UI doesn't know when the entity is really updated (or created). So when the client fetches the data after sending the update-request but before the event is processed, the unchanged data is returned. Therefore the user could think, that the application is broken and/or sends a new request.
Solution attempt:
While looking for a solution for the read-after-write problem I came accross this blog entry.
There is proposed to return the new entity version in the write response. The client can then request the data with the expected entity version (as Expect header). If the actual version is equal or greater than the expected version, the data is returned. Or else an empty response with a Retry-After Header is returned.
The problem:
When the client sends an UpdateFoo request to the write side, the application sends a corresponding UpdateFooCommand over the CommandGateway. The Command is processed by the entity aggregate which publishes the FooUpdatedEvent. The read side receives this event and updates its entity view which can be accessed over the REST interface of the read side.
This is controlled by the axon framework. The handlers are annotated with #CommandHandler and #EventSourcingHandler respectively.
Now: How can I access the new version number of the affected entity in the CommandHandler, so that this number can be returned in the update response?
Thanks in advance
[1] Not only users. There can als be non human clients.
you can use AggregateLifecycle.getVersion() from within your aggregate. You can choose to return that value as part of your command's results and pass that information when doing a query. If the query doesn't have that version number of the aggregate's information, yet, you can (wait and) retry.
I'm pretty new to the FIX protocol and was hoping someone could help clarify some terms.
In particular could someone explain (perhaps with an example) the flow of NewOrderSingle, ExecutionReport, CancelReplaceRequest and how the fields ClOrdID, OrdID, OrigClOrdID are used within those messages?
A quick note about usages of fields. My experience is that many who implement FIX do it slightly differently. So be aware that though I am trying to explain correct usage you may find that there are differences between implementations. When I connect to a new broker I get a FIX specification which details exactly how they use the protocol. I have to be very careful to make sure where they have deviated from other implementations.
That said I will give you a rundown of what you have asked for.
There are more complicated orders but NewOrderSingle is the one most used. It allows you to create a trade for any asset. You will need to create a new order using this object / msg type. Then you will send it through your session using the method sendToTarget(). You can modify the message after this point through the toApp() method, assuming your application implements the quickfix.Application interface.
The broker (or whoever you are connected to) will send you a reply in the form of and Execution report. Using quickfix that reply will enter your application through the fromApp() callback. From there the best thing to do is to implement your app inheriting from the MessageCracker class (or implement it elsewhere) using the crack method from MessageCracker it will then call back a relevant onMessage() method call. You will need to implement a number of these onMessage() methods (it depends on specifically what you are doing as to which methods you will need), the main one being onMessage(ExecutionReport msg, SessionID session). This method will be called by message cracker when you receive and Execution report from the broker. This is the standard reply to a new order.
From there you handle the reply as required.
Some orders do not get filled immediately like Limit orders. They can be changed. For that you will need the CancelReplaceRequest. Your broker will give you details of how to do this specifically for them (again there are differences and not everyone does it the same). You will have to have done a NewOrderSingle first and then you will use this MsgType to update it.
ClOrdID is an ID that the client uses to identify the order. It is sent with the NewOrderSingle and returned in the ExecutionReport. The OrdID tag is in the ExecutionReport message, it is the ID that the broker will use to identify the order. OrgClOrdID is usually used to identify the original order in when you do and update (using CancelReplaceRequest), it is supposed to contain the ClOrdID of the original order. Some brokers want the original order only, others want the ClOrdID of the last update, so the first OrigClOrdID or will be the ClOrdID of the NewOrderSingle, then if there are subsequent updates to the same order then they will be the ClOrderID from the last CancelReplaceRequest. Some brokers want the last OrderID and not ClOrderID. Note that the CancelReplaceRequest will require a ClOrdID as well.
Been looking at a lot of gwt request factory examples lately but still can't quite find the complete picture:
GWT request factory's sweet spot is CRUD (create/read/update/delete). Having said that:
Even in the "update" case, it is not clear to me who is responsible for firing a EntityProxyChange (Event)
I read somewhere (forget where) that the client side request factory keeps a local cache of EntityProxy that it has 'seen', and, if it 'sees' a new one then it fires a EntityProxyChange (Event)
does that mean that, if my "updatePerson()" method returns a (newly updated) PersonProxy, then does the local client side request factory infrastructure 'see' this newly updated person (i.e., by virtue of its updated versionId) and then does it automatically fire a EntityProxyChange (Event) ?
In the "delete" case, say I create a function called "deletePerson()" in my request context, I understand how the request arrives at the server and one might do, e.g., a SQL DELETE to delete the entity, but, who is responsible for firing a EntityProxyChange (Event) w/WriteOperation=DELETE ? do these events get fired at the server side? the client side?
I've had a look at the listwidget example (http://code.google.com/p/listwidget), but, on a 'itemlist' delete, it kinda 'cheats' by just doing a brute force refresh of the entire list (though I do understand that that detail is not necessarily what listwidget is trying to illustrate in the first place); I would have expected to see a EntityProxyChange (Event) handler that listens for WriteOperation.DELETE events and then would just remove just that entity from the ListDataProvider.
Does ServiceLayer/ServiceLayerDecorator.isLive() factor into any of this?
See http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryMovingParts#Flow
The client-side doesn't keep a cache (that was probably the case in the early iterations a year ago though, but has never been the case in non-milestones releases), and the server-side is responsible for "firing" the events (you'll see them in the JSON response payload).
When the wiki page referenced above says:
Entities that can be no longer retrieved ...
What it really means is that isLive has returned false, and isLive's implementation defaults to doing a get by the ID and checking for a non-null result.