I like to serve a default response form stubby4j for a SOAP request with the same value I am receiving in request.
post: "[\\s\\S]*param1.([^<]+)[\\s\\S]*param2.([0-9]+)[\\s\\S]*param3.([^<]+)[\\s\\S]*param4.([^<]+)[\\s\\S]*"
Now the problem is, I can't ensure the sequence of input parameters coming in the request. So there is a chance that param2 comes first.
How can we handle this?
I really dint need it. I noticed that requests coming from the same client maintains the sequence of input field. So I need not to worry to compare or capture them with different patterns.
However due to some limitations of stubby4j, I have made my own utility and switched to stubby-db now.
Hi #Amit Kumar Gupta,
Thank you for using stubby4j and thank you for your question and I am really sorry for replying late. You are welcomed to have a look at stubby4j library now, the docs are at: https://stubby4j.com, as it has undergone many changes and improvements since 2016. I hope you can find features needed, if not, please raise an issue or a feature request.
In addition to HTTP/1.1, it also supports behavior stubbing over HTTP/2 and WebSockets (over HTTP/1.1) protocols. In the near future it will support WebSockets bootstrapping over HTTP/2
Plus, stubby4j has been Dockerized with the official images stored at https://hub.docker.com/r/azagniotov/stubby4j
Thank you.
Related
Can someone please explain me how the "Forever Frame" technique works ? A code example would be awesome! I went through all the material i could find in Google but i still don`t have much of an idea how it works.
Dylan Schiemann gives a great explanation.
In short, it uses "chunked encoding", a feature of HTTP/1.1 intended for an entirely different purpose, but which allows the server to maintain a connection to the client indefinitely, sending additional data to the client at will.
As Dylan says :
This technique is very low-latency because it avoids HTTP and TCP/IP set-up and tear-down by reusing a single long-lived connection.
http://cometdaily.com/2007/11/05/the-forever-frame-technique/
The rest of his article is well worth a read.
If I write an order routing system based on QuickfixJ, can I just start submitting my trades to an exchange? Or do I need to register myself with the exchange or get permission or something like that?
I am not able to understand how QuickfixJ, the order routing system, the actual trading engine and the exchange fits together. Any online architecture diagram would be very helpful for how these components fit together.
FIX is just a transmission protocol. By itself, it's pretty dumb. QuickFIX (any language port) is just an engine that does all the boring dirty work of managing a FIX connection.
The FIX specification includes a list of messages and fields. In reality, you can treat these as suggestions that, in practice, no commercial FIX counterparty uses as-is. Every counterparty I've connected to makes modifications to those messages and fields, sometimes adding entirely new messages. No counterparty supports every message and field.
When connecting to a counterparty, do not assume anything. Your counterparty should provide documentation on how they expect their interface to be used, and which messages and fields they will send and which they expect to receive from you.
Their docs should tell you which message to send them to request market data and any special fields/options you must use.
Their docs will tell you how to submit a trade.
Their docs will tell you how to do anything that they support, and which messages/fields you will receive in return.
Do not try to send any message type to your counterparty unless their docs say they support it.
If you are writing the ORS side... then you have no docs. If you haven't written a FIX client before, you probably shouldn't be writing a FIX server without some assistance from someone who has. At the least, you should try to get ahold of some other systems' FIX interface docs to get an idea of how to go about it. (Unfortunately, such firms usually only give them to client-developers.)
I have a single server which can have multiple clients. Each client sends an asynchronous message to the server which immediately routes the message to a third party provider. At some point in the future, the server receives a response from the third party provider which should immediately be routed back to the sending client. I have had a look at Akka but had trouble figuring out how to route messages from the server back to clients at arbitrary points in the future. If I can be given some pointers even to the right parts of documentation I'm happy to take it from there. At the moment I am bewildered by the array of frameworks and options available.
"I have had a look at Akka but had trouble figuring out how to route messages from the server back to clients at arbitrary points in the future."
When a message comes in from a client, store away the reference of the sender, so you can send to it later.
Perhaps if you elaborate on the problem you experienced we can assist?
Cheers,
√
BlueEyes is designed for this kind of workflow.
You could also use atmosphere.
If your clients are browsers, you can use Lift and its comet support. This post gives you one example of doing async work using Lift
Is it possible to send data on a socket over a TCP?IP connection from a PostgreSQL stored procedure or trigger?
If you know of any useful examples pleas tell me.
If you know of something similar for other data base systems it would also be helpful.
Thanks in advance.
Answer from Milen solves the technical side of the question. But there is also a problem of interactions.
Let's assume you have trigger that does things over TCPIP. This means that the query that launched the trigger can take a long time (think network issues, service issues, firewalls).
Usually much better solution is to store information in some kind of queue, and addition of service, which checks the queue (perhaps using NOTIFY/LISTEN feature of PostgreSQL), and does what's necessary over TCP/IP - with proper handling of long connections, retries and so on.
If you'd be inclined to use such mechanism, you might want to check PgQ from SkyTools.
Yes, it's possible but you have to use one of the "untrusted" languages - PL/perlU, PL/pythonU, etc.
And then all examples you need you'll find in the documentation of the respective language.
We need is to push sports data to a number of different client types such as ajax/javascript, flash, .NET and Mac/iPhone. Data updates need to only be near-real time with delays of several seconds being acceptable.
How to best accomplish this?
The best solution (if we're talking .NET) seem to be to use WCF and streaming http. The client makes the first http connection to the server at port 80, the connection is then kept open with a streaming response that never ends. (And if it does it reconnects).
Here's a sample that demonstrates this: Streaming XML.
The solution to pushing through firewalls: Keeping connections open in IIS
I would go with XML. XML is widely supported on all platforms and has lots of libraries and tools available for it. And since it's text, there are no issues when you pass it between platforms.
I know JSON is another alternative, but I'm not familiar enough with it to know whether or not to recommend it in this case.