We have one customer who sends us thousands of web service requests per minute, and what we're seeing with all of their requests specifically is that the HTTP body comes across the wire, then there is a 150-250ms pause, and then the SOAP body is sent.
Being that the header knows the size of the request, I can rule out that this delay is caused by processing needed to generate the request itself.
Based on the user agent, I can determine that they're using Java 1.5, with HttpsUrlConnection. I don't have access to their code (yet), but I'm wondering if people have seen this behavior or not with poorly written code?
My side: A set of Apache web servers, that are front-ended with load balancers, firewalls, ... those web services take requests and use mod_proxy to send them back to Tomcat application servers.
(Again, this behavior is only seen with this one client, so I have doubts that something on my side is causing this...)
Ended up being a router on my customer's edge was completely saturated/overloaded, adding 400ms+ of latency.. So looks like something where the complete request couldn't be sent quick enough. We have reproduced this same behavior adding 400ms of latency with tcpproxy.
Sometimes it's the most obvious explanation, I guess...
Related
I want my JAVA play server to act as a man in the middle server, so that requests sent in are them forwarded to another, different server. Responses from this server are sent back to the initial requester.
I imagine this is a pretty standard user care, but I cannot find any code for Play 2.5 that does this. There is some other similar question around here, sadly it is for an older version of Play.
I would also like to be able to log all incoming /outgoing requests. All requests are http://
All communications are over rest (or are just plain Gets). I'm not familiar with play framework and its CompletionStage stuff. Can i Please have some code that at least begins to put me in the right direction, I'm not looking for 10,000 mile high architecture stuff
:)
(Ideally answers will also cover scala, just because that is more comprehensive.)
I recommend having both servers communicate over rest. So the middle man server calls the processing server via rest. However there are other options like soap and RPC
This question might sound a bit abstract,answered (but did my search didn't stumble on a convenient answer) or not specific at all ,but I will try to provide as much information as I can.
I am building a mobile application which will gather and send sensory data to a remote server. The remote server will collect all these data in a mySQL database and make computations (not the mysql database ,another process/program) . What I wanna know is :
After some updates in the database , is it doable to send a response from a RESTful Server to a certain client (the one who like did the last update probably) ,using something like "a background thread"? Or this should be done via socket connection through server-client response?
Some remarks:
I am using javaEE, Spring MVC with hibernate and tomcat (cause I am familiar with the environment though in a more asynchronous manner).
I thought this would be a convenient way because the SQL schema is not much complicated and security and authentication issues are not needed (it's a prototype).
Also there is a front-end webpage that will have to visualize these data, so such a back-end system would look like a good option for getting the job done fast.
Lastly I saw this solution :
Is there a way to 'listen' for a database event and update a page in real time?
My issue is that besides the page I wanna update the client's side with messages from the RESTful server.
If all these above are unecessary and a more simple client-server application will prove better and less complex please be welcome to inform me.
Thank you in advance.
Generally you should upload your data to a resource on the server (e.g. POST /widgets and the server should immediately return with a 201 Created or (if creation is too slow and needs to happen later) 202 Accepted status. There are several approaches after that happens, each has their merits:
Polling - The server's response includes a location field which the client can then proceed to poll until a change happens (e.g. check for an update every second). This is the easiest approach and quite efficient if you use HTTP caching effectively and the average number of checks is relatively low.
Push notification - Server sends a push notification when the change happens, report's generated, etc. Obviously this requires you to store the client's details and their notification requirements. This is probably the cleanest approach and also easy to scale. In the case of Android (also iOS) you have free push notifications available via Google Cloud Messaging.
Set up a persistent connection between client and server, e.g. using a Websocket or low-level TCP connection. This should yield the fastest response times, but will probably be a drain on phone battery, harder to scale on the server, and more complex to code.
I've got a news server in Java and want to make it possible for clients to receive news as soon as they appear in database, without reloading client's page. For this purpose I decided to make HTTP request from client that returns response only after news become available. But if there are a lot of clients, server won't be able to accept new requests. So, is there any java technology that deals with it?
P.S. news server is just a similar model, but not an exactly problem, so, please, think about it more abstractedly=)
The term you're looking for is push communication. You could have a look at Comet, or the Java API for WebSockets.
could you please give me a sample code on how an Http Server(Java) receives the request of a client(android)? I mean the client sends the request via Httppost, how the server takes the content of these requests in order to see the context and reply? I am trying to built a chat application.
Thank you in advance!
The server-side of HTTP is usually implemented using the protocol stack provided by a web container. You would then implement your application's server-side as servlets. There are numerous tutorials on this.
If that's the way you want to proceed, look at one of the standard web containers; e.g. Tomcat, Jetty, Glassfish, etc. The source code for all of these is available for you to browse, though I should warn you that they are all complicated under the hood.
Assuming that your HTTP service is going to be delivering JSON or XML (rather than HTML) to clients, you may want to look into using a RESTful framework.
Have a look at ServerSocket. Keep in mind that accept() blocks and, as you will probably run it in a service, you will want to time it out and check for the completion of the service. That should probably run in its own thread as should the responders to requests.
From there, you can open input and output streams to receive the request and write the response. There are any number of packages that can help you with the interaction, or you can roll your own, but it doesn't seem like you've done a lot of homework. Perhaps some searching, reading, and more specific questions would more you along more quickly.
I work with a large Java web application which uses a service to return information. My key goal is to retrieve 100+ individual results as quick as possible. We've noticed that sending 100+ requests for information doesn't give us the best performance on the replies of data. Our solution was to break the 100+ requests into small batches (~15,25) and assemble them once all have been received.
I'm looking for a suggestion in Java to make 1 or 50 or 200 requests from the application, to the service, get back info to the application and perform another batch if there are more requests. If no requests left, assemble into on list and return that full list.
Any suggestions of form are welcome, thanks.
I use Spring Integration for this kind of thing. You can set up a configurable message splitter that chops up your request and sends off many tiny ones, and a message aggregator that knows when it has received all responses and can then give you back a single result.
Spring also has a product called Spring Batch that might be a useful alternative, but that is more for heavy batch processing which it doesn't sound like you are doing.
If possible / feasible, extend the /service to support handle multiple logical requests in a single protocol request; e.g. HTTP request.
In theory, the both the client and server side should be able to do the work with less overheads if the server side gets a single request. There should be savings on both the client and server sides.